paul j3 added the comment:
This patch fixes both help and error formatting.
A module level '_format_metavars' does the formatting for both.
I have tried several alternatives, including using the 'usage' style.
There is similarity between this fix and that for issue 16468 (custom choices),
Jessica McKellar added the comment:
Thanks for reporting this, palm.kevin, and thanks for the patch,
amaury.forgeotdarc.
First, just to be explicit here's a short reproducer:
import sys
sys.stdin = None
help(1)
(Note that to get to the isatty check you need to provide an argument
Charles-François Natali added the comment:
I read again some remarks about alignement, it was suggested to provide
allocators providing an address aligned to a requested alignement. This topic
was already discussed in #18835.
The alignement issue is really orthogonal to the calloc one, so
akira added the comment:
Here's a new patch with a simplified ssl.cert_time_to_seconds()
implementation that brings strptime() back.
The behaviour is changed:
- accept both %e and %d strftime formats for days as strptime-based
implementation did before
- return an integer instead of a float
akira added the comment:
Replace IndexError with ValueError in the patch because tuple.index raises
ValueError.
--
Added file: http://bugs.python.org/file35051/ssl_cert_time_to_seconds-ps5.patch
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
2014-04-27 5:26 GMT+02:00 ivank rep...@bugs.python.org:
(I see the `IOError: [Errno 5] Input/output error` exception now.)
Can you please run your test in strace to see system calls?
--
___
Python tracker
STINNER Victor added the comment:
2014-04-27 10:30 GMT+02:00 Charles-François Natali rep...@bugs.python.org:
I read again some remarks about alignement, it was suggested to provide
allocators providing an address aligned to a requested alignement. This
topic was already discussed in #18835.
Claudiu.Popa added the comment:
In Python 3 docs there is a hint in the documentation for `loadTestsFromModule`:
This method searches module for classes derived from TestCase and creates an
instance of the class for each test method defined for the class.
The phrase with a fixture per test
Claudiu.Popa added the comment:
Ping? The change is clear, has the same semantics and its a little bit faster.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20642
___
Claudiu.Popa added the comment:
Can anyone review this patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
___
___
Python-bugs-list
Claudiu.Popa added the comment:
Ping. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18615
___
___
Python-bugs-list mailing list
Unsubscribe:
Charles-François Natali added the comment:
This issue was opened to be able to use tracemalloc on numpy. I would
like to make sure that calloc is enough for numpy. I would prefer to
change the malloc API only once.
Then please at least rename the issue. Also, I don't see why
everything
Charles-François Natali added the comment:
Note to numpy devs: it would be great if some of you followed the
python-dev mailing list (I know it can be quite volume intensive, but
maybe simple filters could help keep the noise down): you guys have
definitely both expertise and real-life
STINNER Victor added the comment:
I wrote a short microbenchmark allocating objects using my benchmark.py script.
It looks like the operation (None,) * N is slower with calloc-3.patch, but
it's unclear how much times slower it is. I don't understand why only this
operation has different
Antoine Pitrou added the comment:
Regarding the *Calloc functions: how about we provide a sane API
instead of reproducing the cumbersome C API?
Isn't the point of reproducing the C API to allow quickly switching from
calloc() to PyObject_Calloc()?
(besides, it seems the OpenBSD guys like the
Stefan Krah added the comment:
Just to add another data point, I don't find the calloc() API
cumbersome.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21233
___
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20230
___
___
Python-bugs-list
STINNER Victor added the comment:
It looks like calloc-3.patch is wrong: it modify _PyObject_GC_Malloc() to fill
the newly allocated buffer with zeros, but _PyObject_GC_Malloc() is not only
called by PyType_GenericAlloc(): it is also used by _PyObject_GC_New() and
_PyObject_GC_NewVar(). The
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1820
___
___
Python-bugs-list
Stefan Krah added the comment:
Actually, I think we have to match the C-API: For instance, in
Modules/_decimal/_decimal.c:5527 the libmpdec allocators are
set to the Python allocators.
So I'd need to do:
mpd_callocfunc = PyMem_Calloc;
I suppose that's a common use case.
--
New submission from Claudiu.Popa:
Due to some bad math on my side, I passed max_workers=0 to
concurrent.futures.ThreadPoolExecutor. This didn't fail properly, but hanged.
The same behaviour occurs in ProcessPoolExecutor, but this time it fails
internally with something like this:
Exception
Claudiu.Popa added the comment:
For instance, multiprocessing behaves like this:
multiprocessing.Pool(-1)
Traceback (most recent call last):
File stdin, line 1, in module
File C:\Python34\lib\multiprocessing\context.py, line 118, in Pool
context=self.get_context())
File
New submission from Armin Ronacher:
I'm trying to write some code that fixes a misconfigured sys.stdin on a case by
case bases but unfortunately I cannot use TextIOWrapper for this because it
always closes the underlying file:
Python
import io
sys.stdin.encoding
'ANSI_X3.4-1968'
stdin =
Claudiu.Popa added the comment:
Added a new patch with improvements suggested by Jim. Thanks!
I removed the handling of processes=1, because it can still be useful: having a
background worker which processes the files received from _walk_dir. Also, it
checks that compile_dir receives a
Charles-François Natali added the comment:
It looks like calloc-3.patch is wrong: it modify _PyObject_GC_Malloc() to
fill the newly allocated buffer with zeros, but _PyObject_GC_Malloc() is not
only called by PyType_GenericAlloc(): it is also used by _PyObject_GC_New()
and
Changes by Steven D'Aprano steve+pyt...@pearwood.info:
--
nosy: -steven.daprano
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16104
___
___
Berker Peksag added the comment:
Can this be closed? (or needs backport to 2.7?
http://hg.python.org/cpython/file/2.7/Lib/io.py#l69)
--
nosy: +berker.peksag
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21225
Claudiu.Popa added the comment:
Add new patch with fixes proposed by Berker Peksag. Thanks for the review.
Hopefully, this is the last iteration of this patch.
--
Added file: http://bugs.python.org/file35055/issue16104_10.patch
___
Python tracker
Charles-François Natali added the comment:
I'm with Antoine, it's likely a glibc bug.
We already had a similar issue with fwrite():
http://bugs.python.org/issue17976
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
ivank, if you know some C, perhaps you could write a trivial program that does
an fopen() followed by an fread() of 131072 bytes, and see if the fread()
errors out.
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 6b912c90de72 by Benjamin Peterson in branch 'default':
say how to run one test (closes #21361)
http://hg.python.org/devguide/rev/6b912c90de72
--
nosy: +python-dev
resolution: - fixed
stage: patch review - resolved
status: open - closed
Tim Golden added the comment:
Committed. Thanks for the patch.
--
resolution: - fixed
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21349
___
Eric V. Smith added the comment:
I agree with Raymond: this isn't a practical problem worth solving. If it's
causing an actual problem, please re-open this issue and give a use case.
Thanks.
--
nosy: +eric.smith
resolution: - wont fix
status: open - closed
New submission from Armin Ronacher:
The documentation recommends replacing sys.stdin with a binary stream
currently: https://docs.python.org/3/library/sys.html#sys.stdin
This sounds like a bad idea because it will break pretty much everything in
Python in the process.
As example:
import
Roundup Robot added the comment:
New changeset 18cfc2a42772 by Tim Golden in branch '2.7':
Issue #9291 Do not attempt to re-encode mimetype data read from registry in
ANSI mode. Initial patches by Dmitry Jemerov Vladimir Iofik
http://hg.python.org/cpython/rev/18cfc2a42772
--
nosy:
New submission from Paul Sokolovsky:
It caused me a big surprise that asyncio.Task object automatically schedules
itself in the main loop for execution upon creation (i.e. in constructor).
Nowhere in the main reference part of section 18.5.2.4. Task
Roundup Robot added the comment:
New changeset 0c8a7299c7e3 by Tim Golden in branch '2.7':
Issue #9291 Add ACKS NEWS
http://hg.python.org/cpython/rev/0c8a7299c7e3
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
STINNER Victor added the comment:
And
http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/malloc/malloc.c?view=markup
to check that calloc(nelem, elsize) is implemented as calloc(nelem *
elsize)
__libc_calloc() starts with a check on integer overflow.
--
Paul Sokolovsky added the comment:
Based on discussion
https://groups.google.com/forum/#!topic/python-tulip/zfMQIUcIR-0 . That
discussion actually questions the grounds of such Task behavior, and points it
as a violation of Explicit is better than implicit principle, and as
inconsistent
Charles-François Natali added the comment:
__libc_calloc() starts with a check on integer overflow.
Yes, see my previous message:
AFAICT, the two arguments are purely historical (it was used when
malloc() didn't guarantee suitable alignment, and has the advantage of
performing overflow check
New submission from Jon Brandvein:
def foo():
try:
return 1
finally;
return 2
print(foo()) # 2
I've seen this peculiar case discussed on a few blogs lately, but was unable to
find confirmation that this behavior is defined.
In the try/finally section of
Changes by Claudiu.Popa pcmantic...@gmail.com:
Added file: http://bugs.python.org/file35056/issue16104_11.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16104
___
eryksun added the comment:
It works if you detach the buffer beforehand:
import io, sys
stdin = sys.stdin
stdin.flush()
correct_stdin = io.TextIOWrapper(stdin.buffer, 'utf-8')
correct_stdin.readline()
foobar
'foobar\n'
correct_stdin.detach()
Charles-François Natali added the comment:
Thanks for the patch.
That's IMO a good change, but I would only apply it to default, and not
backport it.
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21342
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21365
___
Claudiu.Popa added the comment:
Attached patch with improvements suggested by Charles-François Natali. Thank
you for the review.
--
Added file: http://bugs.python.org/file35057/issue21362.patch
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
list: items are allocated in a second memory block. PyList_New() uses memset(0)
to set all items to NULL.
tuple: header and items are stored in a single structure (PyTupleObject), in a
single memory block. PyTuple_New() fills the items will NULL (so write
Charles-François Natali added the comment:
Like Antoine, I'm really skeptical about the backport: honestly, this change
doesn't bring much in a normal application. To run into the number of open file
descriptors limit (so the scalability aspect), one would need to have *many*
concurrent
STINNER Victor added the comment:
Because if a code creates many such objects which basically just do
calloc(), on operating systems with memory overommitting (such as
Linux), the calloc() allocations will pretty much always succeed, but
will segfault when the page is first written to in case of
Nathaniel Smith added the comment:
@Charles-François: I think your worries about calloc and overcommit are
unjustified. First, calloc and malloc+memset actually behave the same way here
-- with a large allocation and overcommit enabled, malloc and calloc will both
go ahead and return the
Charles-François Natali added the comment:
William, thanks for the benchmarks.
Unfortunately this type of benchmark depends on the hardware (disk, SSD, emmoey
bandwitdh, etc).
So I'd suggest, instead of using an hardcoded value, to simply reuse
io.DEFAULT_BUFFER_SIZE.
That way, if some day
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
components: +IO
nosy: +benjamin.peterson, flox, hynek, pitrou, stutzbach
type: - behavior
versions: +Python 3.3, Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: +flox
stage: - patch review
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21362
___
Antoine Pitrou added the comment:
Initial introduction is 59cb9c074e09.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21364
___
___
Changes by Claudiu.Popa pcmantic...@gmail.com:
Added file: http://bugs.python.org/file35058/issue21362_1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21362
___
Roundup Robot added the comment:
New changeset 17df50df62c7 by Tim Golden in branch 'default':
Issue #18314 os.unlink will now remove junction points on Windows. Patch by Kim
Gräsman.
http://hg.python.org/cpython/rev/17df50df62c7
--
nosy: +python-dev
Roundup Robot added the comment:
New changeset 4b97092aa4bd by Tim Golden in branch 'default':
Issue #18314 Add NEWS item.
http://hg.python.org/cpython/rev/4b97092aa4bd
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
New submission from Lee Clemens:
Not mentioned (at least not specifically) in the release notes,
multiprocessing.JoinableQueue now requires 'ctx' keyword argument:
def __init__(self, maxsize=0, *, ctx):
This causes an application calling JoinableQueue() to work with 3.3.2 (my
single test)
Lee Clemens added the comment:
Same issue (ctx keyword) occurs with multiprocessing.queues.SimpleQueue
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21367
___
Charles-François Natali added the comment:
@Charles-François: I think your worries about calloc and overcommit are
unjustified. First, calloc and malloc+memset actually behave the same way
here -- with a large allocation and overcommit enabled, malloc and calloc
will both go ahead and
Changes by Claudiu.Popa pcmantic...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21367
___
___
Python-bugs-list mailing
Nick Coghlan added the comment:
Yep, it's scary indeed, but such a long lived feature release is a novel
situation that may require some adjustments to our risk management.
However, we can still decide to defer some of the changes until 2.7.8, even
though the notion of backporting them has been
Tim Golden added the comment:
Backed out the commits after all the Windows buildbots broke. Need to look
further. (No problems on a Win7 or Ubuntu build here).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
Antoine Pitrou added the comment:
Just try python -c [i for i in
range(large value)] on a 64-bit machine, I'll bet you'll get a
MemoryError (ENOMEM).
Hmm, I get an OOM kill here.
--
___
Python tracker rep...@bugs.python.org
Nathaniel Smith added the comment:
On my laptop (x86-64, Linux 3.13, 12 GB RAM):
$ python3 -c [i for i in range(9)]
zsh: killed python3 -c [i for i in range(9)]
$ dmesg | tail -n 2
[404714.401901] Out of memory: Kill process 10752 (python3) score 687 or
sacrifice child
Roundup Robot added the comment:
New changeset d42d3d3f9c41 by Guido van Rossum in branch '3.4':
asyncio: Be careful accessing instance variables in __del__ (closes #21340).
http://hg.python.org/cpython/rev/d42d3d3f9c41
New changeset 0cb436c6f082 by Guido van Rossum in branch 'default':
Merge
Charles-François Natali added the comment:
And your test.py produces the same result. Are you sure you don't have a
ulimit set on address space?
Yep, I'm sure:
$ ulimit -v
unlimited
It's probably due to the exponential over-allocation used by the array
(to guarantee amortized constant
Charles-François Natali added the comment:
Dammit, read:
python -c 'bx * (2**48)'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21233
___
___
Jessica McKellar added the comment:
Thanks for the patches, vladris!
I've reviewed the latest version, and it addresses all of Antoine's review
feedback. Ezio left some additional feedback
(http://bugs.python.org/review/5001/#ps3407) which still needs to be addressed.
--
nosy:
Nick Coghlan added the comment:
Additional environments where the system misreports the encoding to use
(courtesy of Armin Ronacher Graham Dumpleton on Twitter): upstart, Salt,
mod_wsgi.
Note that for more complex applications (e.g. integrated web UIs, socket
servers, sending email), round
Stefan Krah added the comment:
1. _asdict() returns a normal dictionary. I don't know if this is what
is required.
Good question. I don't think we can import OrderedDict from collections
because of the impact on startup time (_collections_abc was created to
avoid the issue for
Nathaniel Smith added the comment:
Right, python3 -c 'bx * (2 ** 48)' does give an instant MemoryError for me.
So I was wrong about it being the VM limit indeed.
The documentation on this is terrible! But, if I'm reading this right:
http://lxr.free-electrons.com/source/mm/util.c#L434
the
Charles-François Natali added the comment:
Alright, it bothered me so I wrote a small C testcase (attached),
which calls malloc in a loop, and can call memset upon the allocated
block right after allocation:
$ gcc -o /tmp/test /tmp/test.c; /tmp/test
malloc() returned NULL after 3050MB
$ gcc
Charles-François Natali added the comment:
So yeah, touching pages can affect whether a later malloc returns ENOMEM.
I'm not sure any of this actually matters in the Python case though :-).
There's still no reason to go touching pages pre-emptively just in case we
might write to them
Antoine Pitrou added the comment:
$ gcc -o /tmp/test /tmp/test.c; /tmp/test
malloc() returned NULL after 3050MB
$ gcc -DDO_MEMSET -o /tmp/test /tmp/test.c; /tmp/test
malloc() returned NULL after 2130MB
Without memset, the kernel happily allocates until we reach the 3GB
user address space
Stefan Krah added the comment:
This is probably offtopic, but I think people who want reliable
MemoryErrors can use limits, e.g. via djb's softlimit (daemontools):
$ softlimit -m 1 ./python
Python 3.5.0a0 (default:462470859e57+, Apr 27 2014, 19:34:06)
[GCC 4.7.2] on linux
Type help,
Charles-François Natali added the comment:
Both OOM here (3.11.0-20-generic, 64-bit, Ubuntu).
Hm...
What's /proc/sys/vm/overcommit_memory ?
If it's set to 0, then the kernel will always overcommit.
If you set it to 2, normally you'd definitely get ENOMEM (which is IMO
much nicer than getting
Charles-François Natali added the comment:
Hm...
What's /proc/sys/vm/overcommit_memory ?
If it's set to 0, then the kernel will always overcommit.
I meant 1 (damn, I need sleep).
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Hm...
What's /proc/sys/vm/overcommit_memory ?
If it's set to 0, then the kernel will always overcommit.
Ah, indeed.
If you set it to 2, normally you'd definitely get ENOMEM
You're right, but with weird results:
$ gcc -o /tmp/test test.c; /tmp/test
Charles-François Natali added the comment:
Hm...
What's /proc/sys/vm/overcommit_memory ?
If it's set to 0, then the kernel will always overcommit.
Ah, indeed.
See above, I mistyped: 0 is the default (which is already quite
optimistic), 1 is always.
If you set it to 2, normally you'd
Kim Gräsman added the comment:
Thanks for pushing this forward! Do you have links to the failing bots I could
take a look at?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
Tim Golden added the comment:
Here are a couple:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/4423
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8288
--
___
Python tracker rep...@bugs.python.org
New submission from Nick Coghlan:
Issue 19977 added surrogateescape to the fallback settings for the standard
streams if Python 3 appears to be running under the POSIX locale (which Python
3 currently reads as setting a default encoding of ASCII, which is almost
certainly wrong on any modern
Changes by Charles-François Natali cf.nat...@gmail.com:
--
stage: patch review - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21362
___
Nick Coghlan added the comment:
Issue 21368 now suggests looking for /etc/locale.conf before falling back to
ASCII+surrogateescape.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19977
Antoine Pitrou added the comment:
We should not overcomplicate this. I suggest that we simply use utf-8 under the
C locale.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19977
Jessica McKellar added the comment:
Thanks for working to increase our test coverage, Sean.Fleming!
Looking at the current coverage, the there is one line in
LocaleTextCalendar.formatweekday without coverage:
http://hg.python.org/cpython/file/e159cb0d955b/Lib/calendar.py#l519.
You add some
Nick Coghlan added the comment:
If you can convince Stephen Turnbull that's a good idea, sure. It's
probably more likely to be the right thing than ASCII or ASCII +
surrogateescape, but in the absence of hard data, he's in a better
position than we are to judge the likely impact of that, at
Kim Gräsman added the comment:
Thanks!
At first I suspected 32 vs 64 bit, but the failing bots cover both...
One thing that stands out to me as risky is the memcmp() against \\??\\,
which could overrun a short src_path buffer. But I don't think that would fail
here.
I must have made some
Kathleen Weaver added the comment:
Latest update
--
Added file: http://bugs.python.org/file35061/mywork.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20265
___
New submission from Sworddragon:
tarfile.open() does support optionally an compression method on the mode
argument in the form of 'filemode[:compression]' but tarfile.TarFile() does
only suport 'a', 'r' and 'w'. Is there a special reason that tarfile.TarFile()
doesn't directly support an
New submission from John Rusnak:
Launch python3.3 and then
import traceback
tracebacke.format_exc()
Seomteims a long trace about missing attribute is produced, on subequent of
sometimes first call, python executable segfaults. I see this behavior in an
app as well then calling
Nikolaus Rath added the comment:
As discussed on python-dev, here is a patch that changes the behavior of send()
and sendall() to raise SSLWant* exceptions instead of returning zero.
--
Added file: http://bugs.python.org/file35062/issue20951_r2.diff
Changes by STINNER Victor victor.stin...@gmail.com:
Added file: http://bugs.python.org/file35064/use_calloc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21233
___
STINNER Victor added the comment:
I splitted my patch into two parts:
- calloc-4.patch: add new Calloc functions including _PyObject_GC_Calloc()
- use_calloc.patch: patch types (bytes, dict, list, set, tuple, etc.) and
various modules to use calloc
I reverted my changes on
STINNER Victor added the comment:
bench_alloc2.py: updated benchmark script. I added bytes(n) and bytearray(n)
tests and removed the test decoding from ASCII.
Common platform:
Timer: time.perf_counter
Timer info: namespace(adjustable=False,
implementation='clock_gettime(CLOCK_MONOTONIC)',
Antoine Pitrou added the comment:
Common platform:
Timer: time.perf_counter
Timer info: namespace(adjustable=False,
implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True,
resolution=1e-09)
Platform: Linux-3.13.9-200.fc20.x86_64-x86_64-with-fedora-20-Heisenbug
STINNER Victor added the comment:
Are you sure this is a good platform for performance reports? :)
Don't hesitate to rerun my benchmark on more different platforms?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21233
STINNER Victor added the comment:
Why not using try/except AttributeError?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21340
___
___
STINNER Victor added the comment:
I don't think that Python should read such configuration file. If you consider
that something is wrong here, please report the issue to the C library.
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
1 - 100 of 116 matches
Mail list logo