Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly
On Tue, Sep 28, 2010 at 8:17 AM, Guido van Rossum wrote: > On Mon, Sep 27, 2010 at 2:21 PM, "Martin v. Löwis" wrote: >>> Someone with web server access may want to double check the >>> modification dates of the .txt files relative to the generated .html >>> files for other PEPs though. >> >> make will deal with that just fine. If a PEP was modified, svn up will >> update the time stamp on the file. When then the rebuild fails, the >> html file will still have an old time stamp. >> >> So I'm unsure why you thought you needed to modify some of the files. > > Because it's not clear to most of us on this thread what the failure > modes and recovery strategies are? I know it's clear as mud to me how > to debug these kinds of issues. Yep, it was just a misunderstanding on my part as to possible failure modes for the PEP publication process. I've certainly seen plenty of other systems which need to be resent events if processing of the original events fails. Primarily, I didn't know that any PEP commit just triggered a full Makefile invocation for the PEP directory rather than trying to be selective. (Letting make sort it out is a better idea, I just didn't know it was set up that way). (And, like Terry, Firefox chokes on the postcommit log for me. The file appears to be too big for my system to handle gracefully, so checking it really didn't help me. I did try though.) 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] Pronouncement needed in issue9675
Hi, 2010/9/28 Jesus Cea : > http://bugs.python.org/issue9675 > > Long history sort: Python 2.7 backported Capsule support and > (incorrectly, in my opinion) marked CObject as deprecated. > > All C modules in the stdlib were updated to Capsule (with a CObject > compatibility layer), except BSDDB, because this change was done late in > the cycle, the proposed patch was buggy (solvable) and a pronouncement > was done that CObject was not actually deprecated. > > But in python 2.7 release, CObject is marked as deprecated (arg!), so > when executing python with -We (mark warnings as errors), bsddb fails. > > Since I think that adopting Capsule in BSDDB for 2.7.1 would break the > API compatibility (maybe the CObject proxy would solve this), and since > a previous pronouncement was done abour CObject not-deprecated in 2.7.x, > I would like comments. Is compatibility really broken? PyCObject_AsVoidPtr(), PyCObject_Import() accept Capsule objects as well. Or are there other usages of the api pointer? -- Amaury Forgeot d'Arc ___ 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] issue2180 and using 'tokenize' with Python 3 'str's
On Mon, 27 Sep 2010 23:45:45 -0400 Steve Holden wrote: > On 9/27/2010 11:27 PM, Benjamin Peterson wrote: > > 2010/9/27 Meador Inge : > >> which, as seen in the trace, is because the 'detect_encoding' function in > >> 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string > >> to tokenize 'first' (a 'str' object). It seems to me that strings should > >> still be able to be tokenized, but maybe I am missing something. > >> Is the implementation of 'detect_encoding' correct in how it attempts to > >> determine an encoding or should I open an issue for this? > > > > Tokenize only works on bytes. You can open a feature request if you desire. > > > Working only on bytes does seem rather perverse. I agree, the morality of bytes objects could have been better :) ___ 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] issue2180 and using 'tokenize' with Python 3 'str's
On 28/09/2010 12:19, Antoine Pitrou wrote: On Mon, 27 Sep 2010 23:45:45 -0400 Steve Holden wrote: On 9/27/2010 11:27 PM, Benjamin Peterson wrote: 2010/9/27 Meador Inge: which, as seen in the trace, is because the 'detect_encoding' function in 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string to tokenize 'first' (a 'str' object). It seems to me that strings should still be able to be tokenized, but maybe I am missing something. Is the implementation of 'detect_encoding' correct in how it attempts to determine an encoding or should I open an issue for this? Tokenize only works on bytes. You can open a feature request if you desire. Working only on bytes does seem rather perverse. I agree, the morality of bytes objects could have been better :) The reason for working with bytes is that source data can only be correctly decoded to text once the encoding is known. The encoding is determined by reading the encoding cookie. I certainly wouldn't be opposed to an API that accepts a string as well though. All the best, Michael ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] issue2180 and using 'tokenize' with Python 3 'str's
On 28 September 2010 12:29, Michael Foord wrote: > On 28/09/2010 12:19, Antoine Pitrou wrote: > >> On Mon, 27 Sep 2010 23:45:45 -0400 >> Steve Holden wrote: >> >>> On 9/27/2010 11:27 PM, Benjamin Peterson wrote: >>> 2010/9/27 Meador Inge: > which, as seen in the trace, is because the 'detect_encoding' function > in > 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the > string > to tokenize 'first' (a 'str' object). It seems to me that strings > should > still be able to be tokenized, but maybe I am missing something. > Is the implementation of 'detect_encoding' correct in how it attempts > to > determine an encoding or should I open an issue for this? > Tokenize only works on bytes. You can open a feature request if you desire. Working only on bytes does seem rather perverse. >>> >> I agree, the morality of bytes objects could have been better :) >> >> The reason for working with bytes is that source data can only be > correctly decoded to text once the encoding is known. The encoding is > determined by reading the encoding cookie. > > I certainly wouldn't be opposed to an API that accepts a string as well > though. > > Ah, and to explain the design decision when tokenize was ported to py3k - the Python 2 APIs take the readline method of a file object (not a string). http://docs.python.org/library/tokenize.html For this to work correctly in Python 3 it *has* to be a file object open in binary read mode in order to decode the source code correctly. A new API that takes a string would certainly be nice. The Python 2 API for tokenize is 'interesting'... All the best, Michael Foord > All the best, > > Michael > > > >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of > your employer, to release me from all obligations and waivers arising from > any and all NON-NEGOTIATED agreements, licenses, terms-of-service, > shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, > non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have > entered into with your employer, its partners, licensors, agents and > assigns, in perpetuity, without prejudice to my ongoing rights and > privileges. You further represent that you have the authority to release me > from any BOGUS AGREEMENTS on behalf of your employer. > > > -- http://www.voidspace.org.uk ___ 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] issue2180 and using 'tokenize' with Python 3 'str's
On Tue, Sep 28, 2010 at 9:29 PM, Michael Foord wrote: > On 28/09/2010 12:19, Antoine Pitrou wrote: >> On Mon, 27 Sep 2010 23:45:45 -0400 >> Steve Holden wrote: >>> On 9/27/2010 11:27 PM, Benjamin Peterson wrote: Tokenize only works on bytes. You can open a feature request if you desire. >>> Working only on bytes does seem rather perverse. >> >> I agree, the morality of bytes objects could have been better :) >> > The reason for working with bytes is that source data can only be correctly > decoded to text once the encoding is known. The encoding is determined by > reading the encoding cookie. > > I certainly wouldn't be opposed to an API that accepts a string as well > though. A very quick scan of _tokenize suggests it is designed to support detect_encoding returning None to indicate the line iterator will return already decoded lines. This is confirmed by the fact the standard library uses it that way (via generate_tokens). An API that accepts a string, wraps a StringIO around it, then calls _tokenise with an encoding of None would appear to be the answer here. A feature request on the tracker is the best way to make that happen. 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] issue2180 and using 'tokenize' with Python 3 'str's
On Tue, Sep 28, 2010 at 7:09 AM, Nick Coghlan wrote: > A feature request on the tracker is the best way to make that happen. > Done - http://bugs.python.org/issue9969. Thanks for the feedback everyone. -- Meador ___ 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] Pronouncement needed in issue9675
On Mon, Sep 27, 2010 at 7:44 PM, Jesus Cea wrote: > http://bugs.python.org/issue9675 > > Long history sort: Python 2.7 backported Capsule support and > (incorrectly, in my opinion) marked CObject as deprecated. > > All C modules in the stdlib were updated to Capsule (with a CObject > compatibility layer), except BSDDB, because this change was done late in > the cycle, the proposed patch was buggy (solvable) and a pronouncement > was done that CObject was not actually deprecated. > > But in python 2.7 release, CObject is marked as deprecated (arg!), so > when executing python with -We (mark warnings as errors), bsddb fails. > > Since I think that adopting Capsule in BSDDB for 2.7.1 would break the > API compatibility (maybe the CObject proxy would solve this), and since > a previous pronouncement was done abour CObject not-deprecated in 2.7.x, > I would like comments. > > Long history and links to previous pronouncements in > http://bugs.python.org/issue9675 > > My proposal: CObject should not be marked as deprecated in 2.7.1. It strikes me that in general deprecation warnings in 2.7 don't do anybody any good unless they're Py3k warnings. It sounds to me that there is no shame in removing the warning in Python 2.7 (or turning it into a Py3k warning -- nobody should expect their code to behave well when Py3k warnings are turned into errors). My guess is that the warning was added to 2.7 before it was clear that there would never be a 2.8. At the same time I don't want to go so far as to remove all remaining deprecation warnings from 2.7.1 (too much churn) -- but for this specific one it sounds like a reasonable compromise. -- --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] Pronouncement needed in issue9675
On Tue, 2010-09-28 at 04:44 +0200, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > http://bugs.python.org/issue9675 > > Long history sort: Python 2.7 backported Capsule support and > (incorrectly, in my opinion) marked CObject as deprecated. > > All C modules in the stdlib were updated to Capsule (with a CObject > compatibility layer), except BSDDB, because this change was done late in > the cycle, the proposed patch was buggy (solvable) and a pronouncement > was done that CObject was not actually deprecated. > > But in python 2.7 release, CObject is marked as deprecated (arg!), so > when executing python with -We (mark warnings as errors), bsddb fails. > > Since I think that adopting Capsule in BSDDB for 2.7.1 would break the > API compatibility (maybe the CObject proxy would solve this), and since > a previous pronouncement was done abour CObject not-deprecated in 2.7.x, > I would like comments. > > Long history and links to previous pronouncements in > http://bugs.python.org/issue9675 > > My proposal: CObject should not be marked as deprecated in 2.7.1. This breaks quite a few third-party modules, some with segfaults; we (as in Fedora) ran into this building with 2.7 as the standard /usr/bin/python for Fedora 14. We fixed some of them, but are advising people not to turn on warnings as errors in our release notes [1] See this tracker bug for a survey of the gory details: https://bugzilla.redhat.com/showdependencytree.cgi?id=620842&hide_resolved=0 The list includes SWIG, numpy, and the GTK stack. I'd be more than happy to patch Fedora's python builds to remove the deprecation warning, but I don't want to stray too far from python.org's "official" behavior here. So, I'm +1 on removing this deprecation warning in 2.7, FWIW (though I'm not a committer yet) Hope this is helpful Dave [1] https://fedoraproject.org/wiki/Features/Python_2.7#Caveat:_PyCObject_and_warnings ___ 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] Pronouncement needed in issue9675
On Tue, 2010-09-28 at 11:18 -0400, David Malcolm wrote: > On Tue, 2010-09-28 at 04:44 +0200, Jesus Cea wrote: [snip] > > Long history and links to previous pronouncements in > > http://bugs.python.org/issue9675 Re-reading my post, I realize that my wording was really unclear; sorry. > > > > My proposal: CObject should not be marked as deprecated in 2.7.1. > > This breaks quite a few third-party modules, some with segfaults; we (as > in Fedora) ran into this building with 2.7 as the > standard /usr/bin/python for Fedora 14. Restating: the _deprecation_ breaks quite a few 3rd-party modules, and I'm in agreement with Jesus' proposal. [snip] ___ 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] Pronouncement needed in issue9675
On Tue, 28 Sep 2010 04:44:08 +0200 Jesus Cea wrote: > > But in python 2.7 release, CObject is marked as deprecated (arg!), so > when executing python with -We (mark warnings as errors), bsddb fails. By "fails" you mean "crashes the interpreter". While the deprecation warning can be discussed, bsddb shouldn't crash when PyCObject_FromVoidPtr() returns NULL, but instead bail out cleanly (or perhaps even ignore the error and simply display a warning that the C API won't be available). 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] Pronouncement needed in issue9675
On Tue, Sep 28, 2010 at 8:18 AM, David Malcolm wrote: [...] > This breaks quite a few third-party modules, some with segfaults; we (as > in Fedora) ran into this building with 2.7 as the > standard /usr/bin/python for Fedora 14. > > We fixed some of them, but are advising people not to turn on warnings > as errors in our release notes [1] Sure, but do realize that if an extension segfaults when warnings are turned into errors, that is ultimately a bug in the extension, and an indication that the extension is playing loose with error checking. There are likely other places where the module's error checking is *also* too loose, and this can be a cause of general instability (e.g. segfaulting instead of raising an exception when other rare errors occur, e.g. interrupts or out of memory or even I/O errors). > See this tracker bug for a survey of the gory details: > https://bugzilla.redhat.com/showdependencytree.cgi?id=620842&hide_resolved=0 > > The list includes SWIG, numpy, and the GTK stack. TBH, I'm not surprised. Those are very large code bases, and SWIG in particular is by its nature limited in the amount of error checking it can provide (as the error checking sometimes has to be in the C++ code it wraps). > I'd be more than happy to patch Fedora's python builds to remove the > deprecation warning, but I don't want to stray too far from python.org's > "official" behavior here. > > So, I'm +1 on removing this deprecation warning in 2.7, FWIW (though I'm > not a committer yet) FWIW, you don't have to be a committer for your +1 to count. But you do have to provide additional argumentation, which you did. (IOW thank you!) -- --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] Pronouncement needed in issue9675
On Tue, Sep 28, 2010 at 11:49 PM, Guido van Rossum wrote: > It strikes me that in general deprecation warnings in 2.7 don't do > anybody any good unless they're Py3k warnings. It sounds to me that > there is no shame in removing the warning in Python 2.7 (or turning it > into a Py3k warning -- nobody should expect their code to behave well > when Py3k warnings are turned into errors). My guess is that the > warning was added to 2.7 before it was clear that there would never be > a 2.8. > > At the same time I don't want to go so far as to remove all remaining > deprecation warnings from 2.7.1 (too much churn) -- but for this > specific one it sounds like a reasonable compromise. Converting to a Py3k warning sounds like the best option. 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] Pronouncement needed in issue9675
2010/9/28 Nick Coghlan : > Converting to a Py3k warning sounds like the best option. Can someone please explain why converting to a PyCapsule object is not an option? PyCObject_AsVoidPtr() and PyCObject_Import() accept Capsules and will work as before. -- Amaury Forgeot d'Arc ___ 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] Pronouncement needed in issue9675
On Tue, Sep 28, 2010 at 3:23 PM, Amaury Forgeot d'Arc wrote: > 2010/9/28 Nick Coghlan : >> Converting to a Py3k warning sounds like the best option. > > Can someone please explain why converting to a PyCapsule object is not > an option? > PyCObject_AsVoidPtr() and PyCObject_Import() accept Capsules and will > work as before. Because bsddb is an external module? -- --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] Pronouncement needed in issue9675
2010/9/29 Guido van Rossum : >> Can someone please explain why converting to a PyCapsule object is not >> an option? >> PyCObject_AsVoidPtr() and PyCObject_Import() accept Capsules and will >> work as before. > > Because bsddb is an external module? Yes, bsddb is compiled in a separate .pyd or .so. But what does this change? -- Amaury Forgeot d'Arc ___ 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] Pronouncement needed in issue9675
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/09/10 00:56, Guido van Rossum wrote: > On Tue, Sep 28, 2010 at 3:23 PM, Amaury Forgeot d'Arc > wrote: >> 2010/9/28 Nick Coghlan : >>> Converting to a Py3k warning sounds like the best option. >> >> Can someone please explain why converting to a PyCapsule object is not >> an option? >> PyCObject_AsVoidPtr() and PyCObject_Import() accept Capsules and will >> work as before. > > Because bsddb is an external module? Uhm?. I am confused... The reason to rollback the deprecation warning is because it is breaking other external modules too, see a previous post. Since there is no 2.8 planned, a deprecation warning is not useful. See the thread linked in the tracker. About converting the deprecation warning to a py3k warning... Would a py3k warning be converted to an error when python is invoked as "-We"?. If that is the case, we are in the same situation. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "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/ iQCVAwUBTKJ0UJlgi5GaxT1NAQILeQP8C7zIMPG7BAAo2+m414c5jvy5f3wAlKG+ PGO+IOw/AF7FQSrLj59IWJ1E6oHWf/64TYS8tLTsHdo+sHm/gyHBXlqLUVIIZEMG YduS7G2zeU1XwDsSKqg3vhoDZXMNVhJkbEUegayuKEltAPK8McElx5Agqz26knHD mFA5aRtDw28= =5/5Y -END PGP SIGNATURE- ___ 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] Pronouncement needed in issue9675
On Tue, Sep 28, 2010 at 4:02 PM, Amaury Forgeot d'Arc wrote: > 2010/9/29 Guido van Rossum : >>> Can someone please explain why converting to a PyCapsule object is not >>> an option? >>> PyCObject_AsVoidPtr() and PyCObject_Import() accept Capsules and will >>> work as before. >> >> Because bsddb is an external module? > > Yes, bsddb is compiled in a separate .pyd or .so. But what does this change? Because it needs to support multiple Python versions from single source? -- --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] Pronouncement needed in issue9675
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/09/10 01:06, Guido van Rossum wrote: >>> Because bsddb is an external module? >> >> Yes, bsddb is compiled in a separate .pyd or .so. But what does this change? > > Because it needs to support multiple Python versions from single source? Well, that is my problem, no python-dev :-). I am replying in the mailing list only. It takes a while to propagate. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "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/ iQCVAwUBTKJ21plgi5GaxT1NAQLmGwP+OquVycOmX1MeCxx+wokmHIU7s6HurT4g BJJvCKLZvUByI/NQ9DJP5Ve/n79ZQk208NQou8fEpyvMyUldQJ8hdUbX26ZvDZ7a AZ78eef10Gog2GMVYMO+k41X0d0Pln1+r9RbD5vdLiCeM0iRGOYAKmmNiZQCBsAe LTC5O6+K2O0= =6l9I -END PGP SIGNATURE- ___ 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] issue2180 and using 'tokenize' with Python 3 'str's
Am 28.09.2010 05:45, schrieb Steve Holden: > On 9/27/2010 11:27 PM, Benjamin Peterson wrote: >> 2010/9/27 Meador Inge : >>> which, as seen in the trace, is because the 'detect_encoding' function in >>> 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string >>> to tokenize 'first' (a 'str' object). It seems to me that strings should >>> still be able to be tokenized, but maybe I am missing something. >>> Is the implementation of 'detect_encoding' correct in how it attempts to >>> determine an encoding or should I open an issue for this? >> >> Tokenize only works on bytes. You can open a feature request if you desire. >> > Working only on bytes does seem rather perverse. Yeah, source code really should stop being stored on disks, or else disks should stop being byte-oriented. Let's go the Smalltalk way - they store all source code in the image, no need to deal with perversities like files anymore. 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
Re: [Python-Dev] issue2180 and using 'tokenize' with Python 3 'str's
> I certainly wouldn't be opposed to an API that accepts a string as well > though. Notice that this can't really work for Python 2 source code (but of course, it doesn't need to). In Python 2, if you have a string literal in the source code, you need to know the source encoding in order to get the bytes *back*. Now, if you parse a Unicode string as source code, and it contains byte string literals, you wouldn't know what encoding to apply. Fortunately, Python 3 byte literals ban non-ASCII literal characters, so assuming an ASCII-compatible encoding for the original source is fairly safe. 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
Re: [Python-Dev] Pronouncement needed in issue9675
2010/9/29 Guido van Rossum : > On Tue, Sep 28, 2010 at 4:02 PM, Amaury Forgeot d'Arc > wrote: >> 2010/9/29 Guido van Rossum : Can someone please explain why converting to a PyCapsule object is not an option? PyCObject_AsVoidPtr() and PyCObject_Import() accept Capsules and will work as before. >>> >>> Because bsddb is an external module? >> >> Yes, bsddb is compiled in a separate .pyd or .so. But what does this change? > > Because it needs to support multiple Python versions from single source? But here we are talking about the bsddb module shipped with core python2.7 http://svn.python.org/view/python/branches/release27-maint/Modules/_bsddb.c This is a single source for a single version. And in any case a #ifdef is good enough. -- Amaury Forgeot d'Arc ___ 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] Pronouncement needed in issue9675
2010/9/28 Amaury Forgeot d'Arc : > 2010/9/29 Guido van Rossum : >>> Can someone please explain why converting to a PyCapsule object is not >>> an option? >>> PyCObject_AsVoidPtr() and PyCObject_Import() accept Capsules and will >>> work as before. >> >> Because bsddb is an external module? > > Yes, bsddb is compiled in a separate .pyd or .so. But what does this change? By external, I presume he means externally maintained. -- Regards, Benjamin ___ 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] Pronouncement needed in issue9675
On Tue, Sep 28, 2010 at 4:03 PM, Jesus Cea wrote: > On 29/09/10 00:56, Guido van Rossum wrote: >> On Tue, Sep 28, 2010 at 3:23 PM, Amaury Forgeot d'Arc >> wrote: >>> 2010/9/28 Nick Coghlan : Converting to a Py3k warning sounds like the best option. >>> >>> Can someone please explain why converting to a PyCapsule object is not >>> an option? >>> PyCObject_AsVoidPtr() and PyCObject_Import() accept Capsules and will >>> work as before. >> >> Because bsddb is an external module? > > Uhm?. I am confused... > > The reason to rollback the deprecation warning is because it is breaking > other external modules too, see a previous post. Since there is no 2.8 > planned, a deprecation warning is not useful. See the thread linked in > the tracker. > > About converting the deprecation warning to a py3k warning... Would a > py3k warning be converted to an error when python is invoked as "-We"?. > If that is the case, we are in the same situation. Hm, I am okay with programs not working if -We -3 is selected. Why would anyone want to run in that mode anyway? And if -We crashes you have a bug in your C code (not enouggh error checking),. -- --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] issue2180 and using 'tokenize' with Python 3 'str's
On 29 Sep 2010, at 00:22, "Martin v. Löwis" wrote: >> I certainly wouldn't be opposed to an API that accepts a string as well >> though. > > Notice that this can't really work for Python 2 source code (but of > course, it doesn't need to). > > In Python 2, if you have a string literal in the source code, you need > to know the source encoding in order to get the bytes *back*. Now, > if you parse a Unicode string as source code, and it contains byte > string literals, you wouldn't know what encoding to apply. > > Fortunately, Python 3 byte literals ban non-ASCII literal characters, > so assuming an ASCII-compatible encoding for the original source is > fairly safe. > The new API couldn't be ported to Python 2 •anyway•. As Nick pointed out, the underlying tokenization happens on decoded strings - so starting with source as Unicode will be fine. Michael > 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] Atlassian and bitbucket merge
I see that Atlassian have just taken over BitBucket, the Mercurial hosting company. IIRC Atlassian offered to host our issue tracking on JIRA, but in the end we decided to eat our own dog food and went with roundup. I'm wondering if they'd be similarly interested in supporting our Hg server. Or is self-hosting the only acceptable solution? From recent mail it looks likes we may be up and running on Hg fairly soon. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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
