Re: [Python-Dev] pthreads, fork, import, and execvp
Neal Norwitz wrote: >> As I said: I doubt it is the right thing to do. Instead, the lock >> should get released in the child process if it is held at the >> point of the fork. >> > I'm not sure if this bug can be reproduced now, but the comment in > warnings.py points to: > >http://python.org/sf/683658 > > I didn't investigate it further. That might allow someone to create a > reproducible test case. That's a different problem, though. Here, the main thread waits for a child *thread* while holding the import lock. I don't quite understand the test case given, and I can't make it deadlock anymore (probably because of Just's fix). 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] New string method - splitquoted
On 5/17/06, Dave Cinege <[EMAIL PROTECTED]> wrote: > Very oftenmake that very very very very very very very very very often, > I find myself processing text in python that when .split()'ing a line, I'd > like to exclude the split for a 'quoted' item...quoted because it contains > whitespace or the sep char. > > For example: > > s = ' Chan: 11 SNR: 22 ESSID: "Spaced Out Wifi" Enc: On' > > If I want to yank the essid in the above example, it's a pain. But with my new > dandy split quoted method, we have a 3rd argument to .split() that we can > spec the quote delimiter where no splitting will occur, and the quote char > will be dropped: > > s.split(None,-1,'"')[5] > 'Spaced Out Wifi' > > Attached is a proof of concept patch against > Python-2.4.1/Objects/stringobject.c that implements this. It is limited to > whitespace splitting only. (sep == None) > > As implemented the quote delimiter also doubles as an additional separator for > the spliting out a substr. > > For example: > 'There is"no whitespace before these"quotes'.split(None,-1,'"') > ['There', 'is', 'no whitespace before these', 'quotes'] > > This is useful, but possibly better put into practice as a separate method?? > > Comments please. What's wrong with: re.findall(r'"[^"]*"|[^"\s]+', s) YMMV, n ___ 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] New string method - splitquoted
Heiko Wundram <[EMAIL PROTECTED]> wrote: > Don't get me wrong, I personally find this functionality very, very > interesting (I'm +0.5 on adding it in some way or another), > especially as a > part of the standard library (not necessarily as an extension to > .split()). It's already there. It's called shlex.split(), and follows the semantic of a standard UNIX shell, including escaping and other things. >>> import shlex >>> shlex.split(r"""Hey I\'m a "bad guy" for you""") ['Hey', "I'm", 'a', 'bad guy', 'for', 'you'] 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] New string method - splitquoted
Am Donnerstag 18 Mai 2006 10:21 schrieb Giovanni Bajo: > Heiko Wundram <[EMAIL PROTECTED]> wrote: > > Don't get me wrong, I personally find this functionality very, very > > interesting (I'm +0.5 on adding it in some way or another), > > especially as a > > part of the standard library (not necessarily as an extension to > > .split()). > > It's already there. It's called shlex.split(), and follows the semantic of > a standard UNIX shell, including escaping and other things. I knew about *nix shell escaping, but that isn't necessarily what I find in input I have to process (although generally it's what you see, yeah). That's why I said that it would be interesting to have a generalized method, sort of like the csv module but only for string "interpretation", which takes a dialect, and parses a string for the specified dialect. Remember, there also escaping by doubling the end of string marker (for example, '""this is not a single argument""'.split() should be parsed as ['"this','is','not','a',]), and I know programs that use exactly this format for file storage. Maybe, one could simply export the function the csv module uses to parse the actual data fields as a more prominent method, which accepts keyword arguments, instead of a Dialect-derived class. --- Heiko. ___ 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] New string method - splitquoted
Heiko Wundram <[EMAIL PROTECTED]> wrote:
>>> Don't get me wrong, I personally find this functionality very, very
>>> interesting (I'm +0.5 on adding it in some way or another),
>>> especially as a
>>> part of the standard library (not necessarily as an extension to
>>> .split()).
>>
>> It's already there. It's called shlex.split(), and follows the
>> semantic of a standard UNIX shell, including escaping and other
>> things.
>
> I knew about *nix shell escaping, but that isn't necessarily what I
> find in input I have to process (although generally it's what you
> see, yeah). That's why I said that it would be interesting to have a
> generalized method, sort of like the csv module but only for string
> "interpretation", which takes a dialect, and parses a string for the
> specified dialect.
>
> Remember, there also escaping by doubling the end of string marker
> (for example, '""this is not a single argument""'.split() should be
> parsed as ['"this','is','not','a',]), and I know programs that
> use exactly this format for file storage.
I never met this one. Anyway, I don't think it's harder than:
>>> def mysplit(s):
... """Allow double quotes to escape a quotes"""
... return shlex.split(s.replace(r'""', r'\"'))
...
>>> mysplit('""This is not a single argument""')
['"This', 'is', 'not', 'a', 'single', 'argument"']
> Maybe, one could simply export the function the csv module uses to
> parse the actual data fields as a more prominent method, which
> accepts keyword arguments, instead of a Dialect-derived class.
I think you're over-generalizing a very simple problem. I believe that
str.split, shlex.split, and some simple variation like the one above (maybe
using regular expressions to do the substitution if you have slightly more
complex cases) can handle 99.99% of the splitting cases. They surely handle
100% of those I myself had to parse.
I believe the standard library already covers common usage. There will surely
be cases where a custom lexer/splitetr will have to be written, but that's life
:)
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] New string method - splitquoted
Am Donnerstag 18 Mai 2006 12:26 schrieb Giovanni Bajo: > I believe the standard library already covers common usage. There will > surely be cases where a custom lexer/splitetr will have to be written, but > that's life The csv data field parser handles all common usage I have encountered so far, yes. ;-) But, generally, you can't (easily) get at the method that parses a data field directly, that's why I proposed to publish that method with keyword arguments. (actually, I've only tried getting at it when the csv module was still plain-python, I wouldn't even know whether the "method" is exported now that the module is written in C). I've had the need to write a custom lexer time and again, and generally, I'd love to have a little more general string interpretation facility available to spare me from writing a state automaton... But as I said before, the "simple" patch that was proposed here won't do for my case. But I don't know if it's worth the trouble to actually write a more general version, because there are quite some different pitfalls that have to be overcome... I still remain +0.5 for adding something like this to the stdlib, but only if it's overly general so that it can handle all cases the csv module can handle. --- Heiko. ___ 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] pthreads, fork, import, and execvp
Martin v. Löwis wrote: > Neal Norwitz wrote: >>> As I said: I doubt it is the right thing to do. Instead, the lock >>> should get released in the child process if it is held at the >>> point of the fork. >>> >> I'm not sure if this bug can be reproduced now, but the comment in >> warnings.py points to: >> >>http://python.org/sf/683658 >> >> I didn't investigate it further. That might allow someone to create a >> reproducible test case. > > That's a different problem, though. Here, the main thread waits for a > child *thread* while holding the import lock. I don't quite understand > the test case given, and I can't make it deadlock anymore (probably > because of Just's fix). And if I understand it correctly, it falls under the category that waiting for another thread while holding the import lock is a *really* bad idea from a thread safety point of view. The thing with the import-after-fork deadlock is that you can trigger it without even doing anything that's known not to be thread-safe. 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] New string method - splitquoted
Dave Cinege wrote:
> Very oftenmake that very very very very very very very very very often,
> I find myself processing text in python that when .split()'ing a line, I'd
> like to exclude the split for a 'quoted' item...quoted because it contains
> whitespace or the sep char.
>
> For example:
>
> s = ' Chan: 11 SNR: 22 ESSID: "Spaced Out Wifi" Enc: On'
Even if you don't like Neal's more efficient regex-based version, the
necessary utility function to do a two-pass split operation really isn't that
tricky:
def split_quoted(text, sep=None, quote='"'):
sections = text.split(quote)
result = []
for idx, unquoted_text in enumerate(sections[::2]):
result.extend(unquoted_text.split(sep))
quoted = 2*idx+1
quoted_text = sections[quoted:quoted+1]
result.extend(quoted_text)
return result
>>> split_quoted(' Chan: 11 SNR: 22 ESSID: "Spaced Out Wifi" Enc: On')
['Chan:', '11', 'SNR:', '22', 'ESSID:', 'Spaced Out Wifi', 'Enc:', 'On']
Given that this function (or a regex based equivalent) is easy enough to add
if you do need it, I don't find the idea of increasing the complexity of the
basic split API particularly compelling.
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] New string method - splitquoted
This is not an apropriate function to add as a string methods. There are too many conventions for quoting and too many details to get right. One method can't possibly handle them all without an enormous number of weird options. It's better to figure out how to do this with regexps or use some of the other approaches that have been suggested. (Did anyone mention the csv module yet? It deals with this too.) --Guido On 5/17/06, Dave Cinege <[EMAIL PROTECTED]> wrote: > Very oftenmake that very very very very very very very very very often, > I find myself processing text in python that when .split()'ing a line, I'd > like to exclude the split for a 'quoted' item...quoted because it contains > whitespace or the sep char. > > For example: > > s = ' Chan: 11 SNR: 22 ESSID: "Spaced Out Wifi" Enc: On' > > If I want to yank the essid in the above example, it's a pain. But with my new > dandy split quoted method, we have a 3rd argument to .split() that we can > spec the quote delimiter where no splitting will occur, and the quote char > will be dropped: > > s.split(None,-1,'"')[5] > 'Spaced Out Wifi' > > Attached is a proof of concept patch against > Python-2.4.1/Objects/stringobject.c that implements this. It is limited to > whitespace splitting only. (sep == None) > > As implemented the quote delimiter also doubles as an additional separator for > the spliting out a substr. > > For example: > 'There is"no whitespace before these"quotes'.split(None,-1,'"') > ['There', 'is', 'no whitespace before these', 'quotes'] > > This is useful, but possibly better put into practice as a separate method?? > > Comments please. > > Dave > > > ___ > 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/guido%40python.org > > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] pthreads, fork, import, and execvp
On 16-mei-2006, at 23:20, Martin v. Löwis wrote: Nick Coghlan wrote: Broadening the ifdef to cover all posix systems rather than just AIX might be the right thing to do. As I said: I doubt it is the right thing to do. Instead, the lock should get released in the child process if it is held at the point of the fork. I agree that we should find a repeatable test case first. Contributions are welcome. From what I understand the problem is that when a thread other than the thread calling fork is holding the import lock the child process ends up with an import lock that is locked by a no longer existing thread. The attached script reproduces the problem for me. This creates a thread to imports a module and a thread that forks. Run 'forkimport.py' to demonstrate the problem, if you set 'gHang' at the start of the script to 0 the child process doesn't perform an import and terminates normally. Wouldn't this specific problem be fixed if os.fork were to acquire the import lock before calling fork(2)? Ronald forklock.tgz Description: Binary data 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/ ronaldoussoren%40mac.com ___ 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] New string method - splitquoted
Am Donnerstag 18 Mai 2006 17:11 schrieb Guido van Rossum: > (Did anyone mention the csv module yet? It deals with this too.) Yes, mentioned it thrice. ;-) --- Heiko. ___ 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] pthreads, fork, import, and execvp
Nick Coghlan wrote: > And if I understand it correctly, it falls under the category that > waiting for another thread while holding the import lock is a *really* > bad idea from a thread safety point of view. > > The thing with the import-after-fork deadlock is that you can trigger it > without even doing anything that's known not to be thread-safe. Right. With some googling, I found that one solution is pthread_atexit: a pthread_atexit handler is a triple (before, in_parent, in_child). You set it to (acquire, release, release). When somebody forks, the pthread library will first acquire the import lock in the thread that wants to fork. Then the fork occurs, and the import lock gets then released both in the parent and in the child. I would like to see this approach implemented, but I agree with you that a test case should be created first. 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] New string method - splitquoted
On Thursday 18 May 2006 03:00, Heiko Wundram wrote:
> Am Donnerstag 18 Mai 2006 06:06 schrieb Dave Cinege:
> > This is useful, but possibly better put into practice as a separate
> > method??
>
> I personally don't think it's particularily useful, at least not in the
> special case that your patch tries to address.
Well I'm thinking along the lines of a method to extract only quoted substr's:
' this is "something" and"nothing else"but junk'.splitout('"')
['something ', 'nothing else']
Useful? I dunno
> splitters), but if you have more complicated quoting operators (such as
> """), are you sure it's sensible to implement the logic in split()?
Probably not. See below...
> 2) What should the result of "this is a \"test string".split(None,-1,'"')
> be? An exception (ParseError)?
I'd probably vote for that. However my current patch will simply play dumb and stop split'ing the rest of the line, dropping the first quote.
'this is a "test string'.split(None,-1,'"')
['this', 'is', 'a', 'test string']
> Silently ignoring the missing delimiter, and
> returning ['this','is','a','test string']? Ignoring the delimiter
> altogether, returning ['this','is','a','"test','string']? I don't think
> there's one case to satisfy all here...
Well the point to the patch is a KISS approach to extending the split() method just slightly to exclude a range of substr from split'ing by delimiter, not to engage in further text processing.
I'm dealing with this ALL the time, while processing output from other programs. (Windope) fIlenames, (poorly considered) wifi network names, etc. For me it's always some element with whitespace in it and double quotes surrounding it, that otherwise I could just use a slice to dump the quotes for the needed element
'filename: "/root/tmp.txt"'.split()[1] [1:-1]
'/root/tmp.txt'
OK
'filename: "/root/is a bit slow.txt"'.split()[1] [1:-1]
'/root/i'
NOT OK
This exact bug just zapped me in a product I have, that I didn't forsee whitespace turning up in that element.
Thus my patch:
'filename: "/root/is a bit slow.txt"'.split(None,-1,'"')[1]
'/root/is a bit slow.txt'
LIFE IS GOOD
> 3) What about escapes of the delimiter? Your current patch doesn't address
> them at all (AFAICT) at the moment,
And it wouldn't, just like the current split doesn't.
'this is a \ test string'.split()
['this', 'is', 'a', '\\', 'test', 'string']
> Don't get me wrong, I personally find this functionality very, very
> interesting (I'm +0.5 on adding it in some way or another), especially as a
> part of the standard library (not necessarily as an extension to .split()).
I'd be happy to have this in as .splitquoted(), but once you use it, it seems more to me like a natural 'ought to be there' extension to split itself.
>
> Why not write up a PEP?
Because I have no idea of the procedure. : ) URL?
Dave
___
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] New string method - splitquoted
On Thursday 18 May 2006 04:21, Giovanni Bajo wrote: > It's already there. It's called shlex.split(), and follows the semantic of > a standard UNIX shell, including escaping and other things. Not quite. As I said in my other post, simple is the idea for this, just like the split method itself. (no escaping, etc.just recognizing delimiters as an exception to the split seperatation) shlex.split() does not let one choose the separator or use a maxsplit, nor is it a pure method to strings. Dave ___ 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] pthreads, fork, import, and execvp
Ronald Oussoren wrote: > Wouldn't this specific problem be fixed if os.fork were to acquire the > import lock before calling fork(2)? Right. Of course, you need to release the lock then both in the parent and the child. Also, all places that currently do PyOs_AfterFork should get modified (i.e. fork1, and forkpty also). 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] New string method - splitquoted
Dave Cinege wrote: >> It's already there. It's called shlex.split(), and follows the >> semantic of a standard UNIX shell, including escaping and other >> things. > > Not quite. As I said in my other post, simple is the idea for this, > just like the split method itself. (no escaping, etc.just > recognizing delimiters as an exception to the split seperatation) And what's the actual problem? You either have a syntax which does not support escaping or one that it does. If it can't be escaped, there won't be any weird characters in the way, and shlex.split() will do it. If it does support escaping in a decent way, you can either use shlex.split() directly or modify the string before (like I've shown in the other message). In any case, you get your job done. Do you have any real-world case where you are still not able to split a string? And if you do, are they really so many to warrant a place in the standard library? As I said before, I think that split() and shlex.split() cover the majority of real world usage cases. > shlex.split() does not let one choose the separator > or use a maxsplit Real-world use case? Show me what you need to parse, and I assume this weird format is generated by a program you have not written yourself (or you could just change it to generate a more standard and simple format!) > , nor is it a pure method to strings. This is a totally different problem. It doesn't make it less useful nor it does provide a need for adding a new method to the string. -- 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] total ordering.
Vladimir,
Your examples seem to indicate that you've misunderstood the change
that's proposed for Python 3000. Especially this:
On 5/17/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote:
> # BEGIN: Emulation python3000
> if type(a) is not type(b) and (
> not operator.isNumberType(a) or
> not operator.isNumberType(b)
> ):
> raise TypeError("python3000: not-comparable types",
> (a,b))
> # END: Emulation python3000
Python 3000 will not do anything like this. It'll try a.__cmp__(b),
and failing that b.__cmp__(a) (but imagine this using tp_ slots
instead of actual Python method calls), and if both return
NotImplemented, it'll throw a TypeError (rather than guess, which is
what it does now).
There's a lot of legacy oddness in PyObject_RichCompare() and its many
helper functions; presumably they'll delete some of that, but it won't
be anything you care about.
Comparison with None should also continue to work as it does now,
unless I missed something.
-j
___
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] Reminder: call for proposals "Python Language and Libraries Track" for Europython 2006
Registration for Europython (3-5 July) at CERN in Geneva is now open, if you feel submitting a talk proposal there's still time until the 31th of May. If you want to talk about a library you developed, or you know well and want to share your knowledge, or about how you are making the best out of Python through inventive/elegant idioms and patterns (or if you are a language guru willing to disseminate your wisdom), you can submit a proposal for the Python Language and Libraries track """ A track about Python the Language, all batteries included. Talks about the language, language evolution, patterns and idioms, implementations (CPython, IronPython, Jython, PyPy ...) and implementation issues belong to the track. So do talks about the standard library or interesting 3rd-party libraries (and frameworks), unless the gravitational pull of other tracks is stronger. """ The full call and submission links are at: http://www.europython.org/sections/tracks_and_talks/call-for-proposals Samuele Pedroni, Python Language and Libraries Track Chair ___ 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] 2.5 schedule
I moved up the 2.5 release date by a bit. Ideally, I wanted to have the final on July 27 which corresponds to OSCON. This seems too aggressive since I haven't updated the schedule publicly. So the new schedule has rc1 slated for July 27. http://www.python.org/dev/peps/pep-0356/ So far we've only had very few 2.5 bug reports for the first 2 alphas. Hopefully people really are testing. :-) I'll continue to bug people that have action items. n ___ 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] PEP 3101 Update
On 5/6/06, Talin <[EMAIL PROTECTED]> wrote:
> I've updated PEP 3101 based on the feedback collected so far.
[http://www.python.org/dev/peps/pep-3101/]
I think this is a step in the right direction.
I wonder if we shouldn't borrow more from .NET. I read this URL that
you referenced:
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcompositeformatting.asp
They have special syntax to support field width, e.g. {0,10} formats
item 0 in a field of (at least) 10 positions wide, right-justified;
{0,-10} does the same left-aligned. This is done independently from
the type-specific formatting. (I'm not proposing that we use .NET's
format specifiers after the colon, but I'm also no big fan for keeping
the C specific stuff we have now; we should put some work in designing
something with the same power as the current %-based system for floats
and ints, that would cover it.)
.NET's solution for quoting { and } as {{ and }} respectively also
sidesteps the issue of how to quote \ itself -- since '\\{' is a
2-char string containing one \ and one {, you'd have to write either
'{0}' or r'\\{0}' to produce a single literal \ followed by
formatted item 0. Any time there's the need to quadruple a backslash I
think we've lost the battle. (Or you might search the web for Tcl
quoting hell. :-)
I'm fine with not having a solution for doing variable substitution
within the format parameters. That could be done instead by building
up the format string with an extra formatting step: instead of
"{x:{y}}".format(x=whatever, y=3) you could write
"{{x,{y}}}".format(y=3).format(x=whatever). (Note that this is subtle:
the final }}} are parsed as } followed by }}. Once the parser has seen
a single {, the first } it sees is the matching closing } and adding
another } after it won't affect it. The specifier cannot contain { or
} at all.
I like having a way to reuse the format parsing code while
substituting something else for the formatting itself.
The PEP appears silent on what happens if there are too few or too
many positional arguments, or if there are missing or unused keywords.
Missing ones should be errors; I'm not sure about redundant (unused)
ones. On the one hand complaining about those gives us more certainty
that the format string is correct. On the other hand there are some
use cases for passing lots of keyword parameters (e.g. simple web
templating could pass a fixed set of variables using **dict). Even in
i18n (translation) apps I could see the usefulness of allowing unused
parameters
On the issue of {a.b.c}: like several correspondents, I don't like the
ambiguity of attribute vs. key refs much, even though it appears
useful enough in practice in web frameworks I've used. It seems to
violate the Zen of Python: "In the face of ambiguity, refuse the
temptation to guess."
Unfortunately I'm pretty lukewarm about the proposal to support
{a[b].c} since b is not a variable reference but a literal string 'b'.
It is also relatively cumbersome to parse. I wish I could propose
{a+b.c} for this case but that's so arbitrary...
Even more unfortunately, I expect that dict key access is a pretty
important use case so we'll have to address it somehow. I *don't*
think there's an important use case for the ambiguity -- in any
particular situation I expect that the programmer will know whether
they are expecting a dict or an object with attributes.
Hm, perhaps [EMAIL PROTECTED] might work? It's not an existing binary operator.
Or perhaps # or !.
It's too late to think straight so this will have to be continued...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
