Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread M.-A. Lemburg 
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 :)

The PEP's arguments for deprecating two essential codec design
components are very one sided, by comparing "issues" to "features".

Please add all the comments I've made on the subject to the PEP.
The most important one missing is the fact and major difference
that TextIOWrapper does not work on a per codec basis, but
only on a per stream basis.

By removing the StreamReader and StreamWriter API parts of the
codec design, you essentially make it impossible to add
per codec variations and optimizations that require full access
to the stream interface.

A mentioned before, many improvements are possible and lots of those
can build on TextIOWrapper and the incremental codec parts.

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.

Redirecting codecs.open() to open() should be investigated.

For the issues you mention in the PEP, please open tickets
or add ticket references to the PEP.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 07 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/


> Victor
> 
> ---
> 
> PEP: xxx
> Title: Deprecate codecs.StreamReader and codecs.StreamWriter
> Version: $Revision$
> Last-Modified: $Date$
> Author: Victor Stinner
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 28-May-2011
> Python-Version: 3.3
> 
> 
> Abstract
> 
> 
> io.TextIOWrapper and codecs.StreamReaderWriter offer the same API
> [#f1]_. TextIOWrapper has more features and is faster than
> StreamReaderWriter. Duplicate code means that bugs should be fixed
> twice and that we may have subtle differences between the two
> implementations.
> 
> The codecs modules was introduced in Python 2.0, see the PEP 100. The
> io module was introduced in Python 2.6 and 3.0 (see the PEP 3116), and
> reimplemented in C in Python 2.7 and 3.1.
> 
> 
> Motivation
> ==
> 
> When the Python I/O model was updated for 3.0, the concept of a
> "stream-with-known-encoding" was introduced in the form of
> io.TextIOWrapper. As this class is critical to the performance of
> text-based I/O in Python 3, this module has an optimised C version
> which is used by CPython by default. Many corner cases in handling
> buffering, stateful codecs and universal newlines have been dealt with
> since the release of Python 3.0.
> 
> This new interface overlaps heavily with the legacy
> codecs.StreamReader, codecs.StreamWriter and codecs.StreamReaderWriter
> interfaces that were part of the original codec interface design in
> PEP 100. These interfaces are organised around the principle of an
> encoding with an associated stream (i.e. the reverse of arrangement in
> the io module), so the original PEP 100 design required that codec
> writers provide appropriate StreamReader and StreamWriter
> implementations in addition to the core codec encode() and decode()
> methods. This places a heavy burden on codec authors providing these
> specialised implementations to correctly handle many of the corner
> cases that have now been dealt with by io.TextIOWrapper. While deeper
> integration between the codec and the stream allows for additional
> optimisations in theory, these optimisations have in practice either
> not been carried out and else the associated code duplication means
> that the corner cases that have been fixed in io.TextIOWrapper are
> still not handled correctly in the various StreamReader and
> StreamWriter implementations.
> 
> Accordingly, this PEP proposes that:
> 
> * codecs.open() be updated to delegate to the builtin open() in Python
>   3.3;
> * the legacy codecs.Stream* interfaces, including the streamreader and
>   streamwriter attributes of codecs.CodecInfo be deprecated in Python
>   3.3 and removed in Python 3.4.
> 
> 
> Rationale
> =
> 
> StreamReader and StreamWriter issues
> 
> 
>  * StreamReader is unable to translate newlines.
>  * StreamReaderWriter handles reads using StreamReader and writes
>using

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Nick Coghlan 
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 strike me as particularly backwards compatible, since
>>> you've just enumerated the differences between StreamWriter/Reader and
>>> TextIOWrapper.
>>
>> 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 too well, people are surely relying on
> whatever behavior there is, broken or not.

True, but that's why changes like this are always a judgement call -
is the gain in correctness worth the risk of breakage? We sometimes
break workarounds when we fix bugs, too. From the discussion last time
around, that particular change wasn't very controversial, which is why
it is already in the 3.3 development tree.

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Vinay Sajip 
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 that there might be specific issues with them, but isn't
"actively harmful" a little strong? I don't see who is being actively harmed by
them, nor how.

Regards,

Vinay Sajip



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Nick Coghlan 
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 is not a
>> viable option in this case.
>
> I can understand that there might be specific issues with them, but isn't
> "actively harmful" a little strong? I don't see who is being actively harmed 
> by
> them, nor how.

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.

Codec writers are also told to implement utterly unnecessary
functionality just because PEP 100 says so. Significantly less common,
but still harmful.

The bare minimum change needed is for codecs.open() to do the right
thing in Py3k and be a wrapper around builtin open() and the main IO
stack. Once that happens, the legacy Stream* APIs become redundant
cruft that should be deprecated (although that part is significantly
less important than fixing codecs.open() itself)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Victor Stinner 

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
TextIOWrapper.
Which kind of differences are you thinking about? I only listed two 
attributes specific to StreamReaderWriter (.reader and .writer). You 
mean that these attributes are used? There are maybe other subtle 
differences between Stream* and TextIOWrapper, but I don't think that 
anyone relies on them. Should I try to list all differences in the PEP?


If I understood correctly the previous discussion, an important point is 
to be able to write code Python 2 which "just works" on Python 3 without 
using 2to3. If you don't rely on the subtle implementation details of 
Stream*, it's possible (to use codecs.open in Python 3, even if 
codecs.open is implemented to reuse TextIOWrapper via open). If you rely 
on the differences, I bet that it is easy to not use these differences 
(and continue to be compatible with Python 2). For example, you can 
replace f.reader.read() by f.read(), it's just the same.


