Re: [Python-Dev] 2.5.3: assessing commits
On Tue, Oct 07, 2008 at 08:44:09PM -0400, A.M. Kuchling wrote: > At this point I still have 1191 files left. Many of these commits are > still irrelevant, but this is a lot for me to look through. A tarball > with the remaining commits is at > > http://www.amk.ca/files/python/2.6-changes.tgz On the metro this morning, I worked on this some more and now have only 858 files for consideration. At this point I think we have to look at commits individually. I'll turn the lists of commits into a set of wiki page that we can examine and edit down in parallel. (I've updated the above tarball in the meantime.) --amk ___ 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
[Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
I am working on getting Zope to run (or at least, start) with Python 2.6. It actually starts right now after applying some patches, which is amazing on itself, but it dies right away due to changes in asyncore that break Zope's internal version of medusa. I've opened a bug against Zope on Launchpad, but someone suggested that it might actually be a bug in python, in the sense that it changed asyncore in a backwards-incompatible way. I wouldn't go that far, since I think it's more likely that Zope's version of medusa is poking into asyncore internals instead: https://bugs.edge.launchpad.net/zope2/+bug/280020 I suspect a patch similar to this might be needed: http://codereview.appspot.com/744/diff/1/23 Anyone cares to comment? -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
Sidnei da Silva <[EMAIL PROTECTED]> wrote: > https://bugs.edge.launchpad.net/zope2/+bug/280020 I think there are real issues here with both asynchat and Medusa. Asynchat has been heavily re-written, and the "ac_out_buffer" has apparently disappeared. But "ac_out_buffer_size" is still there. That strikes me as odd, and probably means that asynchat.py needs more changes. However, Medusa (basically just an application layer on top of asyncore/asynchat) also needs to be re-written to take account of the changes in asynchat. Bill ___ 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
[Python-Dev] effect of "exec" on local scope
The issue came up while trying to get some Sympy code running on CLPython.
class C:
exec "a = 3"
print locals()
1. Is it guaranteed that class C gets an attribute "a", i.e. that the
locals printed include {'a': 3}?
2. It it (also) guaranteed if it were in a function scope?
The complete syntax of exec is:
exec CODE in Y, Z
where Y, Z are optional.
The documentation of "exec" says "if the optional parts are
omitted,the code is executed in the current scope." There are at least
two different interpretations:
a. The code is executed in the current class scope, so the assignment
must have an effect on the class scope.
b. The scope defaults to the local scope, by which is meant the
mapping returned by locals(), and of locals() the documentation says
that changes made to it may not influence the interpreter. (The
documentation of exec suggests using globals() and locals() as
arguments to exec, which seems hint at this interpretation.)
The relevant documentation:
exec:
http://docs.python.org/reference/simple_stmts.html#grammar-token-exec_stmt
locals: http://docs.python.org/library/functions.html#locals
- Willem
___
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
[Python-Dev] python dll no longer in system directory?
Is it intended that python30.dll and python26.dll are not longer installed in the \windows\system32 directory? This (pythonxy.dll not on $PATH) causes problems for COM objects implemented in Python. Thanks, Thomas ___ 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
Re: [Python-Dev] python dll no longer in system directory?
Thomas Heller wrote: Is it intended that python30.dll and python26.dll are not longer installed in the \windows\system32 directory? This (pythonxy.dll not on $PATH) causes problems for COM objects implemented in Python. How did you install Python 2.6? Did you install it only for yourself or for all users? Christian ___ 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
Re: [Python-Dev] python dll no longer in system directory?
Christian Heimes schrieb: > Thomas Heller wrote: >> Is it intended that python30.dll and python26.dll are not longer >> installed in the \windows\system32 directory? >> >> This (pythonxy.dll not on $PATH) causes problems for COM objects >> implemented in Python. > > How did you install Python 2.6? Did you install it only for yourself or > for all users? > For all users. I only deselected the 'register file extensions' option. This is on XP SP3, with admin rights. -- Thanks, Thomas ___ 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
Re: [Python-Dev] [python-committers] Proposed Python 3.0 schedule
On 10/7/08, Mark Hammond <[EMAIL PROTECTED]> wrote:
> # This is a Python 3.x script to execute a python 2.x script by 2to3'ing it.
> import sys
> from lib2to3.refactor import RefactoringTool, get_fixers_from_package
>
> fixers = get_fixers_from_package('lib2to3.fixes')
> options = dict(doctests_only=False, fix=[], list_fixes=[],
>print_function=False, verbose=False,
>write=True)
Note that only the print_function option is used.
> r = RefactoringTool(fixers, options)
> script = sys.argv[1]
> data = open(script).read()
> print("Converting...")
> got = r.refactor_string(data, script)
> print("Executing...")
> # nuke ourselves from argv
> del sys.argv[1]
> exec(str(got))
> ---
>
> ___
> python-committers mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-committers
>
--
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."
___
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
Re: [Python-Dev] effect of "exec" on local scope
Willem Broekema wrote:
The issue came up while trying to get some Sympy code running on CLPython.
class C:
exec "a = 3"
print locals()
1. Is it guaranteed that class C gets an attribute "a", i.e. that the
locals printed include {'a': 3}?
2. It it (also) guaranteed if it were in a function scope?
The complete syntax of exec is:
exec CODE in Y, Z
where Y, Z are optional.
The documentation of "exec" says "if the optional parts are
omitted,the code is executed in the current scope." There are at least
two different interpretations:
a. The code is executed in the current class scope, so the assignment
must have an effect on the class scope.
b. The scope defaults to the local scope, by which is meant the
mapping returned by locals(), and of locals() the documentation says
that changes made to it may not influence the interpreter. (The
documentation of exec suggests using globals() and locals() as
arguments to exec, which seems hint at this interpretation.)
The relevant documentation:
exec:
http://docs.python.org/reference/simple_stmts.html#grammar-token-exec_stmt
locals: http://docs.python.org/library/functions.html#locals
The 3.0 doc for exec() has this warning:
"Warning
The default locals act as described for function locals() below:
modifications to the default locals dictionary should not be attempted.
Pass an explicit locals dictionary if you need to see effects of the
code on locals after function exec() returns."
This implies interpretation b.
However, is spite of the warning, class locals is a dict and locals() is
that dict, so a is available for further use in class code.
So the answer to question 1 for current CPython is yes.
Whether that is guaranteed for all implementations and versions is
another story.
Functions are much trickier. The local namespace is not a dict, and
modifying the locals() dict does not modify the namespace. The answer
to 2. is No, not even now.
>>> def f():
exec('a=3')
print(locals())
return a
>>> f()
{'a': 3}
Traceback (most recent call last):
File "", line 1, in
f()
File "", line 4, in f
return a
NameError: global name 'a' is not defined
But why then is 'a' printed in the second call to locals (the implied
one in exec being the first)? It appears that a function or code object
can have only only one repeatedly used shadow dict. The 3.0 (and 2.5)
doc says "locals()
Update and return a dictionary representing the current local symbol
table." Note "update"; I had missed that before. To see this...
>>> def g():
a = locals()
b = locals()
return id(a), id(b), a,b
>>> g()
(20622048, 20622048, {'a': {...}}, {'a': {...}})
Inserting "print(a['a'])" between the locals calls raises KeyError.
Terry Jan Reedy
___
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
[Python-Dev] __getattr__ and new style classes
Hello there. I've just noticed what I consider a performance problem: Using new style classes to provide attribute-like access using __getattr__ is considerably slower than old style classes: Observe: s = """ class dude: def bar(self):pass def __getattr__(self, a): return a class dude2(object): def bar(self):pass def __getattr__(self, a): return a d = dude() d2 = dude2() d.a = d2.a = 1 """ timeit.Timer(´d.foo´, s).timeit() >0.32979211801421116 timeit.Timer(´d2.foo´, s).timeit() > 1.1119853719342245 The overhead is almost 3 times as high. I imagine that this is because new style classes must search further and harder before giving up and going to __getattr__. For the bound method the difference is less: timeit.Timer(´d.bar´, s).timeit() > 0.11835480370018558 timeit.Timer(´d2.bar´, s).timeit() > 0.17820851929263881 For fun, I also tested regular attributes, and see: timeit.Timer(´d.a´, s).timeit() > 0.069161394202183146 timeit.Timer(´d2.a´, s).timeit() > 0.17966275972594303 I'm surprised that accessing instance attributes like this is twice as slow using new style classes. Any thoughts on this? We are using a lot of low-level attribute access magic in EVE and so it would appear that we are best served by sticking with old-style classes. But these are going away eventually, so what to do? Where is this extra overhead coming from? And oh, it is no use using __getattribute__ instead, since it will always involve calls to object.__getattribute__ and become very slow. Cheers, Kristján ___ 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
Re: [Python-Dev] 2.5.3: assessing commits
On Wed, Oct 08, 2008 at 08:06:09AM -0400, A.M. Kuchling wrote: > look at commits individually. I'll turn the lists of commits into a > set of wiki pages that we can examine and edit down in parallel. I decided to put them in SVN instead, in sandbox/py2.5.3/ . How do we want to assess these commits for possible inclusion in 2.5.3? --amk ___ 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
Re: [Python-Dev] python dll no longer in system directory?
Thomas Heller wrote: > Is it intended that python30.dll and python26.dll are not longer > installed in the \windows\system32 directory? No, it's not. Please create a bug report (or, better, study the msiexec logs, and msi.py, to find out why this happens). I might not have time to look into this before the next release candidate. Regards, Martin ___ 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
Re: [Python-Dev] [Python-3000] Proposed Python 3.0 schedule
On Wed, Oct 8, 2008 at 12:51 AM, Dmitry Vasiliev <[EMAIL PROTECTED]> wrote: > > BTW, I think the following issues should be also marked as release blockers: Agreed and done. > > - http://bugs.python.org/issue3714 (nntplib module broken by str to > unicode conversion) > - http://bugs.python.org/issue3725 (telnetlib module broken by str to > unicode conversion) > - http://bugs.python.org/issue3727 (poplib module broken by str to > unicode conversion) > > -- > Dmitry Vasiliev > http://hlabs.spb.ru > -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ 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
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
On Wed, Oct 8, 2008 at 10:30 AM, Bill Janssen <[EMAIL PROTECTED]> wrote: > Sidnei da Silva <[EMAIL PROTECTED]> wrote: > >> https://bugs.edge.launchpad.net/zope2/+bug/280020 > > I think there are real issues here with both asynchat and Medusa. > Asynchat has been heavily re-written, and the "ac_out_buffer" has > apparently disappeared. But "ac_out_buffer_size" is still there. That > strikes me as odd, and probably means that asynchat.py needs more > changes. However, Medusa (basically just an application layer on top > of asyncore/asynchat) also needs to be re-written to take account of > the changes in asynchat. ac_out_buffer was removed because it is unneeded (we have a deque; why rely on an extra attribute?). ac_out_buffer_size still remains as a blocksize in which to pre-split outgoing data (if you have a 100k string you want to send, repeatedly slicing it as you are able to send pieces is slow, but pre-slicing chunks is fast, and generally results in being able to pass full chunk to the underlying TCP/IP stack). But yes, zope needs to be changed to reflect the updated asyncore/asynchat semantics. Trust me; it's faster, cleaner, and easier to use now. - Josiah ___ 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
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
On Wed, Oct 8, 2008 at 6:26 PM, Josiah Carlson <[EMAIL PROTECTED]> wrote: > ac_out_buffer was removed because it is unneeded (we have a deque; why > rely on an extra attribute?). > ac_out_buffer_size still remains as a blocksize in which to pre-split > outgoing data (if you have a 100k string you want to send, repeatedly > slicing it as you are able to send pieces is slow, but pre-slicing > chunks is fast, and generally results in being able to pass full chunk > to the underlying TCP/IP stack). > > But yes, zope needs to be changed to reflect the updated > asyncore/asynchat semantics. Trust me; it's faster, cleaner, and > easier to use now. Great to know. So medusa should be changed similarly to the changes made to asynchat? Your suggestion on the bugtracker is even better: to subclass asynchat as much as possible. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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
Re: [Python-Dev] __getattr__ and new style classes
Kristján Valur Jónsson wrote:
> Hello there.
>
> I‘ve just noticed what I consider a performance problem:
>
> Using new style classes to provide attribute-like access using
> __getattr__ is considerably slower than old style classes: Observe:
I can't reproduce those relative numbers using SVN trunk. Using your
setup code (copied and pasted directly from your message to my
interpreter session) I got the following numbers:
>>> timeit.Timer('d.foo', s).timeit()
1.2362558841705322
>>> timeit.Timer('d2.foo', s).timeit()
1.1634600162506104
>>> timeit.Timer('d.foo', s).timeit()
1.1840031147003174
>>> timeit.Timer('d2.foo', s).timeit()
1.1554200649261475
(a slight speed advantage to the new-style class for __getattr__)
>>> timeit.Timer('d.bar', s).timeit()
0.17601609230041504
>>> timeit.Timer('d2.bar', s).timeit()
0.18697309494018555
>>> timeit.Timer('d.bar', s).timeit()
0.1711127758026123
>>> timeit.Timer('d2.bar', s).timeit()
0.1827549934387207
(very slight speed advantage to the old-style class for the unbound method)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
Sidnei da Silva <[EMAIL PROTECTED]> wrote: > Great to know. So medusa should be changed similarly to the changes > made to asynchat? Hmmm. Been a long time since a Medusa release, but I need a working Medusa, too. > Your suggestion on the bugtracker is even better: to > subclass asynchat as much as possible. That's basically what Medusa is, a set of subclasses. Bill ___ 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
Re: [Python-Dev] __getattr__ and new style classes
On Thu, 9 Oct 2008 06:27:06 am Kristján Valur Jónsson wrote:
> Hello there.
> I've just noticed what I consider a performance problem:
> Using new style classes to provide attribute-like access using
> __getattr__ is considerably slower than old style classes: Observe:
>
> s = """
> class dude:
> def bar(self):pass
> def __getattr__(self, a): return a
> class dude2(object):
> def bar(self):pass
> def __getattr__(self, a): return a
> d = dude()
> d2 = dude2()
> d.a = d2.a = 1
> """
> timeit.Timer(´d.foo´, s).timeit()
> >0.32979211801421116
>
> timeit.Timer(´d2.foo´, s).timeit()
> > 1.1119853719342245
Not only don't I observe the same results as you, I'm afraid I can't
even get your code to run. I get a SyntaxError from the funny quotes
you're using: ´d.foo´ instead of 'd.foo' or "d.foo".
Also, I trust you know enough not to pay too much attention to a single
test result? Timing results are notoriously subject to interference
from external processes.
Finally, when reporting performance problems, it will be VERY helpful to
report the version and platform you are using. There's no point in
having people looking for a slow-down in Python 2.6 if you're actually
using Python 2.3 (say).
Anyway, for the record here are my results for Python 2.5. I don't
believe the differences are significant.
>>> min(Timer('d.foo', s).repeat())
1.9228429794311523
>>> min(Timer('d2.foo', s).repeat())
2.1040639877319336
>>> min(Timer('d.bar', s).repeat())
0.68272304534912109
>>> min(Timer('d2.bar', s).repeat())
0.41949796676635742
>>> min(Timer('d.a', s).repeat())
0.45727396011352539
>>> min(Timer('d2.a', s).repeat())
0.59516501426696777
--
Steven
___
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
Re: [Python-Dev] __getattr__ and new style classes
Steven D'Aprano wrote: Not only don't I observe the same results as you, I'm afraid I can't even get your code to run. I get a SyntaxError from the funny quotes you're using: ´d.foo´ instead of 'd.foo' or "d.foo". Kristján is using the old style and alternative syntax for repr(). Somehow the `` got screwed up by either his mailer or the mailing list. Don't be ashamed that you aren't aware of the alternative syntax. We keep it locked up in the cellar and it has been removed from the new, shiny Python 3 world. >>> `object` "" >>> `object` == repr(object) True Christian ___ 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
Re: [Python-Dev] effect of "exec" on local scope
Hi Terry,
On Wed, Oct 8, 2008 at 9:17 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Willem Broekema wrote:
>>
>> The issue came up while trying to get some Sympy code running on CLPython.
>>
>> class C:
>> exec "a = 3"
>> print locals()
>>
>> 1. Is it guaranteed that class C gets an attribute "a", i.e. that the
>> locals printed include {'a': 3}?
>> 2. It it (also) guaranteed if it were in a function scope?
>>
>> The complete syntax of exec is:
>> exec CODE in Y, Z
>> where Y, Z are optional.
>>
>> The documentation of "exec" says "if the optional parts are
>> omitted,the code is executed in the current scope." There are at least
>> two different interpretations:
>>
>> a. The code is executed in the current class scope, so the assignment
>> must have an effect on the class scope.
>>
>> b. The scope defaults to the local scope, by which is meant the
>> mapping returned by locals(), and of locals() the documentation says
>> that changes made to it may not influence the interpreter. (The
>> documentation of exec suggests using globals() and locals() as
>> arguments to exec, which seems hint at this interpretation.)
>>
>> The relevant documentation:
>> exec:
>> http://docs.python.org/reference/simple_stmts.html#grammar-token-exec_stmt
>> locals: http://docs.python.org/library/functions.html#locals
>
> The 3.0 doc for exec() has this warning:
> "Warning
> The default locals act as described for function locals() below:
> modifications to the default locals dictionary should not be attempted. Pass
> an explicit locals dictionary if you need to see effects of the code on
> locals after function exec() returns."
>
> This implies interpretation b.
>
> However, is spite of the warning, class locals is a dict and locals() is
> that dict, so a is available for further use in class code.
>
> So the answer to question 1 for current CPython is yes.
>
> Whether that is guaranteed for all implementations and versions is another
> story.
>
> Functions are much trickier. The local namespace is not a dict, and
> modifying the locals() dict does not modify the namespace. The answer to 2.
> is No, not even now.
>
def f():
>exec('a=3')
>print(locals())
>return a
>
f()
> {'a': 3}
> Traceback (most recent call last):
> File "", line 1, in
>f()
> File "", line 4, in f
>return a
> NameError: global name 'a' is not defined
>
> But why then is 'a' printed in the second call to locals (the implied one in
> exec being the first)? It appears that a function or code object can have
> only only one repeatedly used shadow dict. The 3.0 (and 2.5) doc says
> "locals()
> Update and return a dictionary representing the current local symbol table."
> Note "update"; I had missed that before. To see this...
>
def g():
>a = locals()
>b = locals()
>return id(a), id(b), a,b
>
g()
> (20622048, 20622048, {'a': {...}}, {'a': {...}})
>
> Inserting "print(a['a'])" between the locals calls raises KeyError.
Thanks very much for the thorough answer. The reason for Willem's
question is this code that we currently have in sympy (see [1] for the
whole thread):
class Basic(AssumeMeths):
...
for k in AssumeMeths._assume_defined:
exec "is_%s = property(make__get_assumption('Basic', '%s'))" % (k,k)
Which works in CPython but fails in CLPython. From your answer it
seems to me that this code is not nice and we should not use it and
should rather use something like:
class Basic(AssumeMeths):
...
for k in AssumeMeths._assume_defined:
setattr(Basic, 'is_%s' % k, property(make__get_assumption('Basic', '%s' % k)))
which should work on all platforms. What do you think?
Ondrej
[1] http://code.google.com/p/sympy/issues/detail?id=1134
___
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
Re: [Python-Dev] __getattr__ and new style classes
Kristján Valur Jónsson wrote: Using new style classes to provide attribute-like access using __getattr__ is considerably slower than old style classes Do you really need __getattr__, or could you use properties instead? -- Greg ___ 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
Re: [Python-Dev] effect of "exec" on local scope
Well, I don't recall what CLPython is, but I believe it is broken and
that code should work -- there are (or used to be) examples of using
exec to populate classes in the standard library so while it may look
dodgy it really is exected to work...
On Wed, Oct 8, 2008 at 4:40 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> Hi Terry,
>
> On Wed, Oct 8, 2008 at 9:17 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> Willem Broekema wrote:
>>>
>>> The issue came up while trying to get some Sympy code running on CLPython.
>>>
>>> class C:
>>> exec "a = 3"
>>> print locals()
>>>
>>> 1. Is it guaranteed that class C gets an attribute "a", i.e. that the
>>> locals printed include {'a': 3}?
>>> 2. It it (also) guaranteed if it were in a function scope?
>>>
>>> The complete syntax of exec is:
>>> exec CODE in Y, Z
>>> where Y, Z are optional.
>>>
>>> The documentation of "exec" says "if the optional parts are
>>> omitted,the code is executed in the current scope." There are at least
>>> two different interpretations:
>>>
>>> a. The code is executed in the current class scope, so the assignment
>>> must have an effect on the class scope.
>>>
>>> b. The scope defaults to the local scope, by which is meant the
>>> mapping returned by locals(), and of locals() the documentation says
>>> that changes made to it may not influence the interpreter. (The
>>> documentation of exec suggests using globals() and locals() as
>>> arguments to exec, which seems hint at this interpretation.)
>>>
>>> The relevant documentation:
>>> exec:
>>> http://docs.python.org/reference/simple_stmts.html#grammar-token-exec_stmt
>>> locals: http://docs.python.org/library/functions.html#locals
>>
>> The 3.0 doc for exec() has this warning:
>> "Warning
>> The default locals act as described for function locals() below:
>> modifications to the default locals dictionary should not be attempted. Pass
>> an explicit locals dictionary if you need to see effects of the code on
>> locals after function exec() returns."
>>
>> This implies interpretation b.
>>
>> However, is spite of the warning, class locals is a dict and locals() is
>> that dict, so a is available for further use in class code.
>>
>> So the answer to question 1 for current CPython is yes.
>>
>> Whether that is guaranteed for all implementations and versions is another
>> story.
>>
>> Functions are much trickier. The local namespace is not a dict, and
>> modifying the locals() dict does not modify the namespace. The answer to 2.
>> is No, not even now.
>>
> def f():
>>exec('a=3')
>>print(locals())
>>return a
>>
> f()
>> {'a': 3}
>> Traceback (most recent call last):
>> File "", line 1, in
>>f()
>> File "", line 4, in f
>>return a
>> NameError: global name 'a' is not defined
>>
>> But why then is 'a' printed in the second call to locals (the implied one in
>> exec being the first)? It appears that a function or code object can have
>> only only one repeatedly used shadow dict. The 3.0 (and 2.5) doc says
>> "locals()
>> Update and return a dictionary representing the current local symbol table."
>> Note "update"; I had missed that before. To see this...
>>
> def g():
>>a = locals()
>>b = locals()
>>return id(a), id(b), a,b
>>
> g()
>> (20622048, 20622048, {'a': {...}}, {'a': {...}})
>>
>> Inserting "print(a['a'])" between the locals calls raises KeyError.
>
>
> Thanks very much for the thorough answer. The reason for Willem's
> question is this code that we currently have in sympy (see [1] for the
> whole thread):
>
> class Basic(AssumeMeths):
> ...
> for k in AssumeMeths._assume_defined:
>exec "is_%s = property(make__get_assumption('Basic', '%s'))" % (k,k)
>
>
> Which works in CPython but fails in CLPython. From your answer it
> seems to me that this code is not nice and we should not use it and
> should rather use something like:
>
> class Basic(AssumeMeths):
> ...
>
> for k in AssumeMeths._assume_defined:
> setattr(Basic, 'is_%s' % k, property(make__get_assumption('Basic', '%s' %
> k)))
>
>
> which should work on all platforms. What do you think?
>
> Ondrej
>
> [1] http://code.google.com/p/sympy/issues/detail?id=1134
> ___
> 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/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
Josiah Carlson <[EMAIL PROTECTED]> wrote: > But yes, zope needs to be changed to reflect the updated > asyncore/asynchat semantics. Trust me; it's faster, cleaner, and > easier to use now. Just for completeness, I built a fresh 2.6, installed Medusa (from http://www.amk.ca/python/code/medusa.html), and it runs just fine (well, as well as it does on 2.5, anyway). I think this is a Zope issue. Bill ___ 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
Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa
On Wed, Oct 8, 2008 at 6:39 PM, Bill Janssen <[EMAIL PROTECTED]> wrote: > Josiah Carlson <[EMAIL PROTECTED]> wrote: > >> But yes, zope needs to be changed to reflect the updated >> asyncore/asynchat semantics. Trust me; it's faster, cleaner, and >> easier to use now. > > Just for completeness, I built a fresh 2.6, installed Medusa (from > http://www.amk.ca/python/code/medusa.html), and it runs just fine (well, > as well as it does on 2.5, anyway). I think this is a Zope issue. Way back in the day, Zope monkeypatched whole parts of asyncore, replacing them with some of its own code. If that's still the case, this breakage should be no surprise. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] effect of "exec" on local scope
Ondrej Certik wrote:
Which works in CPython but fails in CLPython. From your answer it
seems to me that this code is not nice and we should not use it and
should rather use something like:
class Basic(AssumeMeths):
...
for k in AssumeMeths._assume_defined:
setattr(Basic, 'is_%s' % k, property(make__get_assumption('Basic', '%s' % k)))
which should work on all platforms. What do you think?
That is what setattr is for. Many consider exec a last resort. I think
any further discussion should move to the general python list or c.l.p
since this is not a develop-core-python issue.
___
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
