New submission from Eric Govatos :
The RotatingFileHandler class located within lib/logging/handlers.py does not
accept any other 'mode' value than its default value of 'a' - even when the
parameter is supplied, such as 'ab', to append bytes, this is disregarde
Change by Eric Govatos :
--
title: RotatingFileHandler does not support any other mode than 'a'. ->
RotatingFileHandler does not support any mode other than 'a'.
___
Python tracker
<https://
Eric Wieser added the comment:
Nothing holding it up from my end, just waiting on someone to review it.
Perhaps this ping will help with that.
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue34
Eric Snow added the comment:
Awesome! Thanks for doing this, Victor. I'll take a look when I can and
adjust the changes for bpo-33608. If you'll recall, I made a similar change as
part of the solution for that issue, which we later reverted due to problems we
discovered w
Eric Snow added the comment:
FYI, in bpo-39984 Victor moved pending calls to PyInterpreterState, which was
part of my reverted change. However, there are a few other pieces of that
change that need to be applied before this issue is resolved. I'm not sure
when I'll get
Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue37881>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue23967>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Wieser added the comment:
> To make this work I had to write an ast printer that produces evaluatable
> Python code. Note that it's not complete, I know it's not complete, it's
> missing loads of operators. Assume that if this is a good idea I will add
>
Eric Snow added the comment:
> Wouldn't having less static types slow down startup time?
FWIW, I've been considering an approach where the main interpreter
keeps using static types but subinterpreters use heap types. If it
isn't too much effort (or too hacky) then it mig
Eric Snow added the comment:
> I close this issue with a complex history.
>
> If someone wants to continue to work on this topic, please open an issue with
> a very clear description of what should be done and how it is supposed to be
> used.
Yeah, there is more to do. I&
New submission from Eric Snow :
In bpo-37266 we strictly disallowed creation of daemon threads in
subinterpreters. However, this is backward-incompatible for existing users of
the subinterpreter C-API (such as mod-wsgi).
Rather than reverting that change I suggest that we make it opt-in
Eric Snow added the comment:
I've opened bpo-40234 to address backward incompatibility from this
change (e.g. affecting mod-wsgi).
--
___
Python tracker
<https://bugs.python.org/is
Eric Cousineau added the comment:
Super late response, but for this part:
> Well... perhaps you could create another PyObject (it's just a wrapper,
> right?) since the old one doesn't have any outside references to it
> remaining.
In certain cases, yes, that would be
New submission from Eric Cousineau :
Motivated by this downstream project issue that I am working on:
https://github.com/RobotLocomotion/drake/issues/13026
In https://bugs.python.org/issue32377, I encountered PEP 442's updated
resurrection behavior when moving from supporting Python
Eric Cousineau added the comment:
See also bpo-40240: "Expose public spelling of _PyGC_FINALIZED and
_PyGC_SET_FINALIZED?"
--
___
Python tracker
<https://bugs.python.o
Eric Cousineau added the comment:
C functions sound great!
I am certainly not wed to the macros (nor do I love them), as I do not have
intense performance requirements where inlining (and spilling implementation
guts) is necessary.
--
___
Python
Eric Cousineau added the comment:
> [...] but I am not sure it makes sense to allow to mark an object as
> finalized because that could mess with the GC algorithm.
Actually, I would like the opposite, to mark it unfinalized to resurrect the
object more than once. PEP 442 from a way
Eric Cousineau added the comment:
Er, to clarify: "PEP 442 had that effect" => "PEP 442 had the effect of making
it resurrectable only once, but not more than that."
--
___
Python tracker
<https://
Eric Cousineau added the comment:
Aye. Using a workaround for now ("leak" the object by incrementing the refcount
on first resurrection):
https://github.com/RobotLocomotion/pybind11/pull/39
I may try Antoine's suggestion later on, but will definitely reformulate this
to use
Eric Larson added the comment:
If that's out of contract, perhaps there should probably a big, visible warning
at the top of the multiprocessning docs stating that creating one of these
objects requires either using a context manager or ensuring manual
`.close()`ing?
1. It either us
Eric Larson added the comment:
> Why? This is a resource like any other and it requires proper resource
> management. Would you also put a big warning on "open()" stating that opening
> a file requires either using a context manager or ensure a manual close()?
One potent
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue40360>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
pull_requests: +19088
pull_request: https://github.com/python/cpython/pull/19768
___
Python tracker
<https://bugs.python.org/issue32
Eric Snow added the comment:
Thanks, Ben. I'll take a look.
--
components: +Library (Lib) -C API
title: Implement a C API for channel_send_wait for subinterpreters. ->
Implement _xxsubinterpreters.channel_send_wait().
___
Python tracker
Change by Eric Snow :
--
pull_requests: +19090
pull_request: https://github.com/python/cpython/pull/19770
___
Python tracker
<https://bugs.python.org/issue32
Change by Eric Snow :
--
pull_requests: +19149
pull_request: https://github.com/python/cpython/pull/19829
___
Python tracker
<https://bugs.python.org/issue32
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue40453>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Yeah, that looks like an oversight. I've approved your PR. Thanks!
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/is
Eric Snow added the comment:
Did you have a need for this to be fixed in 3.8 or earlier? This seems
reasonably and simple enough to backport. I suppose someone could be relying
on an implicit import of the "imp" module, but that seems highly unlikely and
susp
Change by Eric Snow :
--
stage: -> test needed
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue40350>
___
___
Python-bugs-list mai
Eric Snow added the comment:
Ah, namespace packages. :) Yeah, the code is not taking the "spec.loader is
None" case into account. I expect the fix would be to add handling of that
case a few lines up in the code, right after handling BuiltinImporter and
FrozenImporter. Offha
Eric Snow added the comment:
Thanks for working on this, Ben! FWIW, I've put up a separate PR to
demonstrate how I was thinking we would solve this:
https://github.com/python/cpython/pull/19829.
--
___
Python tracker
<https://bugs.py
Eric Snow added the comment:
Thanks again, Lewis!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Eric Snow added the comment:
FWIW, I think it would make sense to keep "signals_pending" under
_PyRuntimeState rather than moving it to PyInterpreterState.
Signals are only handled by the main interpreter (in its main thread). Even
though "signals_pending" is useful to
Eric Snow added the comment:
>From a user perspective, does it make sense to have a different
>recursion_limit per interpreter? I don't see a problem with it. However,
>does it make sense to also keep a global value that we default to when a
>per-interpreter value is not
Eric Snow added the comment:
If this issue covers the GIL (which it seems to) then I'd expect
_PyRuntimeState.gilstate to be handled here too.
--
___
Python tracker
<https://bugs.python.org/is
Eric Snow added the comment:
Good catch on this, Victor. Thanks for doing it.
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue40
Eric Snow added the comment:
It would probably make sense to remove the build option in the 3.9 release. We
can leave it in master, but remove it in the 3.9 branch once it has been
created.
--
___
Python tracker
<https://bugs.python.
Eric Snow added the comment:
FYI, with the following additions in Lib/test/test_datetime.py...
before = set(sys.modules)
try:
pure_tests = import_fresh_module(TESTS, fresh=['datetime', '_strptime'],
blocked=['_datet
Eric Snow added the comment:
Yep, before per-interpreter GIL is official we must get to the point where *no*
PyObject objects are shared.
Making PyObject.ob_refcnt atomic until then (only as part of the experiment)
should be fine.
--
___
Python
Eric Snow added the comment:
New changeset a1d9e0accd33af1d8e90fc48b34c13d7b07dcf57 by Eric Snow in branch
'master':
bpo-32604: [_xxsubinterpreters] Propagate exceptions. (GH-19768)
https://github.com/python/cpython/commit/a1d9e0accd33af1d8e90fc48b34c13
New submission from Eric Snow :
(This is a continuation of the work from bpo-33608. That issue ended up with a
lot of baggage and clutter (due to problems that have since been resolved), so
we closed it. This issue is where we're picking it up fresh.)
When two interpreters are cooper
Change by Eric Snow :
--
keywords: +patch
pull_requests: +19323
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/20012
___
Python tracker
<https://bugs.python.org/issu
New submission from Eric Wieser :
Consider a class like
class MyClass:
x: int
y: int
Which has
>>> MyClass.__annotations__
{'x': int, 'y': int}
In future, it might change to
class MyClass:
@proper
Change by Eric Wieser :
--
keywords: +patch
nosy: +Eric.Wieser
nosy_count: 1.0 -> 2.0
pull_requests: +19361
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20052
___
Python tracker
<https://bugs.python.org/i
Change by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Eric Wieser added the comment:
This seems somewhat related to https://bugs.python.org/issue31939
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue37
Change by Eric Engeström :
--
nosy: +1ace
___
Python tracker
<https://bugs.python.org/issue34690>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
pull_requests: +22769
pull_request: https://github.com/python/cpython/pull/23918
___
Python tracker
<https://bugs.python.org/issue36
Eric Snow added the comment:
New changeset 7ec59d8861ef1104c3028678b2cacde4c5693e19 by Eric Snow in branch
'master':
bpo-36876: [c-analyzer tool] Add a "capi" subcommand to the c-analyzer tool.
(gh-23918)
https://github.com/python/cpython/commit/7ec59d8861ef1104c302
Change by Eric Snow :
--
pull_requests: +22779
pull_request: https://github.com/python/cpython/pull/23929
___
Python tracker
<https://bugs.python.org/issue36
Eric Snow added the comment:
New changeset 5ae9be68d9f1a628fdc920b647257f94afb77887 by Eric Snow in branch
'master':
bpo-36876: [c-analyzer tool] Additional CLI updates for "capi" command.
(gh-23929)
https://github.com/python/cpython/commit/5ae9be68d9f1a628fdc9
New submission from Eric Osborne :
When I create a temporary directory, the name doesn't come back in a way the
application expects it. I ran into this using gitPython and I'm not entirely
clear whether it's a tmpfile issue or a gitpython issue, but I think it's
tempfil
New submission from Eric Poulsen :
Placing a ctypes.Union inside of a ctypes.BigEndianStructure results in
"TypeError: This type does not support other endian". I believe this is a
similar problem to issue #4376 (https://bugs.python.org/issue4376)
Minimum repro test case:
import
New submission from Eric Martin :
Run on a MacBook Pro (15-inch, 2019)
2.3 GHz 8-Core Intel Core i9
16 GB 2400 MHz DDR4
Python 3.8.7 (default, Dec 24 2020, 19:07:18)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credi
Eric Martin added the comment:
Many thanks Raymond for these insights and thorough explanations, I appreciate
it very much. Your conclusions are of course most reasonable. For me, I cannot
say that it is a real issue in practice. I have teaching notes in which I
illustrate with plots the
New submission from Eric Engestrom :
We have a pytest that boils down to the following:
```
#from __future__ import annotations
from inspect import Parameter, signature
def foo(x: str) -> str:
return x + x
def test_foo():
expected = (
Parameter
Eric Engestrom added the comment:
Sure thing.
Putting the reproducing code in `test_foo.py` and running `docker run --rm -it
-v $PWD:/code python sh -c 'pip install pytest && pytest -vvv
/code/test_foo.py'` yields:
```
Collecting pytest
Downloading pytest-6.2.2-py3-no
Eric Engestrom added the comment:
Sorry, I just realized you asked for the "success" value as well.
For python 3.7-3.9 without the `import annotations`, and for python 3.10, the
type annotation is a class, ie. ``.
--
___
Python track
Eric Engestrom added the comment:
(... and I had the window open for too long and didn't notice Ken's reply
before mine ^^')
@kj: thanks for the workaround! it's good to be able to change our code and not
have to depend on a yet-to-be-released patch on each python v
New submission from Eric L. :
The os.path documentation at https://docs.python.org/3/library/os.path.html
states that:
> Vice versa, using bytes objects cannot represent all file names on Windows
> (in the standard mbcs encoding), hence Windows applications should use string
> o
Eric L. added the comment:
Very confusing but very interesting. I'm trying to follow as I'm the main
maintainer of the rdiff-backup software, which goes cross-platforms, so these
small differences might become important.
Now, looking into the docs, following your explanations,
Eric Martin added the comment:
Thank you for letting us know, I am actually not surprised the issue would
bugger you and you would change your mind... Thinking further about it and
experimenting further, I thought it might not be such an edge case and there
could be a significant cost in
New submission from Eric L. :
tempfile fails on mixed str and bytes when setting tempfile.tempdir to a
non-existent bytes path but succeeds when set to an existing bytes path.
$ python3.9
Python 3.9.0a6 (default, Apr 28 2020, 00:00:00)
[GCC 10.0.1 20200430 (Red Hat 10.0.1-0.14)] on linux
Eric L. added the comment:
In the meantime, I noticed the following in addition:
[ericl@tuxedo ~]$ python3.9
Python 3.9.0a6 (default, Apr 28 2020, 00:00:00)
[GCC 10.0.1 20200430 (Red Hat 10.0.1-0.14)] on linux
Type "help", "copyright", "credits" or "licens
Eric L. added the comment:
Sorry, I uploaded by mistake an early version of the patch. The new one is the
one I had actually tested (the old one would fail with mixing bytes and string
under certain circumstances, I can't remember any more).
--
Added file: https://bugs.pytho
Eric L. added the comment:
On 23/05/2020 21:41, Gregory P. Smith wrote:
> Could you please turn that into a Github PR?
I can, if you don't tell me that I need to setup a full-blown Python
development environment to do this.
--
___
Python
Eric L. added the comment:
On 24/05/2020 20:30, Serhiy Storchaka wrote:
> Maybe just document that tempdir should be a string?
I would definitely prefer to have bytes paths considered as 1st class
citizen.
--
___
Python tracker
<
Eric L. added the comment:
Well, your decision but, as a user of the library, it didn't feel like a new
feature just like a bug to be fixed, the main issue being the inconsistent
handling of bytes vs. str.
--
___
Python tracker
&
New submission from Eric L. :
In chapter 3.1.2. Removing the MAX_PATH Limitation of
https://docs.python.org/3/using/windows.html#removing-the-max-path-limitation
(also in 3.9 and 3.10), it is written that "(Use of bytes as paths is
deprecated on Windows, and this feature is not avai
Eric L. added the comment:
The question is if only the statement that bytes are deprecated is wrong, but
also if the long path feature is supported with bytes or not. As written, I'm a
Linux guy, I don't feel like I have the pre-requisites to check thi
Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue31861>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
pull_requests: +20105
pull_request: https://github.com/python/cpython/pull/20926
___
Python tracker
<https://bugs.python.org/issue32
Eric Snow added the comment:
New changeset 818f5b597ae93411cc44e404544247d436026a00 by Eric Snow in branch
'master':
bpo-32604: Clean up test.support.interpreters. (gh-20926)
https://github.com/python/cpython/commit/818f5b597ae93411cc44e404544247
Eric Snow added the comment:
@Pablo, yeah, I'll try to take a look this week. Are these new failures?
Keep in mind that these tests can sometimes expose existing bugs in our runtime
(as we fix runtime issues elsewhere) rather than regressions, though that isn't
necessarily the
New submission from Eric Frederich :
The __init__ method for IPv4Network has a typo where it says all three of
'192.0.2.0/24', '192.0.2.0/255.255.255.0' and '192.0.0.2/0.0.0.255' should be
equal.
--
assignee: docs@python
components: Documentation
mess
New submission from Eric Wieser :
Python distinguishes signed zeros by their repr:
# floats
>>> 0.0
0.0
>>> -0.0
-0.0
# complex
>>> complex(0.0, 0.0) # A
0j
>>> complex(0.0, -0.0) # B
-0j
>>> complex(-0.0, 0.0) # C
(-0+0j)
>>> comple
Eric Wieser added the comment:
This was reported and closed in https://bugs.python.org/issue17336, but it
seems to me that this is easy to avoid - have `__repr__` return `complex(...)`
for values which do not round-trip.
--
___
Python tracker
Eric Wieser added the comment:
Apologies for not searching the issue tracker effectively until after filing
this.
--
___
Python tracker
<https://bugs.python.org/issue41
Eric Wieser added the comment:
> BTW I don't want repr() of a complex number to use the complex(..., ...)
A compromise would be to only use this notation if signed zeros are involved.
---
Another option would be to use slightly unusual reprs for these complex
numbers, which at lea
New submission from Eric Fahlgren :
Windows 10 Pro 64
Python 3.8.3 64
wxPython 4.1.0
It appears that there are synthetic classes in the mro, which don't appear in
the type's namespace, raising KeyError when encountered. From reading the
function's doc and source, it looks
Change by Eric Wieser :
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue41584>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Pederson :
ArgumentParser.add_subparsers() returns a _SubParsersAction. This requires
user code using type annotations to use a protected type which causes type
checkers like PyCharm to complain. For example:
def add_subparser(name: str, subparser
New submission from Eric Wieser :
The full definition of `multiprocessing.heap.BufferWrapper` is:
class BufferWrapper(object):
_heap = Heap()
def __init__(self, size):
if size < 0:
raise ValueError("Size {0:n} out of range"
Eric Wieser added the comment:
Whoops, typo. `>>> b[0]` should read `m[0]`.
--
___
Python tracker
<https://bugs.python.org/issue41673>
___
___
Python-bu
Eric Osborne added the comment:
Yes, I agree. Regardless of backport policy, this is a handy little
convenience featurette, not sliced bread v2, so it's not worth backporting
even if it was permissible.
eric
On Fri, Oct 16, 2020 at 7:13 PM Eric V. Smith
wrote:
>
> Eric V. Smith
Eric Osborne added the comment:
Did I really ship an enhancement without documenting it? I am a terrible
person. I will pick up the issue and take care of it.
eric
On Sat, Oct 17, 2020 at 9:07 AM Eric V. Smith
wrote:
>
> Eric V. Smith added the comment:
>
> I've create
Change by Eric Snow :
--
pull_requests: +21795
pull_request: https://github.com/python/cpython/pull/22841
___
Python tracker
<https://bugs.python.org/issue36
Eric Snow added the comment:
> I see multiple non trivial problems:
>
> * To finalize the subinterpreter A, Py_Finalize() may switch the current
> Python thread state from the main interpreter to a Python thread in the
> subintrepeter A. It can lead to new funny issues.
I&
Eric Snow added the comment:
New changeset 345cd37abe324ad4f60f80e2c3133b8849e54e9b by Eric Snow in branch
'master':
bpo-36876: Fix the C analyzer tool. (GH-22841)
https://github.com/python/cpython/commit/345cd37abe324ad4f60f80e2c3133b
Change by Eric Wolf :
--
components: Library (Lib)
nosy: Deric-W
priority: normal
severity: normal
status: open
title: unnecessary overhead in tempfile
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
New submission from Eric Wolf :
The tempfile module contains the class _RandomNameSequence, which has the rng
property.
This property checks os.getpid() every time and re-initializes a random number
generator when it has changed.
However, this is only necessary on systems which allow the
Change by Eric Wolf :
--
keywords: +patch
pull_requests: +21911
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22997
___
Python tracker
<https://bugs.python.org/issu
Eric Wolf added the comment:
SystemRandom seems to be slower:
from random import Random, SystemRandom
from timeit import timeit
user = Random()
system = SystemRandom()
characters = "abcdefghijklmnopqrstuvwxyz0123456789_"
timeit(lambda: user.choice(characters))
>>>
Eric Wolf added the comment:
It seems to be insignificant, however it would allow for easier
monkey-patching: https://bugs.python.org/issue32276
Instead of changing _Random one could simply assign a new instance to
_named_sequence
--
___
Python
Eric Wolf added the comment:
Thanks
--
___
Python tracker
<https://bugs.python.org/issue42160>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
pull_requests: +21964
pull_request: https://github.com/python/cpython/pull/23045
___
Python tracker
<https://bugs.python.org/issue36
Eric Snow added the comment:
New changeset 4fe72090deb7fb7bc09bfa56c92f6b3b0967d395 by Eric Snow in branch
'master':
bpo-36876: Small adjustments to the C-analyzer tool. (GH-23045)
https://github.com/python/cpython/commit/4fe72090deb7fb7bc09bfa56c92f6b
Eric Wolf added the comment:
It would be possible to allow the GC to finalize the Random instances through
weak references.
On the other hand, if many _RandomNameSequence instances were used temporarily,
a lot of callbacks would be registered via os.register_at_fork(), could that
cause
Eric Wolf added the comment:
>>> timeit(os.getpid)
0.0899073329931
Considering the reference leaks, os.getpid() seems to be the better solution.
--
___
Python tracker
<https://bugs.python.or
1201 - 1300 of 6144 matches
Mail list logo
