Mailman 3 February 2009 - Python-Dev

regrtest hangs on test_tk_guionly
by Eric Smith 06 Feb '09

06 Feb '09

In the trunk, test_tk_guionly hangs if I run it through regrtest. This is on a Fedora Core 6 box, without X installed. If I run test_tk_guionly directly, it exits saying there's no DISPLAY set, which is what I'd expect: ------8<------------------ [trunk]$ ./python Lib/test/test_ttk_guionly.py Traceback (most recent call last): File "Lib/test/test_ttk_guionly.py", line 11, in <module> raise test_support.TestSkipped("ttk not available: %s" % msg) test.test_support.TestSkipped: ttk not available: no display name and no $DISPLAY environment variable [29788 refs] ------8<------------------ If I run regrtest with (or without) -v, it hangs without any output from test_tk_guionly: ------8<------------------ ... OK test_transformer Test multiple targets on the left hand side. ... ok ---------------------------------------------------------------------- Ran 1 test in 0.020s OK test_ttk_guionly <hangs here> ------8<------------------ I'm not seeing a problem in the py3k branch. There, test_tk_guionly is skipped: ------8<------------------ test_ttk_guionly test_ttk_guionly skipped -- ttk not available: no display name and no $DISPLAY environment variable ------8<------------------ I'm not sure how to further isolate this, since I can't duplicate it when running the test by itself. I'm mostly curious if anyone else is seeing this problem. If it's just me, I'll just switch to a Mac, where the problem doesn't occur (if for no other reason, because ttk is not available). If others are seeing a problem, I'll spend some time isolating it. Is anyone else seeing this problem? Eric.

2 4

Re: [Python-Dev] [Python-checkins] r69314 - sandbox/trunk/dbm_sqlite/alt/dbdict.py
by Nick Coghlan 06 Feb '09

06 Feb '09

raymond.hettinger wrote: > Author: raymond.hettinger > Date: Thu Feb 5 23:04:00 2009 > New Revision: 69314 > > Log: > Can't get tempfile to reliably delete on error and persist otherwise. You work on Windows, don't you Raymond? What you were trying (setting tf.delete after the file was already open but before it was closed) would actually work on non-Windows platforms, since the delete flag is only checked in the close() method. On Windows, however, the tempfile code uses the _os.O_TEMPORARY flag at creation time to tell *Windows* to delete the file when it gets closed. In that case, writing to the delete attribute has no effect (since the flag has already been set) Perhaps the windows special casing should be removed so that the delete flag on named temporary files can be effectively written to on all platforms? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------------------------------------------------------------

1 0

Partial function application 'from the right'
by Ben North 06 Feb '09

06 Feb '09

Hi, My reading of the most recent set of emails on this topic is that the balance of opinion is against adding a 'partial_right' or 'partial.skip' feature. I still think such a feature would be of real use, although I can see the arguments against adding it. Is the conclusion 'no thanks', then? (I still have not had time to create an issue in the tracker and attach the patch, but will do so for completeness.) Thanks for the discussions, Ben.

2 1

Issue 4285 Review
by Ross Light 05 Feb '09

05 Feb '09

Hello, python-dev. I submitted a patch a couple weeks ago for Issue 4285, and it has been reviewed and revised. Would someone please review/commit it? Thank you. http://bugs.python.org/issue4285 Cheers, Ross Light

3 4

The interpreter accepts f(**{'5':'foo'}); is this intentional?
by Michael Haggerty 05 Feb '09

05 Feb '09

I can't find documentation about whether there are constraints imposed on the keys in the map passed to a function via **, as in f(**d). According to http://docs.python.org/reference/expressions.html#id9 , d must be a mapping. test_extcall.py implies that the keys of this map must be strings in the following test: >>> f(**{1:2}) Traceback (most recent call last): ... TypeError: f() keywords must be strings But must the keys be valid python identifiers? In particular, the following is allows by the Python 2.5.2 and the Jython 2.2.1 interpreters: >>> f(**{'1':2}) {'1': 2} Is this behavior required somewhere by the Python language spec, or is it an error that just doesn't happen to be checked, or is it intentionally undefined whether this is allowed? Michael

9 10

Warnings
by Raymond Hettinger 05 Feb '09

05 Feb '09