The two classical usages of codecs.open() (of text files) are:

- read the whole file content
- read the file line by line

For this two usecases, the API is exactly the same. Using 
f=codecs.open() or f=open() (in Python 3, or f=io.open() in Python 2), 
you can use:


- for line in f: ...
- while True: line = f.readline(); if not line: break; ...
- f.read()

I'm not saying that my PEP doesn't break the compatibility, it *does* 
break the backward compatibility. That's why we need a PEP. That's why 
there is a section called "Backwards Compatibility" in the PEP. I'm 
trying to say that I bet that nobody will notice.


The most impacting change will be (at the end) the removal of the 
StreamReader/StreamWriter API. If a program uses directly these classes, 
it will have to be updated to use TextIOWrapper (or codecs.open() or 
open() maybe).


I wrote in a previous email:

"I did search for usage of these classes on the Internet, and except 
projects

implementing their own codecs (and so implement their
StreamReader/StreamWriter classes, even if they don't use it), I only found
one project using directly StreamReader: pygment (*). I searched 
quickly, so

don't trust these results :-) StreamReader & friends are used indirectly
through codecs.open(). My patch changes codecs.open() to make it reuse open
(io.TextIOWrapper), so the deprecation of StreamReader would not be 
noticed by

most users.

(*) I also found Sphinx, but I was wrong: it doesn't use StreamReader, 
it just
has a full copy of the UTF-8-SIG codec which has a StreamReader class. I 
don't

think that the class is used."

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Victor Stinner 

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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Victor Stinner 

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.


Can I upload it to the peps repository? According to the PEP 1, only a 
PEP editor can do that.

Please add all the comments I've made on the subject to the PEP.
I tried to incorporate all of your comments, but because the discussion 
on the bug tracker and on python-dev was long, I missed maybe some 
(important) points. Sorry about that, and please tell me which points 
should be added to the PEP.

The most important one missing is the fact and major difference
that TextIOWrapper does not work on a per codec basis, but
only on a per stream basis.

Yeah, it's not clear in the PEP, I should detail this point.

By removing the StreamReader and StreamWriter API parts of the
codec design, you essentially make it impossible to add
per codec variations and optimizations that require full access
to the stream interface.

A mentioned before, many improvements are possible and lots of those
can build on TextIOWrapper and the incremental codec parts.
I wrote that in the "Possible improvements of StreamReader and 
StreamWriter" section:


"A codec can implement variants which are optimized for the specific 
encoding ..."

and
"It would be possible to change StreamReader and StreamWriter to make 
them use IncrementalDecoder and IncrementalEncoder."

For the issues you mention in the PEP, please open tickets
or add ticket references to the PEP.

Ok, I will do that. There are other Stream* issues, a recent example:
http://bugs.python.org/issue12508

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Vinay Sajip 
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 to convert codecs.open() calls to open(), if they don't want the
performance to be sub-optimal. But I thought the main thrust of this was about
deprecation of the Stream* classes, not open() vs. codecs.open().
 
> Codec writers are also told to implement utterly unnecessary
> functionality just because PEP 100 says so. Significantly less common,
> but still harmful.

Presumably only an issue for anyone writing new codecs for 2.x - I'm not sure
how many cases that'd be.

> The bare minimum change needed is for codecs.open() to do the right
> thing in Py3k and be a wrapper around builtin open() and the main IO
> stack. Once that happens, the legacy Stream* APIs become redundant
> cruft that should be deprecated (although that part is significantly
> less important than fixing codecs.open() itself)

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
would give 2.x->3.x porting projects more trouble than codecs.open() -> open().

Regards,

Vinay Sajip




___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Barry Warsaw 
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 [email protected]

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Nick Coghlan 
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 I contact a PEP editor? How?
>
> Email [email protected]

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 writes a PEP has
commit privileges for the python.org repos.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Nick Coghlan 
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
> would give 2.x->3.x porting projects more trouble than codecs.open() -> 
> open().

No, using the io module is a far more robust way to wrap arbitrary
streams than using the codecs module.

It's unfortunate that nobody pointed out the redundancy when PEP 3116
was discussed and implemented, as I expect PEP 100 would have been
updated and the Stream* APIs would have been either reused or
officially jettisoned as part of the Py3k migration.

However, we're now in a situation where we have:

1. A robust Unicode capable IO implementation (the io module, based on
PEP 3116) that is available in both 2.x and 3.x that is designed to
minimise the amount of work involved in writing new codecs
2. A legacy IO implementation (the codecs module) that is available in
both 2.x and 3.x, but requires additional work on the part of codec
authors and isn't as robust as the PEP 3116 implementation

So the options are:

A. Bring the codecs module IO implementation up to the standard of the
io module implementation (less the C acceleration) and maintain the
requirement that codec authors provide StreamReader and StreamWriter
implementations.

B. Retain the full codecs module API, but reimplement relevant parts
in terms of the io module.

C. Deprecate the codecs.Stream* interfaces and make codecs.open() a
simple wrapper around the builtin open() function. Formally drop the
requirement that codec authors provide StreamReader/Writer instances
(since they are not used by the core IO implementation)

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. That may change
if someone actually goes through and *fixes* all the error cases that
are handled correctly by the io module but not by the codecs module
and credibly promises to continue to do so for at least the life of
3.3.

A 2to3 fixer that simply changes "codecs.open" to "open" is not
viable, as the function signatures are not compatible (the buffering
parameter appears in a different location):
codecs.open(): open(filename, mode='rb', encoding=None,
errors='strict', buffering=1)
3.x builtin open(): open(file, mode='r', buffering=-1,
encoding=None, errors=None, newline=None, closefd=True)

Now, the backported io module does make it possible to write correct
code as far back as 2.6 that can be forward ported cleanly to 3.x
without requiring code modifications. However, it would be nice to
transparently upgrade code that uses codecs.open to the core IO
implementation in 3.x. For people new to Python, the parallel (and
currently deficient) alternative IO implementation also qualifies at
the very least as an attractive nuisance.

Now, it may be that this PEP runs afoul of Guido's stated preference
not to introduce any more backwards incompatibilities between 2.x and
3.x that aren't absolutely essential. In that case, it may be
reasonable to add an option D to the mix, where we just add
documentation notes telling people not to use the affected codecs
module APIs and officially declare that bug reports on those APIs will
be handled with "don't use these, use the io module instead", as that
would also deal with the maintenance problem. It's pretty ugly from an
end user's point of view, though.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Victor Stinner 

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 writes a PEP has
commit privileges for the python.org repos.

Ok, done:
http://www.python.org/dev/peps/pep-0400/
http://hg.python.org/peps/file/tip/pep-0400.txt

I started to include Marc-Andre's suggestions.

Victor
___
Python-Dev mailing list
[email protected]
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 Launcher for Windows (PEP 397) needs testing!

2011-07-07 Thread Gertjan Klein 
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/vinay.sajip/pylauncher

GUILauncher and CLILauncher refuse to build with Visual C++ 2008 Express
Edition (using Launchers.sln):

.\CLILauncher.rc(97) : error RC2135 : file not found:
C:\Users\Vinay\Projects\Launchers\launcher.ico

This is on Windows XP Pro, 32 bit.

There are a few compilation warnings as well:

.\launcher.c(59) : warning C4996: '_wgetenv': This function or variable
may be unsafe. Consider using _wdupenv_s instead. To disable
deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

Associator builds (with the same warning displayed above). When checking
it's dependencies, I see it depends on MSVCR90.DLL. You've mentioned
that you use only "plain C and Win32 APIs"; would it be possible to
remove this dependency? That would make it possible to copy the
executable to a directory on the PATH, without having to worry about
installing the C(++) runtime.

Regards,
Gertjan.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Victor Stinner 

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
___
Python-Dev mailing list
[email protected]
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 Launcher for Windows (PEP 397) needs testing!

2011-07-07 Thread Paul Moore 
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 source available on
>
> https://bitbucket.org/vinay.sajip/pylauncher
>
> there are built 32- and 64-bit msi files at
>
> https://bitbucket.org/vinay.sajip/pylauncher/downloads

I just tried to install launcher.msi, and it seems to have done nothing.

This is on Windows XP SP3 with Python 2.7 installed. It's a corporate
build so there may be funny security limits hindering things, but I
have admin rights and normally don't have problems.

msiexec /i launcher.msi /l* launcher.log gives the following log file.
I can't see any errors in there, but all those "return code 1" entries
look odd (surely 0 is success and 1 failure as with OS commands?)

Paul.

=== Logging started: 07/07/2011  15:01:42 ===
Action 15:01:42: INSTALL.
Action start 15:01:42: INSTALL.
Action 15:01:42: ProgramFilesFolder.9CA91B9B_69A1_494B_A200_44AA4D54BC92.
Action start 15:01:42: ProgramFilesFolder.9CA91B9B_69A1_494B_A200_44AA4D54BC92.
Action ended 15:01:42:
ProgramFilesFolder.9CA91B9B_69A1_494B_A200_44AA4D54BC92. Return value
1.
Action 15:01:42: ValidateProductID.
Action start 15:01:42: ValidateProductID.
Action ended 15:01:42: ValidateProductID. Return value 1.
Action 15:01:42: CostInitialize. Computing space requirements
Action start 15:01:42: CostInitialize.
Action ended 15:01:42: CostInitialize. Return value 1.
Action 15:01:42: FileCost. Computing space requirements
Action start 15:01:42: FileCost.
Action ended 15:01:42: FileCost. Return value 1.
Action 15:01:42: CostFinalize. Computing space requirements
Action start 15:01:42: CostFinalize.
Action ended 15:01:42: CostFinalize. Return value 1.
Action 15:01:42: ExecuteAction.
Action start 15:01:42: ExecuteAction.
Action start 15:01:42: INSTALL.
Action start 15:01:42: ProgramFilesFolder.9CA91B9B_69A1_494B_A200_44AA4D54BC92.
Action ended 15:01:42:
ProgramFilesFolder.9CA91B9B_69A1_494B_A200_44AA4D54BC92. Return value
1.
Action start 15:01:42: ValidateProductID.
Action ended 15:01:42: ValidateProductID. Return value 1.
Action start 15:01:42: CostInitialize.
Action ended 15:01:42: CostInitialize. Return value 1.
Action start 15:01:42: FileCost.
Action ended 15:01:42: FileCost. Return value 1.
Action start 15:01:42: CostFinalize.
Action ended 15:01:42: CostFinalize. Return value 1.
Action start 15:01:42: InstallValidate.
Action ended 15:01:42: InstallValidate. Return value 1.
Action start 15:01:42: InstallInitialize.
Action ended 15:01:42: InstallInitialize. Return value 1.
Action start 15:01:42: ProcessComponents.
Action ended 15:01:42: ProcessComponents. Return value 1.
Action start 15:01:42: UnpublishFeatures.
Action ended 15:01:42: UnpublishFeatures. Return value 1.
Action start 15:01:42: RemoveRegistryValues.
Action ended 15:01:42: RemoveRegistryValues. Return value 1.
Action start 15:01:42: RemoveFiles.
Action ended 15:01:42: RemoveFiles. Return value 0.
Action start 15:01:42: InstallFiles.
Action ended 15:01:42: InstallFiles. Return value 1.
Action start 15:01:42: WriteRegistryValues.
Action ended 15:01:42: WriteRegistryValues. Return value 1.
Action start 15:01:42: RegisterUser.
Action ended 15:01:42: RegisterUser. Return value 0.
Action start 15:01:42: RegisterProduct.
Action ended 15:01:42: RegisterProduct. Return value 1.
Action start 15:01:42: PublishFeatures.
Action ended 15:01:42: PublishFeatures. Return value 1.
Action start 15:01:42: PublishProduct.
Action ended 15:01:42: PublishProduct. Return value 1.
Action start 15:01:42: InstallFinalize.
Action ended 15:01:43: InstallFinalize. Return value 1.
Action ended 15:01:43: INSTALL. Return value 1.
Property(S): TARGETDIR = D:\
Property(S): SourceDir = D:\Downloads\
Property(S): Manufacturer = Vinay Sajip
Property(S): ProductCode = {298B5D62-1287-427F-B8D9-B44D605F8F6B}
Property(S): ProductLanguage = 1033
Property(S): ProductName = Python Launcher
Property(S): ProductVersion = 1.0.0.0
Property(S): UpgradeCode = {36B0A82E-0B4E-47CD-895B-FD4EC726B3AC}
Property(S): ARPPRODUCTICON = arpicon
Property(S): ProgramFilesFolder.9CA91B9B_69A1_494B_A200_44AA4D54BC92 =
C:\Program Files\
Property(S): ProgDir.9CA91B9B_69A1_494B_A200_44AA4D54BC92 = C:\Program
Files\Python Launcher\
Property(S): PackageCode = {C9DC0563-F67F-4F32-A0B1-1D77B10AD2AF}
Property(S): ProductState = 5
Property(S): ProductToBeRegistered = 1
Property(S): CURRENTDIRECTORY = D:\Data
Property(S): CLIENTUILEVEL = 0
Property(S): CLIENTPROCESSID = 5636
Property(S): PRODUCTLANGUAGE = 1033
Property(S): USERNAME = Atos Origin
Property(S): COMPANYNAME = Atos Origin
Property(S): ROOTDRIVE = D:\
Property(S): EXECUTEACTION = INSTALL
Property(S): ACTION = INSTALL
Property(S): INSTALLLEVEL = 1
Property(S): SECONDSEQUENCE = 1
Property(S): _MSI_FEATURE_SELECTION = _NONE_
Property(S): VersionDatab

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Victor Stinner 



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 (-> TextIOWrapper) and 
StreamReaderWriter (-> TextIOWrapper), but not for EncodedFile (by the 
why, who use this horrible class? :-)).


