2009/4/11 Chris Withers :
> Actually, this was gone on the py3k branch already.
>
> I've committed the fix to trunk, is there anything else I need to do?
Since it's not in py3k, I think not.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@
Chris Withers wrote:
Benjamin Peterson wrote:
Assuming it breaks no tests, would there be objection to me committing
the
above change to the Python 3 trunk?
That's up to Benjamin. Personally, I live by "if it ain't broke, don't
fix it." :-)
Anything using an exec is broken by definition ;-)
Steve Holden wrote:
Anything using an exec
that can be done in some other (more pythonic way)
There's *always* another way ;-)
is broken by definition ;-)
Benjamin?
We've just had a fairly clear demonstration that small semantic changes
to the language can leave unexpected areas borked.
Benjamin Peterson wrote:
Assuming it breaks no tests, would there be objection to me committing
the
above change to the Python 3 trunk?
That's up to Benjamin. Personally, I live by "if it ain't broke, don't
fix it." :-)
Anything using an exec is broken by definition ;-)
"practicality beats pu
Alexandre Vassalotti wrote:
> On Tue, Mar 31, 2009 at 11:25 PM, Guido van Rossum wrote:
>> Well hold on for a minute, I remember we used to have an exec
>> statement in a class body in the standard library, to define some file
>> methods in socket.py IIRC.
>
> FYI, collections.namedtuple is also
On Tue, Mar 31, 2009 at 11:25 PM, Guido van Rossum wrote:
> Well hold on for a minute, I remember we used to have an exec
> statement in a class body in the standard library, to define some file
> methods in socket.py IIRC.
FYI, collections.namedtuple is also implemented using exec.
- Alexandre
2009/4/3 Chris Withers :
> Guido van Rossum wrote:
But anyways this is moot, the bug was only about exec in a class body
*nested inside a function*.
>>>
>>> Indeed, I just hate seeing execs and it was an interesting mental
>>> exercise
>>> to try and get rid of the above one ;-)
>>>
Chris Withers wrote:
> Guido van Rossum wrote:
But anyways this is moot, the bug was only about exec in a class body
*nested inside a function*.
>>> Indeed, I just hate seeing execs and it was an interesting mental
>>> exercise
>>> to try and get rid of the above one ;-)
>>>
>>> Assuming
Guido van Rossum wrote:
But anyways this is moot, the bug was only about exec in a class body
*nested inside a function*.
Indeed, I just hate seeing execs and it was an interesting mental exercise
to try and get rid of the above one ;-)
Assuming it breaks no tests, would there be objection to m
On Thu, Apr 2, 2009 at 2:21 PM, Chris Withers wrote:
> Guido van Rossum wrote:
>>>
>>> from functools import partial
>>> from new import instancemethod
>>>
>>> def meth(name,self,*args):
>>> return getattr(self._sock,name)(*args)
>>>
>>> for _m in _socketmethods:
>>> p = partial(meth,_m)
>>>
Guido van Rossum wrote:
from functools import partial
from new import instancemethod
def meth(name,self,*args):
return getattr(self._sock,name)(*args)
for _m in _socketmethods:
p = partial(meth,_m)
p.__name__ = _m
p.__doc__ = getattr(_realsocket,_m).__doc__
m = instancemethod(p,N
On Thu, Apr 2, 2009 at 2:16 PM, Chris Withers wrote:
> R. David Murray wrote:
>>
>> On Wed, 1 Apr 2009 at 13:12, Chris Withers wrote:
>>>
>>> Guido van Rossum wrote:
Well hold on for a minute, I remember we used to have an exec
statement in a class body in the standard library, to
R. David Murray wrote:
On Wed, 1 Apr 2009 at 13:12, Chris Withers wrote:
Guido van Rossum wrote:
Well hold on for a minute, I remember we used to have an exec
statement in a class body in the standard library, to define some file
methods in socket.py IIRC.
But why an exec?! Surely there m
Eeek, I think it was me. Part of the AST changes involved raising a
SyntaxError when exec was used in a scope that had a free variable,
since the behavior is pretty much undefined. If the compiler decides
a variable is free, then it can't be assigned to in the function body.
The compiled exec co
I posted in the bug report, but repeating here: I don't remember why
exec in a nested function changed either. It would help if someone
could summarize why we made the change. (I hope I didn't do it <0.2
wink>.)
Jeremy
On Tue, Mar 31, 2009 at 11:36 PM, Maciej Fijalkowski wrote:
> Because clas
On Wed, 1 Apr 2009 at 13:12, Chris Withers wrote:
Guido van Rossum wrote:
Well hold on for a minute, I remember we used to have an exec
statement in a class body in the standard library, to define some file
methods in socket.py IIRC.
But why an exec?! Surely there must be some other way to
Guido van Rossum wrote:
Well hold on for a minute, I remember we used to have an exec
statement in a class body in the standard library, to define some file
methods in socket.py IIRC.
But why an exec?! Surely there must be some other way to do this than an
exec?
Chris
--
Simplistix - Conte
Shame on me indeed.
On Wed, Apr 1, 2009 at 5:38 AM, Guido van Rossum wrote:
> OK that might change matters. Shame on you though for posting a patch
> without any explanation of the issue.
>
> On Tue, Mar 31, 2009 at 8:36 PM, Maciej Fijalkowski wrote:
>> Because classes have now it's own local sc
OK that might change matters. Shame on you though for posting a patch
without any explanation of the issue.
On Tue, Mar 31, 2009 at 8:36 PM, Maciej Fijalkowski wrote:
> Because classes have now it's own local scope (according to Martin)
>
> It's not about exec in class, it's about exec in class i
Because classes have now it's own local scope (according to Martin)
It's not about exec in class, it's about exec in class in nested function.
On Wed, Apr 1, 2009 at 5:25 AM, Guido van Rossum wrote:
> Well hold on for a minute, I remember we used to have an exec
> statement in a class body in th
Well hold on for a minute, I remember we used to have an exec
statement in a class body in the standard library, to define some file
methods in socket.py IIRC. It's a totally different case than exec in
a nested function, and I don't believe it should be turned into a
syntax error at all. An exec
21 matches
Mail list logo