>> import os >>> os.tmpnam() RuntimeWarning: tmpnam is a potential security risk to your program Are these runtime warnings necessary? Suppressing these warnings is a pita for one-off uses of os.tmpnam() or os.tempnam(). I would hate for this sort of thing to propagate throughout the standard library. Some folks think eval() should never be used and the same for input(). Some folks think md5 should be removed. Some folks think pickles are the ultimate security threat. IMO, it is enough to note potential vulnerabilities in the docs. Even then, I'm not too keen on the docs being filled with lots of red-outlined pink-boxed warning signs, effectively communicating that Python itself is dangerous and unreliable. Raymond --------------------------------- Happy FUN BALL! -only $14.95- Warning: Pregnant women, the elderly and children under 10 should avoid prolonged exposure to Happy Fun Ball. Caution: Happy Fun Ball may suddenly accelerate to dangerous speeds. Happy Fun Ball Contains a liquid core, which, if exposed due to rupture, should not be touched, inhaled, or looked at. Do not use Happy Fun Ball on concrete. Discontinue use of Happy Fun Ball if any of the following occurs: Itching, Vertigo, Dizziness Tingling in extremities, Loss of balance or coordination Slurred speech, Temporary blindness, Profuse sweating, Heart palpitations If Happy Fun Ball begins to smoke, get away immediately. Seek shelter and cover head. Happy Fun Ball may stick to certain types of skin. When not in use, Happy Fun Ball should be returned to its special container and kept under refrigeration... Failure to do so relieves the makers of Happy Fun Ball, Wacky Products Incorporated, and its parent company Global Chemical Unlimited, of any and all liability. Ingredients of Happy Fun Ball include an unknown glowing substance which fell to Earth, presumably from outer space. Happy Fun Ball has been shipped to our troops in Saudi Arabia and is also being dropped by our warplanes on Iraq. Do not taunt Happy Fun Ball. Happy Fun Ball comes with a lifetime guarantee. Happy Fun Ball ACCEPT NO SUBSTITUTES!

6 6

Re: [Python-Dev] Missing operator.call
by Hrvoje Niksic 05 Feb '09

05 Feb '09

Guido van Rossum wrote: >> def call(o, *args, **kwds): >> return o(*args, **kwds) >> >> which would make call a synonym for apply (and would also provide for >> the first definition as a special case). However, with that API, it >> isn't so easy anymore to pass the same arguments to all callables >> (unless it is no arguments that you want to pass). > > My version is in line with the other operators in the operator module. > The version that binds the arguments and returns a callable is already > available as functools.partial. And it works well in the case I encountered. In fact, it works even better because it allows things like map(call, l1, l2) to apply each element of l2 to the corresponding function in l1. If there's no opposition to this, I'll post a patch to the tracker.

1 0

Re: [Python-Dev] Missing operator.call
by Hrvoje Niksic 04 Feb '09

04 Feb '09

Andrew Bennetts wrote: > A patch to add operator.caller(*args, **kwargs) may be a good idea. Your > example would then be: > > map(operator.caller(), lst) Regarding the name, note that I proposed operator.call (and operator.__call__) because it corresponds to the __call__ special method, which is analogous to how operator.neg corresponds to __neg__, operator.add to __add__, etc. The term "caller" implies creation of a new object that carries additional state, such as method name in operator.methodcaller, item in operator.itemgetter, or attr in operator.attrgetter.

5 6

[patch] Duplicate sections detection in ConfigParser
by Yannick Gingras 04 Feb '09

04 Feb '09

Greetings Pythonistas, ConfigParser as you most certainly know is a .ini parser included in the Python standard library. It's documentation mentions a DuplicateSectionError but I was puzzled after hunting a bug in our application that this error was not raised when parsing a file with duplicate sections. After looking at the code, it turns out that DuplicateSectionError is only raised when using the builder interface; the parser interface will never throw it. The attached patch is compatible with both the 2.x and the 3.x branches; it adds a `unique_sects` parameter to the constructor of RawConfigParser and a test in the parser loop that raises DuplicateSectionError if a section is seen more then once and that unique_sects is True. This is just a proof of concept and I'd like your opinion on it before working on the final version. I see two main issues regarding backward compatibility and uniformity. For uniformity `unique_sects` should also apply to the builder interface. However, if it does, it should default to True since it was the default behavior for the builder interface to raise on duplicate sections. On the other hand, the default behavior for the parser interface was to ignore duplicate sections so making `unique_sects` default to True might break existing code. To summarize, I ask you all: * Is the lack of duplicates detection in the parser a problem worth addressing? * Should `unique_sects` control the builder interface? * Should it default to True? Best regards, -- Yannick Gingras http://ygingras.net

3 3

Re: [Python-Dev] Missing operator.call
by Hrvoje Niksic 04 Feb '09

04 Feb '09

Nick Coghlan wrote: > I'm somewhere between -0 and +0 though (-0 due to the lack of concrete > use cases, +0 because the improved consistency is appealing) The operator module is one of the rare cases in python where consistency is valued more than concrete use cases. But, for what it's worth, I really wished to use operator.call in my code, expected to find operator.call, and was quite surprised to find it missing.

1 0