I would prefer solution C to have only one obvious way to read-write 
text files in Python 3(.4).

A 2to3 fixer that simply changes "codecs.open" to "open" is not
viable, as the function signatures are not compatible (the buffering
parameter appears in a different location):
 codecs.open(): open(filename, mode='rb', encoding=None,
errors='strict', buffering=1)
 3.x builtin open(): open(file, mode='r', buffering=-1,
encoding=None, errors=None, newline=None, closefd=True)
What? The prototypes are very close, you just to have to invert some 
arguments. Why do you think that we cannot implement that?

Now, the backported io module does make it possible to write correct
code as far back as 2.6 that can be forward ported cleanly to 3.x
without requiring code modifications. However, it would be nice to
transparently upgrade code that uses codecs.open to the core IO
implementation in 3.x. For people new to Python, the parallel (and
currently deficient) alternative IO implementation also qualifies at
the very least as an attractive nuisance.
Use codecs.open() if you would like to support Python 3 and Python 2 
older than 2.6.


If you don't care of Python 2.5, use directly the io module (you just 
have to know that it is slow in Python 2.6).


Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Antoine Pitrou 
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
> > > codec-specific classes are currently broken.
> > 
> > Yes, but as we all know too well, people are surely relying on
> > whatever behavior there is, broken or not.
> 
> There's also the fact that code which currently runs under 2.x and 3.x would
> stop working if codecs.StreamReader/StreamWriter were to go away.

