Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #69089 > unrolled thread

YADTR (Yet Another DateTime Rant)

Back to article view | Back to comp.lang.python

Contents

  YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-25 20:58 -0400
    Re: YADTR (Yet Another DateTime Rant) Ethan Furman <ethan@stoneleaf.us> - 2014-03-25 18:19 -0700
    Re: YADTR (Yet Another DateTime Rant) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-26 09:27 +0000
    Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-26 08:37 -0500
      Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-26 08:04 -0700
        Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-26 10:39 -0500
          Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-26 17:58 +0200
            Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-26 11:34 -0500
              Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-26 19:13 +0200
              Re: YADTR (Yet Another DateTime Rant) Grant Edwards <invalid@invalid.invalid> - 2014-03-26 19:12 +0000
                Re: YADTR (Yet Another DateTime Rant) Ben Finney <ben+python@benfinney.id.au> - 2014-03-27 07:06 +1100
        Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-26 11:50 -0400
    Re: YADTR (Yet Another DateTime Rant) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-26 15:02 +0100
      Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-26 16:43 +0200
    Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 01:12 +1100
      Re: YADTR (Yet Another DateTime Rant) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-27 11:08 +1300
    Re: YADTR (Yet Another DateTime Rant) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-26 19:25 -0400
      Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-27 00:16 +0000
        Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 12:28 +1100
          Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-26 21:38 -0400
            Re: YADTR (Yet Another DateTime Rant) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-27 08:40 +0000
        Re: YADTR (Yet Another DateTime Rant) Dan Sommers <dan@tombstonezero.net> - 2014-03-27 03:56 +0000
        Re: YADTR (Yet Another DateTime Rant) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-27 11:22 +0100
          Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 21:44 +1100
            Re: YADTR (Yet Another DateTime Rant) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-27 12:05 +0100
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 22:33 +1100
            Re: YADTR (Yet Another DateTime Rant) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-27 12:25 +0100
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 22:42 +1100
              Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-27 06:56 -0500
                Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-27 16:04 +0200
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 23:20 +1100
              Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-27 08:01 -0500
              Re: YADTR (Yet Another DateTime Rant) Terry Reedy <tjreedy@udel.edu> - 2014-03-27 17:10 -0400
              Re: YADTR (Yet Another DateTime Rant) Ethan Furman <ethan@stoneleaf.us> - 2014-03-27 17:04 -0700
              Re: YADTR (Yet Another DateTime Rant) Terry Reedy <tjreedy@udel.edu> - 2014-03-27 21:46 -0400
                Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-27 21:59 -0400
                  Re: YADTR (Yet Another DateTime Rant) Terry Reedy <tjreedy@udel.edu> - 2014-03-27 22:24 -0400
                  Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-28 14:03 +1100
            Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-27 08:52 -0400
              Re: YADTR (Yet Another DateTime Rant) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-27 15:12 +0100
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-28 01:15 +1100
              Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-27 23:41 +0000
                Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-27 20:29 -0400
                  Re: YADTR (Yet Another DateTime Rant) Ben Finney <ben+python@benfinney.id.au> - 2014-03-28 11:43 +1100
                  Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-28 11:11 +0000
                    Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-28 08:30 -0400
                      Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-28 15:10 +0200
                        Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-29 00:19 +1100
                          Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-28 09:22 -0400
                            Re: YADTR (Yet Another DateTime Rant) Rustom Mody <rustompmody@gmail.com> - 2014-03-28 06:30 -0700
                            Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-29 00:32 +1100
                        Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-28 09:20 -0400
                          Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-28 16:34 +0200
                      Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-28 14:35 +0000
                        Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-29 02:25 +1100
    Re: YADTR (Yet Another DateTime Rant) Ethan Furman <ethan@stoneleaf.us> - 2014-03-26 16:33 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#69193

On Fri, Mar 28, 2014 at 1:12 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> I don't recall specifics, but I do remember multiple times
> where I was working with a structure that consisted of
> a whole part and a fracture part where I found it useful
> to have the fracture part always positive and displayed
> as such.

One has already been shared in this thread: Logarithms, where the part
before the decimal is the scale and the part after the decimal is the
mantissa. Makes very good sense to negate the first without changing
the second.

ChrisA

[toc] | [prev] | [next] | [standalone]

#69225

On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote:

> In article <mailman.8613.1395917059.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>> It's not "equally braindead", it follows a simple and logical rule:
>> Only the day portion is negative.
> 
> Simple and logical, yes.  But also entirely braindead.

Do you think it is "braindead" for __str__ to return something which 
follows the internal representation of the object?

