[Python-Dev] New syntax for 'dynamic' attribute access (original) (raw)
Sergio Correia sergio.correia at gmail.com
Tue Feb 13 02:03:15 CET 2007
- Previous message: [Python-Dev] Recent experience with the _ast module
- Next message: [Python-Dev] Weekly Python Patch/Bug Summary
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
A few of you have expressed concern about how would that look to a newbie. Being one, this is what I think:
(again, newbie alert)
The idea sounds good. Setattr and getattr seem kinda unpythonic and difficult to read.
please.(dont_torture) = me(with_dots,that_look,like.(function),calls). Ok, so the dot is needed in order to indicate that we are talking about objects. But if I see something like spam.(eggs) , I would feel tempted to delete the dot thinking it's a typo. Besides, the parenthesis make the dot even harder to read.
x->y feels like assignment. I even recall that in Mathematica it IS some kind of assignment. Besides, it lacks the dot that tells me "this is an object".
Square brackets have a lot of overloading but are not so bad.
Braces feel good. I think they are the best choice of the ones proposed. Because spam{eggs} doesn't mean anything, then there would be no confusion with a typo in spam.{eggs}
--Sergio
On 2/12/07, M.-A. Lemburg <mal at egenix.com> wrote:
On 2007-02-12 16:19, Georg Brandl wrote: >> Tim Delaney asked in particular: >>> Have you checked if [the existing uses of getattr, where "getattr" in >>> that scope is a function argument with default value the built-in >>> "getattr"] are intended to bring the "getattr" name into local scope >>> for fast lookup, or to force a binding to the builtin "gettattr" at >>> compile time (two common (ab)uses of default arguments)? If they are, >>> they would be better served by the new syntax. >> They're all in Lib/codecs.py, and are of the form: >> >> class StreamRecoder: >> def getattr(self, name, >> getattr=getattr): >> >> """ Inherit all other methods from the underlying stream. >> """ >> return getattr(self.stream, name) >> >> Without digging deeper into that code I'm afraid I can't say precisely >> what is going on. > > Since that is a special method and ought to have the signature > getattr(self, name), I think it's safe to assume that that's meant > as an optimization.
I can confirm that: it's a case of fast-local-lookup optimization. You can add a -1 from me to the list as well: I don't think that dynamic lookups are common enough to warrant new syntax. Even if you do add a new syntax for this, using parenthesis is a poor choice IMHO as the resulting code looks too much like a function call (e.g. "callable.(variable)"). Other choices would be square brackets [], but these have the same problem as they are in use for indexing. The only brackets that are not yet overloaded in the context of applying them to an object are curly brackets, so "callable.{variable}" would cause enough raising eyebrows to not think of a typo. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 12 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/sergio.correia%2Bpydev%40gmail.com
- Previous message: [Python-Dev] Recent experience with the _ast module
- Next message: [Python-Dev] Weekly Python Patch/Bug Summary
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]