Mailman 3 November 2008 - Python-ideas

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

Smallest/Largest singletons
by George Sakkis Nov. 27, 2008

Nov. 27, 2008

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

6 9

Complex rationals in Python.
by Rocco Orlando Rossi Nov. 24, 2008

Nov. 24, 2008

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.

5 6

Lock-File class: FileLock
by Mathias Panzenböck Nov. 17, 2008

Nov. 17, 2008

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

1 0

Suggestion for 2.7/3.[01] - sys.isinteractive()
by skip＠pobox.com Nov. 15, 2008

Nov. 15, 2008

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

2 1

Re: [Python-ideas] Proposal for Ruby-style anonymous block functions (that don't kill the indention)
by Carl Johnson Nov. 14, 2008

Nov. 14, 2008

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 >

3 4

Proposal for Ruby-style anonymous block functions (that don't kill the indention)
by Carl Johnson Nov. 10, 2008

Nov. 10, 2008

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

2 2

__missing__ object/keyword
by George Sakkis Nov. 8, 2008

Nov. 8, 2008

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 17

Python Object Notation (PyON)
by Zaur Shibzoukhov Nov. 7, 2008

Nov. 7, 2008

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

5 9

Re: [Python-ideas] Python Object Notation (PyON)
by Zaur Shibzoukhov Nov. 7, 2008

Nov. 7, 2008

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 > -- С уважением, Шибзухов З.М.

1 0

Python Object Notation (PyON)
by Zaur Shibzoukhov Nov. 5, 2008

Nov. 5, 2008

2008/11/5 Arnaud Delobelle wrote: > (or one could use given=dict(lst=lst, d=d)) > > This would have two advantages: > > * eliminate the rist of keyword argument name collision > * one could put all the 'given' objects in a dictionary and then > 'pickle' expressions as needed using this method. Later pyon.loads > could be passed this dictionary so that the objects can be unpickled > correctly. > > I think this idea is good as it would make it possible to pickle some > objects that contain unpicklable objects just by declaring them as > 'given'. > I think it's reasonable. I will change the interface. > Also, what happens with types? E.g. > >>>> pyon.dumps([int, float, str]) > > I think it would be good if typenames were considered literals (like > numbers and strings) so that the above returns '[int, float, str]' > (and the same for user-defined types maybe). Yes, pyon can dump types too. One note: default rule for name resolving uses sys._getframe(1).f_globals and sys._getframe(1).f_locals. But you can change name resolver writing you own. For example: >>> class C(object): pass ... >>> pyon.loads("[int,bool,float,C]") [<class 'int'>, <class 'bool'>, <class 'float'>, <class '__main__.C'>] >>> pyon.dumps([int,bool,float,C]) '[int,bool,float,C]' Best regards, Zaur

1 0

Python Object Notation (PyON)
by Zaur Shibzoukhov Nov. 5, 2008

Nov. 5, 2008

Arnaud Delobelle wrote: > How do you represent a recursive list? E.g. > On 1 Nov 2008, at 19:49, Mathias Panzenböck wrote: > > > > I wonder what it would yield in this case: > > lst = ['foo'] > > lst.append(lst) Now pyon can represent recursive lists and dicts: >>> lst = ['foo'] >>> lst.append(lst) >>> pyon.dumps(lst, fast=False) # fast mode is similar to pickle's fast mode _p__0=['foo',None] _p__0[1]=_p__0 _p__0 >>> d = {'a':'foo'} >>> d['b'] = d >>> pyon.dumps(d, fast=False) _p__0={'a':'foo'} _p__0['b']=_p__0 _p__0 I will commit changes to sources this evening. Best regards, Zaur

3 3

Python Object Notation (PyON)
by Zaur Shibzoukhov Nov. 4, 2008

Nov. 4, 2008

Bruce Leban wrote: > Furthermore, is there any reason this wouldn't be best integrated with > pickle? That is, when I pickle an object, I could specify that it be in > "Pyon" format (or maybe "Pyckle") and when I unpickle, it automatically > accepts any format? I think it could be integrated with pickle. Best regards, Zaur

1 0

Python Object Notation (PyON)
by Zaur Shibzoukhov Nov. 3, 2008

Nov. 3, 2008

Arnaud Delobelle wrote: > Looking at the page, it seems to me that it aims to: > * be able to give a string representation of any(*) object like pickle > and unlike json >* produce human readable output like json and unlike pickle Yes it works that way. > (*) for a suitable definition of 'any', ideally the same as pickle I > guess. Now pyon can't dump any recursive object. It can dump recursive lists and tuples now. I also going to add support for recursive dicts, and then for other objects. > lst = [1, 2] > obj = [lst, lst] pyon.dumps(obj, fast=False; this mode similar to pickle's fast mode) produce a following text: _p__0=[1,2] [_p__0,_p__0] pyon.dumps(obj) (i.e. fast=False) produce a following text: [[1,2],[1,2]] Best regards, Zaur

2 1

type/instance method syntax
by spir Nov. 2, 2008

Nov. 2, 2008

Hello, [New to the list. I spent some time exploring the archives, still I'm not really sure of what kind of subjects fit here -- or not. If ever this post, or a further one, is out of topic, just tell me. Also, I'm a self-trained amateur, and neither python nore english is my native language, thus I may use non-standard idioms. ;-)] -1- real-life case (can safely be skipped) I'm writing an application that should allow a user to chose between several wiki languages, including customized versions, on one side; and uses either a subset of xhtml, or simple plain text tables (simulation of DB import/export), as saving/exchange/standard format. To do this, I have a whole lot of configurable "Symbol" sub-types, each representing a common language feature. (I imagine there are tons of more professional approaches, but this is not my point -- I do it for pleasure.) A list of symbols (instances), parsed from a source text, build an abstract, language-independant, image of the text. The types have to take the (wiki-side) configuration into account; I also wish this config to be "switchable" at run-time. An example use of this feature is to "transcode" a wiki source text into another wiki format. The pattern of a symbol type is then: class BlockFormat(Symbol): def config(): <set type attributes> def __init__(self, source, ...): <read instance attributes from source doc> <read/write methods from/into known languages> I /really/ expected this to work. config() obviously was, for me, a type/class method. I intended to call it and its sisters from a module top-level function: def config(): wiki_config.build(config_file_name) for symbol_type in symbol_types: symbol_type.config() As a consequence, I happily discovered both classmethod() and @classmethod.(Actually, I hadn't programmed for a long time, had forgotten some idiomatic "details", and knew about nothing of python >= 2.0, except for the overall new_style_classes pattern.) -2- type/instance attribute pattern (Below is called 'property' a non-callable object attribute, as opposed to 'method'. I do not know if a better, standard, term is used in the python community.) type/class instance property prop self.prop method call f(args) self.f(args) method def def f(args)+X def f(self,args) (where X means either classmethod() or @classmethod) I wondered where the point is before writing down this table. Why (1) I intended my code to work as is (2) we need to add a line of code to define a class method. In order to distinguish an instance property from a type one, the former is simply prefixed with 'self' -- or any placeholder for a potential instance name --, later with the actual instance's name. This pattern fully applies to method call. But is broken for method definition, for any reason I'm unable to guess. I think this explains why I wrote the code above. Now, watching such a table, the additional instruction looks to my eyes like a workaround rather than a feature. Actually, the instance method definition syntax takes the place of the one that may be expected for class methods instead. Lets imagine this slight change: type/class instance property prop self.prop method call f(args) self.f(args) method def def f(args) def self.f(args) <== Doesn't this deliciously fit in the table? Not only the syntax for instance method definition matches the call syntax; but also the whole method pattern matches the one for properties. -3- proposal I am fully conscious that this syntax cannot be introduced: this would have as magic side-effect to transform all instance methods into class methods ;-) I wonder if the following may be considered: Allow prefixing of class attributes (esp. methods) with the classe's name -- even in the classe's own scope: class C(object): C.a = 1 def C.f(): <method body> This syntax presently launches NameError and SyntaxError, which is correct as C is not yet defined, and the second syntax is unknown. But... it would allow a nicer syntax to define class method, and more: this syntax is precisely the one that will later be used to call the method. An alternative may be to prefix a class method defintition with either 'type' or 'class', used as a pseudo keyword: class C(object): def type.f(): <method body> Denis

