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
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
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
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
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.
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
