On Wed, Jan 10, 2018, at 14:44, Steve Barnes wrote:
> I am somewhat confused because according to
> https://encoding.spec.whatwg.org/index-windows-1252.txt 0x90 (one of the
> original examples) is undefined as the table only runs to 127 i.e. 0x7F.
The spec referenced in the comments says "Let co
On Thu, Jan 11, 2018 at 6:44 AM, Steve Barnes wrote:
>
> I am somewhat confused because according to
> https://encoding.spec.whatwg.org/index-windows-1252.txt 0x90 (one of the
> original examples) is undefined as the table only runs to 127 i.e. 0x7F.
AIUI the table in that file assumes that the f
On 10/01/2018 19:13, Rob Speer wrote:
> I was originally proposing these encodings under different names, and
> that's what I think they should have. Indeed, that helps because a pip
> installable library can backport the new encodings to previous versions
> of Python.
>
> Having a pip instal
On Wed, Jan 10, 2018 at 11:04 AM, M.-A. Lemburg wrote:
> I don't believe it's a good strategy to create the confusion that
> WHATWG is introducing by using the same names for non-standard
> encodings.
>
agreed.
> Python uses the Unicode Consortium standard encodings or
> otherwise internationa
On 11 January 2018 at 05:04, M.-A. Lemburg wrote:
> For the stdlib, I think we should stick to standards and
> not go for spreading non-standard ones.
>
> So -1 on adding WHATWG encodings to the stdlib.
We already support HTML5 in the standard library, and saying "We'll
accept WHATWG's definition
On 10 January 2018 at 18:30, Paul Moore wrote:
> On 10 January 2018 at 02:39, Nick Coghlan wrote:
>> For the coverage.py use case, an environment-based solution is also
>> genuinely helpful, since you typically can't modify subprocess
>> invocations just because the software is being tested. At t
> Well, one of your main arguments was that the Windows API follows these
best fit encodings.
No, that wasn't me, that was Ivan. My argument has been based on
compatibility with Web technologies; I wanted these encodings before I knew
what Windows did (and now what Windows does kind of horrifies m
On 10.01.2018 20:13, Rob Speer wrote:
> I was originally proposing these encodings under different names, and
> that's what I think they should have. Indeed, that helps because a pip
> installable library can backport the new encodings to previous versions of
> Python.
>
> Having a pip installable
I was originally proposing these encodings under different names, and
that's what I think they should have. Indeed, that helps because a pip
installable library can backport the new encodings to previous versions of
Python.
Having a pip installable library as the _only_ way to use these encodings
On 10.01.2018 19:36, Rob Speer wrote:
> I'm looking at the documentation of "best fit" mappings, and that seems to
> be a different matter. It appears that best-fit mappings are designed to be
> many-to-one mappings used only for encoding.
"Best fit" is what the Windows API is implementing.
I don
I'm looking at the documentation of "best fit" mappings, and that seems to
be a different matter. It appears that best-fit mappings are designed to be
many-to-one mappings used only for encoding.
"Examples of best fit are converting fullwidth letters to their
counterparts when converting to single
You don’t have to use distutils to build your extension, and if you want
anything more complex than a release build you probably should build it
yourself.
All you need is the right include and lib directories when compiling/linking,
set the output extension to pyd instead of dll, and use /MD wh
On 10.01.2018 00:56, Rob Speer wrote:
> Oh that's interesting. So it seems to be Python that's the exception here.
>
> Would we really be able to add entries to character mappings that haven't
> changed since Python 2.0?
The Windows mappings in Python come directly from the Unicode
Consortium map
On 10 January 2018 at 04:16, Nick Coghlan wrote:
> On 10 January 2018 at 13:56, Rob Speer wrote:
>> One other thing I've noticed that's related to the WHATWG encoding list: in
>> Python, the encoding name "windows-874" seems to be missing. The _encoding_
>> is there, as "cp874", but "windows-874"
On 10 January 2018 at 02:39, Nick Coghlan wrote:
> For the coverage.py use case, an environment-based solution is also
> genuinely helpful, since you typically can't modify subprocess
> invocations just because the software is being tested. At the moment,
> there are approaches that rely on using
15 matches
Mail list logo
