[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-10-21 - 2011-10-28) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3108 (+13) closed 21961 (+34) total 25069 (+47) Open issues with patches: 1324 Issues opened (33) == #10278: add time.wallclock() method http://bugs.python.org/issue10278 reopened by haypo #13241: llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) http://bugs.python.org/issue13241 opened by Oleg.Plakhotnyuk #13244: WebSocket schemes in urllib.parse http://bugs.python.org/issue13244 opened by oberstet #13245: sched.py kwargs addition and default time functions http://bugs.python.org/issue13245 opened by clach04 #13246: Py_UCS4_strlen and friends needn't be public http://bugs.python.org/issue13246 opened by pitrou #13247: os.path.abspath returns unicode paths as question marks http://bugs.python.org/issue13247 opened by ubershmekel #13248: deprecated in 3.2, should be removed in 3.3 http://bugs.python.org/issue13248 opened by flox #13249: argparse.ArgumentParser() lists arguments in the wrong order http://bugs.python.org/issue13249 opened by roysmith #13252: new decumulate() function in itertools module http://bugs.python.org/issue13252 opened by carlo.verre #13253: 2to3 fix_renames renames sys.maxint only in imports http://bugs.python.org/issue13253 opened by ezio.melotti #13254: maildir.items() broken http://bugs.python.org/issue13254 opened by marco.ghidinelli #13256: Document and test new socket options http://bugs.python.org/issue13256 opened by haypo #13257: Move importlib over to PEP 3151 exceptions http://bugs.python.org/issue13257 opened by brett.cannon #13262: IDLE opens partially hidden http://bugs.python.org/issue13262 opened by Aivar.Annamaa #13263: Group some os functions in submodules http://bugs.python.org/issue13263 opened by ezio.melotti #13264: Monkeypatching using metaclass http://bugs.python.org/issue13264 opened by Artem.Tomilov #13265: IDLE crashes when printing some unprintable characters. http://bugs.python.org/issue13265 opened by maniram.maniram #13266: Add inspect.unwrap(f) to easily unravel __wrapped__ chains http://bugs.python.org/issue13266 opened by ncoghlan #13271: When -h is used with argparse, default values that fail should http://bugs.python.org/issue13271 opened by Joshua.Chia #13272: 2to3 fix_renames doesn't rename string.lowercase/uppercase/let http://bugs.python.org/issue13272 opened by ezio.melotti #13274: heapq pure python version uses islice without guarding for neg http://bugs.python.org/issue13274 opened by Ronny.Pfannschmidt #13275: Recommend xml.etree for XML processing http://bugs.python.org/issue13275 opened by ash #13276: distutils bdist_wininst created installer does not run the pos http://bugs.python.org/issue13276 opened by francisco #13277: tzinfo subclasses information http://bugs.python.org/issue13277 opened by orsenthil #13279: Add memcmp into unicode_compare for optimizing comparisons http://bugs.python.org/issue13279 opened by RichIsMyName #13280: argparse should use the new Formatter class http://bugs.python.org/issue13280 opened by poke #13281: robotparser.RobotFileParser ignores rules preceeded by a blank http://bugs.python.org/issue13281 opened by bernie9998 #13282: the table of contents in epub file is too long http://bugs.python.org/issue13282 opened by wrobell #13283: removal of two unused variable in locale.py http://bugs.python.org/issue13283 opened by nicoe #13284: email.utils.formatdate function does not handle timezones corr http://bugs.python.org/issue13284 opened by burak.arslan #13285: signal module ignores external signal changes http://bugs.python.org/issue13285 opened by vilya #13286: PEP 3151 breaks backward compatibility: it should be documente http://bugs.python.org/issue13286 opened by haypo #13287: urllib.request exposes too many names http://bugs.python.org/issue13287 opened by flox Most recent 15 issues with no replies (15) == #13283: removal of two unused variable in locale.py http://bugs.python.org/issue13283 #13282: the table of contents in epub file is too long http://bugs.python.org/issue13282 #13277: tzinfo subclasses information http://bugs.python.org/issue13277 #13276: distutils bdist_wininst created installer does not run the pos http://bugs.python.org/issue13276 #13272: 2to3 fix_renames doesn't rename string.lowercase/uppercase/let http://bugs.python.org/issue13272 #13262: IDLE opens partially hidden http://bugs.python.org/issue13262 #13257: Move importlib over to PEP 3151 exceptions http://bugs.python.org/issue13257 #13231: sys.settrace - document 'some other code blocks' for 'call' ev http://bugs.python.org/issue13231 #13229: Add shutil.filter_walk http://bugs.python.org/issue13229 #13217: Missing header dependencies in Makefile
[Python-Dev] draft PEP: virtual environments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello python-dev, As has been discussed here previously, Vinay Sajip and I are working on a PEP for making virtual Python environments a la virtualenv [1] a built-in feature of Python 3.3. This idea was first proposed on python-dev by Ian Bicking in February 2010 [2]. It was revived at PyCon 2011 and has seen discussion on distutils-sig [3], more recently again on python-dev [4] [5], and most recently on python-ideas [6]. Full text of the draft PEP is pasted below, and also available on Bitbucket [7]. The reference implementation is also on Bitbucket [8]. For known issues in the reference implementation and cases where it does not yet match the PEP, see the open issues list [9]. In particular, please note the Open Questions section of the draft PEP. These are areas where we are still unsure of the best approach, or where we've received conflicting feedback and haven't reached consensus. We welcome your thoughts on anything in the PEP, but feedback on the open questions is especially useful. We'd also especially like to hear from Windows and OSX users, from authors of packaging-related tools (packaging/distutils2, zc.buildout) and from Python implementors (PyPy, IronPython, Jython). If it is easier to review and comment on the PEP after it is published on python.org, I can submit it to the PEP editors anytime. Otherwise I'll wait until we've resolved a few more of the open questions, as it's easier for me to update the PEP on Bitbucket. Thanks! Carl [1] http://virtualenv.org [2] http://mail.python.org/pipermail/python-dev/2010-February/097787.html [3] http://mail.python.org/pipermail/distutils-sig/2011-March/017498.html [4] http://mail.python.org/pipermail/python-dev/2011-June/111903.html [5] http://mail.python.org/pipermail/python-dev/2011-October/113883.html [6] http://mail.python.org/pipermail/python-ideas/2011-October/012500.html [7] https://bitbucket.org/carljm/pythonv-pep/src/ [8] https://bitbucket.org/vinay.sajip/pythonv/ [9] https://bitbucket.org/vinay.sajip/pythonv/issues?status=newstatus=open PEP: XXX Title: Python Virtual Environments Version: $Revision$ Last-Modified: $Date$ Author: Carl Meyer c...@oddbird.net Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Jun-2011 Python-Version: 3.3 Post-History: 24-Oct-2011, 28-Oct-2011 Abstract This PEP proposes to add to Python a mechanism for lightweight virtual environments with their own site directories, optionally isolated from system site directories. Each virtual environment has its own Python binary (allowing creation of environments with various Python versions) and can have its own independent set of installed Python packages in its site directories, but shares the standard library with the base installed Python. Motivation == The utility of Python virtual environments has already been well established by the popularity of existing third-party virtual-environment tools, primarily Ian Bicking's `virtualenv`_. Virtual environments are already widely used for dependency management and isolation, ease of installing and using Python packages without system-administrator access, and automated testing of Python software across multiple Python versions, among other uses. Existing virtual environment tools suffer from lack of support from the behavior of Python itself. Tools such as `rvirtualenv`_, which do not copy the Python binary into the virtual environment, cannot provide reliable isolation from system site directories. Virtualenv, which does copy the Python binary, is forced to duplicate much of Python's ``site`` module and manually symlink/copy an ever-changing set of standard-library modules into the virtual environment in order to perform a delicate boot-strapping dance at every startup. (Virtualenv copies the binary because symlinking it does not provide isolation, as Python dereferences a symlinked executable before searching for `sys.prefix`.) The ``PYTHONHOME`` environment variable, Python's only existing built-in solution for virtual environments, requires copying/symlinking the entire standard library into every environment. Copying the whole standard library is not a lightweight solution, and cross-platform support for symlinks remains inconsistent (even on Windows platforms that do support them, creating them often requires administrator privileges). A virtual environment mechanism integrated with Python and drawing on years of experience with existing third-party tools can be lower maintenance, more reliable, and more easily available to all Python users. .. _virtualenv: http://www.virtualenv.org .. _rvirtualenv: https://github.com/kvbik/rvirtualenv Specification = When the Python binary is executed, it attempts to determine its prefix (which it stores in ``sys.prefix``), which is then used to find the standard library and other key files, and by the ``site`` module to determine the location of the
[Python-Dev] Emit a BytesWarning on bytes filenames on Windows
Hi, I am not more conviced that raising a UnicodeEncodeError on unencodable characters is the right fix for the issue #13247. The problem with this solution is that you have to wait until an user get a UnicodeEncodeError. I have yet another proposition: emit a warning when a bytes filename is used. So it doesn't affect the default behaviour, but you can use -Werror to test if your program is fully Unicode compliant on Windows (without having to test invalid filenames). I don't know if a BytesWarning or a DeprecationWarning is more apropriate. It depends if we plan to drop support of bytes filenames on Windows later (in Python 3.5 or later). List of impacted functions: os._getfinalpathname(bytes) os._getfullpathname(bytes) os._isdir(bytes) os.access(bytes) os.chdir(bytes) os.chmod(bytes) os.getcwdb() os.link(bytes, bytes) os.listdir(bytes) os.lstat(bytes) os.mkdir(bytes) os.readlink(bytes) os.rename(bytes, bytes) os.rmdir(bytes) os.stat(bytes) os.symlink(bytes, bytes) os.unlink(bytes) os.utime(bytes, time) Note: Unicode filenames are not affected by this change. For example, os.listdir(str) will not emit any warning. Victor ___ 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] draft PEP: virtual environments
This is really very comprehensive, thank you! Why not modify sys.prefix? - -- As discussed above under `Backwards Compatibility`_, this PEP proposes to add ``sys.site_prefix`` as the prefix relative to which site-package directories are found. This maintains compatibility with the documented meaning of ``sys.prefix`` (as the location relative to which the standard library can be found), but means that code assuming that site-packages directories are found relative to ``sys.prefix`` will not respect the virtual environment correctly. Since it is unable to modify ``distutils``/``sysconfig``, `virtualenv`_ is forced to instead re-point ``sys.prefix`` at the virtual environment. An argument could be made that this PEP should follow virtualenv's lead here (and introduce something like ``sys.base_prefix`` to point to the standard library and header files), since virtualenv already does this and it doesn't appear to have caused major problems with existing code. Another argument in favor of this is that it would be preferable to err on the side of greater, rather than lesser, isolation. Changing ``sys.prefix`` to point to the virtual environment and introducing a new ``sys.base_prefix`` attribute would err on the side of greater isolation in the face of existing code's use of ``sys.prefix``. It would seem to make sense to me to err on the side of greater isolation, introducing sys.base_prefix to indicate the base prefix (as opposed to sys.site_prefix indicating the venv prefix). Bugs introduced via a semi-isolated virtual environment are very difficult to troubleshoot. It would also make changes to existing code unnecessary. I have encountered no issues with virtualenv doing this so far. - C ___ 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] draft PEP: virtual environments
On Sat, Oct 29, 2011 at 4:37 AM, Carl Meyer c...@oddbird.net wrote: If it is easier to review and comment on the PEP after it is published on python.org, I can submit it to the PEP editors anytime. Otherwise I'll wait until we've resolved a few more of the open questions, as it's easier for me to update the PEP on Bitbucket. It's best to get it posted, firstly so it has an assigned PEP number (although some may argue having to call it the virtualenv PEP is a feature!), secondly so that it's easy for people to get hold of a formatted version. All the core committers can actually publish PEPs via the PEP hg repo, so Vinay could probably handle pushing the updates to python.org. Submission via the PEP editors is mainly there as a backstop for cases where there's no current core dev directly involved in the PEP. 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] Emit a BytesWarning on bytes filenames on Windows
On 29/10/2011 9:52 AM, Victor Stinner wrote: Hi, I am not more conviced that raising a UnicodeEncodeError on unencodable characters is the right fix for the issue #13247. The problem with this solution is that you have to wait until an user get a UnicodeEncodeError. I have yet another proposition: emit a warning when a bytes filename is used. So it doesn't affect the default behaviour, but you can use -Werror to test if your program is fully Unicode compliant on Windows (without having to test invalid filenames). I don't know if a BytesWarning or a DeprecationWarning is more apropriate. It depends if we plan to drop support of bytes filenames on Windows later (in Python 3.5 or later). When previously discussing this issue, I was under the impression that the problem was unencodable bytes passed from the Python code to Windows - but the reverse is true - only the data coming back from Windows isn't encodable. This changes my opinion significantly :) I don't think raising an error is the right choice - there are almost certainly use-cases where the current behaviour works OK and we would break them (eg, not all files in a directory are likely to be unencodable). As the data came externally, the only solution the programmer has is to change to the unicode version of the api - so we recommend the bytes version not be used by anyone, anytime - which means it is conceptually deprecated already. Therefore, as you imply, I think the solution to this issue is to start the process of deprecating the bytes version of the api in py3k with a view to removing it completely - possibly with a less aggressive timeline than normal. In Python 2.7, I think documenting the issue and a recommendation to always use unicode is sufficient (ie, we can't deprecate it and a new BytesWarning seems gratuitous.) Cheers, Mark ___ 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