That's a fact of life for any deprecation. But it only stops working
*after* the deprecation period has expired. And deprecated stuff can
actually stay in for a long time, depending on its popularity.

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, regardless of whether or
not the "thing" actually gets removed in a later version.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Antoine Pitrou 
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 them without a PEP, which is quite different.
Now we have a PEP and the matter can be discussed using the appropriate
procedure.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
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 Launcher for Windows (PEP 397) needs testing!

2011-07-07 Thread Paul Moore 
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 entries in HKEY_CLASSES_ROOT\Python.File,
> Python.NoConFile and Python.CompiledFile which point to those installed files.
>
> Can you confirm if this is the case?

Ah, yes. This is what has happened.

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.

2. I thought the idea from the PEP was to put py.exe/pyw.exe into a
"system" location which is already on the PATH (likely
windows\system32, or whatever the 64-bit equivalent is). That way, py
or py -3 and similar can be used to launch the interactive
interpreter.

3. Given that you're not installing in system32, you should add the
install dir to PATH (and remove it on uninstall :-)) That's definitely
a second-best option, though, so I'd rather you didn't, but installed
in system32 instead :-)

4. If you embed both of the py.ico and pyc.ico files into the launcher
exes, you wouldn't need to have them as separate files (I see py.ico
is embedded already) and so the footprint becomes 2 exes and an ini
file. That might be a bit more palatable for people who are
uncomfortable with installing into somewhere like system32.

