Mailman 3 March 2009 - Python-ideas

PEP links in docs
by Zac Burns 17 Mar '09

17 Mar '09

I would like to see links to relevant PEP / mailing list docs in the main docs. For example http://docs.python.org/library/dircache.html after "Deprecated since version 2.6" could include a (PEP x.x) link where I could read why it was deprecated and probably what to use in it's place. The docs right now are quite excellent describing the "what" about everything, but often have little to say about the "why". This is a good thing, but links would surely help those that want to learn more. -- Zachary Burns (407)590-4814 Aim - Zac256FL Production Engineer (Digital Overlord) Zindagi Games

6 6

Added a function to parse str.format() mini-language specifiers
by Eric Smith 16 Mar '09

16 Mar '09

I'd like to add a function (or method) to parse str.format()'s standard mini-language format specifiers. It's hard to get right, and if PEP 378 is accepted, it gets more complex. The primary use case is for non-builtin numeric types that want to add __format__, and want it to support the same mini-language that the built in types support. For example see issue 2110, where Mark Dickinson implements his own version for Decimal, and suggests it be moved elsewhere. This function exists in Objects/stringlib/formatter.h, and will just need to be exposed to Python code. I propose a function that takes a single str (or unicode) and returns a named tuple with the appropriate values filled in. So, is such a function desirable, and if so, where would it go? I could expose it through the string module, which is where the sort-of-related Formatter class lives. It could be a method on str and unicode, but I'm not sure that's most appropriate. Eric.

4 8

Keyword same in right hand side of assignments
by Heinrich W Puschmann 16 Mar '09

16 Mar '09

Python-Ideas: Keyword same in right hand side of assignments ------------------------------------------------------------------------------------------- It is proposed to introduce a Keyword "same", to be used in the right hand side of assignments, as follows: "xx = same + 5" or "xx = 5 + same" synonymous with "xx += 5" "value = 2*same + 5" synonymous with "value =*2; value +=5" "switch = 1 - same" synonymous with "switch *-1; switch +=1" "lst = same + [5,6]" synonymous with "lst += [5,6]" "lst = [5,6] + same" synonymous with "lst = [5,6] + lst" "lst[2] = 1/same" synonymous with "lst[2] **=-1" and so on. IN GENERALITY, the effect of keyword same would be the following: The keyword same should only appear in the right hand side expression of an assignment, any number of times and wherever a name can appear. The left hand side of the assignment would have to be bound to some object. The keyword same is substituted by a name, which is bound to the object binding the left hand side of the assignment. The expression at the right hand side is evaluated. The left hand side identifyer is bound to the result of the expression. Since I am not a developer, I have no idea on how to difficult or how easy it would be to implement such a feature. As a programmer, however, I believe that it improves readability and user friendliness, and that it fully adjusts to the Python philosophy. It is very hard for me to discern, whether a similar idea has already been proposed by somebody else. I did not yet have any useful application for statements like "xx = xx.do(*args)" or "xx = yy.do(xx,*args)" or "xx = xx.do(xx,*args)" but as a matter of generalization, they should also allow subtitution of the right hand side appearances of xx by the keyword same. Heinrich Puschmann, Ulm

4 3

Re: [Python-ideas] Rough draft: Proposed format specifier for a thousands separator (discussion moved from python-dev)
by Raymond Hettinger 16 Mar '09

16 Mar '09

[spir] > Probably you know that already, but it doesn't hurt anyway. > In french and most rroman languages comma is the standard decimal sep; and either space or dot is used, when necessary, to sep > thousands. (It's veeery difficult for me to read even short numbers with commas used as thousand separator.) > > en: 1,234,567.89 > fr: 1.234.567,89 > or: 1 234 567,89 Thanks for the informative comment. It looks like your needs are best met by Proposal II where those would be written as: en_num = format(x, "12T, 2f") fr_num = format(x, "12T.,2f") or_num =format(x, "12T ,2f") Raymond

8 11

Inline assignment expression
by Jervis Whitley 15 Mar '09

15 Mar '09

http://bugs.python.org/issue1714448 had an interesting proposal that I thought might be worthwhile discussing here. if something as x: however, of greater use would be assignment expressions that allow: if (something as x) == other: # can now use x. I propose that we implement assignment expressions that would allow assignments to be made any place that expressions are currently valid. The proposal uses the (nominal) right arrow (RARROW) '->' to indicate the assignment. The form would look like this: EXPR -> VAR which translates to VAR = EXPR (EXPR) Expression (EXPR) is evaluated and assigned to target VAR. The value of EXPR is left on the top of stack. another toy example to think about: while len(expensive() -> res) == 4: dosomething(res) A patch has been uploaded to the named issue in the bug tracker. I encourage you to try it out (py3k at the moment). As I mentioned earlier the exact syntax is only nominal. We needn't use the RARROW if consensus is against that, it is a simple operation to change this to any of ('becomes', 'into', 'assigns' ... I look forward to your comments. Cheers, Jervis

8 13

Re: [Python-ideas] [Python-Dev] Rough draft: Proposed format specifier for a thousands separator (discussion moved from python-dev)
by Nick Coghlan 15 Mar '09

15 Mar '09

