Marc-Andre Lemburg added the comment:
I like the idea, but the phrasings "disclosure" and "financial interests" sound
too negative, IMO.
Wouldn't it be better to put the emphasis on a) core devs who do this in their
free time, b) core devs who would be available for h
Marc-Andre Lemburg added the comment:
On 23.09.2015 02:33, Steve Dower wrote:
>
> Done.
Thanks.
> As this is (meant to be) a purely informational/diagnostic module, seems like
> a good idea to fix every version we're supporting in any way.
Yep, that's the intenti
Marc-Andre Lemburg added the comment:
I'm not sure which kind of use for frozen modules you have in mind.
The freeze tool allows you to replace paths in source path prefixes using the
-r option. We use this in eGenix PyRun to set the prefix to "" since at
run-time, the source
Marc-Andre Lemburg added the comment:
Thanks, Nick. The second version looks much better.
A few minor nits, which you may want to address:
* Order in the section should probably be alphabetic rather than
random time based (makes it easier to search for entries once the
list gets longer
Marc-Andre Lemburg added the comment:
The patch looks fine to me, but I still wonder how p - PyBytes_AS_STRING(v) can
be negative when size == 0...
Ah, now I get it: the new size is 0, but the refcount is not 1, since the
nullstring is shared. This causes the exception.
>From _PyBytes_Res
Marc-Andre Lemburg added the comment:
On 01.10.2015 04:35, Martin Panter wrote:
> For the record, because I was curious: Function codecs.escape_encode() is not
> documented, and barely tested. It was used for the documented “string_escape”
> codec in Python 2, but this codec was re
Marc-Andre Lemburg added the comment:
On 30.09.2015 15:11, Serhiy Storchaka wrote:
> May be better to test a condition "size > 0" before calling
> _PyBytes_Resize(), as in many other case where _PyBytes_Resize() is used.
>
> Or accept shared objects in _PyBytes_Resize(
Marc-Andre Lemburg added the comment:
Just to add some more background:
The LE and BE codecs are meant to be used when you already know the endianness
of the platform you are targeting, e.g. in case you work on strings that were
read after the initial BOM, or write to an output string in
Marc-Andre Lemburg added the comment:
I think Jan has a point there. An import should not cause the whole interpreter
to hang.
Wouldn't it be possible to have the getrandom() call be done lazily to avoid
this and only have it block when the RNG from the random is actually being used
Marc-Andre Lemburg added the comment:
On 30.10.2015 14:03, Fredrik Averpil wrote:
> Will this fix be included in python 2.7.11?
Yes. Steve also checked in the patch to Python 2.7.
--
___
Python tracker
<http://bugs.python.org/issu
Marc-Andre Lemburg added the comment:
The release buffer mode bugs were fixed in 1.0.0m and 1.0.1h:
https://openssl.org/news/vulnerabilities.html#y2014
CVE-2014-0198 (OpenSSL advisory) 21st April 2014:
A flaw in the do_ssl3_write function can allow remote attackers to cause a
denial of
Marc-Andre Lemburg added the comment:
On 20.11.2015 12:10, Cory Benfield wrote:
> Yeah, while generally speaking OpenSSL doesn't ship betas, it does provide
> them as tarballs. I have a beta of 1.0.2 floating around somewhere on my
> machine that I was using for ALPN testing bac
Marc-Andre Lemburg added the comment:
On 24.11.2015 02:30, Steven D'Aprano wrote:
>
> Steven D'Aprano added the comment:
>
> On Mon, Nov 23, 2015 at 09:48:46PM +, STINNER Victor wrote:
>
>> * the string has a cached UTF-8 byte string (ex: int(s) was called
Marc-Andre Lemburg added the comment:
I wouldn't say this is a feature request.
What the code wanted to check is "if this is an iterable of two strings,
convert these to a locale string". I have no idea why the doc string uses
"iterable". IMO, a tuple of two strings
Marc-Andre Lemburg added the comment:
On 27.11.2015 23:11, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I don't see the benefit of supporting Unicode strings for setlocale()
> arguments: locale name are always encodable to ASCII, so loc.decode(
Marc-Andre Lemburg added the comment:
On 27.11.2015 23:50, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> BTW: Why did you use (_str, _unicode) instead of basestring ?
>
> Serhiy usually insists that technically, it's possible to compile Python 2.7
Marc-Andre Lemburg added the comment:
On 28.11.2015 00:00, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Marc-Andre Lemburg added the comment:
>> Hmm, but basestring is always defined, even when Python is compiled
>> without Unicode support (...)
>
Marc-Andre Lemburg added the comment:
On 02.12.2015 20:16, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> If the StreamWriter/Reader cannot pickle the underlying stream (which is
>> probably always the case), why should the object itself be picklea
Marc-Andre Lemburg added the comment:
On 02.12.2015 21:29, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
>> I think all we need to do is add a .__reduce__()
>> method to StreamWriter and StreamReader, which then
>> raises a PickleError.
>
>
Marc-Andre Lemburg added the comment:
I see three options:
1. remove the French entry from the dict
2. enhance the test to accept multiple valid values
3. replace the French entry with a different locale that doesn't change the
mapping
Marc-Andre Lemburg added the comment:
> This deprecation and eventual removal, will result in a pypi module created
> with such functionality anyway, that everyone will try to pull in or
> falling that copying in.
That's the plan, right.
The stdlib is not the right place f
Marc-Andre Lemburg added the comment:
Same here. Thanks Martin.
--
___
Python tracker
<http://bugs.python.org/issue25809>
___
___
Python-bugs-list mailin
Marc-Andre Lemburg added the comment:
On 18.12.2015 20:25, R. David Murray wrote:
> I wonder if we originally only had UnicodeError and it got split later but
> these codecs were never updated. The codecs date back to the start of
> unicode support in python2, I think.
UnicodeDecode
Marc-Andre Lemburg added the comment:
Regardless of the cert having expired, I think SSL tests either should use the
main python.org site, e.g. https://www.python.org/ or the domain we
specifically have for stdlib tests: http://pythontest.net/.
Benjamin: If you need a cert for pythontest.net
Marc-Andre Lemburg added the comment:
Please fold these cases into one:
if (strcmp(buf, "utf-8") == 0 ||
strncmp(buf, "utf-8-", 6) == 0)
return "utf-8";
else if (strcmp(buf, "utf8") == 0 ||
strncmp(buf, "utf8-&quo
Marc-Andre Lemburg added the comment:
On 26.12.2015 22:46, STINNER Victor wrote:
>
> In Python, there are multiple implementations of the utf-8 codec with many
> shortcuts. I'm not surprised to see bugs depending on the exact syntax of
> the utf-8 codec name. Maybe we need t
Marc-Andre Lemburg added the comment:
On 27.12.2015 02:05, Serhiy Storchaka wrote:
>
>> I wonder why this does not trigger the exception.
>
> Because in case of utf-8 and iso-8859-1 decoding and encoding steps are
> omitted.
>
> In general case the input is decoded fro
Marc-Andre Lemburg added the comment:
On 04.01.2016 08:43, Martin Panter wrote:
>
> In the meantime, this patch changes the tests to use the new DST root
> certificate. This seems to be the minimum to make the tests pass again, but
> someone else should probably review it because
Marc-Andre Lemburg added the comment:
I think we can close this issue as "won't fix".
It's a bug, but one which is present in a lot of other systems as well, so we'd
potentially make it impossible to write GB2312 data which is supposed to be
read back by these other
Marc-Andre Lemburg added the comment:
Thanks, Ma Lin.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Marc-Andre Lemburg added the comment:
So the use case is that you want to explicitly prevent the file system from
being used for imports ?
You might want to look at how eGenix PyRun works, since this does embed the
Python stdlib into the executable (including the encodings package). While it
Marc-Andre Lemburg added the comment:
Thanks, Brett. I'm too busy with other things at the moment.
--
assignee: -> brett.cannon
___
Python tracker
<http://bugs.python.org
Marc-Andre Lemburg added the comment:
While it's theoretically possible, there's a reason why we haven't done this in
the past: we don't want to keep the possibly large original object alive when
using a slice.
For buffer interface types, you can already use memoryview to
Marc-Andre Lemburg added the comment:
The patch looks good. I only have one question:
Why are you removing this part ? ...
@@ -1684,13 +1688,8 @@
try:
ret = func(*args)
except ssl.SSLError as e:
-# Note that we get a spurious -1
Marc-Andre Lemburg added the comment:
On 15.01.2016 10:05, Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> ... and the way I read it, the NR licence applies specifically to their code,
> not to the basic numerical ideas set out in the text (which is all we'
Marc-Andre Lemburg added the comment:
On 20.01.2016 09:37, Antoine Pitrou wrote:
> Let me add that downstream distributors already customize compilation options
> (Ubuntu's Python is compiled with both PGO and LTO enabled, AFAIR), so this
> change may only really affect the tiny
Marc-Andre Lemburg added the comment:
On 20.01.2016 11:38, Antoine Pitrou wrote:
>> If not, then the patch would also effect the not-so-tiny fraction
>> of Python users on Windows ;-)
>
> I don't see how enabling LTO for gcc and clang could ever affect our Windows
> u
Marc-Andre Lemburg added the comment:
On 04.02.2016 07:02, Yury Selivanov wrote:
> Attaching a second version of the patch. (BTW, Serhiy, I tried your idea of
> using a switch statement to optimize branches
> (https://github.com/1st1/cpython/blob/fastint2/Python/ceval.c#L53
Marc-Andre Lemburg added the comment:
On 04.02.2016 09:01, STINNER Victor wrote:
>
> "In a numerics heavy application it's like that all fast paths will trigger
> somewhere, but those will likely be better off using numpy or numba. For a
> text heavy application such as
Marc-Andre Lemburg added the comment:
Serhiy: Removing the shortcut would slow down the tokenizer a lot since UTF-8
encoded source code is the norm, not the exception.
The "problem" here is that the tokenizer trusts the source code in being in the
correct encoding when you use one o
Marc-Andre Lemburg added the comment:
Does Python 2.7.10 build fine ? If so, then perhaps xlc doesn't
like the computed gotos in ceval.c.
You could try compiling with:
./configure ... --without-computed-gotos ...
to check.
--
nosy: +le
Marc-Andre Lemburg added the comment:
True. At the time the code was written, this was not an issue :-)
Is the libc version information documented somewhere ? If so, we could probably
add a better parser for it.
--
___
Python tracker
<h
Marc-Andre Lemburg added the comment:
Adding other Python versions as well, since this is a bug.
--
versions: +Python 2.7, Python 3.4, Python 3.6
___
Python tracker
<http://bugs.python.org/issue26
Marc-Andre Lemburg added the comment:
The idea is to have similar functionality implemented as a PyPI
package, which can be updated more often than the stdlib.
Unlike Windows and Mac OS X, the approach to finding out
the distribution version is changing too often on Linux (w/r to how
Python
Marc-Andre Lemburg added the comment:
On 13.04.2016 21:50, Stefan Krah wrote:
>
> LTO is not stable on all platforms (according to doko), and people don't
> want to wait for PGO to build when they just run ./configure && make.
>
> --with-pgo and --with-lto is f
Marc-Andre Lemburg added the comment:
On 14.04.2016 10:39, Alecsandru Patrascu wrote:
>
> @Stefan and @Marc, you say that people don't want to wait for PGO to build
> when running ./configure && make, but why? Even though many developers use
> it, this mode is not int
Marc-Andre Lemburg added the comment:
On 19.04.2016 12:52, STINNER Victor wrote:
>
> As usual, I'm very skeptical on the pybench results which almost look like
> noise. I don't understand how my change can make any operation *faster*,
> whereas some benchmarks are
Marc-Andre Lemburg added the comment:
On 19.04.2016 13:11, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> Could you perhaps check what's causing these slowdowns ?
>
> It's obvious, no? My patch causes the slowdown.
Well, yes, of course :-) I
Marc-Andre Lemburg added the comment:
I still believe the underlying system API use should be fixed rather than all
the different instances where it gets used.
getrandom() should not block. If it does on a platform, that's a bug on that
platform and Python should revert to the alternati
Marc-Andre Lemburg added the comment:
As mentioned on the other issue #25420, this is a regression and a change in
documented behavior of os.urandom(), which is expected to be non-blocking,
regardless of whether entropy is available or not.
The fix should be easy (from reading the man page
Marc-Andre Lemburg added the comment:
If the file is guaranteed to exist on most modern Android platforms, this
sounds like a good approach.
Perhaps you could add support to fallback to running getprop instead, if the
file doesn't exist or cannot be parsed ?!
--
nosy: +le
Marc-Andre Lemburg added the comment:
Some screenshots showing different file contents:
*
http://www1-lw.xda-cdn.com/files/2013/12/tweak-your-samsung-galaxy-s3s-performance-with-these-build-prop-android-hacks.w654.jpg
*
http://media.apcmag.com/wp-content/uploads/sites/20/2014/04/buildprop
Marc-Andre Lemburg added the comment:
On 04.05.2016 21:47, Chi Hsuan Yen wrote:
> 1. Should Android 4.1 supported? If not pass_fds and logics for deriving it
> can be removed.
According to http://www.droid-life.com/tag/distribution/ the Jelly
Bean versions (4.1, 4.2 and 4.3) still
Marc-Andre Lemburg added the comment:
We're not supporting Python 3.3 with PyRun, but I can confirm that it works
fine in Python 3.4 and 3.5.
In Python 2.7, it's still broken, as you can test with
pyrun2.7 -m wsgiref.simple_server
--
versions: +Python 2.7 -
Marc-Andre Lemburg added the comment:
Side note, as already indicated by Nick: pkgutil may well still not support
frozen modules in Python 3.4 and 3.5, since runpy, which pyrun uses, does not
rely on pkgutil in Python 3.4 and 3.5.
--
___
Python
Marc-Andre Lemburg added the comment:
Ben, the methods on stings and Unicode objects in Python 2.x are direct
interfaces to the underlying codecs. The codecs can handle any number of input
and output types, so there are some which only work on 8-bit strings (bytes)
and others which take
Marc-Andre Lemburg added the comment:
Can you provide a patch for this ?
--
___
Python tracker
<http://bugs.python.org/issue23550>
___
___
Python-bugs-list mailin
Marc-Andre Lemburg added the comment:
There seem to be quite a few other places where this simple optimization could
make sense as well, perhaps even going as far
as converting all uses of PyMem_MALLOC to PyObject_MALLOC.
There was a time when the small memory allocator did not return
free
Marc-Andre Lemburg added the comment:
On 08.03.2015 20:57, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> Well, that's not useful in a generated file.
>
> Well, here's a case where it's useful... Asking me to change tools is quite
>
Marc-Andre Lemburg added the comment:
This is likely also related to issue23042.
The precompiler #ifdefs were mixed up, causing Win32 code to be compiled in on
other platforms as well.
--
nosy: +lemburg
___
Python tracker
<http://bugs.python.
Marc-Andre Lemburg added the comment:
I would prefer to have someone with good libffi knowledge to chime in here.
It's easy to just revert the patch, but it may be even better to upgrade the
included libffi lib.
But probably not to 3.2.1, since this still has the same bug it seems:
Marc-Andre Lemburg added the comment:
@koobs: I was just looking at the 3.2.1 code where it still looks like
ffi_call_win32() gets called even on non-Win32 platforms.
That said, it's possible that ffi_call_win32() is indeed defined on other
platforms than Win32 as well in 3.2.1 - afte
Marc-Andre Lemburg added the comment:
I wouldn't make this the default, since the probability is small, but not zero.
However, it may be worth exploring this as dict sub-type for applications to
use which could benefit from it.
For internal strings, we already use interning, so no win
Marc-Andre Lemburg added the comment:
On 05.04.2015 18:28, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
>> Now, I knew how to fix this, but the solution was not
>> an obvious one. I had to use truss to figure out where OpenSSL
>> was looking for cer
Marc-Andre Lemburg added the comment:
On 05.04.2015 21:36, Antoine Pitrou wrote:
>
> And you want the python-dev community to care for that broken
> situation by bearing the cost of additional maintenance and security
> risk in implementing the new configuration options?
No, I wan
Marc-Andre Lemburg added the comment:
On 05.04.2015 21:48, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
>> No, I want to be able to easily disable the newly added
>> checks in 2.7.9+ to get systems such as these behave the
>> same as with 2.7.8, since
Marc-Andre Lemburg added the comment:
On 05.04.2015 23:25, R. David Murray wrote:
>
> MAL: then what you are arguing for is that the SSL changes in 2.7.9 should
> not have happened. Which is an argument that Antoine and I at least are
> sympathetic to :)
I think those
Marc-Andre Lemburg added the comment:
Are you sure you want to go with OpenSSL 1.0.2a ? It typically takes a few
patch level releases for them to clear out all the major bugs (including
security relevant ones).
For egenix-pyopenssl, we've chose to stay with 1.0.1 for the time being until
Marc-Andre Lemburg added the comment:
On 14.04.2015 00:29, Ned Deily wrote:
>
> For what it's worth, the resolution of Issue23476 uses an API that was added
> in OpenSSL 1.0.2.
Hmm, I don't think that's a good move at this time.
Most Linux users won't benefit
Marc-Andre Lemburg added the comment:
On 14.04.2015 01:41, Donald Stufft wrote:
>
> I'm pretty massively +1 in Python shipping 1.0.2 (or really, whatever the
> latest OpenSSL is) wherever it can, including the OSX installers even on
> systems where Apple ships it&
Marc-Andre Lemburg added the comment:
On 14.04.2015 01:36, Ned Deily wrote:
>
>> https://github.com/openssl/openssl/pull/218
>> (certificate expiry checks not working)
>
> That issue appears to have been fixed in 1.0.2a, no?
Yes, but it shows the kind of errors to expec
Marc-Andre Lemburg added the comment:
I'm not sure I like the way the simple idea Antoine has now resulted in a
complete mess across platforms.
None of this is documented anywhere except on this ticket.
Since the change is a major one for anyone creating installers, packagers or
othe
Marc-Andre Lemburg added the comment:
We do some monkey-patching on MSVCCompiler as well, but mostly because
distutils doesn't define a good way to subclass or configure a compiler class.
IMO, monkey patching is a really bad idea. distutils should be evolved to
provide more proper exte
Marc-Andre Lemburg added the comment:
On 16.04.2015 15:18, Steve Dower wrote:
>
> Is there a way for those users to specify the version that they want?
Indirectly, yes. There's the build_ext --compiler argument which then
interfaces to ccompiler.new_compiler. In essence, you can
Marc-Andre Lemburg added the comment:
On 16.04.2015 17:30, Matthias Klose wrote:
>
> Matthias Klose added the comment:
>
> Nick filed issue #23966 to document these changes. Yes, these tags should be
> documented, so that installers don't have to guess (currently they ar
Marc-Andre Lemburg added the comment:
On 16.04.2015 18:12, Nick Coghlan wrote:
>
> I can tell you exactly where these files need to live side by side: index
> servers. We currently paper over it on PyPI for Windows and Mac OS X by
> leveraging the implicitly defined ABI compatib
Marc-Andre Lemburg added the comment:
On 16.04.2015 18:53, Matthias Klose wrote:
> I'm disappointed that you discredit any other use case besides what you think
> as
> the typical use case as not real life use case. Maybe you are focused on x86
> only, but if you've b
Marc-Andre Lemburg added the comment:
On 16.04.2015 19:14, Marc-Andre Lemburg wrote:
> However, for plain .so files that you have on your system (which will
> mostly like not support more than 2-4 different architecture configurations
> running at the same time), I don't currently
Marc-Andre Lemburg added the comment:
On 16.04.2015 19:47, Ned Deily wrote:
>
> Ned Deily added the comment:
>
>> Antoine's ticket is the first in two decades to request being
>> able to install .so extension files side-by-side, so even if
>> times and platfo
Marc-Andre Lemburg added the comment:
On 16.04.2015 19:44, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
>> Perhaps you can point me to some use cases where the triple
>> platform tag is really useful.
>
> If I understand correctly (and ABI isn'
Marc-Andre Lemburg added the comment:
On 16.04.2015 20:17, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
>> Well, it's even more wasteful if you have to download 100MB wheels
>> with all the different platforms when the dedicated wheel would just
>&g
Marc-Andre Lemburg added the comment:
On 16.04.2015 20:21, Ned Deily wrote:
>
> Ned Deily added the comment:
>
>> No, PEP 3149 is about the Python ABI, following PEP 3147,
>> which implements this for PYC files.
>
>> The intent is to be able to have mutl
Marc-Andre Lemburg added the comment:
On 17.04.2015 00:51, Donald Stufft wrote:
>
>> Since you need special support for such ZIP files (either using dlopen
>> hacks or temporarily extracting them), you might as well deal with
>> the platform dependencies in that handler.
Marc-Andre Lemburg added the comment:
On 17.04.2015 01:38, Larry Hastings wrote:
>
> Documentation is here:
>
> https://docs.python.org/3/c-api/arg.html#arg-parsing
>
>
> The first line of documentation for each format unit follows this convention:
>
Marc-Andre Lemburg added the comment:
On 17.04.2015 06:42, Larry Hastings wrote:
>
> Larry Hastings added the comment:
>
> One more idea. We annotate with an & when you pass in a pointer to a
> variable. So format unit 'i' would get [& int], 's' w
Marc-Andre Lemburg added the comment:
On 17.04.2015 05:50, Larry Hastings wrote:
>
> Larry Hastings added the comment:
>
>> The "e" variants (typically) allocate a buffer for you, since it's pretty
>> much unknown how long the encoded data will be.
>
Marc-Andre Lemburg added the comment:
On 17.04.2015 00:06, Steve Dower wrote:
>
> So it looks like what I should do is use the include_dirs and library_dirs
> members from CCompiler so they can be set through other properties.
I see that you're basically reading the include and
Marc-Andre Lemburg added the comment:
On 17.04.2015 16:04, Steve Dower wrote:
>
> Yeah, the basic functionality is no different, since there isn't really a
> better way to handle future versions of VS automatically. I'd rather not
> officially expose this stuff though
Marc-Andre Lemburg added the comment:
I agree with closing this as "won't fix".
It is true that the encoding keyword argument is only useful when passing in
byte strings or (and that's also where it originated in Python 2: the default
string type is a byte string), but ev
New submission from Marc-Andre Lemburg:
In Python 3.4.3, the doc string of the str() builtin still reads:
"str(object='') -> str\nstr(bytes_or_buffer[, encoding[, errors]]) ->
str\n\nCreate a new string object from the given object. If encoding or\nerrors
is specified,
New submission from Marc-Andre Lemburg:
In Python 2, the unicode() constructor does not accept bytes arguments, unless
an encoding argument is given:
>>> unicode(u'abcäöü'.encode('utf-8'))
Traceback (most recent call last):
File "", line 1, in
Unicode
Marc-Andre Lemburg added the comment:
On 22.04.2015 15:52, R. David Murray wrote:
> str accepting bytes and returning the repr was a conscious design choice, as
> evidenced by the -bb option, and I'm sure there is code that is both
> unintentionally and *intentionally* using thi
Marc-Andre Lemburg added the comment:
Hi Ma Lin,
thank you for your investigation. In order to fix these tables, we'd need an
official reference which shows that there is in fact an error. If most
programming languages you have tested use the "wrong" version, then maybe it
Marc-Andre Lemburg added the comment:
On 24.04.2015 04:54, aixtools wrote:
> Rather than wait for that to happen I decided to experiment with LibreSSL. If
> you are not familiar with LibreSSL - I shall be quick - openbsd (who also
> maintains openssh) has been cutting out insecu
Marc-Andre Lemburg added the comment:
The "x_" prefix was added as reminder and way to document the desire to look
into this at some point:
https://github.com/python/cpython/commit/c696b47b10db1fa22b77ecfe1af392b3d62aab61
Before adding more codecs, we always ask whether these are
Marc-Andre Lemburg added the comment:
On 24.04.2015 10:34, Behdad Esfahbod wrote:
>
> Thanks Marc-Andre. If the x_ was indeed added for that reason, it's quite a
> coincidence, because the MIME name of these encodings also starts with
> x-mac-..., so I assumed that's w
Marc-Andre Lemburg added the comment:
On 23.04.2015 21:02, Behdad Esfahbod wrote:
>
> They are used in OpenType fonts, but not implemented by Python at this time.
> Here's are the Unicode mappings for them:
>
> http://unicode.org/Public/MAPPINGS/VENDORS/APPLE
Marc-Andre Lemburg added the comment:
On 24.04.2015 20:34, Behdad Esfahbod wrote:
>
> They are a rather minor change on top of the existing Asian encodings. So
> implementing them in Python might be easier. I have a half-done version of
> those. I can try finishing and post
Marc-Andre Lemburg added the comment:
On 24.04.2015 21:25, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> Guido's time machine strikes back.
>
>>>> 'π–∆'.encode('mac_romanian')
> b'\xb9\xd0\xc6'
>>>
Marc-Andre Lemburg added the comment:
I think this discussion is moving in the wrong direction or least one which
won't help people not using some Linux distribution.
The use case here is very similar to the hash seed randomization which was also
successfully handled using an enviro
1801 - 1900 of 1946 matches
Mail list logo
