Re: [Python-Dev] IO implementation: in C and Python?
Benjamin Peterson benjamin at python.org writes: As we prepare to merge the io-c branch, the question has come up [1] about the original Python implementation. Should it just be deleted in favor C version? The wish to maintain the two implementations together has been raised on the basis that Python is easier to experiment on and read (for other vm implementors). As I said, if it is the way forward, I suggest putting the Python version in a separate module (e.g. pyio.py), for the sake of clarity and also because it may slightly improve startup times (the pure-Python module wouldn't get imported in normal conditions). Your thoughts? Regards Antoine. ___ 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] A suggestion: Do proto-PEPs in Google Docs
Stephen J. Turnbull schrieb: FWIW, Google Docs is almost there. Working with Brett et al on early drafts of PEP 0374 was easy and pleasant, and Google Docs gives control of access to the document to the editor, not the Subversion admin. The ability to make comments that are not visible to non-editors was nice. Now that it's in Subversion it's much less convenient for me (a non-committer). I actually have to *decide* to work on it, rather than simply raising a browser window, hitting refresh and fixing a typo or two (then back to day job work). The main problem with Google Docs is that is records a revision automatically every so often (good) but doesn't prune the automatic commits (possibly hard to do efficiently) OR mark user saves specially (easy to do). This lack of marking important revisions makes the diff functionality kind of tedious. I don't know how automatic the conversion to reST was, but the PEP in Subversion is a quite accurate conversion of the Google Doc version. The Python Wiki should also be considered: * Comparing versions is easy, and versions are only saved on Save * It supports reStructuredText, so there is no need for conversion afterwards. For PEPs drafted exclusively by committers, SVN is of course still the best and simplest option. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] A suggestion: Do proto-PEPs in Google Docs
Georg Brandl g.brandl at gmx.net writes: The Python Wiki should also be considered: * Comparing versions is easy, and versions are only saved on Save * It supports reStructuredText, so there is no need for conversion afterwards. And it's vendor-neutral :-) ___ 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] IO implementation: in C and Python?
Antoine Pitrou schrieb: Benjamin Peterson benjamin at python.org writes: As we prepare to merge the io-c branch, the question has come up [1] about the original Python implementation. Should it just be deleted in favor C version? The wish to maintain the two implementations together has been raised on the basis that Python is easier to experiment on and read (for other vm implementors). As I said, if it is the way forward, I suggest putting the Python version in a separate module (e.g. pyio.py), for the sake of clarity and also because it may slightly improve startup times (the pure-Python module wouldn't get imported in normal conditions). Your thoughts? I just hope everyone updates both versions when making changes to IO. This is somewhat of a non-problem for small modules like bisect, or heapq. For pickle and StringIO, we already saw how not to do it in 2.x -- hopefully the new _pickle and pickle modules stay compatible. IO is much larger a piece of code... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] IO implementation: in C and Python?
Georg Brandl g.brandl at gmx.net writes: I just hope everyone updates both versions when making changes to IO. My proposal is just organizational, it is neutral in terms of whether or not the Python version is correctly maintained. We can hope that the IO lib *semantics* won't change too much in the future (although there is an IMO legitimate request for a setblocking() method: http://bugs.python.org/issue949667). On the other hand, I don't expect anyone to willingly use the Python version if the C version is available. ___ 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] IO implementation: in C and Python?
Antoine Pitrou wrote: Georg Brandl g.brandl at gmx.net writes: I just hope everyone updates both versions when making changes to IO. My proposal is just organizational, it is neutral in terms of whether or not the Python version is correctly maintained. We can hope that the IO lib *semantics* won't change too much in the future (although there is an IMO legitimate request for a setblocking() method: http://bugs.python.org/issue949667). On the other hand, I don't expect anyone to willingly use the Python version if the C version is available. If they're functionally equivalent and single set of tests is run on both then -- assuming good tests -- breakage would be noticed... Michael ___ 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/fuzzyman%40voidspace.org.uk ___ 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] IO implementation: in C and Python?
On Thu, 19 Feb 2009 21:41:51 -0600, Benjamin Peterson wrote: As we prepare to merge the io-c branch, the question has come up [1] about the original Python implementation. Should it just be deleted in favor C version? The wish to maintain the two implementations together has been raised on the basis that Python is easier to experiment on and read (for other vm implementors). Thoughts? http://bugs.python.org/issue4565 How about making it an optional module instead, a compile flag when compiling python would determine whether the python or C or both versions of the libraries would be included with C-only as the default. Alternatively, if the compile flag was turned off and you want access to the python version, provide a downloadable pure python library (OS package manager could have something like python-lib-purepy or something similar). This would streamline python, and only people who want to mess around would download the purepy version. ___ 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] Attention Bazaar mirror users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've just upgraded the Bazaar mirrors on code.python.org to use bzr 1.12. We now have the opportunity to upgrade the repository format for better performance. Because of the bzr-svn requirement, we need a rich root format. Upgrading to 1.9-rich-root could buy us some significant performance improvements, but it will require all clients to upgrade to at least bzr 1.9, which was released on November 7, 2008. I would like to do this upgrade. If you are currently using the Bazaar mirrors at code.python.org and upgrading your client to at least bzr 1.9 would be a hardship, please contact me. If I don't hear any objections by say Tuesday, I'll go ahead and do the repo upgrades. Thanks, Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSZ7HwHEjvBPtnXfVAQIlxAQAk0ze8AHLY8aezrH35+Vv4tXloLy/FV1M GHF2QzLBaV45Hr4d3i8Os32eaSvhWyFbCGeBZtm3q3pOwPy9ST/tDdI0XBwjd0M1 FV1Pg3v97IYeI6Pa1HKz0sKxbygACiZ9iQWde3b85zXEhsaZfXo7RiendmMkYift Uvw0WWJZ1DU= =sCFZ -END PGP SIGNATURE- ___ 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] IO implementation: in C and Python?
On Fri, Feb 20, 2009 at 4:01 AM, Antoine Pitrou solip...@pitrou.net wrote: Georg Brandl g.brandl at gmx.net writes: I just hope everyone updates both versions when making changes to IO. My proposal is just organizational, it is neutral in terms of whether or not the Python version is correctly maintained. I worry that with your proposal people are once again going to import the pure Python version where they shouldn't. Maybe _pyio.py would work though? We can hope that the IO lib *semantics* won't change too much in the future (although there is an IMO legitimate request for a setblocking() method: http://bugs.python.org/issue949667). On the other hand, I don't expect anyone to willingly use the Python version if the C version is available. Hoping that modules won't evolve is futile. The concern for divergence is real. Unit-testing both with the same tests might be the solution. -- --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] IO implementation: in C and Python?
Guido van Rossum guido at python.org writes: I worry that with your proposal people are once again going to import the pure Python version where they shouldn't. Maybe _pyio.py would work though? I'm ok with _pyio.py. Hoping that modules won't evolve is futile. The concern for divergence is real. Unit-testing both with the same tests might be the solution. Yes, the same tests should be applied to both (modulo the few ones that test for implementation-specific behaviour, e.g. the max_buffer_size stuff). Regards Antoine. ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (02/13/09 - 02/20/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2341 open (+55) / 14813 closed (+27) / 17154 total (+82) Open issues with patches: 817 Average duration of open issues: 656 days. Median duration of open issues: 393 days. Open Issues Breakdown open 2315 (+55) pending26 ( +0) Issues Created Or Reopened (84) ___ Document __instancecheck__ and __subclasscheck__ 02/13/09 http://bugs.python.org/issue5250created tjreedy contextlib.nested inconsistent with, well, nested with statement 02/13/09 http://bugs.python.org/issue5251created jwp 2to3 should detect and delete import of removed statvfs module 02/13/09 http://bugs.python.org/issue5252created sjt os.environ.get() doesn't handle default value02/13/09 CLOSED http://bugs.python.org/issue5253created marystern Formatting error in findertools header 02/13/09 http://bugs.python.org/issue5254created adamvan unicode support with os.readlink() 02/13/09 CLOSED http://bugs.python.org/issue5255created scudette rlcompleter adds builtins when custom dict is used 02/14/09 http://bugs.python.org/issue5256created armandas test_zipfle and test_distutils write in the test directories 02/14/09 http://bugs.python.org/issue5257created tarek addpackage in site.py fails hard on badly formed .pth files 02/14/09 http://bugs.python.org/issue5258created jwheare smtplib is broken in Python3 02/14/09 http://bugs.python.org/issue5259created miwa longobject.c: minor fixes, cleanups and optimizations02/14/09 CLOSED http://bugs.python.org/issue5260created marketdickinson patch with lock fails on multiprocessing 02/14/09 http://bugs.python.org/issue5261created stepheng.lynch patch PythonLauncher considered harmfull 02/14/09 http://bugs.python.org/issue5262created ronaldoussoren Error printing UTF-8 decoded text02/14/09 CLOSED http://bugs.python.org/issue5263created grace StringIO failure when reading a chunk of text without newlines 02/14/09 http://bugs.python.org/issue5264created pitrou StringIO can duplicate newlines in universal newlines mode 02/14/09 http://bugs.python.org/issue5265created pitrou StringIO.read(n) does not enforce requested size in newline mode 02/14/09 http://bugs.python.org/issue5266created pitrou Subversion problem with PythonLauncher after building 3.0 or 3.1 02/15/09 http://bugs.python.org/issue5267created MLModel VMSError not documented in Doc/library/exceptions.rst02/15/09 CLOSED http://bugs.python.org/issue5268created MLModel OS X Installer: add options to specify universal
Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs
On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou solip...@pitrou.net wrote: Georg Brandl g.brandl at gmx.net writes: The Python Wiki should also be considered: * Comparing versions is easy, and versions are only saved on Save * It supports reStructuredText, so there is no need for conversion afterwards. And it's vendor-neutral :-) Touche. I still don't like wikis for this purpose very much -- a person editing effectively grabs a lock on the whole file. (Wikimedia addresses this to some extend by allowing sections to be edited, but I don't see this feature in moinmoin yet, and I don't see us switching.) Also there is no access control -- anyone who can create a login can edit. -- --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] A suggestion: Do proto-PEPs in Google Docs
On 20-02-2009, Guido van Rossum wrote: On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou solip...@pitrou.net wrote: Georg Brandl g.brandl at gmx.net writes: The Python Wiki should also be considered: * Comparing versions is easy, and versions are only saved on Save * It supports reStructuredText, so there is no need for conversion afterwards. And it's vendor-neutral :-) Touche. I still don't like wikis for this purpose very much -- a person editing effectively grabs a lock on the whole file. (Wikimedia addresses this to some extend by allowing sections to be edited, but I don't see this feature in moinmoin yet, and I don't see us switching.) Also there is no access control -- anyone who can create a login can edit. Isn't it the good oportunity to try a DVCS ? -- William Dodé - http://flibuste.net Informaticien Indépendant ___ 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] Summary of Python tracker Issues
Python tracker wrote: ACTIVITY SUMMARY (02/13/09 - 02/20/09) Python tracker at http://bugs.python.org/ [...] 2341 open (+55) / 14813 closed (+27) / 17154 total (+82) I was about to cry foul, +27 closed? We closed so many issues last week, how come? Then, I realized the headings tell another story: Issues Created Or Reopened (84) [...] Issues Now Closed (103) Woot! We did it! More issues closed than opened, that's sweet :) To celebrate, I'll have a two-day tracker sprint (probably Sunday and Monday, a holiday here) to add a couple of search options and a view for mass-updating issues. During the sprint, you'll be able to get your feature requests for and/or bug reports about the tracker at a considerably lower price, so send them in :) Daniel P.S.: It seems the 2341 open (+55) / 14813 closed (+27) / 17154 total (+82) line is about Issues Created only :) ___ 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] A suggestion: Do proto-PEPs in Google Docs
On Fri, Feb 20, 2009 at 10:02 AM, William Dode w...@flibuste.net wrote: On 20-02-2009, Guido van Rossum wrote: On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou solip...@pitrou.net wrote: Georg Brandl g.brandl at gmx.net writes: The Python Wiki should also be considered: * Comparing versions is easy, and versions are only saved on Save * It supports reStructuredText, so there is no need for conversion afterwards. And it's vendor-neutral :-) Touche. I still don't like wikis for this purpose very much -- a person editing effectively grabs a lock on the whole file. (Wikimedia addresses this to some extend by allowing sections to be edited, but I don't see this feature in moinmoin yet, and I don't see us switching.) Also there is no access control -- anyone who can create a login can edit. Isn't it the good oportunity to try a DVCS ? That was my original suggestion, yes, but Stephen Turnbull suggested Google Docs instead. -- --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] A suggestion: Do proto-PEPs in Google Docs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 20, 2009, at 1:16 PM, Guido van Rossum wrote: Isn't it the good oportunity to try a DVCS ? That was my original suggestion, yes, but Stephen Turnbull suggested Google Docs instead. I found Google docs to be both very helpful and very painful. It was helpful because it supports multiple simultaneous editors pretty nicely. It was painful because I was constantly battered by inexplicable bugs (e.g. at one point my ability to add comments just went away). Maybe the closest home grown solution would be gobby, though the participants would have to manage persistency themselves. A DVCS would probably work too, given these are almost entirely text files. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSZ76AXEjvBPtnXfVAQIx5QQAs29FVEYDjbcvG2vLB3RtuuLOwahECP2Q Yyxvz26mRgOeCX/4rfa4sI/r/dmyhbntGmvfqc/rE3Laej2G5vAqsBJfuhMM6xpx Men3eypCKELK52nR3CQpUfODVu9ASYzNlezYkS2IEDfWRB95wBmLS9oKPwo55coi 9FSsI2rvyKQ= =q+II -END PGP SIGNATURE- ___ 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] Choosing a best practice solution for Python/extension modules
With io getting rewritten as an extension module, I think it's time to try
to come up with a good best practice scenario for how to be able to control
when a module uses a pure Python implementation and when it uses extension
module optimizations. This is really only important for testing as if the
extension is missing then the pure Python version is just flat-out used.
As an example, let's just go with pickle and the Pickler class, with _pickle
as the extension module.
If you look at examples in the standard library, their seems to be two
approaches. One is simply to blast the pure Python version:
class Pickler: pass
try: from _pickle import Pickler
except ImportError: pass
This is bad, though, as the only way to get a pure Python version for
testing is to clear out pickle and _pickle from sys.modules, put None in for
sys.modules['_pickle'] and then import pickle again. Yuck.
The other option is to hide the pure Python version::
class _Pickler: pass
try: from _pickle import Pickler # pickle actualy imports *
except ImportError: Pickler = _Pickler
Better, but it still means that you are mucking around with hidden names and
it hard-codes what part of the module gets replaced (using import * gets
around this, but it also blasts things like __doc__ which you probably don't
want).
Now, from what I can tell, Antoine is suggesting having _pyio and a _io and
then io is simply:
try: from _io import *
except ImportError: from _pyio import *
That works for testing as you can then have test classes have an attribute
for the module to use and then create two subclasses which set what module
to use (kind of like how test_warnings currently does it). But this only
really works for complete module replacements, not modules like pickle where
only key portions have been rewritten (which happens more often than the
complete rewrite).
So here is my crazy idea that I came up with late last night (i.e. might not
make a lot of sense).
First, the module with the pure Python code is the main version. At the end
of that module, you make a function call: ``use_extension(__name__,
'_pickle')``. That function then does some magic::
def use_extension(py_name, ext_name):
try:
ext = importlib.import_module(ext_name)
except ImportError:
return
py = sys.modules[py_name]
swapped = {}
for name in (x for x in dir(ext) if not x.startswith('__')):
swapped[name] = getattr(py, name)
setattr(py, name, getattr(ext, name))
py.__extension__ = ext_name, swapped
You can also have an undo_extension('pickle') and it will unroll what was
changed. This makes choosing what version of a module to use very simple in
tests as it is a single function call in one direction or another. And doing
it this way also allows for different VMs to choose different things to
replace. For instance IronPython might decide that most of pickle is fine
and only want to change a single function with an extension; this solution
lets them do that without it being hard-coded in the standard library. At
worst other VMs simply need to refactor the Python code so that there is a
class or function that can be replaced.
So go ahead and tear this apart so that we can hopefully reach a consensus
that makes sense so that at least testing can easily be done.
-Brett
___
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] IO implementation: in C and Python?
Guido van Rossum wrote: On Fri, Feb 20, 2009 at 4:01 AM, Antoine Pitrou solip...@pitrou.net wrote: Georg Brandl g.brandl at gmx.net writes: I just hope everyone updates both versions when making changes to IO. My proposal is just organizational, it is neutral in terms of whether or not the Python version is correctly maintained. I worry that with your proposal people are once again going to import the pure Python version where they shouldn't. Maybe _pyio.py would work though? From a user perspective, continuity of 'import xyz' importing the currently best implementation is what is important, even if that switches back and forth. We can hope that the IO lib *semantics* won't change too much in the future (although there is an IMO legitimate request for a setblocking() method: http://bugs.python.org/issue949667). On the other hand, I don't expect anyone to willingly use the Python version if the C version is available. Hoping that modules won't evolve is futile. The concern for divergence is real. Unit-testing both with the same tests might be the solution. It seems to me that starting new features with a new test and prototyping in the Python version should mostly avoid the problem. Keeping the Python version allows non-C Pythoneers to contribute to such efforts. (As opposed to fixing a C-only bug.) If the Python version is ahead at the time of a release, the Python version could be reverted to being a master version that import the C version for most but not all functions. tjr ___ 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] Choosing a best practice solution for Python/extension modules
On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon br...@python.org wrote: Now, from what I can tell, Antoine is suggesting having _pyio and a _io and then io is simply: try: from _io import * except ImportError: from _pyio import * That works for testing as you can then have test classes have an attribute for the module to use and then create two subclasses which set what module to use (kind of like how test_warnings currently does it). But this only really works for complete module replacements, not modules like pickle where only key portions have been rewritten (which happens more often than the complete rewrite). A slight change would make it work for modules where only key functions have been rewritten. For example, pickle.py could read: from _pypickle import * try: from _pickle import * except ImportError: pass -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ 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] Choosing a best practice solution for Python/extensionmodules
[Brett] With io getting rewritten as an extension module, I think it's time to try to come up with a good best practice scenario for how to be able to control when a module uses a pure Python implementation and when it uses extension module optimizations. This is really only important for testing as if the extension is missing then the pure Python version is just flat-out used. There is also need in some modules where the two are not exactly equivalent or where there are multiple C extensions to choose from. In PyYAML, there needs to be an easier way to switch parsers and emitters (i.e. LibYAML). There are similar issues with xmlrpclib with the choice of parsers, marshallers, and unmarshallers. Possibly, the same mechanism can offer the user more control over which dbm is used when there are several choices. Raymond ___ 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] Choosing a best practice solution for Python/extension modules
On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach dan...@stutzbachenterprises.com wrote: On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon br...@python.org wrote: Now, from what I can tell, Antoine is suggesting having _pyio and a _io and then io is simply: try: from _io import * except ImportError: from _pyio import * That works for testing as you can then have test classes have an attribute for the module to use and then create two subclasses which set what module to use (kind of like how test_warnings currently does it). But this only really works for complete module replacements, not modules like pickle where only key portions have been rewritten (which happens more often than the complete rewrite). A slight change would make it work for modules where only key functions have been rewritten. For example, pickle.py could read: from _pypickle import * try: from _pickle import * except ImportError: pass True, although that still suffers from the problem of overwriting things like __name__, __file__, etc. -Brett ___ 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] Choosing a best practice solution for Python/extensionmodules
On Fri, Feb 20, 2009 at 12:33, Raymond Hettinger pyt...@rcn.com wrote: [Brett] With io getting rewritten as an extension module, I think it's time to try to come up with a good best practice scenario for how to be able to control when a module uses a pure Python implementation and when it uses extension module optimizations. This is really only important for testing as if the extension is missing then the pure Python version is just flat-out used. There is also need in some modules where the two are not exactly equivalent or where there are multiple C extensions to choose from. In PyYAML, there needs to be an easier way to switch parsers and emitters (i.e. LibYAML). There are similar issues with xmlrpclib with the choice of parsers, marshallers, and unmarshallers. Possibly, the same mechanism can offer the user more control over which dbm is used when there are several choices. So are you saying you want something that takes multiple arguments like ``use_extension(py_name, *ext_names)``? Or are you wanting to go down the road of modules needing to define their own functions to use or unwind changes? -Brett ___ 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] Choosing a best practice solution for Python/extension modules
On Fri, Feb 20, 2009 at 12:37, Brett Cannon br...@python.org wrote: On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach dan...@stutzbachenterprises.com wrote: On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon br...@python.org wrote: Now, from what I can tell, Antoine is suggesting having _pyio and a _io and then io is simply: try: from _io import * except ImportError: from _pyio import * That works for testing as you can then have test classes have an attribute for the module to use and then create two subclasses which set what module to use (kind of like how test_warnings currently does it). But this only really works for complete module replacements, not modules like pickle where only key portions have been rewritten (which happens more often than the complete rewrite). A slight change would make it work for modules where only key functions have been rewritten. For example, pickle.py could read: from _pypickle import * try: from _pickle import * except ImportError: pass True, although that still suffers from the problem of overwriting things like __name__, __file__, etc. Actually, I take that back; the IMPORT_STAR opcode doesn't pull in anything starting with an underscore. So while this alleviates the worry above, it does mean that anything that gets rewritten needs to have a name that does not lead with an underscore for this to work. Is that really an acceptable compromise for a simple solution like this? -Brett ___ 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] Choosing a best practice solution for Python/extension modules
Brett Cannon wrote: On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach dan...@stutzbachenterprises.com mailto:dan...@stutzbachenterprises.com wrote: On Fri, Feb 20, 2009 at 1:44 PM, Brett Cannon br...@python.org mailto:br...@python.org wrote: Now, from what I can tell, Antoine is suggesting having _pyio and a _io and then io is simply: try: from _io import * except ImportError: from _pyio import * That works for testing as you can then have test classes have an attribute for the module to use and then create two subclasses which set what module to use (kind of like how test_warnings currently does it). But this only really works for complete module replacements, not modules like pickle where only key portions have been rewritten (which happens more often than the complete rewrite). A slight change would make it work for modules where only key functions have been rewritten. For example, pickle.py could read: from _pypickle import * try: from _pickle import * except ImportError: pass True, although that still suffers from the problem of overwriting things like __name__, __file__, etc. What do you mean overwriting __name__ and __file__? Doing import * in a pure Python file doesn't override these. Michael -Brett ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Choosing a best practice solution for Python/extension modules
On Fri, Feb 20, 2009, Brett Cannon wrote: On Fri, Feb 20, 2009 at 12:37, Brett Cannon br...@python.org wrote: On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach dan...@stutzbachenterprises.com wrote: A slight change would make it work for modules where only key functions have been rewritten. For example, pickle.py could read: from _pypickle import * try: from _pickle import * except ImportError: pass True, although that still suffers from the problem of overwriting things like __name__, __file__, etc. Actually, I take that back; the IMPORT_STAR opcode doesn't pull in anything starting with an underscore. So while this alleviates the worry above, it does mean that anything that gets rewritten needs to have a name that does not lead with an underscore for this to work. Is that really an acceptable compromise for a simple solution like this? Doesn't __all__ control this? -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ 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] Choosing a best practice solution for Python/extensionmodules
I don't have a particular solution mind. Just wanted to reframe the question to be a more general one about the controlling the selection between near equivalent modules and extensions. Some variant of the problem seems to come-up in many different contexts. No one best practice has emerged as dominant. - Original Message - From: Brett Cannon To: Raymond Hettinger Cc: Python Dev Sent: Friday, February 20, 2009 12:41 PM Subject: Re: [Python-Dev] Choosing a best practice solution for Python/extensionmodules On Fri, Feb 20, 2009 at 12:33, Raymond Hettinger pyt...@rcn.com wrote: [Brett] With io getting rewritten as an extension module, I think it's time to try to come up with a good best practice scenario for how to be able to control when a module uses a pure Python implementation and when it uses extension module optimizations. This is really only important for testing as if the extension is missing then the pure Python version is just flat-out used. There is also need in some modules where the two are not exactly equivalent or where there are multiple C extensions to choose from. In PyYAML, there needs to be an easier way to switch parsers and emitters (i.e. LibYAML). There are similar issues with xmlrpclib with the choice of parsers, marshallers, and unmarshallers. Possibly, the same mechanism can offer the user more control over which dbm is used when there are several choices. So are you saying you want something that takes multiple arguments like ``use_extension(py_name, *ext_names)``? Or are you wanting to go down the road of modules needing to define their own functions to use or unwind changes? -Brett ___ 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] IO implementation: in C and Python?
Steven D'Aprano wrote: Currently, if I want to verify that (say) cFoo and Foo do the same thing, or compare their speed, it's easy because I can import the modules separately. Also, won't foo.py be wasting time in most cases by defining python versions that get overwritten? Instead of defining things directly in foo.py, maybe it should do try: from cFoo import * except ImportError: from pyFoo import * Then the fast path will be taken if cFoo is available, and you can directly import cFoo or pyFoo if you want. -- 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] Attention Bazaar mirror users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 20, 2009, at 10:09 AM, Barry Warsaw wrote: I've just upgraded the Bazaar mirrors on code.python.org to use bzr 1.12. We now have the opportunity to upgrade the repository format for better performance. Because of the bzr-svn requirement, we need a rich root format. Upgrading to 1.9-rich-root could buy us some significant performance improvements, but it will require all clients to upgrade to at least bzr 1.9, which was released on November 7, 2008. I would like to do this upgrade. If you are currently using the Bazaar mirrors at code.python.org and upgrading your client to at least bzr 1.9 would be a hardship, please contact me. If I don't hear any objections by say Tuesday, I'll go ahead and do the repo upgrades. Adam Olsen reminds me that bzr 1.9 won't be supported by default in Ubuntu until Jaunty in April and Thomas reminds me that Debian still just has 1.5. In both those cases, you can use the PPA: https://launchpad.net/~bzr/+archive/ppa For Ubuntu machines, pick the distro version that's most appropriate. For Debian lenny, I use the Hardy PPA which seems to work fine. Gentoo gives me 1.12 and MacPorts gives me 1.11. I can't check any other distros. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSZ8ewnEjvBPtnXfVAQLTEgP+IF8j1UJNqOt1uZ8L5QO+63tcwFdJ3z0X k5ZJg3mJgMVdXMnYSgnO6fBC7R7/zVHFo++cNoitVk1++N+PqdPjGaZkD/4/Yu/I gnUuEnS6aTU9at9rhrLXc310Qs8N9JmKOn9LWie2gCMOyiW/E95mMpH95Ze2jNrR 97p+uBzxtlQ= =wdPZ -END PGP SIGNATURE- ___ 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] Choosing a best practice solution for Python/extension modules
On Fri, Feb 20, 2009 at 12:53, Aahz a...@pythoncraft.com wrote: On Fri, Feb 20, 2009, Brett Cannon wrote: On Fri, Feb 20, 2009 at 12:37, Brett Cannon br...@python.org wrote: On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach dan...@stutzbachenterprises.com wrote: A slight change would make it work for modules where only key functions have been rewritten. For example, pickle.py could read: from _pypickle import * try: from _pickle import * except ImportError: pass True, although that still suffers from the problem of overwriting things like __name__, __file__, etc. Actually, I take that back; the IMPORT_STAR opcode doesn't pull in anything starting with an underscore. So while this alleviates the worry above, it does mean that anything that gets rewritten needs to have a name that does not lead with an underscore for this to work. Is that really an acceptable compromise for a simple solution like this? Doesn't __all__ control this? If you define it, yes. But there is another issue with this: the pure Python code will never call the extension code because the globals will be bound to _pypickle and not _pickle. So if you have something like:: # _pypickle def A(): return _B() def _B(): return -13 # _pickle def _B(): return 42 # pickle from _pypickle import * try: from _pickle import * except ImportError: pass If you import pickle and call pickle.A() you will get -13 which is not what you are after. -Brett ___ 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] Choosing a best practice solution for Python/extension modules
Brett Cannon wrote: So while this alleviates the worry above, it does mean that anything that gets rewritten needs to have a name that does not lead with an underscore for this to work. You can use an __all__ list to explicitly say what is to be exported. -- 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] IO implementation: in C and Python?
On Fri, Feb 20, 2009 at 13:15, Greg Ewing greg.ew...@canterbury.ac.nzwrote: Steven D'Aprano wrote: Currently, if I want to verify that (say) cFoo and Foo do the same thing, or compare their speed, it's easy because I can import the modules separately. Also, won't foo.py be wasting time in most cases by defining python versions that get overwritten? But that's only at import time and that is rather minor compared to other execution costs. Instead of defining things directly in foo.py, maybe it should do try: from cFoo import * except ImportError: from pyFoo import * Then the fast path will be taken if cFoo is available, and you can directly import cFoo or pyFoo if you want. See the other thread I started on discussing best practices for this, but this won't work for modules where only part of the implementation has an optimized version in an extension module (e.g. pickle). -Brett ___ 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] Seeming unintended difference between list comprehensions and generator expressions...
Recently I found the need to generate some constants inside a class
body. What I discovered was a bit unintuitive, and may not be
intended...
In 2.5 and 2.6:
class foo:
... x = {}
... x.update((i, x.get(i, None)) for i in xrange(10))
...
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 3, in foo
File stdin, line 3, in genexpr
NameError: global name 'x' is not defined
class foo:
... x = {}
... x.update([(i, x.get(i, None)) for i in xrange(10)])
...
In 3.0:
class foo():
... x = {}
... x.update((i, x.get(i, None)) for i in range(10))
...
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 3, in foo
File stdin, line 3, in genexpr
NameError: global name 'x' is not defined
class foo():
... x = {}
... x.update([(i, x.get(i, None)) for i in range(10)])
...
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 3, in foo
File stdin, line 3, in listcomp
NameError: global name 'x' is not defined
The behavior of 3.0 WRT list comprehensions behaving the same way as
generator expressions is expected, but why generator expressions
(generally) don't keep a reference to the class scope during execution
seems to be unintended.
- 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] Seeming unintended difference between list comprehensions and generator expressions...
Josiah Carlson wrote:
The behavior of 3.0 WRT list comprehensions behaving the same way as
generator expressions is expected, but why generator expressions
(generally) don't keep a reference to the class scope during execution
seems to be unintended.
It's intended. While arguably not ideal, it would require some pretty
major changes to the lexical scoping rules to make them behave any
differently.
The translation of (i*i for i in x) is conceptually along the lines of:
def _ge(arg):
for i in arg:
yield i*i
expr_value = _ge(x)
Similarly, a 3.x list comprehension [i*i for i in x] is very roughly
translated as:
def _lc(arg):
result = []
for i in arg:
result.append(i*i)
return result
expr_value = _lc(x)
Like any function scope inside a class namespace, the body of a genexp
(and, in 3.x, comprehension) doesn't have direct access to the class
namespace because classes don't play any part in the lexical scoping rules.
Basically, if a generator or 3.x comprehension needs access to a value
from a containing class scope anywhere other than the outermost
iterator, then it needs to be put into a temporary function and given
the extra value as an argument:
. class C:
... x = {}
... def _init_constants(d, itr):
... d.update((i, d.get(i, None)) for i in itr)
... _init_constants(x, range(10))
... del _init_constants
...
. C.x
{0: None, 1: None, 2: None, 3: None, 4: None, 5: None, 6: None, 7: None,
8: None, 9: None}
(in this toy case, of course, it would be simpler to make the temporary
function create and return the constants dictionary, but the above
approach with multiple arguments being passed in applies more generally
when you need to access multiple existing values from the class scope)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
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] Choosing a best practice solution for Python/extension modules
Brett Cannon wrote: But there is another issue with this: the pure Python code will never call the extension code because the globals will be bound to _pypickle and not _pickle. So if you have something like:: # _pypickle def A(): return _B() def _B(): return -13 # _pickle def _B(): return 42 # pickle from _pypickle import * try: from _pickle import * except ImportError: pass If you import pickle and call pickle.A() you will get -13 which is not what you are after. Ah, you may want to think about that a bit more. There's a reason globals are looked up when they're used rather than when their function is defined. Even in your own example, _B isn't defined at all when you define A. There is a (real) related problem whereby the Python version will *use* it's own globals if it actually tries to call any functions during the import, but that's a problem shared by any overwrite at the end of import approach to swapping in extension module versions of functions. With appropriate __all__ definitions in the C extension modules, I don't see anything wrong with Daniel's suggested approach. Note also that with this approach _io.__all__ will give the details of what has been overridden by the extension module, so it even still provides a decent level of introspection support. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Choosing a best practice solution for Python/extension modules
On Fri, Feb 20, 2009 at 5:27 PM, Nick Coghlan ncogh...@gmail.com wrote: Brett Cannon wrote: If you import pickle and call pickle.A() you will get -13 which is not what you are after. Ah, you may want to think about that a bit more. There's a reason globals are looked up when they're used rather than when their function is defined. Even in your own example, _B isn't defined at all when you define A. No, I'm afraid Brett is quite right. Globals are looked up when the function is executed, true, but they are looked up within the module that defined the function. Functions defined in _pypickle would only call the _pypickle version of functions. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ 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] Choosing a best practice solution for Python/extension modules
Daniel Stutzbach wrote: On Fri, Feb 20, 2009 at 5:27 PM, Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: Brett Cannon wrote: If you import pickle and call pickle.A() you will get -13 which is not what you are after. Ah, you may want to think about that a bit more. There's a reason globals are looked up when they're used rather than when their function is defined. Even in your own example, _B isn't defined at all when you define A. No, I'm afraid Brett is quite right. Globals are looked up when the function is executed, true, but they are looked up within the module that defined the function. Functions defined in _pypickle would only call the _pypickle version of functions. Oh, I see what you mean now. Looks like Brett's tracked substitution may be the way to go then. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Seeming unintended difference between list comprehensions and generator expressions...
On Fri, Feb 20, 2009 at 3:14 PM, Nick Coghlan ncogh...@gmail.com wrote:
Josiah Carlson wrote:
The behavior of 3.0 WRT list comprehensions behaving the same way as
generator expressions is expected, but why generator expressions
(generally) don't keep a reference to the class scope during execution
seems to be unintended.
It's intended. While arguably not ideal, it would require some pretty
major changes to the lexical scoping rules to make them behave any
differently.
The translation of (i*i for i in x) is conceptually along the lines of:
def _ge(arg):
for i in arg:
yield i*i
expr_value = _ge(x)
Similarly, a 3.x list comprehension [i*i for i in x] is very roughly
translated as:
def _lc(arg):
result = []
for i in arg:
result.append(i*i)
return result
expr_value = _lc(x)
I was under the impression that in 3.x, it was equivalent to
list(genexp) . Which would explain the difference between 2.6 and
3.0.
Like any function scope inside a class namespace, the body of a genexp
(and, in 3.x, comprehension) doesn't have direct access to the class
namespace because classes don't play any part in the lexical scoping rules.
Indeed, though I had thought (if only briefly ;) ) that when executing
non-definitions in the class body, it would behave similar to the a
more or less equivalent function-based class factory
def make_class(*bases):
... def make_class(fcn):
... dict = fcn()
... return type(object)(fcn.__name__, bases, dict)
... return make_class
...
@make_class(object)
... def foo():
... x = {}
... x.update((i, x.get(i, None)) for i in xrange(10))
... return locals()
...
foo
class '__main__.foo'
foo.x
{0: None, 1: None, 2: None, 3: None, 4: None, 5: None, 6: None, 7:
None, 8: None, 9: None}
But I was wrong ;)
Thank you for the help :)
- Josiah
Basically, if a generator or 3.x comprehension needs access to a value
from a containing class scope anywhere other than the outermost
iterator, then it needs to be put into a temporary function and given
the extra value as an argument:
. class C:
... x = {}
... def _init_constants(d, itr):
... d.update((i, d.get(i, None)) for i in itr)
... _init_constants(x, range(10))
... del _init_constants
...
. C.x
{0: None, 1: None, 2: None, 3: None, 4: None, 5: None, 6: None, 7: None,
8: None, 9: None}
(in this toy case, of course, it would be simpler to make the temporary
function create and return the constants dictionary, but the above
approach with multiple arguments being passed in applies more generally
when you need to access multiple existing values from the class scope)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
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] IO implementation: in C and Python?
Greg Ewing wrote: Instead of defining things directly in foo.py, maybe it should do try: from cFoo import * except ImportError: from pyFoo import * Then the fast path will be taken if cFoo is available, and you can directly import cFoo or pyFoo if you want. For what it's worth, I like that naming convention better than the current conventions Foo/cFoo, Foo/_Foo. -- 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] Seeming unintended difference between list comprehensions and generator expressions...
Josiah Carlson wrote: Similarly, a 3.x list comprehension [i*i for i in x] is very roughly translated as: def _lc(arg): result = [] for i in arg: result.append(i*i) return result expr_value = _lc(x) I was under the impression that in 3.x, it was equivalent to list(genexp) . Which would explain the difference between 2.6 and 3.0. Semantically, the two translations end up being the same. Actually *implementing* it that way turned out to be unnecessarily slow: the comprehensions instead create a normal function that builds the desired type of object (list/set/dict) incrementally rather than building a generator function and invoking it. The speed increase comes from being able to skip the generator resume/yield overhead on each iteration. Like any function scope inside a class namespace, the body of a genexp (and, in 3.x, comprehension) doesn't have direct access to the class namespace because classes don't play any part in the lexical scoping rules. Indeed, though I had thought (if only briefly ;) ) that when executing non-definitions in the class body, it would behave similar to the a more or less equivalent function-based class factory I think there may be a section of the language reference that describes it in those terms. If there is, it should probably be changed, since it gives misleading ideas about how the scoping works. Execution of a class body is actually a bit more like using an exec statement than it is like an implicit function definition. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Attention Bazaar mirror users
On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw ba...@python.org wrote: Adam Olsen reminds me that bzr 1.9 won't be supported by default in Ubuntu until Jaunty in April and Thomas reminds me that Debian still just has 1.5. In both those cases, you can use the PPA: https://launchpad.net/~bzr/+archive/ppa Please note that for many people in a corporate/university environment, this is not an option. Granted, you can install it by yourself at this point, David ___ 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] A suggestion: Do proto-PEPs in Google Docs
Summary: Google Docs is easy to use, featureful, and here now. Since AIUI the PEPs eventually need to be hosted at python.org, I see Google Docs as an immediate replacement for email transmission of early drafts of PEPs, not as a permanent solution to PEP storage. William Dode writes: Isn't it the good oportunity to try a DVCS ? I thought about that (and if I agreed I wouldn't have posted), but there are reasons why Guido is looking forward to rather than calling for volunteers. ISTM that a DVCS is just a wiki where you can't find stuff unless you're told where it is. It will take time. What Google Docs provided for me was an infrastructure that accomplished several useful services automatically, and stayed out of my face (except for the lack of pruning of uninteresting revisions). IMO the features we want are (1) a permanent, easily computed URN for the draft document repo -- DVCS can do this, with straightforward support from python.org -- wiki can do this as a convention such as reserving PEP_0374 for final doc with PEP_0374_draft for development (2) editor control over access to individual documents -- AFAIK there's no mechanism for this at python.org, so to use a DVCS would require developing one -- no mechanism for this in most wikis AFAIK (but ZWiki can do it) -- it could be argued that the current convention of people staying out of each others' space would work, but what about non-committers (like me)? (3) automatic merging of concurrent work -- DVCS does this, but needs to be pushed afterward -- most wikis can't do this in the framework of a single document, but you could organize the doc by sections for drafting (4) automatic saves of intermediate work -- at the tweak stage, the effort to save, commit, and push to a DVCS outweighs the effort to tweak, costing a lot of polish IME -- wikis don't do this, and I wonder whether people would be willing to save unpolished work, or leave it sitting in the browser until later (5) a recorded out of band channel for the editors (when plural) to comment -- XXX can work but when it's scutwork (eg, researching URLs or reworking sections to have parallel organization) it's ugly and distracting for non-editors to read; DVCS by itself provides no such medium, one would need to be developed -- ditto wikis (although Wikipedia has its linked discussion channels, and this could be emulated on any wiki by a convention such as PEP_0374_talk, which would have the advantage that interested non-editors could look at the comments and contribute URLs and ideas, etc) -- for non-trivial work, mail/IRC doesn't really cut it; you're more likely to make the indicated tweak if you're working on the document anyway, mail/IRC is likely to be focused elsewhere and the cost of changing focus too high to do it *now* (1) and (2) are obvious, I think, and I don't know how much (3) really matters when the editors are a small group. But I was surprised by how much (4), and (5) contributed to my experience working on PEP 0374. Maybe Brett, Barry, or Alexandre would like to comment? I note that the FSF had a rather complex system for its collaborative development of 3d generation licenses. I don't think that's necessary for most PEPs. ___ 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] Choosing a best practice solution for Python/extension modules
Daniel Stutzbach wrote: No, I'm afraid Brett is quite right. Globals are looked up when the function is executed, true, but they are looked up within the module that defined the function. I was thinking you could fix that by going over the imported functions and stuffing the current globals into their func_globals, but unfortunately it's read-only. :-( f.func_globals = g Traceback (most recent call last): File stdin, line 1, in module TypeError: readonly attribute Is there a reason it couldn't be made writeable? -- 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] A suggestion: Do proto-PEPs in Google Docs
On Sat, 21 Feb 2009 at 12:56, Stephen J. Turnbull wrote: (4) automatic saves of intermediate work -- at the tweak stage, the effort to save, commit, and push to a DVCS outweighs the effort to tweak, costing a lot of polish IME -- wikis don't do this, and I wonder whether people would be willing to save unpolished work, or leave it sitting in the browser until later Not that I'm expecting to be working on PEPs any time soon, but just as a different perspective, I would find the effort to open up Google docs to be a much higher barrier to doing some editing tweaks than the dvcs case. For the DVCS, I'd just write a little script that would (1) update (2) open the editor on the file (3) do the commit/push dance when the file was closed. So for me it would be as easy as editing the file locally. So for my work style, a DVCS would be the biggest win. --RDM ___ 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] A suggestion: Do proto-PEPs in Google Docs
Not that I'm expecting to be working on PEPs any time soon, but just as a different perspective, I would find the effort to open up Google docs to be a much higher barrier to doing some editing tweaks than the dvcs case. For the DVCS, I'd just write a little script that would (1) update (2) open the editor on the file (3) do the commit/push dance when the file was closed. So for me it would be as easy as editing the file locally. So for my work style, a DVCS would be the biggest win. --RDM That's funny because I would expect that for most people it's the exact opposite... just create a gmail account... boom, done... I'm not necessarily advocating that but just saying that IMO, most people will find google docs to be the fastest and easiest solution. -- Haikus are easy Most make very little sense Refrigerator ___ 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] Attention Bazaar mirror users
David Cournapeau writes: On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw ba...@python.org wrote: In both those cases, you can use the PPA: Please note that for many people in a corporate/university environment, this is not an option. Granted, you can install it by yourself at this point, Er, what are people without access to PPAs doing building Python from a VCS checkout? Surely this is not a problem. ___ 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] Attention Bazaar mirror users
On Sat, Feb 21, 2009 at 3:52 PM, Stephen J. Turnbull step...@xemacs.org wrote: David Cournapeau writes: On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw ba...@python.org wrote: In both those cases, you can use the PPA: Please note that for many people in a corporate/university environment, this is not an option. Granted, you can install it by yourself at this point, Er, what are people without access to PPAs doing building Python from a VCS checkout? I don't see the link between access to PPA and building Python from sources. I don't have administration privileges on any of my machine at work. Adding PPA is simply not allowed at some places (PPA or anything else which is not considered 'safe'), or too much of a (bureaucratic) burden. cheers, David ___ 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
