Mailman 3 November 2010 - Python-ideas

PEP 3151 - Reworking the OS and IO exception hierarchy (again)
by Antoine Pitrou 12 Nov '10

12 Nov '10

Hello, Georg (who manages the 3.2 release) suggested that I push PEP 3151 (*) in the hope that it can get in before the 3.2 feature freeze. Is there any consensus that PEP 3151 should get in 3.2, or even that it should get in at all? If there's some process issue that I'm missing, I'd be glad to know about it. (*) http://www.python.org/dev/peps/pep-3151/ Thanks Antoine.

4 13

time.wallclock() or other similar stuff
by Kristján Valur Jónsson 08 Nov '10

08 Nov '10

Bringing this in from python-dev, and http://bugs.python.org/issue10278 Summary: time.clock() means two different things on Windows and Unix. So, if you need to measure time across a blocking call in a portable way, you need to use time.time() (this fact is not documented). Time.time has its own problems though, such as low resolution (compared to time.clock on windows) and being susceptible to being adjusted by the user. I proposed adding a time.wallclock() to address this issue, which would be the most suitable function for the job on any platform. The patch is an example implementation. Any thoughts? And yes, I acknowledge that the time module is complicated enough as it is :) K

17 25

Multi-line strings that respect indentation
by Daniel da Silva 07 Nov '10

07 Nov '10

On several occasions I have run into code that will do something like the following with a multiline string: def some_func(): > x, y = process_something() > > val = """ > <xml> > <myThing> > <val>%s</val> > <otherVal>%s</otherVal> > </myThing> > </xml> > """ % (x, y) > > return val > To me, this is rather ugly because it messes up the indentation of some_func(). Suppose we could have a multiline string, that when started on a line indented four spaces, ignores the first four spaces on each line of the literal when creating the actual string? In this example, I will use four quotes to start such a string. I think the syntax for this could vary though. It would be something like this: def some_func(): > x, y = process_something() > > val = """" > <xml> > <myThing> > <val>%s</val> > <otherVal>%s</otherVal> > </myThing> > </xml> > """" % (x, y) > > return val > That way, the indentation in the function would be preserved, making everything easy to scan, and the indentation in the output would not suffer. What do you all think?

15 21

Remapping a table's keys
by Andrey Fedorov 05 Nov '10

05 Nov '10

Hi guys, I often run into the problem when I need to systematically rename a bunch of keys in a table. For example, a JSON API returns an object where I need to map "Media Cost" to "adjusted_partner_cost", "Impressions" to "bid_count", etc. One way of doing this is: key_map = { 'Media Cost': 'adjusted_partner_cost', 'Impressions': 'bids_won', 'Day': 'date' } mykeys = {} for k, v in dict_from_elsewhere.items(): if k in key_map: ret[key_map[k]] = v else: ret[k] = dict_from_elsewhere[k] I would love to be able to instead say something like: mykeys = defaultdict(lambda x:x, { 'Media Cost': 'adjusted_partner_cost', 'Impressions': 'bids_won', 'Day': 'date' }) But default functions don't take parameters. Ideas? - Andrey

3 2

Factory functions (was: RE: time.wallclock() or other similar stuff)
by Kristján Valur Jónsson 03 Nov '10

03 Nov '10

Completely off topic. What's with factory functions? Why not a class? And why are there factory functions in threading.py and not classes? K -----Original Message----- From: python-ideas-bounces+kristjan=ccpgames.com(a)python.org [mailto:python-ideas-bounces+kristjan=ccpgames.com@python.org] On Behalf Of Greg Ewing Sent: Wednesday, November 03, 2010 6:19 To: python-ideas(a)python.org Subject: Re: [Python-ideas] time.wallclock() or other similar stuff However, it suggests a factory function that returns some kind of object that performs timing, rather than simply returning a time.

5 7

Re: [Python-ideas] Possible PEP 380 tweak
by Greg Ewing 02 Nov '10

02 Nov '10