1 1

Python Object Notation (PyON)
by Zaur Shibzoukhov Nov. 2, 2008

Nov. 2, 2008

Python Object Notation (PyON<http://code.google.com/p/pyon/wiki/GettingStarted> ) Python 2.6/3.0 now has a module ast. This opens up new opportunities. One of them is the possibility of introducing human readable/writable literal object notation, based on the syntax of the python language. I would like to know what do you think about this? Best regards, Zaur

5 5

Python Object Notation (PyON)
by Zaur Shibzoukhov Nov. 1, 2008

Nov. 1, 2008

Terry Reedy wrote: > Other than syntax details, how is PyON different from json, yaml (3rd > party module), and anything else? I hope that PyON can be seen as native literal object notation for objects in python language. Similar to what JSON is for JavaScript ;) JavaScript hasn't classes, but python has that. So we could say that PyON in some way extends JSON. I that it's better reflecting python's object model. I'l try to explain this by example. Let class Person(object): pass person = Person() person.name = 'John' person.age = 33 First, in PyON person represents as "Person(name='John', age=33)" and loads return an instance of Person. In JSON we need to represent person in a way similar to "{'class':'Person', 'name':'John', 'age':33}" and loads always return dict-like structure, not instance of Person. Second, object instance reconstruction from PyON string or AST performs according to picklie protocol (3). This mean that if we define class that implements right methods in accordance to pickle protocol then we can dumps to PyON string and loads from that. I didn't yet made comparison with yaml. I should do that too. Now I can only say that yaml is much complicated notation (IMHO). >>> Grammar: <kw> := <name> = <pyon_expr>, ..., <name> = <pyon_expr> >>> There is no rule for pyon_expr. Did you just mean <expr>? You right, thank you. This a tipo. I'l update the page. > ... y=IF( > ... flag, > ... A1(kind='A1'), > ... A2(kind='A2') > ... ) This didn't covered by current rough gramma definition. I still do not know if this must be a part of PyON. The fact is that PyON can be extended to thing such as "object template" and current implementation include some of such opportunities. One of this you pointed out here. Here is another example: person = loads("Person(name=real_name, age=real_age)", real_name='John', real_age=33) Best regards, Zaur

1 0