Mailman 3 June 2011 - Python-ideas

inheriting docstrings and mutable docstings for classes
by Eric Snow 10 Jun '11

10 Jun '11

I noticed that __doc__ for classes is immutable: >>> class X: ... "some doc" ... >>> X.__doc__ 'some doc' >>> X.__doc__ = "another doc" Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: attribute '__doc__' of 'type' objects is not writable That is on 3.3, but apparently it's the case all the way back to 2.2. I mentioned this on python-list and several people indicated that it should be an unnecessary restriction [1]. Someone else pointed out that docstrings also behave this way for method objects [2]. I want too see if it would be okay to make __doc__ writable for classes. I am not sure about for method objects, since I've never thought to do that, but it is analogous to class instances, where __doc__ is mutable and distinct from the class docstring. I just don't have any use cases that would dictate changing the docstring of the method object, the wrapped function, or neither when changing __doc__. Someone else on the thread indicated that perhaps docstrings should be inherited and got some support [3][4]. It makes sense to me for many, but not necessarily all, cases. However, if you don't want to inherit you can simply set an empty docstring. Docstrings impact help(), doctests, and some DSLs. I'm +1 on having __doc__ be inherited. Thanks, -eric [1] http://mail.python.org/pipermail/python-list/2011-June/1274079.html [2] http://mail.python.org/pipermail/python-list/2011-June/1274080.html [3] http://mail.python.org/pipermail/python-list/2011-June/1274099.html [4] http://mail.python.org/pipermail/python-list/2011-June/1274105.html

7 11

Re: [Python-ideas] Iteritems() function?
by Matt Billenstein 09 Jun '11

09 Jun '11

On Wed, Jun 08, 2011 at 01:25:42PM +0200, Masklinn wrote: > You could just convert everything to a dict: > > for first, second in dict(some_items).iteritems(): > # etc? That option won't necessarily preserve the order of the original sequence where perhaps it matters... m -- Matt Billenstein matt(a)vazor.com http://www.vazor.com/

3 2

Iteritems() function?
by Jan Kaliszewski 08 Jun '11

08 Jun '11

Case ==== Quite typical: iterate and do something with some_items -- a collection of 2-element items. for first, second in some_items: ... But for dicts it must use another form: for first, second in some_items.items(): ... We must know it'll be a mapping, and even then quite usual bug is to forget to add that `items()'. But sometimes it may be a dict {first: second, ...} OR a seq [(first, second), ...] and in fact we are not interested in it -- we simply want to iterate over its items... But we are forced to do type/interface check, e.g.: if isinstance(coll, collections.Mapping): for first, second in some_items.items(): ... else: for first, second in some_items: ... Idea ==== A new function: builtins.iteritems() or builtins.iterpairs() or itertools.items() or itertools.pairs() (don't know what name would be the best) -- equivalent to: def <one of the above names>(coll): iterable = (coll.items() if isinstance(coll, collections.Mapping) else coll) return iter(iterable) or maybe something like: def <one of the above names>(coll): try: iterable = coll.items() except AttributeError: iterable = coll return iter(iterable) Usage ===== Then, in our example case, we'd do simply: for first, second in iteritems(some_items): ... And we don't need to think about some_items type, whether it's a mapping or 2-tuple sequence. All we need to know is that it's a collection of 2-element items. Regards, *j

5 4

objects aware of being bound to a name
by Eric Snow 06 Jun '11

06 Jun '11

When a name is bound to an object, the object doesn't hear about it, usually. The exceptions I could think of are class and function definitions, and imports. Also, you can sneak around it using setattr/descriptors if you control the class... However, objects are otherwise (and generally) blind to their names. This is relevant when you want an object to be aware of the contexts in which it exists. It also relates to DRY issues that people bring up sometimes with regards to descriptors and namedtuple (though I'm not sure its that big a deal). Here are three approaches that satisfy this situation: 1. have assignment automatically pass the name to the __init__ when binding a new instance. 2. bind the name to __name__ on the object before calling __init__. 3. call __bound__(self, name, obj) on the object before __init__ is called (or maybe after). The first is the approach import/class/def take. You can't really generalize that, though, since most classes don't have a name parameter. Both the first and second approach only work when the object to be bound is instantiated. The second seems to work better than the first, but __name__ shouldn't be re-bound on an object every time it is involved in an assignment. It might be a good special-case, though. I like the third option because it could be tried for any name binding, from assignment to function arguments. However, that may be its downfall too. I would guess that name binding happens more than just once or twice during the course of execution <wink>. I would also guess that it would kill performance. However, I don't know the ins and outs of the compiler/runtime so I could be pleasantly wrong. In addition to __bound__, an __unbound__ could be leveraged (wait for it) to let an object know when it has been unbound from a name (during del or when another object is bound to the name). Of course you get double the performance hit from just __bound__. Like most things, this can already be done, just not cleanly. Here's an example of more or less equivalent code: class Something: def __init__(self): self._names = set() def __bound__(self, name, obj): if (name, obj) in set: return self._names.add((name, obj)) def __unbound__(self, name, obj): self._names.remove((name, obj)) obj = __import__(__file__.rsplit(".py", 1)[0]) something = Something() something.__bound__("something", obj) something.__unbound__("something", obj) something = Something() something.__bound__("something", obj) something.__unbound__("something", obj) del something So you can do it already, explicitly, but it's a mess. I wouldn't be surprised if there was a way to be smarter about when to call __bound__/__unbound__ to alleviate the performance hit, but I don't see it. I also wouldn't be surprised if there was a trivial way to do this, or if no one's brought it up because it's such an obviously bad idea! :) Maybe I just need to get go some sleep. Regardless, this idea hit me suddenly while I was working on something else. I don't remember what prompted the idea, but I at least wanted to float it out there. Even if it's a terrible idea, I think the concept of letting the bound object know how it's bound is an interesting one. It's an angle I had not considered before. Thanks, -eric

