Please no. Let's not add unrelated new functionality in with this
already large change with not entirely understood consequences.
On Thu, Sep 8, 2016 at 1:05 PM, Chris Barker wrote:
> On Thu, Sep 8, 2016 at 10:35 AM, Random832 wrote:
>>
>>
>> It means that the so-called "bash" on windows 10 is a
On Thu, Sep 8, 2016 at 1:14 PM, Guido van Rossum wrote:
> Please no. Let's not add unrelated new functionality in with this
> already large change with not entirely understood consequences.
>
Fair enough -- this is clearly a really raw API so far.
-CHB
>
> On Thu, Sep 8, 2016 at 1:05 PM, C
On Thu, Sep 8, 2016 at 10:35 AM, Random832 wrote:
>
> It means that the so-called "bash" on windows 10 is actually a full
> Ubuntu system (running on, AIUI, a simulation of Linux kernel system
> calls), which will presumably also have its own python installation and
> use a UTF-8 locale, rather t
On Thu, Sep 8, 2016, at 13:10, Guido van Rossum wrote:
> On Thu, Sep 8, 2016 at 9:57 AM, Brett Cannon wrote:
> > Bash on Windows is just Linux, so it isn't affected by any of this.
>
> I don't know what that sentence means.
It means that the so-called "bash" on windows 10 is actually a full
Ubun
On Thu, Sep 8, 2016 at 9:57 AM, Brett Cannon wrote:
>
>
> On Thu, 8 Sep 2016 at 09:06 Chris Barker wrote:
>>
>> On Wed, Sep 7, 2016 at 10:37 AM, Guido van Rossum
>> wrote:
>>>
>>> And apart from Python, few shell commands that work on
>>> Unix make much sense on Windows,
>>
>>
>> Does the (optio
On Thu, 8 Sep 2016 at 09:06 Chris Barker wrote:
> On Wed, Sep 7, 2016 at 10:37 AM, Guido van Rossum
> wrote:
>
>> And apart from Python, few shell commands that work on
>> Unix make much sense on Windows,
>
>
> Does the (optional) addition of bash to Windows 10 have any impact on this?
>
> It'll
On Wed, Sep 7, 2016 at 10:37 AM, Guido van Rossum wrote:
> And apart from Python, few shell commands that work on
> Unix make much sense on Windows,
Does the (optional) addition of bash to Windows 10 have any impact on this?
It'll be something that Windows developers can't count on their users
On 8 September 2016 at 03:37, Guido van Rossum wrote:
> On Sun, Sep 4, 2016 at 11:58 PM, Nick Coghlan wrote:
>> While calling system native apps that way will still have many
>> portability challenges, there are also plenty of cases where folks use
>> sys.executable to launch new Python processes
On 07Sep2016 1037, Guido van Rossum wrote:
I'm hijacking this thread to provisionally accept PEP 529. (I'll also
do this for PEP 528, in its own thread.)
I've talked things over with Steve and Victor and we're going to do an
experiment (as now written up in the PEP:
https://www.python.org/dev/pe
I'm hijacking this thread to provisionally accept PEP 529. (I'll also
do this for PEP 528, in its own thread.)
I've talked things over with Steve and Victor and we're going to do an
experiment (as now written up in the PEP:
https://www.python.org/dev/peps/pep-0529/#beta-experiment) to tease
out an
On 5 September 2016 at 15:59, Steve Dower wrote:
> +continue to default to ``locale.getpreferredencoding()`` (for text files) or
> +plain bytes (for binary files). This only affects the encoding used when
> users
> +pass a bytes object to Python where it is then passed to the operating
> system
I posted an update to PEP 529 at
https://github.com/python/peps/blob/master/pep-0529.txt and a diff below. The
update includes more detail on the affected code within CPython - including a
number of references to broken code that would be resolved with the change -
and more details about the ne
Nick Coghlan (ncoghlan at gmail.com) on Sat Sep 3 12:27:44 EDT 2016 wrote:
> After also reading the Windows console encoding PEP, I realised
> there's a couple of missing discussions here regarding the impacts on
> sys.argv, os.environ, and os.environb.
>
> The reason that's relevant is that "sys.
On 4 September 2016 at 00:49, Nick Coghlan wrote:
> On 2 September 2016 at 08:31, Steve Dower wrote:
>> This proposal would remove all use of the *A APIs and only ever call the *W
>> APIs. When Windows returns paths to Python as str, they will be decoded from
>> utf-16-le and returned as text (in
On 2 September 2016 at 08:31, Steve Dower wrote:
> This proposal would remove all use of the *A APIs and only ever call the *W
> APIs. When Windows returns paths to Python as str, they will be decoded from
> utf-16-le and returned as text (in whatever the minimal representation is).
> When
> Windo
On 1 September 2016 at 23:31, Steve Dower wrote:
[...]
> As a result, POSIX-focused library authors prefer to use bytes to represent
> paths.
A minor point, but in my experience, a lot of POSIX-focused authors
are happy to move to a better text/bytes separation, so I'd soften
this to "some POSIX-
I'm about to be offline for a few days, so I wanted to get my current
draft PEPs out for people can read and review.
I don't believe there is a lot of change as a result of either PEP, but
the impact of what change there is needs to be weighed against the benefits.
We've already had some thor
17 matches
Mail list logo
