From brett at python.org  Wed Dec 20 23:06:46 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Dec 2006 14:06:46 -0800
Subject: [Python-ideas] The point of this list
Message-ID: <bbaeab100612201406sdfe4d65o941c9224771504ad@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20061220/f6c0dbb2/attachment.html>

From carroll at tjc.com  Fri Dec 22 00:47:36 2006
From: carroll at tjc.com (Terry Carroll)
Date: Thu, 21 Dec 2006 15:47:36 -0800 (PST)
Subject: [Python-ideas] bitwise operations on bytes
Message-ID: <Pine.LNX.4.44.0612211535580.24566-100000@violet.rahul.net>

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.



From jcarlson at uci.edu  Fri Dec 22 02:12:38 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu, 21 Dec 2006 17:12:38 -0800
Subject: [Python-ideas] bitwise operations on bytes
In-Reply-To: <Pine.LNX.4.44.0612211535580.24566-100000@violet.rahul.net>
References: <Pine.LNX.4.44.0612211535580.24566-100000@violet.rahul.net>
Message-ID: <20061221170629.BC29.JCARLSON@uci.edu>


Terry Carroll <carroll at tjc.com> wrote:
> 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.

Strings won't exist in Py3k, so discussions about them aren't topical.

[snip]

> GLORPED = 0x10
> newchar = chr(ord(flags[1]) | GLORPED)
> flags = flags[0] + newchar + flags[2:]

You can get byte-wise operations on arrays today.

flags = array.array("B", f.read(4))
flags[1] |= GLORPED


Note that the only difference between 'bytes' and arrays with typecode
'B' is that the 'bytes' object may have more functionality, though the
functionality is not fully specified as of yet.

 - Josiah



From rrr at ronadam.com  Fri Dec 22 09:27:28 2006
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 22 Dec 2006 02:27:28 -0600
Subject: [Python-ideas] Improving Pydoc
Message-ID: <458B96F0.9040604@ronadam.com>


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










From theller at ctypes.org  Fri Dec 22 12:01:46 2006
From: theller at ctypes.org (Thomas Heller)
Date: Fri, 22 Dec 2006 12:01:46 +0100
Subject: [Python-ideas] Improving Pydoc
In-Reply-To: <458B96F0.9040604@ronadam.com>
References: <458B96F0.9040604@ronadam.com>
Message-ID: <458BBB1A.8070300@ctypes.org>

Ron Adam schrieb:
> 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.

Yes, I remember several cases where I had to copy code out of pydoc.py because I wanted
to reuse it and could not because pydoc pulls in too much stuff (I care about this when
freezing my programs with py2exe).
Is splitting pydoc into 2 modules sufficient, or should it even be split into an own package?

Although I do not believe that this is on-topic for *this* list; I would prefer
such changes to go into Python 2.6 already.

Thomas


BTW:  It seems this list is not yet available on gmane.  Is this correct?


From rrr at ronadam.com  Fri Dec 22 14:37:40 2006
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 22 Dec 2006 07:37:40 -0600
Subject: [Python-ideas] Improving Pydoc
In-Reply-To: <458BBB1A.8070300@ctypes.org>
References: <458B96F0.9040604@ronadam.com> <458BBB1A.8070300@ctypes.org>
Message-ID: <458BDFA4.8040706@ronadam.com>

Thomas Heller wrote:
> Ron Adam schrieb:
>> 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.
> 
> Yes, I remember several cases where I had to copy code out of pydoc.py because I wanted
> to reuse it and could not because pydoc pulls in too much stuff (I care about this when
> freezing my programs with py2exe).
> Is splitting pydoc into 2 modules sufficient, or should it even be split into an own package?

That is one of the questions I have, which would be preferable.  Here's a list 
of files I have and what they do.

pyhelp.py        - Command line option parser / front end
gettext.py       - Generates text output
scanner.py       - module and search functions
_pydoc.py        - starts server and web browser
gethtml.py       - Generate html output
server.py        - html server
pager.py         - multy-platform console text pager
stringtools.py   - frequently used string formatting functions
stylesheet.css

There is still quite a bit of inter-dependence between these, but not anywhere 
near as complex as the original was. I think you will need to look at the source 
to see what is actually going on though. I'll be posting a link to it either 
today or tomorrow.


> Although I do not believe that this is on-topic for *this* list; I would prefer
> such changes to go into Python 2.6 already.

As Brett said, and Guido promoted by asking for volunteers:

On 12/18/06, Brett Cannon <brett at python.org> wrote:

 > A Python pie-in-the-sky list (python-ideas?) seems reasonable.  Let's
 > python-dev focus on maintaining the current code, python-3000 on
 > Py3K-specific work, and the ideas list to be where new ideas are vetted out
 > and congealed into a PEP to bring to either python-3000 or python-dev.


While we could hash out the exact meaning of 'pie-in-the-sky', 'new-ideas', 
'vetted out and congealed', etc...  my general impression is that things that 
aren't ready yet for python-dev or python-3000 should be here until they are 
ready.  Then of course, it could be moved to python-dev if you prefer.  I would 
like that too.

This give us a place where we can have in progress discussion of features and 
*alternatives* without disrupting python-dev or python-3000 with things that 
aren't ready.

In this case, there is still a lot more this needs before it's ready I think.  A 
PEP?  A fully (or mostly) working patch?  But maybe if others take an interest 
here, it won't be here long. ;-)

Cheers,
    Ron














From brett at python.org  Fri Dec 22 21:13:53 2006
From: brett at python.org (Brett Cannon)
Date: Fri, 22 Dec 2006 12:13:53 -0800
Subject: [Python-ideas] Improving Pydoc
In-Reply-To: <458BDFA4.8040706@ronadam.com>
References: <458B96F0.9040604@ronadam.com> <458BBB1A.8070300@ctypes.org>
	<458BDFA4.8040706@ronadam.com>