5 5

Fwd: Minor tweak to PEP 8?
by Guido van Rossum 04 Jun '11

04 Jun '11

[Correct list address] Yeah, please prepare a patch. Maybe you can send it to Barry so he can check it in. I would use 4-space indent for the "Opt:" exanple at the end though. On Sat, Jun 4, 2011 at 9:03 AM, Steven Klass <sklass(a)pointcircle.com> wrote: > Hey Barry, > You are correct - it was an artifact from the email tool.. > Guido - it appears we are reaching some consensus. Thoughts? Did you want me > to update the repo? > Continuation lines should align wrapped elements either vertically > using > Python's implicit line joining inside parentheses, brackets and braces, > or > or using a hanging indent. When using a hanging indent the following > considerations should be applied; there should be no arguments on the > first line and further indentation should be used to clearly distinguish > the itself as a continuation line. > > Yes: # Aligned with opening delimiter > foo = long_function_name(var_one, var_two, > var_three, var_four) > # More indentation included to distiguish this from the rest. > def long_function_name( > var_one, var_two, var_three, > var_four): > print(var_one) > No: # Stuff on first line forbidden when not using vertical alignment > foo = long_function_name(var_one, var_two, > var_three, var_four) > # Further indentation required as indentation is not > distiguishable > def long_function_name( > var_one, var_two, var_three, > var_four): > print(var_one) > > Opt: # Extra indentation not necessary. > foo = long_function_name( > var_one, var_two, > var_three, var_four) > > > > On Fri, Jun 3, 2011 at 11:09 AM, Barry Warsaw <barry(a)python.org> wrote: >> >> Hi Steven, >> >> On Jun 03, 2011, at 08:57 AM, Steven Klass wrote: >> >> > Continuation lines should align wrapped elements either vertically >> > using >> > Python's implicit line joining inside parentheses, brackets and >> > braces, >> > or or using a hanging indent. When using a hanging indent the >> > following >> > considerations should be applied; there should be no arguments on the >> > first line and further indentation should be used to clearly >> > distinguish >> > the itself as a continuation line. >> > >> > Yes: # Aligned with opening delimiter >> > foo = long_function_name(var_one, var_two, >> > var_three, var_four) >> -------------------------------------^ >> I'm sure that's just an email alignment bug, right? >> >> > >> > # More indentation included to distiguish this from the rest. >> > def long_function_name( >> > var_one, var_two, var_three, >> > var_four): >> > print(var_one) >> > >> > >> > No: # Stuff on first line forbidden when not using vertical >> > alignment >> > foo = long_function_name(var_one, var_two, >> > var_three, var_four) >> > >> > # Further indentation required as indentation is not >> > distiguishable >> > def long_function_name( >> > var_one, var_two, var_three, >> > var_four): >> > print(var_one) >> > >> > >> >Thoughts? >> >> That looks great to me, thanks. I would add one more example to the 'Yes' >> section to cover the case we've been talking about: >> >> # Extra indentation not necessary. >> foo = long_function_name( >> var_one, var_two, >> var_three, var_four) >> >> This doesn't say that extra indentation isn't allowed, just that it's not >> necessary, so I think it strikes the right balance. >> >> Cheers, >> -Barry > > > > -- > --- > > Steven M. Klass > > ☎ 1 (480) 225-1112 > ✉ sklass(a)pointcircle.com > -- --Guido van Rossum (python.org/~guido)

