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:victor.stin...@gmail.com>> wrote:
>>
> [snip]
>>
>>
>> Also, what is the calling syntax? Are the arguments strictly positional,
>> or do they have
On 2016-08-13 00:48, David Mertz wrote:
On Fri, Aug 12, 2016 at 4:25 PM, Victor Stinner
mailto:victor.stin...@gmail.com>> 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 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 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 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
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
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
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
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?
> -Original Message-
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> list=sdamon@python.org] 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 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
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 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 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 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 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 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
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 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
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
20 matches
Mail list logo
