PyWarts: time, datetime, and calendar modules

[Steven D'Aprano]

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

> On Jan 14, 1:01 pm, Devin Jeanpierre <jeanpierr... at 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