Mailman 3 December 2006 - Python-ideas

copyable iterators, named loops, continue a expression per indentation and a few functional things
by David Blaschke Dec. 27, 2006

Dec. 27, 2006

Using break for parent, grandparent, etc. only works until someone modifies the code incorrectly. It is a problem waiting to happen. Mathias' suggestion breaks the outer loop, but a slight modification allows you to break any one of the loops "Well this is a good way to break the outer most loop without any new syntax:" cond1 = 1 cond2 = 1 cond3 = 1 while cond1: while cond2: while cond3: if cond4: cond2 = 0 ## break second loop, etc

2 1

Python as meta-language
by Talin Dec. 25, 2006

Dec. 25, 2006

One of my long-standing interests is in mini-languages, particularly declarative languages. I'm always looking out for examples where a declarative language is used to represent some idea or concept that is not easily written in an imperative language. Examples are the behaviors of particle systems, kinematic constraints, formalized grammars, logical inferencing systems, query languages, and so on. In other words, you are using a language to describe a complex set of relationships, but you aren't giving specific commands to execute in a specific order. Often such mini-languages are implemented by writing a custom parser. However, often this is not necessary if the underlying language (such as Python) is flexible enough. Python's ability to declare complex structures as literals, combined with its ability to overload operators, means that one can often embed the mini-language within the Python syntax itself, and use the Python compiler as the parser for your mini language. It also allows you a convenient means to "escape" back into the procedural world when needed. Examples of the kind of things I am talking about include the SConstruct file format from SCONS and the SQLBuilder syntax from SQLObject. And although it's not directly related to Python, JSON has a lot of the same ideas - that is, using a scripting language source code as an efficient representation of complex data structures. And these are just a few of the many examples out there. What I'd be interested in doing, in this python-ideas list, is brainstorming some ideas for how we can improve Python's ability to 'host' other kinds of mini-languages within the Python syntax. We can start perhaps by examining some of the use cases I listed in the first paragraph - particle systems, etc - and see how one would want to represent those kinds of semantic structures within Python. Of course, there are some languages (Lisp and Dylan come to mind), which are even more flexible in this regard - the languages can be 'morphed' out of all recognition to the original syntax. (For example, in Dylan, a 'macro' was not a simple textual substitution as in C, but in fact added new production rules to the parser.) In I'm in no way advocating such a course. (Well, at least not at this moment :) ) I certainly recognize that there is a danger in making a language too 'plastic', in that it can easily be obfuscated with too much cleverness and lose it's identity. So I'm more interested in ideas that are subtle yet powerful. I'm sure that there are lots of approaches to this general concept. I'm going to throw out a couple of ideas, but I am going to post them as separate replies to this email, and not right away - the reason is, I don't want this thread to be taken over by the discussion / criticism of those specific ideas, when I'm more interested in brainstorming the general concept. -- Talin

3 6

copyable iterators, named loops, continue a expression per indentation and a few functional things
by Mathias Panzenböck Dec. 25, 2006

Dec. 25, 2006

Copyable iterators ------------------ There are a few ways how you could implement this. However, it only makes sense for iterators, not for generators! Way 1: Copyable iterators have a copy-method: >>> L = [1,2,3,4] >>> it1 = iter(L) >>> it1.next() 1 >>> it2 = it1.copy() >>> it2.next() 2 >>> it1.next() 2 Way 2: Copyable iterators will be copied when you call it's __iter__-method: >>> L = [1,2,3,4] >>> it1 = iter(L) >>> it1.next() 1 >>> it2 = iter(it1) >>> it2.next() 2 >>> it1.next() 2 In way 1 you could check for copy ability per hasattr(it,"copy"). Named loops ----------- With named loops you could break or continue other than only the inner most loop. I'm not sure about a syntax, though. for x in X as loop_a: for y in Y as loop_b: if cond1(): break loop_a elif cond2(): continue loop_a elif cond3(): break # breaks loop_b elif cond4(): continue # continues loop_b Auto-curryfication for operators -------------------------------- I like haskells feature for curryfication of operators. I think this would be nice to have in python. You could write instead of 'operator.add' the much shorter '(+)'. Or even '(2+)' works. >>> map((2+),[1,2,3,4]) [3,4,5,6] >>> filter((>=2),[1,2,3,4]) [2,3,4] __add__-method for functions ---------------------------- In haskell you can write 'f . g . h', which would be the same like '(\a -> f(g(h(a))))' (in python: 'lambda a: f(g(a))'). In python it would also be nice to have such a functionality. It could be implemented with a __add__-method. Here is this functionality simulated with functors: >>> class FunctionBase(object): def __add__(self,other): return lambda *args,**kwargs: self(other(*args,**kwargs)) >>> class F(FunctionBase): def __call__(self,s): return s+" foo" >>> class G(FunctionBase): def __call__(self,s): return s+" bar" >>> f = F() >>> g = G() >>> (f + g)("x") 'x bar foo' >>> (g + f)("x") 'x foo bar' What do you think? panzi