Message-ID: <bbaeab100612221213x6afab4afs3115eb4b38b8a1a7@mail.gmail.com>

On 12/22/06, Ron Adam <rrr at ronadam.com> wrote:
> Thomas Heller wrote:
> > Ron Adam schrieb:
> >> 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.
> >
> > Yes, I remember several cases where I had to copy code out of pydoc.py because I wanted
> > to reuse it and could not because pydoc pulls in too much stuff (I care about this when
> > freezing my programs with py2exe).
> > Is splitting pydoc into 2 modules sufficient, or should it even be split into an own package?
>
> That is one of the questions I have, which would be preferable.  Here's a list
> of files I have and what they do.
>
> pyhelp.py        - Command line option parser / front end
> gettext.py       - Generates text output
> scanner.py       - module and search functions
> _pydoc.py        - starts server and web browser
> gethtml.py       - Generate html output
> server.py        - html server
> pager.py         - multy-platform console text pager
> stringtools.py   - frequently used string formatting functions
> stylesheet.css
>
> There is still quite a bit of inter-dependence between these, but not anywhere
> near as complex as the original was. I think you will need to look at the source
> to see what is actually going on though. I'll be posting a link to it either
> today or tomorrow.
>

I do like your idea of splitting the screen pager and the HTML aspect,
Ron.  And yes, pydoc needs a cleanup.

>
> > Although I do not believe that this is on-topic for *this* list; I would prefer
> > such changes to go into Python 2.6 already.
>
> As Brett said, and Guido promoted by asking for volunteers:
>
> On 12/18/06, Brett Cannon <brett at python.org> wrote:
>
>  > A Python pie-in-the-sky list (python-ideas?) seems reasonable.  Let's
>  > python-dev focus on maintaining the current code, python-3000 on
>  > Py3K-specific work, and the ideas list to be where new ideas are vetted out
>  > and congealed into a PEP to bring to either python-3000 or python-dev.
>
>
> While we could hash out the exact meaning of 'pie-in-the-sky', 'new-ideas',
> 'vetted out and congealed', etc...  my general impression is that things that
> aren't ready yet for python-dev or python-3000 should be here until they are
> ready.  Then of course, it could be moved to python-dev if you prefer.  I would
> like that too.
>
> This give us a place where we can have in progress discussion of features and
> *alternatives* without disrupting python-dev or python-3000 with things that
> aren't ready.
>
> In this case, there is still a lot more this needs before it's ready I think.  A
> PEP?  A fully (or mostly) working patch?  But maybe if others take an interest
> here, it won't be here long. ;-)
>

I don't view code cleanup as something for this list.  I view stuff
like "I want to hash out an idea on abstract base classes" and the
ilk.  Code reorganization, etc. that are more software engineering and
completely new idea should still go to python-dev or python-3000.
Basically stuff where people might throw a fit over the idea should
probably come here until it is a solid idea.  =)

So I agree with Thomas; this should go to python-dev.

-Brett


From rrr at ronadam.com  Sat Dec 23 00:06:01 2006
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 22 Dec 2006 17:06:01 -0600
Subject: [Python-ideas] Improving Pydoc
In-Reply-To: <bbaeab100612221213x6afab4afs3115eb4b38b8a1a7@mail.gmail.com>
References: <458B96F0.9040604@ronadam.com> <458BBB1A.8070300@ctypes.org>	
	<458BDFA4.8040706@ronadam.com>
	<bbaeab100612221213x6afab4afs3115eb4b38b8a1a7@mail.gmail.com>
Message-ID: <458C64D9.5060802@ronadam.com>

Brett Cannon wrote:

> I do like your idea of splitting the screen pager and the HTML aspect,
> Ron.  And yes, pydoc needs a cleanup.

The screen pager is not dependent on any other parts.  So it would make an ideal 
module on it's own, or it could be a part of console io device object.

The html server is very much cleaned up.  It is a nice example of how to write a 
html server and can stand on it's own as an example module I think.


>> In this case, there is still a lot more this needs before it's ready I 
>> think.  A
>> PEP?  A fully (or mostly) working patch?  But maybe if others take an 
>> interest
>> here, it won't be here long. ;-)
>>
> 
> I don't view code cleanup as something for this list.  I view stuff
> like "I want to hash out an idea on abstract base classes" and the
> ilk.  Code reorganization, etc. that are more software engineering and
> completely new idea should still go to python-dev or python-3000.
> Basically stuff where people might throw a fit over the idea should
> probably come here until it is a solid idea.  =)
> 
> So I agree with Thomas; this should go to python-dev.

It's still pretty raw in some places, but maybe that's ok.

I'll post and introduction and the link in python-dev, I also think I uncovered 
a bug in the browser module, so maybe they can look at that too.


It will be interesting to see what will be discussed here, I have some farther 
out "fit-throwing" ideas as well.  ;-)

Cheers,
    Ron




From rrr at ronadam.com  Sat Dec 23 01:04:06 2006
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 22 Dec 2006 18:04:06 -0600
Subject: [Python-ideas] Improving Pydoc
In-Reply-To: <458C64D9.5060802@ronadam.com>
References: <458B96F0.9040604@ronadam.com>
	<458BBB1A.8070300@ctypes.org>		<458BDFA4.8040706@ronadam.com>	<bbaeab100612221213x6afab4afs3115eb4b38b8a1a7@mail.gmail.com>
	<458C64D9.5060802@ronadam.com>
Message-ID: <458C7276.1000601@ronadam.com>

Ron Adam wrote:

> I'll post and introduction and the link in python-dev, I also think I uncovered 
> a bug in the browser module, so maybe they can look at that too.

I found and fixed the problem I was having. So didn't include any mention of it 
on python-dev.




