[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-04-02 - 2010-04-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. 2639 open (+37) / 17538 closed (+30) / 20177 total (+67) Open issues with patches: 1072 Average duration of open issues: 728 days. Median duration of open issues: 489 days. Open Issues Breakdown open 2599 (+37) languishing 7 ( +0) pending32 ( +0) Issues Created Or Reopened (71) ___ Add environment variable $PYTHONWARNINGS 2010-04-07 http://bugs.python.org/issue7301reopened pjenvey patch, needs review patch: BaseHTTPServer reinventing rfc822 date formatting 2010-04-09 http://bugs.python.org/issue7370reopened r.david.murray patch test_py3kwarn fails when running the whole test suite 2010-04-03 http://bugs.python.org/issue7772reopened mark.dickinson patch Documentation of math.pow, math.hypot, and complex.__abs__ 2010-04-06 http://bugs.python.org/issue7947reopened mark.dickinson patch i have a doubt with using __init__ and .self and classes 2010-04-02 CLOSED http://bugs.python.org/issue8291created krishnalolla Incorrect condition test in platform.py2010-04-02 http://bugs.python.org/issue8292created akuchling patch, easy HTTPSConnection.close() does not immediately close the connect 2010-04-02 http://bugs.python.org/issue8293created dandrzejewski Allow Fraction constructor to accept float and decimal instanc 2010-04-02 CLOSED http://bugs.python.org/issue8294created mark.dickinson patch add unpack_archive to shutil 2010-04-02 http://bugs.python.org/issue8295created tarek multiprocessing.Pool hangs when issuing KeyboardInterrupt 2010-04-03 http://bugs.python.org/issue8296created vlasovskikh patch AttributeError message text should include module name 2010-04-03 http://bugs.python.org/issue8297created cjerdonek patch in what way we have to save tha module?2010-04-03 CLOSED http://bugs.python.org/issue8298created krishnalolla Improve GIL in 2.7 2010-04-03 http://bugs.python.org/issue8299created krisvale patch, patch Allow struct.pack to handle objects with an __index__ method. 2010-04-03 CLOSED http://bugs.python.org/issue8300created mark.dickinson patch Putting a function in a unittest.TestSuite doesn't work2010-04-03 http://bugs.python.org/issue8301created michael.foord SkipTest exception in setUpClass or setUpModule is marked as a 2010-04-03 http://bugs.python.org/issue8302created michael.foord python -m unittest -h and python -m unittest discover -h messa 2010-04-03 http://bugs.python.org/issue8303created michael.foord strftime and Unicode characters2010-04-03 http://bugs.python.org/issue8304created AndiDog memoview[0] creates an invalid view if ndim != 1 2010-04-03 ht
[Python-Dev] PEP 3147, __cached__, and PyImport_ExecCodeModuleEx()
I've run into a minor snag implementing the __cached__ attribute on imported modules. From PEP 3147: As part of this PEP, we will add an `__cached__` attribute to modules, which will always point to the actual `pyc` file that was read or written. When the environment variable `$PYTHONDONTWRITEBYTECODE` is set, or the `-B` option is given, or if the source lives on a read-only filesystem, then the `__cached__` attribute will point to the location that the `pyc` file *would* have been written to if it didn't exist. This location of course includes the `__pycache__` subdirectory in its path. The right place to add this seems to be PyImport_ExecCodeModuleEx(), which passes in a `pathname` argument. This function is not documented in the C API reference manual and about the only place where it's described is Misc/HISTORY: - New function PyImport_ExecCodeModuleEx(), which extends PyImport_ExecCodeModule() by adding an extra parameter to pass it the true file. The "true file" can either be the source .py file, the legacy .pyc file, or the PEP 3147 .pyc file depending on the circumstances. The caller knows which it is, but that function itself doesn't. I've tentatively worked out some code that lets it guess, but it's a kludge, it's ugly and I don't like it. I think the right fix is to extend PyImport_ExecCodeModuleEx() to also pass in the pathname for __cached__ (or NULL if None is appropriate). It bothers me a little to change this API, but OTOH, it's an *undocumented* API, so I don't feel too badly. ;) Since this is one of the last things to implement for PEP 3147, I thought I'd ask and see if anybody had any better suggestions. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147, __cached__, and PyImport_ExecCodeModuleEx()
It may be undocumented but it doesn't start with _ and it exists to preserve backwards compatibility. So I recommend adding PyImport_ExecCodeModuleExEx(). On Fri, Apr 9, 2010 at 1:24 PM, Barry Warsaw wrote: > I've run into a minor snag implementing the __cached__ attribute on imported > modules. From PEP 3147: > > As part of this PEP, we will add an `__cached__` attribute to modules, > which will always point to the actual `pyc` file that was read or > written. When the environment variable `$PYTHONDONTWRITEBYTECODE` is > set, or the `-B` option is given, or if the source lives on a > read-only filesystem, then the `__cached__` attribute will point to > the location that the `pyc` file *would* have been written to if it > didn't exist. This location of course includes the `__pycache__` > subdirectory in its path. > > The right place to add this seems to be PyImport_ExecCodeModuleEx(), which > passes in a `pathname` argument. This function is not documented in the C API > reference manual and about the only place where it's described is > Misc/HISTORY: > > - New function PyImport_ExecCodeModuleEx(), which extends > PyImport_ExecCodeModule() by adding an extra parameter to pass it the > true file. > > The "true file" can either be the source .py file, the legacy .pyc file, or > the PEP 3147 .pyc file depending on the circumstances. The caller knows which > it is, but that function itself doesn't. I've tentatively worked out some > code that lets it guess, but it's a kludge, it's ugly and I don't like it. I > think the right fix is to extend PyImport_ExecCodeModuleEx() to also pass in > the pathname for __cached__ (or NULL if None is appropriate). > > It bothers me a little to change this API, but OTOH, it's an *undocumented* > API, so I don't feel too badly. ;) Since this is one of the last things to > implement for PEP 3147, I thought I'd ask and see if anybody had any better > suggestions. > > -Barry > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147, __cached__, and PyImport_ExecCodeModuleEx()
On Apr 09, 2010, at 02:52 PM, Guido van Rossum wrote: >It may be undocumented but it doesn't start with _ and it exists to >preserve backwards compatibility. So I recommend adding >PyImport_ExecCodeModuleExEx(). Cool, thanks. Now I can't wait for PyImport_ExecCodeModuleExExEx() :) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147 working implementation
Patch set 4 has been uploaded to Rietveld: http://codereview.appspot.com/842043/show This includes some fixes for Windows and support for the __cached__ attribute on modules. While I need to do another pass through the PEP to make sure I've gotten everything, this code is very nearly feature complete, so it's probably worth getting Guido to pronounce on the PEP pretty soon. -Barry P.S. 'bzr branch lp:~barry/python/pep3147' signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147, __cached__, and PyImport_ExecCodeModuleEx()
On 9 April 2010 23:00, Barry Warsaw wrote: > On Apr 09, 2010, at 02:52 PM, Guido van Rossum wrote: > >>It may be undocumented but it doesn't start with _ and it exists to >>preserve backwards compatibility. So I recommend adding >>PyImport_ExecCodeModuleExEx(). > > Cool, thanks. Now I can't wait for PyImport_ExecCodeModuleExExEx() :) Would it be better to name this one _PyImport_ExecCodeModuleExEx (with an underscore) so that we *don't* need to create an ExExEx version in future? (Sorry, Barry :-)) Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147
Hello, I'm sorry to chime in a bit late about an aspect of the PEP, but I only wondered about it while reviewing your code :-) « Instead, this PEP proposes to add a mapping between internal magic numbers and a user-friendly tag. Newer versions of Python can add to this mapping so that all later Pythons know the mapping between tags and magic numbers. » The question is: why do we have to keep a mapping of past tags and magic numbers? Don't we only care about our current tag and magic number? (similarly, we don't know, and need to know, about Jython's or Pypy's stuff...). As far as I can tell, it would remove the burden of maintening an ever-growing registry of past magic numbers and tags. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147, __cached__, and PyImport_ExecCodeModuleEx()
On Fri, Apr 9, 2010 at 3:54 PM, Paul Moore wrote: > On 9 April 2010 23:00, Barry Warsaw wrote: >> On Apr 09, 2010, at 02:52 PM, Guido van Rossum wrote: >> >>>It may be undocumented but it doesn't start with _ and it exists to >>>preserve backwards compatibility. So I recommend adding >>>PyImport_ExecCodeModuleExEx(). >> >> Cool, thanks. Now I can't wait for PyImport_ExecCodeModuleExExEx() :) > > Would it be better to name this one _PyImport_ExecCodeModuleExEx (with > an underscore) so that we *don't* need to create an ExExEx version in > future? (Sorry, Barry :-)) I don't care about what name you pick, and my ExEx proposal was meant to include half a wink, but http://docs.python.org/c-api/import.html makes it clear that PyImport_ExecCodeModuleEx() is far from private! (I don't know where Barry got that idea.) While Google Code Search finds mostly references to PyImport_ExecCodeModuleEx in the Python source code and various copies of it, it also shows some real uses, e.g. http://www.google.com/codesearch/p?hl=en#bkFK9YpaWlI/ubuntu/pool/universe/y/yehia/yehia_0.5.4.orig.tar.gz|PZ0_Xf7QzC0/yehia-0.5.4.orig/plugins/python/python-loader.cc&q=PyImport_ExecCodeModuleEx -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
