Julien Danjou jul...@danjou.info added the comment:
Is there to chance to see this *bug* fixed someday?
--
nosy: +jd
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1644818
New submission from Julien Danjou:
import urllib.parse
urllib.parse.splitport(::1)
(':', '1')
This is obviously invalid.
--
components: Library (Lib)
messages: 190968
nosy: jd
priority: normal
severity: normal
status: open
title: urllib2/urllib.parse.splitport does not handle IPv6
Julien Danjou added the comment:
Attached is a patch inspired by a function written for OpenStack Oslo library.
--
keywords: +patch
Added file:
http://bugs.python.org/file30558/0001-Make-urllib.parse.splitport-handle-IPv6-correctly.patch
___
Python
New submission from Julien Danjou :
When using the tracemalloc module, the maximum number of frames that are
captured is specified at startup via a value to the `start` method.
However, if the number of frames is truncated, there's no way to know the
original length of the stack traces
Change by Julien Danjou :
--
keywords: +patch
pull_requests: +15222
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15545
___
Python tracker
<https://bugs.python.org/issu
Julien Danjou added the comment:
> In fact, I didn't check: maybe traceback_t size is not change by your PR,
> because of memory aligment and padding.
It is changed. The current size is should be determined by sizeof(Py_uhash_t +
int + int) which is 4 + 4 + 4, so 12 aligned/padded.
Julien Danjou added the comment:
That's a good question. Considering that Py_DEFAULT_RECURSION_LIMIT is 1000, we
could probably settle on 2 bytes by using an uint16_t which ought to be enough
unless people regularly trace Python stack traces bigger that are bigger than
2^16
Julien Danjou added the comment:
This is actually true and it's quite easy to produce a bug that triggers a
segmentation fault when iterating over a large list of threads create
dynamically.
That makes PyThreadState_Next barely usable for any program that has a few
threads. The head mutex
Julien Danjou added the comment:
It'd be great if you could reopen it. I'm interested in fixing it properly.
It's impossible to "solve" in Python 2 since the head mutex is not accessible
(it's static in pystate.c) but this is doable with Python 3 (yay).
We'd simply need to provide
Julien Danjou added the comment:
Yes, that's the one
--
___
Python tracker
<https://bugs.python.org/issue1021318>
___
___
Python-bugs-list mailing list
Unsub
Julien Danjou added the comment:
Victor, do you have an idea of how you would like this mutex to be exposed?
I see it only recently changed in Python 3.7 to be part of a structure, though
this structure is not public AFAIU.
Is adding 2 new lock/unlock C functions good enough
Julien Danjou added the comment:
Right, though if you read the code I linked, the PyGC_Head size is never used.
AFAICS the Cython code does not access it either (at least not directly).
The code segfaults at import time.
I'm not even sure it's possible and the problem isn't in something
Julien Danjou added the comment:
The problem is that AFAIK the wheel system does not allow you to specify and
provide a wheel for each minor Python version.
For references, the code that segfaults is:
https://github.com/DataDog/dd-trace-py/blob/master/ddtrace/profile/collector/stack.pyx
Julien Danjou added the comment:
> If you want to ship wheel package, another compromise would be to require
> Python 3.7.5 or newer, and check early the Python version.
Yes, this is what I do now to avoid getting a segmentation fault.
I'm fine with closing this as wontfix or reject
New submission from Julien Danjou :
As I've reported originally on the python-dev list, there seems to be an ABI
breakage between 3.7.4 and 3.7.5.
https://mail.python.org/archives/list/python-...@python.org/message/J2FGZPS5PS7473TONJTPAVSNXRGV3TFL/
The culprit commit is
https://github.com
Change by Julien Danjou :
--
keywords: +patch
pull_requests: +17188
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17752
___
Python tracker
<https://bugs.python.org/issu
Julien Danjou added the comment:
Relevant python-dev thread:
https://mail.python.org/archives/list/python-...@python.org/thread/QVMFP76R35SXUIM2WPPVPV5XCVMKPDEB/#TLP6MWNML4PRKFFGXHCKNEUMN6UIQ4MT
--
___
Python tracker
<https://bugs.python.
New submission from Julien Danjou :
PyErr_GetExcInfo does not allow to retrieve exception information for an
arbitrary thread. As it calls `_PyThreadState_GET` itself, it's impossible to
get exception information for a different thread.
--
components: C API
messages: 359029
nosy: jd
New submission from Julien Danjou :
The function _PyErr_GetTopmostException() is not exported and is useful to get
access to exceptions info from a PyThreadState.
--
components: C API
messages: 368327
nosy: jd
priority: normal
severity: normal
status: open
title: Expose
Julien Danjou added the comment:
I would definitely love to have a public API for this.
Would `PyErr_GetTopmostException` be a good candidate for this?
(I can open a different bug report if needed)
--
___
Python tracker
<https://bugs.python.
Change by Julien Danjou :
--
keywords: +patch
pull_requests: +19292
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19977
___
Python tracker
<https://bugs.python.org/issu
Julien Danjou added the comment:
PyErr_GetExcInfo() does not allow to specify a PyThreadState as argument.
--
___
Python tracker
<https://bugs.python.org/issue40
Julien Danjou added the comment:
I confirm what Victor wrote. :)
--
___
Python tracker
<https://bugs.python.org/issue40545>
___
___
Python-bugs-list mailin
Change by Julien Danjou :
--
keywords: +patch
pull_requests: +20832
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21689
___
Python tracker
<https://bugs.python.org/issu
Julien Danjou added the comment:
Adding to the thread object might be a good idea, but it does not work if you
ever start threads with the low-level `_thread` API.
It's also a different design from the existing `sys._current_frames`.
Adding it on top of a frame is interesting though. I think
New submission from Julien Danjou :
In order to do statistical profiling on raised exception, having the ability to
poll all the running threads for their currently handled exception would be
fantastic.
There is an exposed function named `sys._current_frames()` that allows to list
New submission from Julien Danjou :
Python 3.9 introduced a regression with concurrent.futures. The following
program works fine on Python < 3.8 but raises an error on 3.9:
```
import atexit
import concurrent.futures
def spawn():
with concurrent.futures.ThreadPoolExecutor() a
Julien Danjou added the comment:
> Is there a real-world situation where it's specifically necessary or even
> beneficial to utilize ThreadPoolExecutor at this point after thread
> finalization rather than earlier in the program? Not that it doesn't exist,
> but to me it intui
28 matches
Mail list logo
