Mailman 3 December 2008 - Python-ideas

Moving _tkinter._flatten to somewhere else
by Guilherme Polo Dec. 17, 2008

Dec. 17, 2008

Hi there, Probably many of you have seen/written/used a lot of recipes for flattening lists/tuples, several of them are similar diverging just a bit, some uses more obscure code than others, some are not fast enough, but I have noticed all those have one thing in common: none of them mention _tkinter._flatten, not even in comments (if the site allows that). Apparently _tkinter._flatten is unknown, and it being marked private doesn't help, and it also lives under _tkinter but doesn't depend on anything from tcl/tk. This _flatten has the advantage of being faster then the alternatives I have seen coded in Python, since it is done in C and its code is simple and it doesn't try to be too smart. It is also already part of Python, it is just unknown to most apparently. So, I would like to know what do you think about moving _tkinter._flatten to some other module and renaming it to "flatten" ? -- -- Guilherme H. Polo Goncalves

4 3

returning anonymous functions
by Mathias Panzenböck Dec. 16, 2008

Dec. 16, 2008

It is a very common case to return a nested function, e.g. in a decorator: def deco(f): def _f(*args,**kwargs): do_something() try: return f(*args,**kwargs) finally: do_something_different() return _f While I agree that the current way with non-anonymous functions perfectly works, it looks ugly to a lot of people. Maybe one of these syntax variants would be an option: def deco(f): return def(*args,**kwargs): do_something() try: return f(*args,**kwargs) finally: do_something_different() def deco(f): return(*args,**kwargs): do_something() try: return f(*args,**kwargs) finally: do_something_different() def deco(f): def return(*args,**kwargs): do_something() try: return f(*args,**kwargs) finally: do_something_different() Ok, the last one is not serious. This would not be some kind of anonymous function expression but an extended form of the return statement. Maybe you could do the same thing for yield? Well, I guess not, because yield can have a return value and this would be awkward: x = yield(a,b): return a + b And this would not be an option: f(yield(a,b): return a + b) But extending return and not extending yield feels wrong. What do you think? Does anyone have a better idea or is the current way the only thinkable for python (which might very well be the case)? -panzi

3 5

Python Isolated Environment (PIE)
by Tarek Ziadé Dec. 16, 2008

Dec. 16, 2008

Hello, I would like to propose a new mechanism in Python, to deal with package dependencies. It is described here http://tarekziade.wordpress.com/2008/12/15/python-isolated-environment-pie/ Like PJE mentioned in the blog comments, I still need to describe in details how the versions are handled, But does it sounds like a good idea ? Regards, Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

1 0

Re: [Python-ideas] This seems like a wart to me...
by Carl Johnson Dec. 15, 2008

Dec. 15, 2008

Bruce Leban wrote: > [i for i in s.split(x) if i] is simple enough if I don't know how to > write "(" + re.escape(x) + ")+". The point of the dropempty keyword would be less the dropempty=True case as the s.split(None, dropempty=False) case, which would otherwise require a regexp. -- Carl

4 3

Re: [Python-ideas] This seems like a wart to me...
by Carl Johnson Dec. 13, 2008

Dec. 13, 2008

Ron Adam wrote: > These examples was just what a "new" programmer might attempt. I > have a feeling that most new programmers do not attempt regular > expressions ie.. the re module, until sometime after they have > learned the basics of python. Feel what you like, but I assumed that .split meant .splitonchars when I was learning Python in 2007 and was confused when my script didn't work. I was also confused about why it stopped getting rid of empty strings. And I still don't know how to write regexs, so now I when I want to split on multiple chars, I end up .replace-ing a bunch first, which I recognize to be terribly inefficient, but the scripts are throwaways, so it's hardly worth the time to learn a whole other language first. -- Carl

7 11

Re: [Python-ideas] This seems like a wart to me...
by Stephen J. Turnbull Dec. 13, 2008

Dec. 13, 2008

Mike Meyer writes: > Except that if you're doing anything *interesting* - like splitting on > punctuation, which is far more common than splitting on alphanumerics > - then it's not nearly that simpl. The equivalent of > .splitset("^()-[]") is *much* more complicated than just "[^()-[]]" Yeah, it's "[][)(^-]". So much for complexity of the needed regexp (see below for difficulty of composition). > > So I don't think that lack of diagnostics explains widespread reluctance > > to even substitute ".*" for "*", but instead propose something as ugly > > as .split(list("abc")). > > It isn't the lack of diagnostics, it's the write-once nature of re's. They're hardly write-once in this context. The above regexp is hard to write, agreed, because you have to remember to move the close bracket to the start, the hyphen to the end, and the caret away from the start. (Note that there is never a need to put the close bracket and hyphen in other positions, so this is not a particularly hard rule to remember IMO YMMV.) However, precisely because of the oddity of the positions of the close bracket and hyphen it's easy enough to read once you've learned to write it. As far as I can see, that is the hardest regexp that most people will ever want to write for re.split(). Again, I just don't see that (limited) use of regular expressions makes programs harder to read or write than proliferating special case functions that provide nowhere near the power of a single regular expression-based function.

