The problem is that you haven't assigned a "creator" for tag_value, so when
the "value" kwarg is handled first, it creates the Tag, assigns the value
to "key", leaves "value" at None, and then "key" is overwritten by tag_key.
When "key" is handled first, everything works fine.
On Saturday, Septe
Hi Mike,
thank you so much for this insight into your way of tracing this, and for
the provided work-around (which I could really have come up with myself…).
3. next I want to whack the monkeypatched thing, because that's a lot of
> code that I don't want to be involved in the issue. Fortunate
OK so I'll just walk through how I do this:
1. first I run it in py3K where the "random" hash behavior is, until
python 3.6, in effect.
2. I can see the attributes are there or not on each run.
3. next I want to whack the monkeypatched thing, because that's a lot of
code that I don't want to
Am Samstag, 10. September 2016 09:02:32 UTC+2 schrieb Dominik George:
>
> Hi Mike,
>
> here it is. See attached mwe.py.
>
Which is here ;).
-nik
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receivin
Hi Mike,
here it is. See attached mwe.py.
Test:
% for i in $(seq 1 10); do PYTHONHASHSEED=$i python3 mwe.py; done
foo = , bang =
foo = , bang =
foo = bar , bang = baz
foo = bar , bang = baz
foo = , bang =
foo = , bang =
foo = , bang =
foo = bar , bang = baz
foo = , bang =
foo = , ba
Unfortunately I don't have the resources to debug applications, I can
only illustrate why a self-contained test script is doing what it does.
You'd have to roll this into an MCVE.
On 09/09/2016 05:32 PM, Dominik George wrote:
Hi,
Try setting PYTHONHASHSEED to a fixed integer number, and get
Hi,
>Try setting PYTHONHASHSEED to a fixed integer number, and get the test
>suite to fail with that number. Then you will see the same ordering
>failure in each case, and you can then use pdb and logging to more
>specifically isolate your issue.
It is not only the test cases.
All I do is:
When something happens on some test runs, and doesn't happen on other
test runs, the only thing that changes across Python interpreter runs is
the ordering of dictionaries and sets (interesting side note, it's been
announced yesterday/today that they are changing this in Python 3.6).
The steps
Hi,
thanks for your reply!
make sure you set the environment variable PYTHONHASHSEED=random, then
> run your tests repeatedly. This variable produces a random hash seed
> for dictionaries and will smoke out dictionary-ordering based bugs more
> clearly so that you can localize the source of i
On 09/08/2016 03:03 PM, Dominik George wrote:
Hi,
I am encountering a strange bug in my project OSMAlchemy:
https://github.com/Natureshadow/OSMAlchemy/issues/4
The model is a lot like in this example:
https://groups.google.com/group/sqlalchemy/attach/e0e54817232da/mwe.py?part=0.1&authuser=0&v
Hi,
I am encountering a strange bug in my project OSMAlchemy:
https://github.com/Natureshadow/OSMAlchemy/issues/4
The model is a lot like in this example:
https://groups.google.com/group/sqlalchemy/attach/e0e54817232da/mwe.py?part=0.1&authuser=0&view=1
I cannot make a real MWE for this bug becau
11 matches
Mail list logo