Re: [Python-Dev] binary trees. Review obmalloc.c
Vladimir 'Yu' Stepanov wrote: Yes. I understood it when resulted a set example. However, as I just said, people usually don't remove items from just-sorted lists, they tend to iterate over them via 'for i in list:' . Such problem arises at creation of the list of timers. For a list of timers/timeout events, a priority queue is often the best data structure, which is already available through the heapq module. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
On 5/5/06, Nick Coghlan [EMAIL PROTECTED] wrote: Mike Orr wrote: On 5/4/06, Paul Moore [EMAIL PROTECTED] wrote: (But all the current proposals seem to build on os.path, so maybe I should assume otherwise, that os.path will remain indefinitely...) They build on os.path because that's what we're familiar with using. There's no reason to write the platform-specific classes until we agree on an API; that would just be work down the drain. When the new classes are in the library, we can: (one or more) - Leave os.path.foo() alone because it works and most existing programs need it. The threading module doesn't really obsolete the thread module, it just provides a higher level, more convenient API. Similarly, I don't believe it's a given that a nice path object will obsolete the low level operations. When translating a shell script to Python (or vice versa), having access to the comparable low level operations would be of benefit. I think you meant to say Perl in that sentence. In Python there should be one way to do it, and beautiful is better than ugly. The os.path functions are bad enough, but shutil.copy2 is just plain evil. Is it that much of a step to translate: Y=$(dirname $(dirname $X))/lib as y = Path(x).parent.parent + lib y = Path(x).parent.parent.join(lib) or whatever the syntax do jour is rather than y = os.path.join(os.path.dirname(os.path.dirname(x)), lib) ? -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Tim Peters wrote: Instead it would make best sense for each sprint project to work in its own branch, something SVN makes very easy, but only for those who _can_ commit. There's no way of restricting commit privileges to a particular branch? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Martin v. Löwis wrote: Tim Peters wrote: Since I hope we see a lot more of these problems in the future, what can be done to ease the pain? I don't know enough about SVN admin to know what might be realistic. Adding a pile of temporary committers comes to mind, but wouldn't really work since people will want to keep working on their branches after the sprint ends. Purely local SVN setups wouldn't work either, since sprint projects will generally have more than one worker bee, and they need to share code changes. I think Fredrik Lundh points to svk at such occasions. Allow me to make a suggestion. A few months ago, Robert Kern (scipy dev) taught me a very neat trick for this kind of problem; we were going to hack on ipython together and wanted a quick way to share code without touching the main SVN repo (though both of us have commit rights). His solution was very simple, involving just twisted and bazaar-ng (Robert had some bad experiences with SVK, though I suppose you could use that as well). I later had the occasion to test it on a multi-day sprint with other developers, and was extremely happy with the results. For that sprint, I documented the process here: http://projects.scipy.org/neuroimaging/ni/wiki/SprintCodeSharing You might find this useful. In combination with IP aliasing over a local subnet to create stable IPs, and a few named aliases in a little hosts file, a group of people can find each other's data in an extremely efficient way over a several days, sync back and forth as needed, etc. At the end of the sprint, the 'real' committers can evaluate how much of what got done they want to push to the upstream SVN servers. I hope this helps, feel free to ask for further details. Cheers, f ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] binary trees.
Josiah Carlson wrote:
Vladimir 'Yu' Stepanov [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
However, as I just said, people usually don't remove items from
just-sorted lists, they tend to iterate over them via 'for i in list:' .
Such problem arises at creation of the list of timers.
I've never seen that particular use-case.
Please understand something. I believe that trees can be useful in some
cases. However, I don't believe that they are generally useful
enough in Python, given that we already have key,value dictionaries and
sortable lists. They become even less worthwhile in Python, given the
total ordering problem that I describe later in this message.
I tiresome. It so :)
Sorry for that.
Here that I have found through Google on a line order statistic binary
tree :
http://www.cs.mcgill.ca/~cs251/OldCourses/1997/topic20/
Yes, that link does describe what an 'order statistic tree' is. One
thing to note is that you can add order statistics to any tree wih one
more field on each tree node. That is, you can have your AVL or
Red-Black tree, and add order statistics to it. Allowing tree['x'] to
return the associated value for the key 'x' (the same as a dictionary),
as well as offer the ability to do tree.select(10) to get the 10th (or
11th if one counts from 0) smallest key (or key,value), or get the 'rank'
of a key with tree.rank('x').
Thanks.
This problem has nothing to do with dictionaries and hashing, it has to
do with the fact that there may not be a total ordering on the elements
of a sequence.
It is sad. I did not know it. Therefore and have not understood.
I have looked in Google on python dev total ordering. On intentions to
correct this problem I have not found anything. It already earlier was
discussed ?
--
Vladimir Stepanov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] binary trees.
Martin v. Löwis wrote: Vladimir 'Yu' Stepanov wrote: Yes. I understood it when resulted a set example. However, as I just said, people usually don't remove items from just-sorted lists, they tend to iterate over them via 'for i in list:' . Such problem arises at creation of the list of timers. For a list of timers/timeout events, a priority queue is often the best data structure, which is already available through the heapq module. It is in most cases valid so. heapq very much approaches for these purposes. The unique problem is connected with removal of an any element from the list. -- Vladimir Stepanov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] binary trees.
Vladimir 'Yu' Stepanov [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: Vladimir 'Yu' Stepanov wrote: Yes. I understood it when resulted a set example. However, as I just said, people usually don't remove items from just-sorted lists, they tend to iterate over them via 'for i in list:' . Such problem arises at creation of the list of timers. For a list of timers/timeout events, a priority queue is often the best data structure, which is already available through the heapq module. It is in most cases valid so. heapq very much approaches for these purposes. The unique problem is connected with removal of an any element from the list. For this particular problem, usually you don't want to say, remove time 4.34252 from the heap, you want to say remove the (time,event) pair given the event X, from the heap, where you have in your heap (time, event) pairs. For hashable events, you can create a class which implements enough list-like semantics to allow it to work like a heap for event timing (__getitem__, __setitem__, __len__, .pop(-1) is about it, if I remember correctly), but also allows you to remove arbitrary events (as items are shifted around in the heap, you update pointers from a dictionary). The details are a bit annoying to get right, but it is possible. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] binary trees.
Vladimir 'Yu' Stepanov [EMAIL PROTECTED] wrote: Josiah Carlson wrote: This problem has nothing to do with dictionaries and hashing, it has to do with the fact that there may not be a total ordering on the elements of a sequence. It is sad. I did not know it. Therefore and have not understood. I have looked in Google on python dev total ordering. On intentions to correct this problem I have not found anything. It already earlier was discussed ? Not really. It has to do with how non-comparable instances compare to each other. Generally speaking, when instances aren't comparable, Python compares their type, which is actually comparing the names of types. This wouldn't be a big deal, except that: str tuple unicode True And you can actually compare str and unicode, so, if you have a str that is greater than the unicode, you run into this issue. With unicode becoming str in Py3k, we may not run into this issue much then, unless bytes are comparable to str, in which case we end up witht the same problems. Actually, according to my google of python dev total ordering, it gives me... http://mail.python.org/pipermail/python-dev/2003-March/034169.html http://mail.python.org/pipermail/python-list/2003-March/154142.html Which were earlier discussions on this topic, which are quite topical. The ultimate solution is to choose a total ordering on types and consider the problem solved. Then list.sort() and binary trees will work properly. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Nick Coghlan wrote:
So I suggest splitting the internal data into 'path elements separated
by os.sep', 'name elements separated by os.extsep'
What bothers me about that is that in many systems
there isn't any formal notion of an extension,
just a convention used by some applications.
Just because I have a . in my filename doesn't
necessarily mean I intend what follows to be
treated as an extension.
assert pth.basepath == HOMEDIR
assert pth.dirparts == ('foo', 'bar')
assert pth.nameparts == ('baz', 'tar', 'gz')
What if one of the dirparts contains a character
happening to match os.extsep? When you do
pth2 = pth[:-1], does it suddenly get split up
into multiple nameparts, even though it's actually
naming a directory rather than a file?
(This is not hypothetical -- it's a common convention
in some unix systems to use names like spam.d for
directories of configuration files.)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Mike Orr wrote: How do you do slicing and joining? If Path subclasses object, it could be done there like in the first example. But if Path subclasses string, Er, hang on, I thought the idea was that it wouldn't subclass either tuple *or* str, but would be a new class all of its own. That seems like the best idea, because it gives the most flexibility for dealing with the quirks of different systems' pathname semantics. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Greg Ewing [EMAIL PROTECTED] wrote:
So I suggest splitting the internal data into 'path elements
separated by os.sep', 'name elements separated by os.extsep'
What bothers me about that is that in many systems
there isn't any formal notion of an extension,
just a convention used by some applications.
Just because I have a . in my filename doesn't
necessarily mean I intend what follows to be
treated as an extension.
This is up to the application to find out or deduce. Python still needs a
proper support for this highly diffused conventions. I would say that *most* of
the files in my own hard-disk follow this convention (let's see: *.html, *.py,
*.sh, *.cpp, *.c, *.h, *.conf, *.jpg, *.mp3, *.png, *.txt, *.zip, *.tar, *.gz,
*.pl, *.odt, *.mid, *.so... ehi, I can't find a file which it doesn't follow
this convention). Even if you can have a Python file without extension, it
doesn't mean that an application should manually extract foo out of foo.py
just because you could also name it only foo.
assert pth.basepath == HOMEDIR
assert pth.dirparts == ('foo', 'bar')
assert pth.nameparts == ('baz', 'tar', 'gz')
What if one of the dirparts contains a character
happening to match os.extsep? When you do
pth2 = pth[:-1], does it suddenly get split up
into multiple nameparts, even though it's actually
naming a directory rather than a file?
(This is not hypothetical -- it's a common convention
in some unix systems to use names like spam.d for
directories of configuration files.)
Yes. And there is absolutely nothing wrong with it. Do you have in mind any
real-world case in which an algorithm is broken by the fact that splitext()
doesn't magically guess what's an extension and what is not? People coding
Python applications *know* that splitext() will split the string using the
rightmost dot (if any). They *know* it doesn't do anything more than that; and
that it does that on any path string, even those where the rightmost dot
doesn't indicate a real extension. They know it's not magical, in that it can't
try to guess whether it is a real extension or not, and so does the simple,
clear, mechanical thing: it splits on the right-most dot.
And even if they know this limitation (if you want to call it so, I call it
clear, consistent behaviour which applies to a not-always-consistently-used
convention), the function is still useful.
Giovanni Bajo
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Martin v. Löwis wrote: Benji York wrote: Subversion 1.3 added a path-based authorization feature to svnserve. That's what I mean by does not work fine: I would need to update to subversion 1.3. I noted that in my original message. I thought you meant that it wasn't possible at all with svnserve. A simple misunderstanding. -- Benji York ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Yet another type system -- request for comments on a SoC proposal
I'm currently revising a proposal for the Google Summer of Code, and it
was suggested that I start a thread here to get input. Apologies for the
length, but I wanted this to more than just a link to my proposal.
The short version of my proposal is: The module would provide a
system by which the manifests* of function parameters was inferred
through the testing process, and those manifests would be used to check
the arguments to function calls at runtime. In addition to a form of
runtime type checking, this information would also be used to
automatically generate up-to-date documentation.
*: I'm using the word 'manifest' to refer to the list of methods /
attributes provided by an object -- that is, what you get from `dir(obj)`.
I've built a *very* simple proof of concept here:
http://www.cs.uoregon.edu/~ryanf/verify.py
My full proposal is here:
http://www.cs.uoregon.edu/~ryanf/proposal.txt
It's been suggested that this could, instead, be an extension to one of
the lint tools; while I'm open to that suggestion it seems to me like
that would seriously change the character of the modified lint tool, as
it would be running tests rather than simply analyzing source.
So why have something automatically generate signatures, rather than
explicitly declare them? Currently, the knowledge about a function's
signature may be stored in four places (other than the function's calls):
1. The function itself: the programmer expects to be passed a group of
objects which implement certain functions, and uses them as such.
2. The tests run against the function.
3. A sequence of checks on the passed objects, though the author may
trust the function user to pass the right thing.
4. The documentation for the function, though, again, the author may
leave that out.
The proposed module would use the knowledge embedded in the system by
the programmer in the first two points to generate the other
information. As the function changes over time, these generated items
will be kept up to date simply by re-running the new test cases.
A sample program using this module might look like the following:
import sigcheck
verify = sigcheck.decorator('./verify.pickle') # note 1
sigcheck.mode('learn')
@verify # note 2
def foo(file, b, c):
# ... do stuff ...
class A:
@verify
def foo(self, a, b):
return a * b
# and, the worst case:
@verify(('a', sigcheck.Int),# note 3.1
('b', ('m1', 'm2', 'm3')), # 3.2
('c', sigcheck.Int, sigcheck.String), # 3.3
returns=sigcheck.String,# 3.4
raises=(MyException, MyOtherExc)) # 3.5
def bar(self, a, b, c):
# ... do some stuff...
1. The infered information needs to be stored somewhere. A file could
hold the pickled data structure between testing runs.
2. This line shows the most basic use of the decorator. The system
uses inferrence for all the parameters.
3. There may be cases where the inferences are incorrect, the user
wishes to be totally explicit about certain parameters, or wishes
to fold the inferences into their code explicitly. By passing a
data structure to the decorator they may partially or completely
bypass the inferences.
1. The system will come with some common 'types' built in.
2. The user may also require manifests, free-form.
3. If a parameter may have several, very different manifests, they
may simply be listed.
4. The return type may also be specified.
5. The function may raise exceptions which are expected; these
should be specified so the inference system doesn't treat them
as errors.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Greg Ewing wrote: Nick Coghlan wrote: So I suggest splitting the internal data into 'path elements separated by os.sep', 'name elements separated by os.extsep' What bothers me about that is that in many systems there isn't any formal notion of an extension, just a convention used by some applications. Just because I have a . in my filename doesn't necessarily mean I intend what follows to be treated as an extension. This is an interesting point - I've been tinkering with this a bit (despite my best intentions about not getting distracted by the topic ;), and it's starting to look like treating directory paths and file paths identically poses significant problems for an object-oriented API. For example, appending a filename or a relative directory path to an existing directory path is fine (giving a filename or directory path as the result), but you can't do either to a filename. Listing the entries or walking a file doesn't make any sense either. And extension information is typically significant only for filenames, not for directories. When paths are just strings, the distinction doesn't matter because the instances have no inherent behaviour - it is the application that carries the state regarding whether something is meant to be a directory name or a file name. So it makes a lot more sense to have separate Dirpath and Filepath (and possibly Linkpath) objects - from an OO point of view, the methods provided for each of these kinds of filesystem entities will be significantly different. A common parent Path object may still make sense if there's sufficient overlap, though (e.g. retrieving status related information). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
On 5/6/06, Nick Coghlan [EMAIL PROTECTED] wrote: Greg Ewing wrote: Nick Coghlan wrote: So I suggest splitting the internal data into 'path elements separated by os.sep', 'name elements separated by os.extsep' What bothers me about that is that in many systems there isn't any formal notion of an extension, just a convention used by some applications. Just because I have a . in my filename doesn't necessarily mean I intend what follows to be treated as an extension. Good points, Nick and Greg. Splitting directories is unambiguous and makes the API much simpler. But filename extensions are just a convention. The user may want all, some, or no extensions split. With os.splitext() the user is explicitly saying, Split this number of extensions on this particular file. We we should not presume to automate this. How about: .splitext(max_exts=1)= (filename, list_of_extensions) Another good idea yesterday: p.parent(2) # Fulfills my .ancestor() proposal. This is an interesting point - I've been tinkering with this a bit (despite my best intentions about not getting distracted by the topic ;), and it's starting to look like treating directory paths and file paths identically poses significant problems for an object-oriented API. For example, appending a filename or a relative directory path to an existing directory path is fine (giving a filename or directory path as the result), but you can't do either to a filename. Listing the entries or walking a file doesn't make any sense either. And extension information is typically significant only for filenames, not for directories. When paths are just strings, the distinction doesn't matter because the instances have no inherent behaviour - it is the application that carries the state regarding whether something is meant to be a directory name or a file name. So it makes a lot more sense to have separate Dirpath and Filepath (and possibly Linkpath) objects - from an OO point of view, the methods provided for each of these kinds of filesystem entities will be significantly different. A common parent Path object may still make sense if there's sufficient overlap, though (e.g. retrieving status related information). Very interesting. The user knows whether he wants a file or directory, so why not force him to specify? Then we can have a standard exception if the actual filesystem object is inconsistent with the spec. -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
On May 6, 2006, at 2:40 AM, Nick Coghlan wrote:
Remember, the idea with portable path information is to *never*
store os.sep
and os.extsep anywhere in the internal data - those should only be
added when
needed to produce strings to pass to OS-specific functions or to
display to users.
If one of the path segments contained a path-splitting character,
should it automatically get quoted? (Is that even possible on all
platforms?) E.g., what would the following give me on windows?
str(Path('a', 'b\\c'))
-Edward
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
On Sat, May 06, 2006 at 12:11:59PM -0400, Edward Loper wrote:
If one of the path segments contained a path-splitting character,
should it automatically get quoted? (Is that even possible on all
platforms?) E.g., what would the following give me on windows?
str(Path('a', 'b\\c'))
AFAIK there is no way to escape path-splitting characters (directory
separators, actually) on any major platform.
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Yet another type system -- request for comments on a SoC proposal
Apologies for the double post. Had my mail client misconfigured. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Edward Loper wrote: If one of the path segments contained a path-splitting character, should it automatically get quoted? No, an exception should be raised if you try to construct a Path object containing such a name. No such object could exist in the file system, so there's no point in being able to name it. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] binary trees.
[Josiah Carlson]
...
str tuple unicode
True
And you can actually compare str and unicode, so, if you have a str that
is greater than the unicode, you run into this issue.
Oh dear -- I didn't realize we still had holes like that:
'b' () u'a' 'b'
True
We used to have a bunch of those with numeric types (like int list
long), and then hacked comparison to artificially lump all the
numeric types together (by pretending that their type names are the
empty string -- see default_3way_compare() in object.c:
/* different type: compare type names; numbers are smaller */
if (PyNumber_Check(v))
vname = ;
).
That ensures, e.g., that int list and long list, despite that
int list long.
With unicode becoming str in Py3k, we may not run into this issue much
then, unless bytes are comparable to str, in which case we end up with
the same problems.
If Guido thinks about it in time :-), I expect it's more likely that
P3K will never fall back to comparing by type name; that non-equality
comparisons that currently fall back to looking at the type name will
raise exceptions instead. That's already the case for the types most
recently added to Python, like
{} set()
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: can only compare to a set
import datetime
{} datetime.datetime.now()
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: can't compare datetime.datetime to dict
{} == set()
False
{} == datetime.datetime.now()
False
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3101 Update
I've updated PEP 3101 based on the feedback collected so far.
-
PEP: 3101
Title: Advanced String Formatting
Version: $Revision: 45928 $
Last-Modified: $Date: 2006-05-06 18:49:43 -0700 (Sat, 06 May 2006) $
Author: Talin talin at acm.org
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 16-Apr-2006
Python-Version: 3.0
Post-History: 28-Apr-2006, 6-May-2006
Abstract
This PEP proposes a new system for built-in string formatting
operations, intended as a replacement for the existing '%' string
formatting operator.
Rationale
Python currently provides two methods of string interpolation:
- The '%' operator for strings. [1]
- The string.Template module. [2]
The scope of this PEP will be restricted to proposals for built-in
string formatting operations (in other words, methods of the
built-in string type).
The '%' operator is primarily limited by the fact that it is a
binary operator, and therefore can take at most two arguments.
One of those arguments is already dedicated to the format string,
leaving all other variables to be squeezed into the remaining
argument. The current practice is to use either a dictionary or a
tuple as the second argument, but as many people have commented
[3], this lacks flexibility. The all or nothing approach
(meaning that one must choose between only positional arguments,
or only named arguments) is felt to be overly constraining.
While there is some overlap between this proposal and
string.Template, it is felt that each serves a distinct need,
and that one does not obviate the other. In any case,
string.Template will not be discussed here.
Specification
The specification will consist of 4 parts:
- Specification of a new formatting method to be added to the
built-in string class.
- Specification of a new syntax for format strings.
- Specification of a new set of class methods to control the
formatting and conversion of objects.
- Specification of an API for user-defined formatting classes.
String Methods
The build-in string class will gain a new method, 'format',
which takes takes an arbitrary number of positional and keyword
arguments:
The story of {0}, {1}, and {c}.format(a, b, c=d)
Within a format string, each positional argument is identified
with a number, starting from zero, so in the above example, 'a' is
argument 0 and 'b' is argument 1. Each keyword argument is
identified by its keyword name, so in the above example, 'c' is
used to refer to the third argument.
The result of the format call is an object of the same type
(string or unicode) as the format string.
Format Strings
Brace characters ('curly braces') are used to indicate a
replacement field within the string:
My name is {0}.format('Fred')
The result of this is the string:
My name is Fred
Braces can be escaped using a backslash:
My name is {0} :-\{\}.format('Fred')
Which would produce:
My name is Fred :-{}
The element within the braces is called a 'field'. Fields consist
of a 'field name', which can either be simple or compound, and an
optional 'conversion specifier'.
Simple field names are either names or numbers. If numbers, they
must be valid base-10 integers; if names, they must be valid
Python identifiers. A number is used to identify a positional
argument, while a name is used to identify a keyword argument.
Compound names are a sequence of simple names seperated by
periods:
My name is {0.name} :-\{\}.format(dict(name='Fred'))
Compound names can be used to access specific dictionary entries,
array elements, or object attributes. In the above example, the
'{0.name}' field refers to the dictionary entry 'name' within
positional argument 0.
Each field can also specify an optional set of 'conversion
specifiers' which can be used to adjust the format of that field.
Conversion specifiers follow the field name, with a colon (':')
character separating the two:
My name is {0:8}.format('Fred')
The meaning and syntax of the conversion specifiers depends on the
type of object that is being formatted, however many of the
built-in types will recognize a standard set of conversion
specifiers.
The conversion specifier consists of a sequence of zero or more
characters, each of which can consist of any printable character
except for a non-escaped '}'.
Conversion specifiers can themselves contain replacement fields;
this will be described in a later section. Except for this
replacement, the format() method does not attempt to intepret the
conversion specifiers in any way; it merely passes all of the
characters between the