Otherwise it looks great.

> P.S. I didn't copy the list, as if there is some problem which requires going
> back and forth a bit, it would be OT for the list.

Agreed. I've added the list back in as the above is really design
feedback, and so would benefit from comments from the list.

Paul.
___
Python-Dev mailing list
[email protected]
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 Launcher for Windows (PEP 397) needs testing!

2011-07-07 Thread Vinay Sajip 
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 C4996: '_wgetenv': This function or variable
> may be unsafe. Consider using _wdupenv_s instead. To disable
> deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

This is a security related warning which I think can be ignored - we only ever
read environment values, never write them, so making a private copy via _wdupenv
isn't really needed IMO. I don't disable the warning because it would disable
all security-related warnings.
 
> Associator builds (with the same warning displayed above). When checking
> it's dependencies, I see it depends on MSVCR90.DLL. You've mentioned
> that you use only "plain C and Win32 APIs"; would it be possible to
> remove this dependency? That would make it possible to copy the
> executable to a directory on the PATH, without having to worry about
> installing the C(++) runtime.

I noticed this too, and later builds of associator have the library linked in
statically.

If you get any more issues, you can post them on the BitBucket issue tracker -
they are probably OT for here, unless design/PEP related.

Regards,

Vinay Sajip



___
Python-Dev mailing list
[email protected]
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 Launcher for Windows (PEP 397) needs testing!

