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
Hello.
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/
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
I use cached dns lookups with pdnsd on my ubuntu machine to speed up web
access as regular lookups can take 15-30 seconds. However, python's
mechanize and urllib etc use socket.getaddrinfo, which seems not to be using
dns cacheing or taking a long time because of ipv6 lookups. In either case,
I sub
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
Paul Moore gmail.com> writes:
> In that case, some points:
>
> 1. A "silent by default" installer like this is not very usual in the
> Windows world, I'd have expected a confirmation dialog at least. For
> silent installs, msiexec /silent is available.
Agreed, a "success" message is probably a
Hi Gertjan,
Thanks for trying it.
> .\CLILauncher.rc(97) : error RC2135 : file not found:
> C:\Users\Vinay\Projects\Launchers\launcher.ico
Somewhere there's an absolute path where it should be relative - I'll get on it.
> There are a few compilation warnings as well:
>
> .\launcher.c(59) : war
On 7 July 2011 15:24, Vinay Sajip wrote:
> Hi Paul,
>
> Thanks for trying it out. If it installs successfully, nothing will appear to
> happen, Unix-style :-)
>
> There should be files installed in c:\Program Files\Python Launcher:
>
> py.exe, pyw.exe, py.ini
>
> and there should be registry entri
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
On 6 July 2011 19:31, Vinay Sajip wrote:
> The C implementation of the PEP 397-compatible Python Launcher for Windows has
> come along nicely in the last few days, and now reached a point where it would
> benefit from some testing by interested python-dev members. Points of note:
>
> 1. As well as
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
___
Vinay Sajip wrote:
>The C implementation of the PEP 397-compatible Python Launcher for Windows has
>come along nicely in the last few days, and now reached a point where it would
>benefit from some testing by interested python-dev members.
I've gotten the sources from:
>https://bitbucket.org/vin
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
28 matches
Mail list logo
