Stefan Krah <ste...@bytereef.org> added the comment:
On Tue, Nov 14, 2017 at 01:31:52PM +, Nick Coghlan wrote:
> If limited to the original scope, this isn't a new special case, it's fixing
> a bug in the implementation of the existing special case (where it's ignoring
> the
Stefan Krah <ste...@bytereef.org> added the comment:
I would prefer to do nothing about the subject of this issue. I still
don't see any ambiguity, except in a very broad colloquial sense.
Why introduce another special case?
--
___
Python t
Stefan Krah <ste...@bytereef.org> added the comment:
I think "ambiguous" is not the right word. If a single argument
can be a non-parenthesized generator and all arguments can be
followed by a trailing comma, it's clear.
The language spec is often behind in my experience.
Stefan Krah <ste...@bytereef.org> added the comment:
Okay, it is probably this:
https://bugs.kde.org/show_bug.cgi?id=331311
The question is whether we should add a suppression or a perhaps
a comment in _posixsubprocess.c
--
nosy: +gregory.p
Stefan Krah <ste...@bytereef.org> added the comment:
More info:
==22845== Warning: invalid file descriptor 1024 in syscall close()
==22845==at 0x4E493F0: __close_nocancel (syscall-template.S:81)
==22845==by 0xF0BAA74: _close_open_fds_safe (_posixsubprocess.c:297)
=
Change by Stefan Krah <ste...@bytereef.org>:
--
nosy: +skrah
stage: -> needs patch
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
Stefan Krah <ste...@bytereef.org> added the comment:
On Wed, Nov 08, 2017 at 08:28:10PM +, Serhiy Storchaka wrote:
> Does this check work? I tried similar checks with other functions and they
> were falsely passed because calling an undeclared function is not an error in
&g
Stefan Krah <ste...@bytereef.org> added the comment:
Just adding +1.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Stefan Krah <ste...@bytereef.org> added the comment:
It looks like guaranteed ordered literals are going to happen (yay!):
https://mail.python.org/pipermail/python-dev/2017-November/150144.html
--
nosy: +skrah
resolution: later -> out of date
stage: -> resolved
Stefan Krah <ste...@bytereef.org> added the comment:
Berker's latest patch looks good to me.
Unrelated to the patch (same before and after), this looks odd to me:
>>> import uuid
>>> uuid._has_uuid_generate_time_safe is None
True
>>>
>>> import _uu
Change by Stefan Krah <ste...@bytereef.org>:
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> setup.py cannot find vcversall.bat on MSWin 8.1 if installed in
user AppData
___
P
Change by Stefan Krah <ste...@bytereef.org>:
--
nosy: +jyrkih
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31932>
___
__
Stefan Krah <ste...@bytereef.org> added the comment:
> I'm not sure that the cost of the memory allocator itself defeats the gain of
> aligned memory on algorithms. I expect data processing to be much more
> expensive than the memory allocation, no?
I guess this issue isn't ea
Stefan Krah <ste...@bytereef.org> added the comment:
Yes, it may be better not to add it.
To summarize the problems again:
- C11 aligned_alloc() / free() would be more comfortable but isn't
available on MSVC.
- posix_memalign() performance
Stefan Krah <ste...@bytereef.org> added the comment:
On Wed, Nov 01, 2017 at 06:17:44PM +, Mark Dickinson wrote:
> I'm really reluctant to (even conditionally) skip the test, because it's
> doing exactly what it's designed to do, namely detecting and reporting that
> Python
Stefan Krah <ste...@bytereef.org> added the comment:
> For large allocations, you'll probably be better off implementing your own
> aligned allocator on top of calloc than implementing your own calloc on top
> of an aligned allocator. (It's O(1) overhead versus O(n).) And once
Stefan Krah <ste...@bytereef.org> added the comment:
On Tue, Oct 31, 2017 at 07:32:00PM +, Serhiy Storchaka wrote:
> >>From 4 considered results the tests are failed on gcc 4.2.1, 4.7.2, 4.8.5,
> >>but are passes on gcc 7.2.0. I suppose this is gcc or libc bug fixed
Stefan Krah <ste...@bytereef.org> added the comment:
So the big mystery is still:
https://mail.python.org/pipermail/python-dev/2017-October/149880.html
Could be a Linux router with some alternative libc ...
--
___
Python tracke
Stefan Krah <ste...@bytereef.org> added the comment:
> Do you mean the C++ std::max_align_t? Does C99 have something like that?
>
> The Linux malloc() manual page says:
>
> "The malloc() and calloc() functions return a pointer to the allocated
> memory, which
Change by Stefan Krah <ste...@bytereef.org>:
--
nosy: +haypo
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31912>
___
__
New submission from Stefan Krah <ste...@bytereef.org>:
This is related to #27987 and #20064 and perhaps the pymalloc patch
from #18835.
I think PyMem_Malloc() should guarantee alignof(max_align_t).
It actually did before the "#define PYMEM_FUNCS PYOBJ_FUNCS" optimization,
s
Stefan Krah <ste...@bytereef.org> added the comment:
On Tue, Oct 31, 2017 at 02:55:04PM +, Nathaniel Smith wrote:
> 3) also it's not clear what the best approach will look like, given that we
> care a lot about using calloc when possible, and have reason to prefer using
>
Stefan Krah <ste...@bytereef.org> added the comment:
Same as #7442, I think.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Stefan Krah <ste...@bytereef.org> added the comment:
Also, does this occur in a VM on on the bare metal or both?
What leaves me puzzled is that I cannot reproduce the Linux x86 report
with almost the exact same compiler. But I'm on x64 and us
Stefan Krah <ste...@bytereef.org> added the comment:
Ah sorry, you mean it cannot write the special bytes.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Stefan Krah <ste...@bytereef.org> added the comment:
> realloc() must not touch the original buffer on failure
I don't understand this: If realloc() fails, the original buffer
is perfectly valid.
--
nosy: +skrah
___
Python tra
Stefan Krah <ste...@bytereef.org> added the comment:
> The ways we've discussed using aligned allocation in numpy wouldn't follow
> this requirement without special checking. Which isn't necessarily a big
> deal, and numpy won't necessarily use this API anyway. But I would s
Stefan Krah <ste...@bytereef.org> added the comment:
Should we care about the C11 restriction?
http://en.cppreference.com/w/c/memory/aligned_alloc
"size - number of bytes to allocate. An integral multiple of alignment"
posix_memalign and _aligned_malloc don't care ab
Stefan Krah <ste...@bytereef.org> added the comment:
> In Python 3.7, should we also add the "aligned alloc" requirement?
Linux, BSD, OSX, MSVC should be covered. According to Stackoverflow
MinGW has an internal function.
Android, I don't know. Xavier?
--
Stefan Krah <ste...@bytereef.org> added the comment:
Since we have "#define PYMEM_FUNCS PYOBJ_FUNCS", I think extensions that
use PyMem_Malloc() also won't get the glibc max_align_t alignment.
But guess technically they should.
---
Stefan Krah <ste...@bytereef.org> added the comment:
[me]
> This weakens my use case somewhat [...]
I looked at Victor's patch, and thanks to the alignment <= ALIGNMENT
optimization it seems that always using the aligned_alloc() and
aligned_free() versions for a specific pointer i
Stefan Krah <ste...@bytereef.org> added the comment:
On Mon, Oct 23, 2017 at 09:16:08PM +, Antoine Pitrou wrote:
> > The Arrow memory format for example recommends 64 bit alignment.
>
> I presume you mean 64 bytes?
Yes, I w
Stefan Krah <ste...@bytereef.org> added the comment:
On Mon, Oct 23, 2017 at 05:16:53PM +, STINNER Victor wrote:
> Memory allocated by PyMem_AlignedAlloc() must be freed with
> PyMem_AlignedFree().
>
> We cannot reuse PyMem_Free(). On Windows, PyMem_AlignedAllo
Change by Stefan Krah <ste...@bytereef.org>:
--
nosy: +eric.snow
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31845>
___
__
Stefan Krah <ste...@bytereef.org> added the comment:
Yes, I think it is partly convenience. I want to set ...
ndt_mallocfunc = PyMem_Malloc;
ndt_alignedallocfunc = PyMem_AlignedAlloc;
ndt_callocfunc = PyMem_Calloc;
ndt_reallocfunc = PyMem_Realloc;
ndt_freefunc = PyMe
Stefan Krah <ste...@bytereef.org> added the comment:
I need this too. I would like to set this
https://github.com/plures/ndtypes/commit/c260fdbae707da0dfefef499621a0a9f37a3e509#diff-2402fff6223084b74d97237c0d620b29R50
to something line PyMem_AlignedAlloc(), because the Python all
Stefan Krah <ste...@bytereef.org> added the comment:
I know I closed #20166 myself, but could we revisit this?
I'm now in favor of telling people to fix their modules.
--
nosy: +skrah
status: closed -> open
___
Python tracker <rep...@bug
Stefan Krah <ste...@bytereef.org> added the comment:
I'd push it so we don't have to worry about similar things in the
future. The "warnings.catch_warnings()" thing is also a workaround
for some past numpy release.
--
___
Pyt
Stefan Krah <ste...@bytereef.org> added the comment:
I can't figure out how to make the damn button green on GitHub,
so LGTM. :)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Stefan Krah <ste...@bytereef.org> added the comment:
That's fine.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31792>
___
_
Stefan Krah <ste...@bytereef.org> added the comment:
Thanks. If it only occurs when mixing debug/non-debug I don't think we have to
do anything about it.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Stefan Krah <ste...@bytereef.org> added the comment:
So it is a numpy issue? Which numpy version is it?
--
versions: +Python 3.8 -Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Stefan Krah <ste...@bytereef.org> added the comment:
> I'm also assuming that Decimal(0) sets both base and exponent to 0.
No, 0 is really special in the IBM specification. The magnitude is
kept, the precision is not.
>>> Decimal("0e10") * Decimal("0e20&
Stefan Krah <ste...@bytereef.org> added the comment:
I don't think format() destroys the information:
>>> '{:+.19e}'.format(Decimal("0.0e20"))
'+0.000e+34'
The original magnitude was e+15, after f
Stefan Krah <ste...@bytereef.org> added the comment:
Yes, from the point of view of decimal it's the right thing:
>>> x = Decimal("1e25").quantize(Decimal("1e30"))
>>> x
Decimal('0E+30')
>>> '{:+.19e}'.format(x)
'+0.000e
Stefan Krah <ste...@bytereef.org> added the comment:
I think the configure check should be this (sets HAVE_LIBUUID in pyconfig.h):
diff --git a/configure.ac b/configure.ac
index 41bd9effbf..90d53c1b7d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2657,6 +2657,7 @@ AC_MSG_RESULT($
Stefan Krah <ste...@bytereef.org> added the comment:
OpenBSD reduces to the range [-pi/4,pi/4]:
https://github.com/openbsd/src/blob/master/lib/libm/src/s_tan.c
According to the man page on i386:
http://man.openbsd.org/FreeBSD-11.0/math.3
"Argument reduction is not performed
Stefan Krah <ste...@bytereef.org> added the comment:
Does the difference stay at 10-15% if you run it 5 times or is it
a one time cost of around 100 ms?
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<https://
Stefan Krah <ste...@bytereef.org> added the comment:
> We see if digits * bits_per_char + PyLong_SHIFT -1 overflows an int?
Yes, but the check is too late: UB can already occur in this calculation
and then all bets are off.
It looks like 'n' was Py_ssize_t in 2.7. :)
--
nos
Stefan Krah added the comment:
Also, I don't think --with-pydebug works well with valgrind.
It's either:
1) --with-pydebug
2) CFLAGS="-O0 -g" --with-valgrind
3) CFLAGS="-O0 -g" --without-pymalloc
Combining 2) and 3) probably does not hurt, but is not necessary.
-
Stefan Krah added the comment:
The suppressions are mainly for "invalid access" due to a gc trick.
The primary goal is to be definitely-lost-clean.
I would say it works as expected.
--
nosy: +skrah
___
Python tracker <rep...@bu
Changes by Stefan Krah <ste...@bytereef.org>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bu
Stefan Krah added the comment:
New changeset b1558a0368949714f5765702a8d83a2d163eaacf by Stefan Krah in branch
'master':
bpo-31443: Update included code. (#3697)
https://github.com/python/cpython/commit/b1558a0368949714f5765702a8d83a2d163eaacf
Changes by Stefan Krah <ste...@bytereef.org>:
--
pull_requests: +3681
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31443>
___
_
Stefan Krah added the comment:
New changeset ca72589bfabe2fd0e12eebfeb770b6c7a499b3e6 by Stefan Krah in branch
'master':
bpo-31443: Formulate the type slot initialization rules in terms of C99. (#3688)
https://github.com/python/cpython/commit/ca72589bfabe2fd0e12eebfeb770b6c7a499b3e6
Stefan Krah added the comment:
Okay, thanks.
I found that bz2module.c has also used direct initialization for ages.
I'm going to commit the change.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Stefan Krah added the comment:
In fact, building _decimal should also fail on Cygwin if this
were still an issue.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Stefan Krah added the comment:
Erik, if you are interested in Cygwin, could you please check that xxmodule.c
builds on Cygwin with the patch? You need to uncomment
a couple of lines in setup.py to build 'xx'.
--
___
Python tracker <
Changes by Stefan Krah <ste...@bytereef.org>:
--
keywords: +patch
pull_requests: +3678
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Stefan Krah added the comment:
I've just asked on python-dev if Cygwin is still broken. Not sure
if we support it.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Stefan Krah added the comment:
Thanks, Christian. -- I found that in the docs the culprit is Cygwin:
db6a569de7ae595ada53b618fce6bbbd1c98d350
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Stefan Krah added the comment:
Christian, do you remember which compiler was the reason for the commit
cbf3b5cb76906fba15dbf59a1e83c540a447b907 ?
+ /* Due to cross platform compiler issues the slots must be filled
+* here. It's required for portability to Windows without
Stefan Krah added the comment:
FWIW, I've been using
https://github.com/python/cpython/blob/master/Modules/_decimal/_decimal.c#L689
the static initialization on problematic platforms like Windows and
AIX for years, without any problems.
I'm sure this is valid C, and people here agree
Stefan Krah added the comment:
PyType_GenericNew() should be in libpython, so indeed the example in the docs
seems a bit odd to me.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Stefan Krah added the comment:
Pythons has binary floating point, which does not give the same
results as a pocket calculator.
You can see the differences by using the decimal module:
# These are the binary floats in exact decimal representation.
>>> Decimal(7.95
Stefan Krah added the comment:
It's fixed, thanks!
--
resolution: -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder: -> Reference leaks introduced by bpo-30860
___
Python tracker <rep...@bugs.pyt
Stefan Krah added the comment:
Could be the same as #31408.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Changes by Stefan Krah <ste...@bytereef.org>:
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
Stefan Krah added the comment:
Thanks for the report and the patch!
--
resolution: -> fixed
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.or
Stefan Krah added the comment:
New changeset f8909d0e4b652256e4da153fa6be664490f60a07 by Stefan Krah (Miss
Islington (bot)) in branch '3.6':
[3.6] bpo-31406: Fix crash due to lack of type checking in subclassing.
(GH-3477) (#3479)
https://github.com/python/cpython/commit
Stefan Krah added the comment:
New changeset 3cedf46cdbeefc019f4a672c1104f3d5e94712bd by Stefan Krah in branch
'master':
bpo-31406: Fix crash due to lack of type checking in subclassing. (#3477)
https://github.com/python/cpython/commit/3cedf46cdbeefc019f4a672c1104f3d5e94712bd
New submission from Stefan Krah:
I traced this valgrind result down to
2ebc5ce42a8a9e047e790aefbf9a94811569b2b6 :
==23495== 240 (72 direct, 168 indirect) bytes in 1 blocks are definitely lost
in loss record 2,255 of 2,922
==23495==at 0x4C2A9A1: malloc (vg_replace_malloc.c:299)
==23495
New submission from Stefan Krah:
./configure --without-pymalloc produces:
Objects/obmalloc.c: In function ‘bumpserialno’:
Objects/obmalloc.c:1326:21: error: ‘struct _pymem_runtime_state’ has no member
named ‘serialno’
++_PyRuntime.mem.serialno;
^
Objects/obmalloc.c
Changes by Stefan Krah <ste...@bytereef.org>:
--
pull_requests: +3468
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31406>
___
_
Changes by Stefan Krah <ste...@bytereef.org>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
New submission from Stefan Krah:
New changeset c0c29dff7940b7e7ecc1dd051080c5d5f9e42ba8 by Stefan Krah in branch
'master':
bpo-31403: Remove WITHOUT_THREADS from _decimal. (#3474)
https://github.com/python/cpython/commit/c0c29dff7940b7e7ecc1dd051080c5d5f9e42ba8
Changes by Stefan Krah <ste...@bytereef.org>:
--
keywords: +patch
pull_requests: +3466
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Changes by Stefan Krah <ste...@bytereef.org>:
--
assignee: skrah
components: Extension Modules
nosy: skrah
priority: normal
severity: normal
status: open
title: Remove WITHOUT_THREADS from _decimal
type: behavior
versions: Python 3.7
___
Stefan Krah added the comment:
On Tue, Sep 05, 2017 at 05:10:24PM +, STINNER Victor wrote:
> That's a good example of better implementation for Py_UNREACHABLE().
>
> The tricky part is to make compiler warnings quiet. For example, you cannot
> replace "abort(); return N
Stefan Krah added the comment:
And Solaris lint recognizes it:
https://docs.oracle.com/cd/E60778_01/pdf/E60745.pdf
Actually it could be that the convention comes right from K, but I
can't find my copy right now.
--
___
Python tracker <
Stefan Krah added the comment:
> Is /* NOT REACHED */ a common convention?
I think it's often used in BSD, I first saw it in OpenBSD.
A macro is fine of course.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Stefan Krah added the comment:
Regarding lint warnings, I may have confused abort() with exit().
Lintian has the shlib-calls-exit tag, somehow I thought there was
a similar one for abort(), but I can't find it now.
--
___
Python tracker <
Stefan Krah added the comment:
I'm very much in favor of using abort() /* NOT REACHED */ in such cases.
The only drawback is that in the case of libraries, sometimes
distribution package lint tools complain.
--
nosy: +skrah
___
Python tracker <
Changes by Stefan Krah <ste...@bytereef.org>:
--
components: +Build
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> compile error
versions: +Python 3.7
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
New changeset dce6502059f46a04f90938b9d832394c8215397b by Stefan Krah in branch
'master':
bpo-31279: Silence -Wstringop-overflow warning. (#3207)
https://github.com/python/cpython/commit/dce6502059f46a04f90938b9d832394c8215397b
Changes by Stefan Krah <ste...@bytereef.org>:
--
pull_requests: +3244
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31279>
___
_
New submission from Stefan Krah:
gcc-7.2 emits the following not-so-useful warning:
Objects/bytearrayobject.c:226:9: warning: ‘memcpy’: specified size between
9223372036854775808 and 18446744073709551615 exceeds maximum object size
9223372036854775807
--
messages: 300851
nosy: skrah
Stefan Krah added the comment:
Thanks, Serhiy!
--
components: +Build
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> compile error
versions: +Python 3.7
___
Python tracker <rep...@bugs.python.org>
<h
Stefan Krah added the comment:
New changeset 138753c1b96b5e06a5c5d409fa4cae5e2fe1108b by Stefan Krah in branch
'master':
bpo-31275: Small refactoring to silence a fall-through warning. (#3206)
https://github.com/python/cpython/commit/138753c1b96b5e06a5c5d409fa4cae5e2fe1108b
Changes by Stefan Krah <ste...@bytereef.org>:
--
pull_requests: +3243
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31275>
___
_
Stefan Krah added the comment:
All warnings except for #31275 are dealt with.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> compile error
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
New submission from Stefan Krah:
The last fall-through warning is in _codecs_iso2022.c. IMO the
current code is equivalent to this, but I'm no codecs expert at
all:
diff --git a/Modules/cjkcodecs/_codecs_iso2022.c
b/Modules/cjkcodecs/_codecs_iso2022.c
index 1ce4218f30..abf214880f 100644
Stefan Krah added the comment:
New changeset 9e1e6f528f3fec16b9bd99f5ee38048ffec04a81 by Stefan Krah in branch
'master':
bpo-30923: Silence fall-through warnings in libexpat build. (#3205)
https://github.com/python/cpython/commit/9e1e6f528f3fec16b9bd99f5ee38048ffec04a81
Changes by Stefan Krah <ste...@bytereef.org>:
--
pull_requests: +3242
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30923>
___
_
Stefan Krah added the comment:
What needs to be mentioned though is that the context has to be set
for unrounded calculations:
c = getcontext()
c.prec = MAX_PREC
c.Emax = MAX_EMAX
c.Emin = MIN_EMIN
Otherwise some people believe that the bignums are just rounded floating point
arithmetic
Stefan Krah added the comment:
pypy-5.8.0-beta0 (Python 3.5.3) is using a very nicely written CFFI wrapper for
libmpdec, so it also has the fast bignums.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Cherry picking has too many conflicts, I'm not backporting this myself.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
New changeset f432a3234f9f2ee09bd40be03e06bf72865ee375 by Stefan Krah in branch
'master':
bpo-30923: Silence fall-through warnings included in -Wextra since gcc-7.0.
(#3157)
https://github.com/python/cpython/commit/f432a3234f9f2ee09bd40be03e06bf72865ee375
Stefan Krah added the comment:
PR 3157 addresses everything apart from expat and
https://github.com/python/cpython/blob/master/Modules/cjkcodecs/_codecs_iso2022.c#L816
I'm not sure about that one. It looks harmless but a bit odd.
--
___
Python
Changes by Stefan Krah <ste...@bytereef.org>:
--
pull_requests: +3194
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30923>
___
_
501 - 600 of 3373 matches
Mail list logo
