Eric Frederich added the comment:
Attached, as inj3.py, is a version I made which seems to work with Python2 but
not with Python3's C implementation of OrderedDict.
I had to walk the MRO myself to get the unbound method to pass along as
dict_setitem.
With Python3 it doesn't look
Eric Frederich added the comment:
I understand that in the general case you cannot just swap the order around and
get the same behaviour.
This LoggingDict just prints some stuff to the screen and delegates to super
and so I believe it should work wherever it is placed in a cooperative
Eric Frederich added the comment:
Éric (Araujo),
Combinding defaultdict and OrderedDict is a little easier since one of them
(defaultdict) has special behavior on getitem while the other (OrderedDict) has
special behavior on setitem.
I played with mixing those two myself and saw some issues
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
New submission from Eric S:
Documentation states:
Element.findall() finds only elements with a tag which are direct children of
the current element.
More accurate to say "direct descendents" as "direct children" implies only one
generation below whereas function goes down
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 S added the comment:
Pointing to XPath and clarifying the example reference are good ideas.
For me though, the phrase "direct children" would still lead me to believe that
findall() would only give me the first generation right below the element (e.g.
only the countries in t
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 S added the comment:
To my preference, the drop-in is verbose and I got a little confused on first
read. The current documentation and example seem mostly OK to me.
If we leave "children" as in "all children of *root*", it doesn't
illuminate the fact that
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 S added the comment:
Code was intended as example, not request for help to correct, but rushed so
example was flawed, but still, I tested and you both are right. Must've had
other error in code to cause the xml to dict to have every element map to under
every node. Debugger also s
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
Changes by Eric Snow :
Removed file: http://bugs.python.org/file40126/odict-correct-resize.diff
___
Python tracker
<http://bugs.python.org/issue24667>
___
___
Python-bug
Changes by Eric Snow :
--
nosy: +brett.cannon, eric.snow, gregory.p.smith, ncoghlan, superluser, twouters
___
Python tracker
<http://bugs.python.org/issue24
Changes by Eric Snow :
--
nosy: +gregory.p.smith, superluser, twouters
___
Python tracker
<http://bugs.python.org/issue19699>
___
___
Python-bugs-list mailin
Changes by Eric Snow :
--
nosy: +brett.cannon, eric.snow, ncoghlan, superluser
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue23
Changes by Eric Snow :
--
versions: +Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue24792>
___
___
Python-bugs-list mailing list
Unsub
Changes by Eric Snow :
--
nosy: +eric.snow, superluser
___
Python tracker
<http://bugs.python.org/issue23327>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +superluser
versions: +Python 3.6 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue5950>
___
___
Python-bugs-list mailin
Changes by Eric Snow :
--
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue19883>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue19699>
___
___
Python-bugs-list mailing list
Unsub
Changes by Eric Snow :
--
nosy: +eric.snow, superluser
___
Python tracker
<http://bugs.python.org/issue19883>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
type: crash -> behavior
versions: +Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue23327>
___
___
Python-
Changes by Eric Snow :
--
nosy: +superluser
___
Python tracker
<http://bugs.python.org/issue21062>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +gregory.p.smith, superluser
versions: +Python 3.6 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue17004>
___
___
Pytho
Changes by Eric Snow :
--
nosy: +gregory.p.smith, superluser
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue1116520>
___
___
Changes by Eric Snow :
--
nosy: +superluser
versions: +Python 3.6 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue19081>
___
___
Python-bugs-list m
Changes by Eric Snow :
--
nosy: +superluser
versions: +Python 3.6 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue14678>
___
___
Python-bugs-list m
Changes by Eric Snow :
--
nosy: +superluser
versions: +Python 3.6 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue16651>
___
___
Python-bugs-list m
Changes by Eric Snow :
--
nosy: +brett.cannon, gregory.p.smith, superluser
stage: -> patch review
versions: +Python 3.6 -Python 3.4
___
Python tracker
<http://bugs.python.org/issu
Changes by Eric Snow :
--
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue8400>
___
___
Python-bug
Changes by Eric Snow :
--
nosy: +brett.cannon, gregory.p.smith, superluser
___
Python tracker
<http://bugs.python.org/issue8400>
___
___
Python-bugs-list mailin
Changes by Eric Snow :
--
stage: -> patch review
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue17633>
___
___
Python-bugs-list
Changes by Eric Snow :
--
nosy: +superluser
versions: +Python 3.6 -Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue14905>
___
___
Python-bug
Changes by Eric Snow :
--
nosy: +gregory.p.smith, superluser
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue17633>
___
___
Pytho
Changes by Eric Snow :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue14905>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Fair enough.
--
resolution: -> not a bug
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric Snow added the comment:
@Fabian, hey, thanks for bringing it to our attention!
--
___
Python tracker
<http://bugs.python.org/issue24667>
___
___
Python-bug
Eric Snow added the comment:
If I don't get any feedback before then, I'll commit the patch on Friday.
--
___
Python tracker
<http://bugs.python.o
Eric Snow added the comment:
That's good to know. Thanks.
--
___
Python tracker
<http://bugs.python.org/issue24667>
___
___
Python-bugs-list mailing list
Eric Snow added the comment:
I've pushed the fix for RC1. Thanks again Fabian for bringing it to our
attention.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Eric Snow added the comment:
> Yeah, I stopped it at 300k iterations. No problems. Glad this fix got
in for rc1.
Thanks for the double-check, Larry. I'd done similar testing, though not
as exhaustively. :) Getting a fix in for RC1 was pretty important to me.
It stretched me a bit, b
Eric Snow added the comment:
patch LGTM. Presumably the divergence between importlib (in _handle_fromlist)
and import.c was strictly accidental (i.e. lack of test coverage).
--
stage: patch review -> commit review
___
Python tracker
&l
Eric Snow added the comment:
Looks fine to me. Nick had suggested calling exec_builtin from exec_dynamic
(to the same effect as your patch), but I don't consider that much of an issue.
:)
--
stage: -> commit review
___
Python tracke
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue24846>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
This sort of thread belongs on python-id...@python.org, not on the tracker.
Please post there (feel free to reference this issue; also add a link to the
thread here). TBH, I think there's a larger discussion to be had regarding the
topic of other u
Eric Snow added the comment:
That said...
What's the benefit of it being a decorator? The docstring? Access to
func.__name__? It could just as well be:
class attribute:
_name = None
def __get__(self, instance, owner):
if instance is
Eric Snow added the comment:
No worries, Emanuel. Thanks for bringing it up. I'd still be interested to
see what sort discussion ensued if you took this to python-ideas. Starting a
thread on the topic has been on my todo list for a while but other matters
always end up taking prece
Eric Snow added the comment:
"Hybrid Nathaniel/Brett approach" LGTM
--
___
Python tracker
<http://bugs.python.org/issue24305>
___
___
Python-bugs-l
Eric Snow added the comment:
I've posted a counter-proposal on python-ideas:
https://mail.python.org/pipermail/python-ideas/2015-August/035614.html
Basically: instead of "classproperty", add a more lenient alternative to
classmethod which allows composition. I called it
Eric Snow added the comment:
I also posted a broader proposal:
https://mail.python.org/pipermail/python-ideas/2015-August/035615.html
--
___
Python tracker
<http://bugs.python.org/issue24
Eric Snow added the comment:
Doesn't the fix mean that `vars(MyNamedtuple)` will no longer work? While I
personally don't mind (though I prefer that spelling) and appreciate the
benefit of simpler code, isn't there a backward-compatibility issue here?
I do concede that
Changes by Eric Fried :
--
nosy: +2uasimojo
___
Python tracker
<http://bugs.python.org/issue24980>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Thanks for taking care of this, Victor (and Serhiy). :)
--
stage: -> resolved
type: -> behavior
___
Python tracker
<http://bugs.python.org/i
Eric Snow added the comment:
Yeah, this definitely relates to the project I'm working on.
--
___
Python tracker
<http://bugs.python.org/issue24991>
___
___
Eric Snow added the comment:
While I recognize the practicality/purity argument here, I somewhat agree with
Mark. Assigning to module.__class__ makes sense for the use case, but it does
open up a number of negative possible side effects (e.g. changing
sys.__class__). Ideally it would be
Eric Snow added the comment:
OrderedDict has a C implementation now. So try the following:
try:
from _collections import OrderedDict
except ImportError:
from collections import OrderedDict
--
nosy: +eric.snow
___
Python tracker
<h
Eric Snow added the comment:
I'm fairly sure this was just an oversight on my part.
--
___
Python tracker
<http://bugs.python.org/issue25186>
___
___
Pytho
New submission from Eric Snow:
(a generalization of issue #21335)
One way or another, we should be able to record the appropriate path in the
resulting data when a module is frozen. Keeping track of the source location
is useful when debugging, especially with tracebacks. Also see a related
Eric Snow added the comment:
The underlying issue extends to all frozen modules. I've opened #25268 to
consider how we might address it.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/is
Changes by Eric Snow :
--
nosy: +lemburg
___
Python tracker
<http://bugs.python.org/issue25268>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue12238>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
assignee: -> serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue25406>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric Snow added the comment:
@Serhiy, patch LGTM. Thanks for taking care of it.
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issu
Eric Snow added the comment:
Thanks for working on this, Serhiy. I've left a review.
As to the points you outlined, I have concerns with the impact of #3 and #5 on
subclasses. Notably od.__class__ is not necessarily the same as type(od).
Also #7 may introduce an unhandled re-ent
Eric Snow added the comment:
Regarding Py_TYPE(od) vs. od.__class__, there is a difference for subclasses,
as you demonstrated in your example. [1] Thanks for explaining your rationale.
I now understand your argument about using PyTYPE() for repr and pickle in C
types. I still have
Eric Snow added the comment:
Regarding #5, you're right about OrderedDict().__dict__ being empty for the C
implementation. (Nice observation!) So I'm okay with ripping all that code
out of odict_reduce(). Since we're still accessing od.__dict__ through
_PyObject_GetAttrId()
Eric Snow added the comment:
Regarding #7, I see what you did now. That looks fine to me.
--
___
Python tracker
<http://bugs.python.org/issue25410>
___
___
Pytho
Eric Snow added the comment:
new patch LGTM
--
___
Python tracker
<http://bugs.python.org/issue25410>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
> Backward compatibility related to __class__ assignment was already broken in C
> implementation. In 3.4 following code works:
[snip]
> In 3.5 it doesn't.
Depending on what feedback we get from python-dev, that may need to be
fixed. I'd be in
Eric Snow added the comment:
Posted to python-dev:
https://mail.python.org/pipermail/python-dev/2015-October/141953.html
https://mail.python.org/pipermail/python-dev/2015-October/141954.html
--
stage: patch review -> commit review
___
Pyt
Eric Snow added the comment:
both patches* LGTM
* odict_type.patch and odict_add_new_node_leak.patch
--
___
Python tracker
<http://bugs.python.org/issue25
Eric Snow added the comment:
And thanks again, Serhiy, for taking the time on this. :)
--
___
Python tracker
<http://bugs.python.org/issue25410>
___
___
Python-bug
Eric Snow added the comment:
Thanks for solving this!
odict-trashcan.v3.patch LGTM
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issu
Eric Snow added the comment:
Since the python-dev discussion about __class__, leaving the Python
implementation alone is fine with me.
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issu
Eric Snow added the comment:
LGTM as long as you also add PurePythonOrderedDictSubclassTests to match
CPythonOrderedDictSubclassTests (per PEP 399).
--
nosy: +eric.snow
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issu
Eric Snow added the comment:
Regarding dict.__setitem__, see issue #24726. Raymond outlined what needs to
be fixed.
--
___
Python tracker
<http://bugs.python.org/issue25
Changes by Eric Snow :
--
stage: commit review -> patch review
___
Python tracker
<http://bugs.python.org/issue25449>
___
___
Python-bugs-list mailing list
Un
Eric Snow added the comment:
FTR, this will likely involve more than just fixing odict_repr().
--
___
Python tracker
<http://bugs.python.org/issue24726>
___
___
Eric Price added the comment:
This patch seems to fix the issue for me, by installing a signal handler for
SIGWINCH that sets a flag which is checked while waiting for input.
One could make a simpler patch that just calls rl_resize_terminal() from the
signal handler. That would essentially
Eric Price added the comment:
Right, thanks, I've updated the patch.
--
Added file: http://bugs.python.org/file40843/rl_sigwinch_update.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Eric Price :
Removed file: http://bugs.python.org/file40837/rl_sigwinch_update.patch
___
Python tracker
<http://bugs.python.org/issue23735>
___
___
Python-bug
Changes by Eric Price :
Removed file: http://bugs.python.org/file40843/rl_sigwinch_update.patch
___
Python tracker
<http://bugs.python.org/issue23735>
___
___
Python-bug
Eric Price added the comment:
Hmm, hopefully the review tool works now. (I was generating the patch manually
from a source tarball, not a checkout.)
--
Added file: http://bugs.python.org/file40844/rl_sigwinch_update.patch
___
Python tracker
<h
Eric Price added the comment:
SIGWINCH handler for readline. Fixed indentation issues.
--
Added file: http://bugs.python.org/file40870/rl_sigwinch_update.patch
___
Python tracker
<http://bugs.python.org/issue23
3601 - 3700 of 6702 matches
Mail list logo
