A few of you have expressed concern about how would that look to a
newbie. Being one, this is what I think:
- The idea sounds good. Setattr and getattr seems both unpythonic and illegible.
- 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.
- Square brackets have enough overloading.
- 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}
As someone said before, the problem is that it would limit braces for
serving further purposes in the future. If the chances of requiring
using braces in the next few versions seem low to you, I would say go
for it.
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