Note that I'm not asking if that is the best choice for every object, or 
even the best choice for any object. You've made an extremely strong 
claim, by calling something "braindead" you're essentially arguing that 
this is an *utterly irredeemable choice whatsoever* with absolutely no 
redeeming features.

Hyperbole is fun, that's why we do it. It allows us to build up a nice 
feeling of righteous indignation over something utterly outrageous and 
indefensible, without having to worry about inconvenient distractions 
like other points of view :-)


>> That might not be perfectly suited to all situations
> 
> Give ma a real-life situation where you would want such behavior.

Easy -- I'm debugging timedelta routines, and I want to easily see that 
the timedeltas calculated match what I expect them to be when I print 
them. The quickest, easiest and simplest way is for str(timedelta) to 
follow the internal representation.

Oh look, that's exactly what the docs say:

"String representations of timedelta objects are normalized similarly to 
their internal representation. This leads to somewhat unusual results for 
negative timedeltas."

as Skip has already pointed out.

Is this the *best* choice for a timedelta? Probably not. But it's a 
simple, logical, *reasonable* choice. It only fails the "reasonable" test 
if you insist that timedelta objects *must* match the time-keeping 
conventions of native English speakers, and any other convention is 
unspeakable. For all we know, maybe (say) Koreans or Egyptians or Gaelic 
Scots do say something like "It was a day ago, less four hours" meaning 
twenty hours ago. Stranger things happen in natural language, and we 
ought to be cautious about insisting that English conventions are 
universal.

(Given Johannes Bauer's reaction, we can be fairly certain that German 
speakers follow a similar convention to English speakers. Which shouldn't 
be terribly surprising, since English is a Germanic language.)


A few seconds searching the bug tracker shows that this is not, in fact, 
a bug in timedelta but probably a deliberate feature:

http://bugs.python.org/issue9430

This one is also relevant: http://bugs.python.org/issue1569623


Alas, the discussion appears to have been on #python-dev, which 
(probably) means it is not archived anywhere.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#69229

In article <5334b747$0$29994$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote:
> 
> > In article <mailman.8613.1395917059.18130.python-list@python.org>,
> >  Chris Angelico <rosuav@gmail.com> wrote:
> >> It's not "equally braindead", it follows a simple and logical rule:
> >> Only the day portion is negative.
> > 
> > Simple and logical, yes.  But also entirely braindead.
> 
> Do you think it is "braindead" for __str__ to return something which 
> follows the internal representation of the object?

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

> > Give ma a real-life situation where you would want such behavior.
> 
> Easy -- I'm debugging timedelta routines, and I want to easily see that 
> the timedeltas calculated match what I expect them to be when I print 
> them. The quickest, easiest and simplest way is for str(timedelta) to 
> follow the internal representation.

That's what __repr__() is for.
 
> Oh look, that's exactly what the docs say:
> 
> "String representations of timedelta objects are normalized similarly to 
> their internal representation. This leads to somewhat unusual results for 
> negative timedeltas."

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

[toc] | [prev] | [next] | [standalone]

#69231

Roy Smith <roy@panix.com> writes:

> In article <5334b747$0$29994$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
> > On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote:
> > > Give ma a real-life situation where you would want such behavior
> > > [the ‘datetime.timedelta.__str__’ method returning a string
> > > showing some portions negative and others positive].
> > 
> > Easy -- I'm debugging timedelta routines, and I want to easily see
> > that the timedeltas calculated match what I expect them to be when I
> > print them. The quickest, easiest and simplest way is for
> > str(timedelta) to follow the internal representation.
>
> That's what __repr__() is for.

Indeed, that is why Python's data model defines separate ‘__str__’ and
‘__repr__’ methods.

    object.__repr__(self)

    […] If at all possible, this should look like a valid Python
    expression that could be used to recreate an object with the same
    value (given an appropriate environment). If this is not possible, a
    string of the form <...some useful description...> should be
    returned.

    <URL:http://docs.python.org/3/reference/datamodel.html#object.__repr__>

    object.__str__(self)

    […] compute the “informal” or nicely printable string representation
    of an object. […] a more convenient or concise representation can be
    used.

    <URL:http://docs.python.org/3/reference/datamodel.html#object.__str__>

If you're a programmer wanting to know about the internal representation
of an object, call its ‘__repr__’ method (by calling ‘repr(foo)’).

If you're wanting to see a string representation that follows the
*semantics* of the object, call its ‘__str__’ method (by calling
‘str(foo)’).

If the ‘__str__’ method follows the internal representation at the
expense of the user's conceptual model, that's terrible (which I think
is what Roy means by “braindead”).

I wouldn't go as far as that insult, because it could be mere omission:

    The default implementation [of ‘__str__’] defined by the built-in
    type object calls object.__repr__().

