Python-ideas November 2008

python-ideas@python.org

30 participants
17 discussions

A Wiki-style documentation with an approval process

by Ezio Melotti

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

12 years

Smallest/Largest singletons

by George Sakkis

One small side-effect of not being able to compare incompatible types in 3.0 is that None cannot be used any more as the smallest element. Yes this has always been an implementation artifact and a hack, but it was very convenient none the less. Is it maybe the right time to add a builtin Smallest (and also Largest) object, i.e. two singletons so that `Smallest < x` for every x: x is not Smallest and `Largest > x` for every x: x is not Largest ? Although it's not hard to define them in pure Python and one could object with "not every n-liner needs to be a builtin", the main added value is that these will be endorsed as the standard, otherwise we risk mymodule.Smallest clashing with with yourmodule.Smallest. George

12 years

Complex rationals in Python.

by Rocco Orlando Rossi

I appreciate the inclusion of the fractions module in Python 2.6 and therefore in Python 3.0. But I feel there's something missing: no possibility for complex rationals (or arbitrary precision) integers. I was just checking the complex number support in Python, compared, for instance, to Common Lisp and Scheme, and I realized that there was this subtle omission. The inclusion of rationals and arbitrary integers is cool, but the numeric tower (say, compared to Scheme) is not complete. I don't think there would be a performance hit if complex rationals were provided. Ordinary operations on complex floats, in theory, should not be affected and handled separately. But it would be nice to be able to do: (3/4 + 1/2j) * (1/4 - j) = 11/16 - 5/8j with no loss of precision. Python is heavily used in math and science all over the world. We've even got a recent symbolic math project (sympy) that looks very promising, so I guess this could be an important issue. Note: there exists a library that implements what I'm talking about: http://calcrpnpy.sourceforge.net/clnum.html but still I personally would have liked to see this stuff included natively in the new Python 3.0.

12 years

Lock-File class: FileLock

by Mathias Panzenböck

Hi. Maybe I'm just blind and can't find it, but it seems that python has no file based lock. I wrote one using fcntl (mscvrt on windows): http://twoday.tuwien.ac.at/pub/stories/319462/ I think this would be a nice addition to pythons standard library. I called the lock/unlock methods, well, lock and unlock (and there is a trylock method, too). I just now saw the methods of threading.Lock are called acquire and release. Shall I change the method names? (a matter of s/\<lock\>/acquire/g s/\<unlock\>/release/g s/\<trylock\>/tryacquire/g) I will change it if it gets included to python that way. I like lock/unlock more, though. -panzi

12 years

Suggestion for 2.7/3.[01] - sys.isinteractive()

by skip＠pobox.com