8 10

Improving Pydoc
by Ron Adam Dec. 23, 2006

Dec. 23, 2006

Improving pydoc has been suggested before by me and others. I've been working on a version that is probably 80% done and would like to get feed back at this point to determine if I'm approaching this in the best way. Basically pydoc.py consists of over 2,000 lines of python code and is not well organized inside which means (my thoughts) it will pretty much stay the way it is and not be as useful as it could be. Currently pydoc.py has the following uses. * It is imported and used as pythons console help function. * It can be used to generate help text files. * It can open a tkinter search index and from that launch a web server and a browser to veiw a html help page. * It can be used to generate static html help files. It looks (to me) like splitting it into two modules would be good. One module for just the text help and introspection functions, and the other for the html server and html output stuff. 1. pyhelp.py - Pythons help function from inside the console, and running it directly would open an interactive text help session. 2. _pydoc.py - Python html help browser. This starts an html server and opens a web page with a modules/package index. The html page headers would contain the current Python version info and the following inputs fields. * get field - directly bring up help on an object/module/or package. * Search field - returns a search results index. * Modules button - modules index page * Keywords button - keywords index page * Help button - pydoc Help instructions, version, and credits info. Note: The leading underscore "_pydoc.py" is to keep it from clashing with the current pydoc version. It probably should be something else. An additional feature is clicking on a filename opens up a numbered source listing. Which is nice for source code browsing and for referencing specific lines of code in python list discussions. ;-) The colors, fonts and general appearance can be changed by editing the style sheet. The output is readable as plain (outline form) text if the style sheet is ignored by the browser. _pydoc.py imports pyhelp and uses it to do the introspection work and extends classes in pyhelp to produce html output. I've tried to make pyhelp.py useful in a general way so that it can more easily be used as a base that other output formats can be built from. That's something that can't be done presently. These improvements to pydoc mean you can browse pythons library dynamically without ever leaving the web browser. Currently you switch back and forth between the browser and a tkinter index window. Something I found to be annoying enough to discourage me from using pydoc. The version I'm working on is split up into eight python files, each addressing a particular function of pydoc. That was to help me organize things better. These will be recombined into fewer files. Some parts of it could be moved to other modules if they seem more generally useful. For example, the console text pager could be used in many other console applications. Things that still need to be done are adding the object resolution order output back in. And adding inter-page html links back in. And a few other things I just haven't gotten to yet. I got a bit burned out on this project a while back, and then moved to a new house.. etc.. etc.. But I'm starting to have more time, and with the current discussion s turning on to refining pythons library this seems like it would be a useful tool in that effort. Any comments on this general approach? Any suggestions, questions, or comments? I'll post a link to the zipped files in the next day or two and announce it here. I need to look into a glitch on my computer first that's probably a windows path/name problem. I don't think it's anything that needs to be fixed in the files but I want to be sure. Cheers, Ron Adam

3 5

bitwise operations on bytes
by Terry Carroll Dec. 22, 2006

Dec. 22, 2006

I'll start. I would like to be able to have the capability of doing bitwise operations on a string-like field. For this example, I'll use strings, but as I understand it, the planned byte type would probably be more appropriate. An example. Suppose I have a string (say, read in from a binary file) that has a 4-byte field in it. Bit 11 indicates whether the accompanying data is in glorped form (something I'm just making up for this example). For example, if the field has 0x000480c4, the data is not glorped. If the data is glorped, bit 11 would be on, i.e., 0x001480c4. Let's say I want to turn on the glorp bit; what I have to do now: GLORPED = 0x10 newchar = chr(ord(flags[1]) | GLORPED) flags = flags[0] + newchar + flags[2:] (messy) What I'd like to be able to do is something like: GLORPED = "x\00x\10x\00\x00" flags = flags | GLORPED I've actually run into this, on a read-only side, in reading and interpreting MP3 files. As I said, this is probably better for a bytes object than string.

2 1

The point of this list
by Brett Cannon Dec. 20, 2006

Dec. 20, 2006

I have gotten some emails from people saying how they expect this list to be the Wild West of Python propoals. I personally don't think it will be nor do I want it to be. I view this list as a stop-gap between python-dev/python-3000 and comp.lang.python. Totally wild ideas that have no hope of being accepted in the language (e.g., add curly braces) should not be brought up here. c.l.pyis a more proper place to start flame wars. Plus c.l.py is usually a good place to vent initial ideas anyway. I view this list as a staging area for ideas that actually have some form of a chance to either be turned into a solid proposal to take to the Python committers or to reject them and have the archives act as a place to point people to why. Basically I expect people to get redirected here from python-dev and python-3000 to gestate an idea before going to those lists to get approval to add it to the language. In other words, I have no problem telling people their idea is ridiculous and to stop talking about it. I am hoping we don't have to go that far and we can give people a fair chance to bring up ideas that they come up with. But if this list gets too ridiculous I have no problem policing it or even shutting the list down. I doubt it will come to that, though. =) -Brett

1 0