New submission from Eric Froemling :
I've run into an issue where exceptions thrown by Enum constructors are keeping
my objects alive. The underlying issue seems to be the same as
https://bugs.python.org/issue36820
The same method used to fix the issue above seems to work here: simply a
Change by Eric Snow :
--
pull_requests: +22322
pull_request: https://github.com/python/cpython/pull/23431
___
Python tracker
<https://bugs.python.org/issue36
Eric Snow added the comment:
New changeset 9f02b479e6b6b48d0c2aad621978cff82e530b15 by Eric Snow in branch
'master':
bpo-36876: [c-analyzer tool] Tighten up the results and output. (GH-23431)
https://github.com/python/cpython/commit/9f02b479e6b6b48d0c2aad621978cf
Eric Snow added the comment:
> The vulnerability is known since 2003 (Usenix 2003): read "Denial of
> Service via Algorithmic Complexity Attacks" by Scott A. Crosby and Dan
> S. Wallach.
Crosby started a meaningful thread on python-dev at that time similar to the
c
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue6531>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
FYI: unless importlib took undue liberties (unlikely), frozen modules also
precede path-based modules. See the implicit additions to sys.meta_path in
Lib/importlib/_bootstrap.py.
Whether or not to include a mention of frozen modules in the tutorial...I'll
Eric Snow added the comment:
what value do you see for __package__ in pkgA?
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13912>
___
___
Eric Snow added the comment:
Jason: just a warning. importlib_backport is a relatively naive tool for
generating the backport from the py3k source. It's also relatively fragile and
at this point probably doesn't work with the defa
Eric Snow added the comment:
The problem is your level is off and the name is incomplete.
master.pkgA.foo.py should have the following:
__import__('pkgB.bar', master.pkgA.__dict__, level=2).bar
or
__import__('pkgB.bar', master.pkgA.__dict__, fro
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13405>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
No problem, Stefan. :) The main motivation was to capture the discussion at
the time so that something actually came of it.
Adding info to the devguide, essentially the catalog/how-to of core dev
activities, was meant to simply provide another clear avenue for
Eric Talevich added the comment:
It's more-or-less fixed in Python 3.2:
- With cElementTree, both bytes and strings are accepted for events;
- With ElementTree, only strings are accepted, and bytes raise a ValueError
(unknown event).
A small inconsistency remains, but it's fine t
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13961>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13977>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Talevich added the comment:
Well, this is not the best month for me to try digging into a new codebase... I
would not mind if someone else did the patch for this.
--
___
Python tracker
<http://bugs.python.org/issue9
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13991>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Ran into this bug today in 2.7 (building python-sybase with freetds). The fix
in msg121260 took care of it (didn't try the patch). Thanks, Éric.
Is this something that could get patched in the upcoming micro releases? It's
not so important for
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14043>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14040>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14057>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14067>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13447>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14080>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue1116520>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue8706>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13797>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue11477>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue992389>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14226>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14209>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue1469629>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue4199>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14328>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14331>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue11105>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Snow :
The imp.init_frozen() function was removed from the documentation prior to 3.2
(changeset 2cf7bb2bbfb8). One reference to the function was left behind. I've
attached a very intricate patch.
--
assignee: docs@python
components: Documentation
Changes by Eric Snow :
--
title: imp module should omit references to init_frozen -> imp module docs
should omit references to init_frozen
___
Python tracker
<http://bugs.python.org/issu
Eric Snow added the comment:
Here's an incomplete (though essentially test-passing) patch that flips more of
imp into importlib. It builds on Brett's patch. The gist is that imp.py is a
minimal wrapper around importlib, which uses _imp directly.
Ultimately the things implemen
Eric Snow added the comment:
Here's a listing of the places where import-ish modules are used in CPython.
Once things all the import stuff currently on the table is wrapped up, I'll
probably work on switching things over to using importlib directly.
--
Added
Eric Snow added the comment:
Of note for my patch is the addition of SUFFIXES and MODE to the 3 main "file
loader" classes. I did this to reverse the dependence on imp.get_suffixes().
As well, a couple of extra functions are added to
Python/importlib/_bootstrap.py for a similar r
Eric Snow added the comment:
Sounds good. It will be a while before we get there, but at that point I was
already planning on getting in touch with the maintainers of relevant modules
before messing with them.
--
___
Python tracker
<h
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14386>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
+0 as long as the linked pages don't go anywhere. They've been great
resources, containing some information that is not located elsewhere.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.o
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
It's been a while and I probably need to clean up that last patch a little. I
also need to address the questions of:
1. f_func for class/module execution
2. thread-safety
see:
http://mail.python.org/pipermail/python-ideas/2011-August/011321.html
and
Eric Snow added the comment:
for reference, a related issue:
http://bugs.python.org/issue13672
--
___
Python tracker
<http://bugs.python.org/issue12
Eric Snow added the comment:
(Éric, I'd reply in the review if reitveld recognized my current username --
see http://psf.upfronthosting.co.za/roundup/meta/issue402. FYI, I also did not
get an email for your review, which is likely related to that issue.)
Regarding __all__, I didn'
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue1>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14494>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14500>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14551>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue6380>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue1590864>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14578>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Yeah, that's one part of imp.find_module that I kind of set aside too (the
#ifdef MS_COREDLL sections in Python/import.c). For now would it be sufficient
to expose _PyWin_FindRegisteredModule() privately with a wrapper in the imp
m
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14581>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
big +1! I went quite a while before realizing that loader.load_module() was
supposed to return the module, due to this specific issue.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14580>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14583>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14585>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14592>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14594>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14593>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
This is a mostly-working sketch of find_module() in imp.py. I've run out of
time tonight, but wanted to get it up in case it's useful to anyone else (a.k.a
Brett). If nobody's touched it before then, I'll finish it up tomorrow.
---
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14604>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14605>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue24932>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
pull_requests: +13445
___
Python tracker
<https://bugs.python.org/issue36876>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Note that I'm working on making pending calls per-interpreter (see issue #33608
and https://github.com/python/cpython/pull/12360 (since reverted)).
As to exposing Py_AddPendingCall() as sys.addpendingcall, that might be opening
a can of worms. Injecting
Eric Snow added the comment:
> Well, it's absolutely the same mechanism that signal handlers use.
Antoine changed signals a while back so they no longer use the pending calls
machinery.
--
___
Python tracker
<https://bugs.python.org
Eric Snow added the comment:
If this is about signals, it isn't enough just to run on the main thread. It
also has to be the main interpreter.
--
___
Python tracker
<https://bugs.python.org/is
Eric Snow added the comment:
FWIW, I don't see the problem with supporting any read-only "buffer" object,
rather than just bytes objects, for the string of bytes in a code object.
That's all that Dino is proposing. The change is not invasive and solves a
real n
Eric Snow added the comment:
New changeset 396e0a8d9dc65453cb9d53500d0a620602656cfe by Eric Snow in branch
'master':
bpo-36818: Add PyInterpreterState.runtime field. (gh-13129)
https://github.com/python/cpython/commit/396e0a8d9dc65453cb9d53500d0a62
Change by Eric Snow :
--
pull_requests: +13601
pull_request: https://github.com/python/cpython/pull/13714
___
Python tracker
<https://bugs.python.org/issue33
Change by Eric Snow :
--
resolution: rejected -> fixed
___
Python tracker
<https://bugs.python.org/issue36818>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Eric Snow :
In Python/lifecycle.c (Py_FinalizeEx) we call _Py_FinishPendingCalls(), right
after we stop all non-daemon Python threads but before we've actually started
finalizing the runtime state. That call looks for any remaining pending calls
(for the main interp
Eric Snow added the comment:
Also, someone did manage to investigate and identify a likely cause:
https://bugs.python.org/issue33608#msg342791
--
___
Python tracker
<https://bugs.python.org/issue37
Eric Snow added the comment:
That's really helpful, Pavel! Thanks for investigating so thoroughly. I'm
going to double check all the places I've made the assumption that "tstate"
isn't NULL and likewise for "tstate->interp".
Is there an issue o
Eric Snow added the comment:
I've made a few tweaks and Victor did some cleanup, so I'm going to try the PR
again. At first I'm also going to disable the _PyEval_FinishPendingCalls()
call in _Py_FinalizeEx() and then enable it is a separate PR.
Also, I've opened bpo-3
Eric Snow added the comment:
New changeset 6a150bcaeb190d1731b38ab9c7a5d1a352847ddc by Eric Snow in branch
'master':
bpo-33608: Factor out a private, per-interpreter _Py_AddPendingCall().
(gh-13714)
https://github.com/python/cpython/commit/6a150bcaeb190d1731b38ab9c7a5d1
Eric Snow added the comment:
So far so good. :) I'll keep an eye on things and if the buildbots are still
happy then I'll add back _PyEval_FinishPendingCalls() in _Py_FinalizeEx() in a
few days.
--
___
Python tracker
<https://bu
Eric Snow added the comment:
FYI, after merging that PR I realized that the COMPUTE_EVAL_BREAKER macro isn't
quite right. While the following scenario worked before, now it doesn't:
1. interpreter A: _PyEval_AddPendingCall() causes the global
eval breaker to be set
2. interpre
Eric Snow added the comment:
Please wait on reverting. I'm going to investigate.
@koobs, yeah, I'll send you a key. Thanks! :)
--
___
Python tracker
<https://bugs.python.o
Eric Snow added the comment:
FWIW, the failures before were in test_io and test_multiprocessing_spawn, not
test_asyncio.
--
___
Python tracker
<https://bugs.python.org/issue33
Eric Snow added the comment:
I had really hoped to get this in for 3.8, as I may need it. However,
realistically I doubt it will take just a few minutes to resolve this. With
the beta 1 targeted for today it makes sense to revert my change. :(
(I may still try to convince our fearless RM
Eric Snow added the comment:
Well, for this PR I actually disabled the execution of pending calls during
runtime finialization. I'd hoped it would help, but it did not. :(
Regardless, I'll need to look even more closely at what is different during
runtime finalization
Eric Snow added the comment:
Also, thanks for the suggestions, Victor!
--
___
Python tracker
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailin
New submission from Eric Wieser :
This behavior is pretty surprising:
```python
import ctypes
class Simple(ctypes.Structure):
_fields_ = [
('a', ctypes.c_uint8),
('b', ctypes.c_uint8),
]
class Bitfields(ctypes.Structure):
_fields_ = [
New submission from Eric Wieser :
Introduced in the fix to bpo-36504, GH-12660.
```python
>>> (ctypes.c_uint8 * 0 * 2)()
Fatal Python error: Floating point exception
>>> struct Empty(ctypes.Structure): _fields_ = []
>>> (Empty * 2)()
Fatal Python error: Floating poi
Change by Eric Wieser :
--
keywords: +patch
pull_requests: +13759
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13881
___
Python tracker
<https://bugs.python.org/issu
Change by Eric Wieser :
--
components: +ctypes
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue37187>
___
___
Python-bugs-list mai
Change by Eric Wieser :
--
components: +ctypes
___
Python tracker
<https://bugs.python.org/issue37188>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue10915>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
versions: +Python 3.8, Python 3.9 -Python 3.6
___
Python tracker
<https://bugs.python.org/issue15751>
___
___
Python-bugs-list mailin
Eric Snow added the comment:
The situation with subinterpreters and the gilstate API is a known problem (see
issues #10915 and #15751). We plan on fixing that in the near future for 3.9
(and probably for 3.8). Feel free to chime in on those earlier issues. Note
that the subinterpreter
Change by Eric Wieser :
--
pull_requests: +13779
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/13906
___
Python tracker
<https://bugs.python.org/issu
Change by Eric Snow :
Removed file: https://bugs.python.org/file48418/122.pdf
___
Python tracker
<https://bugs.python.org/issue12857>
___
___
Python-bugs-list mailin
Eric Snow added the comment:
FYI, I plan on looking into this either today or next Friday.
--
___
Python tracker
<https://bugs.python.org/issue34651>
___
___
Eric Snow added the comment:
(Sorry for the delay!)
Is the need for a named section due to the fact that _PyRuntime is part of the
"internal" C-API (hidden behind the Py_BUILD_CORE macro)? I.E. would it help
to build with Py_BUILD_CORE?
Regarding the GIL:
The plan for 3.9 is t
New submission from Eric Snow :
PEP 421 added sys.implementation for Python implementors to provide values
required by stdlib code (e.g. importlib). That PEP indicates that any new
required attributes must go through the PEP process. [1] That requirement
isn't obvious.
To fix th
1301 - 1400 of 6224 matches
Mail list logo
