Le lundi 19 avril 2010 22:55:39, vous avez écrit :
> Can you please elaborate what the specific issue is?
Amaury reopened my issue #8393 "subprocess: support undecodable current
working directory on POSIX OS" because "It does not work on Windows" (bytes
are rejected).
> I completely fail to see
Victor Stinner:
> It's a choice, I didn't want to patch Windows because I know that Windows use
> unicode internally. I consider that developers using Python3 should use
> unicode on Windows, and byte or unicode+surrogates on other OS.
The Win32 byte string APIs convert their inputs to Unicode
On Mon, Apr 19, 2010 at 12:51 PM, Michael Foord
wrote:
> On 19/04/2010 21:19, Scott Dial wrote:
>> Is consensus superficial?
>
> No, but it isn't always possible or necessary. In general the maintainer of
> a module should make the best decision, not the one with the most backing.
> :-)
Yep, that
> I'm working on surrogates in filenames on Linux (more generally on BSD and
> UNIX OS) to support undecodable filenames, see PEP 383. Amaury told me that I
> only fixed the non-Windows versions (I fixed subprocess about the current
> directory and _ctypes.dlopen()), but it doesn't work on Windo
Antoine Pitrou wrote:
> Victor Stinner haypocalc.com> writes:
>> It's a choice, I didn't want to patch Windows because I know that Windows
>> use
>> unicode internally. I consider that developers using Python3 should use
>> unicode on Windows, and byte or unicode+surrogates on other OS.
>
> I
On 19/04/2010 21:19, Scott Dial wrote:
On 4/18/2010 9:44 PM, Steve Holden wrote:
Tobias Herp wrote:
Steven Bethard schrieb:
On Sun, Apr 18, 2010 at 2:35 PM, Tobias Herp wrote:
Steven Bethard schrieb:
But I'd really like a consensus about the correct b
On 4/18/2010 9:44 PM, Steve Holden wrote:
> Tobias Herp wrote:
>> Steven Bethard schrieb:
>>> On Sun, Apr 18, 2010 at 2:35 PM, Tobias Herp wrote:
Steven Bethard schrieb:
> But I'd really like a consensus about the correct behavior, and so far
> I have not seen that.
>>
>> Do you take
Antoine Pitrou writes:
> Does it include a license for Windows itself?
> Does it allow me to install and run it in a VM?
> If so, I'm interested.
Yes, in fact, it's due to the availability of this license that I was
able to set up the Win7 buildbot.
-- David
___
I'm with Martin; just let it be explicit and stick an example in the docs.
-Brett (from his phone with hopefully only one copy sent of this email)
On Apr 18, 2010 9:22 PM, Martin v. Löwis wrote:
> - many optparse programs use the version argument
> - many other programmers find this feature ver
Barry Warsaw wrote:
> On Apr 19, 2010, at 08:14 AM, Brian Curtin wrote:
>
>> On Mon, Apr 19, 2010 at 06:48, Steve Holden wrote:
>>
>>> Antoine Pitrou wrote:
Le Fri, 16 Apr 2010 08:01:54 -0500, Brian Curtin a écrit :
> The recent threads on builds/installers for Mac and Windows reminded m
On Apr 19, 2010, at 08:14 AM, Brian Curtin wrote:
>On Mon, Apr 19, 2010 at 06:48, Steve Holden wrote:
>
>> Antoine Pitrou wrote:
>> > Le Fri, 16 Apr 2010 08:01:54 -0500, Brian Curtin a écrit :
>> >> The recent threads on builds/installers for Mac and Windows reminded me
>> >> of Steve Holden's pu
On Mon, Apr 19, 2010 at 06:48, Steve Holden wrote:
> Antoine Pitrou wrote:
> > Le Fri, 16 Apr 2010 08:01:54 -0500, Brian Curtin a écrit :
> >> The recent threads on builds/installers for Mac and Windows reminded me
> >> of Steve Holden's push to get the python-dev team equipped via a
> >> connect
On 19/04/2010 13:33, Paul Moore wrote:
On 19 April 2010 11:47, Antoine Pitrou wrote:
Le Fri, 16 Apr 2010 08:01:54 -0500, Brian Curtin a écrit :
The recent threads on builds/installers for Mac and Windows reminded me
of Steve Holden's push to get the python-dev team equipped via a
connection w
On 19 April 2010 11:47, Antoine Pitrou wrote:
> Le Fri, 16 Apr 2010 08:01:54 -0500, Brian Curtin a écrit :
>>
>> The recent threads on builds/installers for Mac and Windows reminded me
>> of Steve Holden's push to get the python-dev team equipped via a
>> connection with the Microsoft Open Source
On 19 April 2010 04:44, Ron Adam wrote:
> Note that the python interpreter uses -V and --version.
>
> r...@gutsy:~$ python3.1 -V
> Python 3.1.2
> r...@gutsy:~$ python3.1 --version
> Python 3.1.2
>
> And -v is used as follows:
>
> -v : verbose (trace import statements); also PYTHONVERBOSE=x
>
On 19/04/2010 12:47, Antoine Pitrou wrote:
Le Fri, 16 Apr 2010 08:01:54 -0500, Brian Curtin a écrit :
The recent threads on builds/installers for Mac and Windows reminded me
of Steve Holden's push to get the python-dev team equipped via a
connection with the Microsoft Open Source Technology
Antoine Pitrou wrote:
> Le Fri, 16 Apr 2010 08:01:54 -0500, Brian Curtin a écrit :
>> The recent threads on builds/installers for Mac and Windows reminded me
>> of Steve Holden's push to get the python-dev team equipped via a
>> connection with the Microsoft Open Source Technology Center. The OSTC
Victor Stinner haypocalc.com> writes:
>
> It's a choice, I didn't want to patch Windows because I know that Windows use
> unicode internally. I consider that developers using Python3 should use
> unicode on Windows, and byte or unicode+surrogates on other OS.
I think both possibilities should
Le Fri, 16 Apr 2010 08:01:54 -0500, Brian Curtin a écrit :
>
> The recent threads on builds/installers for Mac and Windows reminded me
> of Steve Holden's push to get the python-dev team equipped via a
> connection with the Microsoft Open Source Technology Center. The OSTC
> team provides Microsof
Le lundi 19 avril 2010 11:33:58, Victor Stinner a écrit :
> I'm working on surrogates in filenames on Linux (...)
Related issues:
#8391: os.execvpe() doesn't support surrogates in env
#8393: subprocess: support undecodable current working directory on POSIX OS
#8394: ctypes.dlopen() doesn't suppo
Hi,
I'm working on surrogates in filenames on Linux (more generally on BSD and
UNIX OS) to support undecodable filenames, see PEP 383. Amaury told me that I
only fixed the non-Windows versions (I fixed subprocess about the current
directory and _ctypes.dlopen()), but it doesn't work on Windows.
21 matches
Mail list logo