1 0

date.datetime() method to convert from date to datetime
by Evan Martin 04 Jun '11

04 Jun '11

There is a datetime.date() method for converting from a datetime to a date, but no stdlib method to do the opposite conversion. Could a date.datetime() method be added that returns a datetime with the time component set to zero? Alternatively, if the object is already a datetime, it could simply return itself. This isn't exactly hard to do in user code, but the obvious way of doing it is a bit too verbose for such a simple operation. Less verbose ways are not obvious or are error-prone, as this StackOverflow question shows: http://stackoverflow.com/questions/1937622/convert-date-to-datetime-in-pyth… -- Evan Martin

4 6

Adding 'bytes' as alias for 'latin_1' codec.
by INADA Naoki 03 Jun '11

03 Jun '11

Hi, all. There are some situation that I want to use bytes as a string in real world. (I use the 'bstr' for bytes as a string below) Sadly, Python 3's bytes is not bytestring. For example, when I want to make 'cat -n' that is transparent to encoding, Python 3 doesn't permit b'{0:6d}'.format(n) and '{0:6d}'.format(n).encode('ascii') is circuitous way against simple requirements. I think the best way to handle such situation with Python 3 is using 'latin1' codec. For example, encoding transparent 'cat -n' is: import sys fin = open(sys.stdin.fileno(), 'r', encoding='latin1') fout = open(sys.stdout.fileno(), 'w', encoding='latin1') for n, L in enumerate(fin): fout.write('{0:5d}\t{1}'.format(n, L)) If using 'latin1' is Pythonic way to handle encoding transparent string, I think Python should provide another alias like 'bytes'. Any thoughts? -- INADA Naoki <songofacandy(a)gmail.com>

16 57

Minor tweak to PEP 8?
by Mike Meyer 02 Jun '11

02 Jun '11

PEP eight has an interesting omission in the "Code Layout" section. It doesn't say how to indent continuation lines when code is wrapped to comply with the line length limits. It has examples, but no textual guides. Which means you can do a rock-stupid word warp (with no indentation on the continuation lines), point at the resulting mess, and say "See? If we follow this part of the PEP, we get really ugly code!". Mail doing just that is what prompted this suggestion. I therefore propose adding a sentence or two to this section, something along the lines of: The continuation line(s) should be indented to reflect the structure of the statement being continued. This should be at least one space beyond the first open parenthesis that is not closed on the continued line, if present. Nothing hard and fast, just a requirement to use good sense and the minimal indent resulting from doing so. <mike -- Mike Meyer <mwm(a)mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

11 20

Why does += trigger UnboundLocalError?
by Carl M. Johnson 02 Jun '11

02 Jun '11

We all know that the following code won't work because of UnboundLocalError and that to get around it, one needs to use nonlocal: >>> def accum(): ... x = 0 ... def inner(): ... x += 1 ... return x ... return inner ... >>> inc = accum() >>> inc() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 4, in inner UnboundLocalError: local variable 'x' referenced before assignment But why does this happen? Let's think about this a little more closely: += is not the same as =. A += can only happen if the left-hand term was already defined. So, why does the compiler treat this as though there were an assignment inside the function? Compare: >>> def accum(): ... x = [] ... def inner(): ... x.append(1) ... return x ... return inner ... >>> inc = accum() >>> inc() [1] >>> inc() [1, 1] >>> inc() [1, 1, 1] So, if I changed += to .append, the code suddenly works fine. Heck, I could also change it to x.__iadd__ if x happens to have that attribute. As we all know, adding an = anywhere to the function bound will cause x to be considered a local. So, for example, we can make the .append example fail by adding some unreachable code: >>> def accum(): ... x = [] ... def inner(): ... x.append(1) ... return x ... x = 0 #Won't ever be reached, but will cause x to be considered a local ... return inner ... >>> inc = accum() >>> inc() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 4, in inner UnboundLocalError: local variable 'x' referenced before assignment So, my proposal is that += by itself should not cause x to be considered a local variable. There should need to be a normal = assignment for the compiler to count x as a local. If the objection to my proposal is that I'm being "implicit and not explicit" because it would be like there's an implicit "nonlocal," my rebuttal is that we already have "implicit" nonlocals in the case of .append. -- Carl Johnson

13 24