Re: [Python-Dev] None as slice params to list.index() and tuple.index()
Hm. I agree with Raymond that this should be treated as a feature request and not fixed in 2.7 / 3.2. (However the mention of 'find' in the error message for 'index' is a bug and should be fixed.) As for the feature request, I think that allowing None in more places is more regular and consistent across interfaces. I note that the slice() object also represents missing or default values as None, so it is not just a carryover from the old string.py. So, +1 on the feature for 3.3; -1 on the fix in 3.2 or 2.7. --Guido On Sun, Nov 6, 2011 at 11:56 AM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Nov 6, 2011, at 12:49 AM, Petri Lehtinen wrote: Currently, find(), rfind(), index(), rindex(), count(), startswith() and endswith() of str, bytes and bytearray accept None. Should list.index() and tuple.index() accept it, too? The string methods accept None as a historical artifact of being in string.py where optional arguments defaulted to None. That doesn't imply that you should change every other API that accepts a start argument. The list.index() API is ancient and stable. There has been little or no demonstrated need for its start argument to be None. Also, the list API does not exist in isolation. It shows up in strings, the sequence ABC, and every API that aspires to be list-like. Overall, I'm -1 on this change and find it to be gratuitous. We have *way* to many micro API changes of dubious benefit. Also, the change should not have been applied to Py2.7 and Py3.2. We don't backport API changes. That would just make Jython and IronPython become non-compliant in mid-stream. 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/guido%40python.org -- --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
[Python-Dev] Regression test coupling
I ran into an error today related to the use of support.TESTFN throughout the regression test suite. In my Windows tests, test_base64 passed, but left a file (named by support.TESTFN) lying around: 'test_base64' left behind file '@test_3532_tmp' Much later in the run, a set of unrelated tests started failing, all apparently because of the left-behind file - for example, test_mailbox.setUp failed while trying to make a directory named by support.TESTFN: File c:\Users\Vinay\Projects\pythonv\lib\mailbox.py, line 270, in __init__ os.mkdir(self._path, 0o700) PermissionError: [Error 5] Access is denied: 'c:\\Users\\Vinay\\Projects\\pythonv\\build\\test_python_3532\\@test_3532_tmp' Sorry if this has come up before, but why do we couple the tests in this way, so that failure to clean up in one test causes drive-by failures in other, unrelated tests? Regards, Vinay Sajip ___ 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] Regression test coupling
On Tue, Nov 8, 2011 at 8:02 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Sorry if this has come up before, but why do we couple the tests in this way, so that failure to clean up in one test causes drive-by failures in other, unrelated tests? Personally, I just use the tempfile module in tests that I write (historically via test.script_helper.temp_dir, these days via the public tempfile.TemporaryDirectory API). Given the other things regrtest cleans up between tests, I'm not sure why it doesn't also kill TESTFN, though. 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] Regression test coupling
Nick Coghlan ncoghlan at gmail.com writes: Given the other things regrtest cleans up between tests, I'm not sure why it doesn't also kill TESTFN, though. Well, there's a function regrtest.cleanup_test_droppings which aims to do just this, and it's called in a finally: block from regrtest.runtest. It's supposed to print a message if removal fails, and appears to be what prints the left behind message. In my case no couldn't remove message was printed, and yet the file was there later - whether it wasn't properly removed, or whether it was created in an intervening test, is not easy to determine :-( Regards, Vinay Sajip ___ 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] Merging 3.2 to 3.3 is messy because Misc/NEWS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When merging from 3.2 to 3.3 Misc/NEWS always conflicts (lately). Instead of copypaste the test manually between versions, has anybody a better workflow?. Since any change applied to 3.2 should be applied to 3.3 too (except very few cases), Mercurial merge machinery should be able to merge both versions except when the changes are very near the version headers. I haven't checked, but I guess that the problem is that the different issues have been added in different positions in the file, so both branches are diverging, instead of only divert in the python versions referenced. If that is the case, could be acceptable to reorganize 3.3 version to ease future merges?. Would that solve it? Ideas?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTrlPl5lgi5GaxT1NAQKVggP/bn6vUhQlHjEYg+pFEInnVXYSudamPafP m6bgX6hKS/MtaixVJGlRnAwJ6UQ/nftjmVn80Yd7CsxnsyPApUZVgzkaLMLOhh++ H08gwxgoh1skciYmtyjsy4Vi4xi/4tehu2IVc73SVXkLVbnkc4z1c2Xmsu4TZ2ai r2ncgxRkHgw= =pCHL -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] Python 3 optimizations, continued, continued again...
Hi guys, while there is at least some interest in incorporating my optimizations, response has still been low. I figure that the changes are probably too much for a single big incorporation step. On a recent flight, I thought about cutting it down to make it more easily digestible. The basic idea is to remove the optimized interpreter dispatch loop and advanced instruction format and use the existing ones. Currently (rev. ca8a0dfb2176), opcode.h uses 109 of potentially available 255 instructions using the current instruction format. Hence, up to 149 instruction opcodes could be given to optimized instruction derivatives. Consequently, a possible change would require to change: a) opcode.h to add new instruction opcodes, b) ceval.c to include the new instruction opcodes in PyEval_EvalFrameEx, c) abstract.c, object.c (possible other files) to add the quickening/rewriting function calls. If this is more interesting, I could start evaluating which instruction opcodes should be allocated to which derivatives to get the biggest benefit. This is a lot easier to implement (because I can re-use the existing instruction implementations) and can easily be made to be conditionally compile-able, similar to the computed-gotos option. Since the changes are minimal it is also simpler to understand and deal with for everybody else, too. On the downside, however, not all optimizations are possible and/or make sense in the given limit of instructions (no data-object inlining and no reference-count elimination.) How does that sound? Have a nice day, --stefan ___ 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 3 optimizations, continued, continued again...
2011/11/8 stefan brunthaler s.bruntha...@uci.edu: How does that sound? I think I can hear real patches and benchmarks most clearly. -- Regards, Benjamin ___ 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] Merging 3.2 to 3.3 is messy because Misc/NEWS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Nov 08, 2011, at 04:49 PM, Jesus Cea wrote: When merging from 3.2 to 3.3 Misc/NEWS always conflicts (lately). Instead of copypaste the test manually between versions, has anybody a better workflow?. Does Mercurial support custom merge plugins? I know for example, Bazaar has a custom merge plugin for dealing with debian/changelogs which has greatly reduced conflicts when doing similar operations there. Seems like that would be the best way to go for Misc/NEWS. Barring that, I always keep a copy of the unconflicted Misc/NEWS around to consult when manually resolving the conflicts. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOuXnxAAoJEBJutWOnSwa/9iAP/03KIeGBA/3qTyyfaEhen2o/ dYXvTrabjCI9S0tcbYyU3oUpUtGX8kxjOaIklwKBxpF82CmAES96jJh+gIf/5qUX K3aGQe3Xhr7yezFA5fWiE52rUqtFenPDTz9R+06xzDvoBM/MkEZRcl3KDZloYeI+ wm+h13x7mDp2MEJwRbYGFBe6ydW3phraMbNdC6zu2CbXQ8ttcKm3sohbVL4IEzHb rKVMJFiub1fu270UCdRHClzeGovqytbjFmiFTM91qNRR/xi5Wky/9RaKT/ar4w+r tr19ZCRt+9TtdluW1iJ3I8C+ygzKQH+d6vgpdyxfzLoq8RVnIVpVxWLQZz3efm1I yvBUtsxNsZeEEnvtm6qgBWB+KRzMVqmZLxf/kJgSY1+ybWdrbV6g+cWk5y0UMZNQ hlEE44S6/wCKl9hjUgFufw1ox4bXJpYgyc10cIrIwnL1jjoxIqrTV06GtwqI6JJO O1/1UJQ/LfM8P79deZeflYAdxarUEewOPqruWSBFt1Hv+L10DF1N2IebDluctLzX KD/WJA8smKiWwzo0TAHhniQL8Ckxr/7SJNeRq0q+LrypVz86okZExFWOjHm6zWih cpcFCJ+0tX6ajS++9nzOTJGGQ166fMC86HTLnP7565Gg57G/JoeLRCTnLkODdb6X NKuRRPZIK0daJVEmiUpE =s7Wv -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] Merging 3.2 to 3.3 is messy because Misc/NEWS
On 11/8/2011 10:49 AM, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When merging from 3.2 to 3.3 Misc/NEWS always conflicts (lately). Instead of copypaste the test manually between versions, has anybody a better workflow?. If a bug is fixed in 3.2.latest, then it will not be new in 3.3.0, so perhaps it should not be added there. NEWS could just refer back to previous sections. Then 3.3.0 News would only be new features and the occasional ambiguous item not fixed before. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
I'm curious to know how this level of flexibility can be achieved with the MSI format: I know one can code the equivalent logic in C (for example) in a custom action, but don't know how you can keep the logic in Python. I'd provide a fixed custom action which gets hold of the installer session, and then runs a Python script. IIUC, it should be possible to map categories to entries in the Directory table, so that the Python script would actually configure the installer process before the installer actually starts installing the files. The DLL could be part of packaging, similar to how the bdist_wininst executable is part of distutils. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Merging 3.2 to 3.3 is messy because Misc/NEWS
On 08Nov2011 13:50, Barry Warsaw ba...@python.org wrote: | On Nov 08, 2011, at 04:49 PM, Jesus Cea wrote: | When merging from 3.2 to 3.3 Misc/NEWS always conflicts (lately). | Instead of copypaste the test manually between versions, has anybody | a better workflow?. | | Does Mercurial support custom merge plugins? I know for example, Bazaar has a | custom merge plugin for dealing with debian/changelogs which has greatly | reduced conflicts when doing similar operations there. Yes it does. I use this facility to merge timesheet files mainatined on separate hosts (home machine, travelling laptop) in my hgbox script. The hgrc says: [merge-patterns] timesheets-cameron/2* = merge-dumb dailylog-cameron/2*/[A-Z]* = merge-dumb so it is easy to specify a particular tool to merge particular files. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ It is a tale told by an idiot, full of sound and fury, signifying nothing. - William Shakespeare ___ 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] Merging 3.2 to 3.3 is messy because Misc/NEWS
On 09Nov2011 07:19, I wrote: | Yes it does. I use this facility to merge timesheet files mainatined on | separate hosts (home machine, travelling laptop) in my hgbox script. | The hgrc says: | | [merge-patterns] | timesheets-cameron/2* = merge-dumb | dailylog-cameron/2*/[A-Z]* = merge-dumb | | so it is easy to specify a particular tool to merge particular files. Oh yes, the associated clause: [merge-tools] merge-dumb.args = $local $other $output to specify how merge-dumb is invoked. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ I was gratified to be able to answer promptly and I did. I said I didn't know. - Mark Twain ___ 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] cpython: Remove the old style [...] to denote optional args and show the defaults.
Am 08.11.2011 21:30, schrieb brian.curtin: http://hg.python.org/cpython/rev/60ae7979fec8 changeset: 73463:60ae7979fec8 user:Brian Curtin br...@python.org date:Tue Nov 08 14:30:02 2011 -0600 summary: Remove the old style [...] to denote optional args and show the defaults. files: Doc/library/os.rst | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Doc/library/os.rst b/Doc/library/os.rst --- a/Doc/library/os.rst +++ b/Doc/library/os.rst @@ -872,7 +872,7 @@ .. versionadded:: 3.3 -.. function:: futimesat(dirfd, path[, (atime, mtime)]) +.. function:: futimesat(dirfd, path, (atime, mtime)=None) Like :func:`utime` but if *path* is relative, it is taken as relative to *dirfd*. If *path* is relative and *dirfd* is the special value :data:`AT_FDCWD`, then *path* Hmm, while the [] are old style, they are still correct when the function doesn't support kwargs. Please revert. (Also, the syntax ``(atime, mtime)=None`` would not be valid Python and at is best confusing.) Georg ___ 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] cpython: Remove the old style [...] to denote optional args and show the defaults.
On Tue, Nov 8, 2011 at 14:47, Georg Brandl g.bra...@gmx.net wrote: Am 08.11.2011 21:30, schrieb brian.curtin: http://hg.python.org/cpython/rev/60ae7979fec8 changeset: 73463:60ae7979fec8 user: Brian Curtin br...@python.org date: Tue Nov 08 14:30:02 2011 -0600 summary: Remove the old style [...] to denote optional args and show the defaults. files: Doc/library/os.rst | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Doc/library/os.rst b/Doc/library/os.rst --- a/Doc/library/os.rst +++ b/Doc/library/os.rst @@ -872,7 +872,7 @@ .. versionadded:: 3.3 -.. function:: futimesat(dirfd, path[, (atime, mtime)]) +.. function:: futimesat(dirfd, path, (atime, mtime)=None) Like :func:`utime` but if *path* is relative, it is taken as relative to *dirfd*. If *path* is relative and *dirfd* is the special value :data:`AT_FDCWD`, then *path* Hmm, while the [] are old style, they are still correct when the function doesn't support kwargs. Please revert. (Also, the syntax ``(atime, mtime)=None`` would not be valid Python and at is best confusing.) Georg Backed out. http://hg.python.org/cpython/rev/2636df45b630 ___ 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] Packaging and binary distributions
I'd provide a fixed custom action which gets hold of the installer session, and then runs a Python script. IIUC, it should be possible to map categories to entries in the Directory table, so that the Python script would actually configure the installer process before the installer actually starts installing the files. The DLL could be part of packaging, similar to how the bdist_wininst executable is part of distutils. Presumably the code in the DLL would need to be independent of Python, and find the correct Python version to run? Perhaps a variable in the .MSI could serve to indicate the version dependency. It's certainly feasible, but needs specifying in more detail ... Regards, Vinay Sajip ___ 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
Le samedi 29 octobre 2011 07:47:01, vous avez écrit : 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.) I wrote a patch to implement the deprecation: http://bugs.python.org/issue13374 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
On Sat, Oct 29, 2011 at 4:37 AM, Carl Meyer c...@oddbird.net wrote: 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``. I'm actually finding I quite like the virtualenv scheme of having sys.prefix refer to the virtual environment and sys.real_prefix refer to the interpeter's default environment. If pyvenv used the same naming scheme, then a lot of code designed to work with virtualenv would probably just work with pyvenv as well. 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] draft PEP: virtual environments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/08/2011 05:43 PM, Nick Coghlan wrote: I'm actually finding I quite like the virtualenv scheme of having sys.prefix refer to the virtual environment and sys.real_prefix refer to the interpeter's default environment. If pyvenv used the same naming scheme, then a lot of code designed to work with virtualenv would probably just work with pyvenv as well. Indeed. I've already been convinced (see my reply to Chris McDonough earlier) that this is the more practical approach. I've already updated my copy of the PEP on Bitbucket (https://bitbucket.org/carljm/python-peps/src/0936d8e00e5b/pep-0404.txt) to reflect this switch, working (slowly) on an update of the reference implementation. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk650A0ACgkQ8W4rlRKtE2cYuACgk5oRU54R+w4jHAynvW/QAxNU mQQAoI0zM4wzpPdOa0RIvEuAkUCmm+jT =RMyV -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
