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
New submission from Eric Wieser :
PEP 442 states that:
> Two new C API functions are provided to ease calling of tp_finalize,
> especially from custom deallocators.
But it does not give the names of these functions, nor do any python docs I can
discover.
>From grepping for tp_fin
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
Eric Wieser added the comment:
Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing.
PEP3118 as a protocol is far less useful if the canonical implementation is
non-compliant.
--
___
Python tracker
<ht
Eric Wieser added the comment:
Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing.
Ideally this and https://bugs.python.org/issue32780 would make the same patch
release.
--
___
Python tracker
<https://bugs.python.
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue34099>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Janson :
Hitting next from 16.10 in standard library online docs jumps to 16.12.
Previous goes from 16.12 back to 16.10. Curses.Textpad(16.11) must be
random-accessed.
--
assignee: docs@python
components: Documentation
messages: 322002
nosy: Eric Janson
Eric Wieser added the comment:
> It should be fairly simple to modify the code to use a format of "B"
> for unions, so that it at least matches the itemsize
Seems reasonable, although:
* I think it should be "B" or "()B"
* I'd rather leave that for
Eric Wieser added the comment:
> I get the following results for builtin objects that have defined subclasses
>From that list, the only unhelpful ones with > 4 items, in my opinion, appear
>to be `object`, since that just tells you every type that exists, and `tuple`,
>bec
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:
New submission from Eric Martin :
After entering a line number, clicking OK brings to the foreground and makes
active the first hidden window (in the simplest case where we have just one
window for a .py file and the Shell window, the former being in the foreground,
clicking OK brings the
Eric Wieser added the comment:
This now leaves `inspect.getsource` inconsistent with `inspect.getsourcefile`:
>>> import inspect
>>> from contextlib import contextmanager
>>> @contextmanager
... def func():
...yield
>>> inspect.getsource(func)
'
New submission from Eric Wieser :
Following on from https://bugs.python.org/issue1764286 - inspect.getsourcefile
and inspect.getcomments fall afoul of the same problem.
--
components: Library (Lib)
messages: 322847
nosy: Eric.Wieser
priority: normal
severity: normal
status: open
title
Change by Eric Wieser :
--
nosy: +yselivanov
___
Python tracker
<https://bugs.python.org/issue34305>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Wieser :
--
keywords: +patch
pull_requests: +8108
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34305>
___
___
Py
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 Wieser added the comment:
New issue opened at https://bugs.python.org/issue34305, along with a PR linked
there.
--
___
Python tracker
<https://bugs.python.org/issue1764
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 Fahlgren added the comment:
I believe that the CL command line switch is /FC, not /FP:
https://msdn.microsoft.com/en-us/library/027c4t2s.aspx
--
nosy: +eric.fahlgren
___
Python tracker
<https://bugs.python.org/issue34
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
Change by Eric Wieser :
--
nosy: +Eric.Wieser
___
Python tracker
<https://bugs.python.org/issue34494>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Wieser added the comment:
What I think I find surprising is that I'd expect the sequence protocol to be
defined by `__getitem__` and `__len__`, and for `__iter__` to be inferred as:
def __iter__(self):
for i in range(len(self)):
yield self[i]
But in reali
New submission from Eric Lippert :
In _PyFunction_FastCallDict we have local nk assigned to be the size of a
dictionary, and then local i is assigned to twice the size of the same
dictionary, and then nk is assigned to half of i, which it already is:
nk = (kwargs != NULL
Change by Eric Lippert :
--
keywords: +patch
pull_requests: +8479
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34551>
___
___
Py
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
Eric Lippert added the comment:
If it were possible that the interpreter iterating over a dictionary could
cause the dictionary to change size then I suspect that this would be a rich
source of bugs to mine. :-)
It would be great if we could make it a documented, enforced invariant that
Eric Wieser added the comment:
Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing.
--
___
Python tracker
<https://bugs.python.org/issue34
Eric Wieser added the comment:
Pinging again, for lack of a clearer path forward
--
___
Python tracker
<https://bugs.python.org/issue32782>
___
___
Python-bug
Eric Atkin added the comment:
It seems the note at the bottom for `object.__hash__(self)` [1] should be
updated as well.
[1] https://docs.python.org/3/reference/datamodel.html#object.__hash__
--
nosy: +Eric Atkin
___
Python tracker
<ht
Eric Wieser added the comment:
For anyone doing archaeology - this came up on python-dev about a year after
this issue was filed:
https://mail.python.org/pipermail/python-dev/2009-December/094439.html
--
___
Python tracker
<ht
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,
New submission from Eric Lindblad :
The development version code can set the variable EXTERNALS_DIR in two .bat
files, but nowhere in a .bat file is set the variable EXTERNAL_DIR, the latter
appearing in find_python.bat. I am not a Powershell user and so cannot
interpret the content of the
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:
Eric Wieser added the comment:
> then we should perhaps instead consider the rewrite for 3.6: provide a *new*
> distutils function that does use Popen and does things "right" (based on
> everything we've learned since distutils was written), leaving the old
> fu
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue17449>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Wieser:
This code:
class Sudoku(dict):
COLUMNS = [
{(x, y) for y in xrange(9)} for x in xrange(9)
]
When run on Python 2.7.5, fails with this traceback:
Traceback (most recent call last):
File "", line 1, in
Changes by Eric Wieser :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue18110>
___
___
Python-bugs-list mailing list
Unsubscri
Eric Wieser added the comment:
This is not at first glance, a duplicate of 3692 - in that case, the list
comprehension is referring to another class variable.
Most notably, that describes a behavioural change introduced by python 3 - in
this case, python 3 handles it correctly - there's
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
Eric Wieser added the comment:
Thanks for the clarification - this behavior now makes perfect sense to me. As
expected, swapping the list comprehension for a generator comprehension, or
vice versa, prevents the error.
--
___
Python tracker
<h
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
1901 - 2000 of 6382 matches
Mail list logo
