Thu, Aug 11, 2016 at 6:41 PM, Adam Bartoš wrote:
> The transcoding wrappers with 'utf-8' encoding are used just as a work
> around the fact that Python tokenizer cannot use utf-16-le and that the
> readlinehook machinery is unfortunately bytes-based. The tanscoding wrapper
> just has encoding 'utf
On Thu, Aug 11, 2016 at 9:07 AM, Paul Moore wrote:
> set codepage to UTF-8
> ...
> set codepage back
> spawn subprocess X, but don't wait for it
> set codepage to UTF-8
> ...
> ... At this point what codepage does Python see? What codepage does
> process X see? (Note that they are both sharing the
I was thinking we would end up using the console API for input but stick with
the standard handles for output, mostly to minimize the amount of magic
switching we have to do. But since we can just switch the entire stream object
in __std*__ once at startup if nothing is redirected it probably is
On 12 August 2016 at 13:38, eryk sun wrote:
>> ... At this point what codepage does Python see? What codepage does
>> process X see? (Note that they are both sharing the same console).
>
> The input and output codepages are global data in conhost.exe. They
> aren't tracked for each attached proces
On Wed, Aug 10, 2016, at 14:10, Steve Dower wrote:
> * force the console encoding to UTF-8 on initialize and revert on
> finalize
>
> So what are your concerns? Suggestions?
As far as I know, the single biggest problem caused by the status quo
for console encoding is "some string containing chara
On Wed, Aug 10, 2016, at 15:08, Steve Dower wrote:
> That's the hope, though that module approaches the solution differently
> and may still uses. An alternative way for us to fix this whole thing
> would be to bring win_unicode_console into the standard library and use
> it by default (or proba
*On Fri Aug 12 11:33:35 EDT 2016, *
*Random832 wrote:*> On Wed, Aug 10, 2016, at 15:08, Steve Dower wrote:
>>* That's the hope, though that module approaches the solution differently
*>>* and may still uses. An alternative way for us to fix this whole thing
*>>* would be to bring win_unicode_conso
On Fri, Aug 12, 2016 at 6:41 AM, Paul Moore wrote:
> I
> understand Steve's point about being an improvement over 100% wrong,
> but we've lived with the current state of affairs long enough that I
> think we should take whatever time is needed to do it right,
Sure -- but his is such a freakin'
On 12 August 2016 at 18:05, Chris Barker wrote:
> On Fri, Aug 12, 2016 at 6:41 AM, Paul Moore wrote:
>>
>> I
>> understand Steve's point about being an improvement over 100% wrong,
>> but we've lived with the current state of affairs long enough that I
>> think we should take whatever time is ne
On Fri, Aug 12, 2016, at 12:24, Adam Bartoš wrote:
> There is no buffer just on those wrapping streams because the bytes I
> have are not in UTF-8. Adding one would mean a fake buffer that just
> decodes and writes to the text stream. AFAIK there is no guarantee
> that sys.std* objects have buffer
> -Original Message-
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> [email protected]] On Behalf Of Paul Moore
> Sent: Friday, August 12, 2016 9:42 AM
> To: eryk sun
> Cc: python-ideas
> Subject: Re: [Python-ideas] Fix default encodings on Windows
>
> On 12 Augus
On Fri, Aug 12, 2016 at 10:19 AM, Paul Moore wrote:
> > In which case, something IS better than nothing.
>
>
> I'm not arguing that we do nothing. Are you saying we should use
> CP_UTF8 *in preference* to wide character APIs? Or that we should
> implement CP_UTF8 first and then wide chars later?
Hello,
I'm in holiday and I'm writing on a phone, so sorry in advance for the
short answer.
In short: we should drop support for the bytes API. Just use Unicode on all
platforms, especially for filenames.
Sorry but most of these changes look like very bad ideas. Or maybe I
misunderstood somethin
Le 10 août 2016 20:16, "Steve Dower" a écrit :
> So what are your concerns? Suggestions?
Add a new option specific to Windows to switch to UTF-8 everywhere, use
BOM, whatever you want, *but* don't change the defaults.
IMO mbcs encoding is the least worst encoding for the default.
I have an idea
In short, a PEP is a summary of a long discussion. IMHO a PEP is required
to write down the rationale and lists most important alternative and
explain why the PEP is better.
The hard part is to write a short but "complete" PEP.
I tried to follow this discussion and I still to understand why my
pr
On Fri, Aug 12, 2016 at 4:25 PM, Victor Stinner
wrote:
> I tried to follow this discussion and I still to understand why my
> proposition of "def clamp(min_val, value, max_val): return min(max(min_val,
> value), max_val)" is not good. I expect that a PEP replies to this question
> without to read
On Sat, Aug 13, 2016 at 01:25:58AM +0200, Victor Stinner wrote:
> I tried to follow this discussion and I still to understand why my
> proposition of "def clamp(min_val, value, max_val): return min(max(min_val,
> value), max_val)" is not good. I expect that a PEP replies to this question
> without
On Fri, Aug 12, 2016 at 2:20 PM, Random832 wrote:
> On Wed, Aug 10, 2016, at 14:10, Steve Dower wrote:
>> * force the console encoding to UTF-8 on initialize and revert on
>> finalize
>>
>> So what are your concerns? Suggestions?
>
> As far as I know, the single biggest problem caused by the statu
On 2016-08-13 00:48, David Mertz wrote:
On Fri, Aug 12, 2016 at 4:25 PM, Victor Stinner
mailto:[email protected]>> wrote:
[snip]
Also, what is the calling syntax? Are the arguments strictly positional,
or do they have keywords? What are those default values if the arguments
are not spe
On Sat, Aug 13, 2016 at 1:31 PM, MRAB wrote:
> On 2016-08-13 00:48, David Mertz wrote:
>>
>> On Fri, Aug 12, 2016 at 4:25 PM, Victor Stinner
>> mailto:[email protected]>> wrote:
>>
> [snip]
>>
>>
>> Also, what is the calling syntax? Are the arguments strictly positional,
>> or do they have
20 matches
Mail list logo