2 1

This seems like a wart to me...
by skip＠pobox.com Dec. 12, 2008

Dec. 12, 2008

Python 2 and 3 both exhibit this behavior: >>> "".split() [] >>> "".split("*") [''] >>> "".split(" ") [''] It's not at all clear to me why splitting an empty string on implicit whitespace should yield an empty list but splitting it with a non-whitespace character or explicit whitespace should yield a list with an empty string as its lone element. I realize this is documented behavior, but I can't for the life of me understand what the rationale might be for the different behaviors. Seems like a wart which might best be removed sometime in 3.x. Skip

10 18

Decimal literal?
by Chris Rebert Dec. 8, 2008

Dec. 8, 2008

With Python 3.0 being released, and going over its many changes, I was reminded that decimal numbers (decimal.Decimal) are still relegated to a library and aren't built-in. Has there been any thought to adding decimal literals and making decimal a built-in type? I googled but was unable to locate any discussion of the exact issue. The closest I could find was a suggestion about making decimal the default instead of float: http://mail.python.org/pipermail/python-ideas/2008-May/001565.html It seems that decimal arithmetic is more intuitively correct that plain floating point and floating point's main (only?) advantage is speed, but it seems like premature optimization to favor speed over correctness by default at the language level. Obviously, making decimal the default instead of float would be fraught with backward compatibility problems and thus is not presently feasible, but at the least for now Python could make it easier to use decimals and their associated nice arithmetic by having a literal syntax for them and making them built-in. So what do people think of: 1. making decimal.Decimal a built-in type, named "decimal" (or "dec" if that's too long?) 2. adding a literal syntax for decimals; I'd naively suggest a 'd' suffix to the float literal syntax (which was suggested in the brief aforementioned thread) 3. (in Python 4.0/Python 4000) making decimal the default instead of float, with floats instead requiring a 'f' suffix Obviously #1 & #2 would be shooting for Python 3.1 or later. Cheers, Chris P.S. Yay for the long-awaited release of Python 3.0! Better than can be said for Perl 6. -- Follow the path of the Iguana... http://rebertia.com

13 33

Anyone interested in zsh-style subpattern matching for fnmatch/glob?
by Erick Tryzelaar Dec. 8, 2008

Dec. 8, 2008

My project needs to extend fnmatch to support zsh-style globbing, where you can use brackets to designate subexpressions. Say you had a directory structure like this: foo/ foo.ext1 foo.ext2 bar/ foo.ext1 foo.ext2 The subexpressions will let you do patterns like this: >>> glob.glob('foo/foo.{ext1,ext2}') ['foo/foo.ext1', 'foo/foo.ext2'] >>> glob.glob('foo/foo.ext{1,2}') ['foo/foo.ext1', 'foo/foo.ext2'] >>> glob.glob('{foo,bar}') ['bar', 'foo'] >>> glob.glob('{foo,bar}/foo*') ['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2'] >>> glob.glob('{foo,bar}/foo.{ext*}') ['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2'] >>> glob.glob('{f?o,b?r}/foo.{ext*}') ['bar/foo.ext1', 'bar/foo.ext2', 'foo/foo.ext1', 'foo/foo.ext2'] Would this be interesting to anyone else? It would unfortunately break fnmatch since it currently would ignore with {} in it. It'd be easy to work around that by adding a flag or using a different function name. Anyway, here's the patch against the head of py3k. -e Index: Lib/glob.py =================================================================== --- Lib/glob.py (revision 67629) +++ Lib/glob.py (working copy) @@ -72,8 +72,8 @@ return [] -magic_check = re.compile('[*?[]') -magic_check_bytes = re.compile(b'[*?[]') +magic_check = re.compile('[*?[{]') +magic_check_bytes = re.compile(b'[*?[{]') def has_magic(s): if isinstance(s, bytes): Index: Lib/fnmatch.py =================================================================== --- Lib/fnmatch.py (revision 67629) +++ Lib/fnmatch.py (working copy) @@ -22,10 +22,11 @@ Patterns are Unix shell style: - * matches everything - ? matches any single character - [seq] matches any character in seq - [!seq] matches any char not in seq + * matches everything + ? matches any single character + [seq] matches any character in seq + [!seq] matches any char not in seq + {pat1,pat2} matches subpattern pat1 or subpattern pat2 An initial period in FILENAME is not special. Both FILENAME and PATTERN are first case-normalized @@ -84,10 +85,15 @@ There is no way to quote meta-characters. """ - i, n = 0, len(pat) + return _translate(0, pat, '')[2] + '$' + +def _translate(i, pat, end): res = '' + n = len(pat) while i < n: c = pat[i] + if c in end: + return i, c, res i = i+1 if c == '*': res = res + '.*' @@ -111,6 +117,27 @@ elif stuff[0] == '^': stuff = '\\' + stuff res = '%s[%s]' % (res, stuff) + elif c == '{': + i, sub = _translate_subexpression(i, pat) + res += sub else: res = res + re.escape(c) - return res + "$" + return i, '', res + +def _translate_subexpression(i, pat): + j = i + subexpressions = [] + while True: + j, c, res = _translate(j, pat, ',}') + subexpressions.append(res) + + if c == ',': + j += 1 + elif c == '}': + j += 1 + break + else: + # turns out we didn't have a subpattern + return j, '{' + ','.join(subexpressions) + + return j, '(' + '|'.join(subexpressions) + ')' Index: Lib/test/test_fnmatch.py =================================================================== --- Lib/test/test_fnmatch.py (revision 67629) +++ Lib/test/test_fnmatch.py (working copy) @@ -37,6 +37,12 @@ check('a', r'[!\]') check('\\', r'[!\]', 0) + check('abcdefghi', 'ab{cd,12*}ef{gh?,34}') + check('ab1234ef34', 'ab{cd,12*}ef{gh?,34}') + + check('abcdefgh', 'ab{cd,12*}ef{gh?,34}', 0) + check('ab1234ef345', 'ab{cd,12*}ef{gh?,34}', 0) + def test_mix_bytes_str(self): self.assertRaises(TypeError, fnmatch, 'test', b'*') self.assertRaises(TypeError, fnmatch, b'test', '*') Index: Lib/test/test_glob.py =================================================================== --- Lib/test/test_glob.py (revision 67629) +++ Lib/test/test_glob.py (working copy) @@ -69,6 +69,7 @@ eq(self.glob('aa?'), map(self.norm, ['aaa', 'aab'])) eq(self.glob('aa[ab]'), map(self.norm, ['aaa', 'aab'])) eq(self.glob('*q'), []) + eq(self.glob('a{?a,?b}'), map(self.norm, ['aaa', 'aab'])) def test_glob_nested_directory(self): eq = self.assertSequencesEqual_noorder @@ -89,6 +90,9 @@ [self.norm('a', 'bcd', 'efg', 'ha')]) eq(self.glob('?a?', '*F'), map(self.norm, [os.path.join('aaa', 'zzzF'), os.path.join('aab', 'F')])) + eq(self.glob('a', 'b{c,x}d', '{*}', '*a'), + [self.norm('a', 'bcd', 'efg', 'ha')]) + eq(self.glob('a', 'b{x,y}d', '{*}', '*a'), []) def test_glob_directory_with_trailing_slash(self): # We are verifying that when there is wildcard pattern which

3 3

A Wiki-style documentation with an approval process
by Ezio Melotti Dec. 1, 2008

Dec. 1, 2008

As far as I know, the only way to report a typo or change something in the documentation is actually open an issue in the bug tracker. This implies that: 1. If the user is not registered to the bug tracker he can't open the issue, and he won't probably register for a small mistake; 2. The user has to spend some time to reach the bug tracker page, open a new issue, write a brief description of the problem and possibly create and attach a patch; 3. A developer (of Python) has to read the issue, write a patch or check if the attached patch is ok and then apply it (even if I think that some developers can edit the doc directly). In my opinion this is rather clumsy and certainly not user-friendly. Even if the user is registered to the bug tracker and knows how to report an issue (and this is already a small subset of the doc readers) he may not want to go through all these step just to fix a typo. The idea is to allow all the users to edit the documentation pages directly (like a wiki), but wait the approval of a developer before apply the changes. The steps will then be: 1. The user finds a mistake, clicks on an [edit] link and fixes it; 2. A developer check if the correction is ok and approves of refuses it. This will also lead to the following benefits: 1. All the users can contribute even if they are not registered and/or they don't know how/where to report the problem; 2. The process is simpler so the users are more likely to report mistakes, spending less time; 3. If the process is easy enough, users may want to submit some example or tip that could be useful to others; 4. The developers just have to check and approve/refuse the changes. Again, this will require less time and they will be able to fix several mistakes in few minutes (if not seconds); 5. The bug tracker won't be "polluted" by issues regarding typos and other small mistakes in the doc. Problems and limitations: Even if probably there's already something like this out there, I don't know how easy it is to find/implement it. It shouldn't be too hard to write something ex-novo, but then again, someone will have to do it. Something like this works well for self-explanatory corrections (like typos), but it could not be the best when you have to explain the reasons of the change. Possible solutions are: 1. Allow the user to write an (optional) comment to the correction (e.g. "Changed xyz to match the new docstring."); 2. Open an issue where to discuss about the correction and then edit the page (some developers could have direct access to the page so they can edit them immediately -- I don't know if there's already something like that now or if they have to apply patches); 3. Have a "discussion page" like the the ones that are commonly used in wikis. I don't know how feasible this idea is, but I'd really like to have a simpler way of editing the doc. It would also be nice, if the users could contribute actively to improve the doc, adding more exampes and pointing out possible pitfalls (and the developers' approval will still assure correctness). -- Ezio Melotti

8 10