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

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

PyWarts: time, datetime, and calendar modules

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

Contents

  PyWarts: time, datetime, and calendar modules Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-14 10:54 -0800
    Re: PyWarts: time, datetime, and calendar modules Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-01-14 14:01 -0500
      Re: PyWarts: time, datetime, and calendar modules Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-14 11:23 -0800
        Re: PyWarts: time, datetime, and calendar modules Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-01-14 15:11 -0500
        Re: PyWarts: time, datetime, and calendar modules Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-14 13:31 -0800
        Re: PyWarts: time, datetime, and calendar modules Chris Angelico <rosuav@gmail.com> - 2012-01-15 08:56 +1100
        Re: PyWarts: time, datetime, and calendar modules Evan Driscoll <edriscoll@wisc.edu> - 2012-01-14 14:58 -0600
          Re: PyWarts: time, datetime, and calendar modules Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-14 15:19 -0800
            Re: PyWarts: time, datetime, and calendar modules Chris Angelico <rosuav@gmail.com> - 2012-01-15 11:42 +1100
          Re: PyWarts: time, datetime, and calendar modules Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-15 04:26 +0000
        Re: PyWarts: time, datetime, and calendar modules Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-15 04:23 +0000
          Re: PyWarts: time, datetime, and calendar modules Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-14 21:27 -0800
            Re: PyWarts: time, datetime, and calendar modules Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-15 07:00 +0000
            Re: PyWarts: time, datetime, and calendar modules Michael Torrie <torriem@gmail.com> - 2012-01-15 19:50 -0700
        Re: PyWarts: time, datetime, and calendar modules Lie Ryan <lie.1296@gmail.com> - 2012-01-16 02:13 +1100
    Re: PyWarts: time, datetime, and calendar modules Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-15 03:53 +0000

#18974 — PyWarts: time, datetime, and calendar modules

The interface for these modules is not intuitive. Instead of creating
true OOP objects we have lists and strings. Any calendar object should
expose string names of both: days of the week and months of the year.
It seems one (or possibly more) of the three expose this important
info however i cannot find it *easily* enough.

It seems we need to combine the three in some shape or form. time and
datetime would no doubt be great bedfellows. Or maybe datetime should
be attached to time, like os.path. In any event the interfaces are
horrendous.

[toc] | [next] | [standalone]

#18975

On Sat, Jan 14, 2012 at 1:54 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> The interface for these modules is not intuitive. Instead of creating
> true OOP objects we have lists and strings. Any calendar object should
> expose string names of both: days of the week and months of the year.
> It seems one (or possibly more) of the three expose this important
> info however i cannot find it *easily* enough.
>
> It seems we need to combine the three in some shape or form. time and
> datetime would no doubt be great bedfellows. Or maybe datetime should
> be attached to time, like os.path. In any event the interfaces are
> horrendous.


What's "horrendous" about the datetime module interface? Your listed
complaints (OOP etc.) don't seem to have anything to do with it.

-- Devin

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

#18977

On Jan 14, 1:01 pm, Devin Jeanpierre <jeanpierr...@gmail.com> wrote:

> What's "horrendous" about the datetime module interface? Your listed
> complaints (OOP etc.) don't seem to have anything to do with it.

Well my immediate complaint about date-time is actually a problem with
the syntactic quandaries of the Python language itself.

I find myself navigating an objects API using the dir function or the
autocomplete function of my IDE. Now. One the continuing issues of the
Python's syntax (and the syntax of many other languages) is the fact
that a reader has no idea which names belonging to an object are
methods and which names are instance/class variables. The status quo
has been to use verbs for methods but you cannot always find the
perfect verb, or even sometimes, anyverb! Consider this:

>>> import datetime, time, calendar
>>> d = datetime.date.today()
>>> d.day
14
>>> d.month
1
>>> d.year
2012
>>> d.weekday
<built-in method weekday of datetime.date object at 0x026A5A58>

