Mailman 3 April 2010 - Python-Dev

Planning a Windows buildbot
by Tim Golden April 20, 2010

April 20, 2010

I've got agreement in principle for one of our decommissioned servers to be repurposed as a Python buildbot. My idea would be to set it up as a Windows 2003 R2 server, at least partly because we don't seem to have any Windows server buildbots and it's a platform I'm especially interested in. Does anyone suggest that a different configuration would be preferable? Thanks to the PSF MSDN license I can pretty much choose whatever I want. I believe Brian Curtin's looking at the possibility of a … [View More]

3 3

Support byte string API of Windows in Python3?
by Victor Stinner April 20, 2010

April 20, 2010

Hi, I'm working on surrogates in filenames on Linux (more generally on BSD and UNIX OS) to support undecodable filenames, see PEP 383. Amaury told me that I only fixed the non-Windows versions (I fixed subprocess about the current directory and _ctypes.dlopen()), but it doesn't work on Windows. It's a choice, I didn't want to patch Windows because I know that Windows use unicode internally. I consider that developers using Python3 should use unicode on Windows, and byte or unicode+… [View More]

4 7

MSDN licenses available for python-dev
by Brian Curtin April 19, 2010

April 19, 2010

Hi python-dev, The recent threads on builds/installers for Mac and Windows reminded me of Steve Holden's push to get the python-dev team equipped via a connection with the Microsoft Open Source Technology Center. The OSTC team provides Microsoft Developer Network licenses to open source projects to assist them in better supporting Windows. I've talked with Steve (who passed the task to me) and the Microsoft folks, and they are happy to provide more licenses if needed. If you are interested in … [View More]

10 13

Re: [Python-Dev] Python 2.7b1 and argparse's version action
by Brett Cannon April 19, 2010

April 19, 2010

I'm with Martin; just let it be explicit and stick an example in the docs. -Brett (from his phone with hopefully only one copy sent of this email) On Apr 18, 2010 9:22 PM, Martin v. Löwis <martin(a)v.loewis.de> wrote: > - many optparse programs use the version argument > - many other programmers find this feature ver... You actually brought up a good reason yourself: In the face of ambiguity, refuse the temptation to guess. If you ask "give me a version argument", the question … [View More]

1 0

Bug? syslog.openlog using ident "python" by default.
by Sean Reifschneider April 19, 2010

April 19, 2010

I'd appreciate some opinions on this. Personally, I'm in the "the current code is buggy" camp. :-) I can code up the changes to the syslog module if we decide that's the right way to go. Looks like Raymond, Guido, and I are the last ones to do syslog-specific changes to this module in the last 15 years. If you call: from syslog import syslog, openlog syslog('My error message') Something like the following gets logged: Mar 18 05:20:22 guin python: My error message … [View More] ^^^^^^ Where I'm annoyed by the "python" in the above. This is pulled from the C argv[0]. IMHO, what we really want is the Python sys.argv[0]. Because of this feature, I always have to do the following when I'm using syslog: openlog(os.path.basename(sys.argv[0])) I would propose changing the Python syslog() call to do the C equivalent of: if openlog_hasnt_been_called_before_now: if sys.argv[0]: syslog.openlog(os.path.basename(sys.argv[0])) In other words, if there's a script name and openlog hasn't already been called, call openlog with the basename of the script name. This is effectively what happens in normal C code that calls syslog. Note that the Python syslog.openlog says that the default for ident is "(usually) 'syslog'". The benefit of this change is that you get a more identifiable ident string in Python programs, so when you look at the logs you can tell what script it came from, not just that it came from some Python program. One way of looking at it would be that the syslog module logging "python" as the program name is a bug. The downside I see is that there might be some users doing log scraping depending on this (IMHO, buggy) log ident. Something else just occurred to me though, a nice enhancement would be for openlog() to have a "None" default for ident, something like: orig_openlog = openlog def openlog(ident = None, logopt = 0, facility = LOG_USER) if ident == None: if sys.argv[0]: ident = os.path.basename(sys.argv[0]) else: ident = 'python' orig_openlog(ident, logopt, facility) So you could call openlog and rely on the default ident (sys.argv[0]), and set the logopt and facility. The gory details of why this is occurring are: If you don't call "openlog()" before "syslog()", the system syslog() function calls something similar to: "openlog(basename(argv[0]))", which causes the "ident" of the syslog messages to be "python" rather than the specific program. Thoughts? Thanks, Sean -- "Every increased possession loads us with new weariness." -- John Ruskin Sean Reifschneider, Member of Technical Staff <jafo(a)tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability [View Less]

3 3

bbreport
by Victor Stinner April 18, 2010

April 18, 2010

