Re: PyWarts: time, datetime, and calendar modules
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sat, Jan 14, 2012 at 1:54 PM, Rick Johnson rantingrickjohn...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sat, Jan 14, 2012 at 2:23 PM, Rick Johnson rantingrickjohn...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sun, Jan 15, 2012 at 6:23 AM, Rick Johnson rantingrickjohn...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On 01/14/2012 02:11 PM, Devin Jeanpierre wrote: On Sat, Jan 14, 2012 at 2:23 PM, Rick Johnson rantingrickjohn...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
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! -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
On Sun, Jan 15, 2012 at 10:19 AM, Rick Johnson rantingrickjohn...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
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 rantingrickjohn...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWarts: time, datetime, and calendar modules
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 -- http://mail.python.org/mailman/listinfo/python-list