So, where ‘str(foo)’ is returning an unhelpful representation that
follows the implementation, it could simply be that there is no
‘__str__’ defined for that type.

> > Oh look, that's exactly what the docs say:
> > 
> > "String representations of timedelta objects are normalized
> > similarly to their internal representation. This leads to somewhat
> > unusual results for negative timedeltas."
>
> Yes, I know that's what the docs say.  That's why it's not an 
> implementation bug.  It's a design bug :-)

One which to some extent violates the defined data model for Python
objects, and hence should be fixed.

-- 
 \      “I don't know half of you half as well as I should like, and I |
  `\   like less than half of you half as well as you deserve.” —Bilbo |
_o__)                                                          Baggins |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#69261

On Thu, 27 Mar 2014 20:29:17 -0400, Roy Smith wrote:

> In article <5334b747$0$29994$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
>> On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote:
>> 
>> > In article <mailman.8613.1395917059.18130.python-list@python.org>,
>> >  Chris Angelico <rosuav@gmail.com> wrote:
>> >> It's not "equally braindead", it follows a simple and logical rule:
>> >> Only the day portion is negative.
>> > 
>> > Simple and logical, yes.  But also entirely braindead.
>> 
>> Do you think it is "braindead" for __str__ to return something which
>> follows the internal representation of the object?
> 
> 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.)


>> > Give ma a real-life situation where you would want such behavior.
>> 
>> Easy -- I'm debugging timedelta routines, and I want to easily see that
>> the timedeltas calculated match what I expect them to be when I print
>> them. The quickest, easiest and simplest way is for str(timedelta) to
>> follow the internal representation.
> 
> 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


>> Oh look, that's exactly what the docs say:
>> 
>> "String representations of timedelta objects are normalized similarly
>> to their internal representation. This leads to somewhat unusual
>> results for negative timedeltas."
> 
> 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.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#69266

In article <533558fa$0$29994$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> > 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*

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.

[toc] | [prev] | [next] | [standalone]

#69269

Roy Smith <roy@panix.com>:

> 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

[toc] | [prev] | [next] | [standalone]

#69270

On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#69272

In article <mailman.8667.1396012782.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> > 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

The real question is, what does this print:

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

[toc] | [prev] | [next] | [standalone]

#69274

On Friday, March 28, 2014 6:52:15 PM UTC+5:30, Roy Smith wrote:
>  Chris Angelico wrote:

> > On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa wrote:
> > > 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

> 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!

[toc] | [prev] | [next] | [standalone]

#69275

On Sat, Mar 29, 2014 at 12:22 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.8667.1396012782.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Sat, Mar 29, 2014 at 12:10 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> > 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
>
> 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

[toc] | [prev] | [next] | [standalone]

#69271

In article <871txmwjt4.fsf@elektro.pacujo.net>,
 Marko Rauhamaa <marko@pacujo.net> wrote:

> 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.

[toc] | [prev] | [next] | [standalone]

#69278

Roy Smith <roy@panix.com>:

> 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

[toc] | [prev] | [next] | [standalone]

#69279

On Fri, 28 Mar 2014 08:30:11 -0400, Roy Smith wrote:

> In article <533558fa$0$29994$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
>> > 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*
> 
> I'm not sure how "decoupling internal representation from external
> behavior" is substantially different from encapsulation.

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_%28object-oriented_programming%29


> 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.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#69281

On Sat, Mar 29, 2014 at 1:35 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#69155

On 03/26/2014 04:25 PM, Dennis Lee Bieber wrote:
> On Tue, 25 Mar 2014 20:58:27 -0400, Roy Smith <roy@panix.com> declaimed the
> following:
>
>> One of my roles on this newsgroup is to periodically whine about
>> stupidities in the Python datetime module.  This is one of those times.
>>
>> I have some code which computes how long ago the sun set.  Being a nice
>> pythonista, I'm using a timedelta to represent this value.  It would be
>> difficult to imagine a less useful default way to print a timedelta:
>>
>> previous sunset: -1 day, 22:25:26.295993
>>
>> The idea of str() is that it's supposed to return a human-friendly
>> representation of a value.  Humans do not say things like, "The sun set
>> 1 day ago plus 22 hours and 25 minutes".
>
> 	Makes sense to me -- the key being time DELTA... IE, a difference from
> some (unspecified) instance in time...
>
> 	If you want an instance of time, you need to add some known instance
> and the delta value.

Making sense is not the same as user friendly...

   "Hey, when did Bob get here?"

   "About 15 minutes ago."

vs

   "About an hour ago, plus 45 minutes."

--
~Ethan~

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web