We have a special exception handling hook written for the application platform we developed at work. Mostly it makes sure any exceptions raised get their tracebacks logged before going belly up. But it also makes sure the program does go belly up. When using bits of this platform in an interactive session it can be annoying (to say the least) for the interpreter to exit when you make a spelling error. Consequently I wanted something like: if we are not running interactively: sys.excepthook = exception_handler The only problem was to decide what the proper python-speak was for "we are not running interactively". It seemed to me that sys.argv[0] was the empty string when running interactively but that seemed fragile so I decided to ask on comp.lang.python. Peter Otten responded with hasattr(sys, "ps1") and a link to the sys module doc section where the presence of sys.ps1 only in interacive mode is documented. So now I know the proper spelling in python-speak, but that seems like a very non-obvious way to do that (and a bit fragile since it's possible, if not exactly reasonable to "del sys.ps1". It seems to me that it would be preferable if sys had an "interactive" attribute or an "isinteractive" method. Maybe in 2.7 and 3.0 or 3.1? Am I way off base? I realize that would present two ways to do it, but in my mind one would be obvious, the other not. Thx, Skip

12 years

Re: [Python-ideas] Proposal for Ruby-style anonymous block functions (that don't kill the indention)

by Carl Johnson

On 2008/11/09, at 8:15 pm, Mike Meyer wrote: > On Sun, 9 Nov 2008 16:56:55 -1000 > Carl Johnson <carl(a)carlsensei.com> wrote: > >> This list had a proposal last month to make everything an expression, >> and it has not infrequent attempts to create multi-line lambdas, >> and I >> think the reason for this is that people want a better way to create >> functions that act like Ruby-style blocks since sometimes it makes >> more sense to write the function that will be passed after the thing >> it will be passed to and not before. So, here's my proposal. I expect >> it to get rejected, but hey, someone approved @decorator, so maybe it >> will make it... > > I think you may be on to something. You've identified the real cause > of the reasons this kind of thing generates ugly code, and attempted > to deal with them. But it needs some tweaking. > >> Instead of >> >>>>> def decorator(f): >> ... def inner(*args, **kwargs): >> ... print(*args, **kwargs) >> ... return f(*args, **kwargs) >> ... return inner >> ... >> >> where the def inner comes before you know what it's going to be used >> for, why not >> >>>>> def decorator(f): >> ... return @(*args, **kwargs): >> ... print(*args, **kwargs) >> ... return f(*args, **kwargs) >> ... > > You seem to have realized *part* of the problem, and attempt to deal > with it here: > >> Caveats: This shouldn't be allowed to work with two @s in one line. >> If >> you have two of them, you should give them names ahead of time with >> def. This also should not be allowed work inside a for-, if-, with-, >> or while- statement's initial expression, since the indenting won't >> work out. > > Yup, this makes lots of sense, and would seem to eliminate some simple > ugly cases. But it doesn't deal with the real ugliness that comes with > multiple things in a statement. This would look like a godsend to > creating properties, where you need three functions that could all be > anonymous, like so: > > class Ugly(object): > x = property(@(self): > return self._x > , @(self, value): > self._x = value > , @(self), "I'm the x property"): > del self._x > > Except that that's the simple case, and it border on unreadable all by > itself. > > Maybe @() shouldn't be allowed except for the last line in a > multi-line statement? Properties have already been fixed in Python 2.6+ as far as I'm concerned, but I don't think that should be a valid use of the @, even without my caveats, since it's mixing blocks around inside an expression. The expression should be terminated before the beginning of the block. >> Also, myfunc = @(args) should be preemptively banned, since >> def is the one right way to do it. Also you shouldn't be allowed to >> do >> this to make one liners with this (as you can eg. with if- >> statements), >> since that's why there's lambda. > > I disagree with both of these, mostly on symmetry grounds. I can > already do: > > lowerfunc = lamba word: word.lower() > > why should this nifty new construct not be allowed to play? Similarly, > every statement that is followed by a block can be followed by a > simple statement, or a list of simple statements separated by > semicolons. Why is this one different? Mostly on grounds of TWOOTDI. I know people already consider "x = lambda:" to be poor style, so I want to ban bad style preemptively with @. Incidentally, does anyone know why for decorators, @lambda x: x def f(): pass is a syntax error? I guess people just don't want lambda based decorators, for whatever reason. > In particular, this fixes one of the properties of lambda's that > people complain about most often: the inability to put statements in > them. Why provide that win, only to basically make it worthless by > forcing people it to use multiple statements? I mean, this: > > newlist = sorted(words, key=lambda word, print word; word.lower()) > > would be great, but isn't allowed because lambda is restricted to an > expression. You fix it by giving us: > > newlist = sorted(words, @(word)): print word; return word.lower() > > only to turn around and day "No, this block is special, and you can't > do that here."???? I think it would look better on four lines. Maybe I'm wrong, but that's my intuition. >> And using this on the declaration line of a decorator is just crazy. > > Why? One of the most powerful languages I know of came about because > the designers let people do "crazy" things. Sure, using a @( construct > for the decorator expression is sort of pointless, but what if you > want to pass an anonymous function to a decorator. Why is: > > @magicdecorator(lambda word, word.lower()) > def function(... > > ok, but: > > @advancedmagicdecorator(@(word)): > return word.lower() > def function(... > > not ok? Ah, to be honest, I hadn't thought it through and just assumed it was impossible to make it work, since there would be two things needing indent-dedent tokens in a row. Still, isn't it a little ugly? (And remember, this proposal is not about adding power to Python, just making things more readable.) > I kinda like it, if you can figure out how to deal with things like > property. On the other hand, it smells a lot like lambda, which some > people would like removed from the language... Agreed. I fully expect the BDFL to reject this proposal, but I still think it's interesting to consider as a "solution" to the insolvable problem of multiline anonymous functions. > <mike > -- > Mike Meyer <mwm(a)mired.org> http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more > information. > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org >

12 years

Proposal for Ruby-style anonymous block functions (that don't kill the indention)

by Carl Johnson

This list had a proposal last month to make everything an expression, and it has not infrequent attempts to create multi-line lambdas, and I think the reason for this is that people want a better way to create functions that act like Ruby-style blocks since sometimes it makes more sense to write the function that will be passed after the thing it will be passed to and not before. So, here's my proposal. I expect it to get rejected, but hey, someone approved @decorator, so maybe it will make it... Instead of >>> def decorator(f): ... def inner(*args, **kwargs): ... print(*args, **kwargs) ... return f(*args, **kwargs) ... return inner ... where the def inner comes before you know what it's going to be used for, why not >>> def decorator(f): ... return @(*args, **kwargs): ... print(*args, **kwargs) ... return f(*args, **kwargs) ... ? Here's it's very straightforward that what you're doing is returning an anonymous function, and then you find out what's in the function. Similarly, >>> words = ["blah one", "Blah two", " bLAh three"] >>> sorted(words, key=@(word)): ... word = word.lower() ... word = word.replace("one", "1") ... word = word.replace("two", "2") ... word = word.replace("three", "3") ... word = word.replace(" ", "") ... return word ... [u'blah one', u'Blah two', u' bLAh three'] Which will be equivalent to: >>> words = ["blah one", "Blah two", " bLAh three"] >>> def key(word): ... word = word.lower() ... word = word.replace("one", "1") ... word = word.replace("two", "2") ... word = word.replace("three", "3") ... word = word.replace(" ", "") ... return word ... >>> sorted(words, key=key) [u'blah one', u'Blah two', u' bLAh three'] Again, I think it's clear here to be told first, "Oh, we're going to sort something" and then learn how the sorting will be done than it is to read a weird function and only after that learn what it's for. Caveats: This shouldn't be allowed to work with two @s in one line. If you have two of them, you should give them names ahead of time with def. This also should not be allowed work inside a for-, if-, with-, or while- statement's initial expression, since the indenting won't work out. Also, myfunc = @(args) should be preemptively banned, since def is the one right way to do it. Also you shouldn't be allowed to do this to make one liners with this (as you can eg. with if-statements), since that's why there's lambda. And using this on the declaration line of a decorator is just crazy. Of course, for all I know, Python's grammar is too simple to make this work with all the caveats, but if it's not, I think this might be a good way to improve readability without killing the indention-based nature of Python that we all know and love. My other thought is that if @ is deemed to be too "Perl-ish" of line noise, def could be used as the keyword instead. Or perhaps a new keyword like "block" or something. That said, I think there is a good analogy here to the existing @-decorator where things are, strictly speaking, written out of order so that the readability is improved and the function that follows is given as an argument to the initial @ line. Thoughts? -- Carl

12 years

__missing__ object/keyword

by George Sakkis

Several times I find myself using the following idiom: _Missing = object() # sentinel def foo(x, y=_Missing): if y is _Missing: do_this else: do_that The reason for using a "private" sentinel is that any python object, including None, might be a valid argument. Another option is using *args or **kwds instead of y but that obfuscates unnecessarily the function signature. It would be nice if a new object or keyword, say __missing__, was introduced as a canonical way to address this common scenario. Specifically, the only valid usages of __missing__ would be: 1. As a default argument in a callable. 2. In identity tests: <var> is __missing__ Anything else would raise either a SyntaxError (e.g. `x = __missing__`) or a RuntimeError/TypeError (e.g. `x = y` if y is __missing__). Only the interpreter could assign __missing__ to a name when binding objects to formal parameters. If this was to be accepted, a further generalization could be to allow the `var is __missing__` expression even if `var` is not a formal parameter. This would be equivalent to: try: var except NameError: expr = True else: expr = False Thoughts ? George

12 years

Python Object Notation (PyON)

by Zaur Shibzoukhov

I have added support for naming objects in dumps, cross-references and declarative support in dumps/loads too. I can't now commit changes. This night I will commit changes to sources and update project pages. Here are examples of how it works now: == Examples with loads== ===Example with recursive list=== >>> lst = pyon.loads(""" ... lst = ['foo', lst] ... lst""") >>> lst is lst[1] True ===Example with recursive dict=== >>> d = pyon.loads(""" ... d = {'a':'foo', 'b':d} ... d""") >>> d is d['b'] True ===Example with cross-references=== >>> ob = pyon.loads(""" ... lst = ['foo', lst, d] ... d = {'a':'foo', 'b':d, 'c':lst} ... [d, lst]""") >>> lst = ob[1] >>> d = ob[0] >>> lst[1] is lst True >>> d is d['b'] True >>> lst[2] is d True >>> d['c'] is lst True ===Example with recursive class and cross-references=== >>> ob = pyon.loads(""" ... c = C(parent=c, lst=lst, d=d) ... lst = ['foo', lst, d, c] ... d = {'a':'foo', 'b':d, 'c':lst, 'd':c} ... [d, lst, c]""") >>> lst = ob[1] >>> d = ob[0] >>> c = ob[2] >>> c.parent is c True >>> c.lst is lst True >>> c.d is d True >>> d is d['b'] True >>> lst[2] is d True >>> d['c'] is lst True >>> d['d'] is c True >>> lst[3] is c True ==Examples with dumps== ===Example with naming and assignments== >>> p1 = (1,2) >>> p2 = [1,2] >>> pyon.dumps([p1,p2,p1,p2], fast=False) _p__0=(1,2) _p__1=[1,2] [_p__0,_p__1,_p__0,_p__1] >>> pyon.dumps([p1,p2,p1,p2], fast=False, p1=p1,p2=p2) p1=(1,2) p2=[1,2] [p1,p2,p1,p2] ===Example with recursive list=== >>> lst = ['foo'] >>> lst.append(lst) >>> pyon.dumps(lst, fast=False) _p__0=['foo',_p__0] _p__0 >>> pyon.dumps(lst, fast=False, lst=lst) lst=['foo',lst] lst ===Example with recursive dict=== >>> d = {'a':'foo'} >>> d['b'] = d >>> pyon.dumps(d, fast=False) _p__0={'a':'foo', 'b':_p__0} _p__0 >>> pyon.dumps(d, fast=False, d=d) d={'a':'foo', 'b':d} d ===Example with recursion in class instance== class C(object): def __reduce__(self): return C, (), self.__dict__ >>> c= C() >>> c.parent = c >>> pyon.dumps(c, fast=False) _p__0=C(parent=_p__0) _p__0 >>> pyon.dumps(c, fast=False, c=c) c=C(parent=c) c ===Example with cross-refernce=== class C(object): def __reduce__(self): return C, (), self.__dict__ >>> lst = ['foo'] >>> lst.append(lst) >>> d = {'a':'bar','b':lst} >>> d['c'] = d >>> c = C() >>> c.lst = lst >>> c.d = d >>> c.parent = c >>> d['d'] = c >>> pyon.dumps([lst,d,c], fast = False, lst=lst, d=d) lst=['foo',lst] _p__1=C(lst=lst,d=d,parent=_p__1) d={'a':'bar','c':d,'b':lst,'d':_p__1} [lst,d,_p__1] Best regards, Zaur

12 years

Re: [Python-ideas] Python Object Notation (PyON)

by Zaur Shibzoukhov

I am sure that it is now too early to draw conclusions about PyON. Best regards, Zaur 2008/11/7 Josiah Carlson <josiah.carlson(a)gmail.com>: > On Thu, Nov 6, 2008 at 12:08 AM, Zaur Shibzoukhov <szport(a)gmail.com> wrote: >> 2008/11/6 Josiah Carlson <josiah.carlson(a)gmail.com>: >> >>> I guess I really don't understand the purpose of PyON. Syntactically >>> it doesn't fit between json and yaml. It supports features that are >>> more useful for a serialization language for RPC, etc., rather than >>> configuration/inlining. And it doesn't really offer a reverse of >>> representation -> object without going through the standard Python >>> parser and executing the result (which has security implications). >> PyON dosn't use exec in order to reconstruct obbject. >> It uses python parser for constructing AST and then builds object >> using pickle-like protocol from AST. >> I guess PyON could be used as standard reconstructable representation >> of python objects. > > Then that strictly limits it to Python. No other language can make > use of it. And in that sense, we may as well use pickle (which is > fast, already exists, supports recursive object definitions, as well > as arbitrary Python objects). > >>> Again, json is very human readable/writable, is very close to literal >>> Python syntax, and already has support in just about every language >>> worth discussing (and Python offers a json loading module in the >>> standard library). Can you give me a good reason why someone would >>> want to choose PyON over json in 6 months? >> If someone need standard way for reconstructable representation >> of almost every python object based on python syntax then PyON is a >> possible choice (probably in near future). >> Also maybe in the future someone will offer better solution for >> reconstructable representation of >> python objects based on python syntax. >> >> Also I do not think that PyON should be used instead of JSON. > > Limiting yourself to Python syntax for something that really isn't > human readable (in particular recursive structures and arbitrary > object serialization) doesn't make a lot of sense. It's like limiting > yourself to a 3rd grade vocabulary level for a doctoral dissertation > because you think that 3rd graders might want to read it some day. > People don't really read object representations. And when they do, > it's because the representations are configuration files, in which > self-references are a *really* bad idea. > > If you want a pure-python representation (rather than json), look at > 'unrepr'; it uses the Python parser, and by default only supports > standard data structures. It can be extended to support arbitrary > classes with standard instantiation methods. > > - Josiah > -- С уважением, Шибзухов З.М.

12 years

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas November 2008