-----BEGIN PGP SIGNED MESSAGE-----
This happens to me very frequently.
I get the notification about new issues open in the bugtracker. If I
see an interesting "bug", I usually open a Firefox tab with it, to
monitor it, decide if I will work on it in the future, whatever.
When I have time to decide, I proceed. If I find the issue interesting
but don't have the time to work on it, or somebody else is taking care
of it, I just add myself to the nosy list, and close the tab.
The problem with this is that even if I reload the tab, flags are
usually stale and when I add myself to the nosy list, I revert flags
to the old value.
This happens frequently. Last time:
I think tracker should keep a "version" hidden field, and refuse to
act if the version on server is different that the just posted
changes. Or something.
Or am I doing something fundamentally wrong?. I reflesh 99% of the
time, but could forget sometimes, and some other times I need a
"shift+reload" to bypass browser cache.
PS: Tracker tells me about conflicts ocasionally, but most of the time
the stale flags are not noticed.
Jesús Cea Avión _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:firstname.lastname@example.org _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----
Hello and happy 2013,
Something I noticed earlier today is that some C versions of stdlib modules
define their name similarly to the Python version in their PyTypeObject.
Some examples: Decimal, xml.etree's Element. Others prepend an understore,
like _pickle.Pickler and many others.
What are the tradeoffs involved in this choice? Is there a "right" thing
for types that are supposed to be compatible (i.e. the C extension, where
available, replaces the Python implementation seamlessly)?
I can think of some meanings for pickling. Unpickling looks at the class
name to figure out how to unpickle a user-defined object, so this can
affect the pickle/unpickle compatibility between the C and Python versions.
This came up while investigating some test-order-dependency failures in
test___all__ goes over modules that have `__all__` in them and does 'from
<module> import *' on them. This leaves a lot of modules in sys.modules,
which may interfere with some tests that do fancy things with sys,modules.
In particular, the ElementTree tests have trouble with it because they
carefully set up the imports to get the C or the Python version of etree
(see issues 15083 and 15075).
Would it make sense to save the sys.modules state and restore it in
test___all__ so that sys.modules isn't affected by this test?
Likely the wrong place to report this, but I couldn't work out the best place and figured this is only as bad as anywhere else.
A user has reported to webmaster that hgweb is misconfigured (or at least the server configuration is interfering with hgweb).
The symptom is that this url is incorrectly a 404:
>> the web server is misconfigured to serve the hgweb static
>> files for any directory named 'static'. It is appropriate for it to do
>> this for http://hg.python.org/static/ and maybe even
>> http://hg.python.org/cpython/static/ and the other repositories, but
>> it is inappropriate for it to serve the hgweb static files within the
>> repository contents.
What should have happened: The web server passes on the request to
hgweb, which notices that it is supposed to retrieve a particular
version of a file from the Mercurial repository and show it to the
user. This works successfully for URLs not containing '/static/'
(ending slash significant), e.g.,
You can see that hgweb successfully displays the directory listing.
However, try adding a slash onto the end of that. The web server picks
up '/static/' and takes over the request, listing its static files
(rather than letting hgweb display the 'static' directory from the
Mercurial repository). The static files shown by the web server's
directory listing are used for the user interface of hgweb; for
example, the logo <http://hg.python.org/cpython/static/hglogo.png>. It
should be serving those static files on <http://hg.python.org/static/>
and <http://hg.python.org/repo/static/> (where repo is a repository
name like cpython), but it is also serving on
<http://hg.python.org/repo/file/.../static/>, which is inappropriate,
because it makes it impossible to view version_switch.js and the other
files in that directory with the hgweb interface.
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing
Good morning and happy new year!
I would like to let you know that I'm working on two new PEPs.
The first PEP addresses hash collision attacks as discussed in
http://bugs.python.org/issue14621. I'm planing to make the internal
string and bytes hash function more secure, pluggable and even faster.
DJB's SipHash is part of the plan as well. Users will be able to choose
an algorithm on startup and embedders will be able to provide their own
hash function, too.
The second PEP addresses key derivation functions for secure password
hashing. I like to add PBKDF2, bcrypt and scrypt facilities to the
A couple of us from the OpenStack project are interested in getting involved in the packaging rewrite/update project. I was following that work for a while, but have lost track of its current state. Can someone point me to the right mailing list, and maybe a status page or something so I can start figuring out where we might be able to help?
For the record, due to a bug in the "hg graft" command, a
recent changeset of mine basically merged branch 2.7 into 3.2:
$ hg log -r "ee8d999b6e05 or parents(ee8d999b6e05)" -G
o changeset: 81129:ee8d999b6e05
|\ branch: 3.2
| | parent: 81124:e4ea38a92c4d
| | parent: 81128:3436769a7964
| | user: Antoine Pitrou <solipsis(a)pitrou.net>
| | date: Fri Dec 28 19:07:43 2012 +0100
| | summary: Forward port new test for SSLSocket.connect_ex()
| o changeset: 81128:3436769a7964
| | branch: 2.7
| | user: Antoine Pitrou <solipsis(a)pitrou.net>
| | date: Fri Dec 28 19:03:43 2012 +0100
| | summary: Backport Python 3.2 fix for issue #12065, and add
another test for SSLSocket.connect_ex().
o | changeset: 81124:e4ea38a92c4d
| | branch: 3.2
| | parent: 81118:b2cd12690a51
| | user: Serhiy Storchaka <storchaka(a)gmail.com>
| | date: Fri Dec 28 09:42:11 2012 +0200
| | summary: Issue #16761: Raise TypeError when int() called with
base argument only.
The first symptoms were reported in
http://bz.selenic.com/show_bug.cgi?id=3748 but the actual cause of the
issue is http://bz.selenic.com/show_bug.cgi?id=3667.
Chances are the problem won't be very annoying in practice, but just