Domen Kožar added the comment:
Note: same bug is relevant to DatagramHandler since it uses UDP transport.
--
nosy: +iElectric
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11907
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 rep...@bugs.python.org
http://bugs.python.org/issue7559
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 rep...@bugs.python.org
http://bugs.python.org/issue7559
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 rep...@bugs.python.org
http://bugs.python.org/issue7559
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 hash
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 rep...@bugs.python.org
http
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 rep...@bugs.python.org
http://bugs.python.org/issue16816
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 rep...@bugs.python.org
http
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 ielect...@gmail.com 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 rep...@bugs.python.org
http
New submission from Domen Kožar ielect...@gmail.com:
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
Domen Kožar ielect...@gmail.com 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')
Option at 0x7f55bdb32dd0: --test
Domen Kožar ielect...@gmail.com 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_argument('foobar2', nargs='?')
parser.add_argument
Domen Kožar ielect...@gmail.com 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 rep
14 matches
Mail list logo
