Re: [Python-Dev] Unicode module names (Was: Python 3.3 release schedule posted)
Le samedi 02 avril 2011 à 16:06 +0300, anatoly techtonik a écrit : > On Thu, Mar 24, 2011 at 2:41 AM, Victor Stinner > wrote: > > > > I am still working on the import machinery to fix last bugs related to > > Unicode. So it will be possible to do an useless "import café" in Python > > 3.3, on any platform. But it is not really an huge change (for the user, > > but an huge change in the code ;-)). > > I don't like the idea of reading the code with some kind of Chinese > variable names in them. I'd prefer that I and l confusion will be the > only I should care about in valid Python syntax. Please read the PEP 3131 (Supporting Non-ASCII Identifiers): http://www.python.org/dev/peps/pep-3131/ And the thread "Import and unicode: part two" (19 Jan 2011) on python-dev. Victor ___ 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] Python 3.3 release schedule posted
Le samedi 02 avril 2011 à 16:00 +0300, anatoly techtonik a écrit :
> Do you have an estimate of Python 3.2.1 release?
FYI I introduced (and then fixed) two regressions specific to Windows in
Python 3.2:
http://bugs.python.org/issue11272 (input)
http://bugs.python.org/issue11395 (print)
Issue #11272 is annoying: input() returns a string ending a string
ending by '\r'. The workaround is input().rstrip('\r')or
input().rstrip().
The second end is more a corner case: print fails if you write more than
60,000 bytes at once.
Victor
___
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] Policy for making changes to the AST
On 3 April 2011 07:55, "Martin v. Löwis" wrote: >> 1. Do nothing. This will break code that currently uses AST, but doesn't add >> any complexity to cpython. > > I'm in favor of this approach as well. Notice that there is > ast.__version__ precisely so that applications can support multiple AST > versions. This might be a suitable topic for a post to "Python Insider" - as it's a policy question, that would make the discussion known to a wider audience, giving people with an interest the opportunity to comment. Hopefully, that also makes the "Do Nothing" approach more acceptable to the wider Python community by publicising the implications well in advance. If there are no objections (I'm conscious that we don't want every python-dev discussion dumped onto Python Insider) I'll post a short article once a consensus has been reached. 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] [Python-checkins] cpython: Issue #5863: Rewrite BZ2File in pure Python, and allow it to accept
Hi, > changeset: 69112:2cb07a46f4b5 > user:Antoine Pitrou > date:Sun Apr 03 17:05:46 2011 +0200 > summary: > Issue #5863: Rewrite BZ2File in pure Python, and allow it to accept > file-like objects using a new `fileobj` constructor argument. Patch by > Nadeem Vawda. > > files: > Doc/ACKS.txt | 1 + I think we use Misc/ACKS for code+docs contribution like this one, Doc/ACKS.txt being used for doc-only changes. This second file is not comprehensive nor always used though, so maybe it should be superseded by the former. Regards > Doc/library/bz2.rst | 221 +- > Lib/bz2.py | 392 + > Lib/test/test_bz2.py | 142 +- > Misc/NEWS| 4 + > Modules/bz2module.c | 2281 - > PCbuild/bz2.vcproj | 4 +- > PCbuild/pcbuild.sln | 2 +- > PCbuild/readme.txt | 6 +- > setup.py | 4 +- ___ 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] Please revert autofolding of tracker edit form
How about something like http://andurin.com/python-issue-tracker/issue5863.htm but with proper click to expand js not css hover expansion since the pure css solution gets a little jumpy. Dj Gilcrease ( | \ o () | o |`| | | /`\_/| | | ,__ ,_, ,_, __, , ,_, _| | | / | | |/ / / | |_/ / | / \_|_/ (/\___/ |/ /(__,/ |_/|__/\___/ |_/|__/\__/|_/\,/ |__/ /| \| ___ 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] [Python-checkins] cpython (merge 3.2 -> default): Merge fix for issue #11746
On 4/3/2011 12:20 PM, antoine.pitrou wrote: > http://hg.python.org/cpython/rev/c11e05a60d36 > changeset: 69115:c11e05a60d36 > parent: 69113:ff105faf1bac > parent: 69114:88ed3de28520 > user:Antoine Pitrou > date:Sun Apr 03 18:16:50 2011 +0200 > summary: > Merge fix for issue #11746 > > files: > Misc/NEWS | 3 +++ > Modules/_ssl.c | 2 +- > 2 files changed, 4 insertions(+), 1 deletions(-) Test? ___ 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] [Python-checkins] cpython: Issue #5863: Rewrite BZ2File in pure Python, and allow it to accept
On Sun, 03 Apr 2011 18:55:33 +0200 Éric Araujo wrote: > Hi, > > > changeset: 69112:2cb07a46f4b5 > > user:Antoine Pitrou > > date:Sun Apr 03 17:05:46 2011 +0200 > > summary: > > Issue #5863: Rewrite BZ2File in pure Python, and allow it to accept > > file-like objects using a new `fileobj` constructor argument. Patch by > > Nadeem Vawda. > > > > files: > > Doc/ACKS.txt | 1 + > > I think we use Misc/ACKS for code+docs contribution like this one, > Doc/ACKS.txt being used for doc-only changes. This second file is not > comprehensive nor always used though, so maybe it should be superseded > by the former. Nadeem is already in Misc/ACKS. I don't know what the policy is for Doc/ACKS.txt, but since he added himself in the patch, I saw no good reason for reverting the change. +1 for merging these files by the way. 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] [Python-checkins] cpython (merge 3.2 -> default): Merge fix for issue #11746
On Sun, 03 Apr 2011 13:29:28 -0400 Eric Smith wrote: > On 4/3/2011 12:20 PM, antoine.pitrou wrote: > > http://hg.python.org/cpython/rev/c11e05a60d36 > > changeset: 69115:c11e05a60d36 > > parent: 69113:ff105faf1bac > > parent: 69114:88ed3de28520 > > user:Antoine Pitrou > > date:Sun Apr 03 18:16:50 2011 +0200 > > summary: > > Merge fix for issue #11746 > > > > files: > > Misc/NEWS | 3 +++ > > Modules/_ssl.c | 2 +- > > 2 files changed, 4 insertions(+), 1 deletions(-) > > Test? Good point. If someone knows how to generate elliptic curve keys, a patch for test_ssl.py is welcome. (the patch was trivial enough in itself to commit it) 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] Please revert autofolding of tracker edit form
Dj> How about something like Dj> http://andurin.com/python-issue-tracker/issue5863.htm but with Dj> proper click to expand js not css hover expansion since the pure css Dj> solution gets a little jumpy. That's part of it. Note the files list as well: bz2module-v1.diff nvawda, 2011-01-24 20:15... bz2module-v2.diff nvawda, 2011-01-25 17:07 bz2-v3.diff nvawda, 2011-01-30 14:12 bz2-doc.diffnvawda, 2011-02-05 20:31 bz2-v3b.diffnvawda, 2011-02-08 21:57 bz2-v4.diff nvawda, 2011-03-20 19:15 bz2-v4-doc.diff nvawda, 2011-03-20 19:18 bz2-v5.diff nvawda, 2011-04-02 07:34 bz2-v5-doc.diff nvawda, 2011-04-02 07:38 bz2-v6.diff nvawda, 2011-04-02 18:14 bz2-v6-doc.diff nvawda, 2011-04-02 18:14 It looks like there are seven versions of the bz2 patch and four versions of the doc patch. I think this list should be collapsed as well (ignoring that the author seems to have changed his mind about the name of the patch): bz2.diff > nvawda, 2011-04-02 18:14 bz2-doc.diff > nvawda, 2011-04-02 18:14 expanding the patch proper: bz2.diff v nvawda, 2011-04-02 18:14 bz2.diff nvawda, 2011-04-02 07:34 bz2.diff nvawda, 2011-03-20 19:15 ... bz2-doc.diff > nvawda, 2011-04-02 18:14 Skip ___ 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] Policy for making changes to the AST
On Sun, Apr 3, 2011 at 4:17 AM, Paul Moore wrote: > On 3 April 2011 07:55, "Martin v. Löwis" wrote: >>> 1. Do nothing. This will break code that currently uses AST, but doesn't add >>> any complexity to cpython. >> >> I'm in favor of this approach as well. Notice that there is >> ast.__version__ precisely so that applications can support multiple AST >> versions. > > This might be a suitable topic for a post to "Python Insider" - as > it's a policy question, that would make the discussion known to a > wider audience, giving people with an interest the opportunity to > comment. Hopefully, that also makes the "Do Nothing" approach more > acceptable to the wider Python community by publicising the > implications well in advance. > > If there are no objections (I'm conscious that we don't want every > python-dev discussion dumped onto Python Insider) I'll post a short > article once a consensus has been reached. Agreed, it would be good to know what people do with AST nodes before going too far. In the mean time, until we hear differently, I'm also in favor of #1 (do nothing). I would (perhaps redundantly) say that such changes should only go into new major releases (i.e. 3.3 right now), not backported into bugfix releases (e.g. 3.2.1). AFAIK the AST is CPython-specific so should be treated with the same attitude as changes to the bytecode. That means, do it conservatively, since there *are* people who like to write tools that manipulate or analyze this, and while they know they're doing something CPython and version-specific, they should not be broken by bugfix releases, since the people who *use* their code probably have no idea of the deep magic they're depending on. -- --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] Policy for making changes to the AST
On Sat, Apr 2, 2011 at 23:55, "Martin v. Löwis" wrote: > > 1. Do nothing. This will break code that currently uses AST, but doesn't > add > > any complexity to cpython. > > I'm in favor of this approach as well. Notice that there is > ast.__version__ precisely so that applications can support multiple AST > versions. > As someone who actually does use the AST (http://code.google.com/p/mnfy/), I am in favour of #1 thanks to ast.__version__. I actually have a version check in my code to make sure that if a change occurs my tests fail and I know I need to update things. > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ 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] [Python-checkins] cpython: Issue #5863: Rewrite BZ2File in pure Python, and allow it to accept
On Sun, Apr 3, 2011 at 8:02 PM, Antoine Pitrou wrote: > On Sun, 03 Apr 2011 18:55:33 +0200 > Éric Araujo wrote: >> I think we use Misc/ACKS for code+docs contribution like this one, >> Doc/ACKS.txt being used for doc-only changes. This second file is not >> comprehensive nor always used though, so maybe it should be superseded >> by the former. > > Nadeem is already in Misc/ACKS. I don't know what the policy is for > Doc/ACKS.txt, but since he added himself in the patch, I saw no good > reason for reverting the change. I added myself because I assumed the policy for Doc/ACKS.txt to be the same as the policy for Misc/ACKS - if you submit a patch, add your name. Looking at the devguide, though, I can't find any mention of Doc/ACKS.txt. > +1 for merging these files by the way. Sounds good to me. The intro at the top of Misc/ACKS is pretty broad, thanking people for all contributions (not just code). Unless there's some plan to split the documentation off into a separate repository, I can't think of any reason not to merge them. Regards, Nadeem ___ 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] [Python-checkins] cpython (merge 3.2 -> default): Merge fix for issue #11746
> Good point. If someone knows how to generate elliptic curve keys, a > patch for test_ssl.py is welcome. You can generate EC keys and certificates like this: openssl ecparam -out server.key -name secp112r2 -genkey openssl req -new -x509 -key server.key -out server.pem -subj /CN=www.test (see "openssl ecparam -list_curves" for a list of valid names) Regards, Martin ___ 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
[Python-Dev] Policy for versions of system python
Hello, CPython source code currently contains a number of python scripts (e.g Python/makeopcodetargets.py, Objects/typeslots.py, Parser/asdl_c.py) that are used during the build of the python interpreter itself. For this reason they are run with system installed python. What is the policy regarding the range of python versions that they should support? I looked at some of the scripts and they seem to support both 2 and 3, starting from at most 2.4. Python/makeopcodetargets.py says at the top: # This code should stay compatible with Python 2.3, at least while # some of the buildbots have Python 2.3 as their system Python. Is this the official minimal version or do we have this spelled out more explicitly somewhere? Eugene ___ 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] Policy for making changes to the AST
On Mon, Apr 4, 2011 at 5:11 AM, Guido van Rossum wrote: > In the mean time, until we hear differently, I'm also in favor of #1 > (do nothing). I would (perhaps redundantly) say that such changes > should only go into new major releases (i.e. 3.3 right now), not > backported into bugfix releases (e.g. 3.2.1). AFAIK the AST is > CPython-specific so should be treated with the same attitude as > changes to the bytecode. That means, do it conservatively, since there > *are* people who like to write tools that manipulate or analyze this, > and while they know they're doing something CPython and > version-specific, they should not be broken by bugfix releases, since > the people who *use* their code probably have no idea of the deep > magic they're depending on. Perhaps we should add a warning to the ast module docs similar to the one we have for the dis module, and use it to explicitly remind people to check ast.__version__ before proceeding with AST manipulation? Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Policy for making changes to the AST
On Sun, Apr 3, 2011 at 6:43 PM, Nick Coghlan wrote: > On Mon, Apr 4, 2011 at 5:11 AM, Guido van Rossum wrote: >> In the mean time, until we hear differently, I'm also in favor of #1 >> (do nothing). I would (perhaps redundantly) say that such changes >> should only go into new major releases (i.e. 3.3 right now), not >> backported into bugfix releases (e.g. 3.2.1). AFAIK the AST is >> CPython-specific so should be treated with the same attitude as >> changes to the bytecode. That means, do it conservatively, since there >> *are* people who like to write tools that manipulate or analyze this, >> and while they know they're doing something CPython and >> version-specific, they should not be broken by bugfix releases, since >> the people who *use* their code probably have no idea of the deep >> magic they're depending on. > > Perhaps we should add a warning to the ast module docs similar to the > one we have for the dis module, and use it to explicitly remind people > to check ast.__version__ before proceeding with AST manipulation? Sure, but do we have any indication that the warnings for dis make a difference? -- --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] Policy for making changes to the AST
On Mon, Apr 4, 2011 at 12:02 PM, Guido van Rossum wrote: >> Perhaps we should add a warning to the ast module docs similar to the >> one we have for the dis module, and use it to explicitly remind people >> to check ast.__version__ before proceeding with AST manipulation? > > Sure, but do we have any indication that the warnings for dis make a > difference? I know it makes *me* feel better when I commit anything that messes with the bytecode. I don't know how much it really matters to end users - bytecode hackery has been frowned upon for so long, the warning is probably somewhat redundant. Still, if we do articulate a clearer policy on the topic, it should be officially documented somewhere, and the AST module docs are probably the most discoverable of the available options. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Policy for making changes to the AST
On 4/2/2011 9:55 PM, Eugene Toder wrote: Documentation for ast module does not warn about possible changes, The current boxed warning at the top of the dis doc is fairly recent. The ast doc should gain something similar. It currently does say: "__version__ which is the decimal Subversion revision number of the file shown below." which clearly implies at ast details can change. I presume that sentence needs revision for hg. > but obviously changes can occur, for example, when new constructs are introduced. What about other changes? Is there a policy for what's acceptable and how this should be handled? Thanks for bringing this up. We need to be able to make changes to improve compilation as well as to add new features. -- Terry Jan Reedy ___ 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