THAT PISSES ME OFF!!! >:( We should never be forced to guess if a name
is a callable or a variable!

So how do we solve this dilemma you ask??? Well, we need to "mark"
method OR variable names (OR both!) with syntactic markers so there
will be NO confusion.

Observe:
  def $method(self):pass
  self.@instanceveriable
  self.@@classvariable

I dunno if these are the best markers but the "marker" must be
succinct! Of course if we choose to use the "@" and "@@" then we might
as well drop the redundant "self" and allow the compiler to parse out
the difference.

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

#18978

On Sat, Jan 14, 2012 at 2:23 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> THAT PISSES ME OFF!!! >:( We should never be forced to guess if a name
> is a callable or a variable!
>
> So how do we solve this dilemma you ask??? Well, we need to "mark"
> method OR variable names (OR both!) with syntactic markers so there
> will be NO confusion.

I might be being bit OT, but, you should give Common Lisp a try. It
does something similar for functions versus variables.

As for the issue, I suppose I can see how this would be confusing. I
don't agree with your solution, though. I happen to like the
interchangeability of the different sorts of attributes, so that
x.foo() can be a method call, a classmethod call, or a call on a
function that is an attribute.

-- Devin

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

#18980

On Jan 14, 1:23 pm, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
>   def $method(self):pass
>   self.@instanceveriable
>   self.@@classvariable

Actually, class level methods can be accessed through
ClassIdentifier.method, and instance methods through
instanceidentifier.instancemethod. So decorating methods becomes
moot.

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

#18981

On Sun, Jan 15, 2012 at 6:23 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Observe:
>  def $method(self):pass
>  self.@instanceveriable
>  self.@@classvariable

Are you deliberately inverting what PHP does, with $variablename?
(Incidentally, that's one of the things that irks me about PHP -
adorned variable names.)

In any case: Python does not distinguish between functions and other
sorts of objects. It makes no sense to adorn things in this way.

ChrisA

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

#18982

On 01/14/2012 02:11 PM, Devin Jeanpierre wrote:
> On Sat, Jan 14, 2012 at 2:23 PM, Rick Johnson
> <rantingrickjohnson@gmail.com>  wrote:
>> THAT PISSES ME OFF!!!>:( We should never be forced to guess if a name
>> is a callable or a variable!
>>
>> So how do we solve this dilemma you ask??? Well, we need to "mark"
>> method OR variable names (OR both!) with syntactic markers so there
>> will be NO confusion.
>
> I might be being bit OT, but, you should give Common Lisp a try. It
> does something similar for functions versus variables.
>
> As for the issue, I suppose I can see how this would be confusing. I
> don't agree with your solution, though.

It also has some problems. For instance, if an object has a member which 
is a type that implements __call__ but is also useful to access "on its 
own", is that a field or a function?

Personally, I'd suggest the thing to "fix" to solve your confusion would 
be how things like your code completion and dir() display the results, 
not anything fundamental about the language. (And also the datetime 
API.) PyDev, for instance, tries to show you what "kind" of thing each 
entry in its completion menu are.

Evan

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

#18984

On Jan 14, 2:58 pm, Evan Driscoll <edrisc...@wisc.edu> wrote:
> On 01/14/2012 02:11 PM, Devin Jeanpierre wrote:

> It also has some problems. For instance, if an object has a member which
> is a type that implements __call__ but is also useful to access "on its
> own", is that a field or a function?

Can you site a real world example that would prove your point?

> Personally, I'd suggest the thing to "fix" to solve your confusion would
> be how things like your code completion and dir() display the results,

I must admit this would be the low cost solution, although, i have
always been irked by the obfuscation of programming language syntax. I
don't need the manual anymore. I just need some introspection tools.
HOWEVER, even the best introspection tools in the world cannot make up
for obfuscation.

Consider the case of the obfuscation of sex by certain "gender
neutral" names. males and females frequent usenet and forums around
the net, and in most cases we know that a "Tom", "Dick", and "Harry"
are going be males, and that "June", "April", and "May" are going to
be females. But what about "August", "Jamie", "Payton", or
"Parker"? ...and don't forget about that boy named Sue!

In face to face communication we will know (most times) who is male,
who is female, and who is other. But when all we have to go by is a
simple name, well, that name MUST be descriptive. It must carry some
hint as to sex. "Hello Mr, urrr Mrs., urrr Payton" EGG ON FACE!

Same in programming. We need syntactical clues. When we are removed
from the visual, and have no proper syntactic clues, we are then
forced to guess! -- and nobody wants to be accused of being the
opposite sex!

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

#18987

On Sun, Jan 15, 2012 at 10:19 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Jan 14, 2:58 pm, Evan Driscoll <edrisc...@wisc.edu> wrote:
>> On 01/14/2012 02:11 PM, Devin Jeanpierre wrote:
>
>> It also has some problems. For instance, if an object has a member which
>> is a type that implements __call__ but is also useful to access "on its
>> own", is that a field or a function?
>
> Can you site a real world example that would prove your point?

Not without breaking a non-disclosure agreement and copyright.

ChrisA

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

#18995

On Sat, 14 Jan 2012 14:58:26 -0600, Evan Driscoll wrote:

> On 01/14/2012 02:11 PM, Devin Jeanpierre wrote:
>> On Sat, Jan 14, 2012 at 2:23 PM, Rick Johnson
>> <rantingrickjohnson@gmail.com>  wrote:
>>> THAT PISSES ME OFF!!!>:( We should never be forced to guess if a name
>>> is a callable or a variable!
>>>
>>> So how do we solve this dilemma you ask??? Well, we need to "mark"
>>> method OR variable names (OR both!) with syntactic markers so there
>>> will be NO confusion.
>>
>> I might be being bit OT, but, you should give Common Lisp a try. It
>> does something similar for functions versus variables.
>>
>> As for the issue, I suppose I can see how this would be confusing. I
>> don't agree with your solution, though.
> 
> It also has some problems. For instance, if an object has a member which
> is a type that implements __call__ but is also useful to access "on its
> own", is that a field or a function?

This is the problem with Ruby's syntax for calling functions with no 
argument with brackets. Since f on its own is interpreted as "call f with 
no arguments", there is no easy way to get a reference to the object f. 
This makes functions second-class objects in Ruby, since you can't refer 
to them easily by name like you can other objects.


-- 
Steven

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

#18994

On Sat, 14 Jan 2012 11:23:29 -0800, Rick Johnson wrote:

> On Jan 14, 1:01 pm, Devin Jeanpierre <jeanpierr...@gmail.com> wrote:
> 
>> What's "horrendous" about the datetime module interface? Your listed
>> complaints (OOP etc.) don't seem to have anything to do with it.
> 
> Well my immediate complaint about date-time is actually a problem with
> the syntactic quandaries of the Python language itself.
> 
> I find myself navigating an objects API using the dir function or the
> autocomplete function of my IDE. Now. One the continuing issues of the
> Python's syntax (and the syntax of many other languages) is the fact
> that a reader has no idea which names belonging to an object are methods
> and which names are instance/class variables. 

This is not Java, and we prefer Python terminology.

A variable holding an int is an int variable.
A variable holding a string is a string variable.
A variable holding a list is a list variable.
A variable holding an instance is an instance variable.
A variable holding a class is a class variable.

Clarity of language is your friend. Perhaps you mean instance and class 
ATTRIBUTES, since dotted names are attributes, not variables.

x # x is a variable
x.y  # y is an attribute of x

Methods ARE attributes. You are asking for a distinction which does not 
exist. This is Python, not Java, and methods are attributes which happen 
to be callable. (Actually, to be technical they are attributes which use 
the descriptor protocol to return a callable.) In some other languages, 
methods (and functions and classes) are second-class entities created at 
compile time. In Python, they are first-class objects created at runtime 
like all other objects. Distinguishing methods from other attributes by 
syntax alone is ugly and artificial.


> The status quo has been to
> use verbs for methods but you cannot always find the perfect verb, or
> even sometimes, anyverb! Consider this:
> 
>>>> import datetime, time, calendar
>>>> d = datetime.date.today()
>>>> d.day
> 14
>>>> d.month
> 1
>>>> d.year
> 2012
>>>> d.weekday
> <built-in method weekday of datetime.date object at 0x026A5A58>
> 
> THAT PISSES ME OFF!!! >:( We should never be forced to guess if a name
> is a callable or a variable!

Guessing is for fourth-class programmers who don't know their language 
and are too lazy to RTFM.

py> import datetime
py> d = datetime.date.today()
py> hasattr(d.weekday, '__call__')
True

help(d) is also your friend.


> So how do we solve this dilemma you ask??? Well, we need to "mark"
> method OR variable names (OR both!) with syntactic markers so there will
> be NO confusion.

No we don't. There is no dilemma.

At worst, we might agree that the datetime API is old and tired, and that 
if descriptors existed back in Python 1.x then datetime.weekday could 
have been a computed property instead of a method, but alas we've lost 
the opportunity for this. Any changes to datetime need to be backward 
compatible.

If you want to actually do something useful, instead of just big-noting 
yourself and trolling about how bad Python is because it doesn't work 
like the language you have in your head, I suggest you write a datetime 
wrapper class and offer it to the community via PyPI. If it is good, and 
becomes popular, then in Python 3.4 or 3.5 it may become part of the 
standard library.


-- 
Steven

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

#18997

On Jan 14, 10:23 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:

> This is not Java, and we prefer Python terminology.
>
> A variable holding an int is an int variable.
> A variable holding a string is a string variable.
> A variable holding a list is a list variable.
> A variable holding an instance is an instance variable.
> A variable holding a class is a class variable.

You went to a lot of trouble to prove nothing. Here allow me to
retort:

A box holding an apple is an apple box.
A box holding a pear is a pear box.
A box holding an orange is a orange box.
A box holding an banana is an banana box.
And a box that penis comes in is a vagina!

> Guessing is for fourth-class programmers who don't know their language
> and are too lazy to RTFM.

Oh really. I don't know about you Steven but i am not JUST a Python
programmer. I write tons of code with Python but i also write tons of
code in many other languages too. Not only am i emerged in many
aspects of the IT world, i have a WIDE scope of knowledge in many
other fields and disciplines; all of which is ongoing because let's
face it, the minute you _think_ you know everything is the second you
become obsolete. But i digress...  Making claims that obfuscated
syntax and insufficient APIs are *somehow* the programmers fault,
because he (or she!) does not have EVERY *SINGLE* corner of the Python
library memorized, is quite preposterous.

> At worst, we might agree that the datetime API is old and tired, and that
> if descriptors existed back in Python 1.x then datetime.weekday could
> have been a computed property instead of a method, but alas we've lost
> the opportunity for this. Any changes to datetime need to be backward
> compatible.

Why? "print()" is not backward compatible? Face it, Guido has broken
Python's cherry. She is no longer pure. You're acting like some over-
protective father. WAKE UP! Python is a promiscuous little whore and
she's on girls gone wild (Volume 4000) shaking her little money maker.
We should at least profit from the immorality.

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

#18998

On Sat, 14 Jan 2012 21:27:32 -0800, Rick Johnson wrote:

> On Jan 14, 10:23 pm, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
> 
>> This is not Java, and we prefer Python terminology.
>>
>> A variable holding an int is an int variable. A variable holding a
>> string is a string variable. A variable holding a list is a list
>> variable. A variable holding an instance is an instance variable. A
>> variable holding a class is a class variable.
> 
> You went to a lot of trouble to prove nothing. Here allow me to retort:
> 
> A box holding an apple is an apple box. A box holding a pear is a pear
> box.
> A box holding an orange is a orange box. A box holding an banana is an
> banana box. And a box that penis comes in is a vagina!

Penises aren't supplied in boxes. About 50% of the population already has 
one, the other 50% can get as many as they want.


>> Guessing is for fourth-class programmers who don't know their language
>> and are too lazy to RTFM.
> 
> Oh really. I don't know about you Steven but i am not JUST a Python
> programmer. I write tons of code with Python but i also write tons of
> code in many other languages too.

Why don't you approach those other languages and demand that they change 
to match Python's model then? See how well that goes over.


>> At worst, we might agree that the datetime API is old and tired, and
>> that if descriptors existed back in Python 1.x then datetime.weekday
>> could have been a computed property instead of a method, but alas we've
>> lost the opportunity for this. Any changes to datetime need to be
>> backward compatible.
> 
> Why? "print()" is not backward compatible? 

You missed your opportunity by two versions. The time to have made the 
change was before Python 3.0 came out. We're now up to 3.2 and 3.3 is 
under development. The opportunity for breaking backward compatibility 
was 3-4 years ago. Now we're back to the normal paradigm of caring about 
backward compatibility.  


> Face it, Guido has broken Python's cherry. She is no longer pure.

You need to get yourself a girlfriend. Or at least a subscription to 
Playboy.



-- 
Steven

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

#19026

On 01/14/2012 10:27 PM, Rick Johnson wrote:
> Face it, Guido has broken Python's cherry. She is no longer pure.
> You're acting like some over- protective father. WAKE UP! Python is a
> promiscuous little whore and she's on girls gone wild (Volume 4000)
> shaking her little money maker. We should at least profit from the
> immorality.

Hmm, down goes all the credibility you had since your rebirth on this
list.  Back to the old ways.

That said, Rick I think it's time for you to fork python.  Your
brilliance and foresight put Guido's to shame.  No one else has the guts
to stand up and say what needs to be said.  If you can't fix python, no
one can.

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

#19008

On 01/15/2012 06:23 AM, Rick Johnson wrote:
> So how do we solve this dilemma you ask??? Well, we need to "mark"
> method OR variable names (OR both!) with syntactic markers so there
> will be NO confusion.
>
> Observe:
>    def $method(self):pass
>    self.@instanceveriable
>    self.@@classvariable

There is no need for a language-level support for Hungarian notation.

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

#18992

On Sat, 14 Jan 2012 10:54:57 -0800, Rick Johnson wrote:

> The interface for these modules is not intuitive. Instead of creating
> true OOP objects we have lists and strings.

Lists and strings are true OOP objects.


-- 
Steven

[toc] | [prev] | [standalone]

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

csiph-web