Benjamin Peterson benjamin at python.org writes:
2011/7/6 Nick Coghlan ncoghlan at gmail.com:
The API of the resulting object is the same (i.e. they're file-like
objects). The behavioural differences are due to cases where the
codec-specific classes are currently broken.
Yes, but as
Victor Stinner wrote:
Hi,
Last may, I proposed to deprecate open() function, StreamWriter and
StreamReader classes of the codecs module. I accepted to keep open()
after the discussion on python-dev. Here is a more complete proposition
as a PEP. It is a draft and I expect a lot of comments
On Thu, Jul 7, 2011 at 1:51 PM, Benjamin Peterson benja...@python.org wrote:
2011/7/6 Nick Coghlan ncogh...@gmail.com:
On Thu, Jul 7, 2011 at 11:16 AM, Benjamin Peterson benja...@python.org
wrote:
2011/7/6 Victor Stinner victor.stin...@haypocalc.com:
codecs.open() will be changed to reuse
Nick Coghlan ncoghlan at gmail.com writes:
Unless somebody steps forward to fix them, the Stream* classes have to
go (albeit with a suitable period of deprecation). They're *actively
harmful* in their current state, so retaining the status quo is not a
viable option in this case.
I can
On Thu, Jul 7, 2011 at 6:49 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Unless somebody steps forward to fix them, the Stream* classes have to
go (albeit with a suitable period of deprecation). They're *actively
harmful* in their current state, so
Le 07/07/2011 03:16, Benjamin Peterson a écrit :
2011/7/6 Victor Stinnervictor.stin...@haypocalc.com:
codecs.open() will be changed to reuse the builtin open() function
(TextIOWrapper).
This doesn't strike me as particularly backwards compatible, since
you've just enumerated the differences
Le 07/07/2011 05:26, Nick Coghlan a écrit :
Victor, could you please check this into the PEPs repo? It's easier to
reference once it has a real number.
How do I upload it? Should I contact a PEP editor? How?
Victor
___
Python-Dev mailing list
Le 07/07/2011 10:07, M.-A. Lemburg a écrit :
The PEP's arguments for deprecating two essential codec design
components are very one sided, by comparing issues to features.
Yes, please help me to write an unbiased PEP. I don't know which tool is
more appropriate to write a PEP with many authors.
Nick Coghlan ncoghlan at gmail.com writes:
Anyone forward porting codecs.open based code will get subpar IO in
Python 3 *because* they're trying to do the right thing in Python 2.
That's actively harmful in my book.
I see. Presumably if they're doing a porting exercise, then it's easy enough
On Jul 07, 2011, at 12:26 PM, Victor Stinner wrote:
Le 07/07/2011 05:26, Nick Coghlan a écrit :
Victor, could you please check this into the PEPs repo? It's easier to
reference once it has a real number.
How do I upload it? Should I contact a PEP editor? How?
Email p...@python.org
Cheers,
On Thu, Jul 7, 2011 at 9:12 PM, Barry Warsaw ba...@python.org wrote:
On Jul 07, 2011, at 12:26 PM, Victor Stinner wrote:
Le 07/07/2011 05:26, Nick Coghlan a écrit :
Victor, could you please check this into the PEPs repo? It's easier to
reference once it has a real number.
How do I upload it?
On Thu, Jul 7, 2011 at 8:53 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've no issue with telling people to use open() rather than codecs.open() when
moving code from 2.x to 3.x. But in 2.x, is there any other API which allows
you
to wrap arbitrary streams? If not, then ISTM that removing
Le 07/07/2011 13:43, Nick Coghlan a écrit :
Or just check it in to hg.python.org/peps (claiming the next number in
sequence - 400 at the time of writing this email). I asked if that
approach was OK quite some time ago and David said yes - PEP 1 is
written the way it is because not everyone that
Le 07/07/2011 12:53, Vinay Sajip a écrit :
I've no issue with telling people to use open() rather than codecs.open() when
moving code from 2.x to 3.x. But in 2.x, is there any other API which allows you
to wrap arbitrary streams?
Yes, io.TextIOWrapper.
Victor
B. Retain the full codecs module API, but reimplement relevant parts
in terms of the io module.
This solution would not break backward compatibility, or less than my
PEP. I didn't try to implement this solution. It should be possible for
StreamReader (- TextIOWrapper), StreamWriter (-
On Thu, 7 Jul 2011 06:53:50 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Benjamin Peterson benjamin at python.org writes:
2011/7/6 Nick Coghlan ncoghlan at gmail.com:
The API of the resulting object is the same (i.e. they're file-like
objects). The behavioural differences
On Thu, 07 Jul 2011 10:07:38 +0200
M.-A. Lemburg m...@egenix.com wrote:
That said, I'm not really up for a longer discussion on this. We've
already had the discussion and decided against removing those
parts of the codec API.
I don't remember any such decision. We decided against unilateraly
On Thu, 7 Jul 2011 22:08:45 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Currently, nobody has stepped forward to do the work of maintaining
the codecs IO implementation independently of the io module, so the
only two options seriously on the table are B and C.
Since nobody has stepped up to
On 7/7/2011 7:28 AM, Antoine Pitrou wrote:
The main point of the PEP, IMO, is actually the deprecation itself. By
deprecating, we signal that something isn't actively maintained
anymore, and that a (allegedly better) alternative is available.
I think that's a very reasonable thing to do,
Le 07/07/2011 19:33, Terry Reedy a écrit :
On 7/7/2011 7:28 AM, Antoine Pitrou wrote:
The main point of the PEP, IMO, is actually the deprecation itself. By
deprecating, we signal that something isn't actively maintained
anymore, and that a (allegedly better) alternative is available.
I think
On Thu, Jul 7, 2011 at 11:43, Victor Stinner
victor.stin...@haypocalc.comwrote:
Le 07/07/2011 19:33, Terry Reedy a écrit :
On 7/7/2011 7:28 AM, Antoine Pitrou wrote:
The main point of the PEP, IMO, is actually the deprecation itself. By
deprecating, we signal that something isn't actively
On Fri, Jul 8, 2011 at 4:43 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Le 07/07/2011 19:33, Terry Reedy a écrit :
On 7/7/2011 7:28 AM, Antoine Pitrou wrote:
The main point of the PEP, IMO, is actually the deprecation itself. By
deprecating, we signal that something isn't actively
Hi,
Last may, I proposed to deprecate open() function, StreamWriter and
StreamReader classes of the codecs module. I accepted to keep open()
after the discussion on python-dev. Here is a more complete proposition
as a PEP. It is a draft and I expect a lot of comments :)
Victor
2011/7/6 Victor Stinner victor.stin...@haypocalc.com:
codecs.open() will be changed to reuse the builtin open() function
(TextIOWrapper).
This doesn't strike me as particularly backwards compatible, since
you've just enumerated the differences between StreamWriter/Reader and
TextIOWrapper.
On Thu, Jul 7, 2011 at 11:16 AM, Benjamin Peterson benja...@python.org wrote:
2011/7/6 Victor Stinner victor.stin...@haypocalc.com:
codecs.open() will be changed to reuse the builtin open() function
(TextIOWrapper).
This doesn't strike me as particularly backwards compatible, since
you've
2011/7/6 Nick Coghlan ncogh...@gmail.com:
On Thu, Jul 7, 2011 at 11:16 AM, Benjamin Peterson benja...@python.org
wrote:
2011/7/6 Victor Stinner victor.stin...@haypocalc.com:
codecs.open() will be changed to reuse the builtin open() function
(TextIOWrapper).
This doesn't strike me as
26 matches
Mail list logo