On 2/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> That's what rankles people about this, I think -- there
> doesn't seem to be a good reason for treating the global
> scope so specially, given that all scopes could be
> treated uniformly if only there were an 'outer' statement.
> All the argument
On 2/24/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> > The more practical complaint is that list comprehensions use the same
> > namespace as the block that contains them.
> > ... but I suspect we're stuck with the
> > current behavior for backwards compatibility reasons.
>
>
Jeremy Hylton wrote:
> The more practical complaint is that list comprehensions use the same
> namespace as the block that contains them.
> ... but I suspect we're stuck with the
> current behavior for backwards compatibility reasons.
There will be no backwards compatibility in 3.0,
so perhaps
On 2/24/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Feb 24, 2006, at 1:54 AM, Greg Ewing wrote:
> > Thomas Wouters wrote:
> >> On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
> >>
> >>> As an aside, is there any chance that this could be
> >>> changed in 3.0? I.e. have the for-lo
On Feb 24, 2006, at 1:54 AM, Greg Ewing wrote:
> Thomas Wouters wrote:
>> On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
>>
>>> As an aside, is there any chance that this could be
>>> changed in 3.0? I.e. have the for-loop create a new
>>> binding for the loop variable on each iteratio
Thomas Wouters wrote:
> On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
>
>>As an aside, is there any chance that this could be
>>changed in 3.0? I.e. have the for-loop create a new
>>binding for the loop variable on each iteration.
>
> You can't do that without introducing a whole new
On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
> Samuele Pedroni wrote:
>
> > If you are looking for rough edges about nested scopes in Python
> > this is probably worse:
> >
> > >>> x = []
> > >>> for i in range(10):
> > ... x.append(lambda : i)
> > ...
> > >>> [y() for y in x]
Almann T. Goo wrote:
> (although rebinding a name in the global scope from a
> local scope is really just a specific case of that).
That's what rankles people about this, I think -- there
doesn't seem to be a good reason for treating the global
scope so specially, given that all scopes could be
Samuele Pedroni wrote:
> If you are looking for rough edges about nested scopes in Python
> this is probably worse:
>
> >>> x = []
> >>> for i in range(10):
> ... x.append(lambda : i)
> ...
> >>> [y() for y in x]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
As an aside, is there any chance that this co
On 22-Feb-06, at 9:28 PM, [EMAIL PROTECTED] wrote:On 21-Feb-06, at 11:21 AM, Almann T. Goo" <[EMAIL PROTECTED]> wrote:Why not just use a class?def incgen(start=0, inc=1) : class incrementer(object): a = start - inc def __call__(self): self.a += inc return self.a retu
> Oddly, in Python, 'global' isn't actually necessary,
> since the module can always import itself and use
> attribute access.
>
> Clearly, though, Guido must have thought at the time
> that it was worth providing an alternative way.
I believe that use cases for rebinding globals (module attribute
Josiah Carlson wrote:
> However, I believe global was and is necessary for the
> same reasons for globals in any other language.
Oddly, in Python, 'global' isn't actually necessary,
since the module can always import itself and use
attribute access.
Clearly, though, Guido must have thought at the
On 21-Feb-06, at 11:21 AM, Almann T. Goo" <[EMAIL PROTECTED]> wrote:Why not just use a class?def incgen(start=0, inc=1) : class incrementer(object): a = start - inc def __call__(self): self.a += inc return self.a return incrementer()a = incgen(7, 5)for n in range(10)
Greg Ewing wrote:
> Jeremy Hylton wrote:
>
>
>>The names of naming statements are quite hard to get right, I fear.
>
>
> My vote goes for 'outer'.
>
> And if this gets accepted, remove 'global' in 3.0.
>
In 3.0 we could remove 'global' even without 'outer',
and make module global scopes read
Almann T. Goo wrote:
>>As far as I remember, Guido wasn't particularly opposed
>>to the idea, but the discussion fizzled out after having
>>failed to reach a consensus on an obviously right way
>>to go about it.
>
>
> My apologies for bringing this debated topic again to the
> front-lines--that s
"Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> IMO, Having properly nested scopes in Python in a sense made 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 i
At 06:14 AM 2/22/2006 -0500, Jeremy Hylton wrote:
>On 2/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Mark Russell wrote:
> >
> > > PEP 227 mentions using := as a rebinding operator, but rejects the
> > > idea as it would encourage the use of closures.
> >
> > Well, anything that facilitates reb
On 2/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Mark Russell wrote:
>
> > PEP 227 mentions using := as a rebinding operator, but rejects the
> > idea as it would encourage the use of closures.
>
> Well, anything that facilitates rebinding in outer scopes
> is going to encourage the use of closu
Josiah Carlson wrote:
> In this particular example, there is no net reduction in line use. The
> execution speed of your algorithm would be reduced due to function
> calling overhead.
If there were more uses of the function, the line count
reduction would be greater.
In any case, line count and
> As far as I remember, Guido wasn't particularly opposed
> to the idea, but the discussion fizzled out after having
> failed to reach a consensus on an obviously right way
> to go about it.
My apologies for bringing this debated topic again to the
front-lines--that said, I think there has been go
Just van Rossum wrote:
> Btw, PJE's "crazy" idea (.name, to rebind an outer name) was proposed
> before, but Guido wanted to reserve .name for a (Pascal-like) 'with'
> statement. Hmm,
I guess that doesn't apply any more, since we've already
used "with" for something else.
Regardless, names with
Mark Russell wrote:
> PEP 227 mentions using := as a rebinding operator, but rejects the
> idea as it would encourage the use of closures.
Well, anything that facilitates rebinding in outer scopes
is going to encourage the use of closures, so I can't
see that as being a reason to reject a parti
Terry Reedy wrote:
> There were perhaps 10
> different proposals, including, I believe, 'outer'. Guido rejected them
> all as having costs greater than the benefits.
As far as I remember, Guido wasn't particularly opposed
to the idea, but the discussion fizzled out after having
failed to reach
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
>
> On 2/21/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > The question which still remains in my mind, which I previously asked,
> > is whether the use cases are compelling enough to warrant the feature
> > addition.
>
> I don't know whether I supp
Jeremy Hylton wrote:
> On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
>
>>On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
>
>>>But to the topic, it just occurred to me that any outer scopes could be
>>>given names
>>>(including global namespace, but that would have the name global by
Georg Brandl wrote:
> But why is that better than
>
> class namespace(object): pass
>
> def my_func():
> foo = namespace()
> (...)
Because then it would be extremely difficult for CPython to
optimise accesses to foo into local variable lookups.
--
Greg Ewing, Computer Science Dept, +-
Jeremy Hylton wrote:
> The names of naming statements are quite hard to get right, I fear.
My vote goes for 'outer'.
And if this gets accepted, remove 'global' in 3.0.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post
On 21 Feb 2006, at 21:13, Ian Bicking wrote:
> By rebinding operator, does that mean it is actually an operator?
> I.e.:
>
># Required assignment to declare?:
>chunk = None
>while chunk := f.read(1000):
>...
No, I think that "x := y" should be a statement not an expression
"Jeremy Hylton" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> If I recall the discussion correctly, Guido said he was open to a
> version of nested scopes that allowed rebinding.
Yes. Among other places, he said in
http://article.gmane.org/gmane.comp.python.devel/25153/match=ne
On 2/21/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> The question which still remains in my mind, which I previously asked,
> is whether the use cases are compelling enough to warrant the feature
> addition.
I don't know whether I support the proposal or not, but in reading
Mark Russel's email,
Mark Russell wrote:
> On 21 Feb 2006, at 19:25, Jeremy Hylton wrote:
>
>>If I recall the discussion correctly, Guido said he was open to a
>>version of nested scopes that allowed rebinding.
>
>
> PEP 227 mentions using := as a rebinding operator, but rejects the
> idea as it would encourage th
Mark Russell wrote:
> PEP 227 mentions using := as a rebinding operator, but rejects the
> idea as it would encourage the use of closures. But to me it seems
> more elegant than some special keyword, especially is it could also
> replace the "global" keyword. It doesn't handle things like
On 21 Feb 2006, at 19:25, Jeremy Hylton wrote:
> If I recall the discussion correctly, Guido said he was open to a
> version of nested scopes that allowed rebinding.
PEP 227 mentions using := as a rebinding operator, but rejects the
idea as it would encourage the use of closures. But to me it s
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > Mechanisms which rely on manipulating variables within closures or
> > nested scopes to function properly can be elegant, but I've not yet seen
> > one that *really* is.
>
> It seems a bit inconsistent to say on the one hand
On 2/21/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > I certainly hope that an initiative like this doesn't get stymied by
> > the lack of a good name for such a keyword. Maybe something like
> > "outer"?
>
> Addi
"Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I certainly hope that an initiative like this doesn't get stymied by
> the lack of a good name for such a keyword. Maybe something like
> "outer"?
Adding a keyword has a cost that you have so far ignored. Guido is
Almann T. Goo <[EMAIL PROTECTED]> wrote:
>> 1. Adding a keyword such as "use" that would follow similar semantics as
"
>> global" does today. A nested scope could declare names with this keyword
>> to enable assignment to such names to change the closest parent's
binding.
+0, and I like "outer"
> Why not just use a class?
>
>
> def incgen(start=0, inc=1) :
> class incrementer(object):
> a = start - inc
> def __call__(self):
> self.a += inc
> return self.a
> return incrementer()
>
> a = incgen(7, 5)
> for n in range(10):
> print a(),
Because I thi
Greg Ewing wrote:
>def my_func():
> namespace foo
> foo.x = 42
>
> def inc_x():
>foo.x += 1
>
> The idea here is that foo wouldn't be an object in
> its own right, but just a collection of names that
> would be implemented as local variables of my_func.
But why is tha
Jeremy Hylton wrote:
> On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
>> I had to lookup top-post :-).
>>
>> On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
>>> On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]>
>>> wrote:
Jeremy
>>> Hey, only Guido is allowed
> But to the topic, it just occurred to me that any outer scopes could be given
> names
> (including global namespace, but that would have the name global by default,
> so
> global.x would essentially mean what globals()['x'] means now, except it would
> be a name error if x didn't pre-exist when
On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> I had to lookup top-post :-).
>
> On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> > On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]>
> > wrote:
> > >Jeremy
> > Hey, only Guido is allowed to top-post. He said so ;-
I had to lookup top-post :-).
On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]> wrote:
> >Jeremy
> Hey, only Guido is allowed to top-post. He said so ;-)
The Gmail UI makes it really easy to forget where the q
> But to
On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]> wrote:
>Almann,
>
>The lack of support for rebinding names in enclosing scopes is
>certainly a wart. I think option one is a better fit for Python,
>because it more closely matches the existing naming semantics. Namely
>that
On Tue, Feb 21, 2006 at 08:02:08AM -0500, Jeremy Hylton wrote:
> The lack of support for rebinding names in enclosing scopes is
> certainly a wart. I think option one is a better fit for Python,
> because it more closely matches the existing naming semantics. Namely
> that assignment in a block
Jeremy,
I definitely agree that option one is more in line with the semantics
in place within Python today.
> The names of naming statements are quite hard to get right, I fear. I
> don't particularly like "use." It's too generic. (I don't
> particularly like "scope" for option 2, either, for
Almann,
The lack of support for rebinding names in enclosing scopes is
certainly a wart. I think option one is a better fit for Python,
because it more closely matches the existing naming semantics. Namely
that assignment in a block creates a new name unless a global
statement indicates otherwis
Josiah Carlson wrote:
> Mechanisms which rely on manipulating variables within closures or
> nested scopes to function properly can be elegant, but I've not yet seen
> one that *really* is.
It seems a bit inconsistent to say on the one hand
that direct assignment to a name in an outer scope
is no
"Almann T. Goo" <[EMAIL PROTECTED]> wrote:
> > Mechanisms which rely on manipulating variables within closures or
> > nested scopes to function properly can be elegant, but I've not yet seen
> > one that *really* is.
>
> This really isn't a case for or against what I'm proposing since we
> can al
> Mechanisms which rely on manipulating variables within closures or
> nested scopes to function properly can be elegant, but I've not yet seen
> one that *really* is.
This really isn't a case for or against what I'm proposing since we
can already do this in today's Python with mutable variables i
"Almann T. Goo" <[EMAIL PROTECTED]> wrote:
> I would 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.
-1
Mechanisms which rely on manipula
51 matches
Mail list logo