From grosser.meister.morti at gmx.net  Sat Dec 23 18:20:05 2006
From: grosser.meister.morti at gmx.net (=?ISO-8859-15?Q?Mathias_Panzenb=F6ck?=)
Date: Sat, 23 Dec 2006 18:20:05 +0100
Subject: [Python-ideas] copyable iterators, named loops,
 continue a expression per indentation and a few functional things
Message-ID: <458D6545.4090709@gmx.net>

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


From fw at deneb.enyo.de  Sat Dec 23 18:59:53 2006
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 23 Dec 2006 18:59:53 +0100
Subject: [Python-ideas] copyable iterators, named loops,
	continue a expression per indentation and a few functional things
In-Reply-To: <458D6545.4090709@gmx.net> (Mathias =?iso-8859-1?Q?Panzenb=F6?=
	=?iso-8859-1?Q?ck's?= message of "Sat,
	23 Dec 2006 18:20:05 +0100")
References: <458D6545.4090709@gmx.net>
Message-ID: <87zm9efq7a.fsf@mid.deneb.enyo.de>

* Mathias Panzenb?ck:

>>>> f = F()
>>>> g = G()
>>>> (f + g)("x")
> 'x bar foo'
>>>> (g + f)("x")
> 'x foo bar'

I would expect that (f + g)(x) == f(x) + g(x).  Using "+" for a
non-commutative operation doesn't seem right.


From guido at python.org  Sun Dec 24 02:14:06 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 23 Dec 2006 17:14:06 -0800
Subject: [Python-ideas] copyable iterators, named loops,
	continue a expression per indentation and a few functional things
In-Reply-To: <87zm9efq7a.fsf@mid.deneb.enyo.de>
References: <458D6545.4090709@gmx.net> <87zm9efq7a.fsf@mid.deneb.enyo.de>
Message-ID: <ca471dc20612231714i77d6d03fnab52ada5dd42524e@mail.gmail.com>

On 12/23/06, Florian Weimer <fw at deneb.enyo.de> wrote:
> Using "+" for a
> non-commutative operation doesn't seem right.

Perhaps you've never used string concatenation in Python?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From ironfroggy at gmail.com  Sun Dec 24 04:00:20 2006
From: ironfroggy at gmail.com (Calvin Spealman)
Date: Sat, 23 Dec 2006 22:00:20 -0500
Subject: [Python-ideas] copyable iterators, named loops,
	continue a expression per indentation and a few functional things
In-Reply-To: <458D6545.4090709@gmx.net>
References: <458D6545.4090709@gmx.net>
Message-ID: <76fd5acf0612231900r1cebc66jc41d574d80d63e0d@mail.gmail.com>

On, Copyable Iterators:
I would like the option of copyable iterators, and I think a copy
method is better than just iter(), because it can be common to be
slightly unsure if you have an iteratable or an iterator (hasattr(x,
'__iter__') vs hasattr(x, 'next')). Also, it might be more work but I
would love to see generators that can do this.

On, Named Loops:
Although I appriciate what problems this idea aims to solve, I think
it would lead to things far too close to spagetti code to be worth the
trouble.

On, Auto-curryfication for operators:
This looks a little strange in Python, but its certainly clear enough
in intention that it could be pretty valuable. Likewise, what if we
expand this a bit to supporting __r*__ methods on generators
expressions so we can do the following?

    indexes_from_one = 1 + (i for (i, j) in enumerate(L))

Which reads well as "One plug i for each ...", etc.

On, __add__-method for functions:
Although this is not a terrible idea, I can not be convinced that its
the thing most people would expect when seeing it in code. In other
words, when anyone new to this sees the code (f + g)(x, y) are they
going to expect f(g(x,y)) or f(x)+g(y), as some sort of an
extra-argument or parameter spillover catch? No, most wouldn't expect
something terribly wrong, other than getting f and g backwards in the
translated f(g(x,y)), but the point is that it might not be intuitive
enough not to be used incorrectly a lot.


On 12/23/06, Mathias Panzenb?ck <grosser.meister.morti at gmx.net> wrote:
> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/


From jcarlson at uci.edu  Sun Dec 24 06:14:36 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sat, 23 Dec 2006 21:14:36 -0800
Subject: [Python-ideas] copyable iterators, named loops,
	continue a expression per indentation and a few functional things
In-Reply-To: <458D6545.4090709@gmx.net>
References: <458D6545.4090709@gmx.net>
Message-ID: <20061223211302.BC45.JCARLSON@uci.edu>


Mathias Panzenb?ck <grosser.meister.morti at gmx.net> wrote:
> 
> Copyable iterators
> ------------------
> 
> There are a few ways how you could implement this. However, it only makes sense for iterators, not
> for generators!

-1 on the entire proposal.  All iterators (and generators) are already
copyable.  It's called list().


 - Josiah



From talin at acm.org  Sun Dec 24 08:32:07 2006
From: talin at acm.org (Talin)
Date: Sat, 23 Dec 2006 23:32:07 -0800
Subject: [Python-ideas] copyable iterators, named loops,
 continue a expression per indentation and a few functional things
In-Reply-To: <20061223211302.BC45.JCARLSON@uci.edu>
References: <458D6545.4090709@gmx.net> <20061223211302.BC45.JCARLSON@uci.edu>
Message-ID: <458E2CF7.201@acm.org>

Josiah Carlson wrote:
> Mathias Panzenb?ck <grosser.meister.morti at gmx.net> wrote:
>> Copyable iterators
>> ------------------
>>
>> There are a few ways how you could implement this. However, it only makes sense for iterators, not
>> for generators!
> 
> -1 on the entire proposal.  All iterators (and generators) are already
> copyable.  It's called list().

Actually, what he wants to be able to do is to 'tee' an iterator. 
However, we already have a 'tee' function in itertools that does just 
that. (And it works on generators too!)

-- Talin


From talin at acm.org  Sun Dec 24 08:55:41 2006
From: talin at acm.org (Talin)
Date: Sat, 23 Dec 2006 23:55:41 -0800
Subject: [Python-ideas] Python as meta-language
Message-ID: <458E327D.5010409@acm.org>

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


From rrr at ronadam.com  Sun Dec 24 16:38:57 2006
From: rrr at ronadam.com (Ron Adam)
Date: Sun, 24 Dec 2006 09:38:57 -0600
Subject: [Python-ideas] Python as meta-language
In-Reply-To: <458E327D.5010409@acm.org>
References: <458E327D.5010409@acm.org>
Message-ID: <458E9F11.6070307@ronadam.com>

Talin wrote:
> 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.

This sounds like a wide range of things.  Maybe even a bit too broad.  Can you 
narrow it down a bit.

The first thing that comes to mind for me is Visual's modeling system with both 
an internal C loop for handling the defined objects, motions, colors, lighting 
and updating the screen, but it also allows modifying and querying the models 
while everything is moving around in a python loop.  In this case extending the 
background processing vs foreground processing would be good.

When dealing with real time, or 1/nth time for slower computers, the preferred 
ordering would be given the faster changing objects. Those values should be 
updated or checked more frequently.  So it's not a procedural problem where 
doing things in a predefined order is the best way.

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


Another (possibly related?) idea I think might be useful is to incorporate the 
concept of responsibility, authorization, delegation into the language more 
directly.  In a (well run) business responsibility and authority are delegated 
in a way that gives the employee the ability to succeed, while also protecting 
the interests of the business owners(s) by not giving too much power to any one 
employee.  These are good business practices and I think they could be useful 
concepts if implemented in a computer language in a more formal way.

Cheers,
    Ron Adam




From ironfroggy at gmail.com  Sun Dec 24 17:20:33 2006
From: ironfroggy at gmail.com (Calvin Spealman)
Date: Sun, 24 Dec 2006 11:20:33 -0500
Subject: [Python-ideas] copyable iterators, named loops,
	continue a expression per indentation and a few functional things
In-Reply-To: <458E2CF7.201@acm.org>
References: <458D6545.4090709@gmx.net> <20061223211302.BC45.JCARLSON@uci.edu>
	<458E2CF7.201@acm.org>
Message-ID: <76fd5acf0612240820p3b06ca3t1049186321350142@mail.gmail.com>

On 12/24/06, Talin <talin at acm.org> wrote:
> Josiah Carlson wrote:
> > Mathias Panzenb?ck <grosser.meister.morti at gmx.net> wrote:
> >> Copyable iterators
> >> ------------------
> >>
> >> There are a few ways how you could implement this. However, it only makes sense for iterators, not
> >> for generators!
> >
> > -1 on the entire proposal.  All iterators (and generators) are already
> > copyable.  It's called list().
>
> Actually, what he wants to be able to do is to 'tee' an iterator.
> However, we already have a 'tee' function in itertools that does just
> that. (And it works on generators too!)
>
> -- Talin

If I am understanding the proposal correctly, which I think I am,
itertools.tee is not the same as what this is proposing. itertools.tee
simply iterates the original and caches the results to be given when
iterating over the two tees created for it. This is not the same as
copying an iterator. Copying an iterator would create a new iterator
of the same state as the original. For example, with generators the
copy would be a new generator object with the same state as the
original and iterating over the copy would execute the same code as
the first.

def g():
    i = 0
    while True:
        print i
        yield i
        i = i + 1

If you "copy" this with itertools.tee, you only see i printed once for
each iteration of the generator, not each iteration of the tees. With
a real copying of iterators, if I copied this, iterating over the
copies would always produce an output of that copies value of i.

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/


From talin at acm.org  Sun Dec 24 19:07:43 2006
From: talin at acm.org (Talin)
Date: Sun, 24 Dec 2006 10:07:43 -0800
Subject: [Python-ideas] copyable iterators, named loops,
 continue a expression per indentation and a few functional things
In-Reply-To: <76fd5acf0612240820p3b06ca3t1049186321350142@mail.gmail.com>
References: <458D6545.4090709@gmx.net>
	<20061223211302.BC45.JCARLSON@uci.edu>	<458E2CF7.201@acm.org>
	<76fd5acf0612240820p3b06ca3t1049186321350142@mail.gmail.com>
Message-ID: <458EC1EF.1050903@acm.org>

Calvin Spealman wrote:
> On 12/24/06, Talin <talin at acm.org> wrote:
>> Josiah Carlson wrote:
>>> Mathias Panzenb?ck <grosser.meister.morti at gmx.net> wrote:
>>>> Copyable iterators
>>>> ------------------
>>>>
>>>> There are a few ways how you could implement this. However, it only makes sense for iterators, not
>>>> for generators!
>>> -1 on the entire proposal.  All iterators (and generators) are already
>>> copyable.  It's called list().
>> Actually, what he wants to be able to do is to 'tee' an iterator.
>> However, we already have a 'tee' function in itertools that does just
>> that. (And it works on generators too!)
>>
>> -- Talin
> 
> If I am understanding the proposal correctly, which I think I am,
> itertools.tee is not the same as what this is proposing. itertools.tee
> simply iterates the original and caches the results to be given when
> iterating over the two tees created for it. This is not the same as
> copying an iterator. Copying an iterator would create a new iterator
> of the same state as the original. For example, with generators the
> copy would be a new generator object with the same state as the
> original and iterating over the copy would execute the same code as
> the first.
> 
> def g():
>     i = 0
>     while True:
>         print i
>         yield i
>         i = i + 1
> 
> If you "copy" this with itertools.tee, you only see i printed once for
> each iteration of the generator, not each iteration of the tees. With
> a real copying of iterators, if I copied this, iterating over the
> copies would always produce an output of that copies value of i.

The OP already stated that the proposal is not meant to apply to 
generators, and rightly so, because there's no way to copy all of the 
mutable state that a generator might access.

However, I think that the idea of copying 'iterators but not generators' 
is too restrictive, since externally you might not be able to tell the 
difference. That's why I suggested tee, since it works on both. No, you 
don't get the same side effects, but that's not what the OP was asking for.

-- Talin



From jcarlson at uci.edu  Sun Dec 24 20:36:47 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sun, 24 Dec 2006 11:36:47 -0800
Subject: [Python-ideas] Python as meta-language
In-Reply-To: <458E327D.5010409@acm.org>
References: <458E327D.5010409@acm.org>
Message-ID: <20061224113553.BC48.JCARLSON@uci.edu>


Talin <talin at acm.org> wrote:
> 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.

If you haven't already seen it, you should check out Logix:
http://www.livelogix.net/logix/

 - Josiah



From brett at python.org  Sun Dec 24 21:18:26 2006
From: brett at python.org (Brett Cannon)
Date: Sun, 24 Dec 2006 12:18:26 -0800
Subject: [Python-ideas] copyable iterators, named loops,
	continue a expression per indentation and a few functional things
In-Reply-To: <458EC1EF.1050903@acm.org>
References: <458D6545.4090709@gmx.net> <20061223211302.BC45.JCARLSON@uci.edu>
	<458E2CF7.201@acm.org>
	<76fd5acf0612240820p3b06ca3t1049186321350142@mail.gmail.com>
	<458EC1EF.1050903@acm.org>
Message-ID: <bbaeab100612241218v177b1d96sff2a41fc7a026504@mail.gmail.com>

On 12/24/06, Talin <talin at acm.org> wrote:
> Calvin Spealman wrote:
> > On 12/24/06, Talin <talin at acm.org> wrote:
> >> Josiah Carlson wrote:
> >>> Mathias Panzenb?ck <grosser.meister.morti at gmx.net> wrote:
> >>>> Copyable iterators
> >>>> ------------------
> >>>>
> >>>> There are a few ways how you could implement this. However, it only makes sense for iterators, not
> >>>> for generators!
> >>> -1 on the entire proposal.  All iterators (and generators) are already
> >>> copyable.  It's called list().
> >> Actually, what he wants to be able to do is to 'tee' an iterator.
> >> However, we already have a 'tee' function in itertools that does just
> >> that. (And it works on generators too!)
> >>
> >> -- Talin
> >
> > If I am understanding the proposal correctly, which I think I am,
> > itertools.tee is not the same as what this is proposing. itertools.tee
> > simply iterates the original and caches the results to be given when
> > iterating over the two tees created for it. This is not the same as
> > copying an iterator. Copying an iterator would create a new iterator
> > of the same state as the original. For example, with generators the
> > copy would be a new generator object with the same state as the
> > original and iterating over the copy would execute the same code as
> > the first.
> >
> > def g():
> >     i = 0
> >     while True:
> >         print i
> >         yield i
> >         i = i + 1
> >
> > If you "copy" this with itertools.tee, you only see i printed once for
> > each iteration of the generator, not each iteration of the tees. With
> > a real copying of iterators, if I copied this, iterating over the
> > copies would always produce an output of that copies value of i.
>
> The OP already stated that the proposal is not meant to apply to
> generators, and rightly so, because there's no way to copy all of the
> mutable state that a generator might access.
>
> However, I think that the idea of copying 'iterators but not generators'
> is too restrictive, since externally you might not be able to tell the
> difference. That's why I suggested tee, since it works on both. No, you
> don't get the same side effects, but that's not what the OP was asking for.
>

Ditto from me.  Generators are just a type of iterator technically, so
the OP really wanted to say "non-generator iterators".  But that is a
nasty restriction.

-Brett

From eopadoan at altavix.com  Mon Dec 25 00:16:23 2006
From: eopadoan at altavix.com (Eduardo "EdCrypt" O. Padoan)
Date: Sun, 24 Dec 2006 21:16:23 -0200
Subject: [Python-ideas] copyable iterators, named loops,
	continue a expression per indentation and a few functional things
In-Reply-To: <458D6545.4090709@gmx.net>
References: <458D6545.4090709@gmx.net>
Message-ID: <dea92f560612241516kd69a2b4hc86dad2c459fd06e@mail.gmail.com>

> Named loops

This is an useful idea. But lets explore it a little.
First, it is not exactly a name, a name is a reference to an object,
it is more like a lable.

> -----------
>
> With named loops you could break or continue other than only the inner most loop. I'm not sure about
> a syntax, though.

That is the useful part, and I will show why I think your syntax is
not the best for it.


> for x in X as loop_a:

The 'as' keyword (not a keyword untill 2.6) is used to give a name to
an object. Here, the lable 'loop_a', I think, should not be a name to
any object.

Second, it gives the impression that with '... X as loop_a' you are
giving X the name 'loop_a'. It reads that way and it is how 'import
... as ...', 'with ... as ...' works and, in Py3k, how 'except ... as
...' will work. Your syntax is an exception to the 'OBJ as NAME'
pattern, and could be misleading. The problem is, I couldnt think yet
of any better syntax.

Besides, the loop label is very usefull, and could be used in while
too if someone find a better syntax.


-- 
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
Blog: http://edcrypt.blogspot.com
Jabber: edcrypt at jabber dot org
ICQ: 161480283
GTalk: eduardo dot padoan at gmail dot com
MSN: eopadoan at altavix dot com


From grosser.meister.morti at gmx.net  Mon Dec 25 01:12:27 2006
From: grosser.meister.morti at gmx.net (=?UTF-8?B?TWF0aGlhcyBQYW56ZW5iw7Zjaw==?=)
Date: Mon, 25 Dec 2006 01:12:27 +0100
Subject: [Python-ideas] copyable iterators, named loops,
 continue a expression per indentation and a few functional things
In-Reply-To: <dea92f560612241516kd69a2b4hc86dad2c459fd06e@mail.gmail.com>
References: <458D6545.4090709@gmx.net>
	<dea92f560612241516kd69a2b4hc86dad2c459fd06e@mail.gmail.com>
Message-ID: <458F176B.9060304@gmx.net>

Eduardo "EdCrypt" O. Padoan schrieb:
>> Named loops
> 
> This is an useful idea. But lets explore it a little.
> First, it is not exactly a name, a name is a reference to an object,
> it is more like a lable.
> 
>> -----------
>>
>> With named loops you could break or continue other than only the inner
>> most loop. I'm not sure about
>> a syntax, though.
> 
> That is the useful part, and I will show why I think your syntax is
> not the best for it.
> 
> 
>> for x in X as loop_a:
> 
> The 'as' keyword (not a keyword untill 2.6) is used to give a name to
> an object. Here, the lable 'loop_a', I think, should not be a name to
> any object.
> 
> Second, it gives the impression that with '... X as loop_a' you are
> giving X the name 'loop_a'. It reads that way and it is how 'import
> ... as ...', 'with ... as ...' works and, in Py3k, how 'except ... as
> ...' will work. Your syntax is an exception to the 'OBJ as NAME'
> pattern, and could be misleading. The problem is, I couldnt think yet
> of any better syntax.
> 
> Besides, the loop label is very usefull, and could be used in while
> too if someone find a better syntax.
> 
> 

Indeed, that's a problem. Also that a name should always be a object. Maybe:
break # breaks inner most loop
break . # the same
break .. # breaks parent
break ... # breaks grandparent

but this is ugly, too.

maybe:
raise StopLoop(level)

I don't know.

Well this is a good way to break the outer most loop without any new syntax:

try:
	while cond1():
		while cond2():
			if cond3():
				raise MyLoopStopper()
except MyLoopStopper:
	pass


But how to make something like this for continue?


From rrr at ronadam.com  Mon Dec 25 07:42:35 2006
From: rrr at ronadam.com (Ron Adam)
Date: Mon, 25 Dec 2006 00:42:35 -0600
Subject: [Python-ideas] Python as meta-language
In-Reply-To: <458E9F11.6070307@ronadam.com>
References: <458E327D.5010409@acm.org> <458E9F11.6070307@ronadam.com>
Message-ID: <458F72DB.6030101@ronadam.com>

Ron Adam wrote:
> Talin wrote:
>> 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.
> 
> 
> Another (possibly related?) idea I think might be useful is to incorporate the 
> concept of responsibility, authorization, delegation into the language more 
> directly.  In a (well run) business responsibility and authority are delegated 
> in a way that gives the employee the ability to succeed, while also protecting 
> the interests of the business owners(s) by not giving too much power to any one 
> employee.  These are good business practices and I think they could be useful 
> concepts if implemented in a computer language in a more formal way.


I wanted to expand on this a bit since I do think it's related to several 
discussions that have taken place on the python-3000 list.  In general, I get a 
feeling that there is an effort to reach for that next thing.  So far that next 
thing has centered around efforts to extend generators, the with statement, 
generic functions, and improved threading/multiprocessing.  And now your desire 
for mini-language support could be included in that.  So how are these all 
related and is there a common theme that can organize these ideas in a way that 
is not brain exploding, as one respected individual here abouts would put it.  I 
think so.

I mentioned above the business concepts of responsibility, authorization and 
delegation.  But without describing how those concept would relate to a computer 
languages in general and also python, it probably doesn't mean a whole lot.  So 
I'll try to give an outline of how this might work.


Most business's are pretty boring in that there are no (or few) surprises. 
Everything is planned out.  There is usually a manual of procedures to follow 
that is used to train new workers.  Those procedures are usually based on sound 
and well tried business practices.  The biggest problem most business's have is 
hiring dependable workers to actually do the work.  In most cases workers are 
expected to do more than one job.  Also there are times or situations where 
workers join together to do one larger job.  These are also relationships that 
would be good to emulate in software.  So lets look at some of these 
relationships and how they might be organized in a software program.

A brief outline to help picture things:

     Data base -  The inventory

     Skill base - The procedures, (a collection of routines)

     Knowledge base - How to combine skills and data to achieve desired results.

     Worker objects:
        Responsibility - the objectives the worker must achieve
        Authorization - limits of what data, skills, and knowledge, can be used

     Delegation - The assignment of responsibility and authority to a worker.

A Skill base might just be another name for generic functions.  It's really just 
a collection of routines to do standardized things to data.  These could be 
tests to check quality or values, or routines to combine, split or alter a unit 
of data.

A knowledge base is a bit more, it's the instructions of how to combine skills 
to achieve specific objectives.

Workers would be something new.  They would be sort of be like an object, but 
instead of having limited skills (methods) in them, they might have 
responsibilities and authorizations. Each responsibility would represent a 
different activity which would be defined by the knowledge base.  And 
authorizations would specify what knowledge and skills can be used.  This would 
be needed to insure a worker object doesn't get used in an abusive way.  For 
example if you have a worker object assigned to processing input you may want to 
limit this particular worker to this one activity so there is little chance it 
can be hacked and used for other things.

In other less critical places you may have a group (pool) of worker objects that 
can fill multiple needs.

These worker objects could be run on different threads.  Groups of workers might 
be run on different CPU's.  Possibly, this would be something that is determined 
by the interpreter (manager) and not something the programmer has to think about.


These are just seeds of ideas right now, but I think there is a lot of potential 
in going in this direction. I would place this in between artificial 
intelligence and objective programming.  This would be a higher level of 
abstraction with the goal of using both software and the underlying hardware 
more efficiently.

How this translates to different programming models depends on how you 
distribute and organize the work between worker objects.

A series of worker with each a single responsibility would be a procedural 
structure.  (an assembly line)

A group of  workers with many shared responsibilities would be a parallel (or as 
close as the hardware allows) structure.  These would be used to simulate models 
with many object and specifications.


Ok it's late and I'm starting to loose my focus.  Hopefully you can see how this 
might be related to either emulating mini-languages, or how it might be a 
mini-language in it self.  And also hopefully there isn't too many typos or 
mistakes due to me being tired.

Cheers,
    Ron





























From talin at acm.org  Mon Dec 25 09:25:23 2006
From: talin at acm.org (Talin)
Date: Mon, 25 Dec 2006 00:25:23 -0800
Subject: [Python-ideas] Python as meta-language
In-Reply-To: <20061224113553.BC48.JCARLSON@uci.edu>
References: <458E327D.5010409@acm.org> <20061224113553.BC48.JCARLSON@uci.edu>
Message-ID: <458F8AF3.7040709@acm.org>

Josiah Carlson wrote:
> Talin <talin at acm.org> wrote:
>> 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.
> 
> If you haven't already seen it, you should check out Logix:
> http://www.livelogix.net/logix/

I think I looked at it before, but I'll have another look. From what I 
can tell, there's some interesting ideas here, but there are also some 
things that are kind of kludged together.

I'm not sure that I would want Python to be quite so malleable as Logix. 
The reason for this is that it's hard to reason about a language when 
the language is so changeable. Of course, this argument shouldn't be 
taken too strongly - I don't mean to condemn programmable syntax in 
general, I just don't want to take it too far.

I think what would make sense is to identify some of the most common use 
cases in Logix, and see if those specific use cases fit within the 
Python model. The example in the docs shows how to define an 'isa' 
operator, and I certainly think that Python readability would be 
improved by having something similar. (I've argued this before, so I 
don't expect to get much traction on this.) But I wouldn't go so far as 
to allow you to define brand new operators of arbitrary precedence.

Similarly, I think that it wouldn't hurt to expand the suite of 
operators that are built into the compiler. Like most languages, 
Python's compiler supports only those operators which are defined for 
built-in types. Thus, we have the math operators +, -, * and /, because 
we have built-in numeric types which support those basic operations.

However, mathematics defines many different kinds of operators, many of 
which operate on other kinds of entities than just scalars. Examples 
include cross-product and dot-product. Most languages don't define 
operators for cross-product and dot-product, because they don't define 
matrices as a built-in type. This gets inconvenient when you are doing 
things like, say, 3D graphics programming, where they types that you are 
operating on are vectors and matrices, and writing the code using 
operators allows for more concise and readable code than having to do 
everything using function calls. (There's an inherent readability 
advantage IMHO to being able to take something right out of a math 
textbook and type it directly as a line of code.)

Of course, anything that's done with an operator can also be done with a 
function call, but from a readability standpoint, there are times when 
operators make a lot of sense. After all, do you really want to write 
'add( multiply( a, 1 ), 2 )'?

Given the ability to overload operators and define their meaning, why 
should we limit the set of operators recognized by the compiler to only 
those that make sense on built-in types?

I would say that while it certainly does make sense to give operators a 
standard *meaning*, there's no reason why operators have to have a 
standard *implementation*. In other words - unlike Logix, I want to be 
able to look at a given operator and always know what it means, just as 
I can look at the symbol '+' and know that it is somehow related to the 
concept of 'addition'. The same would be true for any new operators.

In the case of mathematics and other languages that make heavy use of 
symbols, there's the additional problem of rendering those symbols into 
some combination of ASCII characters. To see what I mean, have a look at 
this chart of math symbols as a starting point:

    http://en.wikipedia.org/wiki/Table_of_mathematical_symbols.

Some of these symbols would be fairly difficult to represent in ASCII, 
others would be pretty easy. For example, the characters '=>' could be 
used to represent the logical 'implies' symbol.

A less trivial example would be the "::=" operator that is used in many 
formal grammars. I'd call this the "becomes" operator - thus, the 
expression "a ::= b" might be spoken as "a becomes b" (or is it the 
other way around?). A corresponding __becomes__ function would allow the 
operator to be implemented for certain types, although I haven't really 
worked out what the calling protocol would be.

Such an operator could be used in more than just parser generators 
however; Ideally, it ought to be usable as an overloadable assignment 
operator, or any situation where you want to express the concept 'a is 
defined as b'.

-- Talin


From talin at acm.org  Mon Dec 25 09:46:04 2006
From: talin at acm.org (Talin)
Date: Mon, 25 Dec 2006 00:46:04 -0800
Subject: [Python-ideas] Python as meta-language
In-Reply-To: <458F72DB.6030101@ronadam.com>
References: <458E327D.5010409@acm.org> <458E9F11.6070307@ronadam.com>
	<458F72DB.6030101@ronadam.com>
Message-ID: <458F8FCC.30604@acm.org>

Ron Adam wrote:
> Ron Adam wrote:
>> Talin wrote:
>>> 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.
>>
>> Another (possibly related?) idea I think might be useful is to incorporate the 
>> concept of responsibility, authorization, delegation into the language more 
>> directly.  In a (well run) business responsibility and authority are delegated 
>> in a way that gives the employee the ability to succeed, while also protecting 
>> the interests of the business owners(s) by not giving too much power to any one 
>> employee.  These are good business practices and I think they could be useful 
>> concepts if implemented in a computer language in a more formal way.
> 
> 
> I wanted to expand on this a bit since I do think it's related to several 
> discussions that have taken place on the python-3000 list.  In general, I get a 
> feeling that there is an effort to reach for that next thing.  So far that next 
> thing has centered around efforts to extend generators, the with statement, 
> generic functions, and improved threading/multiprocessing.  And now your desire 
> for mini-language support could be included in that.  So how are these all 
> related and is there a common theme that can organize these ideas in a way that 
> is not brain exploding, as one respected individual here abouts would put it.  I 
> think so.

<snip>

Two places I think you might want to look for ideas.

The first is the operating system EROS, which is a 'capability-based' 
operating system. Every object in the system has an explicit set of 
'capabilities' (i.e. authorizations) that are enforced at the kernel level.

For the second, google for the words "agoric systems". The notion here 
is that a software system is like an economic system. Agorics takes this 
further by having various software modules compete against each other in 
a marketplace, so for example if you want to sort a list, then various 
agents within the system (representing different algorithms with 
different time/space trade offs) 'bid' on the job; The winner (which may 
vary depending on the current system constraints) gets 'paid' from the 
budget of the caller.

Also, since you mentioned concurrency: I recently saw a presentation by 
a fellow from Intel (I don't remember his name, but apparently he's also 
on the C++ standards committee), who was basically saying that from now, 
until the rest of our lives, concurrency will be the only way to improve 
performance - that "Moore's Law" (in the sense of how many transistors 
can be stuffed on a chip) will continue for the foreseeable future, but 
we're pretty much reached the limit in terms of how much performance we 
can squeeze out of a single scalar processor; Clock speeds won't get 
that much higher (certainly not orders of magnitude), and any further 
pipelining is just going to increase memory latency. One the other hand, 
there's no practical barrier to having a single chip with, say, 128 
hyperthread cores on it, within the next 10 years or so. (I'm not sure I 
entirely buy this - there may be some way around this by rethinking the 
way memory is accessed.)

Anyway, his basic message was this: There will come a time when, if your 
app is only single-threaded, that you'll effectively be using 1/128th of 
the machine's power. And this will be true for the rest of your life.

He also mentioned that until we get 'transactional memory' (i.e. the 
ability to do low-level operations that have commit / rollback 
semantics) that multi threaded programming is always going to suck.

...but that's a whole 'nother topic.

-- Talin



From jcarlson at uci.edu  Mon Dec 25 16:27:00 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 25 Dec 2006 07:27:00 -0800
Subject: [Python-ideas] Python as meta-language
In-Reply-To: <458F8AF3.7040709@acm.org>
References: <20061224113553.BC48.JCARLSON@uci.edu> <458F8AF3.7040709@acm.org>
Message-ID: <20061225064923.BC51.JCARLSON@uci.edu>


Talin <talin at acm.org> wrote:
> 
> Josiah Carlson wrote:
> > Talin <talin at acm.org> wrote:
> >> 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.
> > 
> > If you haven't already seen it, you should check out Logix:
> > http://www.livelogix.net/logix/
> 
> I think I looked at it before, but I'll have another look. From what I 
> can tell, there's some interesting ideas here, but there are also some 
> things that are kind of kludged together.

I should have said a bit more.  Basically, my idea of suggesting that
you take a look at Logix was a veiled attempt at saying "I think the
base Python language syntax is fine".  While Logix does go to the
extreme of making Python syntax far more maleable than is generally
desired (in my opinion), there are cases where conservative use does
make life easier.  Say, for example, if one preferred C-style
conditional syntax to Python's conditional syntax.


> I'm not sure that I would want Python to be quite so malleable as Logix. 
> The reason for this is that it's hard to reason about a language when 
> the language is so changeable. Of course, this argument shouldn't be 
> taken too strongly - I don't mean to condemn programmable syntax in 
> general, I just don't want to take it too far.

The ultimate question is, "what is too far?"

[snip math operation discussion]

While it would be convenient to define all standard mathematic
operations, I don't believe that Python is the language for it.  Python
can be used as a language to do mathematics, it's not a computer algebra
system, and I believe the vast majority of mathematical operations
should be limited to computer algebra systems.  Say, for example, Sage.

Offering "production rules" a'la ::=, wile being an interesting idea,
can be represented with current syntax, if one uses certain "tricks" (AB
for concatenating A and B, | for offering alternatives, * for repetition,
etc., and the use of a custom namespace for name resolution):

    A = B | C | D.F | E

Anyways.  Come up with a set of operators.  I don't know if consensus is
where we should go with this, but the existence of Logix, in my opinion,
puts the realm of alternate/additional operators within the realm of
extension modules, and operators need to show that they have (or would
be used) significantly within the Python user community (like the
requirements for standard library module additions).  So far, aside from
matrix multiplication (which can be defined as * for all non-single
vector multiplications unambiguously), I've not heard any *compelling*
cases for operators.

Also, I'm sort of a curmudgeony jerk (I like my Python as it is), so
while you perhaps shouldn't take me *too* seriously when I say "Use
Logix", maybe you should take my advice to find a set of *useful*
operators, and specify *why* they would be useful (hopefully in a
general sense).

 - Josiah



From dwblas at gmail.com  Tue Dec 26 23:56:17 2006
From: dwblas at gmail.com (David Blaschke)
Date: Tue, 26 Dec 2006 14:56:17 -0800
Subject: [Python-ideas]  copyable iterators, named loops,
	continue a expression per indentation and a few functional things
Message-ID: <7e69a0400612261456x7b1f1c47ye02a31b1e4705b9@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20061226/dfe38099/attachment.html>

From grosser.meister.morti at gmx.net  Wed Dec 27 04:05:11 2006
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Wed, 27 Dec 2006 04:05:11 +0100
Subject: [Python-ideas] copyable iterators, named loops,
 continue a expression per indentation and a few functional things
In-Reply-To: <7e69a0400612261456x7b1f1c47ye02a31b1e4705b9@mail.gmail.com>
References: <7e69a0400612261456x7b1f1c47ye02a31b1e4705b9@mail.gmail.com>
Message-ID: <4591E2E7.60206@gmx.net>

David Blaschke schrieb:
> 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
> 
> 

of course you could do it this way. then you could also say, what is "break" and "continue" good for
at all? I think its a matter of taste (not good or bad taste, just different)