Hi, Ezio and Florent are developing a tool called bbreport to collect buildbot results and generate short reports to the command line. It's possible to filter results by Python branch, builder name, etc. I send patches to link failed tests to existing issues to see quickly known failures vs new failures. This tool becomes really useful to analyze buildbot results! http://code.google.com/p/bbreport/ bbreport requires Python trunk (2.7) and color output only works on UNIX/BSD OS (ie. not … [View More]

4 4

Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))
by Ronald Oussoren April 18, 2010

April 18, 2010

On Wednesday, April 14, 2010, at 04:47PM, "Nick Coghlan" <ncoghlan(a)gmail.com> wrote: >Martin v. Löwis wrote: >>> Wasn't that problem fixed weeks ago? The installer image has been >>> available there since several days after the release. And the link >>> seems fine now. >> >> The inherent problem remains. There is no binary for 2.7b1, for example. >> The last binaries produced in the 2.7 testing process were for 2.7a2. That's because … [View More]

10 25

Keyword-only arguments in 2.x
by George Sakkis April 18, 2010

April 18, 2010

Hi all, what's the status of backporting PEP 3102 ? It was supposed to go into 2.6 and it seems it won't be in 2.7 either. There is an updated patch in the tracker [1] that applies cleanly on the latest trunk and passes all relevant tests, so unless there has been a decision against backporting it, would it be possible to push it for 2.7 ? I think this is a very useful PEP and it would be great to have it in 2.x too. George [1] http://bugs.python.org/issue1745

2 1

Python 2.7b1 and argparse's version action
by Tobias Herp April 18, 2010

April 18, 2010

Hi, all, I noticed that Python 2.7 beta 1 now contains the argparse module, which might be a good thing. The code has been cleaned up, too, compared to the current version 1.1. But there is still one issue with argparse; to tell the story from the beginning: The ArgumentParser class uses uses '-v' as a default short option for the 'tell me the program version' facility. Since this is commonly used for verbosity, and the vast majority of *X commandline tools use '-V' instead (if they bother … [View More]to accompany '--version' with a short option at all). Therefore I submitted an issue report at <http://code.google.com/p/argparse/issues/detail?id=43>. To put it short: *Argparse should simply do this like optparse does already.* I.e., use '--version', '--help' and '-h' by default, but not '-v'. Subsequently I spent a hard time arguing. (Perhaps it was somewhat distracting that I proposed a way of postponing the creation of the help and version options and to provide them with the short options which are left unused e.g. for hosts (database clients), human readability (ls, du, etc.) or verbosity; Steven had stated it might break backward compatibility if the '-v' option string for version output would be dropped which might be relied on by other programs which parse the output. IMO, however, anyone should be beaten who relies on '-v' giving the version while '--version' has been present all the time. The Zen of Python, 2nd aphorism: "Explicit is better than implicit") What happened was the following: Completely unnecessarily, the 'version' constructor argument is now deprecated. This fact doesn't solve any problem I can think of; the only effect is to make programming more cumbersome, and it is /one more/ difference to optparse. The 'version' argument is a perfectly reasonable way to provide a script with a simple version information feature. Of course, it should only define the '--version' argument; it *must not* define '-v' for this purpose, since this is commonly used for verbosity, and '-V' is widely used to accompany '--version'. I have lots of scripts which use optparse, and every single one uses the version argument. I consider this a matter of good style. The deprecation of the 'version' argument press-gangs people to replace it by parser.add_argument('--version', action='version', version='<the version>', # the only common part help="show program's version number and exit") in every single script (which violates the DRY principle, by the way). Of course, if a more fancy version information is needed, e.g. reporting the versions of all imported modules, it is perfectly possible to just omit the version argument during creation and build a special 'version' action. No deprecation warnings are needed for this. *Before Python 2.7 reaches productivity stage*, IMNSHO the following changes should be applied to argparse.py: - removal of the deprecation warnings - removal of the default usage of '-v' with the version information facility This is a very simple thing to do; I'd happily provide a patch. (The only complicated task might be to make the unit tests reflect the change; but for a start, 7 lines of the test_main function could be dropped.) Just for the records, this is what optparse does: - it defines -h and --help for the help (unless suppressed) - it defines --version for the version (if version argument given) This is how it should be (regarding the version, at least). This is how the vast majority of *x tools looks like. No reason to change this behaviour. What do you think? -- Cheers, Tobias [View Less]

1 0

Very Strange Argument Handling Behavior
by Alex Gaynor April 17, 2010

April 17, 2010

Hi all, I ran into the follow behavior while making sure Django works correctly on PyPy. The following behavior was observed in all tested versions of CPython (2.5, 3.1): >>> def f(**kwargs): ... print(kwargs) ... >>> kwargs = {1: 3} >>> >>> dict({}, **kwargs) {1: 3} >>> f(**kwargs) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: f() keywords must be strings >>> This behavior seems … [View More]

22 48