On Fri, Jul 8, 2011 at 4:43 AM, Victor Stinner
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 maintained
>>>
On Thu, Jul 7, 2011 at 11:43, Victor Stinner
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 maintained
>>> any
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 t
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, regardl
On Thu, 7 Jul 2011 22:08:45 +1000
Nick Coghlan 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 implement option
On Thu, 07 Jul 2011 10:07:38 +0200
"M.-A. Lemburg" 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
removing
On Thu, 7 Jul 2011 06:53:50 + (UTC)
Vinay Sajip wrote:
> Benjamin Peterson python.org> writes:
>
> >
> > 2011/7/6 Nick Coghlan 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
> >
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 (-> TextIO
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
___
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 w
On Thu, Jul 7, 2011 at 8:53 PM, Vinay Sajip 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 the Stream* classes
On Thu, Jul 7, 2011 at 9:12 PM, Barry Warsaw 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? Should
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
Nick Coghlan 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 for
them
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 autho
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
Python-D
Le 07/07/2011 03:16, Benjamin Peterson a écrit :
2011/7/6 Victor Stinner:
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
On Thu, Jul 7, 2011 at 6:49 PM, Vinay Sajip wrote:
> Nick Coghlan 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
Nick Coghlan 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 understand t
On Thu, Jul 7, 2011 at 1:51 PM, Benjamin Peterson wrote:
> 2011/7/6 Nick Coghlan :
>> On Thu, Jul 7, 2011 at 11:16 AM, Benjamin Peterson
>> wrote:
>>> 2011/7/6 Victor Stinner :
codecs.open() will be changed to reuse the builtin open() function
(TextIOWrapper).
>>>
>>> This doesn't stri
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 comme
Benjamin Peterson python.org> writes:
>
> 2011/7/6 Nick Coghlan 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 we all know
2011/7/6 Nick Coghlan :
> On Thu, Jul 7, 2011 at 11:16 AM, Benjamin Peterson
> wrote:
>> 2011/7/6 Victor Stinner :
>>> 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 en
On Thu, Jul 7, 2011 at 11:16 AM, Benjamin Peterson wrote:
> 2011/7/6 Victor Stinner :
>> 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 St
2011/7/6 Victor Stinner :
> 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.
--
Regards,
Benjamin
__
25 matches
Mail list logo
