Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
Le 28/07/2011 06:10, Benjamin Peterson a écrit : there any reason to continue using codecs.open()? It's the easiest way to write Unicode friendly code that spans both 2.x and 3.x. Even on 2.6, where the io module exists? io on 2.6 is fairly broken and dead slow. The advantage of codecs.open is it hasn't changed in the very long time. It still has the same reliable buggy behavior no matter what version you're on. I don't see the problem with leaving codecs.open() to rot a few more releases before deprecating it while leaving messaging in the docs suggesting io.*. All these points were already discussed before. There is a subsection in "Backwards Compatibility" section in the PEP 400 explaining why codecs.open is NOT deprecated: http://www.python.org/dev/peps/pep-0400/#keep-the-public-api-codecs-open "codecs.open() can be replaced by the builtin open() function. open() has a similar API but has also more options. Both functions return file-like objects (same API). codecs.open() was the only way to open a text file in Unicode mode until Python 2.6. Many Python 2 programs uses this function. Removing codecs.open() implies more work to port programs from Python 2 to Python 3, especially projets using the same code base for the two Python versions (without using 2to3 program). codecs.open() is kept for backward compatibility with Python 2." 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
Le 28/07/2011 11:03, M.-A. Lemburg a écrit : Victor Stinner wrote: Hi, Three weeks ago, I posted a draft on my PEP on this mailing list. I tried to include all remarks you made, and the PEP is now online: http://www.python.org/dev/peps/pep-0400/ It's now unclear to me if the PEP will be accepted or rejected. I don't know what to do to move forward. The PEP still compares apples and oranges, issues and features, I don't know how to write a PEP and this is my first PEP. I think that it is possible to compare two classes using a list of issues and features. How should I change the PEP to compare comparable things? and doesn't cover the fact that it is proposing to not just deprecate a feature, but a part of a design concept which will then no longer be available in Python. The "Usage of StreamReader and StreamWriter" section tries to list usages of these classes, and "Deprecate StreamReader and StreamWriter" section explains that these classes will be removed. I agree that these sections are short, but I don't know what to add. Could you please enhance these sections? I'm still -1 on that part of the PEP. Ok. As I mentioned before, having codecs.open() changed to be a wrapper around io.open() in Python 3.3, should be investigated. If it doesn't cause too much trouble, this would be a good idea. I did already try on the full Python test suite, and all test pass. I don't know if it's representative. Please do keep the original implementation around (e.g. renamed to codecs.open_stream()), though, so that it's still possible to get easy-to-use access to codec StreamReader/Writers. I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to: * rename codecs.open() to codecs.open_stream() * change codecs.open() to reuse open() (and so io.TextIOWrapper) (and don't deprecate anything) Add a new function to Python 3.3 means that we will have to maintain it for later versions. It's just the opposite of my proposition :-) 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
Victor Stinner wrote: > Hi, > > Three weeks ago, I posted a draft on my PEP on this mailing list. I > tried to include all remarks you made, and the PEP is now online: > >http://www.python.org/dev/peps/pep-0400/ > > It's now unclear to me if the PEP will be accepted or rejected. I don't > know what to do to move forward. The PEP still compares apples and oranges, issues and features, and doesn't cover the fact that it is proposing to not just deprecate a feature, but a part of a design concept which will then no longer be available in Python. I'm still -1 on that part of the PEP. As I mentioned before, having codecs.open() changed to be a wrapper around io.open() in Python 3.3, should be investigated. If it doesn't cause too much trouble, this would be a good idea. Please do keep the original implementation around (e.g. renamed to codecs.open_stream()), though, so that it's still possible to get easy-to-use access to codec StreamReader/Writers. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 28 2011) >>> 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
[Python-Dev] HTMLParser and HTML5
Hello all, I wanted to ask a few questions and start a discussion about HTML5 support within the HTMLParser class(es). Over on issue 670664, an inconsistency with the way browsers and the HTMLParser parse script and style tags was discovered. Currently, HTMLParser adheres strictly to the HTML4 standard, which says that these tags should exit CDATA mode when the start of *any* closing tag is found. No browsers, to my knowledge, have ever supported this (at least in the 21st century). Instead, all browsers implement the behavior described in the HTML5 spec, which states that script tags should exit their "raw text mode" when the full closing tag for that element is encountered. The repercussions of adhering to the HTML4 standard in HTMLParser are somewhat serious: a good number of documents will either encounter exceptions for broken markup (which aren't actually broken). Libraries like Beautiful Soup (which depend on HTMLParser) are also affected, requiring the use of hacks just to get the document to parse at all. Rather than bore you all with another paragraph about how HTML4 is terrible, feel free to look at the issue (http://bugs.python.org/issue670664), which quite thoroughly outlines the pros and cons of this particular change. Any feedback/input on the proposed changes is welcome. So here are my questions: - What plans, if any, are there to support HTML5 parsing behaviors, since the HTML5 spec effectively describes current web browser behavior? - What policies are in place for keeping parity with other HTML parsers (such as those in web browsers)? Given the semi-backward-compatible nature of HTML5's syntax, this seems like a rather unique problem that could use some more discussion. Thanks Matt Basta ___ 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] Convention on functions that shadow existing stdlib functions
On Wed, Jul 27, 2011 at 16:53, Steven D'Aprano wrote: > Eli Bendersky wrote: > > Sure, but I'm still leery of two functions with the same name doing acting >> slightly differently. >> > > > and then in a later post: > > > As I mentioned elsewhere, it's not good practice to have two functions >> with >> the same name doing something slightly different, in different modules in >> the code-base. >> > > artist.draw() and gunslinger.draw() do not necessarily need to do the same > thing, and I don't agree that a (futile) preference for globally unique > names is good practice: it can lead to unnecessarily long names > (artist.draw_with_pencil_on_**paper) or redundant characters prefixing the > name (itertools.imap -- what does the "i" in imap tell you that the > itertools didn't already?). Solving this problem is what namespaces are for. > > Renaming test.support.ulink to something else doesn't fix the problem of > unsupported support functions being used in third-party code. It may even > *encourage* it, by making the extra functionality more explicit. > > However, is there any reason why test.support itself shouldn't be renamed > test._support, or possibly _test.support, so that the *entire* suite is > marked as a private implementation detail? > Technically no for the _test idea, although it would promote the idea of not shipping Python with its tests, which would be a shame as it's hard enough to get people to run them. Renaming test.support is much more acceptable, just more work considering how many times that module is used in the test suite. ___ 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] HTMLParser and HTML5
On Thu, Jul 28, 2011 at 11:25, Matt wrote: > Hello all, > > I wanted to ask a few questions and start a discussion about HTML5 > support within the HTMLParser class(es). Over on issue 670664, an > inconsistency with the way browsers and the HTMLParser parse script > and style tags was discovered. Currently, HTMLParser adheres strictly > to the HTML4 standard, which says that these tags should exit CDATA > mode when the start of *any* closing tag is found. No browsers, to my > knowledge, have ever supported this (at least in the 21st century). > Instead, all browsers implement the behavior described in the HTML5 > spec, which states that script tags should exit their "raw text mode" > when the full closing tag for that element is encountered. > > The repercussions of adhering to the HTML4 standard in HTMLParser are > somewhat serious: a good number of documents will either encounter > exceptions for broken markup (which aren't actually broken). Libraries > like Beautiful Soup (which depend on HTMLParser) are also affected, > requiring the use of hacks just to get the document to parse at all. > > Rather than bore you all with another paragraph about how HTML4 is > terrible, feel free to look at the issue > (http://bugs.python.org/issue670664), which quite thoroughly outlines > the pros and cons of this particular change. Any feedback/input on > the proposed changes is welcome. > > So here are my questions: > > - What plans, if any, are there to support HTML5 parsing behaviors, > since the HTML5 spec effectively describes current web browser > behavior? > There are not specific plans that have been publicly brought up (to my knowledge). > - What policies are in place for keeping parity with other HTML > parsers (such as those in web browsers)? > There aren't any beyond "it would be nice". > > Given the semi-backward-compatible nature of HTML5's syntax, this > seems like a rather unique problem that could use some more > discussion. > It's more of an issue of someone caring enough to do the coding work to bring the parser up to spec for HTML5 (or introduce new code to live beside the HTML4 parsing code). IOW there is no policies specifically about this topic beyond the general desire to stay up-to-date with stable specs. ___ 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] Convention on functions that shadow existing stdlib functions
On Fri, Jul 29, 2011 at 7:33 AM, Brett Cannon wrote: >> However, is there any reason why test.support itself shouldn't be renamed >> test._support, or possibly _test.support, so that the *entire* suite is >> marked as a private implementation detail? > > Technically no for the _test idea, although it would promote the idea of not > shipping Python with its tests, which would be a shame as it's hard enough > to get people to run them. Renaming test.support is much more acceptable, > just more work considering how many times that module is used in the test > suite. Moving the docs should deal with the module and name indexing issue, so -1 one to expending any developer effort on unnecessary name changes in the test suite. 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] HTMLParser and HTML5
Brett Cannon, 28.07.2011 23:49: On Thu, Jul 28, 2011 at 11:25, Matt wrote: - What policies are in place for keeping parity with other HTML parsers (such as those in web browsers)? There aren't any beyond "it would be nice". [...] It's more of an issue of someone caring enough to do the coding work to bring the parser up to spec for HTML5 (or introduce new code to live beside the HTML4 parsing code). Which, given that html5lib readily exists, would likely be a lot more work than anyone who is interested in HTML5 handling would want to invest. I don't think we need a new HTML5 parsing implementation only to have it in the stdlib. That's the old sunny Java way of doing it. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Convention on functions that shadow existing stdlib functions
On Fri, Jul 29, 2011 at 03:39, Nick Coghlan wrote: > On Fri, Jul 29, 2011 at 7:33 AM, Brett Cannon wrote: > >> However, is there any reason why test.support itself shouldn't be > renamed > >> test._support, or possibly _test.support, so that the *entire* suite is > >> marked as a private implementation detail? > > > > Technically no for the _test idea, although it would promote the idea of > not > > shipping Python with its tests, which would be a shame as it's hard > enough > > to get people to run them. Renaming test.support is much more acceptable, > > just more work considering how many times that module is used in the test > > suite. > > Moving the docs should deal with the module and name indexing issue, > so -1 one to expending any developer effort on unnecessary name > changes in the test suite. > > Alright, I think there's now a sufficiently wide consensus to move the documentation of Lib/test and Lib/test/support in particular to the devguide, which raises a question: Currently test.support is documented both for Python 3K and 2.7, while the devguide (AFAIK) comes in a single version. I propose to just move 3K's docs to the devguide, and make both doc pages (in 3K and 2.7) point to it. Is this acceptable? Eli ___ 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] Convention on functions that shadow existing stdlib functions
On Fri, Jul 29, 2011 at 3:24 PM, Eli Bendersky wrote: > I propose to just move 3K's docs to the devguide, and make both doc pages > (in 3K and 2.7) point to it. Is this acceptable? Yeah, just include a note in the devguide version saying that anything added in 3.2 or later may not be available when writing tests for the 2.7 maintenance branch. 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] [Python-checkins] cpython: Issue #10639: reindent.py tool now accepts a --newline option to specify the
On Tue, Jul 26, 2011 at 18:59, jason.coombs wrote: > http://hg.python.org/cpython/rev/4feb889d3bed > changeset: 71506:4feb889d3bed > user:Jason R. Coombs > date:Tue Jul 26 11:38:04 2011 -0400 > summary: > Issue #10639: reindent.py tool now accepts a --newline option to specify > the newline to be used in the output of converted files. > Jason, this breaks "make patchcheck". Please see my comment on the issue. Eli ___ 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