I've been pondering the whole close()-returning-a-value thing I've convinced myself once again that it's a bad idea. Essentially the problem is that we're trying to make the close() method, and consequently GeneratorExit, serve two different and incompatible roles. One role (the one it currently serves) is as an emergency bail-out mechanism. In that role, when we have a stack of generators delegating via yield-from, we want things to behave as thought the GeneratorExit originates in the innermost one and propagates back out of the entire stack. We don't want any of the intermediate generators to catch it and turn it into a StopIteration, because that would give the next outer one the misleading impression that it's business as usual, but it's not. This is why PEP 380 currently specifies that, after calling the close() method of the subgenerator, GeneratorExit is unconditionally re-raised in the delegating generator. The proponents of close()-returning-a-value, however, want GeneratorExit to serve another role: as a way of signalling to a consuming generator (i.e. one that is having values passed into it using send()) that there are no more values left to pass in. It seems to me that this is analogous to a function reading values from a file, or getting them from an iterator. The behaviour that's usually required in the presence of delegation is quite different in those cases. Consider a function f1, that calls another function f2, which loops reading from a file. When f2 reaches the end of the file, this is a signal that it should finish what it's doing and return a value to f1, which then continues in its usual way. Similarly, if f2 uses a for-loop to iterate over something, when the iterator is exhausted, f2 continues and returns normally. I don't see how GeneratorExit can be made to fulfil this role, i.e. as a "producer exhausted" signal, without compromising its existing one. And if that idea is dropped, the idea of close() returning a value no longer has much motivation that I can see. So how should "producer exhausted" be signalled, and how should the result of a consumer generator be returned? As for returning the result, I think it should be done using the existing PEP 380 mechanism, i.e. the generator executes a "return", consequently raising StopIteration with the value. A delegating generator will then see this as the result of a yield-from and continue normally. As for the signalling mechanism, I think that's entirely a matter for the producer and consumer to decide between themselves. One way would be to send() in a sentinel value, if there is a suitable out-of-band value available. Another would be to throw() in some pre-arranged exception, perhaps EOFError as a suggested convention. If we look at files as an analogy, we see a similar range of conventions. Most file reading operations return an empty string or bytes object on EOF. Some, such as readline(), raise an exception, because the empty element of the relevant type is also a valid return value. As an example, a consumer generator using None as a sentinel value might look like this: def summer(): tot = 0 while 1: x = yield if x is None: break tot += x return tot and a producer using it: s = summer() s.next() for x in values: s.send(x) try: s.send(None) except StopIteration as e: result = e.value Having to catch StopIteration is a little tedious, but it could easily be encapsulated in a helper function: def close_consumer(g, sentinel): try: g.send(sentinel) except StopIteration as e: return e.value The helper function could also take care of another issue that arises. What happens if a delegating consumer carries on after a subconsumer has finished and yields again? The analogous situation with files is trying to read from a file that has already signalled EOF before. In that case, the file simply signals EOF again. Similarly, calling next() on an exhausted iterator raises StopIteration again. So, if a "finished" consumer yields again, and we are using a sentinel value, the yield should return the sentinel again. We can get this behaviour by writing our helper function like this: def close_consumer(g, sentinel): while 1: try: g.send(sentinel) except StopIteration as e: return e.value So in summary, I think PEP 380 and current generator semantics are fine as they stand with regard to the behaviour of close(). Signalling the end of a stream of values to a consumer generator can and should be handled by convention, using existing facilities. -- Greg

5 18

Accepting "?" as a valid character for identifiers
by Andre Roberge 02 Nov '10

02 Nov '10

In some languages (e.g. Scheme, Ruby, etc.), the question mark character (?) is a valid character for identifiers. I find that using it well can improve readability of programs written in those languages. Python 3 now allow all kinds of unicode characters in source code for identifiers. This is fantastic when one wants to teach programming to non-English speakers and have them use meaningful identifiers. While Python 3 does not allow ?, it does allow characters like ʔ ( http://en.wikipedia.org/wiki/Glottal_stop_%28letter%29) which can be used to good effect in writing valid identifiers such as functions that return either True or False, etc., thus improving (imo) readability. Given that one can legally mimic ? in Python identifiers, and given that the ? symbol is not used for anything in Python, would it be possible to consider allowing the use of ? as a valid character in an identifier? André

14 14