PyWarts: time, datetime, and calendar modules

[Rick Johnson]

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.

 

[Devin Jeanpierre]

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

 

[Rick Johnson]

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:
<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)ass
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.

 

[Devin Jeanpierre]

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

 

[Evan Driscoll]

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

 

[Rick Johnson]

  def $method(self)ass
  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.

 

[Chris Angelico]

Observe:
 def $method(self)ass
 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

 

[Rick Johnson]

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!

 

[Chris Angelico]

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

Not without breaking a non-disclosure agreement and copyright.

ChrisA

 

[Steven D'Aprano]

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 D'Aprano]

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:

<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 D'Aprano]

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.

 

[Rick Johnson]

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.

 

[Steven D'Aprano]

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.

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.

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.

 

[Lie Ryan]

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)ass
self.@instanceveriable
self.@@classvariable

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