YADTR (Yet Another DateTime Rant)

[Terry Reedy]

I apologize for my poor choice of vocabulary.

I actually meant if you post on the tracker or python-ideas. There is a
little more leeway here. But as you maybe noticed. even here a trollish
word can divert discussion from you main point.

Back to your main point: the current output looks strange to me also.
But I did not follow the datetime development discussion. I do know that
the people responsible are not normally braindead ;-).

 

[Chris Angelico]

I do know that the people responsible are not normally braindead ;-).

Yeah, anyone who develops Python is clearly abnormally braindead...

*dives for cover*

ChrisA

 

[Steven D'Aprano]

Yes. The whole idea of OOD is to decouple internal representation from
external behavior.

The *whole* idea? You don't think that encapsulation and inheritance
might also be involved? *wink*

Besides, there's a difference between internal _representation_ and
internal _implementation_. I don't always choose my words carefully, but
this was one of those times

A timedelta object *represents* a delta as (days + seconds +
microseconds). That is part of the interface, not implementation. How it
is actually implemented is irrelevant. (If I were to take a wild guess,
I'd predict that timedeltas record the total number of seconds.)

That's what __repr__() is for.

Actually, __repr__ should, if practical, match the constructor for the
object:

py> import datetime
py> t = datetime.timedelta(2, 3)
py> eval(repr(t)) == t
True

Yes, I know that's what the docs say. That's why it's not an
implementation bug. It's a design bug

I don't think it is. Given a timedelta object with D days, S seconds and
M microseconds, I think that it is a very useful property if the string
also says it has D days, S seconds and M microseconds. Would you not
agree? I think that this would be silly:

str(timedelta(1, 0, 0))
=> '0 day, 24:01:-5184000.0'

even though it would be correct. So we can dismiss the idea that the str
of a timedelta should be free to arbitrarily vary from the internal
representation.

I consider this to be a useful constraint on timedelta's internal
representation (not implementation): the seconds and microseconds should
be normalised to the half-open intervals, 0 to 86400 for seconds and 0 to
1000000 for microseconds. Given that constraint, and the previous
constraint that strings should show the same number of days etc., and we
have the current behaviour.

Both constraints are reasonable. You have to weaken one, or the other, in
order to get the result you want. That's not necessarily unreasonable,
but neither is it a given. Python-Dev is not normally "braindead", so at
least given them the benefit of the doubt that *maybe* there's some good
reason we haven't thought of.

 

[Roy Smith]

Yes. The whole idea of OOD is to decouple internal representation from
external behavior.

The *whole* idea? You don't think that encapsulation and inheritance
might also be involved? *wink*[/QUOTE]

I'm not sure how "decoupling internal representation from external
behavior" is substantially different from encapsulation. And, no, I
don't think inheritance is a fundamental characteristic of OOD, nudge
nudge.

 

[Marko Rauhamaa]

I'm not sure how "decoupling internal representation from external
behavior" is substantially different from encapsulation.

Yes, that's encapsulation. The idea of encapsulation is older than OO.

And, no, I don't think inheritance is a fundamental characteristic of
OOD, nudge nudge.

Inheritance was there with Simula so I think it's high up there with OO.

If encapsulation exists outside OO and inheritance is not key to it,
what is OO then, a marketing term?

(It's a different thing, then, that encapsulation and inheritance are
mutually exclusive principles.)


Marko

 

[Chris Angelico]

If encapsulation exists outside OO and inheritance is not key to it,
what is OO then, a marketing term?

Yep, OO is a marketing term. So's programming - after all, it's just
flipping bits in memory... we only pretend it means anything. Do I
really exist, or do I just think I do?

ChrisA

 

[Roy Smith]

what is OO then, a marketing term?

Sometimes, I think it must be

(It's a different thing, then, that encapsulation and inheritance are
mutually exclusive principles.)

There're certainly not mutually exclusive. Mutually exclusive means if
you have one, you can't have the other.

I think the phrase you're looking for is "orthogonal concepts". You can
have either, or both, or neither, and the existence of one doesn't imply
anything about the existence of the other.

 

[Roy Smith]

Yep, OO is a marketing term. So's programming - after all, it's just
flipping bits in memory... we only pretend it means anything. Do I
really exist, or do I just think I do?

ChrisA

The real question is, what does this print:

c1 = ChrisA()
c2 = ChrisA()
print c1 == c2
print c2 is c2

 

[Rustom Mody]

Chris Angelico wrote:

The real question is, what does this print:

c1 = ChrisA()
c2 = ChrisA()
print c1 == c2
print c2 is c2

OO is of course a marketing term

Unicode OTOH is the real cure for all diseases

Proof by example:
Replace the last with
print c2 ≡ c2
or even better
print c2 ≣ c2

No confusion any more...
See? We all know now who (what?) Chris is!

 

[Chris Angelico]

The real question is, what does this print:

c1 = ChrisA()
c2 = ChrisA()
print c1 == c2
print c2 is c2

And if you could answer that, you would know whether my mother was
right when, in exasperation, she would say "Your design follows the
singleton principle!". Okay, so she actually was more likely to say
"You are one of a kind!", but it comes to the same thing...

ChrisA

 

[Marko Rauhamaa]

There're certainly not mutually exclusive. Mutually exclusive means if
you have one, you can't have the other.

Correct.

The classic inheritance diamond:

class A(B, C):
def add_bean(self):
??? # how to implement

class B(D): pass
class C(D): pass

class D:
def __init__(self):
self.beans = 0

def add_bean(self):
self.beans += 1

def bean_count(self):
return self.beans

cannot be dealt with without A addressing the common base class D. And
once it deals with it, A can be broken by reimplementing C without
inheriting it from D:

class C:
def __init__(self):
self.beans = ""

def add_bean(self):
self.beans += "o"

def bean_count(self):
return len(self.beans)

thus violating encapsulation.


Marko

 

[Steven D'Aprano]

The *whole* idea? You don't think that encapsulation and inheritance
might also be involved? *wink*

I'm not sure how "decoupling internal representation from external
behavior" is substantially different from encapsulation.[/QUOTE]

They are mostly unrelated. In the first, you're talking about information
hiding. The second, encapsulation, relates to the bundling of code and
data, optionally in such a way as to restrict or control access to some
or all of the encapsulated data.

Encapsulation can be used as a mechanism for information hiding, but need
not be.

https://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)

And, no, I
don't think inheritance is a fundamental characteristic of OOD, nudge
nudge.

That's not representative of what most people, and specifically
most computer scientists, consider fundamental to OOP.

https://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts

It's difficult to pin-point exactly what characteristics of OOP are
fundamental, but inheritance is surely one of them.

 

[Chris Angelico]

It's difficult to pin-point exactly what characteristics of OOP are
fundamental, but inheritance is surely one of them.

I've always understood OOP to be all about binding code and data
together (methods as part of an object, rather than functions
operating on data) - ie polymorphism, such that you say "do this" and
the object knows how its "do this" should be done. That's at least as
important as inheritance IMO.

But yes, it is very hard to pin it down.

ChrisA