Issue5237
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2009-02-12 23:28 by terry.reedy, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
auto_number_formatter.py | eric.smith, 2009-02-13 13:30 | |||
auto_number_formatter_1.py | eric.smith, 2009-02-13 16:25 | |||
auto_number_formatter_2.py | eric.smith, 2009-02-14 10:03 | |||
auto_number_formatter_3.py | eric.smith, 2009-02-14 10:29 | |||
issue5237-0.patch | eric.smith, 2009-03-14 01:35 | |||
string27.txt | terry.reedy, 2009-04-21 23:21 | Revised string doc for implicit numeric arg names |
Messages (43) | |||
---|---|---|---|
msg81837 - (view) | Author: Terry J. Reedy (terry.reedy) * ![]() |
Date: 2009-02-12 23:28 | |
3.x str.format() format strings denote replacement fields with braces {}. Currently, replacement fields *must* contain "either the numeric index of a positional argument, or the name of a keyword argument". [lib ref / builtin types / sequence types / string methods /str.format()] For simple sequential positional replacements, such as: "{0} is {1} {2}".format('Numbering fields', 'an annoying', 'nuisance') the writer has to do what computers are so good at, counting, and what was *not* required with % interpolation, where one could write more simply "%s is %s %s" % (('Auto-numbering', 'a convenient', 'feature') . Proposal: Allow field names to be omitted for all fields in a string and then default to 0, 1, ... so one could also write "{} is {} {}".format('Auto-numbering', 'a convenient', 'feature' This proposal is currently all or nothing for simplicity of description and presumed ease of implementation. The patch to the doc could then be "If all replacement fields are left blank, then sequential indexes 0, 1, ... will be automatically inserted." inserted after the phrase quoted above. Mixing blank and non-blank specs would then be an error and raise an exception. This idea was posted today on Python-ideas thread "String formatting and named tuple". So far, +1 from Aahz, Raymond Hettinger, and Mathias Panzenbock. |
|||
msg81861 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-02-13 03:23 | |
It's easy enough to implement. Although the 'all-or-nothing' aspect is a little tough, I'll have to give it some thought. Maybe the best way to do this is to first create a string.Formatter subclass that implements it. I'll play with it and see what I come up with. From the description, I'm presuming we'd want: '{d}{s}{f}'.format(3, 'foo', 3.14) to work. |
|||
msg81865 - (view) | Author: David W. Lambert (LambertDW) | Date: 2009-02-13 03:31 | |
'{d}{s}{f}'.format(3, 'foo', 3.14) is possibly unclear, but is shorter than '{#d}{#s}{#f}'.format(...) |
|||
msg81869 - (view) | Author: David W. Lambert (LambertDW) | Date: 2009-02-13 03:56 | |
I am net yet fluent in format method. I meant ":" where "#" appeared. Anyway, I think you need the colon. If from print('{0:9}'.format(33)) you make the argument number implicit and remove the colon you'd get print('{9}'.format(33)) which does and should raise IndexError. |
|||
msg81873 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-02-13 04:07 | |
How is: '{d}{s}{f}'.format(3, 'foo', 3.14) more unclear than: '%d%s%f' % (3, 'foo', 3.14) ? But the more I think about it, the more I think it would have to be: '{:d}{:s}{:f}'.format(3, 'foo', 3.14) Since "{0:0}" is a legitimate format string, I need some way to tell whether "{0}" is missing the positional parameter or is missing the format specifier. |
|||
msg81910 - (view) | Author: Mark Dickinson (mark.dickinson) * ![]() |
Date: 2009-02-13 11:46 | |
+1 for the general idea from me too, assuming that all the details can be worked out in a sane manner. Is it worth opening a discussion about this on comp.lang.python? |
|||
msg81920 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-02-13 13:30 | |
The attached file is a mostly working version that inherits from string.Formatter. It has the following shortcomings, which would all be addressed if we go forward: - Doesn't handle escaping '{' or '}' - Doesn't handle conversion specifiers, like '!s' These are all a function of me being too lazy to write a complete parser. If anyone really wants them, I could add them. But this is just a proof of concept. Admittedly this isn't a drop-in replacement for ''.format(), but it should give a taste of what using it would be like. |
|||
msg81930 - (view) | Author: Antoine Pitrou (pitrou) * ![]() |
Date: 2009-02-13 14:09 | |
Unfortunately, `'{d}{s}{f}'.format(3, 'foo', 3.14)` can't work as you expect it to, because it already means "display the keyword arguments named `d`, `s` and `f`. (I agree that the syntax for format() strings is exceedingly tedious) On the other hand, `'{:d}{:s}{:f}'.format(3, 'foo', 3.14)` should be possible. |
|||
msg81935 - (view) | Author: David W. Lambert (LambertDW) | Date: 2009-02-13 14:39 | |
Answering first question msg81873. Without colon separator, this might be considered confusing: >>> ( ... '{d}{s}{f}{f}'.format(3, 'foo', 3.14, 2.72), ... '{d}{s}{f}{f}'.format(d=3, s='foo', f=3.14) ... ) ('3foo3.1400002.720000', '3foo3.143.14') |
|||
msg81947 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-02-13 16:25 | |
Right. The colon would be required if there's a format specifier. Or an exclamation if there's just a conversion specifier: "{!r}{:f}{!s:^10}".format('foo', 3, 10) would give: "'foo'3.000000 10 " I've attached a new version that includes format specifiers. |
|||
msg81951 - (view) | Author: Terry J. Reedy (terry.reedy) * ![]() |
Date: 2009-02-13 16:37 | |
All I am requesting is that '{} {} {}'.format(3, 'pi', 3.14) work as >>> '%s %s %s' % (3, 'pi', 3.14) '3 pi 3.14' >>> '{0} {1} {2}'.format(3, 'pi', 3.14) '3 pi 3.14' do today (3.0). I should note that the difference between typing {}, which is easy, and {1}, is more than just one keystroke because the latter requires unshift-1-shift |
|||
msg81961 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-02-13 18:36 | |
Terry J. Reedy wrote: > Terry J. Reedy <tjreedy@udel.edu> added the comment: > > All I am requesting is that > '{} {} {}'.format(3, 'pi', 3.14) work as > >>>> '%s %s %s' % (3, 'pi', 3.14) > '3 pi 3.14' >>>> '{0} {1} {2}'.format(3, 'pi', 3.14) > '3 pi 3.14' > > do today (3.0). My string.Formatter subclass (attached to this bug report) does do this: $ ./python.exe Python 2.7a0 (trunk:69516, Feb 11 2009, 14:30:31) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from auto_number_formatter_1 import MyFormatter >>> f = MyFormatter() >>> f.format('{} {} {}', 3, 'pi', 3.14) '3 pi 3.14' >>> This is just for vetting the concept, if it's accepted I'll modify ''.format(). It's not a huge change. I just want to make sure that this implements what people are expecting. The talk about '{:d}' and the like is just to make sure all the cases are addressed. I doubt it would often be used that way. > I should note that the difference between typing {}, which is easy, and > {1}, is more than just one keystroke because the latter requires > unshift-1-shift Agreed. |
|||
msg82002 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-02-14 10:03 | |
auto_number_formatter_2.py lets you experiment with this with a syntax more similar to what ''.format() looks like: $ ./python Python 2.7a0 (trunk:69608, Feb 14 2009, 04:51:18) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from auto_number_formatter_2 import formatter as _ >>> _('{} {} {}').format(3, 'pi', 3.14) '3 pi 3.14' >>> It still doesn't handle escaping '{' and '}', but is otherwise complete. If the consensus is that this is useful, I'll implement it in ''.format(), otherwise I'm done with this issue. |
|||
msg82005 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-02-14 10:28 | |
Okay, one last version. This one lets you use object access within the replacement string: >>> from auto_number_formatter_3 import formatter as _ >>> _('{} {} {}').format(3, 'pi', 3.14) '3 pi 3.14' >>> _('{:#b} {!r:^10} {.imag}').format(3, 'pi', 3j+1) "0b11 'pi' 3.0" So not it lets you add in format specifiers, conversion specifiers, and object access. At this point the improvement of leaving out the index numbers is less clear. I'll leave it for debate if this is useful. I think it probably is, if only because it's easier to explain the behavior: If you leave out the 'field name', a sequential number is added in front of the 'replacement string' (using PEP 3101 nomenclature). |
|||
msg83373 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-03-09 12:16 | |
I'm attaching a patch that delivers the basic functionality in str.format. This patch is against trunk, although it will probably work elsewhere. DO NOT USE THIS PATCH IN ANY SERIOUS WORK It doesn't implement all of the needed functionality, it probably has a memory leak, and it most likely can cause a GP fault. It does, however, handle the common cases and it will give you a taste of the feature. In particular, it doesn't handle anything other than empty braces ('{:d}' will fail). I can add this, and I think it should be added, but I just haven't had the time to finish it up. I wanted to get this posted so others can play with it and we can reach a decision if we want to add this functionality. Personally, I think it's a great improvement, and the more I play with it the more I like it. If we reach a consensus that the feature should be added, I can probably get it cleaned up and finished before PyCon. $ ./python.exe Python 2.7a0 (trunk:70244M, Mar 8 2009, 16:54:23) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> '{} {} {}'.format(1, 3.4, 'test') '1 3.4 test' >>> '{} {1}'.format(1, 2) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: cannot switch from automatic field numbering to manual field specification >>> |
|||
msg83374 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-03-09 12:19 | |
Also note that this patch causes a few tests to fail, since they're trying to ensure that '{}'.format will fail. If we go forward I'll address that too, of course. |
|||
msg83394 - (view) | Author: Guido van Rossum (gvanrossum) * ![]() |
Date: 2009-03-09 16:51 | |
Please go ahead and finish this. I'm glad this is going in! |
|||
msg83409 - (view) | Author: Nick Coghlan (ncoghlan) * ![]() |
Date: 2009-03-09 22:29 | |
Excellent feature - with this, I would actually see some hope for dropping all of my remaining uses of %-formatting at some point in the future. |
|||
msg83414 - (view) | Author: Senthil Kumaran (orsenthil) * ![]() |
Date: 2009-03-10 05:36 | |
Would someone like to point the python-ideas discussion which rationalizes this request? And what would be written in the documentation? As much as I understand this, emptry braces {} for replacement fields is kind of unseen and leaves much thinking if this can be simplified, just as % or # or any other character instead of a opening { and closing }. |
|||
msg83418 - (view) | Author: Ezio Melotti (ezio.melotti) * ![]() |
Date: 2009-03-10 07:14 | |
http://mail.python.org/pipermail/python-ideas/2009-February/002873.html |
|||
msg83422 - (view) | Author: Nick Coghlan (ncoghlan) * ![]() |
Date: 2009-03-10 09:13 | |
Terry covered how to document the feature in his original description of the proposal. After the phrase "either the numeric index of a positional argument, or the name of a keyword argument." in the docs, add a sentence along the lines of the following: "If the index/name is left out for all replacement fields, then the sequential values 0, 1, ... will be automatically inserted." |
|||
msg83423 - (view) | Author: Nick Coghlan (ncoghlan) * ![]() |
Date: 2009-03-10 09:34 | |
It may also be worth explicitly stating the following in the docs: "Note that automatically numbered and explcitly namged/numbered replacement fields cannot be mixed in a single format string". (This could probably be relegated to a footnote). This proposal is also significantly better defined than the rather bizarre behaviour seen in the equivalent situation with %-formatting: >>> "%s %(name)s" % dict(name="Hmm") "{'name': 'Hmm'} Hmm" >>> "%s %(name)s %s" % dict(name="Hmm") Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: not enough arguments for format string >>> "%s %(name)s %s" % (dict(name="Hmm"), "dodgy") Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: format requires a mapping |
|||
msg83546 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-03-13 23:51 | |
I'm thinking of allowing you to mix keywords and auto-numbering, but not manual numbering and auto-numbering. This would be so we could do: >>> '{:{fmt}} {:{fmt}}'.format(3.1415, 2.71828, fmt='1.4f') 'pi=3.1415 e=2.7183' Unfortunately the ':' is required, because if it's not there you have 2 braces next to each other, which is the escape sequence for a single brace. |
|||
msg83547 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-03-13 23:53 | |
Copy and paste error. That should be: >>> 'pi={:{fmt}} e={:{fmt}}'.format(3.1415, 2.71828, fmt='1.4f') 'pi=3.1415 e=2.7183' |
|||
msg83559 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-03-14 01:19 | |
Should string.Format also support auto-numbering? It seems like it should, but I'm not convinced it's possible without modifying the signatures to the public methods, in particular get_field(). The design of string.Format doesn't support state that is created in format() or vformat() and is passed in to get_field(). I could use object state in the string.Format instance, but that doesn't work well, due to the fact that format() can be called multiple times per instance lifetime. string.Format really needs to have no state of its own, for example in the case where a single instance is being used by multiple threads or if it calls the same instance of itself recursively. I'm going to punt on this for now. |
|||
msg83560 - (view) | Author: Guido van Rossum (gvanrossum) * ![]() |
Date: 2009-03-14 01:20 | |
Not sure if that's worth it -- doesn't sound like the people who would need that feature would mind much using explicit numbering. Let's try KISS. |
|||
msg83561 - (view) | Author: Guido van Rossum (gvanrossum) * ![]() |
Date: 2009-03-14 01:23 | |
(I meant that as a reply to the {:{fmt}} example, but it applies to your later post too. :-) |
|||
msg83565 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-03-14 01:35 | |
I believe this patch is complete. I need to add tests and documentation, but the code itself should be finished. Here's the normal case: >>> '{} {}'.format('test', 0) 'test 0' It also handles error checking: >>> '{1} {}'.format('test', 0) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: cannot switch from manual field specification to automatic field numbering >>> '{} {1}'.format('test', 0) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: cannot switch from automatic field numbering to manual field specification You can use named fields along with auto-numbered fields: >>> '{test} {}'.format(1, test=2) '2 1' You can nest either named or auto-numbered fields: >>> '{:^{}}'.format('x', 10) ' x ' >>> 'pi={:{fmt}} {:{fmt}}'.format(3.1415, 2.71828, fmt='1.4f') 'pi=3.1415 2.7183' Attribute access is supported: >>> '{.__abs__}'.format(0) "<method-wrapper '__abs__' of int object at 0x85db8f8>" As is subscripting: >>> '{[x]}'.format({'x':4}) '4' >>> '{[1]}'.format([1, 2]) '2' I'll work on the tests over the weekend, then commit to trunk and py3k. We need to decide what to do about string.Formatter (which I just realized I erroneously called string.Format in the previous message). |
|||
msg83567 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-03-14 01:49 | |
About '{:{fmt}}' and other wacky combinations, like '{.__doc__}': It's much easier and cleaner in the code to allow these cases than it would be to disallow them. And I rather like the '{:{fmt}}' example! I suggest leaving them in. They might be useful, and it makes the implementation cleaner. I think it will be easier to document, as well. There are no special cases to describe: If the field name is omitted, it's auto-numbered with a sequential index number. You can't mix auto-numbering and manual specification of indexes. As for string.Formatter, I agree we should leave it alone. I'd be surprised if anyone is actually using it, anyway. But I'd love to hear otherwise. |
|||
msg83570 - (view) | Author: Guido van Rossum (gvanrossum) * ![]() |
Date: 2009-03-14 02:44 | |
> About '{:{fmt}}' and other wacky combinations, like '{.__doc__}': > > It's much easier and cleaner in the code to allow these cases than it > would be to disallow them. And I rather like the '{:{fmt}}' example! > > I suggest leaving them in. They might be useful, and it makes the > implementation cleaner. I think it will be easier to document, as well. > There are no special cases to describe: If the field name is omitted, > it's auto-numbered with a sequential index number. You can't mix > auto-numbering and manual specification of indexes. OK, if allowing it is simpler, I'm all for allowing it! (I thought it would be extra work. Shame on me for not looking at the code. :-) > As for string.Formatter, I agree we should leave it alone. I'd be > surprised if anyone is actually using it, anyway. But I'd love to hear > otherwise. OK. |
|||
msg83571 - (view) | Author: Nick Coghlan (ncoghlan) * ![]() |
Date: 2009-03-14 02:50 | |
Only Formatter.format_field() is particularly hard to override at the moment (for the same reason that __format__() methods are tricky to write). That said, creating a locale aware version of string formatting based on string.Formatter is such an obvious idea that I would actually be surprised if someone *hasn't* done it by now (they may not have published it anywhere, but I expect someone has implemented it for their own use). That said, I think it's OK for string.Formatter to lag the actual str.format implementation when it comes to features like this. I see it as similar to the formatting mini-language parser problem: the primary goal is to have a good implementation and syntax for str.format, while providing the tools to allow people to create alternative formatters with similar power is secondary. |
|||
msg83585 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-03-14 12:38 | |
Committed: r70364 (trunk) r70366 (py3k) The docs still need updating. If anyone with more knowledge of the documentation system than I have would like to tackle those, please feel free! |
|||
msg83604 - (view) | Author: Terry J. Reedy (terry.reedy) * ![]() |
Date: 2009-03-14 21:30 | |
Either Brandl or Peterson can and typically will change the .rst source if given the exact new text. For me to write that, I need to know the grammar you actually implemented. Did you, in essence, simply change field_name ::= (identifier | integer) ("." attribute_name | "[" element_index "]")* to (in essence) field_name ::= (identifier | integer | ) ("." attribute_name | "[" element_index "]")* with the proviso that integers and blanks not be mixed in the same string, so that{.attr} and {[dex]} become legal? Or are those still illegal because only totally blank field names are allowed, so that the new field_name rule is essentially field_name ::= ((identifier | integer) ("." attribute_name | "[" element_index "]")*) | ( ) (with the same proviso). The existing doc text after the grammar box is slightly ambiguous or contradictory in that it first says that field names *are* ints or names and then says, correctly, that they *begin* with an int or name. (I would like to fix this in addition to adding a sentence.) Hence 'blank field name' can have two slightly different meanings and hence the question above. |
|||
msg83605 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-03-14 22:05 | |
I implemented this one: field_name ::= (identifier | integer | ) ("." attribute_name | "[" element_index "]")* Which I would have written as: field_name ::= (identifier | integer)? ("." attribute_name | "[" element_index "]")* Not that it matters, of course. And the proviso is correct: blanks and integers cannot be mixed in the same string. Thanks for looking at this! |
|||
msg86043 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-04-16 20:56 | |
Terry, are you still interested in documenting this (please say yes!)? I'm hoping it can be done by the beta release. Thanks. Eric. |
|||
msg86045 - (view) | Author: Terry J. Reedy (terry.reedy) * ![]() |
Date: 2009-04-16 21:23 | |
Yes, added to 'do in next few days' list. |
|||
msg86046 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-04-16 21:27 | |
Terry J. Reedy wrote: > Terry J. Reedy <tjreedy@udel.edu> added the comment: > > Yes, added to 'do in next few days' list. Thanks so much. |
|||
msg86214 - (view) | Author: Terry J. Reedy (terry.reedy) * ![]() |
Date: 2009-04-21 00:11 | |
Suggested doc change for LibRef / StringServices / string.... / Format String Syntax 1. In the grammar box, replace the field_name line with " field_name ::= arg_name ("." attribute_name | "[" element_index "]")* arg_name ::= (identifier | integer)? " The current text ambiguously uses "field_name" for both 'field_name' and 'arg_name'. I found explaining the rule for blank arg_names in field_names easier and clearer with two separate unambiguous terms. Note: 'element_index' should be linked to its definition just as, for instance, 'attribute_name' is. Currently it is not. 2. Revise the next two paragraphs as follows (using * to indicate grammar-term italics as in the current text -- except *all* is just for emphasis): " In less formal terms, the replacement field starts with a *field_name* that specifies the object whose value is to be formatted and inserted into the output instead of the replacement field. The *field_name* is optionally followed by a *conversion* field, which is preceded by an exclamation point '!', and a *format_spec*, which is preceded by a colon ':'. These specify a non-default format for the replacement value. The *field_name* itself begins with an *arg_name* that is either a number or a keyword. If it’s a number, it refers to a positional argument of the str.format() method, and if it’s a keyword it refers to a named keyword argument. If the numerical arg_names in a format string are 0, 1, 2, ... in sequence, they can *all* be omitted (not just some) and the numbers 0, 1, 2, ... will be automatically inserted in order. The *arg_name* can be followed by any number of index or attribute expressions. An expression of the form '.name' selects the named attribute using getattr(), while an expression of the form '[index]' does an index lookup using __getitem__(). " Note: getattr and __getitem__ should be left linked as in the current text. 3. In the following examples, add ''' "From {} to {}" # Same as "From {0] to {1}" |
|||
msg86258 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-04-21 19:09 | |
Thanks, Terry. Your changes look reasonable to me. Can you commit them, or at least convert it to a patch against the existing docs? |
|||
msg86262 - (view) | Author: Terry J. Reedy (terry.reedy) * ![]() |
Date: 2009-04-21 23:21 | |
I am not a committer and cannot make patches. However, I did download http://svn.python.org/view/python/trunk/Doc/library/string.rst?revision=70650&view=markup, as string27.txt, carefully edit using the existing rst format, and upload. I trust you can make the patch and commit. |
|||
msg86263 - (view) | Author: Terry J. Reedy (terry.reedy) * ![]() |
Date: 2009-04-21 23:27 | |
PS. I first edited http://svn.python.org/view/python/branches/py3k/Doc/library/strings.rst?revision=63803&view=markup but then noticed that this goes in 2.7. My impression is that the procedure is to commit to trunk and then forward port, so I redid it as indicated above. But if you are going from 3.1 to 2.7, I will upload the 3.1 revision. |
|||
msg86264 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-04-22 00:38 | |
Thanks, Terry. I think the only changes I'll make are: arg_name: (`identifier` | `integer`)* should be: arg_name: (`identifier` | `integer`)? And leave: conversion: "r" | "s" instead of: conversion: "r" | "s" | "a" because 'a' isn't valid in 2.7. |
|||
msg86265 - (view) | Author: Eric V. Smith (eric.smith) * ![]() |
Date: 2009-04-22 00:55 | |
Documentation changes checked into trunk in r71788 and py3k in r71790. Issue closed. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:45 | admin | set | github: 49487 |
2009-04-22 00:55:30 | eric.smith | set | status: open -> closed messages: + msg86265 |
2009-04-22 00:38:36 | eric.smith | set | messages: + msg86264 |
2009-04-21 23:27:02 | terry.reedy | set | messages: + msg86263 |
2009-04-21 23:21:28 | terry.reedy | set | files:
+ string27.txt messages: + msg86262 |
2009-04-21 19:09:02 | eric.smith | set | messages: + msg86258 |
2009-04-21 00:11:58 | terry.reedy | set | messages: + msg86214 |
2009-04-16 21:27:04 | eric.smith | set | messages: + msg86046 |
2009-04-16 21:23:14 | terry.reedy | set | messages: + msg86045 |
2009-04-16 20:56:12 | eric.smith | set | messages: + msg86043 |
2009-03-14 22:05:22 | eric.smith | set | messages:
+ msg83605 stage: resolved |
2009-03-14 21:30:50 | terry.reedy | set | messages: + msg83604 |
2009-03-14 12:38:53 | eric.smith | set | priority: high messages: + msg83585 resolution: accepted |
2009-03-14 07:42:51 | eric.smith | set | files: - half-baked-not-for-real-use.patch |
2009-03-14 02:50:21 | ncoghlan | set | messages: + msg83571 |
2009-03-14 02:44:23 | gvanrossum | set | messages: + msg83570 |
2009-03-14 01:49:32 | eric.smith | set | messages: + msg83567 |
2009-03-14 01:35:42 | eric.smith | set | files:
+ issue5237-0.patch messages: + msg83565 |
2009-03-14 01:23:04 | gvanrossum | set | messages: + msg83561 |
2009-03-14 01:20:03 | gvanrossum | set | messages: + msg83560 |
2009-03-14 01:19:26 | eric.smith | set | messages: + msg83559 |
2009-03-13 23:53:14 | eric.smith | set | messages: + msg83547 |
2009-03-13 23:51:03 | eric.smith | set | messages: + msg83546 |
2009-03-10 09:34:15 | ncoghlan | set | messages: + msg83423 |
2009-03-10 09:13:56 | ncoghlan | set | messages: + msg83422 |
2009-03-10 07:14:23 | ezio.melotti | set | messages: + msg83418 |
2009-03-10 05:36:56 | orsenthil | set | nosy:
+ orsenthil messages: + msg83414 |
2009-03-09 22:29:06 | ncoghlan | set | nosy:
+ ncoghlan messages: + msg83409 |
2009-03-09 16:51:01 | gvanrossum | set | nosy:
+ gvanrossum messages: + msg83394 |
2009-03-09 12:19:04 | eric.smith | set | messages: + msg83374 |
2009-03-09 12:17:02 | eric.smith | set | files:
+ half-baked-not-for-real-use.patch messages: + msg83373 keywords: + patch |
2009-02-14 10:31:06 | eric.smith | set | files:
+ auto_number_formatter_3.py messages: + msg82005 |
2009-02-14 10:03:50 | eric.smith | set | files:
+ auto_number_formatter_2.py messages: + msg82002 |
2009-02-14 01:33:43 | eric.smith | set | assignee: eric.smith |
2009-02-13 18:36:55 | eric.smith | set | messages: + msg81961 |
2009-02-13 16:37:11 | terry.reedy | set | messages: + msg81951 |
2009-02-13 16:25:57 | eric.smith | set | files:
+ auto_number_formatter_1.py messages: + msg81947 |
2009-02-13 14:39:06 | LambertDW | set | messages: + msg81935 |
2009-02-13 14:09:43 | pitrou | set | nosy:
+ pitrou messages: + msg81930 |
2009-02-13 13:30:11 | eric.smith | set | files:
+ auto_number_formatter.py messages: + msg81920 |
2009-02-13 11:46:32 | mark.dickinson | set | nosy:
+ mark.dickinson messages: + msg81910 |
2009-02-13 09:48:45 | ezio.melotti | set | nosy: + ezio.melotti |
2009-02-13 04:07:23 | eric.smith | set | messages: + msg81873 |
2009-02-13 03:56:15 | LambertDW | set | messages: + msg81869 |
2009-02-13 03:31:55 | LambertDW | set | nosy:
+ LambertDW messages: + msg81865 |
2009-02-13 03:23:38 | eric.smith | set | messages: + msg81861 |
2009-02-13 03:06:45 | benjamin.peterson | set | nosy: + eric.smith |
2009-02-13 00:16:15 | pitrou | set | versions: + Python 2.7 |
2009-02-12 23:28:48 | terry.reedy | create |