Re: [Python-Dev] Mercurial Schedule
Am 19.11.2010 03:23, schrieb Benjamin Peterson: > 2010/11/18 Jesus Cea : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 18/11/10 18:32, "Martin v. Löwis" wrote: >>> In general, I'm *also* concerned about the lack of volunteers that >>> are interested in working on the infrastructure. I wish some of the >>> people who stated that they can't wait for the migration to happen >>> would work on solving some of the remaining problems. >> >> Do we have a exhaustive list of mercurial "to do" things?. > > http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt This doesn't, but IMO should, list - resolve open issues in PEP - finalize and implement branch structure - set and implement policy for external code bases for Windows builds - set up account management infrastructure, determine account managers 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
[Python-Dev] sha digest endianness
Please see this defect: http://bugs.python.org/issue10430 It would appear that the digest and hexdigest for sha, is wrong on little endian machines. There certainly is a discrepancy between little and big endian ones, irrespective of which one is "right" Any thoughts? K ___ 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] Mercurial Schedule
On Fri, Nov 19, 2010 at 5:43 PM, Georg Brandl wrote: > Am 19.11.2010 03:23, schrieb Benjamin Peterson: >> 2010/11/18 Jesus Cea : >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 18/11/10 18:32, "Martin v. Löwis" wrote: In general, I'm *also* concerned about the lack of volunteers that are interested in working on the infrastructure. I wish some of the people who stated that they can't wait for the migration to happen would work on solving some of the remaining problems. >>> >>> Do we have a exhaustive list of mercurial "to do" things?. >> >> http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt > > Uh, that's the list of things to do *at* the migration. The todo list is > > http://hg.python.org/pymigr/file/1576eb34ec9f/todo.txt That kind of link is the sort of thing that should really be in the PEP... (along with the info about where to find the hooks repository, specific URLs for at least 3.x, 3.1 and 2.7, pointers to a draft FAQ to replace the current SVN focused FAQ, etc) Target dates for the following specific activities would also be useful: - date a "final draft" of converted repository will be made available to Martin and Ronald to dry run creation of Windows and Mac OS X installers - date SVN will go read only - date Hg will be available for write access (it should be frozen for a while, to give the folks doing the conversion a chance to make sure buildbot is back up and run, commit emails are working properly, etc) So as long as we acknowledge that any migration problems may mean additional beta releases of 3.2 to iron things out, I don't see a problem with releasing beta 1 as planned to close the door on any *other* new features, and giving the Hg migration a clear run at the source repository before we start working seriously on dealing with bug reports (either existing ones, or those from the first beta). 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] Mercurial Schedule
> - date Hg will be available for write access (it should be frozen for > a while, to give the folks doing the conversion a chance to make sure > buildbot is back up and run, commit emails are working properly, etc) I would target the build slaves to the Mercurial repository already in the testing phase, e.g by creating builders for building from commits to the 3k branch. I hope Buildbot supports multiple change sources now. Likewise, I'd also see commit emails being delivered in the test phase already, and let committers make test commits to trigger this all (and also to get acquainted with the Mercurial tools they are going to use, without fear of breaking something). 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] Mercurial Schedule
On Nov 19, 2010, at 11:50 PM, Nick Coghlan wrote: >- date SVN will go read only Please note that svn cannot be made completely read-only. We've already decided that versions already in maintenance or security-only mode (2.5, 2.6, 2.7, 3.1) will get updates and releases only via svn. But only the release managers should have write access to the svn repositories. -Barry signature.asc Description: 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] Mercurial Schedule
On Sat, Nov 20, 2010 at 12:46 AM, Barry Warsaw wrote: > On Nov 19, 2010, at 11:50 PM, Nick Coghlan wrote: > >>- date SVN will go read only > > Please note that svn cannot be made completely read-only. We've already > decided that versions already in maintenance or security-only mode (2.5, 2.6, > 2.7, 3.1) will get updates and releases only via svn. But only the release > managers should have write access to the svn repositories. Again, something that should be in PEP 385 (but isn't). It seems that the work *is* going on, and the people actually doing it have a reasonable idea as to what has been decided and where things are going, but those of us "out here" have a fair stake in this as well, and without an up to date PEP 385 there's no one place to go to to see the current state of the migration. That's enough to make folks like me somewhat nervous as to whether or not we're actually going to have a usable source control system come December 12. 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] Mercurial Schedule
On Fri, Nov 19, 2010 at 15:56, Nick Coghlan wrote: > That's enough to make folks like me somewhat nervous as to whether or > not we're actually going to have a usable source control system come > December 12. Yes, I've been negligent about updating the PEP. I'll try do so next week. Georg, if you have time to update it a bit, that would be great as well. Cheers, Dirkjan ___ 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] Mercurial Schedule
Am 19.11.2010 08:58, schrieb "Martin v. Löwis": > Am 19.11.2010 03:23, schrieb Benjamin Peterson: >> 2010/11/18 Jesus Cea : >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 18/11/10 18:32, "Martin v. Löwis" wrote: In general, I'm *also* concerned about the lack of volunteers that are interested in working on the infrastructure. I wish some of the people who stated that they can't wait for the migration to happen would work on solving some of the remaining problems. >>> >>> Do we have a exhaustive list of mercurial "to do" things?. >> >> http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt > > This doesn't, but IMO should, list > > - resolve open issues in PEP > - finalize and implement branch structure > - set and implement policy for external code bases for Windows builds > - set up account management infrastructure, determine account managers Good points, I've added the missing ones to the todo list. 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] Mercurial Schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2010 7:50 AM, Nick Coghlan wrote: > On Fri, Nov 19, 2010 at 5:43 PM, Georg Brandl wrote: >> Am 19.11.2010 03:23, schrieb Benjamin Peterson: >>> 2010/11/18 Jesus Cea : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/11/10 18:32, "Martin v. Löwis" wrote: > In general, I'm *also* concerned about the lack of volunteers that > are interested in working on the infrastructure. I wish some of the > people who stated that they can't wait for the migration to happen > would work on solving some of the remaining problems. Do we have a exhaustive list of mercurial "to do" things?. >>> >>> http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt >> >> Uh, that's the list of things to do *at* the migration. The todo list is >> >> http://hg.python.org/pymigr/file/1576eb34ec9f/todo.txt > > That kind of link is the sort of thing that should really be in the > PEP... (along with the info about where to find the hooks repository, > specific URLs for at least 3.x, 3.1 and 2.7, pointers to a draft FAQ > to replace the current SVN focused FAQ, etc) > Well, if it goes in the pep, you should at least use the 'always the most recent' version :) http://hg.python.org/pymigr/file/tip/todo.txt John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzmp/gACgkQJdeBCYSNAAOwjgCeOda2XeNvxOR0UnFuQOfN0zZt jGIAoIuarrvIz3oQ+o1jtnH5dFoFk35t =JJo8 -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] Mercurial Schedule
Am 19.11.2010 16:00, schrieb Dirkjan Ochtman: > On Fri, Nov 19, 2010 at 15:56, Nick Coghlan wrote: >> That's enough to make folks like me somewhat nervous as to whether or >> not we're actually going to have a usable source control system come >> December 12. > > Yes, I've been negligent about updating the PEP. I'll try do so next > week. Georg, if you have time to update it a bit, that would be great > as well. I'm at it. In fact, I think I will merge both todo.txt and tasks.txt into the PEP. It's not more of a burden to update it there, and it's more visible to the developer community. 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
[Python-Dev] len(chr(i)) = 2?
I was recently surprised to learn that chr(i) can produce a string of length 2 in python 3.x. I suspect that I am not alone finding this behavior non-obvious given that a mistake in Python manual stating the contrary survived several releases. [1] Note that I am not arguing that the change was bad. In Python 2.x, \U escapes have been producing surrogate pair on narrow builds for a long time if not since introduction of unicode. I do believe, however that a change like this [2] and its consequences should be better publicized. I have not found any discussion of this change in PEPs or "What's new" documents. The closest find was a mentioning of a related issue #3280 in the 3.0 NEWS file. [3] Since this feature will be first documented in the Library Reference in 3.2, I wonder if it will be appropriate to mention it in "What's new in 3.2"? [1] http://bugs.python.org/issue7828 [2] http://svn.python.org/view?view=rev&revision=56395 [3] http://www.python.org/download/releases/3.0.1/NEWS.txt ___ 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] Mercurial Schedule
Am 19.11.2010 15:36, schrieb "Martin v. Löwis": >> - date Hg will be available for write access (it should be frozen for >> a while, to give the folks doing the conversion a chance to make sure >> buildbot is back up and run, commit emails are working properly, etc) > > I would target the build slaves to the Mercurial repository already in > the testing phase, e.g by creating builders for building from commits > to the 3k branch. I hope Buildbot supports multiple change sources now. > Likewise, I'd also see commit emails being delivered in the test phase > already, and let committers make test commits to trigger this all (and > also to get acquainted with the Mercurial tools they are going to use, > without fear of breaking something). I've already let my Mercurial buildbot configuration run for a few checkins while testing it; a separate changesource was not needed. The commit email hook also has been tested extensively by its usage for the distutils2 repo, which are also sent to python-checkins. That said, it will of course be nice to activate both for the test repo as well, once it's available. 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-11-12 - 2010-11-19) 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: open2549 (+23) closed 19694 (+43) total 22243 (+66) Open issues with patches: 1058 Issues opened (43) == #2571: cmd.py always uses raw_input, even when another stdin is speci http://bugs.python.org/issue2571 reopened by eric.araujo #4153: Unicode HOWTO up to date? http://bugs.python.org/issue4153 reopened by belopolsky #6941: Socket error when launching IDLE http://bugs.python.org/issue6941 reopened by 08jpurcell #10356: decimal.py: hash of -1 http://bugs.python.org/issue10356 reopened by rhettinger #10399: AST Optimization: inlining of function calls http://bugs.python.org/issue10399 opened by dmalcolm #10401: Globals / builtins cache http://bugs.python.org/issue10401 opened by pitrou #10402: sporadic test_bsddb3 failures http://bugs.python.org/issue10402 opened by pitrou #10403: Use "member" consistently http://bugs.python.org/issue10403 opened by fdrake #10404: IDLE on OS X popup menus do not work: cannot set/clear breakpo http://bugs.python.org/issue10404 opened by ned.deily #10405: IDLE breakpoint facility undocumented http://bugs.python.org/issue10405 opened by ned.deily #10406: IDLE 2.7 on OS X does not enable Rstrip extension by default http://bugs.python.org/issue10406 opened by ned.deily #10407: missing errno import in distutils/dir_util.py http://bugs.python.org/issue10407 opened by zbysz #10408: Denser dicts and linear probing http://bugs.python.org/issue10408 opened by pitrou #10415: readline.insert_text documentation incomplete http://bugs.python.org/issue10415 opened by Justin.Lebar #10417: unittest triggers UnicodeEncodeError with non-ASCII character http://bugs.python.org/issue10417 opened by jammon #10419: distutils command build_scripts fails with UnicodeDecodeError http://bugs.python.org/issue10419 opened by hagen #10420: Document of Bdb.effective is wrong. http://bugs.python.org/issue10420 opened by naoki #10423: s/args/options in arpgarse "Upgrading optparse code" http://bugs.python.org/issue10423 opened by bethard #10424: better error message from argparse when positionals missing http://bugs.python.org/issue10424 opened by bethard #10427: 24:00 Hour in DateTime http://bugs.python.org/issue10427 opened by ingo.janssen #10430: _sha.sha().digest() method is endian-sensitive. and hexdigest( http://bugs.python.org/issue10430 opened by krisvale #10433: Document unique behavior of 'getgroups' on OSX http://bugs.python.org/issue10433 opened by r.david.murray #10434: Document the rules for "public names" http://bugs.python.org/issue10434 opened by belopolsky #10435: Document unicode C-API in reST http://bugs.python.org/issue10435 opened by belopolsky #10436: tarfile.extractfile in "r|" stream mode fails with filenames o http://bugs.python.org/issue10436 opened by David.Nesting #10437: ThreadPoolExecutor should accept max_workers=None http://bugs.python.org/issue10437 opened by stutzbach #10438: list an example for calling static methods from WITHIN classes http://bugs.python.org/issue10438 opened by ifreecarve #10439: PyCodec C API is not documented in reST http://bugs.python.org/issue10439 opened by belopolsky #10441: some stdlib modules need to be updated to handle SSL certifica http://bugs.python.org/issue10441 opened by db #10444: A mechanism is needed to override waiting for Python threads t http://bugs.python.org/issue10444 opened by michaelahughes #10446: pydoc3 links to 2.x library reference http://bugs.python.org/issue10446 opened by belopolsky #10448: Add Mako template benchmark to Python Benchmark Suite http://bugs.python.org/issue10448 opened by bobbyi #10449: âos.environ was modified by test_httpserversâ http://bugs.python.org/issue10449 opened by eric.araujo #10450: Fix markup in Misc/NEWS http://bugs.python.org/issue10450 opened by eric.araujo #10451: memoryview can be used to write into readonly buffer http://bugs.python.org/issue10451 opened by abacabadabacaba #10453: Add -h/--help option to compileall http://bugs.python.org/issue10453 opened by eric.araujo #10454: Clarify compileall command-line options http://bugs.python.org/issue10454 opened by eric.araujo #10457: "Related help topics" shown outside pager http://bugs.python.org/issue10457 opened by cben #10458: 2.7 += re.ASCII http://bugs.python.org/issue10458 opened by hfuru #10459: missing character names in unicodedata (CJK...) http://bugs.python.org/issue10459 opened by vbr #10460: Misc/indent.pro does not reflect PEP 7 http://bugs.python.org/issue10460 opened by Mick.Beaver #10461: Use with statement throughout the docs http://bugs.python.org/issue10461 opened by eric.araujo #10445: _ast py3k : add lineno back to "args" node http://bugs.python.org/issue10445 opened by emile.anclin
Re: [Python-Dev] Mercurial Schedule
Am 19.11.2010 15:46, schrieb Barry Warsaw: > On Nov 19, 2010, at 11:50 PM, Nick Coghlan wrote: > >>- date SVN will go read only > > Please note that svn cannot be made completely read-only. We've already > decided that versions already in maintenance or security-only mode (2.5, 2.6, > 2.7, 3.1) will get updates and releases only via svn. But only the release > managers should have write access to the svn repositories. Really? I can understand this for security-only branches (commits there will be rare, and equivalent commits to the Mercurial branches can be made by others than the release managers, in order to keep history consistent). But having the maintenance branches (by then, that will mostly be 2.7 because 3.1 will go to security-only mode soon) in SVN will be a burden for every developer, since they have to backport bugfixes from Hg to SVN... 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] len(chr(i)) = 2?
On Fri, 19 Nov 2010 11:53:58 -0500 Alexander Belopolsky wrote: > Since this feature will be first documented in the > Library Reference in 3.2, I wonder if it will be appropriate to > mention it in "What's new in 3.2"? No, since it's not new in 3.2. No need to further confuse users. If there's a porting guide to 3.x it should be mentioned there. 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] Mercurial Schedule
On Nov 19, 2010, at 06:12 PM, Georg Brandl wrote: >Am 19.11.2010 15:46, schrieb Barry Warsaw: >> On Nov 19, 2010, at 11:50 PM, Nick Coghlan wrote: >> >>>- date SVN will go read only >> >> Please note that svn cannot be made completely read-only. We've already >> decided that versions already in maintenance or security-only mode (2.5, 2.6, >> 2.7, 3.1) will get updates and releases only via svn. But only the release >> managers should have write access to the svn repositories. > >Really? I can understand this for security-only branches (commits there will >be rare, and equivalent commits to the Mercurial branches can be made by >others than the release managers, in order to keep history consistent). > >But having the maintenance branches (by then, that will mostly be 2.7 because >3.1 will go to security-only mode soon) in SVN will be a burden for every >developer, since they have to backport bugfixes from Hg to SVN... Maybe I misremembered Martin's suggestion, and he was only talking about security releases. I think the key thing is whether you're going to backport the vcs related bits to stable releases. I plan to only do releases for 2.6 from svn, because it's not worth breaking things like sys.subversion, and as you say the number of commits will be small. -Barry signature.asc Description: 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] Mercurial Schedule
On Fri, 19 Nov 2010 12:41:58 -0500 Barry Warsaw wrote: > >Really? I can understand this for security-only branches (commits there will > >be rare, and equivalent commits to the Mercurial branches can be made by > >others than the release managers, in order to keep history consistent). > > > >But having the maintenance branches (by then, that will mostly be 2.7 because > >3.1 will go to security-only mode soon) in SVN will be a burden for every > >developer, since they have to backport bugfixes from Hg to SVN... > > Maybe I misremembered Martin's suggestion, and he was only talking about > security releases. I think the key thing is whether you're going to backport > the vcs related bits to stable releases. It would be horribly burdensome to use two different VCSes depending on whether you're working on a bugfix branch or a feature branch. > I plan to only do releases for 2.6 from svn, because it's not worth breaking > things like sys.subversion, and as you say the number of commits will be > small. But 2.6 is security-fixes only, right? It would really be annoying if the same rules applied for 2.7 and 3.1. I don't understand all the worry about sys.subversion. It's not like it's useful to anybody else than us, and I think it should have been named sys._subversion instead. There's no point in making API-like promises about which DVCS, bug tracker or documentation toolset we use for our workflow. 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] Mercurial Schedule
> I don't understand all the worry about sys.subversion. It's not like > it's useful to anybody else than us, and I think it should have been > named sys._subversion instead. There's no point in making API-like > promises about which DVCS, bug tracker or documentation toolset we use > for our workflow. I read “subversion” as “sub-piece of information about version”, not the name of a VCS, so I have no problem with its continuing existence under Mercurial (it’s in PEP 385). Regards ___ 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] Mercurial Schedule
On Fri, Nov 19, 2010 at 05:50, Nick Coghlan wrote: > On Fri, Nov 19, 2010 at 5:43 PM, Georg Brandl wrote: >> Am 19.11.2010 03:23, schrieb Benjamin Peterson: >>> 2010/11/18 Jesus Cea : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/11/10 18:32, "Martin v. Löwis" wrote: > In general, I'm *also* concerned about the lack of volunteers that > are interested in working on the infrastructure. I wish some of the > people who stated that they can't wait for the migration to happen > would work on solving some of the remaining problems. Do we have a exhaustive list of mercurial "to do" things?. >>> >>> http://hg.python.org/pymigr/file/1576eb34ec9f/tasks.txt >> >> Uh, that's the list of things to do *at* the migration. The todo list is >> >> http://hg.python.org/pymigr/file/1576eb34ec9f/todo.txt > > That kind of link is the sort of thing that should really be in the > PEP... (along with the info about where to find the hooks repository, > specific URLs for at least 3.x, 3.1 and 2.7, pointers to a draft FAQ > to replace the current SVN focused FAQ, etc) I am spending my PSF grant time in January rewriting python.org/dev practically from scratch. Any needed updates to take Mercurial in account will happen no later than then. -Brett > > Target dates for the following specific activities would also be useful: > - date a "final draft" of converted repository will be made available > to Martin and Ronald to dry run creation of Windows and Mac OS X > installers > - date SVN will go read only > - date Hg will be available for write access (it should be frozen for > a while, to give the folks doing the conversion a chance to make sure > buildbot is back up and run, commit emails are working properly, etc) > > So as long as we acknowledge that any migration problems may mean > additional beta releases of 3.2 to iron things out, I don't see a > problem with releasing beta 1 as planned to close the door on any > *other* new features, and giving the Hg migration a clear run at the > source repository before we start working seriously on dealing with > bug reports (either existing ones, or those from the first beta). > > 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/brett%40python.org > ___ 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] len(chr(i)) = 2?
Hi, On Friday 19 November 2010 17:53:58 Alexander Belopolsky wrote: > I was recently surprised to learn that chr(i) can produce a string of > length 2 in python 3.x. Yes, but only on narrow build. Eg. Debian and Ubuntu compile Python 3.1 in wide mode (sys.maxunicode == 1114111). > I suspect that I am not alone finding this behavior non-obvious > given that a mistake in Python manual stating the contrary survived > several releases. [1] It was a documentation bug and you fixed it. Non-BMP characters are rare, so few (maybe only you?) noticed the documentation bug. I consider the behaviour as an improvment of non-BMP support of Python3. Python is unclear about non-BMP characters: narrow build was called "ucs2" for long time, even if it is UTF-16 (each character is encoded to one or two UTF-16 words). Python2 accepts non-BMP characters with \U syntax, but not with chr(). This is inconsistent and I see this as a bug. But I don't want to touch Python2 about non-BMP characters, and the "bug" is already fixed in Python3! > I do believe, however that a change like > this [2] and its consequences should be better publicized. Change made before the release of Python 3.0. Do you want to patch the "What's new in Python 3.0?" document? > I have not > found any discussion of this change in PEPs or "What's new" documents. > The closest find was a mentioning of a related issue #3280 in the 3.0 > NEWS file. [3] Since this feature will be first documented in the > Library Reference in 3.2, I wonder if it will be appropriate to > mention it in "What's new in 3.2"? In my opinion, the question is more what was it not fixed in Python2. I suppose that the answer is something ugly like "backward compatibility" or "historical reasons" :-) 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] Mercurial Schedule
> Maybe I misremembered Martin's suggestion, and he was only talking about > security releases. Technically, I was only talking about 2.5. For each branch, the respective release manager should make a decision. For 2.5 and 2.6, it's been decided; Benjamin has not yet announced plans how 2.7 and 3.1 will be maintained after the switchover. 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] Mercurial Schedule
> I don't understand all the worry about sys.subversion. Really? For a security release, there should be *zero* chance that it breaks existing applications, unless the application relies on the security bug that has been fixed. By "zero chance", I mean absolutely no chance, never. I'm pretty sure that applications *will* break because of the change to sys.subversion, or sys.version. People made bug reports complaining that sys.version has a newline on some systems and not on others. > It's not like > it's useful to anybody else than us I think you underestimate what API people actually use in applications http://tinyurl.com/292vhxx http://tinyurl.com/23ah8ps http://tinyurl.com/27fhyvk http://tinyurl.com/28cuyv9 etc. 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] Mercurial Schedule
Am 19.11.2010 22:35, schrieb "Martin v. Löwis": >> I don't understand all the worry about sys.subversion. > > Really? For a security release, there should be *zero* chance that it > breaks existing applications, unless the application relies on the > security bug that has been fixed. By "zero chance", I mean absolutely > no chance, never. I'm pretty sure that applications *will* break because > of the change to sys.subversion, or sys.version. People made bug reports > complaining that sys.version has a newline on some systems and not on > others. > >> It's not like >> it's useful to anybody else than us > > I think you underestimate what API people actually use in applications > > http://tinyurl.com/292vhxx > http://tinyurl.com/23ah8ps > http://tinyurl.com/27fhyvk > http://tinyurl.com/28cuyv9 > etc. Well, it should not be a problem to continue to provide a sys.subversion that at least will not break applications reading it. And yes, I am in favor of giving the new attribute a leading underscore. 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] Mercurial Schedule
Le vendredi 19 novembre 2010 à 22:35 +0100, "Martin v. Löwis" a écrit : > > I don't understand all the worry about sys.subversion. > > Really? For a security release, there should be *zero* chance that it > breaks existing applications, It should have been clear that my message explicitly excluded security releases. 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] len(chr(i)) = 2?
> In my opinion, the question is more what was it not fixed in Python2. I > suppose > that the answer is something ugly like "backward compatibility" or > "historical > reasons" :-) No, there was a deliberate decision to not support that, see http://www.python.org/dev/peps/pep-0261/ There had been a long discussion on this specific detail when PEP 261 was written, and in the end, an explicit, deliberate, considered decision was made to raise a ValueError. 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] [Python-checkins] r86530 - python/branches/py3k/Doc/howto/unicode.rst
Hi,
On 19/11/2010 18.10, alexander.belopolsky wrote:
Author: alexander.belopolsky
Date: Fri Nov 19 17:09:58 2010
New Revision: 86530
Log:
Issue #4153: Updated Unicode HOWTO.
Modified:
python/branches/py3k/Doc/howto/unicode.rst
Modified: python/branches/py3k/Doc/howto/unicode.rst
==
--- python/branches/py3k/Doc/howto/unicode.rst (original)
+++ python/branches/py3k/Doc/howto/unicode.rst Fri Nov 19 17:09:58 2010
[...]
-Python 2.x's Unicode Support
-
+Python's Unicode Support
+
Now that you've learned the rudiments of Unicode, we can look at Python's
Unicode features.
@@ -265,7 +263,7 @@
UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position 0:
unexpected code byte
>>> b'\x80abc'.decode("utf-8", "replace")
-'\ufffdabc'
+'�abc'
Apparently 'make latex' and 'make all-pdf' don't like this char.
>>> b'\x80abc'.decode("utf-8", "ignore")
'abc'
[...]
Best Regards,
Ezio Melotti
___
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] Mercurial Schedule
2010/11/19 "Martin v. Löwis" : >> Maybe I misremembered Martin's suggestion, and he was only talking about >> security releases. > > Technically, I was only talking about 2.5. For each branch, the > respective release manager should make a decision. For 2.5 and 2.6, > it's been decided; Benjamin has not yet announced plans how 2.7 and 3.1 > will be maintained after the switchover. I propose that they follow the development branches over to hg. Having to backport bug fixes with any frequency from hg to svn would probably be more unpleasant than the current svnmerge situation. -- 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] len(chr(i)) = 2?
Victor Stinner wrote: > Hi, > > On Friday 19 November 2010 17:53:58 Alexander Belopolsky wrote: >> I was recently surprised to learn that chr(i) can produce a string of >> length 2 in python 3.x. > > Yes, but only on narrow build. Eg. Debian and Ubuntu compile Python 3.1 in > wide mode (sys.maxunicode == 1114111). > >> I suspect that I am not alone finding this behavior non-obvious >> given that a mistake in Python manual stating the contrary survived >> several releases. [1] > > It was a documentation bug and you fixed it. Non-BMP characters are rare, so > few (maybe only you?) noticed the documentation bug. I consider the behaviour > as an improvment of non-BMP support of Python3. > > Python is unclear about non-BMP characters: narrow build was called "ucs2" > for > long time, even if it is UTF-16 (each character is encoded to one or two > UTF-16 words). No, no, no :-) UCS2 and UCS4 are more appropriate than "narrow" and "wide" or even "UTF-16" and "UTF-32". It'S rather common to confuse a transfer encoding with a storage format. UCS2 and UCS4 refer to code units (the storage format). You can use UCS2 and UCS4 code units to represent UTF-16 and UTF-32 resp., but those are not the same things. In UTF-16 0xD800 has a special meaning, in UCS2 it doesn't. Python uses UCS2 internally. It does not assign a special meaning to those surrogate code point ranges. However, when it comes to codecs, we do try to make use of the fact that UCS2 can easily be used to represent an UTF-16 encoding and that's why you often see surrogates being created for code points that wouldn't otherwise fit into UCS2 and you see those surrogates being converted back to single code units in UCS4 builds. I don't know who invented the terms "narrow" and "wide" builds for Python3. Not me that's for sure :-) They don't have any meaning in Unicode terminology and thus cause even more confusion than UCS2 and UCS4. E.g. the import errors you get when importing extensions built for a different Unicode version, (correctly) refer to UCS2 vs. UCS4 and now give even less of a clue that they relate to difference in Unicode builds (since these are now labeled "narrow" and "wide"). IMO, we should go back to the Python2 terms UCS2 and UCS4 which are correct and provide a clear description of what Python uses internally for code units. > Python2 accepts non-BMP characters with \U syntax, but not with > chr(). This is inconsistent and I see this as a bug. But I don't want to > touch > Python2 about non-BMP characters, and the "bug" is already fixed in Python3! > >> I do believe, however that a change like >> this [2] and its consequences should be better publicized. > > Change made before the release of Python 3.0. Do you want to patch the > "What's > new in Python 3.0?" document? Perhaps add a section "What we forgot to mention in 3.0" or "What's not so new in 3.2" to "What's new in 3.2" :-) >> I have not >> found any discussion of this change in PEPs or "What's new" documents. >> The closest find was a mentioning of a related issue #3280 in the 3.0 >> NEWS file. [3] Since this feature will be first documented in the >> Library Reference in 3.2, I wonder if it will be appropriate to >> mention it in "What's new in 3.2"? > > In my opinion, the question is more what was it not fixed in Python2. I > suppose > that the answer is something ugly like "backward compatibility" or > "historical > reasons" :-) Backwards compatibility. Python2 applications don't expect unichr(i) to return anything other than a single character. If you need this in Python2, it's easy enough to get around, though, with a little helper function. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 19 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] len(chr(i)) = 2?
> It'S rather common to confuse a transfer encoding with a storage format. > UCS2 and UCS4 refer to code units (the storage format). Actually, they don't. Instead, they refer to "coded character sets", in W3C terminology: mapping of characters to natural numbers. See http://unicode.org/faq/basic_q.html#14 The term "UCS-2" is a character set that can encode only encode 65536 characters; it thus refers to Unicode 1.1. According to the Unicode Consortium's FAQ, the term UCS-2 should be avoided these days. > IMO, we should go back to the Python2 terms UCS2 and UCS4 which > are correct and provide a clear description of what Python uses > internally for code units. No, we shouldn't. The term UCS-2 is deprecated, see above. 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
[Python-Dev] Web servers, bytes, str, documentation, Python 3.2a4
So maybe this is the wrong forum, if so please tell me what the right
forum is for each of the various pieces. I'm assuming that I should
file some bugs in the tracker, but I'm not exactly sure whether to file
them on cgitb, http.server, or subprocess, or all of the above. Pretty
sure there are at least some in http.server, but maybe some of those
will be considered "enhancement requests" since they are long
outstanding in the predecessor code.
So I've been writing CGI scripts in Python behind Apache. No framework,
just raw CGI.
Got everything working on Python 2.6 (it's the newest that the hosting
company has). Whacked at 2.6's CGIHTTPServer.py until I got an
environment that would actually run CGI programs in the same sort of way
that Apache does, so I can test faster, locally. Got the site working.
Am happy.
Now I decided to tackle porting the code to Python 3, in hopes that
someday the hosting company might have it, and to see what I could learn
about the "Subject:" matters, and to altruistically see if 3.2a4 has a
consistent story. Um. Well. Some of me, Python 3.2a4, or its
documentation is missing something. Maybe several somethings.
Here's some code to ponder.
import sys
import traceback
sys.stdout = open("sob", "wb") # WSGI sez data should be binary, so
stdout should be binary???
import cgitb
sys.stdout.write(b"out")
fhb = open("fhb", "wb")
cgitb.enable(0,"d:\temp")
fhb.write("abcdef") # try writing non-binary to binary file. Expect an
error, of course.
Feed it to python32...
d:\temp>c:\python32\python.exe test11.py
Error in sys.excepthook:
TypeError: 'str' does not support the buffer interface
Original exception was:
Traceback (most recent call last):
File "d:\my\py\test11.py", line 8, in
fhb.write("abcdef") # try writing non-binary to binary file.
Expect an err
or, of course.
TypeError: 'str' does not support the buffer interface
So it seems that cgitb can't write to binary files, to report the
error? Or how else should I interpret the Error in sys.excepthook ?
So then I tweaked the code for cgitb's enjoyment:
import sys
import traceback
sys.stdout = open("sob", "w", encoding="UTF-8") # WSGI sez data should
be binary, so stdout should be binary???
import cgitb
sys.stdout.write("out")
fhb = open("fhb", "wb")
cgitb.enable(0,"d:\temp")
fhb.write("abcdef") # try writing non-binary to binary file. Expect an
error, of course.
Now I get the following report in the stdout file:
out
--> -->
A
problem occurred in a Python script.
and the following error on the console:
d:\temp>c:\python32\python.exe test12.py
Error in sys.excepthook:
Traceback (most recent call last):
File "c:\python32\lib\tempfile.py", line 209, in _mkstemp_inner
fd = _os.open(file, flags, 0o600)
OSError: [Errno 22] Invalid argument
Original exception was:
Traceback (most recent call last):
File "d:\my\py\test12.py", line 8, in
fhb.write("abcdef") # try writing non-binary to binary file.
Expect an error, of course.
TypeError: 'str' does not support the buffer interface
I was expecting see a whole cgitb in sob, but no such luck. Not sure
why it is trying to create a temporary file, but it seems to fail to do
that.
Of course, the next test, would have been to write binary data into fhb,
and try to copy it to stdout, which would fail, because stdout has to
not be binary to make cgitb work???
That brings me to http.server, the 3.2a4 replacement for CGIHTTPServer.
There are definitely some improvements here, and some
reported-but-yet-unfixed bugs. And some pitiful missing features,
especially on Windows. I applied some of the whacks I had applied to
CGIHTTPServer, and got some things working, but, per what I was trying
to demonstrate above, there seems to be an incompatibility with the idea
of using cgitb (which wants stdout open with some encoding provided) and
serving binary files (which wants stdout open in binary) [this latter is
supported by the WSGI spec too].
So it seems to be that there are some problems. Yet, it seems that
http.server can some accept the data sent by cgitb, which comes from
subprocess running my CGI script, but my CGI script fails to be able to
copy a binary file to its stdout (a subprocess created PIPE). The
subprocess documentation doesn't say what encoding is supplied to the
PIPE-created handles, if any, but since cgitb data is accepted but
binary file data is not, I infer it must be a non-binary handle,
encoding unknown. The subprocess documentation doesn't document any way
to specify what encoding should be used on the PIPE-created handles,
either. So this isn't very enlightening. In the absence of a
specification or parameter, I would have expected the PIPEs to be
binary, but this seems to be experimentally false.
Yet http.server, when serving plain files, seems to open them in binary
mode, and transfer them successfully to the browser. And it can also
accept th
Re: [Python-Dev] len(chr(i)) = 2?
"Martin v. Löwis" writes: > The term "UCS-2" is a character set that can encode only encode 65536 > characters; it thus refers to Unicode 1.1. According to the Unicode > Consortium's FAQ, the term UCS-2 should be avoided these days. So what do you propose we call the Python implementation? You can call it "code-unit-oriented" if you like, but in fact it is identical to UCS-2 for all non-hairsplitting purposes. AFAICS the Unicode Consortium deprecates the *term* UCS-2 because they would like us to avoid *implementations* that don't encode the full Unicode character set, not because the term is technically incorrect. Strictly speaking, internally Python only encodes 65536 characters in 2-octet builds. Its (Unicode) string-handling code does not know about surrogates at all, AFAIK, and therefore is not UTF-16 conforming. (The anomolies discussed here are type transformations, not string-handling, for my purpose.) I really don't see why we shouldn't call a UCS-2 implementation by its name. AFAIK this was not supposed to change in Python 3; indexing and slicing go by code unit (isomorphic to UCS-n), not character, and due to PEP 383 4-octet builds do not conform (internally) to UTF-32, and can produce output that conforms to Unicode not at all (as a user option, of course, but it's still non-conformant). > > IMO, we should go back to the Python2 terms UCS2 and UCS4 which > > are correct and provide a clear description of what Python uses > > internally for code units. > > No, we shouldn't. The term UCS-2 is deprecated, see above. Too bad for the Unicode Consortium, I say. UCS-2 is the closest term that folks who are not Unicode geeks will have a chance of understanding. I agree with Marc-Andre that "narrow" and "wide" are too ambiguous to be useful. Many people will interpret that as "UTF-16" (or even "UTF-8") and "UTF-32", respectively, which is dead wrong. Others won't have a clue. Using "UCS-2" and "UCS-4" has the correct connotations to Unicode geeks, and they are easy to look up for non-geeks who care about precise definitions. Cf. the second half of the FAQ you quote: Instead, "UCS-2" has sometimes been used in the past to indicate that an implementation does not support supplementary characters and doesn't interpret pairs of surrogate code points as characters. Such an implementation would not handle processing like character properties, codepoint boundaries, collation, etc. for supplementary characters. "Hey, Python, I'm looking at you!" (Strictly speaking, Python libraries do some of that for us, but the Python *language* does not.) ___ 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] r86540 - in python/branches/py3k: Parser/asdl_c.py Python/Python-ast.c
On Fri, Nov 19, 2010 at 20:01, benjamin.peterson wrote:
> Author: benjamin.peterson
> Date: Sat Nov 20 03:01:45 2010
> New Revision: 86540
>
> Log:
> c89 declarations
>
> Modified:
> python/branches/py3k/Parser/asdl_c.py
> python/branches/py3k/Python/Python-ast.c
>
> Modified: python/branches/py3k/Parser/asdl_c.py
>
> ==
> --- python/branches/py3k/Parser/asdl_c.py (original)
> +++ python/branches/py3k/Parser/asdl_c.py Sat Nov 20 03:01:45 2010
> @@ -366,9 +366,9 @@
> self.emit("obj2ast_%s(PyObject* obj, %s* out, PyArena* arena)" %
> (name, ctype), 0)
> self.emit("{", 0)
> self.emit("PyObject* tmp = NULL;", 1)
> +self.emit("int isinstance;", 1)
> # Prevent compiler warnings about unused variable.
> self.emit("tmp = tmp;", 1)
> -self.emit("int isinstance;", 1)
> self.emit("", 0)
>
> def sumTrailer(self, name, add_label=False):
>
> Modified: python/branches/py3k/Python/Python-ast.c
>
> ==
> --- python/branches/py3k/Python/Python-ast.c(original)
> +++ python/branches/py3k/Python/Python-ast.cSat Nov 20 03:01:45 2010
> @@ -3375,8 +3375,8 @@
> obj2ast_mod(PyObject* obj, mod_ty* out, PyArena* arena)
> {
> PyObject* tmp = NULL;
> -tmp = tmp;
> int isinstance;
> +tmp = tmp;
Windows builds fail due to this change.
___
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] Web servers, bytes, str, documentation, Python 3.2a4
On 11/19/2010 7:48 PM, Glenn Linderman wrote:
One of the cgitb outputs from my attempt to serve the binary file
claims that my CGI script's output file (which comes from a subprocess
PIPE) is a TextIOWrapper with encoding cp1252. Maybe that is the
default that comes when a new Python is launched, even though it gets
a subprocess PIPE as stdout?
So the rather gross code below solves the cp1252 stdout problem, and
also permits both strings and bytes to be written to the same file,
although those two features are separable. But now that I've worked
around it, it seems that subprocesss should somehow ensure that launched
Python programs know they are working on a binary stream? Of course,
not all programs launched are Python programs... so maybe it should be a
documentation issue, but it seems to be missing from the documentation.
#
if sys.version_info[ 0 ] == 2:
class IOMix():
def __init__( self, fh, encoding="UTF-8"):
self.fh = fh
def write( self, param ):
if isinstance( param, unicode ):
self.fh.write( param.encode( encoding ))
else:
self.fh.write( param )
#
if sys.version_info[ 0 ] == 3:
class IOMix():
def __init__( self, fh, encoding="UTF-8"):
if hasattr( fh, 'buffer'):
self.bio = fh.buffer
fh.flush()
self.last = 'b'
import io
self.txt = io.TextIOWrapper( self.bio, encoding, None,
'\r\n')
else:
raise ValueError("not a buffered stream")
def write( self, param ):
if isinstance( param, str ):
self.last = 't'
self.txt.write( param )
else:
if self.last == 't':
self.txt.flush()
self.last = 'b'
self.bio.write( param )
#
___
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