2011-07-07 Thread Vinay Sajip 
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 good idea for the standalone launcher.
The installer is a bit tentative because (a) the PEP is still
under discussion, and (b) I don't know exactly how launcher installation
will work as part of Python installation. 
 
> 2. I thought the idea from the PEP was to put py.exe/pyw.exe into a
> "system" location which is already on the PATH (likely
> windows\system32, or whatever the 64-bit equivalent is). That way, py
> or py -3 and similar can be used to launch the interactive
> interpreter.

This can always be changed in the installer - the PEP says install in System32
"if possible", and I'm not yet sure of all the security/permissions implications
of that. The current location should be usable for test purposes, even if you
have to manually add to the path for now.

> 3. Given that you're not installing in system32, you should add the
> install dir to PATH (and remove it on uninstall ) That's definitely
> a second-best option, though, so I'd rather you didn't, but installed
> in system32 instead 

I'll look at changing the installer builds to do this.

> 4. If you embed both of the py.ico and pyc.ico files into the launcher
> exes, you wouldn't need to have them as separate files (I see py.ico
> is embedded already) and so the footprint becomes 2 exes and an ini
> file. That might be a bit more palatable for people who are
> uncomfortable with installing into somewhere like system32.
> 
> Otherwise it looks great.
> 

Thanks for the feedback. Please log any implementation-related issues on the
BitBucket tracker.

