Domen Kožar added the comment:
Note: same bug is relevant to DatagramHandler since it uses UDP transport.
--
nosy: +iElectric
___
Python tracker
<http://bugs.python.org/issue11
Domen Kožar added the comment:
Could we backport this one to 3.x and 2.7? It's leads to really bad UX.
--
___
Python tracker
<http://bugs.python.org/i
Domen Kožar added the comment:
One relevant use case is the following:
https://github.com/Pylons/venusian/issues/23
Here the module is supposed to raise an ImportError.
--
___
Python tracker
<http://bugs.python.org/issue7
Domen Kožar added the comment:
What can I do to put this forward? It's still an issue in py2.7
--
nosy: +iElectric
___
Python tracker
<http://bugs.python.org/i
Domen Kožar added the comment:
According to talk at 29c3:
http://events.ccc.de/congress/2012/Fahrplan/events/5152.en.html
Quote: We also describe a vulnerability of Python's new randomized hash,
allowing an attacker to easily recover the 128-bit secret seed. As a reliable
fix to
Domen Kožar added the comment:
Ah, works much better if you pass tuple to ordereddict. Seems like a bug in my
program indeed (I was using ordereddict, but not correctly).
Sorry for the noise!
--
___
Python tracker
<http://bugs.python.
Domen Kožar added the comment:
That would mean there is a bug in OrderedDict, since iterator of item in
OrderedDict should keep the order?
--
___
Python tracker
<http://bugs.python.org/issue16
Domen Kožar added the comment:
I believe this is not the case, I have updated example to use ordereddict, same
effect:
https://gist.github.com/4409304
--
resolution: invalid ->
status: closed -> open
___
Python tracker
<http://bugs.p
New submission from Domen Kožar:
Script to reproduce the issue https://gist.github.com/4409304
--
components: Interpreter Core
messages: 178539
nosy: iElectric
priority: normal
severity: normal
status: open
title: Bug in hash randomization
type: behavior
versions: Python 3.3
Domen Kožar added the comment:
I see, currently re module does not support debugging for matching a string.
Even the upcoming new regex implementation does not support it.
--
___
Python tracker
<http://bugs.python.org/issue12
New submission from Domen Kožar :
When using self.assertRegexpMatches, it would be useful to see where did the
matching stop. Maybe using re module debugging flag?
--
components: Library (Lib)
messages: 137432
nosy: iElectric
priority: normal
severity: normal
status: open
title
Domen Kožar added the comment:
I always used optparse like this, using the rargs (maybe this is not main
intention, but worked so far):
>>> import optparse
>>> parser = optparse.OptionParser()
>>> parser.add_option('--test', action='store_true')
Domen Kožar added the comment:
Optparse behaved like that, how would one get the same results with argparse?
That is by having variable positional parameters to command. And at the same
time stop at --.
--
___
Python tracker
<h
Domen Kožar added the comment:
I agree — not the best example, here is a better one explaining what behavior
should not exist:
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foobar', action='store')
>>> parser.add_argumen
14 matches
Mail list logo
