Eric Snow added the comment:
Okay, apparently this is only happening on 2 of the buildbots from bpo-33615:
ARMv7 Ubuntu 3.x
PPC64 AIX 3.x
Judging by the failures I'm guessing that it's something related to handling of
int64_t. I'm looking into it.
--
assignee
Eric Snow added the comment:
I'm pretty sure at this point that the failures are due to using a %d format
string for int64_t instead of %lld. I'll have a PR up shortly.
--
___
Python tracker
<https://bugs.python.o
Change by Eric Snow :
--
keywords: +patch
pull_requests: +6959
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33724>
___
___
Python-
Change by Eric Snow :
--
pull_requests: +6960
___
Python tracker
<https://bugs.python.org/issue32604>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
New changeset 6854e803b73ac4d02ba160d514b8a53dd7a62905 by Eric Snow in branch
'master':
bpo-33724: Use the right format code for int64_t in subinterpreters code.
(gh-7330)
https://github.com/python/cpython/commit/6854e803b73ac4d02ba160d514b8a5
Eric Snow added the comment:
The fix took care of the failures.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Eric Snow added the comment:
New changeset 63799136e6c0491bb5d6f4a234d5a775db3458db by Eric Snow in branch
'master':
bpo-33615: Re-enable a subinterpreter test. (gh-7251)
https://github.com/python/cpython/commit/63799136e6c0491bb5d6f4a234d5a7
Eric Snow added the comment:
New changeset 63799136e6c0491bb5d6f4a234d5a775db3458db by Eric Snow in branch
'master':
bpo-33615: Re-enable a subinterpreter test. (gh-7251)
https://github.com/python/cpython/commit/63799136e6c0491bb5d6f4a234d5a7
Change by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> pending
___
Python tracker
<https://bugs.python.or
Eric Snow added the comment:
This appears to be recurring on the "x86 Gentoo Refleaks 3.x" builder still. I
was thrown off by the success of the first run after I landed my fix:
http://buildbot.python.org/all/#/builders/1/builds/241
FYI, the other buildbots having this issue b
Eric Snow added the comment:
Sorry for any confusion. This issue is still resolved. It is bpo-33615 that
had an unexpected recurrence. I've re-opened that one.
--
resolution: -> fixed
status: open -> closed
___
Python trac
Eric Snow added the comment:
FTR, the issue of ABI breakage has come up quite a few times on the mailing
list. Most recently:
https://mail.python.org/pipermail/python-dev/2018-June/153775.html
--
___
Python tracker
<https://bugs.python.
Eric Snow added the comment:
That email thread contains multiple references to scripts that may be used to
identify ABI issues, among other good points. FWIW, when consolidating the C
globals last year I added a tool to track the remaining globals:
Tools/c-globals
It is similar (at
Eric Snow added the comment:
I'll definitely take a look. It might not be until Friday though.
--
___
Python tracker
<https://bugs.python.org/is
Eric Snow added the comment:
FTR, bpo-33724 is related
--
___
Python tracker
<https://bugs.python.org/issue33615>
___
___
Python-bugs-list mailing list
Unsub
Change by Eric Snow :
--
pull_requests: +7038
___
Python tracker
<https://bugs.python.org/issue17045>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
I found some time to at least get the patch to apply cleanly to master and to
make a PR. :)
--
___
Python tracker
<https://bugs.python.org/issue17
Eric Snow added the comment:
@Christian, you can use the "blurb" tool to create the NEWS entry. You can use
pip to install it. See:
https://devguide.python.org/committing/?highlight=blurb#what-s-new-and-news-entries
--
nosy:
Eric Snow added the comment:
Yeah, I did a custom build the other day. Sorry about the delay in disabling
the test again and thanks for getting it done.
--
___
Python tracker
<https://bugs.python.org/issue33
Change by Eric Snow :
--
pull_requests: +7184
___
Python tracker
<https://bugs.python.org/issue33615>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
New changeset ab4a1988fd4347484a7928394b94e2cdf5f8f2a7 by Eric Snow in branch
'master':
bpo-33615: Re-enable subinterpreter tests. (#7552)
https://github.com/python/cpython/commit/ab4a1988fd4347484a7928394b94e2
Eric Snow added the comment:
I've re-enabled the subinterpreter tests, but left the one problem test
(ChannelTests.test_run_string_arg_resolved) disabled. I also changed all uses
of %lld to use PRId64 instead. (Thanks, Victor, for the suggestion.)
The buildbots look good. I'
Eric Snow added the comment:
@Cheryl, thanks for pointing that out. I'll take a look.
--
___
Python tracker
<https://bugs.python.org/issue17045>
___
___
Eric Snow added the comment:
Thanks for bringing this up, Hristo!
"Initialization" (in this context, and hopefully everywhere in the C-API docs)
is referring specifically to setting fields on a custom instance, much as you
would expect in __init__ (or sometimes even __new__)
Eric Snow added the comment:
As to the docs, the entry for tp_alloc in Doc/c-api/typeobj.rst does not
mention initialization. The tp_new entry does say that it should call tp_alloc
and then do the minimum initialization possible. That implies (weakly) that
tp_alloc should do the minimum
Eric Snow added the comment:
Would it be possible to re-use the __reverse__() support that exists for
OrderedDict? Doing so could help avoid adding a bunch of duplicated code.
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.
Change by Eric Snow :
--
status: pending -> closed
___
Python tracker
<https://bugs.python.org/issue33615>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric Snow added the comment:
New changeset 9e7c92193cc98fd3c2d4751c87851460a33b9118 by Eric Snow in branch
'master':
bpo-17045: Improve C-API doc for PyTypeObject. (gh-7413)
https://github.com/python/cpython/commit/9e7c92193cc98fd3c2d4751c878514
Change by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Eric Snow added the comment:
Note that bpo-32604 is strongly related.
--
___
Python tracker
<https://bugs.python.org/issue24553>
___
___
Python-bugs-list mailin
Eric Snow added the comment:
Also see #24553.
--
___
Python tracker
<https://bugs.python.org/issue32604>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
I'll take a look.
--
___
Python tracker
<https://bugs.python.org/issue33868>
___
___
Python-bugs-list mailing list
Unsubscr
Change by Eric Snow :
--
nosy: +emilyemorehouse
___
Python tracker
<https://bugs.python.org/issue33868>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
nosy: +emilyemorehouse
___
Python tracker
<https://bugs.python.org/issue33607>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
nosy: +emilyemorehouse
___
Python tracker
<https://bugs.python.org/issue33608>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue31558>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
nosy: +emilyemorehouse, eric.snow
___
Python tracker
<https://bugs.python.org/issue33919>
___
___
Python-bugs-list mailing list
Unsub
Eric Snow added the comment:
> I looked quickly at _Py_InitializeCore() and I'm not sure
> that it's designed to replace an existing configuration.
> ...
> So maybe for this specific case, _Py_InitializeCore() should
> always set Py_HashRandomizationFlag.
+1
At the
Eric Snow added the comment:
@barry, make sure you take a look at https://bugs.python.org/issue14803.
--
___
Python tracker
<https://bugs.python.org/issue33
Change by Eric Snow :
--
nosy: +emilyemorehouse, eric.snow
___
Python tracker
<https://bugs.python.org/issue16822>
___
___
Python-bugs-list mailing list
Unsub
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue34099>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue34206>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
nosy: +emilyemorehouse
___
Python tracker
<https://bugs.python.org/issue34206>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
The matter of unloading extension modules is partly covered in bpo-401713.
However, note that a few things have changed in the last 18 years. :) I think
it would be worth revisiting the decision in that issue at this point.
If that were sorted out would there
Eric Snow added the comment:
Regarding your 3 points:
> a) Py_Finalize cannot be used reliably
Note that unloading extension modules is not the only thing that Py_Finalize
isn't doing that it probably should be. I expect that you would find a number
of memory leaks and potential
Eric Snow added the comment:
Ah, thanks for clarifying. So which of these is the main thing you really want:
1. reload extension modules
2. completely restart Python
It sounds like #1. If that's the case then there are a number of issues to
resolve to make it work. However, ther
Eric Snow added the comment:
Also, part of the motivation for PEP 489 (extension module initialization) was
to help with reloading extension modules.
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue34
Eric Snow added the comment:
Also, PEP 3121 provides a good summary of some of the issues at hand.
--
___
Python tracker
<https://bugs.python.org/issue34
Eric Snow added the comment:
@chris, I can't promise that anything will happen right away, but I'll be sure
to look into this further when I work on improving extension module usage in
subinterpreters in the next few months.
--
___
Pyth
Eric Snow added the comment:
I've changed the issue title to reflect where things stand.
Hmm, doing so reminded me of an important consideration here. A module object
is effectively a fairly light wrapper around a dict. When you call
importlib.reload() the loader from the module'
Eric Snow added the comment:
FWIW, the C implementation of Task.__init__ is not exactly equivalent to the
Python implementation (nor to both the C and Python implementation of
Task.set_name). In the C impl of Task.__init__ the provided name is used as-is
if it's an instance o
Eric Snow added the comment:
I'm not sure that this is a duplicate of #5322. That one's about a warning
when arguments are passed to object.__new__(). Yours is about using an
incompatible __new__ when creating a new class in Python. I agree that
behavior you're seeing is
Eric Snow added the comment:
I'm not too invested in any changes happening at this point, actually. :)
Mostly I happened to be reading through the commit and noticed the
inconsistency. If I had reviewed the PR then I would have asked that it be
fixed. So I figured I'd mention
New submission from Eric Snow :
In the 3.5 "What's New" doc, the porting section [1] does not mention the
bytecode changes resulting from the PEP 448 implementation. [2][3] It should.
I've marked this issue for the versions past 3.5 because each branch has its
own &quo
Eric Snow added the comment:
FTR, the change was introduced by the PEP 448 implementation. [1]
[1] https://github.com/python/cpython/pull/8338#issuecomment-406256152
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue33
Eric Snow added the comment:
FYI, I opened bpo-34413 to address how the bytecode change is not mentioned in
the porting section of the 3.5 "What's New" doc. In retrospect (I didn't
notice that this issue was still open), I suppose that doesn't need a separate
is
Eric Snow added the comment:
There are several issues at hand here, Phillip. I'll enumerate them below.
Thanks for taking the time to let us know about this. However, I'm closing
this issue since realistically the behavior of imp.find_module() isn't going to
change, particu
Eric Snow added the comment:
Fair enough. Having the note in the 3.5 docs should be fine. :)
--
resolution: -> rejected
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Eric Snow :
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue6531>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric Snow added the comment:
Thanks for the proposal. At first glance I actually kind of like the idea,
though I can't offer much more feedback than that without taking some time to
think it through. :)
That said, proposals like this for new syntax and other new language features
are
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue4921>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Thanks for bringing this up, Michael. I'll give you a review on the PR
sometime this week (while at the core sprint).
--
___
Python tracker
<https://bugs.python.org/is
Change by Eric Snow :
--
nosy: +eric.snow, vstinner
___
Python tracker
<https://bugs.python.org/issue34579>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Snow :
os.fork() potentially has some problematic behavior when called from a
subinterpreter. In additional to the normal fork+threads madness, there's the
question of what to do with existing subinterpreters. The simplest solution is
to simply disallow fork
Change by Eric Snow :
--
keywords: +patch
pull_requests: +8710
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue34651>
___
_
Eric Snow added the comment:
New changeset 5903296045b586b9cd1fce0b1e02caf896028d1d by Eric Snow in branch
'master':
bpo-34651: Only allow the main interpreter to fork. (gh-9279)
https://github.com/python/cpython/commit/5903296045b586b9cd1fce0b1e02ca
Change by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue34690>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
keywords: +patch
pull_requests: +8758
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue33608>
___
_
Eric Snow added the comment:
@Neil, we're definitely on the same page. In fact, in a world where
subinterpreters do not share a GIL, we can't ever use an object in one
interpreter that was created in another (due to thread safety on refcounts).
The role of "tightly contr
Eric Snow added the comment:
Also see PEP 432 ("Restructuring the CPython startup sequence"), which is still
in the process of fine-tuning.
--
nosy: +eric.snow, ncoghlan, vstinner
___
Python tracker
<https://bugs.python.o
Change by Eric Snow :
--
nosy: +benjamin.peterson
___
Python tracker
<https://bugs.python.org/issue34722>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
FWIW, the PEP 520 example isn't exactly right. PEP 520 is about the class
definition namespace, not the namespace object passed to type(). That always
does the right thing, since the default class definition namespace is dict
(which happens to be order
Change by Eric Snow :
--
Removed message: https://bugs.python.org/msg325897
___
Python tracker
<https://bugs.python.org/issue34320>
___
___
Python-bugs-list m
Eric Snow added the comment:
FWIW, the PEP 520 example isn't exactly right. PEP 520 is about the class
definition namespace, not the namespace object passed to type(). That always
does the right thing, since the default class definition namespace is dict
(which happens to be order
Eric Snow added the comment:
> one of the things we want to fix is to eliminate non-PyObject
> pointer types from public APIs entirely.
A notable exception is Py_buffer. [1] As well, cross-interpreter data must not
be PyObject, though that isn't much of an issue (yet). :) At so
Eric Snow added the comment:
As Serhiy said, this is the correct behavior. Nearly all builtin operations
are made using the appropriate "dunder" method from the object's type (not
looked up on the object itself). So the following (based on your example) are
equivalent:
Eric Snow added the comment:
There is a conversion. See builtin___build_class__ in Python/bltinmodule.c
(and the LOAD_BUILD_CLASS target in Python/ceval.c). Specifically, the
metaclass (e.g. the builtin type) is instantiated using the namespace from the
class definition. The metaclass
Eric Snow added the comment:
> Conversion is happens when type() (or metaclass()) is called.
Right. So an extra test to cover the __prepare__ case is somewhat redundant.
I only suggested it because type() is called implicitly and the test would make
the conversion case clear. However,
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue26558>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue35081>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue35059>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue17449>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Without too many optimzations, the C implementation of OrderedDict is basically
between 1x and 4x the performance of raw dict. This contrasts with the pure
Python OrderedDict, which falls in roughly between 4x and 100x.
I've attached an addition to pybench
Changes by Eric Snow :
Removed file: http://bugs.python.org/file30357/cOrderedDict.diff
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list m
Eric Snow added the comment:
Here's an updated patch that has fixes for recursive pickles and for a couple
memory-related segfaults that I missed before. That leaves the following to be
done:
* handle the case where a node is deleted during iteration
* check for any reference cycles (s
Eric Snow added the comment:
Here's one solution to the deletion-during-iteration problem. It makes the
iterators track the key rather than the node, at the expense of a sliver of
speed on __iter__() and keys().
--
Added file: http://bugs.python.org/file30467/cOrderedDict-iter
Eric Snow added the comment:
The concern about reference cycles here lies in their existence in the
linked-list. To see what I mean, check out the use of weakrefs in the pure
Python implementation at Lib/collections/__init__.py. As the current
implementation does not use PyObjects for the
Changes by Eric Snow :
Removed file:
http://bugs.python.org/file30467/cOrderedDict-iterators-by-key.diff
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Changes by Eric Snow :
Removed file: http://bugs.python.org/file30462/cOrderedDict.diff
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list m
Eric Snow added the comment:
Here's what I feel is a nearly complete patch. The only outstanding issues
that I feel need to be answered are 4 spots where calls into the interpreter
may result in unexpected changes to the object or make the current function
state out-of-dat
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue7796>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
It may not enough, but the use of namedtuples (vs. plain tuples) with
functools.singledispatch() would be messier without a NamedTuple ABC (or other
base type). Of course, when would you want to dispatch specifically on
namedtuple? I can think of a few
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue17963>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14303>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
It's for times like this that I wonder if a simple serialization protocol might
be worth it--something separate from __str__() but much simpler than the pickle
protocol. __str__() could be the fallback. In the end, though, I always
conclude that it's
Eric Snow added the comment:
> Serialization isn't the only issue - you have to know how
> to deserialize as well.
+1
> (TBH, I wish the json module had better hooks for extending
> both serialization and deserialization of non-basic types.)
+1
There's at least one s
Eric Snow added the comment:
I figured out what I hope were the last memory-related issues. Apparently
tp_traverse is not inherited if tp_flags is set. I had it set on all the view
types and all the iterator types. So during GC it would blow up when it tried
to call tp_traverse
Changes by Eric Snow :
Removed file: http://bugs.python.org/file30468/cOrderedDict.diff
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list m
Eric Snow added the comment:
For the record, issue12633 has some more discussion on this.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue17
1201 - 1300 of 2629 matches
Mail list logo
