[Python-Dev] Set the namespace free!

Gregory P. Smith greg at krypto.org
Sat Jul 24 03:31:55 CEST 2010


On Thu, Jul 22, 2010 at 9:24 AM, <gregory.smith3 at sympatico.ca> wrote:

>  I agree with the idea, but a far less radical change is needed to get the
> desired result.
> The basic idea is this: it should be possible to use any name as an
> identifier in the syntax, including names
> like 'while' and 'import'. But there is no need to mess up the entire
> language to allow this
> (either by quoting all the identifiers, perl-style, or by marking the
> keywords).
>

Yuck.  Anyone who feels they need a variable named the same a reserved word
simply feels wrong and needs reeducation.  New words are introduced very
rarely and we do care about the ramifications when we do it.

What next?  An optional way to support case insensitive names using a
unicode character prefix?

-gps


>
> All that is needed is something like this:
>
> foo = 7
> :foo = 7   # exactly like foo=7
> :while= 3  # assigns 3 to variable 'while'
> globals()['while']=3  # current way to do this
>
> print element.:for  # from example below
> #
> # keyword parameters to a function call:
> #
> BuildUrlQuery( lang='en', item='monsoon', :class='normal')  # ->
> "?lang=en&query=monsoon&class=normal"
>
>
> The generic keyword function call is a really nice language feature, but
> it's rather impaired by the need to avoid
> those names which happen to be keywords.
>
> The lack of this is most painful when you are auto-generating python code
> which forms a bridge to another language with its own
> namespace (as in XML example). It's a pain when some of the names you might
> generate could conflict with python keywords.
> So, you end up using dicts and getattrs for everything and the code gets
> much less readable. With a simple escape like :name available,
> it's worthwhile to do everything with identifiers and generate the escape
> only as needed for these.
>
>
> One of the great strengths of python is the ability to form cleans and
> comprehensive bridges to other languages and environments (thus,
> in many cases, avoiding the need to write programs in those other
> environments :-) ). This feature would fill a gap there.
>
> The python tcl/tk interface is a bit messed up since tcl/tk uses some names
> for options which conflict with python keywords,
> and so you need to add '_' to those names.
>
> There is a feature like this in VHDL:  \name\ and \while\ are identifiers,
> the backslashes are not part of the name, but just
> quote it. In  VHDL you can write identifiers like  \22\, and
> \!This?is=Strange\ as well; since VHDL creates modules that
> have named ports, and those modules can interface to things generated by
> other environments, they needed a
> way to assign any name to a port.
>
> For python, I'm not sure it makes sense to allow identifiers that doesn't
> follow the basic rule "[A-Za-z_][A-Za-z_0-9]*" -- that could
> break some debugging tools which expect variable names to be well-formed --
> but it would be useful
> to be able to use any well-formed name as an identifier, including those
> which happen to be keywords.
>
> I've suggested :name, which doesn't break old code, and doesn't require
> using any new punctuation. Syntax would not change,
> just the lexical definition of 'identifier'.  If the intent is to allow
> arbitrary names (not just well-formed ones), then n'name' would
> work better (and is consistent with existing stuff).
>
>
>
> > Date: Thu, 22 Jul 2010 10:41:39 -0400
> > From: jnoller at gmail.com
> > To: bartosz-tarnowski at zlotniki.pl
> > CC: python-dev at python.org
> > Subject: Re: [Python-Dev] Set the namespace free!
>
> >
> > On Thu, Jul 22, 2010 at 10:04 AM, Bartosz Tarnowski
> > <bartosz-tarnowski at zlotniki.pl> wrote:
> > >
> > > Hello, guys.
> > >
> > > Python has more and more reserved words over time. It becomes quite
> > > annoying, since you can not use variables and attributes of such names.
> > > Suppose I want to make an XML parser that reads a document and returns
> an
> > > object with attributes corresponding to XML element attributes:
> > >
> > >> elem = parse_xml("<element param='boo'/>")
> > >> print elem.param
> > > boo
> > >
> > > What should I do then, when the attribute is a reserver word? I could
> use
> > > trailing underscore, but this is quite ugly and introduces ambiguity.
> > >
> > >> elem = parse_xml("<element for='each'/>")
> > >> print elem.for_ #?????
> > >> elem = parse_xml("<element for_='each'/>")
> > >> print elem.for__ #?????
> > >
> > > My proposal: let's make a syntax change.
> > >
> > > Let all reserved words be preceded with some symbol, i.e. "!"
> (exclamation
> > > mark). This goes also for standard library global identifiers.
> > >
> > > !for boo in foo:
> > >    !if boo is !None:
> > >        !print(hoo)
> > >    !else:
> > >        !return !sorted(woo)
> > >
> > >
> > > This would allow the user to declare any identifier with any name:
> > >
> > > for = with(return) + try
> > >
> > > What do you think of it? It is a major change, but I think Python needs
> it.
> > >
> > > --
> > > haael
> > >
> >
> > I'm not a fan of this - I'd much prefer[1] that we use the exclamation
> > point to determine scope:
> >
> > foobar - local
> > !foobar - one up
> > !!foobar - higher than the last one
> > !!!foobar - even higher in scope
> >
> > We could do the inverse as well; if you append ! you can push variable
> > down in scope.
> >
> > Jesse
> >
> >
> > [1] I am not serious.
> > _______________________________________________
> > 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/gsmith%40alumni.uwaterloo.ca
>
> _______________________________________________
> 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/greg%40krypto.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100723/c687f423/attachment.html>


More information about the Python-Dev mailing list