Le samedi 29 octobre 2011 07:47:01, vous avez écrit :
> Therefore, as you imply, I think the solution to this issue is to start
> the process of deprecating the bytes version of the api in py3k with a
> view to removing it completely - possibly with a less aggressive
> timeline than normal. In Pyt
On 10/30/2011 5:39 PM, Victor Stinner wrote:
Terry J. Reedy is also concerned about backward compatibility (3.2 ->
3.3). Emiting a warning, disabled by default, is a softer solution :-)
The fact that Mark, Martin, and someone else, I believe, agree with you
that the bytes api is not useful at
On 31/10/2011 8:39 AM, Victor Stinner wrote:
Le 29/10/2011 07:47, Mark Hammond a écrit :
When previously discussing this issue, I was under the impression that
the problem was unencodable bytes passed from the Python code to Windows
- but the reverse is true - only the data coming back from Wind
Le 29/10/2011 07:47, Mark Hammond a écrit :
When previously discussing this issue, I was under the impression that
the problem was unencodable bytes passed from the Python code to Windows
- but the reverse is true - only the data coming back from Windows isn't
encodable.
The undecodable filenam
Le 30/10/2011 09:00, "Martin v. Löwis" a écrit :
As quoted above, deprecation of the bytes version of the API sounds
fine to me, but isn't this going to run into the usual objections from
the "we need bytes for efficiency" crowd? It's OK with me to
say "in this restricted area you must convert
On Sun, Oct 30, 2011 at 6:00 PM, "Martin v. Löwis" wrote:
>> As quoted above, deprecation of the bytes version of the API sounds
>> fine to me, but isn't this going to run into the usual objections from
>> the "we need bytes for efficiency" crowd? It's OK with me to
>> say "in this restricted are
> As quoted above, deprecation of the bytes version of the API sounds
> fine to me, but isn't this going to run into the usual objections from
> the "we need bytes for efficiency" crowd? It's OK with me to
> say "in this restricted area you must convert to Unicode", but is that
> going to fly with
"Martin v. Löwis" writes:
> > Therefore, as you imply, I think the solution to this issue is to start
> > the process of deprecating the bytes version of the api in py3k with a
> > view to removing it completely
> That sounds all fine to me.
As quoted above, deprecation of the bytes version
> Therefore, as you imply, I think the solution to this issue is to start
> the process of deprecating the bytes version of the api in py3k with a
> view to removing it completely - possibly with a less aggressive
> timeline than normal. In Python 2.7, I think documenting the issue and
> a recomme
On 29/10/2011 9:52 AM, Victor Stinner wrote:
Hi,
I am not more conviced that raising a UnicodeEncodeError on unencodable
characters is the right fix for the issue #13247. The problem with this
solution is that you have to wait until an user get a UnicodeEncodeError.
I have yet another propositi
Hi,
I am not more conviced that raising a UnicodeEncodeError on unencodable
characters is the right fix for the issue #13247. The problem with this
solution is that you have to wait until an user get a UnicodeEncodeError.
I have yet another proposition: emit a warning when a bytes filename is u
11 matches
Mail list logo
