Re: [Python-Dev] [Python-checkins] cpython (3.2): Nudge readers towards a more accurate mental model for loop else clauses
Note: reply-to set to python-ideas. Nick Coghlan writes: The inaccuracies in the analogy are why this is in the tutorial, not the language reference. All 3 else clauses are really their own thing. Nick, for the purpose of the tutorial, actually there are 4 else clauses: you need to distinguish *while* from *for*. It was much easier for me to get confused about *for*. I think Terry is on to something here: An else clause used with a loop has two differences from an else clause used with an if statement. [...] [The] condition is tested repeatedly instead of just once. A loop else is the same in that it triggers when that one condition is false. I think it would be a good idea to use an example where the loop is a *while* loop, not a *for* loop. In the case of the *for* loop, it's easy to confuse the implicit test used (ie, item is true) with a test on the iterable (iterable is not empty). With a *while* loop, that's not true. I don't have trouble understanding that the while suite is executed while the condition is true: for n in range(2, 10): ... x = 2 ... while x n: ... if n % x == 0: ... print(n, 'equals', x, '*', n//x) ... break ... x = x + 1 ... else: ... # loop fell through without finding a factor ... print(n, 'is a prime number') ... Of course it's useful to point out here that use of a while loop is bad style, and the for x in range(2,n) version is preferred, having *exactly the same semantics* for the *else* clause. Also, I find rewriting the if/else as if condition: do_when_true() else: do_when_false() as while condition: do_when_true() break # do only once, and skip else! else: do_when_false() to be quite mnemonic for understanding what the while/else construct really does. [The loop *else*] is subordinate to just one condition instead of possibly many. (In for statements, the condition is implicit but still there.) FWIW, this issue doesn't affect my understanding, as I think of if/elif/else as indentation-optimized tail-nested ifs anyway. I'm not sure if anybody else will feel as I do, so I don't offer a patch here. ___ 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] PyPy 1.9 - Yard Wolf
PyPy 1.9 - Yard Wolf We're pleased to announce the 1.9 release of PyPy. This release brings mostly bugfixes, performance improvements, other small improvements and overall progress on the `numpypy`_ effort. It also brings an improved situation on Windows and OS X. You can download the PyPy 1.9 release here: http://pypy.org/download.html .. _`numpypy`: http://pypy.org/numpydonate.html What is PyPy? = PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7. It's fast (`pypy 1.9 and cpython 2.7.2`_ performance comparison) due to its integrated tracing JIT compiler. This release supports x86 machines running Linux 32/64, Mac OS X 64 or Windows 32. Windows 64 work is still stalling, we would welcome a volunteer to handle that. .. _`pypy 1.9 and cpython 2.7.2`: http://speed.pypy.org Thanks to our donors But first of all, we would like to say thank you to all people who donated some money to one of our four calls: * `NumPy in PyPy`_ (got so far $44502 out of $6, 74%) * `Py3k (Python 3)`_ (got so far $43563 out of $105000, 41%) * `Software Transactional Memory`_ (got so far $21791 of $50400, 43%) * as well as our general PyPy pot. Thank you all for proving that it is indeed possible for a small team of programmers to get funded like that, at least for some time. We want to include this thank you in the present release announcement even though most of the work is not finished yet. More precisely, neither Py3k nor STM are ready to make it in an official release yet: people interested in them need to grab and (attempt to) translate PyPy from the corresponding branches (respectively ``py3k`` and ``stm-thread``). .. _`NumPy in PyPy`: http://pypy.org/numpydonate.html .. _`Py3k (Python 3)`: http://pypy.org/py3donate.html .. _`Software Transactional Memory`: http://pypy.org/tmdonate.html Highlights == * This release still implements Python 2.7.2. * Many bugs were corrected for Windows 32 bit. This includes new functionality to test the validity of file descriptors; and correct handling of the calling convensions for ctypes. (Still not much progress on Win64.) A lot of work on this has been done by Matti Picus and Amaury Forgeot d'Arc. * Improvements in ``cpyext``, our emulator for CPython C extension modules. For example PyOpenSSL should now work. We thank various people for help. * Sets now have strategies just like dictionaries. This means for example that a set containing only ints will be more compact (and faster). * A lot of progress on various aspects of ``numpypy``. See the `numpy-status`_ page for the automatic report. * It is now possible to create and manipulate C-like structures using the PyPy-only ``_ffi`` module. The advantage over using e.g. ``ctypes`` is that ``_ffi`` is very JIT-friendly, and getting/setting of fields is translated to few assembler instructions by the JIT. However, this is mostly intended as a low-level backend to be used by more user-friendly FFI packages, and the API might change in the future. Use it at your own risk. * The non-x86 backends for the JIT are progressing but are still not merged (ARMv7 and PPC64). * JIT hooks for inspecting the created assembler code have been improved. See `JIT hooks documentation`_ for details. * ``select.kqueue`` has been added (BSD). * Handling of keyword arguments has been drastically improved in the best-case scenario: proxy functions which simply forwards ``*args`` and ``**kwargs`` to another function now performs much better with the JIT. * List comprehension has been improved. .. _`numpy-status`: http://buildbot.pypy.org/numpy-status/latest.html .. _`JIT hooks documentation`: http://doc.pypy.org/en/latest/jit-hooks.html JitViewer = There will be a corresponding 1.9 release of JitViewer which is guaranteed to work with PyPy 1.9. See the `JitViewer docs`_ for details. .. _`JitViewer docs`: http://bitbucket.org/pypy/jitviewer Cheers, The PyPy Team ___ 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-checkins] cpython (3.2): #14957: clarify splitlines docs.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/2012 08:55 AM, R. David Murray wrote: On Thu, 07 Jun 2012 11:08:09 +0100, Sam Partington sam.parting...@gmail.com wrote: Wouldn't that be better written as a doctest and so avoid any other typos? Possibly, except (1) I don't think we currently actually test the doctests in the python docs and FWIW, I've had a lot of success lately with automating testing of doctest snippets in Sphinx docs via:: $ /path/to/sphinx-build -b doctest \ -d docs/_build/doctrees docs docs/_build/doctest (That was from non-Python-core packages where the convention is that the Sphink docs are managed and built in the 'docs' subdirectory). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/R4BAACgkQ+gerLs4ltQ426ACgzzr3WHWe8q/4QCdFJgOhYirU 9rAAoMcMZJ3ycPa6B0C4jqCihVdVY9f0 =rYxl -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] backporting stdlib 2.7.x from pypy to cpython
The windows port of pypy makes special demands on stdlib, specifically that files are explicitly closed. There are some other minor issues, in order to merge all the changes necessary to get pypy windows up to speed, around 10 modules or at least their tests seem to need to be modified. I have been doing a bit of work on the stdlib shipped with pypy 1.9 (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, what would be the best path to get, for instance, a modified version of mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported to cpython? Matti PS - I know closing files on delete is also an issue for cpython3.3, I did merge as much of 3.3 back into mailbox as I could, but there were still more issues. ___ 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 (2012-06-01 - 2012-06-08) 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: open3460 (+10) closed 23354 (+46) total 26814 (+56) Open issues with patches: 1460 Issues opened (44) == #12988: Tkinter File Dialog crashes on Win7 when saving to Documents L http://bugs.python.org/issue12988 reopened by serwy #14502: Document better what happens on releasing an unacquired lock http://bugs.python.org/issue14502 reopened by petri.lehtinen #14982: pkgutil.walk_packages seems to not work properly on Python 3.3 http://bugs.python.org/issue14982 opened by Marc.Abramowitz #14983: email.generator should always add newlines after closing bound http://bugs.python.org/issue14983 opened by mitya57 #14984: netrc module allows read of non-secured .netrc file http://bugs.python.org/issue14984 opened by bruno.Piguet #14988: _elementtree: Raise ImportError when importing of pyexpat fail http://bugs.python.org/issue14988 opened by Arfrever #14990: detect_encoding should fail with SyntaxError on invalid encodi http://bugs.python.org/issue14990 opened by flox #14991: Option for regex groupdict() to show only matching names http://bugs.python.org/issue14991 opened by rhettinger #14995: PyLong_FromString documentation should state that the string m http://bugs.python.org/issue14995 opened by rfk #14997: IDLE tries to run shell window if line is completed with F5 ra http://bugs.python.org/issue14997 opened by cuulblu #14998: pprint._safe_key is not always safe enough http://bugs.python.org/issue14998 opened by Shawn.Brown #14999: ctypes ArgumentError lists arguments from 1, not 0 http://bugs.python.org/issue14999 opened by perey #15001: segmentation fault with del sys.module['__main__'] http://bugs.python.org/issue15001 opened by amaury.forgeotdarc #15002: urllib2 does not download 4 MB file completely using ftp http://bugs.python.org/issue15002 opened by sspapilin #15003: make PyNamespace_New() public http://bugs.python.org/issue15003 opened by eric.snow #15004: add weakref support to types.SimpleNamespace http://bugs.python.org/issue15004 opened by eric.snow #15005: trace corrupts return result on chained execution http://bugs.python.org/issue15005 opened by techtonik #15006: Allow equality comparison between naive and aware datetime obj http://bugs.python.org/issue15006 opened by belopolsky #15007: Unittest CLI does not support test packages very well http://bugs.python.org/issue15007 opened by r.david.murray #15008: PEP 362 Signature Objects reference implementation http://bugs.python.org/issue15008 opened by Yury.Selivanov #15009: urlsplit can't round-trip relative-host urls. http://bugs.python.org/issue15009 opened by Buck.Golemon #15010: unittest: _top_level_dir is incorrectly persisted between call http://bugs.python.org/issue15010 opened by r.david.murray #15011: Change Scripts to bin on Windows http://bugs.python.org/issue15011 opened by brian.curtin #15013: smtplib: add low-level APIs to doc? http://bugs.python.org/issue15013 opened by sandro.tosi #15014: smtplib: add support for arbitrary auth methods http://bugs.python.org/issue15014 opened by sandro.tosi #15015: Access to non-existing future attribute in error path of fut http://bugs.python.org/issue15015 opened by pieleric #15016: Add special case for latin messages in email.mime.text http://bugs.python.org/issue15016 opened by mitya57 #15018: Incomplete Python LDFLAGS and CPPFLAGS used for extension modu http://bugs.python.org/issue15018 opened by marcusva #15019: Sting termination on Linux http://bugs.python.org/issue15019 opened by jjanis #15020: Poor default value for progname http://bugs.python.org/issue15020 opened by Joshua.Cogliati #15021: xmlrpc server hangs http://bugs.python.org/issue15021 opened by Abhishek.Singh #15022: types.SimpleNamespace needs to be picklable http://bugs.python.org/issue15022 opened by eric.snow #15025: httplib and http.client are missing response messages for defi http://bugs.python.org/issue15025 opened by craigloftus #15026: Faster UTF-16 encoding http://bugs.python.org/issue15026 opened by storchaka #15027: Faster UTF-32 encoding http://bugs.python.org/issue15027 opened by storchaka #15028: PySys_SetArgv escapes quotes in argv[] http://bugs.python.org/issue15028 opened by RMBianchi #15029: Update Defining New Types chapter according to PEP 253 http://bugs.python.org/issue15029 opened by mloskot #15030: PyPycLoader can't read cached .pyc files http://bugs.python.org/issue15030 opened by Ronan.Lamy #15031: Split .pyc parsing from module loading http://bugs.python.org/issue15031 opened by Ronan.Lamy #15032: Provide a select.select implemented using select.poll http://bugs.python.org/issue15032 opened by gregory.p.smith #15033: Different exit status when using -m
Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython
On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus matti.pi...@gmail.com wrote: The windows port of pypy makes special demands on stdlib, specifically that files are explicitly closed. There are some other minor issues, in order to merge all the changes necessary to get pypy windows up to speed, around 10 modules or at least their tests seem to need to be modified. I have been doing a bit of work on the stdlib shipped with pypy 1.9 (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, what would be the best path to get, for instance, a modified version of mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported to cpython? These fixes would also be useful for IronPython and possibly Jython as well. Unclosed files are probably the biggest set of failures when running CPython's tests on IronPython (along with assuming that sys.platform == 'win32' means Windows). Whether or not they get backported to CPython, it might be worth finding a way to share the 2.7 stdlib between the alternative implementations (changes to 3.x should go into CPython, obviously). - Jeff ___ 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] backporting stdlib 2.7.x from pypy to cpython
On Fri, Jun 8, 2012 at 9:22 AM, Jeff Hardy jdha...@gmail.com wrote: On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus matti.pi...@gmail.com wrote: The windows port of pypy makes special demands on stdlib, specifically that files are explicitly closed. There are some other minor issues, in order to merge all the changes necessary to get pypy windows up to speed, around 10 modules or at least their tests seem to need to be modified. I have been doing a bit of work on the stdlib shipped with pypy 1.9 (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, what would be the best path to get, for instance, a modified version of mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported to cpython? These fixes would also be useful for IronPython and possibly Jython as well. Unclosed files are probably the biggest set of failures when running CPython's tests on IronPython (along with assuming that sys.platform == 'win32' means Windows). Whether or not they get backported to CPython, it might be worth finding a way to share the 2.7 stdlib between the alternative implementations (changes to 3.x should go into CPython, obviously). I think it's supposed to be alright to push changes to CPython's 2.7 *tests* (like test_mailbox.py) but not other parts of the standard library (like mailbox.py) -- I'd love to find a way to share the modifications from various implementations though -- and in the 3.x future hopefully it can all just end up in CPython's Lib. -Frank ___ 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-checkins] cpython (3.2): #14957: clarify splitlines docs.
On Fri, 08 Jun 2012 07:20:55 -0400, Tres Seaver tsea...@palladion.com wrote: On 06/07/2012 08:55 AM, R. David Murray wrote: On Thu, 07 Jun 2012 11:08:09 +0100, Sam Partington sam.parting...@gmail.com wrote: Wouldn't that be better written as a doctest and so avoid any other typos? Possibly, except (1) I don't think we currently actually test the doctests in the python docs and FWIW, I've had a lot of success lately with automating testing of doctest snippets in Sphinx docs via:: Oh, the *mechanics* of running the doctests in the docs are not difficult, 'make doctest' in Doc works just fine (on Python2). The are four issues: (1) we build the python3 docs using python2, so 'make doctest' on python3 doesn't currently work, and (2) not all the doctest snippets are valid doctests, (3) not all the code snippets that can (and should) be validated are recognized as such by 'make doctest', and (4) there is no buildbot-style automation for running the doc doctests. (1) is the easiest one to fix. --David PS: A year or so ago I cleaned up the doctests for turtle and multiprocessing, but I haven't re-run those tests since. I just did now: multiprocessing still passes(*), and there is one failing turtle test. The grand total on 2.7 is 1131 tests, 78 failures. (*) If I remember correctly cleaning up the doctests in Multiprocessing mostly meant making them not-doctests from 'make doctest's point of view, and then hand validating them. But Multiprocessing is a bit of a special case. ___ 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] backporting stdlib 2.7.x from pypy to cpython
On Fri, 08 Jun 2012 09:39:47 -0700, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Fri, Jun 8, 2012 at 9:22 AM, Jeff Hardy jdha...@gmail.com wrote: On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus matti.pi...@gmail.com wrote: The windows port of pypy makes special demands on stdlib, specifically that files are explicitly closed. There are some other minor issues, in order to merge all the changes necessary to get pypy windows up to speed, around 10 modules or at  least their tests seem to need to be modified. I have been doing a bit of work on the stdlib shipped with pypy 1.9 (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, what would be the best path to get, for instance, a modified version of mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported to cpython? These fixes would also be useful for IronPython and possibly Jython as well. Unclosed files are probably the biggest set of failures when running CPython's tests on IronPython (along with assuming that sys.platform == 'win32' means Windows). Whether or not they get backported to CPython, it might be worth finding a way to share the 2.7 stdlib between the alternative implementations (changes to 3.x should go into CPython, obviously). I think it's supposed to be alright to push changes to CPython's 2.7 *tests* (like test_mailbox.py) but not other parts of the standard library (like mailbox.py) -- I'd love to find a way to share the modifications from various implementations though -- and in the 3.x future hopefully it can all just end up in CPython's Lib. If you can write a test that shows a problem with the code, it doesn't matter if you found in in a different implementation. As long as the change conforms to our backward compatibility policy it can be fixed in 2.7. And yes, I agree with your understanding that fixing tests (especially for things like resources not getting cleaned up correctly) is appreciated for the 2.7 tests. We should of course verify whether or not similar changes are needed for Python3. As for path to get them in...if you have any question about whether or not the change is appropriate, post a proposed patch to the tracker. --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] backporting stdlib 2.7.x from pypy to cpython
On Fri, Jun 8, 2012 at 12:39 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Fri, Jun 8, 2012 at 9:22 AM, Jeff Hardy jdha...@gmail.com wrote: On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus matti.pi...@gmail.com wrote: The windows port of pypy makes special demands on stdlib, specifically that files are explicitly closed. There are some other minor issues, in order to merge all the changes necessary to get pypy windows up to speed, around 10 modules or at least their tests seem to need to be modified. I have been doing a bit of work on the stdlib shipped with pypy 1.9 (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, what would be the best path to get, for instance, a modified version of mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported to cpython? These fixes would also be useful for IronPython and possibly Jython as well. Unclosed files are probably the biggest set of failures when running CPython's tests on IronPython (along with assuming that sys.platform == 'win32' means Windows). Whether or not they get backported to CPython, it might be worth finding a way to share the 2.7 stdlib between the alternative implementations (changes to 3.x should go into CPython, obviously). I think it's supposed to be alright to push changes to CPython's 2.7 *tests* (like test_mailbox.py) but not other parts of the standard library (like mailbox.py) R. David already replied to this, but just to reiterate: tests can always get updated, and code that fixes a bug (and leaving a file open can be considered a bug) can also go in. It's just stuff like code refactoring, speed improvements, etc. that can't go into Python 2.7 at this point. -- I'd love to find a way to share the modifications from various implementations though -- and in the 3.x future hopefully it can all just end up in CPython's Lib. If/until the stdlib is made into its own repo, should the various VMs consider keeping a common Python 2.7 repo that contains nothing but the stdlib (or at least just modifications to those) so they can modify in ways that CPython can't accept because of compatibility policy? You could keep it on hg.python.org (or wherever) and then all push to it. This might also be a good way to share Python implementations of extension modules for Python 2.7 instead of everyone maintaining there own for the next few years (although I think those modules should go into the stdlib directly for Python 3 as well). Basically this could be a test to see if communication and collaboration will be high enough among the other VMs to bother with breaking out the actual stdlib into its own repo or if it would just be a big waste of time. P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. ___ 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] backporting stdlib 2.7.x from pypy to cpython
On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon br...@python.org wrote: R. David already replied to this, but just to reiterate: tests can always get updated, and code that fixes a bug (and leaving a file open can be considered a bug) can also go in. It's just stuff like code refactoring, speed improvements, etc. that can't go into Python 2.7 at this point. Thanks for the clarification! If/until the stdlib is made into its own repo, should the various VMs consider keeping a common Python 2.7 repo that contains nothing but the stdlib (or at least just modifications to those) so they can modify in ways that CPython can't accept because of compatibility policy? You could keep it on hg.python.org (or wherever) and then all push to it. This might also be a good way to share Python implementations of extension modules for Python 2.7 instead of everyone maintaining there own for the next few years (although I think those modules should go into the stdlib directly for Python 3 as well). Basically this could be a test to see if communication and collaboration will be high enough among the other VMs to bother with breaking out the actual stdlib into its own repo or if it would just be a big waste of time. I'd be up for trying this. I don't think it's easy to fork a subdirectory of CPython though - right now I just keep an unchanged copy of the 2.7 LIb in our repo (PyPy does the same, at least the last time I checked). P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. I think a python-implementations list would be a fantastic idea - I sometimes miss multi-implementation discussions in python-dev, or at least come in very late. -Frank ___ 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] backporting stdlib 2.7.x from pypy to cpython
On Fri, Jun 8, 2012 at 2:21 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon br...@python.org wrote: R. David already replied to this, but just to reiterate: tests can always get updated, and code that fixes a bug (and leaving a file open can be considered a bug) can also go in. It's just stuff like code refactoring, speed improvements, etc. that can't go into Python 2.7 at this point. Thanks for the clarification! If/until the stdlib is made into its own repo, should the various VMs consider keeping a common Python 2.7 repo that contains nothing but the stdlib (or at least just modifications to those) so they can modify in ways that CPython can't accept because of compatibility policy? You could keep it on hg.python.org (or wherever) and then all push to it. This might also be a good way to share Python implementations of extension modules for Python 2.7 instead of everyone maintaining there own for the next few years (although I think those modules should go into the stdlib directly for Python 3 as well). Basically this could be a test to see if communication and collaboration will be high enough among the other VMs to bother with breaking out the actual stdlib into its own repo or if it would just be a big waste of time. I'd be up for trying this. I don't think it's easy to fork a subdirectory of CPython though - right now I just keep an unchanged copy of the 2.7 LIb in our repo (PyPy does the same, at least the last time I checked). Looks like hg doesn't have support yet: http://stackoverflow.com/questions/920355/how-do-i-clone-a-sub-folder-of-a-repository-in-mercurial . The only sane option I can see then is to keep doing what you and PyPy are doing and keep a copy of the stdlib, but now you all simply share the repo instead of keeping your own copies and possibly use subrepos to pull it into your own hg repos. P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. I think a python-implementations list would be a fantastic idea - I sometimes miss multi-implementation discussions in python-dev, or at least come in very late. If other people agree then I will get Barry to create it. ___ 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] backporting stdlib 2.7.x from pypy to cpython
On Fri, Jun 8, 2012 at 11:57 AM, Eric Snow ericsnowcurren...@gmail.com wrote: This would have been handy for feedback on sys.implementation. FWIW I followed the discussion and am happy with the result :) -Frank ___ 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] VS 11 Express is Metro only.
On Fri, May 25, 2012 at 7:06 AM, mar...@v.loewis.de wrote: I hereby predict that Microsoft will revert this decision, and that VS Express 11 will be able to build CPython. And your prediction was right on :-) : http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx. -- # Meador ___ 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-checkins] cpython (3.2): #14957: clarify splitlines docs.
On Fri, Jun 8, 2012 at 11:08 AM, R. David Murray rdmur...@bitdance.com wrote: The are four issues: (1) we build the python3 docs using python2, so 'make doctest' on python3 doesn't currently work For reference: http://bugs.python.org/issue10224. Are there any others? -eric ___ 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] backporting stdlib 2.7.x from pypy to cpython
Le 08/06/2012 20:29, Brett Cannon a écrit : P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. I think a python-implementations list would be a fantastic idea - I sometimes miss multi-implementation discussions in python-dev, or at least come in very late. If other people agree then I will get Barry to create it. Well, the question is, are many python-dev discussions CPython(specific? If not, then it doesn't make a lot of sense to create python-implementations (and it's one more subscription to manage for those of us who want to keep an eye on all core development-related discussions). 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] TZ-aware local time
On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum gu...@python.org wrote: See http://bugs.python.org/issue9527 . With datetime.timestamp() method committed, I would like to get back to this issue. In some sense, an inverse of datetime.timestamp() is missing from the datetime module. Given a POSIX timestamp, I cannot get the local time as an aware datetime object. Reading the requirements for a timezone implementation and the time.localtime() function, it would seem that a timezone object representing local time can certainly be constructed, as long as the time module uses or emulates the Unix/C behavior. A tzinfo subclass emulating local time rules introduces the DST ambiguity to a problem that does not inherently suffer from it. See http://bugs.python.org/issue9063. A typical application is an e-mail agent that has to insert local time complete with UTC offset in the message header. The time.localtime() method will produce local time components together with the dst flag from which time.strftime() can produce RFC 3339 timestamp using %z directive. There is no ambiguity during DST transition. The only complication is that time component TZ components exhibit canceling discontinuities at those times. For example, t = mktime((2010, 11, 7, 1, 0, 0, -1, -1, 0)) for i in range(5): ... print(strftime(%T%z, localtime(t + i - 2))) ... 01:59:58-0400 01:59:59-0400 01:00:00-0500 01:00:01-0500 01:00:02-0500 As I explained at http://bugs.python.org/msg109452, it is not possible to reproduce this sequence using LocalTimezone. I don't like that function. It returns two different timezone objects depending on whether DST is in effect. Also it adds a new method to the datetime class, which I think is unnecessary here. We can avoid introducing new methods. We can add aware= flag to datetime.now() and datetime.fromtimestamp(), but it may be better to introduce special values for existing tzinfo= argument instead. For example, we can allow passing an empty string in tzinfo to signify that a timezone instance should be generated filled with appropriate local offset. This choice may seem less of a hack if we introduce some simple TZ parsing and allow string values like UTC-0500 as valid tzinfo specifications. ___ 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] Import semantics?
Dan Stromberg wrote:
On Fri, Jun 8, 2012 at 3:16 PM, Ethan Furman wrote:
Dan Stromberg wrote:
Did the import semantics change in cpython 3.3a4?
I used to be able to import treap.py even though I had a treap
directory in my cwd. With 3.3a4, I have to rename the treap
directory to see treap.py.
Check out PEP 420 -- Implicit Namespace Packages
[http://www.python.org/dev/peps/pep-0420/]
Am I misinterpreting this? It seems like according to the PEP, I should
have still been able to import treap.py despite having a treap/. But I
couldn't; I had to rename treap/ to treap-dir/ first.
During import processing, the import machinery will continue to iterate
over each directory in the parent path as it does in Python 3.2. While
looking for a module or package named foo, for each directory in the
parent path:
* If directory/foo/__init__.py is found, a regular package is
imported and returned.
* If not, but directory/foo.{py,pyc,so,pyd} is found, a module
is imported and returned. The exact list of extension varies
by platform and whether the -O flag is specified. The list
here is representative.
* If not, but directory/foo is found and is a directory, it is
recorded and the scan continues with the next directory in the
parent path.
* Otherwise the scan continues with the next directory in the
parent path.
I do not understand PEP 420 well enough to say if this is intentional or
a bug -- thoughts?
~Ethan~
___
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] Import semantics?
On 6/8/2012 6:41 PM, Ethan Furman wrote:
Dan Stromberg wrote:
On Fri, Jun 8, 2012 at 3:16 PM, Ethan Furman wrote:
Dan Stromberg wrote:
Did the import semantics change in cpython 3.3a4?
I used to be able to import treap.py even though I had a treap
directory in my cwd. With 3.3a4, I have to rename the treap
directory to see treap.py.
Check out PEP 420 -- Implicit Namespace Packages
[http://www.python.org/dev/peps/pep-0420/]
Am I misinterpreting this? It seems like according to the PEP, I
should have still been able to import treap.py despite having a
treap/. But I couldn't; I had to rename treap/ to treap-dir/ first.
During import processing, the import machinery will continue to
iterate over each directory in the parent path as it does in Python
3.2. While looking for a module or package named foo, for each
directory in the parent path:
* If directory/foo/__init__.py is found, a regular package is
imported and returned.
* If not, but directory/foo.{py,pyc,so,pyd} is found, a module
is imported and returned. The exact list of extension varies
by platform and whether the -O flag is specified. The list
here is representative.
* If not, but directory/foo is found and is a directory, it is
recorded and the scan continues with the next directory in the
parent path.
* Otherwise the scan continues with the next directory in the
parent path.
I do not understand PEP 420 well enough to say if this is intentional or
a bug -- thoughts?
I missed the beginning of this discussion and I need some more details.
What directories are on sys.path, where do treap.py and treap/ appear in
them, and is there an __init__.py in treap? At first blush it sounds
like it should continue working.
If you (Dan?) could re-create this in a small example and open a bug,
that would be great.
Eric.
___
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] TZ-aware local time
On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum gu...@python.org wrote: See http://bugs.python.org/issue9527 . With datetime.timestamp() method committed, I would like to get back to this issue. What was committed? The bug only mentions a change to the email package. In some sense, an inverse of datetime.timestamp() is missing from the datetime module. Given a POSIX timestamp, I cannot get the local time as an aware datetime object. But that's because there are (almost) no tz objects in the stdlib. Reading the requirements for a timezone implementation and the time.localtime() function, it would seem that a timezone object representing local time can certainly be constructed, as long as the time module uses or emulates the Unix/C behavior. A tzinfo subclass emulating local time rules introduces the DST ambiguity to a problem that does not inherently suffer from it. But if you knew the name for the local time zone and constructed a datetime using it (e.g. using the excellent pytz package) it would suffer from exactly the same problem, wouldn't it? (Except on some systems it might be more correct for historic dates when a different algorithm was used.) See http://bugs.python.org/issue9063. A typical application is an e-mail agent that has to insert local time complete with UTC offset in the message header. The time.localtime() method will produce local time components together with the dst flag from which time.strftime() can produce RFC 3339 timestamp using %z directive. There is no ambiguity during DST transition. The only complication is that time component TZ components exhibit canceling discontinuities at those times. For example, t = mktime((2010, 11, 7, 1, 0, 0, -1, -1, 0)) for i in range(5): ... print(strftime(%T%z, localtime(t + i - 2))) ... 01:59:58-0400 01:59:59-0400 01:00:00-0500 01:00:01-0500 01:00:02-0500 As I explained at http://bugs.python.org/msg109452, it is not possible to reproduce this sequence using LocalTimezone. So LocalTimezone (or any named timezone that uses DST) should not be used for this purpose. That does not make LocalTimezone useless -- it is no less useless than any DST-supporting timezone. I don't like that function. It returns two different timezone objects depending on whether DST is in effect. Also it adds a new method to the datetime class, which I think is unnecessary here. We can avoid introducing new methods. We can add aware= flag to datetime.now() and datetime.fromtimestamp(), but it may be better to introduce special values for existing tzinfo= argument instead. For example, we can allow passing an empty string in tzinfo to signify that a timezone instance should be generated filled with appropriate local offset. This choice may seem less of a hack if we introduce some simple TZ parsing and allow string values like UTC-0500 as valid tzinfo specifications. I'm still unsure what problem you're trying to solve. Can we just introduce LocalTimezone (or whatever name it should have) and let the issue rest? -- --Guido van Rossum (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