Regards,

Vinay Sajip

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Antoine Pitrou 
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 B either, I think the
only option seriously on the table is C.

> Now, it may be that this PEP runs afoul of Guido's stated preference
> not to introduce any more backwards incompatibilities between 2.x and
> 3.x that aren't absolutely essential.

Well, a deprecation isn't an incompatibility in itself.
Especially when deprecation warnings are hidden by default.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] making socket.getaddrinfo use cached dns

2011-07-07 Thread high bandwidth 
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 subsequent access to the same site to be fast and not require lengthy
calls to getaddrinfo. How can I get python to correctly use cached dns
lookups and ipv4 only (at least in those cases where it is appropriate).

As mentioned here:
http://stackoverflow.com/questions/2014534/force-python-mechanize-urllib2-to-only-use-a-requests/2035686#2035686
It seems that many python libraries are hardcoded to look for both ipv6 and
ipv4. Since ipv6 lookups are extremely slow at least for some users, perhaps
the devs should carry over these optional arguments to higher level
libraries like mechanize, urllib, httplib etc.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Terry Reedy 

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, regardless of whether or
not the "thing" actually gets removed in a later version.


Yes, the final decision could be deprecate now, remove in 4.0, as 
happened during the 2.x series.




___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] making socket.getaddrinfo use cached dns

2011-07-07 Thread Oleg Broytman 
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/news
group is the best place; there are Python developers who participate in it;
you may get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.

On Thu, Jul 07, 2011 at 12:57:59PM -0400, high bandwidth wrote:
> 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 subsequent access to the same site to be fast and not require lengthy
> calls to getaddrinfo. How can I get python to correctly use cached dns
> lookups and ipv4 only (at least in those cases where it is appropriate).
> 
> As mentioned here:
> http://stackoverflow.com/questions/2014534/force-python-mechanize-urllib2-to-only-use-a-requests/2035686#2035686
> It seems that many python libraries are hardcoded to look for both ipv6 and
> ipv4. Since ipv6 lookups are extremely slow at least for some users, perhaps
> the devs should carry over these optional arguments to higher level
> libraries like mechanize, urllib, httplib etc.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Victor Stinner 

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 that's a very reasonable thing to do, regardless of whether or
not the "thing" actually gets removed in a later version.


Yes, the final decision could be deprecate now, remove in 4.0, as 
happened during the 2.x series.


Python 4? Are you serious?

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Brett Cannon 
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
>>> anymore, and that a (allegedly better) alternative is available.
>>> I think that's a very reasonable thing to do, regardless of whether or
>>> not the "thing" actually gets removed in a later version.
>>>
>>
>> Yes, the final decision could be deprecate now, remove in 4.0, as happened
>> during the 2.x series.
>>
>
> Python 4? Are you serious?
>


Yes he is, as are others who would support that position (not me; I prefer
two releases of pending deprecation, one release deprecation, then removal).
When I was organizing the stdlib reorg, one viewpoint that came up was to
never actually remove module code but simply deprecate it so that that those
who care to use the module can continue to do so, but otherwise let it
bit-rot so that pre-existing code does not necessarily break.

-Brett



>
> Victor
>
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> brett%40python.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

2011-07-07 Thread Nick Coghlan 
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
>>> anymore, and that a (allegedly better) alternative is available.
>>> I think that's a very reasonable thing to do, regardless of whether or
>>> not the "thing" actually gets removed in a later version.
>>
>> Yes, the final decision could be deprecate now, remove in 4.0, as happened
>> during the 2.x series.
>
> Python 4? Are you serious?

Py3k was a mythological "some time in the dim distant future" target
for backwards incompatible changes for a long time before it became a
real project that people were working on actually building. Py4k is
now a similarly mythological beast :)

However, like Brett, I don't think it's actually needed in this
particular case. Deprecation in 3.3, removal in 3.5 is a time frame
completely in line with the desire to avoid a repeat of the
PyCObject/PyCapsule related incompatibility problems.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com