Joining the discussion over here to add a couple of points that I haven't seen in Raymond's PEP updates on the checkin list: 1. The Single Unix Specification apparently uses an apostrophe as a flag in prinft() %-formatting to request inclusion of a thousands separator in a locale aware way [1]. Since the apostrophe is much harder to mistake for a period than a comma is, I would modify my "just a flag" suggestion to use an apostrophe as the flag instead of a comma: [[fill]align][sign][#][0][width]['][.precision][type] The output would still use commas though: format(1234, "8.1f") --> ' 1234.0' format(1234, "8'.1f") --> ' 1,234.0' format(1234, "8d") --> ' 1234' format(1234, "8'd") --> ' 1,234' 2. PEP 3101 *already included* a way to modify the handling of format strings in a consistent way: use a custom string.Formatter subclass instead of relying on the basic str.format method. When the mini language parser is exposed (which I consider a separate issue from this PEP), a locale aware custom formatter is going to find a "include digit separators" flag far more useful than the overly explicit "use this thousands separator and this decimal separator". Cheers, Nick. [1] http://linux.die.net/man/3/printf -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------------------------------------------------------------

5 5

A real limitation of contextlib.nested()
by Nick Coghlan 15 Mar '09

15 Mar '09

I missed the discussion about potentially adding syntactic support for multiple context managers in the with statement, but figured I should mention a real limitation of contextlib.nested that *would* be fixed by adding dedicated syntactic support. There's a genuine semantic difference between this: with cmA(): with cmB(): # whatever and this: with nested(cmA(), cmB()): # whatever The latter is actually more accurately translated as: mgr1, mgr2 = cmA(), cmB(): with mgr1: with mgr2: # whatever That is, when using nested() the later context managers are created outside the scope of the earlier context managers. So, to use Christian's example from the previous discussion: with lock: with open(infile) as fin: with open(outfile, 'w') as fout: fout.write(fin.read()) Using contextlib.nested for that would be outright broken: with nested(lock, open(infile), open(outfile) as (_, fin, fout): fout.write(fin.read()) 1. The files are opened without acquiring the lock first 2. If an IOError is raised while opening "outfile", then "infile" doesn't get closed immediately I created issue 5491 [1] to point out that the contextlib.nested docs could do with being tweaked to make this limitation clearer. Dedicated syntax (such as the form that Christian proposed) would fix this problem: with lock, (open(infile) as fin), (open(outfile, 'w') as fout): fout.write(fin.read()) Of course, a custom context manager doesn't suffer any problems either: @contextmanager def synced_io(lock, infile, outfile): with lock: with open(infile) as fin: with open(outfile) as fout: yield fin, fout with synced_io(lock, infile, outfile) as (fin, fout): fout.write(fin.read()) Cheers, Nick. [1] http://bugs.python.org/issue5491 -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------------------------------------------------------------

5 5

str.split with padding
by And Clover 14 Mar '09

14 Mar '09

Here's a simple one I've reinvented in my own apps often enough that it might be worth adding to the built-in split() method: s.split(sep[, maxsplit[, pad]]) pad, if set True, would pad out the returned list with empty strings (strs/unicodes depending on returned datatype) so that the list was always (maxsplit+1) elements long. This allows one to do things like unpacking assignments: user, hostname= address.split('@', 1, True) without having to worry about exceptions when the number of ‘sep’s in the string is unexpectedly fewer than ‘maxsplit’. -- And Clover mailto:and@doxdesk.com http://www.doxdesk.com/

6 9

Re: [Python-ideas] String formatting and namedtuple
by Adam Olsen 14 Mar '09

14 Mar '09

On Wed, Feb 11, 2009 at 5:09 AM, Lie Ryan <lie.1296(a)gmail.com> wrote: > On Wed, Feb 11, 2009 at 7:41 PM, Adam Olsen <rhamph(a)gmail.com> wrote: > >> Exposing a dict API would pollute namedtuple. > > What do you mean by "pollute namedtuple"? I just mean that we don't want to add a bunch of extra options and features that'll only be appropriate for rare special cases. >> What's more, it's >> unnecessary in python 2.6/3.0: >> >> >>> print('one = {0.x}, two = {0.y}'.format(nt)) >> one = 12, two = 32 >> >> (And before you ask, no, I don't think it's worth adding the dict API >> just to make old-style formatting a tiny bit easier.) > > Is % interpolation deprecated? I've never heard of that... There's no plans to remove it in the near future, so it's not deprecated, and there's no problem using it when it's convenient. However, .format() obsoletes it. .format() is significantly more powerful for reasons just like this. There's no reason to add new features to % interpolation with .format() around. -- Adam Olsen, aka Rhamphoryncus

17 43

String formatting utility functions
by Eric Smith 13 Mar '09

13 Mar '09

Jim Jewett wrote: > On 3/12/09, Eric Smith <eric(a)trueblade.com> wrote: >> Eric Smith wrote: >>> ... formats >>> a number based on the same settings that are in the locale, but not >>> actually use the locale. > ... > >> The key point is that it takes everything as parameters and doesn't use >> any global state. In particular, it by itself would not reference the >> locale. > > Why not? You'll need *some* default for decimal_point, and the one > from localeconv makes at least as much sense as a hard-coded default. I guess you could do this, but I can't see it ever actually being used that way. Do you really want to only specify that you're using commas for thousands, then find that someone has switched the locale to one where a comma is the decimal character? new_util_func(1234.56, thousands_sep=',') '1,234,56' Best to be explicit on what you're expecting. My use case for this function is one where all of the arguments are known and specified every time. Specifically it's for implementing 'n' formatting for Decimal or other numeric types. You will either know the arguments, or want to use every one of them from the locale. If you're using the locale, just call localeconv() and use every value you get back. I don't have a mix-and-match use case. Eric.

1 0