Re: [Python-Dev] Security implications of pep 383
On Wed, Mar 30, 2011 at 07:54, Toshio Kuratomi a.bad...@gmail.com wrote: Lennart is missing that you just need to use the same encoding + surrogateescape (or stick with bytes) for decoding the byte strings that you are comparing. You lost me here. I need to do this for what? //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security implications of pep 383
On Tue, Mar 29, 2011 at 23:17, Martin v. Löwis mar...@v.loewis.de wrote: I think the whole blacklist example is artificial. The string in the blacklist is actually a Chinese hello greeting, so it surely isn't the string being blacklisted. For proper blacklisting, you would likely use substring searches, case-insensitivity, transliterations, and perhaps even regular expressions and word stemming. Good point. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security implications of pep 383
On Tue, Mar 29, 2011 at 4:07 PM, Terry Reedy tjre...@udel.edu wrote: On 3/29/2011 2:23 PM, Michael Foord wrote: Not sure how real the security risk is here: http://blog.omega-prime.co.uk/?p=107 Basically he is saying that if you store a list of blacklisted files with names encoded in big-5 (or some other non-utf8 compatible encoding) if those names are passed at the command line, or otherwise read in and decoded from an assumed-utf8 source with surrogate escaping, the surrogate escape decoded names will not match the properly decoded blacklisted names. I posted link to this as comment, with my summary of thread. -- Terry Jan Reedy I don't see your comment on the blog post. So either the author is moderating comments and hasn't seen yours yet (likely) or they don't want disagreement in their comments. ;) Regardless, is isn't a bug with Python or PEP 383. If someone is dealing with security and does not know what formats the various inputs to their program that are used to make the security check can come in as they shouldn't be writing security oriented code at all... (But that's never stopped anyone). -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Differences among Emacsen
Barry Warsaw ba...@python.org writes: In case you missed it, there are now *three* Python modes. Tim Peters' original and best (in my completely unbiased opinion wink) python-mode.el which is still being developed, the older but apparently removed from Emacs python.el and the 'new' (so I've heard) python.el. https://github.com/fgallina/python.el is the fourth one.. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed issue tracker submission
2011/3/29 Python tracker roundup-ad...@psf.upfronthosting.co.za: The node specified by the designator in the subject of your message (22663) does not exist. Subject was: [issue22663] Aha. This email was probably generated by a commit hook because this changeset http://hg.python.org/cpython/rev/dd852a0f92d6 has a typo in the issue number, it should have been 11662. Mail Gateway Help = Incoming messages are examined for multiple parts: . In a multipart/mixed message or part, each subpart is extracted and examined. The text/plain subparts are assembled to form the textual body of the message, to be stored in the file associated with a msg class node. Any parts of other types are each stored in separate files and given file class nodes that are linked to the msg node. . In a multipart/alternative message or part, we look for a text/plain subpart and ignore the other parts. Summary --- The summary property on message nodes is taken from the first non-quoting section in the message body. The message body is divided into sections by blank lines. Sections where the second and all subsequent lines begin with a or | character are considered quoting sections. The first line of the first non-quoting section becomes the summary of the message. Addresses - All of the addresses in the To: and Cc: headers of the incoming message are looked up among the user nodes, and the corresponding users are placed in the recipients property on the new msg node. The address in the From: header similarly determines the author property of the new msg node. The default handling for addresses that don't have corresponding users is to create new users with no passwords and a username equal to the address. (The web interface does not permit logins for users with no passwords.) If we prefer to reject mail from outside sources, we can simply register an auditor on the user class that prevents the creation of user nodes with no passwords. Actions --- The subject line of the incoming message is examined to determine whether the message is an attempt to create a new item or to discuss an existing item. A designator enclosed in square brackets is sought as the first thing on the subject line (after skipping any Fwd: or Re: prefixes). If an item designator (class name and id number) is found there, the newly created msg node is added to the messages property for that item, and any new file nodes are added to the files property for the item. If just an item class name is found there, we attempt to create a new item of that class with its messages property initialized to contain the new msg node and its files property initialized to contain any new file nodes. Triggers Both cases may trigger detectors (in the first case we are calling the set() method to add the message to the item's spool; in the second case we are calling the create() method to create a new node). If an auditor raises an exception, the original message is bounced back to the sender with the explanatory message given in the exception. $Id: mailgw.py,v 1.196 2008-07-23 03:04:44 richard Exp $ Return-Path: python-dev@python.org X-Original-To: rep...@bugs.python.org Delivered-To: roundup+trac...@psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 7DCEE1DEB0 for rep...@bugs.python.org; Tue, 29 Mar 2011 22:10:55 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3PzjsW1q1lz7Lmy for rep...@bugs.python.org; Tue, 29 Mar 2011 22:10:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1301429455; bh=WYL3NF6gQtbDZ+R9KxXHGS2PSlCAxyY+EQEgb/Yw5jI=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=RiMAivS4Shae7bPg7E7SocheqYB9pzk/Svimv+qumX5arnUaaC8h9iIJo8MFDcDdi +Wk0XzTjTjKsbobrKgZnfZf9a8j6Fv4Ym1nTyTcPcyjCMritjq9xNUluVQvHv/Vn2e RhpV2FUWOdCtBx83eUopMPGEEEwABnbG5ZwgsDzM= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 29 Mar 2011 22:10:55 +0200 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for rep...@bugs.python.org; Tue, 29 Mar 2011 22:10:55 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from python-dev@python.org) id 1Q4fFf-00023G-4C for rep...@bugs.python.org; Tue, 29 Mar 2011 22:10:55 +0200 Date: Tue, 29 Mar 2011 22:10:55 +0200 Message-Id: e1q4fff-00023g...@dinsdale.python.org
Re: [Python-Dev] Information about how cpython in benchmarked
On Wed, Mar 30, 2011 at 1:19 AM, Nick Stinemates nstinema...@gmail.com wrote: This is really great to hear and something I would be hugely interested in contributing to. Lurking has paid off :) Nick Once I get the machine in place, and the team engaged, I am sure they'll be looking for help. As it stands, the best place to start helping is by getting in conact with the speed.pypy.org team (the pypy folks) and look into the codespeed codebase. We have to start work on it now to get it ready to be more general use. jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security implications of pep 383
On Wed, Mar 30, 2011 at 4:57 PM, Gregory P. Smith g...@krypto.org wrote: I don't see your comment on the blog post. So either the author is moderating comments and hasn't seen yours yet (likely) or they don't want disagreement in their comments. ;) My comment was sitting in the moderation queue last time I looked as well. While Toshio is correct that there is no one correct filesystem encoding on Linux systems, Python still does its best to guess one (even though it may be wrong for some of the mounted filesystems). That's what it will use when encoding Unicode strings to pass to bytes-oriented POSIX APIs, so you can always pre-check values by using os.fsencode to get everything into the bytes format that will actually be passed to the underlying OS API. Python 3.2 provides the tools to do this kind of thing correctly, but it is finicky enough that there isn't really any way for us to make it easy. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .hgignore including site-packages and scripts directories?
On Wed, 30 Mar 2011 12:17:05 +1100 Mark Hammond mhamm...@skippinet.com.au wrote: On 30/03/2011 12:09 PM, R. David Murray wrote: On Wed, 30 Mar 2011 11:11:45 +1100, Mark Hammondmhamm...@skippinet.com.au wrote: I'm wondering if it is a reasonable idea to have .hgignore exclude all files from 'Lib/site-packages' and 'Scripts'? As I install packages into my source builds, a 'hg status' lists *many* files in both those directories forcing me to scroll up a number of pages to see files which have actually changed. I hardly ever install things into my source build. The first time I've done that, in fact, was to run coverage. Windows doesn't really have an install process integrated into the build, so it is probably fairly common there. The solution is to add such directories and/or files to your personal ignore list See the 'ignore' entry under 'ui' in the hgrc documentation. Yeah - but I was wondering if it could be made more convenient by default given the downside seems quite small... I don't see any downside myself. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security implications of pep 383
On 3/29/2011 12:10 PM, Toshio Kuratomi wrote: The possible flaw in python is this: Code like the blog poster wrote passes python3 without an error or a warning. This gives the programmer no feedback that they're doing something wrong until it actually bites them in the foot in deployed code. Yes there is a certain level of knowledge required of the system configuration and python defaults for accessing the system for things like filenames. It can be coded in any of several ways. But by the above definition of possible flaw, that seems equivalent to saying that Python should give a warning for things like os.unlink(my-most-important-file.doc) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Test Force Build on custom buildbots
Hi,
I'm testing my faulthandler repository on the custom buildbots, here are
some remarks and issues.
The form still refers to SVN ('Branch to build' is relative to
http://svn.python.org/projects/python.) = the branch is relative to
hg.python.org/
I cannot write # in the branch field to specify... the branch (only
the repository). If the branch contains #, the request looks to be
ignored (without any warning/error). I merged my faulthandler branch
into the default branch (in my features/faulthandler branch).
I don't understand the meaning of the project field. It is maybe
something specific to Subversion?
What are the 3 optional properties?
If branch doesn't end with a slash (e.g. features/faulthandler), the
request is ignored (without any warning/error).
I canceled a build on a Windows buildbot during the tests step using
the [Cancel] button, but it failed to kill the process:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%
20custom/builds/2/steps/test/logs/stdio
---
command interrupted, killing pid 2168
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1
---
To test my faulthandler feature branch, the correct parameters are:
--
Name: haypo
Reason: test faulthandler
Branch: features/faulthandler/
Revision: tip
Repository: features/faulthandler
(leave the project and the 6 property fields empty)
--
The repository looks like a duplicate of the branch field. I would be
better to use default as the branch and features/faulthandler as the
repository.
I would be nice to have error messages.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test Force Build on custom buildbots
On Wed, 30 Mar 2011 17:59:02 +0200 Victor Stinner victor.stin...@haypocalc.com wrote: I cannot write # in the branch field to specify... the branch (only the repository). If the branch contains #, the request looks to be ignored (without any warning/error). I merged my faulthandler branch into the default branch (in my features/faulthandler branch). You could have put the branch name in the revision field instead (as I told you on #python-dev). This is very much an unofficial feature right now, which also explains that the UI has not been adapted. I canceled a build on a Windows buildbot during the tests step using the [Cancel] button, but it failed to kill the process: http://www.python.org/dev/buildbot/all/builders/x86%20Windows7% 20custom/builds/2/steps/test/logs/stdio --- command interrupted, killing pid 2168 SIGKILL failed to kill process using fake rc=-1 program finished with exit code -1 --- This is the kind of question you have to ask on the buildbot channels. I don't think any of us knows enough about buildbot internals to answer it or give any guidance. Thank you Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test Force Build on custom buildbots
Le mercredi 30 mars 2011 à 17:59 +0200, Victor Stinner a écrit : I'm testing my faulthandler repository on the custom buildbots, here are some remarks and issues. Oh, I forgot something: there is an error on hg purge. Example on a Windows buildbot: C:\Program Files\Mercurial\hg.EXE purge --all ... argv: ['C:\\Program Files\\Mercurial\\hg.EXE', 'purge', '--all'] ... program finished with exit code -1 'hg purge' failed: Mercurial Distributed SCM It looks like build slaves require the purge extension. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test Force Build on custom buildbots
On Wed, 30 Mar 2011 18:11:53 +0200 Victor Stinner victor.stin...@haypocalc.com wrote: Le mercredi 30 mars 2011 à 17:59 +0200, Victor Stinner a écrit : I'm testing my faulthandler repository on the custom buildbots, here are some remarks and issues. Oh, I forgot something: there is an error on hg purge. [...] It's not an error, it falls back on another purging method when the purge extension is not enabled. cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security implications of pep 383
On 3/30/2011 2:57 AM, Gregory P. Smith wrote: http://blog.omega-prime.co.uk/?p=107 I posted link to this as comment, with my summary of thread. I don't see your comment on the blog post. So either the author is moderating comments and hasn't seen yours yet (likely) My comment and Nick's are now both posted. Blogger Max replied Nick, thanks for that info. It is certainly nice that there is a work around, and perhaps this indeed the best that can be done if you still want the convenience of representing filenames as strings. Terry: thanks also for the link to the mailing list thread. It is certainly interesting, and the argument regarding latin1 is a compelling one — this issue is indeed not specific to PEP383. So the dangerous operation seems to be comparing strings that were originally created from byte strings in two different encodings. It’s not clear to me that it would be sensible for the language to check this (perhaps by throwing an exception if you try it). The other 2 comments are also followed by responses. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Differences among Emacsen
On Mar 30, 2011, at 09:43 AM, Ralf Schmitt wrote: Barry Warsaw ba...@python.org writes: In case you missed it, there are now *three* Python modes. Tim Peters' original and best (in my completely unbiased opinion wink) python-mode.el which is still being developed, the older but apparently removed from Emacs python.el and the 'new' (so I've heard) python.el. https://github.com/fgallina/python.el is the fourth one.. Wonderful. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Differences among Emacsen
On Mar 30, 2011, at 2:54 PM, Barry Warsaw wrote: On Mar 30, 2011, at 09:43 AM, Ralf Schmitt wrote: Barry Warsaw ba...@python.org writes: In case you missed it, there are now *three* Python modes. Tim Peters' original and best (in my completely unbiased opinion wink) python-mode.el which is still being developed, the older but apparently removed from Emacs python.el and the 'new' (so I've heard) python.el. https://github.com/fgallina/python.el is the fourth one.. Wonderful. I have a plea for posterity: since I'm sure that a hundred people will see this post and decide that the best solution to this proliferation of python plugins for emacs is that there should be a new one that is even better than all these other ones (and also totally incompatible, of course)... I won't try to stop you all from doing that, but please at least don't call it python.el. This is like if ActiveState, Wing, PyCharm and PyDev for Eclipse had all decided to call their respective projects IDLE because that's what you call a Python IDE :). It would be nice to be able to talk about Python / Emacs code without having to do an Abbott and Costello routine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replace useless %.100s by %s in PyErr_Format()
Victor Stinner wrote: Le jeudi 24 mars 2011 à 13:22 +0100, M.-A. Lemburg a écrit : BTW: Why do you think that %.100s is not supported in PyErr_Format() in Python 2.x ? PyString_FromFormatV() does support this. The change to use Unicode error strings introduced the problem, since PyUnicode_FromFormatV() for some reason ignores the precision (which is shouldn't). Oh... You are right, it is a regression in Python 3. We started to write unit tests for PyBytes_FromFormat() and PyUnicode_FromFormat(), I hope that they will improve the situation. That said, it's a good idea to add the #7330 fix to at least Python 2.7 as well, since ignoring the precision is definitely a bug. It may even be security relevant, since it could be used for DOS attacks on servers (e.g. causing them to write huge strings to log files instead of just a few hundreds bytes per message), so may even need to go into Python 2.6. Python 2 is not affected because PyErr_Format() uses PyString_FromFormatV() which supports precision for %s format (e.g. %.100s truncate the string to 100 bytes). Right, but the PyUnicode_FromFormatV() which ignores the precision is still present in Python 2.6 and 2.7, even though it is not used by PyErr_Format(). Do you think that Python 3.1-3.3 should be fixed? Yes, indeed. The above mentioned security threat is real. The CPython code only has a few cases where this could be use for a DOS (e.g. in the pickle module or the AST code), but since this function is used in 3rd party extensions, those are affected indirectly as well. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2011) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devguide: Add a table of contents to the FAQ.
On Tue, 29 Mar 2011 21:00:22 +0200 ezio.melotti python-check...@python.org wrote: http://hg.python.org/devguide/rev/f722956afeac changeset: 405:f722956afeac user:Ezio Melotti date:Tue Mar 29 22:00:13 2011 +0300 summary: Add a table of contents to the FAQ. Could it be collapsed by default? It's quite long, and redundant with the sidebar. thanks Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Documenting the buildbots
For the record, I added a page documenting our continuous integration
setup at:
http://docs.python.org/devguide/buildbots.html
Regards
Antoine.
On Wed, 30 Mar 2011 17:59:02 +0200
Victor Stinner victor.stin...@haypocalc.com wrote:
Hi,
I'm testing my faulthandler repository on the custom buildbots, here are
some remarks and issues.
The form still refers to SVN ('Branch to build' is relative to
http://svn.python.org/projects/python.) = the branch is relative to
hg.python.org/
I cannot write # in the branch field to specify... the branch (only
the repository). If the branch contains #, the request looks to be
ignored (without any warning/error). I merged my faulthandler branch
into the default branch (in my features/faulthandler branch).
I don't understand the meaning of the project field. It is maybe
something specific to Subversion?
What are the 3 optional properties?
If branch doesn't end with a slash (e.g. features/faulthandler), the
request is ignored (without any warning/error).
I canceled a build on a Windows buildbot during the tests step using
the [Cancel] button, but it failed to kill the process:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%
20custom/builds/2/steps/test/logs/stdio
---
command interrupted, killing pid 2168
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1
---
To test my faulthandler feature branch, the correct parameters are:
--
Name: haypo
Reason: test faulthandler
Branch: features/faulthandler/
Revision: tip
Repository: features/faulthandler
(leave the project and the 6 property fields empty)
--
The repository looks like a duplicate of the branch field. I would be
better to use default as the branch and features/faulthandler as the
repository.
I would be nice to have error messages.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documenting the buildbots
On Wed, Mar 30, 2011 at 5:01 PM, Antoine Pitrou solip...@pitrou.net wrote: For the record, I added a page documenting our continuous integration setup at: http://docs.python.org/devguide/buildbots.html Regards Antoine. that's awesome. should we document how to donate/add a buildbot somewhere in the same section (or alongside)? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documenting the buildbots
On Wed, 30 Mar 2011 17:14:10 -0400 Jesse Noller jnol...@gmail.com wrote: On Wed, Mar 30, 2011 at 5:01 PM, Antoine Pitrou solip...@pitrou.net wrote: For the record, I added a page documenting our continuous integration setup at: http://docs.python.org/devguide/buildbots.html Regards Antoine. that's awesome. should we document how to donate/add a buildbot somewhere in the same section (or alongside)? It's documented at http://wiki.python.org/moin/BuildBot. I think it's a bit outside the scope of the devguide. (perhaps we should have an infrastructure/sysadmin contribution guide) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documenting the buildbots
On Wed, Mar 30, 2011 at 5:24 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 30 Mar 2011 17:14:10 -0400 Jesse Noller jnol...@gmail.com wrote: On Wed, Mar 30, 2011 at 5:01 PM, Antoine Pitrou solip...@pitrou.net wrote: For the record, I added a page documenting our continuous integration setup at: http://docs.python.org/devguide/buildbots.html Regards Antoine. that's awesome. should we document how to donate/add a buildbot somewhere in the same section (or alongside)? It's documented at http://wiki.python.org/moin/BuildBot. I think it's a bit outside the scope of the devguide. (perhaps we should have an infrastructure/sysadmin contribution guide) Not a bad idea. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Please revert autofolding of tracker edit form
The tracker was recently changed so that when I click on a link to a tracker page, the page is properly displayed, but then a fraction of a second it blinks and redisplays with the edit form hidden. This is so obnoxious to me that I no longer want to visit the tracker. Then I have to find and click the button to get back the edit form that I nearly always want to see, as I often make changes. All this to compress the page by half a screen, which makes almost no difference once one grabs the scrollbar anyway. If someone actually considers this a desired feature, after using it, then please add a field on the profile page to select autofolding or not. Also, there should be a button to fold as well as one to unfold. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Notification for buildbot builder changes for slaves?
I was wondering if it might be possible to have a channel (message here, email to a list of slave owners or whatever) to mention when the set of builders for the slaves is getting adjusted? A new builder tree can burn a good deal of disk space in some cases for example (each tree adds in the neighborhood of .5GB for each of my Windows buildbots), and while it's generally not an issue, the recent conversion to hg actually exhausted my disk space on several slaves, for example. I'm not looking to get in the way of any process - just have a way to hear about such changes in advance when possible in case I need to make adjustments. Thanks. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security implications of pep 383
On Wed, Mar 30, 2011 at 08:36:43AM +0200, Lennart Regebro wrote:
On Wed, Mar 30, 2011 at 07:54, Toshio Kuratomi a.bad...@gmail.com wrote:
Lennart is missing that you just need to use the same encoding
+ surrogateescape (or stick with bytes) for decoding the byte strings that
you are comparing.
You lost me here. I need to do this for what?
The lesson here seems to be if you have to use blacklists, and you
use unicode strings for those blacklists, also make sure the string
you compare with doesn't have surrogates.
Really, surrogates are a red herring to this whole issue. The issue is that
the original code was trying to compare two different transformations of
byte sequences and expecting them to be equal. Let's say that you have the
following byte value::
b_test_value = b'\xa4\xaf'
This is something that's stored in a file or the filename of something on
a unix filesystem or stored in a database or any number of other things.
Now you want to compare that to another piece of data that you've read in
from somewhere outside of python. You'd expect any of the following to
work::
b_test_value == b_other_byte_value
b_test_value.encode('utf-8', 'surrogateescape') ==
b_other_byte_value('utf-8', 'surrogateescape')
b_test_value.encode('latin-1') == b_other_byte_value('latin-1')
b_test_value.encode('euc_jp') == b_other_byte_value('euc_jp')
You wouldn't expect this to work::
b_test_value.encode('latin-1') == b_other_byte_value('euc_jp')
Once you see that, you realize that the following is only a specific case of
the former, surrogateescape doesn't really matter::
b_test_value.encode('utf-8', 'surrogateescape') ==
b_other_byte_value('euc_jp')
-Toshio
pgpZiMIuYZION.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
On Thu, Mar 31, 2011 at 7:35 AM, Terry Reedy tjre...@udel.edu wrote: The tracker was recently changed so that when I click on a link to a tracker page, the page is properly displayed, but then a fraction of a second it blinks and redisplays with the edit form hidden. This is so obnoxious to me that I no longer want to visit the tracker. Then I have to find and click the button to get back the edit form that I nearly always want to see, as I often make changes. All this to compress the page by half a screen, which makes almost no difference once one grabs the scrollbar anyway. Interesting - it comes straight up with the folded screen for me, no flickering at all. It may depend on how a given browser handles the scripts involved. If someone actually considers this a desired feature, after using it, then please add a field on the profile page to select autofolding or not. Also, there should be a button to fold as well as one to unfold. Skip objected to the amount of noise at the top of the tracker screen, so I assume whoever added the feature was doing so in response to that concern. Since it doesn't flicker for me, I actually found it to be an elegant solution. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
On Mar 30, 2011, at 2:35 PM, Terry Reedy wrote: The tracker was recently changed so that when I click on a link to a tracker page, the page is properly displayed, but then a fraction of a second it blinks and redisplays with the edit form hidden. This is so obnoxious to me that I no longer want to visit the tracker. Then I have to find and click the button to get back the edit form that I nearly always want to see, as I often make changes. All this to compress the page by half a screen, which makes almost no difference once one grabs the scrollbar anyway. Same thing happening here (Google Chrome browser running on Snow Leopard). I also find it weird and irritating. If someone actually considers this a desired feature, after using it, then please add a field on the profile page to select autofolding or not. Also, there should be a button to fold as well as one to unfold. +1 Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
On Thu, Mar 31, 2011 at 12:54 AM, Nick Coghlan ncogh...@gmail.com wrote: Interesting - it comes straight up with the folded screen for me, no flickering at all. I didn't get any flicker either and my first impression of the change was also positive -- I usually skip straight to the comments the first time I visit an issue. Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
On Thu, 31 Mar 2011 08:54:41 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Thu, Mar 31, 2011 at 7:35 AM, Terry Reedy tjre...@udel.edu wrote: The tracker was recently changed so that when I click on a link to a tracker page, the page is properly displayed, but then a fraction of a second it blinks and redisplays with the edit form hidden. This is so obnoxious to me that I no longer want to visit the tracker. Then I have to find and click the button to get back the edit form that I nearly always want to see, as I often make changes. All this to compress the page by half a screen, which makes almost no difference once one grabs the scrollbar anyway. Interesting - it comes straight up with the folded screen for me, no flickering at all. It has flickered occasionally here (Firefox 4). It may depend on how a given browser handles the scripts involved. Or how fast they get loaded compared to the main HTML, which can then interact with some redraw timers in your browser or whatever else. If someone actually considers this a desired feature, after using it, then please add a field on the profile page to select autofolding or not. Also, there should be a button to fold as well as one to unfold. Skip objected to the amount of noise at the top of the tracker screen, so I assume whoever added the feature was doing so in response to that concern. Since it doesn't flicker for me, I actually found it to be an elegant solution. There's a lot of noise but that noise is useful. I find the natural language summary to be much too terse and doesn't make it easy to visualize said information as opposed to the form fields. What's more, it lacks the most important: the issue title. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documenting the buildbots
For the record, I added a page documenting our continuous integration setup at: http://docs.python.org/devguide/buildbots.html Jesse that's awesome. should we document how to donate/add a buildbot Jesse somewhere in the same section (or alongside)? I must admit, it wasn't obvious to me where the link to this page exists in the devguide. Also, I see a link to this page: http://python.org/dev/buildbot/ labelled buildbot status. Should it link back to Antoine's new page? S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] faulthandler is now part of Python 3.3
Hi, I pushed my faulthandler module into the default branch (Python 3.3). Since one week, I fixed a lot of bugs (platform issues), improved the tests and Antoine wrote a new implementation of dump_backtraces_later() using a thread (instead of SIGALRM+alarm()). It should now work on all platforms (but register() is not available on Windows). Use python -X faulthandler or PYTHONFAULTHANDLER=1 python to install the fault handler at startup (catch segfaults and other fatal errors). You can also register a signal (e.g. SIGUSR1) to dump the traceback on this signal. The latest added feature is to be able to the dump the traceback after a timeout and exit the process: we may use it on regrtest.py to learn more about test_multiprocess and test_threadsignals hangs. Issue #11393 has a patch implementing this issue: add --timeout option to regrtest.py. You can also just dump the traceback after the timeout without exiting. Py_FatalError() always print the Python traceback (except if an exception was raised: print the exception with its traceback). For more information, read the doc: http://docs.python.org/dev/library/faulthandler.html Please tell me if you have any issue related to faulthandler. -- If you get undefined reference to `_PyFaulthandler_Init' compiler error, copy Modules/Setup.dist to Modules/Setup (cp Modules/Setup.dist Modules/Setup). test_faulthandler hangs on AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana 3.x. It looks to be related to the stack overflow test (the stack is maybe not limited on these buildbots?). I have a patch, but I cannot test it because these buildbots are dead (oops, sorry!). Most buildbots are red because a regression in test_logging (since 2 days): I disabled temporary the test (issue #11557), I hope that the situation will be better in a few hours. Thank you Antoine for your reviews! Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
On 3/30/2011 7:32 PM, Antoine Pitrou wrote: There's a lot of noise but that noise is useful. I find the natural language summary to be much too terse and doesn't make it easy to visualize said information as opposed to the form fields. Yes, there is a good reason why database records are routinely displayed in labeled and located fields rather than in variable length natural language sentences with a monochrome font. Form letters, of course, are an exception. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Security implications of pep 383
On 3/30/2011 6:39 PM, Toshio Kuratomi wrote:
Really, surrogates are a red herring to this whole issue. The issue is that
the original code was trying to compare two different transformations of
byte sequences and expecting them to be equal. Let's say that you have the
following byte value::
b_test_value = b'\xa4\xaf'
This is something that's stored in a file or the filename of something on
a unix filesystem or stored in a database or any number of other things.
Now you want to compare that to another piece of data that you've read in
from somewhere outside of python. You'd expect any of the following to
work::
b_test_value == b_other_byte_value
b_test_value.encode('utf-8', 'surrogateescape') ==
b_other_byte_value('utf-8', 'surrogateescape')
b_test_value.encode('latin-1') == b_other_byte_value('latin-1')
b_test_value.encode('euc_jp') == b_other_byte_value('euc_jp')
You wouldn't expect this to work::
b_test_value.encode('latin-1') == b_other_byte_value('euc_jp')
Once you see that, you realize that the following is only a specific case of
the former, surrogateescape doesn't really matter::
b_test_value.encode('utf-8', 'surrogateescape') ==
b_other_byte_value('euc_jp')
All the encodes above should be decodes instead. Aside from that. your
point is correct, and not limited to CS. The whole art of disguise, for
instance, is about effecting a transformation to falsely pass or fail an
identity or equality comparison.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
On Thu, 31 Mar 2011 08:54:41 +1000, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Mar 31, 2011 at 7:35 AM, Terry Reedy tjre...@udel.edu wrote: If someone actually considers this a desired feature, after using it, then please add a field on the profile page to select autofolding or not. Also, there should be a button to fold as well as one to unfold. Skip objected to the amount of noise at the top of the tracker screen, so I assume whoever added the feature was doing so in response to that concern. Since it doesn't flicker for me, I actually found it to be an elegant solution. Flicker or not, I don't like it myself. I've turned off javascript on bugs.python.org in my browser, and now it doesn't bother me anymore. But I don't think that is a good long term solution. Making it optional based on a setting in the user profile might be OK. -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Non-code changes on old branches
Hi, There are a couple of changes I'd like to make and would like some guidance on policy: http://bugs.python.org/issue6498 is a documentation bug which exists in Python 2.6 and later. The patch in that bug touches the docs and a comment in one source file. Is it acceptable to push that change to the 2.6 branch, or should I start with 2.7? My request re .hgignore from yesterday didn't get any complaints, so I intend opening a bug, asking for review here and if I don't get objections in a day or so, pushing the change. This really should go all the way back to 2.5 even though that release has long been closed. Is it acceptable to push a change to .hgignore to the 2.5 branch? If not, where should I start with such a change? I ask these questions primarily as the dev guide tells me I should forward-port all changes - thus, I need to know the earliest versions I can use before I can even start the process... Thanks, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
