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 <[EMAIL PROTECTED]> 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@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/sergio.correia%2Bpydev%40gmail.com
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
