Changes by Eric Snow :
--
priority: release blocker ->
stage: -> patch review
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs.python.org/i
Eric Snow added the comment:
I've moved this to 3.6. Small as the patch might be, there just isn't enough
urgency to warrant making use of an exception to get it into 3.5. If
__definition_order__ were still on the table then I'd probably stil
Eric Snow added the comment:
> Eric I realize that O (1) deletion is hard, and don't see a good way
> around it without changing the implementation ... I just think that the
> preserving the current C layout may be forcing an even more complicated
> solution than
Eric Snow added the comment:
I had a similar concern, Nick, but don't think I did anything that would have
broken the frame hiding logic. That said, I did not take stacklevel for
warnings into account.
--
nosy: +eric.snow
___
Python tracker
New submission from Eric Snow:
In issue #23911 I worked around a bug [1] in pkg_resources (setuptools) which
caused test_venv to fail when I split out importlib._bootstrap_external. That
bug has now been fixed so we just(?) need to update the version of pip we're
bundling and remove the
Eric Snow added the comment:
Would we be okay fixing this in 3.5 as well? I ask because I'm not familiar
with the constraints we have on what pip is bundled.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Eric Snow :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue24321>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Planning on committing today after I address some review comments.
--
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Eric Snow added the comment:
@Jim, I believe I've addressed all the review comments that have indicate a
risk. I've also answered basically all the rest. Thanks for the great review.
Unless there are any objections, I'll likely commit the patch in the ne
Changes by Eric Snow :
Added file: http://bugs.python.org/file39566/0813b1a88171.diff
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list m
Eric Snow added the comment:
Yep. :)
--
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
I'll keep an eye out for trouble on the buildbots.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> pending
___
Python tracker
<http://bugs.pyth
Eric Snow added the comment:
> PyObject_TypeCheck() should be used instead of PyObject_IsInstance() (see
> issue24257).
Thanks for pointing this out. I've fixed both dictobject.h and odictobject.h.
>
> Perhaps Py_ODict_GetItemId() should be private API as relevant dict func
Eric Snow added the comment:
> New changeset 0a7380984e37 by Eric Snow in branch '3.5':
> Issue #16991: Use PyObject_TypeCheck instead of PyObject_IsInstance.
> https://hg.python.org/cpython/rev/0a7380984e37
I've also merged this into defa
Eric Snow added the comment:
> I'm getting the following linker errors on Windows 8.1 for 32 and 64 bit
> debug and release builds. unresolved external symbol _PyODict_Type in
> C:\cpython\PCbuild\_collectionsmodule.obj, and _PyODictIter_Type,
> _PyODictValues_Type,
Eric Snow added the comment:
> You already added public name Py_ODict_GetItemId. It uses private
> _Py_Identifier API and shouldn't be public.
Ah. I'll remove it.
--
___
Python tracker
<http://bugs.py
Eric Snow added the comment:
If it's just a matter of adding the definitions then here's a patch. Does that
look correct?
--
Added file: http://bugs.python.org/file39567/odict-windows.diff
___
Python tracker
<http://bugs.python.o
Eric Snow added the comment:
That last message is about building on Windows.
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Eric Snow added the comment:
I'm checking a fix for Windows against a buildbot
(http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x).
--
___
Python tracker
<http://bugs.python.org/is
Changes by Eric Snow :
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric Snow added the comment:
Well, that last one has everything compiling again. I expect it should be okay
now. I'll watch the results.
--
___
Python tracker
<http://bugs.python.org/is
Eric Snow added the comment:
Changing the title back. :)
--
nosy: +eric.snow
title: coroutine wrapper recursion -> coroutine wrapper reentrancy
___
Python tracker
<http://bugs.python.org/issu
Eric Snow added the comment:
@Jim and Stefan, Thanks for thorough reviews!
@Stefan, I'll take a look at those crashers and other suggestions ASAP. I
really appreciate you taking the time. Now that the patch has been landed,
would you mind opening new issues for each problem you find?
Eric Snow added the comment:
@Skip, because roundup will change the title to the subject of the email and
the title had been changed after the message to which you replied.
--
___
Python tracker
<http://bugs.python.org/issue24
New submission from Eric Snow:
(from msg244574 in issue16991)
crash-1.py is due to an unchecked return value from _odictnode_VALUE().
We should probably use PyDict_GetItemWithError(), also in other
places.
I normally try to steer clear of stylistic remarks, but the
_odictnode* macros are
New submission from Eric Snow:
(from msg244575 in issue16991)
crash-2.py is due to the fact that _PyDict_Pop() deletes a reference
to 'key' in _odict_popkey().
The INCREF(key) in popitem should take place before calling _odict_popkey().
Again, I don't see the point of INCREF
New submission from Eric Snow:
(from msg244587 in issue16991)
Coverity has found an issue in odict, too:
*** CID 1302699: Null pointer dereferences (NULL_RETURNS)
/Objects/odictobject.c: 1316 in odict_copy()
1310 od_copy = PyObject_CallFunctionObjArgs((PyObject
*)Py_TYPE(od
Eric Snow added the comment:
I've opened the following issues to address the 3 last comments:
issue24347
issue24348
issue24349
I'll be opening a separate issue for outstanding review comments.
--
status: open -> closed
___
Python t
Eric Snow added the comment:
Regarding the macros, my intent was to limit leaking the details of the linked
list implementation and make it easier to change the linked list implementation
later. However, if that results in problems then I'm open to changing it.
What would you reco
Eric Snow added the comment:
Using PyDict_GetItemWithError() is a good idea. Also, raising KeyError when
the value is NULL (and no errors set) eliminates the crash. Here's a patch
that fixes the problem. Unless there are any objections, I'll commit it in a
couple hours.
--
Eric Snow added the comment:
Correct me if I'm wrong, but this is a duplicate of the bug Stefan reported in
issue24347.
--
resolution: -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder: -> unchecked return value
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Eric Snow :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Eric Snow:
Currently test_detect_deletion_during_iteration is disabled for the C
implementation of OrderedDict. The test needs to pass after being enabled.
--
assignee: eric.snow
components: Library (Lib)
messages: 244651
nosy: eric.snow
priority: release blocker
Changes by Eric Snow :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric Snow added the comment:
Addressing the concerns with resize()/get_index() is next on my list. I had
meant to open up an issue on it last night but it was getting pretty late for
me and it slipped my mind. I've opened issue24362 to track that
New submission from Eric Snow:
Between comments on issue16991 and review comments there, it's clear that the
implementation of _odict_resize and _odict_get_index in Objects/odictobject.c
are too complicated to be a long-term solution. simplifying the approach to
avoid recursion should
Eric Snow added the comment:
https://hg.python.org/cpython/rev/5c4ba50f6a57
I'll see if that does it.
@Larry, would you be opposed to dropping the hack for beta 3? That would mean
just deleting the last 2 lines in Lib/importlib/_bootstrap_extern
Eric Snow added the comment:
Yep. test_venv failures is how I found the problem in the first place.
--
___
Python tracker
<http://bugs.python.org/issue24
Eric Snow added the comment:
Here's a patch that adds stores the hash on each node. This eliminates the
need to call PyObject_Hash when rebuilding the fast nodes table during a
resize. The patch also drops a superfluous while loop.
--
keywords: +patch
stage: needs patch -&g
Eric Snow added the comment:
Hmm. Looks like the fix in setuptools/pkg_resources is 17.0. [1] The bundled
pip to which we just updated is 7.0.3, which appears to bundle pkg_resources
15.0. [2] So unless I've misunderstood, the hack will have to linger for a bit
longer.
Here's a
Eric Snow added the comment:
FYI, this doesn't crash when I have the patch from issue24362 applied.
--
assignee: -> eric.snow
___
Python tracker
<http://bugs.python.org
New submission from Eric Snow:
Several methods were implemented using PyArg_UnpackTuple and need to use
PyArg_ParseTupleAndKeywords instead.
--
assignee: eric.snow
components: Library (Lib)
messages: 244716
nosy: eric.snow
priority: release blocker
severity: normal
stage: needs patch
Eric Snow added the comment:
Here's a patch with tests.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file39601/issue24368-kwargs.diff
___
Python tracker
<http://bugs.python.org
New submission from Eric Snow:
While the dict/OrderedDict iterators already check for additions and deletions,
using the OrderedDict.move_to_end during iteration can lead to surprising
results.
The following results in an infinite loop:
od = OrderedDict.fromkeys('abc')
l
Eric Snow added the comment:
Sounds good. Thanks, Raymond.
--
___
Python tracker
<http://bugs.python.org/issue24369>
___
___
Python-bugs-list mailing list
Unsub
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Eric Snow:
How well does OrderedDict need to behave in the face of keys with unstable
hashes (e.g. define __hash__ with varying results across calls)? I would
expect the behavior to be undefined (though non-crashing). Here's an example
of a misbehaving key:
Eric Snow added the comment:
Thanks for pushing this, Stefan (and Jim). :)
--
resolution: -> fixed
type: -> behavior
___
Python tracker
<http://bugs.python.org/i
Eric Snow added the comment:
This has been fixed via issue24362.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Eric Snow:
It should be a one-line fix.
--
assignee: eric.snow
messages: 244775
nosy: eric.snow
priority: high
severity: normal
stage: needs patch
status: open
title: Refleak in OrderedDict.__repr__ when an item is not found.
type: behavior
versions: Python 3.5
Changes by Eric Snow :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric Snow added the comment:
Here's a patch that tracks changes to the C OrderedDict linked list, similar to
how it's done in deque. I've left the pure Python OrderedDict alone.
@Raymond, that state counter works great. :)
--
keywords: +patch
stage: test needed ->
Changes by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric Snow added the comment:
This has been fixed in issue24368. The fix came just after the beta 2 release.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Some C OrderedDict methods need to support keywo
Eric Snow added the comment:
I've left a review. That said, we need to be sure this behavior is
intentional. The fact that it skips the "nonlocal" scope(s) smells like a bug
to me.
--
nosy: +eric.snow
___
Python tracker
<http
Eric Snow added the comment:
I expect you'll get the same response, especially given potential (though
slight) chance for backward-compatibility issues. What I find curious is
Guido's reference to "the rule that class bodies don't play the nested
scopes game" (and h
Changes by Eric Snow :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue24508>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Note that the idea of replacing .pth files came up a couple years ago:
https://mail.python.org/pipermail/import-sig/2013-July/000645.html
That proposal didn't go anywhere basically because there were more important
things to wo
Eric Snow added the comment:
FYI, support for .pth has been around since at least Python 2.0. However,
support for imports in .pth files was added in 2.1:
changeset: 15815:868d2acf745808c9033f57cd5829d97a69ecf56e
branch: legacy-trunk
user:Martin v. Löwis
date:Thu Jan
New submission from Eric Snow:
We do very little testing of subinterpreters in CPython. About all I'm aware
of is in test_tracemalloc. I'll be working on improving test coverage as a
precursor to fixing some existing bugs.
--
components: Tests
messages: 246107
nosy:
Changes by Eric Snow :
--
nosy: +eric.snow
versions: +Python 3.5, Python 3.6 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue10915>
___
___
Python-bug
Changes by Eric Snow :
--
versions: +Python 3.6 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue15751>
___
___
Python-bugs-list mailing list
Unsub
Changes by Eric Snow :
--
nosy: +eric.snow
versions: +Python 3.5, Python 3.6 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue4202>
___
___
Python-bug
Changes by Eric Snow :
--
versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue6531>
___
___
Python-bug
New submission from Eric Snow:
Per A. Jesse Jiryu Davis:
===
# mod.py
class C(object):
pass
class Pool(object):
def __del__(self):
print('del')
list()
C.pool = Pool()
===
===
Eric Snow added the comment:
Sorry I didn't get a review in before. Since subinterpreters and multi-phase
initialization are on my mind, I have a couple questions:
Should there be a note in the "Single-phase initialization" section (perhaps at
the top of the section) that en
Eric Snow added the comment:
What is the level of impact of the callback problem? Of the 4 scenarios in
[1], it seems to me like #1 (C callbacks w/o a module reference) would be the
most common. However, can't that be addressed by adjusting the API, so it
would only be a big problem i
Eric Snow added the comment:
FTR, subinterpreters are already accessible during testing with
_testcapi.run_in_subinterp().
*
https://hg.python.org/cpython/file/09b223827f63/Modules/_testcapimodule.c#l2615
That function is used here:
* Lib/test/test_threading.py
* Lib/test/support.__init__
Eric Snow added the comment:
Also, I was mistaken about test_tracemalloc.
--
___
Python tracker
<http://bugs.python.org/issue24553>
___
___
Python-bugs-list mailin
Eric Snow added the comment:
Now I'm wondering what further test coverage we really need...
--
status: open -> pending
___
Python tracker
<http://bugs.python.org
Eric Snow added the comment:
I agree with Antoine.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue24597>
___
___
Python-bugs-list mailin
Eric Snow added the comment:
Just to get this out of the way, are you running your tests against the latest
beta (3)? There were some known bugs in earlier betas that have since been
fixed.
--
___
Python tracker
<http://bugs.python.org/issue24
Eric Snow added the comment:
Correct me if I'm wrong but the travis-ci logs [1] seem to indicate it's using
Python 3.6.0a0.
[1] https://travis-ci.org/xZise/pywikibot-core/builds/71550286#L144
--
___
Python tracker
<http://bu
Eric Snow added the comment:
Ah, sorry. I wasn't thinking past Python 3.5 (which is about to go to beta 4).
While 3.6.0a0, doesn't tell us much, d6c91b8242d2 (r96935) does. That
revision has all the necessary fixes to OrderedDict. I'll look into this some
more. Do you
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue24440>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Thanks for the extra info. I'm going to see if I can reproduce the issue by
running the pywikibot test suite locally. What's the best way to set that up?
Are there instructions somewhere?
As to the C implementation, it was first released (as a special
Eric Snow added the comment:
I've thus far been unsuccessful in running the pywikibot test suite. I'm
guessing there are some prerequisites (e.g. an account on some wiki site). Is
there a way to run the tests without network access? Also, I ran into some
trouble with i18n.__f
Eric Snow added the comment:
Thanks for the clear explanation, Raymond. The approach you've described is
useful in a number of circumstances. Would you mind publishing (somewhere
outside the tracker; devguide?) the specific steps you take and the tools you
use?
--
nosy: +eric
Eric Snow added the comment:
That worked. I'll take a close look at what's going on as soon as I can.
--
___
Python tracker
<http://bugs.python.o
New submission from Eric Snow:
(see issue24667)
collections.OrderedDict subclasses dict so calling dict's methods on an
OrderedDict works. However, neither the pure Python nor the C implementation
of OrderedDict was written to support doing so. In fact, both of them
currently ent
Eric Snow added the comment:
@Mark, note that you get the same behavior with the pure Python OrderedDict.
Calling dict.* methods on an OrderedDict gives you undefined behavior. I
expect the same is true for most subclasses of builtin types that override
builtin methods.
Anyway, the problem
Eric Snow added the comment:
Regarding this bug, it's clear now that the ordered keys and the underlying
dict are getting out of sync somewhere. This is either due to a bug in the C
OrderedDict implementation or the use of the concrete dict C-API (or dict.*
methods; thanks Mark).
Eric Snow added the comment:
Ah, you're right. I was hung up on issue10977. :)
--
___
Python tracker
<http://bugs.python.org/issue24721>
___
___
Pytho
Eric Snow added the comment:
Feel free to close this, Raymond.
--
___
Python tracker
<http://bugs.python.org/issue24721>
___
___
Python-bugs-list mailin
Eric Snow added the comment:
I've been able to pare down the tests that run to reproduce the bug. These 3
must run:
archivebot
interwiki_graph
l10n
Given how long the entire suite takes, this helps drastically improve my
iteration time while debugging. At this point I should be ab
Eric Snow added the comment:
This is most likely related to PEP 489, which changed extension module loading
in what was meant to be a backward-compatible way.
--
nosy: +brett.cannon, encukou, eric.snow, ncoghlan
versions: +Python 3.6
___
Python
Eric Snow added the comment:
It's starting to look like this is threading-related. There's a single
requests.Session defined as a module global in pywikibot.comms.http which is
shared by all threads handling requests. requests.Session uses OrderedDict for
an LRU cache for redirect
Eric Snow added the comment:
After some quick tests, it looks like during the tests only a single thread is
used, so it is *not* threading-related. That makes a bit more sense to me
given the consistency. Notwithstanding this development, I should be able to
isolate the problem soon (when I
Eric Snow added the comment:
You are correct that SystemError indicates a non-fatal issue in the interpreter
and thanks for reporting the matter. In this case I'd say that SystemError is
the wrong exception type. I expect that ImportError (or perhaps RuntimeError)
is more approp
Eric Snow added the comment:
Also, here is the output from running the pywikibot suite (using just the 3
test modules) with the logging odict wrapper.
--
Added file: http://bugs.python.org/file40069/odict.log
___
Python tracker
<h
Eric Snow added the comment:
Getting closer. Here's a reproducer derived from the calls made while running
the pywikibot test suite (3 tests only). Note that the KeyError indicates a
different key for each run, even though the code is consistent. This means
that order preservati
Eric Snow added the comment:
As expected (considering the link to dict ordering here), the inconsistent
results are tied to hash randomization:
$ for i in `seq 1 25`; do echo $i; PYTHONHASHSEED=$i ./python
/tmp/odict_reproduce.py; done
Changes by Eric Snow :
Added file: http://bugs.python.org/file40078/odict_reproduce.py
___
Python tracker
<http://bugs.python.org/issue24667>
___
___
Python-bugs-list m
Eric Snow added the comment:
For the reproducer I'm sticking with a seed of 1:
PYTHONHASHSEED=1 ./python /tmp/odict_reproduce.py
--
___
Python tracker
<http://bugs.python.org/is
Eric Snow added the comment:
I've verified that it is definitely the linked list that is getting updated
incorrectly at the point that a key is popped off. The underlying dict is
working fine. The erroneous behavior is happening with either pop, popitem, or
__delitem__. However,
Eric Snow added the comment:
It's looking like the problem is in _odict_add_new_node. If that's the case
then I should be able to resolve this issue soon.
--
___
Python tracker
<http://bugs.python.o
Eric Snow added the comment:
It turns out the problem was that the odict resize mechanism was not getting
triggered in all the cases that it should have been. dict resizes after a
certain number of insertions, whether or not previous deletions have cleared
out space. odict only resizes its
Changes by Eric Snow :
--
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue24667>
___
___
Python-bugs-list mailing list
Un
Changes by Eric Snow :
Added file: http://bugs.python.org/file40127/odict-correct-resize.diff
___
Python tracker
<http://bugs.python.org/issue24667>
___
___
Python-bug
2301 - 2400 of 2629 matches
Mail list logo
