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
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:
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
On 6 July 2011 19:31, Vinay Sajip vinay_sa...@yahoo.co.uk 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
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 7 July 2011 15:24, Vinay Sajip vinay_sa...@yahoo.co.uk 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
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) : warning
Paul Moore p.f.moore at 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
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
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
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,
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
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
29 matches
Mail list logo
