lobal meets all of these requirements. "free" was the word Iremember preferring from earlier discussions, but I think it fails #2. (Too much confusion about freeing memory, for example.)
I remember previous discussions also referring to spelling
d like the community's opinion if there is enough out there
that think this would be a worthwile endevour--or if there is already
an initiative that I missed. Please let me know your questions,
comments.
Best Regards,
Almann-- Almann T. Goo[EMAIL PROTECTED]
___
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
etting to the point where the programmer
> is trying to be too clever.
Even though I may agree with you on this, your argument is more of an
argument against PEP 227 than what I am proposing. Again, today's
Python already allows a developer to have deep nested scopes.
-Almann
--
Alma
tually like this, would sort of make "global" obsolete (and thus
making the global scope behave like other lexical scopes with regard
to to re-binding, which is probably a good thing)
-Almann
--
Almann T. Goo
[EMAIL PROTECTED]
___
Python-De
7
print n.a
I don't like how a child scope can access a free variable from an
enclosing scope without the namespace object, but needs to use it for
re-binding. Because of this, namespace objects have the potential to
obfuscate things more than fix the language issue that I am
address
g scope name rebinds are
not provided for by the language especially since the behavior with
the global scope is not so. In a nutshell I am proposing a solution
to make nested lexical scopes to be orthogonal with the global scope
and removing a "wart," as Jeremy put it, in the language.
-
having
closures a natural idiom to the language and part of its "user
interface." By not allowing the name re-binding it almost seems like
that "user interface" has a rough edge that is almost too easy to get
cut on. This in-elegance seems very un-Pythonic to me.
Anyhow, good
x27; key word to avoid
clumsier workarounds. Since there were no nested lexical scopes back
then, there was no need to have a construct for arbitrary enclosing
scopes.
-Almann
--
Almann T. Goo
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.
keeping the semantics cleaner--but that
would be incredibly backwards incompatible for what I would guess is
*a lot* of code. This is where the case for the re-bind operator
(i.e. ":=") or an "outer" type keyword is stronger--the semantics in
the language today are not a
er languages with this feature and
fix my orthogonality gripes. As far as backwards compatibility, I
doubt there would be too much impact in this regard, as places that
would break would be where "global" was used in a closure where the
name was shadowed in an enclosing scope. A "
with, I'd say that narrows things down to something
> well within the range of acceptable breakage in 3.0.
You read my mind--I made a reply similar to this on another branch of
this thread just minutes ago :).
I am curious to see what the community thinks about this.
-Almann
--
Almann T
On 2/23/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 2/22/06, Almann T. Goo <[EMAIL PROTECTED]> wrote:
> > def incrementer_getter(val):
> >def incrementer():
> >val = 5
> >def inc():
> >
en inconsistent with all other forms of
class and instance attribute access, which always use attribute
references. Code that used simple names would have been obscure.
I especially don't want to add an issue that is similar to one that
PEP 227 went out of its way to avoid.
e way by issuing a warning in these cases
when the new semantics are not being used (i.e. no "from __future__").
-Almann
--
Almann T. Goo
[EMAIL PROTECTED]
___
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
roposal that forces explicit name
spaces would have to allow for both accessing "simple names" (like
just "var") and names via attribute access (name spaces) like
"glob.var"--I think this adds the problem of introducing obscurity to
the language.
-Almann
--
Almann T.
hon 2.1--this is PEP 227
(http://www.python.org/peps/pep-0227.html). The proposal is for a
mechanism to allow for re-binding of enclosing scopes which seems like
a logical step to me. The rest of the scoping semantics would remain
as they are today in Python.
-Almann
--
g as there are workarounds (i.e. mutable objects) or other ways to express (
i.e. use classes) such things, but it does trip people up from time to time as warts typically do--I guess that's why this gets brought up now and again. Best regards,Almann-- Almann T. Goo
[EMAIL PROTECTED]
___
g if assignment is involved or is not involved). Of course, if the semantics were well defined such that it would be difficult for users to trap themselves with different spellings of local variables, then I would be +0 for it.
Best Regards,Almann-- Almann T. Goo[EMAIL PROTECTED]
_
18 matches
Mail list logo
