From ncoghlan at gmail.com  Mon May  1 02:56:20 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 01 May 2006 10:56:20 +1000
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06Apr30.125533pdt."58641"@synergy1.parc.xerox.com>
References: <06Apr30.125533pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <44555CB4.1030606@gmail.com>

Bill Janssen wrote:
> I've looked over the PyGUI code a bit more carefully.
> 
> It still looks good to me as a Py3K standard portable GUI candidate.
> In particular, it doesn't look like it would be hard to port to Java
> Swing (for Jython) and Windows.Forms (for IronPython on .NET and
> Mono).  Might make good summer projects...

So you're really aiming at incorporating a gui-api for Python, so that it can 
be pointed at the backend of choice? Something similar to what the DB-api 
achieves for databases?

That certainly seems like a laudable goal. Advanced usage might still need to 
dig into the underlying GUI framework directly, but a common front-end could 
cover the needs of basic apps.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From greg.ewing at canterbury.ac.nz  Mon May  1 03:00:27 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 01 May 2006 13:00:27 +1200
Subject: [Python-3000] Automatically invoking str() in str.join()
In-Reply-To: <e2ql0f$9ee$1@sea.gmane.org>
References: <4450C80D.50002@iinet.net.au> <e2qkki$79p$1@sea.gmane.org>
	<e2ql0f$9ee$1@sea.gmane.org>
Message-ID: <44555DAB.5090108@canterbury.ac.nz>

Fredrik Lundh wrote:
> join()
> 
> it's time to make this a builtin.  the "it's the separator that's doing the
> joining" idea is silly and unintuitive, and should be fixed.

+1

--
Greg

From nnorwitz at gmail.com  Mon May  1 03:07:21 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 30 Apr 2006 18:07:21 -0700
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <-7719664816515528725@unknownmsgid>
References: <-7719664816515528725@unknownmsgid>
Message-ID: <ee2a432c0604301807l78033491s8ab43c3d26290b4b@mail.gmail.com>

On 4/30/06, Bill Janssen <janssen at parc.com> wrote:
> I've looked over the PyGUI code a bit more carefully.
>
> It still looks good to me as a Py3K standard portable GUI candidate.
> In particular, it doesn't look like it would be hard to port to Java
> Swing (for Jython) and Windows.Forms (for IronPython on .NET and
> Mono).  Might make good summer projects...

You could mentor a Summer of Code project and find a student to do the work.

http://wiki.python.org/moin/SummerOfCode

n

From tjreedy at udel.edu  Mon May  1 04:42:35 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 30 Apr 2006 22:42:35 -0400
Subject: [Python-3000] Add a standard GUI system
References: <06Apr29.004032pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <013f01c66cc8$e786ada0$0300a8c0@HPPAVILION>

"Bill Janssen" <janssen at parc.com> wrote

a reply to my objection to his GUI proposal  --
that makes the proposal more sensible to me.

I see you putting forth four propositions.  My wording of them is:

1. Python 3 should (still) have a standard lib GUI system.

2a. TK/Tkinter should not be grandfathered in.
2b. Current popularity should not be the determining factor.

3. The GUI chosen should be Pythonic, rather than a direct translation of, 
for instance, Jave or C++ style.

4. An updated and revised version of PyGUI looks like the best choice.

I currently agree with 1, 2a, maybe 2b, 3 to the extent I know the 
difference (but would like to see specific examples), and am neutral to 4 
due to ignorance.  I could imagine someone agreeing with 1-3 but proposing, 
say, Wax instead.  So that should be the most controversial.

One thing I do know about wxWidgets is that it includes a library of utility 
functions that are not directly gui functions and that duplicate functions 
already in Python.  While it is sensible for wxPython to wrap these, it 
would be duplicative to add them to the standard lib.

Terry Jan Reedy


From collinw at gmail.com  Mon May  1 05:22:12 2006
From: collinw at gmail.com (Collin Winter)
Date: Sun, 30 Apr 2006 23:22:12 -0400
Subject: [Python-3000] Changing function-related TypeErrors
Message-ID: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>

One of the things that's always puzzled me about Python 2.x is why any
of the following raise a TypeError:

Given a function "def foo(a, b, c=None)",

> foo(4)
> foo(4, 5, 6, 7)
> foo(4, 5, b=6)
> foo(4, 5, d=6)

all raise TypeErrors, as do several other classes of calling errors --
none of which have anything to do with the type of an object. This
usage of TypeError is confusing. Also, "except TypeError" statements
may end up accidentally hiding this class of error, making one of
these situations very difficult to debug.

To make it more obvious what the problem is, I propose that Python
3000 introduce an ArgumentError exception to handle these cases.

The one case that I'm not sure about is this:
"""
>>> def foo(a, (b, c)): pass
...
>>> foo(5, 6)
TraceBack (most recent call last)
  File "<stdin>", line 1, in <module>
  File "<stind>", line 1, in foo
TypeError: unpack non-sequence
"""
I can see arguments both for keeping this as a TypeError and for
changing it to an ArgumentError.


Since I doubt that anyone is (intentionally) trapping this particular
brand of TypeErrors, it might even be feasible to make the TypeError
-> ArgumentError changeover in Python 2.6.

I'm more than willing to work up a PEP and patches for this if there's interest.

Collin Winter

From alexander.belopolsky at gmail.com  Mon May  1 04:50:28 2006
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sun, 30 Apr 2006 22:50:28 -0400
Subject: [Python-3000] Future of slices
Message-ID: <49841143-4F65-40DF-9324-8587712F45D3@local>

Since Py3K is going to considerably change the behavior of the  
fundamental collection types, it may be appropriate to revisit the  
design of slicing.  I would like to start the discussion by  
mentioning some of the python 2.x slicing features that I don't  
like.   I fully anticipate that most of the following will quickly  
end up in PEP-3099, but that by itself is progress :-).

1. l[:] syntax for shallow copy.  I remember this being discussed  
before, but could not dig out that discussion.  The difficulty  
finding the old discussion on this topic illustrates the point: this  
feature is not easily discoverable ("[:]" is a rare Google query that  
results in an empty page:-).  In 2.x TOOWTDI: from copy import copy;  
copy(l), which is a better way for several reasons (explicit choice  
wrt. copy/deepcopy, consistency  with the other collection types:  
dict, set, etc.)

2. Overloading of [] syntax. The primary meaning of c[i] is: get the  
i-th item from the collection. This meaning is consistent between  
lists/tuples and dicts.  The only difference is that  i may not be an  
integer in the case of dict.   Slicing is specific  to lists, tuples  
and strings (I am ignoring non-built-in types for now). This is an  
operation that is very different from "get item", but uses the same  
syntax. The main problem with [] overloading is that c[i] is not  
guaranteed to be "smaller" than c.  If i = slice(None), c[i] is a  
copy of i.   This problem is even worse for strings, where c[i] is  
*always* a slice: c[i] is the same as c[i:i+1].   I think it would be  
better to have the slicing functionality provided by named functions  
or methods, for example l.slice(start, stop, stride) instead of l 
[start:stop:stride].  If that is deemed to result in a different  
language, maybe we can reconsider compiling l[a:b:c] into  
l.__getitem__(slice(a,b,c)) and go back to __getslice__.

3.  Overloading of []= syntax. Similarly to #2, this is the case when  
the same notation is used to do conceptually different operations.   
In addition it provides alternative ways to do the same thing (e.g. l  
+= a vs. l[len(l):] = a).

4. Extended slicing.  I believe the most common use case l[::-1] was  
eliminated with the introduction of "reversed".  The remaining  
functionality in case of a tuple c can be expressed as tuple(c[i] for  
i in range(start,stop, stride)).  The later is more verbose than c 
[start:stop:stride], but also more flexible.



From greg.ewing at canterbury.ac.nz  Mon May  1 08:51:51 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 01 May 2006 18:51:51 +1200
Subject: [Python-3000] sets in P3K?
In-Reply-To: <1146188543.10790.65.camel@resist.wooz.org>
References: <mailman.18397.1146112002.27774.python-3000@python.org>
	<Pine.GSO.4.58.0604270656080.5502@dvp.cs> <4450BE0E.8090903@gmail.com>
	<4450C311.8040603@fas.harvard.edu> <4450CB36.7090504@gmail.com>
	<44511237.5000609@ewtllc.com>
	<1146170691.10791.20.camel@resist.wooz.org>
	<44514E29.4080406@wickedgrey.com>
	<1146188543.10790.65.camel@resist.wooz.org>
Message-ID: <4455B007.4040204@canterbury.ac.nz>

Barry Warsaw wrote:

> Well here's another nutty idea.  We actually have two ways to create
> literal tuples, right?

An even nuttier idea: don't use {} at all for sets,
use backquotes instead. No inconsistency for empty
sets would be required then.

   set3 = `1, 2, 3`
   set1 = `1`
   set0 = ``

Slightly less nutty idea: use {} but introduce
a new reserved word 'phi' for constructing an
empty set.

   set3 = {1, 2, 3}
   set1 = {1}
   set0 = phi

--
Greg

From greg.ewing at canterbury.ac.nz  Mon May  1 09:39:35 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 01 May 2006 19:39:35 +1200
Subject: [Python-3000] sets in P3K?
In-Reply-To: <17489.59905.992631.381588@montanaro.dyndns.org>
References: <Pine.GSO.4.58.0604131106140.23335@qew.cs>
	<44506457.1040607@gmx.net> <e2q77a$kiv$1@sea.gmane.org>
	<200604271217.59323.gmccaughan@synaptics-uk.com>
	<3d2ce8cb0604280007q303261bbu6bbc7634d6a2a9b0@mail.gmail.com>
	<17489.59905.992631.381588@montanaro.dyndns.org>
Message-ID: <4455BB37.2070402@canterbury.ac.nz>

skip at pobox.com wrote:
> In my case it's
> 
>     Fn-Shift-F3 / O
> 
> though I note now that my Mac supports Shift-Option-O as well.  In any case,
> neither is all that straightforward,

What we need here is APL-style overstrikes, so you can type
an O with a / on top of it. :-)

This would also resolve the != vs <> wars, since we could
use = with / over it.

--
Greg

From thomas at python.org  Mon May  1 09:58:44 2006
From: thomas at python.org (Thomas Wouters)
Date: Mon, 1 May 2006 09:58:44 +0200
Subject: [Python-3000] Automatically invoking str() in str.join()
In-Reply-To: <e2ql0f$9ee$1@sea.gmane.org>
References: <4450C80D.50002@iinet.net.au> <e2qkki$79p$1@sea.gmane.org>
	<e2ql0f$9ee$1@sea.gmane.org>
Message-ID: <9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com>

On 4/27/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
>
> join()
>
> it's time to make this a builtin.  the "it's the separator that's doing
> the
> joining" idea is silly and unintuitive, and should be fixed.


I disagree, and I believe that would be a big mistake to change it.

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060501/c1ba94d7/attachment.html 

From jcarlson at uci.edu  Mon May  1 10:32:23 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 01 May 2006 01:32:23 -0700
Subject: [Python-3000] Future of slices
In-Reply-To: <49841143-4F65-40DF-9324-8587712F45D3@local>
References: <49841143-4F65-40DF-9324-8587712F45D3@local>
Message-ID: <20060501011031.674D.JCARLSON@uci.edu>


If you want to get my general opinion; -1 on all of your recommendations. 
In each part, I describe why.

Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> 1. l[:] syntax for shallow copy.

Note that [:] doesn't necessarily copy.  It certainly is the case for
Python lists, strings, tuples, and unicode today, but given standard
slicing of l[i:j] producing a copy of a section of a list/string/tuple
from i...j, removing the first is equivalent to 'the start', and
removing the second being equivalent to 'the end'; having l[:] do
something other than slicing the entire sequence (at least for
list/string/tuple) seems pretty unintuitive.

> 
> 2. Overloading of [] syntax. The primary meaning of c[i] is: get the  
> i-th item from the collection.
[snip]
> The main problem with [] overloading is that c[i] is not  
> guaranteed to be "smaller" than c.

How is this related at all to anything?

> This problem is even worse for strings, where c[i] is  
> *always* a slice: c[i] is the same as c[i:i+1].

No.
    >>> ''[0]
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    IndexError: string index out of range
    >>> ''[0:1]
    ''

> maybe we can reconsider compiling l[a:b:c] into  
> l.__getitem__(slice(a,b,c)) and go back to __getslice__.

You can still use __getslice__ if you want (I believe it is deprecated,
but I don't know when it will be removed)...

    >>> class foo(object):
    ...     def __getitem__(self, *args):
    ...             print 'getitem', args
    ...     def __getslice__(self, *args):
    ...             print 'getslice', args
    ...
    >>> foo()[1]
    getitem (1,)
    >>> foo()[1:]
    getslice (1, 2147483647)
    >>> del foo.__getslice__
    >>> foo()[1:]
    getitem (slice(1, None, None),)
    >>>


> 3.  Overloading of []= syntax. Similarly to #2, this is the case when  
> the same notation is used to do conceptually different operations.   
> In addition it provides alternative ways to do the same thing (e.g. l  
> += a vs. l[len(l):] = a).

There should be one-- and preferably only one --obvious way to do it.

'l[len(l):] = a' is not obvious.  In my opinion, neither is 'l += a' (at
least for certain kinds of 'l' and 'a'). If you have a list,
list.extend() is the obvious way. If you have something else, then
probably some other method is the obvious way. Getting rid of
non-obvious ways of doing these kinds of things would be foolish,
especially when it would be disabling corner cases that may be used by
real code (and not interactive sessions).

Say, for example, someone were doing something like...
    l[i:] = k
And what if i just happened to be >= len(l)?  How would raising an
exception help anyone?


> 4. Extended slicing.  I believe the most common use case l[::-1] was  
> eliminated with the introduction of "reversed". The remaining  
> functionality in case of a tuple c can be expressed as tuple(c[i] for  
> i in range(start,stop, stride)).  The later is more verbose than c 
> [start:stop:stride], but also more flexible.


Technically speaking, all slicing for current built-in Python sequence
objects can be replaced by a variant of:
    <type>(c[i] for i in xrange(start,stop,step))
...but that doesn't mean that removing read-based slicing makes any
sense at all.  Which would you rather do:
    b = a[i:j]
or
    b = str(a[k] for i in xrange(i,j))

Obviously the first.  People who use extended slicing feel the same way,
as they can add a :X and have precisely what they want.


 - Josiah


From ncoghlan at gmail.com  Mon May  1 10:34:48 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 01 May 2006 18:34:48 +1000
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
Message-ID: <4455C828.1060209@gmail.com>

Collin Winter wrote:
> One of the things that's always puzzled me about Python 2.x is why any
> of the following raise a TypeError:
> 
> Given a function "def foo(a, b, c=None)",
> 
>> foo(4)
>> foo(4, 5, 6, 7)
>> foo(4, 5, b=6)
>> foo(4, 5, d=6)
> 
> all raise TypeErrors, as do several other classes of calling errors --
> none of which have anything to do with the type of an object. This
> usage of TypeError is confusing. Also, "except TypeError" statements
> may end up accidentally hiding this class of error, making one of
> these situations very difficult to debug.

The Type Error is actually referring to the type of 'foo' - the code is 
clearly expecting it to be something with a different __call__ signature.

However, for things like functions, there's nothing wrong with the type of the 
supplied object. For functions, the problem is actually a Value Error, in that 
the signature of that particular function *instance* is wrong.

I don't really have a preference here - the current error is a little obscure, 
but I'm not sure fixing it is worth the effort of adding a new exception type.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From fredrik at pythonware.com  Mon May  1 10:57:56 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 1 May 2006 10:57:56 +0200
Subject: [Python-3000] Automatically invoking str() in str.join()
References: <4450C80D.50002@iinet.net.au>
	<e2qkki$79p$1@sea.gmane.org><e2ql0f$9ee$1@sea.gmane.org>
	<9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com>
Message-ID: <e34iim$24o$1@sea.gmane.org>

Thomas Wouters wrote:

> > join()
> >
> > it's time to make this a builtin.  the "it's the separator that's doing
> > the
> > joining" idea is silly and unintuitive, and should be fixed.
>
>
> I disagree, and I believe that would be a big mistake to change it.

big mistake?

can anyone point to one other example where "call method on
literal" is used in Python ?

didn't think so.

(there's been more "cannot find out how to join strings" posts on
c.l.python since my last post on this topic, btw ;-)

</F>




From ncoghlan at gmail.com  Mon May  1 11:06:10 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 01 May 2006 19:06:10 +1000
Subject: [Python-3000] Future of slices
In-Reply-To: <49841143-4F65-40DF-9324-8587712F45D3@local>
References: <49841143-4F65-40DF-9324-8587712F45D3@local>
Message-ID: <4455CF82.9070607@gmail.com>

Short version: +1 for the first point (but for different reasons), -1 for the 
rest. Use cases for advanced slicing operations are not provided by the 
standard library, but by Numpy's sophisticated data manipulation capabilities.

Alexander Belopolsky wrote:
<get rid of ...>> 1. l[:] syntax for shallow copy.


I kind of agree with this one, mainly because I'd like standard library data 
types to return views for slicing operations. Making a copy based on a view is 
as easy as wrapping the view in a call to the appropriate constructor. 
Avoiding the memory impact of multiple slicing operations that copy data 
around is much harder.

Returning views rather than copies would also eliminate some of the use cases 
for islice().

> 2. Overloading of [] syntax. The primary meaning of c[i] is: get the  
> i-th item from the collection. This meaning is consistent between  
> lists/tuples and dicts.  The only difference is that  i may not be an  
> integer in the case of dict.

The c[x] syntax isn't really overloaded - it always means "ask the container c 
for the item corresponding to subscript x"

For a dict, x must be hashable, but otherwise both x and the item returned are 
unconstrained. Other mappings may remove the requirement for hashability.

Sequences use the rule that x must be either an integer (object with an 
__index__ method), or a slice object. The key characteristic that 
distinguishes a sequence from a general mapping is that c[0:0] == type(c)().

Multi-dimensional arrays then loosen the restrictions on x imposed by 
sequences slightly to also permit tuples. The key characteristic to 
distinguish Numpy-style arrays from other sequences is that c[0:0] == c[0:0,].

These behaviours aren't fundamental rules of programming that need to be 
embedded in the underlying language implementation. The kinds of subscript 
that makes sense may vary from container to container. Python's current 
approach avoids embedding particular interpretations in the language allowing 
each data structure designer to make their own decisions (hopefully guided by 
the conventions used for existing data structures).

>   Slicing is specific  to lists, tuples  
> and strings (I am ignoring non-built-in types for now).

Ignoring external types when discussing slicing is a mistake. Much of Python's 
slicing design was driven by the Numpy folks, rather than the needs of the 
standard library.

> 3.  Overloading of []= syntax. Similarly to #2, this is the case when  
> the same notation is used to do conceptually different operations.   
> In addition it provides alternative ways to do the same thing (e.g. l  
> += a vs. l[len(l):] = a).

The OOW in TOOWTDI stands for "One Obvious Way" not "Only One Way" :)

As Josiah said, for manipulating data structures, that obvious way is 
typically the appropriate methods of the collection being used.

> 4. Extended slicing.  I believe the most common use case l[::-1] was  
> eliminated with the introduction of "reversed".  The remaining  
> functionality in case of a tuple c can be expressed as tuple(c[i] for  
> i in range(start,stop, stride)).  The later is more verbose than c 
> [start:stop:stride], but also more flexible.

Extended slicing was added to provide syntactic support for various operations 
on Numpy's multi-dimensional arrays. As I understand it, the later addition of 
support to the types in the standard library was more due to consistency 
reasons than really compelling uses cases.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From thomas at python.org  Mon May  1 12:41:29 2006
From: thomas at python.org (Thomas Wouters)
Date: Mon, 1 May 2006 12:41:29 +0200
Subject: [Python-3000] Automatically invoking str() in str.join()
In-Reply-To: <e34iim$24o$1@sea.gmane.org>
References: <4450C80D.50002@iinet.net.au> <e2qkki$79p$1@sea.gmane.org>
	<e2ql0f$9ee$1@sea.gmane.org>
	<9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com>
	<e34iim$24o$1@sea.gmane.org>
Message-ID: <9e804ac0605010341u68e77864u6d2f8b48848f725c@mail.gmail.com>

On 5/1/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
>
> Thomas Wouters wrote:
>
> > > join()
> > >
> > > it's time to make this a builtin.  the "it's the separator that's
> doing
> > > the
> > > joining" idea is silly and unintuitive, and should be fixed.
> >
> >
> > I disagree, and I believe that would be a big mistake to change it.
>
> big mistake?


Yes.

can anyone point to one other example where "call method on
> literal" is used in Python ?


It doesn't matter. Either case is confusing, one way or another, as Tim has
already argued. Changing it would be a big mistake. If you want me to come
with more comprehensive arguments (other than what Tim already covered),
please come with more comprehensive arguments *for* the change, too.

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060501/efb2a13a/attachment.htm 

From birchb at tpg.com.au  Mon May  1 12:50:08 2006
From: birchb at tpg.com.au (Bill Birch)
Date: Mon, 1 May 2006 20:50:08 +1000
Subject: [Python-3000] Metaclass syntax?
Message-ID: <200605012050.08254.birchb@tpg.com.au>

This has probably been proposed before, here goes anyhow. 

instead of:

   class TheLarch(deciduous)
       __metaclass__ = KindsOfTrees

could we have this syntax:

   class[KindsOfTrees]  TheLarch(deciduous):
	   pass

more real examples:

   class[interface] iterable: pass

   class[Persistent] Customer: pass

er, that's it.

-- 
http://billbirch.wordpress.com/

From fredrik at pythonware.com  Mon May  1 12:53:30 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 1 May 2006 12:53:30 +0200
Subject: [Python-3000] Automatically invoking str() in str.join()
References: <4450C80D.50002@iinet.net.au>
	<e2qkki$79p$1@sea.gmane.org><e2ql0f$9ee$1@sea.gmane.org><9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com><e34iim$24o$1@sea.gmane.org>
	<9e804ac0605010341u68e77864u6d2f8b48848f725c@mail.gmail.com>
Message-ID: <e34pbc$kv3$1@sea.gmane.org>

Thomas Wouters wrote:

> > can anyone point to one other example where "call method on
> > literal" is used in Python ?
>
> It doesn't matter.

it doesn't matter to you when the preferred way to do things don't look
like Python code?

> Either case is confusing, one way or another, as Tim has
> already argued.

this far, people have argued that it's confusing when methods have more
than one argument (which is pure rubbish), and that people seem to recall
that this was a common issue on comp.lang.python (it wasn't; especially
not compared to the amount of "how do I join things" posts we're seeing
these days and the amount of "eww. that's ugly" I hear when teaching
Python...).

you're also forgetting that I wrote the Unicode type, and was among the
first persons to bring up the "how the heck do we handle join" issue.
there's no frigging way anyone can convince me that the current design
is the result of a careful design process; the whole argument went "we
need an implementation hook anyway, so we might as well expose it".

if you think that's a good design guideline, please explain why we shouldn't
remove "len", "getattr", "int/float/complex/str/repr" (as converters), and a ton
of other things from the language.  after all, isn't obj.__getattr__(name) a lot
less error-prone than getattr(obj, name) ?

> Changing it would be a big mistake.

nonsense.  keeping a design mistake is a big mistake.  fixing a design mistake
is a good thing, and it'll make Python a nicer language.

</F>




From greg.ewing at canterbury.ac.nz  Mon May  1 12:57:57 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 01 May 2006 22:57:57 +1200
Subject: [Python-3000] Metaclass syntax?
In-Reply-To: <200605012050.08254.birchb@tpg.com.au>
References: <200605012050.08254.birchb@tpg.com.au>
Message-ID: <4455E9B5.3040006@canterbury.ac.nz>

Bill Birch wrote:

>    class[KindsOfTrees]  TheLarch(deciduous):
> 	   pass

I'd prefer not to put anything between 'class' and
the name being defined. Maybe

   class TheLarch(deciduous) [KindsOfTrees]:
     ...

--
Greg

From greg.ewing at canterbury.ac.nz  Mon May  1 13:08:49 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 01 May 2006 23:08:49 +1200
Subject: [Python-3000] Add a standard GUI system
In-Reply-To: <20060428225107.6727.JCARLSON@uci.edu>
References: <20060428000801.671E.JCARLSON@uci.edu>
	<06Apr28.101121pdt.58641@synergy1.parc.xerox.com>
	<20060428225107.6727.JCARLSON@uci.edu>
Message-ID: <4455EC41.1020102@canterbury.ac.nz>

Josiah Carlson wrote:

> Ultimately, PyGUI is essentially a wrapper of native or near-native
> widgets into a common interface.  wxPython is exactly the same thing,

Are you sure? Last time I looked at wxWindows, it seemed more
like it re-implemented everything its own way.

I might be wrong, but if wxWindows is just a wrapper, why
is it so huge?

> only it has a much larger user base, developer support,

My goal for PyGUI is to make it simple enough that it
doesn't *need* a huge amount of developer support. I want
it to fit in my brain like the rest of Python. :-)

--
Greg

From ncoghlan at gmail.com  Mon May  1 13:10:32 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 01 May 2006 21:10:32 +1000
Subject: [Python-3000] Automatically invoking str() in str.join()
In-Reply-To: <9e804ac0605010341u68e77864u6d2f8b48848f725c@mail.gmail.com>
References: <4450C80D.50002@iinet.net.au>
	<e2qkki$79p$1@sea.gmane.org>	<e2ql0f$9ee$1@sea.gmane.org>	<9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com>	<e34iim$24o$1@sea.gmane.org>
	<9e804ac0605010341u68e77864u6d2f8b48848f725c@mail.gmail.com>
Message-ID: <4455ECA8.3000408@gmail.com>

Thomas Wouters wrote:
> It doesn't matter. Either case is confusing, one way or another, as Tim 
> has already argued. Changing it would be a big mistake. If you want me 
> to come with more comprehensive arguments (other than what Tim already 
> covered), please come with more comprehensive arguments *for* the 
> change, too.

What if the join() builtin had a similar signature to min() & max(), and the 
separator was a keyword only argument? Something like:

   def join(*args, **kwds):
       # Need a mutable seq to handle type conversions
       if len(args) == 1:
           seq = list(args[0])  # Single argument handled as iterator
       else:
           seq = list(args)     # Multiple arguments also accepted
       # Check for a custom separator (keyword argument only)
       sep = kwds.pop('sep', '')
       assert not kwds
       assert isinstance(sep, basestring)
       # Check if we want unicode or 8-bit strings
       sep_is_unicode = isinstance(sep, unicode)
       use_unicode = sep_is_unicode or any(isinstance(x, unicode) for x in seq)
       # Convert all items to desired type
       if use_unicode:
           desired = unicode
           if not sep_is_unicode:
               sep = unicode(sep)
       else:
           desired = str
       for i, item in enumerate(seq):
           if not isinstance(item, desired):
               seq[i] = desired(item)
       # Perform the join operation
       return sep.join(seq)

(as with min() and max(), a single argument which is a non-sequence doesn't 
make sense, as it would simply mean that join(x) == x).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From greg.ewing at canterbury.ac.nz  Mon May  1 13:10:45 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 01 May 2006 23:10:45 +1200
Subject: [Python-3000] Add a standard GUI system
In-Reply-To: <20060428000801.671E.JCARLSON@uci.edu>
References: <06Apr27.215050pdt.58641@synergy1.parc.xerox.com>
	<20060428000801.671E.JCARLSON@uci.edu>
Message-ID: <4455ECB5.6070303@canterbury.ac.nz>

Josiah Carlson wrote:

> Also, it would require shipping a Python GTK binding, which would
> basically necessitate shipping GTK+ with Python.

Keep in mind that PyGUI is still very much a work in progress.
My eventual goal is for each implementation to depend only on
what is provided natively by the platform. The use of the Gtk
implementation on Windows is only a stopgap measure until
something more native is available.

I'd like to see PyGUI or something like it become more widely
used and maybe even included in the core one day, but it
needs a lot more development first. Whether it will have
reached a sufficient level of development by the time Py3k
comes around remains to be seen.

> we may as well go whole hog and take wxPython;

I'd be disappointed if something like wxPython were chosen
as the next "official" Python gui, for a lot of reasons --
bloat, ugly and unpythonic API, non-native appearance and
behaviour, dubious quality of ports, etc.

> and it offers an "upgrade" path towards more "Pythonic"
> additions like Pythoncard, Wax, or even Dabo.

I'm also not fond of the idea of putting yet more layers of
code over something that's already too bloated.

--
Greg

From fredrik at pythonware.com  Mon May  1 13:18:07 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 1 May 2006 13:18:07 +0200
Subject: [Python-3000] Automatically invoking str() in str.join()
References: <4450C80D.50002@iinet.net.au><e2qkki$79p$1@sea.gmane.org>	<e2ql0f$9ee$1@sea.gmane.org>	<9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com>	<e34iim$24o$1@sea.gmane.org><9e804ac0605010341u68e77864u6d2f8b48848f725c@mail.gmail.com>
	<4455ECA8.3000408@gmail.com>
Message-ID: <e34qpg$p6o$1@sea.gmane.org>

Nick Coghlan wrote:

> What if the join() builtin had a similar signature to min() & max(), and the
> separator was a keyword only argument?

+0.5 (clever)

</F>




From walter at livinglogic.de  Mon May  1 13:20:07 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Mon, 01 May 2006 13:20:07 +0200
Subject: [Python-3000] Automatically invoking str() in str.join()
In-Reply-To: <4455ECA8.3000408@gmail.com>
References: <4450C80D.50002@iinet.net.au>	<e2qkki$79p$1@sea.gmane.org>	<e2ql0f$9ee$1@sea.gmane.org>	<9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com>	<e34iim$24o$1@sea.gmane.org>	<9e804ac0605010341u68e77864u6d2f8b48848f725c@mail.gmail.com>
	<4455ECA8.3000408@gmail.com>
Message-ID: <4455EEE7.3060506@livinglogic.de>

Nick Coghlan wrote:
> Thomas Wouters wrote:
>> It doesn't matter. Either case is confusing, one way or another, as Tim 
>> has already argued. Changing it would be a big mistake. If you want me 
>> to come with more comprehensive arguments (other than what Tim already 
>> covered), please come with more comprehensive arguments *for* the 
>> change, too.
> 
> What if the join() builtin had a similar signature to min() & max(), and the 
> separator was a keyword only argument? Something like:
> 
>    def join(*args, **kwds):

In many cases what I pass to join() is a generator expression. If the 
separator was a separate argument, I'd have to wrap the generator in (), 
which IMHO is uglier that the status quo:

",".join(word.upper() for word in words)

vs.

join((word.upper() or word in words), sep=",")

Servus,
    Walter


From solipsis at pitrou.net  Mon May  1 13:21:46 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 01 May 2006 13:21:46 +0200
Subject: [Python-3000] Automatically invoking str() in str.join()
In-Reply-To: <e34iim$24o$1@sea.gmane.org>
References: <4450C80D.50002@iinet.net.au> <e2qkki$79p$1@sea.gmane.org>
	<e2ql0f$9ee$1@sea.gmane.org>
	<9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com>
	<e34iim$24o$1@sea.gmane.org>
Message-ID: <1146482506.5679.3.camel@fsol>

Le lundi 01 mai 2006 ? 10:57 +0200, Fredrik Lundh a ?crit :
> Thomas Wouters wrote:
> 
> > > join()
> > >
> > > it's time to make this a builtin.  the "it's the separator that's doing
> > > the
> > > joining" idea is silly and unintuitive, and should be fixed.
> >
> >
> > I disagree, and I believe that would be a big mistake to change it.
> 
> big mistake?
> 
> can anyone point to one other example where "call method on
> literal" is used in Python ?

It seems it is being considered for string formatting ;-)




From greg.ewing at canterbury.ac.nz  Mon May  1 13:47:03 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 01 May 2006 23:47:03 +1200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06Apr30.125533pdt.58641@synergy1.parc.xerox.com>
References: <06Apr30.125533pdt.58641@synergy1.parc.xerox.com>
Message-ID: <4455F537.8010408@canterbury.ac.nz>

Bill Janssen wrote:

> 1)  I'd add some kind of standard analog value control class,

You're in luck - I've just almost-finished adding a Slider control.

> 2)  There needs to be some kind of combobox multiple-value choice
>     widget

Yes, there are several more controls like this that I would
like to add at some point, once I get the basic infrastructure
in place.

> 4)  The widget class hierarchy should probably be re-worked a bit to
>     use more abstract mix-in classes.  For instance, the PyGUI Container
>     class should probably be abstract (rather than inheriting from
>     Component). This would make it easier to implement new components
>     in pure Python.

Not sure I follow you here. Any pure-Python component is going to
be subclassed from either View or Frame, which are already Containers.
The only thing it would make easier is creating a Python component
that *wasn't* a Container, which is a somewhat purist thing to want
to do, since if you don't want to add subcomponents you're at
liberty not to do so. :-)

If you're thinking that you could take e.g. a Button, mix it
with Container and then add subcomponents to it, that wouldn't
work. It's a deliberate design decision that most of the
predefined components are *not* Containers, because adding
subwidgets to them is not easily supported on some platforms
without adding considerable overhead to all instances of them.

The current design was arrived at after a lot of experience spanning
about 5 different implementations. While it might be a bit cleaner
conceptually for Component to be a mixin, I'd be very reluctant to
reorganise the hierarchy at this stage without some very careful
thought.

> I think I see why the current implementation exists,
> because the toolkit dates from the pre-grand-type-unification days,

I don't think that has much to do with it; mixins worked just
as well with old-style classes as long as you kept them
orthogonal. It's just that the current hierarchy made sense
and expressed the constraints I wanted to impose.

> 5)  There should probably be a new class to permit rendering into a
>     PDF stream, for printing.

There will be some kind of support for printing at some stage.
Whether it will promise to produce PDF or not depends on what
sort of support there is for this across the target platforms.

> An editable styled-text widget would be interesting, instead of the
> simpler editable text widget that already exists.

Yes, that's another thing I have in mind. I need to find out
what's available on Windows before I get too carried away with
this, however.

> It would also be useful to have pure-Python implementations of all the
> widgets, to make porting it to a new platform dirt simple.

That's a possibility too, although it could be a lot of work,
especially for the more advanced things like rich text editing
and table/tree views.

> By the way, I would not include the OpenGL widgets currently in PyGUI
> into the standard GUI.  At least, not yet -- they are still clearly
> being experimented with.

As far as I'm concerned, the whole thing is still being experimented
with. I'm still making changes to the API now and then as I gain
experience with what works well and what doesn't. The OpenGL part
isn't really any less stable than the rest -- it just looks that
way. :-)

Thanks for your comments,
Greg


From solipsis at pitrou.net  Mon May  1 15:32:10 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 01 May 2006 15:32:10 +0200
Subject: [Python-3000] Add a standard GUI system
In-Reply-To: <4455EC41.1020102@canterbury.ac.nz>
References: <20060428000801.671E.JCARLSON@uci.edu>
	<06Apr28.101121pdt.58641@synergy1.parc.xerox.com>
	<20060428225107.6727.JCARLSON@uci.edu>
	<4455EC41.1020102@canterbury.ac.nz>
Message-ID: <1146490330.5679.13.camel@fsol>

Le lundi 01 mai 2006 ? 23:08 +1200, Greg Ewing a ?crit :
> Are you sure? Last time I looked at wxWindows, it seemed more
> like it re-implemented everything its own way.
> 
> I might be wrong, but if wxWindows is just a wrapper, why
> is it so huge?

I think it is huge because it has a lot of widgets (some of which are
indeed half-custom), it has a lot of functionalities, etc.

Not to mention that wxWidgets also includes a lot of non-GUI functions
which are already provided in the Python stdlib.

> > only it has a much larger user base, developer support,
> 
> My goal for PyGUI is to make it simple enough that it
> doesn't *need* a huge amount of developer support. I want
> it to fit in my brain like the rest of Python. :-)

The problem is that for a GUI system to be useful for many people, it
has to implement a lot of small details which are bound to add up and
form a huge package ;-)



From bcd240 at gmail.com  Mon May  1 15:52:47 2006
From: bcd240 at gmail.com (Michael Goral)
Date: Mon, 1 May 2006 15:52:47 +0200
Subject: [Python-3000] Automatically invoking str() in str.join()
Message-ID: <1e18d73c0605010652i45d18a33yd697421ec14377bb@mail.gmail.com>

> Thomas Wouters wrote:
> "I disagree, and I believe that would be a big mistake to change it."

seems to me that Thomas is right here ...

some remarks by a recent arrival at Python, my initial offset was
version 2.4.0: I think cleaning up things to ease newbie adaptation is
often misleading

I view the tree empty pairs of parenthesis, brackets and braces to
signify the three fundamental container types almost as a *trademark*
of Python: "look here, this is Python ...", and these pairs highlight
the most important focus of all things Python: "simple, yet powerful"
(okay, later on you will apply the related type functions more often,
every newbie will follow this path and turn to a non-newbie soon ...)

even the quirky need to sometimes replace () with (,) is *minor
trademark-ig*, as the meaning of () is kind of shallow compared to the
deep significance of [] and {}.

realising that 'a' + 'bb' + 'ccc' is bad yields the mental rule "do
apply the concatenation operator to pairs of strings only", which
brings us to the str-method 'join' and makes this method pretty
important:

tc = ('a', 'bb', 'ccc')
' <> '.join(tc)

ss = ' <> '
tcInner = tc
tcOuter = (ss[-2:], ss[:2])

ss.join(tcInner).join(tcOuter)
--> '> a <> bb <> ccc <'

a.join(b) is another idiom of *minor trademark-ig* quality

''.join(x) highlights (for a newbie) that any string in Python is an
object hosting methods, the beauty here is symmetry:
' <> '.join(tc)
--> 'a <> bb <> ccc'

and not 'a <> bb <> ccc <> ' or ' <> a <> bb <> ccc' - something to be
cleaned up afterwards most often

[ is /a/ in 'a.join(b)' a delimiter? generally speaking: no! ]

if this 'join' is a successful idiom (I do think so), then it is/would
be healthy, if there was no other idiom using 'join' - another point:
such a solitary 'join' easily builts up a rich specific meaning "und
das ist R?ckenwind"

last remark:
coming across the 'enumerate' function (as a newbie), this phrase was
not speaking to me, I could not guess what it's purpose might be ...
afterwards it turned into a powerful idiom that is (for me) not
disturned by the plain meaning of 'enumerate':

x, y in enumerate(z)

--Michael

From birchb at tpg.com.au  Mon May  1 16:27:01 2006
From: birchb at tpg.com.au (Bill Birch)
Date: Tue, 2 May 2006 00:27:01 +1000
Subject: [Python-3000] Unsure if I should write a PEP on Types
In-Reply-To: <ca471dc20604262043g79fc5ba4ub63e525c864bc88e@mail.gmail.com>
References: <200604250009.04347.birchb@tpg.com.au>
	<ca471dc20604262043g79fc5ba4ub63e525c864bc88e@mail.gmail.com>
Message-ID: <200605020027.01750.birchb@tpg.com.au>

On Thu, 27 Apr 2006 01:43 pm, Guido van Rossum wrote:
> Sorry for the belated response. Yes, I'd like to see this PEP. I'll
> probably eventually end up rewriting it :-), but right now I'm
> terribly overcommitted and really appreciate the help!!!
>

Rough draft is available for flames and comments here: 
http://billbirch.wordpress.com/


From guido at python.org  Mon May  1 16:36:43 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 1 May 2006 07:36:43 -0700
Subject: [Python-3000] Metaclass syntax?
In-Reply-To: <4455E9B5.3040006@canterbury.ac.nz>
References: <200605012050.08254.birchb@tpg.com.au>
	<4455E9B5.3040006@canterbury.ac.nz>
Message-ID: <ca471dc20605010736h38f51d1dqc9860a6b621c1767@mail.gmail.com>

On 5/1/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Bill Birch wrote:
>
> >    class[KindsOfTrees]  TheLarch(deciduous):
> >          pass
>
> I'd prefer not to put anything between 'class' and
> the name being defined. Maybe
>
>    class TheLarch(deciduous) [KindsOfTrees]:
>      ...

This has usually been solved by creating a non-meta class whose only
purpose is to introduce the new metaclass. You'd write

class TheLarch(KindsOfTrees, deciduous): ...

and the metaclass would be called KindsOfTreesMeta.

(Of course you could come up with a different naming convention.)

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

From guido at python.org  Mon May  1 16:56:14 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 1 May 2006 07:56:14 -0700
Subject: [Python-3000] Unicode identifiers (Was: sets in P3K?)
In-Reply-To: <44550467.20304@v.loewis.de>
References: <mailman.18397.1146112002.27774.python-3000@python.org>
	<445279F7.8080306@v.loewis.de>
	<ca471dc20604281344v615eaba7pd13613d60771c9a1@mail.gmail.com>
	<4452916F.1030304@v.loewis.de>
	<ca471dc20604281521g4172851fh9492c2b9b0691561@mail.gmail.com>
	<4452D871.9020901@v.loewis.de>
	<ca471dc20604290940l21e8206ai1aa7c08a5f92163d@mail.gmail.com>
	<4453FBFE.7060001@v.loewis.de>
	<ca471dc20604300928l7fc1d4b4o579911b9d382e965@mail.gmail.com>
	<44550467.20304@v.loewis.de>
Message-ID: <ca471dc20605010756q1dc54c25ufa17767409fc64ba@mail.gmail.com>

On 4/30/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Ok. I was only worried about your change in PEP 3099:
> "Python won't use Unicode characters for anything except string literals
> or comments."
> If that is only meant to say "this won't be introduced in Python 3",
> I'm fine with it.

Right.

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

From guido at python.org  Mon May  1 16:59:05 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 1 May 2006 07:59:05 -0700
Subject: [Python-3000] in-out parameters
In-Reply-To: <20060430005356.3DA9B8B34E@xprdmxin.myway.com>
References: <20060430005356.3DA9B8B34E@xprdmxin.myway.com>
Message-ID: <ca471dc20605010759x586704b9i57a6b8305651703c@mail.gmail.com>

On 4/29/06, Rudy Rudolph <rudyrudolph at excite.com> wrote:
> One thing that has always bothered me about Python is the lack of in-out
> parameters. Python is such a wonderful object-oriented language, but it lacks
> this feature that nearly every language has. Maybe we can fix this in 3.0.

When I first saw this I thought "you must be joking". What's OO about
in-out parameters? I believe the feature was invented for Fortran.
(Does Java have them? I can't recall ever using them there.)

For the record, a strong -1 on this. You all are wasting your time.

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

From janssen at parc.com  Mon May  1 17:44:48 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 08:44:48 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Sun, 30 Apr 2006 17:56:20 PDT."
	<44555CB4.1030606@gmail.com> 
Message-ID: <06May1.084454pdt."58641"@synergy1.parc.xerox.com>

> So you're really aiming at incorporating a gui-api for Python, so that it can 
> be pointed at the backend of choice? Something similar to what the DB-api 
> achieves for databases?

Yes, that's essentially what PyGUI already is.  It doesn't attempt to
model directly any specific existing toolkit, but rather to define an
abstraction which can be realized with most existing toolkits.

See the home page at http://www.cosc.canterbury.ac.nz/~greg/python_gui/, and

http://www.cosc.canterbury.ac.nz/~greg/python_gui/version/Doc/index.html has

a description of the abstract API.

What I think we should do for Py3K is a bit more extensive.  I think
we should try to make sure than any Python distribution includes PyGUI
plus one or more bindings appropriate for that distribution.  For
example, a Linux RPM might include the bindings for GTK+ and wxWidgets
(presuming it's ported to wxWidgets), the Jython distribution would
include the bindings for Swing, the Mac OS X distribution would
include the bindings for Cocoa, etc.  The source distribution would
include the binding code for all the bindings, but of course autoconf
would figure out which of those to build.

Let's get "batteries included" working on the GUI front.

> That certainly seems like a laudable goal. Advanced usage might still need to 
> dig into the underlying GUI framework directly, but a common front-end could 
> cover the needs of basic apps.

That's the general idea.  Things like PyGTK and wxPython will always
exist, and some people may need them, but the PyGUI basic framework
should suffice for most uses.  I think, with a good graphics subsystem
(the Canvas widget), you can really do quite a bit.

Bill
------------------------------------------
 Bill Janssen  <janssen at parc.com>     (650) 812-4763    FAX: (650) 812-4258
 PARC -- User Interface Research Area          http://www.parc.com/janssen/

From janssen at parc.com  Mon May  1 17:51:27 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 08:51:27 PDT
Subject: [Python-3000] Add a standard GUI system
In-Reply-To: Your message of "Sun, 30 Apr 2006 19:42:35 PDT."
	<013f01c66cc8$e786ada0$0300a8c0@HPPAVILION> 
Message-ID: <06May1.085129pdt."58641"@synergy1.parc.xerox.com>

> "Bill Janssen" <janssen at parc.com> wrote
> 
> a reply to my objection to his GUI proposal  --
> that makes the proposal more sensible to me.
> 
> I see you putting forth four propositions.  My wording of them is:
> 
> 1. Python 3 should (still) have a standard lib GUI system.
> 
> 2a. TK/Tkinter should not be grandfathered in.
> 2b. Current popularity should not be the determining factor.
> 
> 3. The GUI chosen should be Pythonic, rather than a direct translation of, 
> for instance, Jave or C++ style.
> 
> 4. An updated and revised version of PyGUI looks like the best choice.

Terry, thanks for helping put this more clearly.

> I currently agree with 1, 2a, maybe 2b, 3 to the extent I know the 
> difference (but would like to see specific examples), and am neutral to 4 
> due to ignorance.  I could imagine someone agreeing with 1-3 but proposing, 
> say, Wax instead.  So that should be the most controversial.

I'm fairly enthusiastic about PyGUI for this purpose, but I'll happily
throw it out in favor of a better candidate.  The goal is to get a
good standard GUI system included with Python.

> One thing I do know about wxWidgets is that it includes a library of utility 
> functions that are not directly gui functions and that duplicate functions 
> already in Python.  While it is sensible for wxPython to wrap these, it 
> would be duplicative to add them to the standard lib.

Sure.  I see wxPython and the others as potential implementation
platforms for PyGUI, rather than as competitors.  We might have
bindings for PyGUI for each of them.

Bill

From janssen at parc.com  Mon May  1 17:55:48 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 08:55:48 PDT
Subject: [Python-3000] Add a standard GUI system
In-Reply-To: Your message of "Mon, 01 May 2006 04:10:45 PDT."
	<4455ECB5.6070303@canterbury.ac.nz> 
Message-ID: <06May1.085554pdt."58641"@synergy1.parc.xerox.com>

Greg Ewing writes:
> I'd like to see PyGUI or something like it become more widely
> used and maybe even included in the core one day, but it
> needs a lot more development first. Whether it will have
> reached a sufficient level of development by the time Py3k
> comes around remains to be seen.

I think Greg's being too modest here.  It looks to me as if it's a
couple months out from being a fairly polished system.  At least the
core of it; I agree that some classes (the OpenGL, for instance)
should remain experimental for a bit longer.

Bill

From janssen at parc.com  Mon May  1 17:59:34 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 08:59:34 PDT
Subject: [Python-3000] Add a standard GUI system
In-Reply-To: Your message of "Mon, 01 May 2006 06:32:10 PDT."
	<1146490330.5679.13.camel@fsol> 
Message-ID: <06May1.085939pdt."58641"@synergy1.parc.xerox.com>

> Not to mention that wxWidgets also includes a lot of non-GUI functions
> which are already provided in the Python stdlib.

This is a standard thing for toolkits designed for so-called base
languages (C, C++, Objective-C).  That's one of the reasons they don't
really fit into higher-level languages without looking kind of odd.

Bill

From mcherm at mcherm.com  Mon May  1 18:08:13 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Mon, 01 May 2006 09:08:13 -0700
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
Message-ID: <20060501090813.8y05zi9jhpq88kw4@login.werra.lunarpages.com>

> [Bill Janssen proposes we use Greg Ewing's PyGUI as the standard GUI
> framework in Py3K.]

I really like PyGUI. I have dabbled in a number of different GUI frameworks
over the years, and PyGUI is the only one where upon reading the
documentation I immediately thought "that's Pythonic!". (It's usually more
like "My GOD that's inelegant!".)

But PyGUI is not complete. (Greg is one of the people who says this.) And
I belive that it is just not ready to be the "blessed" Python GUI framework.
Perhaps after a few years more work it will be... and then I would favor
including it. But not now. By way of illustration, the GUI task I am working
on at the moment is a tree-view in which individual items and entire branches
can be selected by clicking checkboxes -- a challenge to most any framework
I know of. It's not that PyGUI's tree-view component isn't flexible enough,
PyGUI doesn't even *have* a tree view component. Me, I nearly always use
wxPython (which is TERRIBLE to use, but it usually does what I need).

Besides, including PyGUI doesn't need to be part of Py3K because it doesn't
break backward compatibility -- it can be added (if desired) whenever PyGUI
is deemed ready. What needs to be decided for Py3K is whether to DROP
support for TK. I am actually mildly in favor of dropping TK support in
the core if we can make it easy enough to download and install separately.

-- Michael Chermside


From ronaldoussoren at mac.com  Mon May  1 18:32:32 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 1 May 2006 09:32:32 -0700
Subject: [Python-3000] Add a standard GUI system
In-Reply-To: <4455ECB5.6070303@canterbury.ac.nz>
References: <06Apr27.215050pdt.58641@synergy1.parc.xerox.com>
	<20060428000801.671E.JCARLSON@uci.edu>
	<4455ECB5.6070303@canterbury.ac.nz>
Message-ID: <BCF4006F-00F2-478C-896C-95403A2EFD7D@mac.com>


On 1-mei-2006, at 4:10, Greg Ewing wrote:

>
>
>> we may as well go whole hog and take wxPython;
>
> I'd be disappointed if something like wxPython were chosen
> as the next "official" Python gui, for a lot of reasons --
> bloat, ugly and unpythonic API, non-native appearance and
> behaviour, dubious quality of ports, etc.

I agree. It's an absolute pain to build a wxPython application that  
looks exactly right on several platforms (specifically Windows and  
MacOS). IIRC several widgets also behave noticeably different on  
MacOS and windows, although the details escape me at the moment.

I haven't seriously looked at PyGUI yet, but if tkinter were replaced  
I'd prefer a simple pythonic interface and that is what PyGUI claims  
to be.

Ronald


From janssen at parc.com  Mon May  1 18:59:20 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 09:59:20 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Mon, 01 May 2006 09:08:13 PDT."
	<20060501090813.8y05zi9jhpq88kw4@login.werra.lunarpages.com> 
Message-ID: <06May1.095920pdt."58641"@synergy1.parc.xerox.com>

> But PyGUI is not complete. (Greg is one of the people who says this.) And
> I belive that it is just not ready to be the "blessed" Python GUI framework.

I'm suggesting a concerted effort to *make* it complete over the rest
of this year.  Or, if that's for some reason not possible, to pick
some other framework and bless *that*.  I just think PyGUI is the best
available candidate right now.

> Perhaps after a few years more work it will be...

That will be too late to PyGUI to be the standard GUI.  If Py3K is
about getting Python "right", missing the boat on a standard GUI again
is not part of that plan.  If PyGUI isn't in Py3K, something else has
to be.

> By way of illustration, the GUI task I am working
> on at the moment is a tree-view in which individual items and entire branches
> can be selected by clicking checkboxes -- a challenge to most any framework
> I know of. It's not that PyGUI's tree-view component isn't flexible enough,
> PyGUI doesn't even *have* a tree view component.

Interesting.  I never seem to use tree-views, but I do use graph
views.  I think the standard Python GUI should make it easy to build
these kinds of things.  Right now a graph view is fairly easy to build
on top of a raw View.

> Me, I nearly always use
> wxPython (which is TERRIBLE to use, but it usually does what I need).

Even worse for me -- I nearly always use Swing :-).

> What needs to be decided for Py3K is whether to DROP
> support for TK. I am actually mildly in favor of dropping TK support in
> the core if we can make it easy enough to download and install separately.

I can't imagine that we wouldn't drop Tk.

Bill

From rhettinger at ewtllc.com  Mon May  1 18:59:59 2006
From: rhettinger at ewtllc.com (Raymond Hettinger)
Date: Mon, 01 May 2006 09:59:59 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <e336a8$spg$1@sea.gmane.org>
References: <mailman.18736.1146255866.27774.python-3000@python.org>	<Pine.GSO.4.58.0604301605170.18138@qew.cs>
	<e336a8$spg$1@sea.gmane.org>
Message-ID: <44563E8F.8050001@ewtllc.com>


>>>set() == set{}
>>>set(x)              # No braced equivalent
>>>set([x]) == set{x}  # Ignoring list comprehensions
>>>set((x,)) == set{x}
>>>set((a, b, c)) == set{a, b, c}
>>>      
>>>
>>I would rather stick to what we have than introduce two notations for
>>construction, call, subscripting, etc. --- Perl's [] vs. {} *always*
>>causes headaches for newcomers.
>>    
>>
>
>And last time I looked they were gonna change it for Perl 6.
>
>  
>

Nick's syntax proposal represents some creative and original thinking on 
the problem; however, I think all such proposals face a somewhat 
difficult hurdle -- a change has to be weighed against the almost 
microscopically small benefit provided by set literals.  Accordingly, we 
should reject any set literal proposal that results in complexifying the 
grammar.  While I would like to see some way of writing set literals, it 
certainly isn't worth the dizzying effect produced by the examples shown 
above.

IOW, I recommend saving your big guns (alternative constructor syntaxes) 
for big problems whose solutions provide big rewards.   Set literals are 
barely worth the brain power that has already been expended in this 
thread.  If a set literal proposal isn't dirt simple, it is almost 
certainly a mistake.


Raymond



From fredrik at pythonware.com  Mon May  1 19:11:42 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 1 May 2006 19:11:42 +0200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
References: <20060501090813.8y05zi9jhpq88kw4@login.werra.lunarpages.com>
	<06May1.095920pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <e35fgf$v7h$1@sea.gmane.org>

Bill Janssen wrote:

> > But PyGUI is not complete. (Greg is one of the people who says this.) And
> > I belive that it is just not ready to be the "blessed" Python GUI framework.
>
> I'm suggesting a concerted effort to *make* it complete over the rest
> of this year.  Or, if that's for some reason not possible, to pick
> some other framework and bless *that*.  I just think PyGUI is the best
> available candidate right now.

since this is the Py3K list, why hurry ?

I don't think PyGUI is good enough for a standard API; it feels way too
much "MFC era" for my tastes.

(for the record, I'd prefer a conceptual mix of HTML, PyGUI, WinForms,
and WCK, plus Tkinter's binding model and Canvas.  more about this some
other day.)

</F>




From solipsis at pitrou.net  Mon May  1 19:30:52 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 01 May 2006 19:30:52 +0200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06May1.095920pdt."58641"@synergy1.parc.xerox.com>
References: <06May1.095920pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <1146504652.5679.26.camel@fsol>

Le lundi 01 mai 2006 ? 09:59 -0700, Bill Janssen a ?crit :
> Interesting.  I never seem to use tree-views, but I do use graph
> views.  I think the standard Python GUI should make it easy to build
> these kinds of things.  Right now a graph view is fairly easy to build
> on top of a raw View.

As far as I've seen by trying the demos and taking a quick glance at the
source, PyGUI also lacks (from the top of my head):
- list and combo boxes
- list controls
- icons in menus
- menu hotkeys (e.g. Alt+F to open File menu)
- toolbars (very important)
- status bars
- i18n support especially for built-in texts (like "New", "Open",
"Save", "Ok", "Cancel"...)
- stock icons in accordance with the desktop (e.g. stock Gnome icons),
including fallback in case the desktop doesn't provide them
- stock buttons (ok / close / cancel / etc.)
- ...

Not to mention other wishes like bounded (smart) resizing.

If making PyGUI into the stdlib is important, a wiki or something could
be opened to list the various issues people have with PyGUI.




From jimjjewett at gmail.com  Mon May  1 19:32:16 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 1 May 2006 13:32:16 -0400
Subject: [Python-3000] Unicode identifiers (Was: sets in P3K?)
In-Reply-To: <e2vonm$4gr$3@sea.gmane.org>
References: <mailman.18397.1146112002.27774.python-3000@python.org>
	<e2r8b2$ni7$1@sea.gmane.org> <e2rhi5$q8e$1@sea.gmane.org>
	<17489.31069.526965.186604@montanaro.dyndns.org>
	<4451AF74.8040702@gmx.net>
	<ca471dc20604280732j4c12c5cbxf50a4c012fa1e7f1@mail.gmail.com>
	<445279F7.8080306@v.loewis.de>
	<ca471dc20604281344v615eaba7pd13613d60771c9a1@mail.gmail.com>
	<4452916F.1030304@v.loewis.de> <e2vonm$4gr$3@sea.gmane.org>
Message-ID: <fb6fbf560605011032v4f1760a8qd962270c8afc8685@mail.gmail.com>

Martin v. L?wis wrote:

> It depends on the language you use to communicate. In English,
> it is certainly cumbersome to talk about Chinese identifiers.
> OTOH, I believe it is cumbersome to communicate about English
> identifiers in Chinese, either, because the speakers might
> not even know what the natural-language concept behind the
> identifiers is, and because they can't pronounce the identifier.

In theory, a pre-processor or display hook could automatically
translate between the localized names and the "standard" names, even
for keywords.  It would lead to "standard names" like T8asR34k, but it
would work.

Ensuring that it is easy to hook the imports and the editor is
probably useful, and at least part of it can be done in 2.0.  Anything
more than that may be premature.

-jJ

From guido at python.org  Mon May  1 19:35:53 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 1 May 2006 10:35:53 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <44563E8F.8050001@ewtllc.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<Pine.GSO.4.58.0604301605170.18138@qew.cs>
	<e336a8$spg$1@sea.gmane.org> <44563E8F.8050001@ewtllc.com>
Message-ID: <ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>

On 5/1/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> IOW, I recommend saving your big guns (alternative constructor syntaxes)
> for big problems whose solutions provide big rewards.   Set literals are
> barely worth the brain power that has already been expended in this
> thread.  If a set literal proposal isn't dirt simple, it is almost
> certainly a mistake.

Right. I see two proposals worthy of pursueing:

(a) {testlist} and {genexp} with the empty set written as set().

(b) Ditto but the empty set written as {/} or some other syntax that
doesn't already have a meaning.

Proposals that require us to change the way we write dict literals, or
that try to make {} ambiguously denote both an empty set and an empty
dict are off the table.

Since attempts to find an acceptable empty set notation for (b) seem
stalled on the acceptance of *anything*, I propose to go with (a) for
now -- it's simple to explain, similar to what people use on paper and
in textbooks, simple to implement, and syntactically unambiguous. The
minor notational discontinuity for empty sets is nothing compared to
the one we already have for singleton tuples. Plus, we can always
decide to approve {/} later -- which would still be a syntactic
discontinuity altough a much smaller one.

As Raymond says, upheaval of other notations isn't worth the minor
convenience that set literals provide.

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

From phd at mail2.phd.pp.ru  Mon May  1 19:41:39 2006
From: phd at mail2.phd.pp.ru (Oleg Broytmann)
Date: Mon, 1 May 2006 21:41:39 +0400
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <1146504652.5679.26.camel@fsol>
References: <06May1.095920pdt."58641"@synergy1.parc.xerox.com>
	<1146504652.5679.26.camel@fsol>
Message-ID: <20060501174139.GA27528@phd.pp.ru>

On Mon, May 01, 2006 at 07:30:52PM +0200, Antoine Pitrou wrote:
> As far as I've seen by trying the demos and taking a quick glance at the
> source, PyGUI also lacks (from the top of my head):
> - list and combo boxes
> - list controls
> - icons in menus
> - menu hotkeys (e.g. Alt+F to open File menu)
> - toolbars (very important)
> - status bars
> - i18n support especially for built-in texts (like "New", "Open",
> "Save", "Ok", "Cancel"...)
> - stock icons in accordance with the desktop (e.g. stock Gnome icons),
> including fallback in case the desktop doesn't provide them
> - stock buttons (ok / close / cancel / etc.)

   Does it support printing? wxPython/wxWidgets support cross-platform
low-level (pixel by pixel) printing, preview with zoom...

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From alexander.belopolsky at gmail.com  Mon May  1 19:47:22 2006
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 1 May 2006 17:47:22 +0000 (UTC)
Subject: [Python-3000] Future of slices
References: <49841143-4F65-40DF-9324-8587712F45D3@local>
	<4455CF82.9070607@gmail.com>
Message-ID: <loom.20060501T175626-112@post.gmane.org>

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> 
> Short version: +1 for the first point (but for different reasons), -1 for the 
> rest. Use cases for advanced slicing operations are not provided by the 
> standard library, but by Numpy's sophisticated data manipulation capabilities.
> 
I am glad you mentioned Numpy, because my post was mostly motivated by my Numpy
experiences. Numpy's integration into the standard Python library was on the
table for many years (PEP-209), but for reasons that I don't completely
understand that proposal was never accepted.  As I  said, I don't know the real
reasons for rejection, but in my view the problem with adding numpy to the
standard library is that in many aspects numpy is not a package, but a different
language (now complete with its own scalars and arithmetic rules that make
1/0 = 0!).  Numpy is a perfect language for scientific computing, borrowing more
from APL than from python, but I would rather see Py3K providing ways to
implement scientific libraries without becoming an APL-like language.

> Alexander Belopolsky wrote:
> <get rid of ...>> 1. l[:] syntax for shallow copy.
> 
> I kind of agree with this one, mainly because I'd like standard library data 
> types to return views for slicing operations. Making a copy based on a view is 
> as easy as wrapping the view in a call to the appropriate constructor. 
> Avoiding the memory impact of multiple slicing operations that copy data 
> around is much harder.
> 
> Returning views rather than copies would also eliminate some of the use cases 
> for islice().
> 

I understand that Numpy's implementation of views was not acceptable because
Python lists often relocate their storage.  Maybe Py3K views will provide the
way to solve that problem.


> > 2. Overloading of [] syntax. The primary meaning of c[i] is: get the  
> > i-th item from the collection. This meaning is consistent between  
> > lists/tuples and dicts.  The only difference is that  i may not be an  
> > integer in the case of dict.
> 
> The c[x] syntax isn't really overloaded - it always means "ask the container c 
> for the item corresponding to subscript x"
> 

I disagree. If type(x) is slice, then in c[x] notation (1) x is not a
subscript and (2) the value of c[x] is not an item.

(1) Depending on what you mean by "subscript," your statement is either a
tautology or is incorrect.  If subscript == whatever appears between square
brackets, than x is a subscript by definition, but in my view subscript is
a typographical term referring in the present context to the tradition of
denoting vector components by adding a subscript to the name of the vector.
I am not familiar with any scientific notation for slices.

(2) c[x] is not an item:

>>> c = range(10)
>>> x = slice(3,6)
>>> c[x] in c
False

This is another case where strings differ from other containers:

>>> c = 'abcbdefghij'
>>> c[x] in c
True

> For a dict, x must be hashable, but otherwise both x and the item returned are 
> unconstrained. Other mappings may remove the requirement for hashability.
> 
Yes, and Numpy is the prime example. However, in my view Numpy takes []
overloading a little bit too far. I Numpy c[x] can have the following meanings
(the list is probably incomplete):

1. Traditional subscripting. Multidimentional arrays are indexed by tuples. c[x]
is a scalar.

2.  Projection. Happens when len(x) < rank(c) or if ellipsis is present (to 
allow obtaining rank-0 arrays).  If you view multidimensional arrays as
functions (think of "()" replacing "[]"), then projection is  similar top
functional.partial. c[x] is an array view of rank <= rank(c).

3. Slicing. Nominally rank-preserving, by can be combined with projection in
the same expression. c[x] is an array view of rank = rank(c).

4. Special kind of reshape.  As in c[newaxis]. c[x] is an array view of
rank > rank(c).

5. Selection. AKA "fancy indexing": c[x] is a copy.

I probably missed a few, but you get the picture.  All that functionality could
be implemented without asking python to add new syntax.  Slicing can be a
function or a method.  Tuple-based indexing did not require any additional
syntax, but it could easily be implemented by overloading __call__ instead of
__getitem__ with an additional benefit of a natural way to support named
dimensions.  


> Sequences use the rule that x must be either an integer (object with an 
> __index__ method), or a slice object. The key characteristic that 
> distinguishes a sequence from a general mapping is that c[0:0] == type(c)().
> 

... and c[x] in c may be False.


> Multi-dimensional arrays then loosen the restrictions on x imposed by 
> sequences slightly to also permit tuples. The key characteristic to 
> distinguish Numpy-style arrays from other sequences is that c[0:0] == c[0:0,].
> 
As I explained above that loosening was not entirely necessary.  Numpy could
easily use "()" syntax for that and make itself more familiar to Fortran and
C++ programmers.

> These behaviours aren't fundamental rules of programming that need to be 
> embedded in the underlying language implementation. The kinds of subscript 
> that makes sense may vary from container to container. Python's current 
> approach avoids embedding particular interpretations in the language allowing 
> each data structure designer to make their own decisions (hopefully guided by 
> the conventions used for existing data structures).
> 

That's true, but using similar notation to perform different operations
depending on the type of the operands often leads to confusion, particularly 
when operands are otherwise similar.  This type of confusion is real: I've seen
a bug report for Numeric filed by a user who realized that he cannot resize an
array using slice assignment. 

> >   Slicing is specific  to lists, tuples  
> > and strings (I am ignoring non-built-in types for now).
> 
> Ignoring external types when discussing slicing is a mistake. Much of Python's 
> slicing design was driven by the Numpy folks, rather than the needs of the 
> standard library.
> 

Isn't it a sign of a weakness in the language design when an external library
dictates changes to the syntax?  Recognizing ':' and '...' only inside '[]' 
feels a little odd.  There are probably some parsing issues with making a:b
a shortcut for range(a,b) and allow it anywhere, but I don't see a problem
with making ... a keyword. (Parsing problems with ':' could be solved by 
spelling it '..' or 'to', but I know that's not going to happen:-). 

> > 3.  Overloading of []= syntax. Similarly to #2, this is the case when  
> > the same notation is used to do conceptually different operations.   
> > In addition it provides alternative ways to do the same thing (e.g. l  
> > += a vs. l[len(l):] = a).
> 
> The OOW in TOOWTDI stands for "One Obvious Way" not "Only One Way" :)
> 
> As Josiah said, for manipulating data structures, that obvious way is 
> typically the appropriate methods of the collection being used.
> 

I probably made a wrong example. My main gripe about slice assignment is that
it gives a feel of slice being a view when it is not.

> > 4. Extended slicing.  I believe the most common use case l[::-1] was  
> > eliminated with the introduction of "reversed".  The remaining  
> > functionality in case of a tuple c can be expressed as tuple(c[i] for  
> > i in range(start,stop, stride)).  The later is more verbose than c 
> > [start:stop:stride], but also more flexible.
> 
> Extended slicing was added to provide syntactic support for various operations 
> on Numpy's multi-dimensional arrays. As I understand it, the later addition of 
> support to the types in the standard library was more due to consistency 
> reasons than really compelling uses cases.

In Numpy the need for extended slicing is often a sign of an inapropriate choice
of dimension.  For example if you often use ::2 slices of 1-d arrays, you can
probably represent your data by an Nx2 matrix and refer to columns instead of
::2 slices.  However, I am not against the functionality, I am only against
the syntax.  I would prefer writing c.slice(0, 10, by=2) instead of c[0:10:2].

-- sasha 




From janssen at parc.com  Mon May  1 20:27:17 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 11:27:17 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Mon, 01 May 2006 10:30:52 PDT."
	<1146504652.5679.26.camel@fsol> 
Message-ID: <06May1.112726pdt."58641"@synergy1.parc.xerox.com>

> If making PyGUI into the stdlib is important, a wiki or something could
> be opened to list the various issues people have with PyGUI.

Great idea.

Bill

From janssen at parc.com  Mon May  1 20:44:00 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 11:44:00 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Mon, 01 May 2006 10:30:52 PDT."
	<1146504652.5679.26.camel@fsol> 
Message-ID: <06May1.114401pdt."58641"@synergy1.parc.xerox.com>

Antoine, thanks for looking more closely at this.

> PyGUI also lacks (from the top of my head):
> - list and combo boxes

Yes, in my message yesterday I noted that.  I think only
drop-down/pop-up menu support is really necessary for this, and
there's already a menu class that could be mildly altered.

> - list controls

Not sure what you mean here.

> - icons in menus

Not sure this is necessary.

> - menu hotkeys (e.g. Alt+F to open File menu)

Menus already support "keyboard equivalents".
http://www.cosc.canterbury.ac.nz/~greg/python_gui/version/Doc/Menu.html

> - toolbars (very important)

I don't see the need, but they could be added.

> - status bars

Why isn't that a label?
http://www.cosc.canterbury.ac.nz/~greg/python_gui/version/Doc/Label.html

You must mean something other than what I'm thinking.  Are you referring
to an animated progress bar, perhaps?

> - i18n support especially for built-in texts (like "New", "Open",
>   "Save", "Ok", "Cancel"...)

I suggest that this is a larger problem than just the GUI.  I suggest
we just use whatever is put together for Python in general.  It would
be useful to list the places where this would have to be done (labels,
menu items, etc.).  I think that there are only a few such places in
the GUI toolkit proper.

> - stock icons in accordance with the desktop (e.g. stock Gnome icons),
> including fallback in case the desktop doesn't provide them

I think of this as creeping featurism, but I could see it.  My general
feeling on this is that if you want stock icons, use stock widgets.

> - stock buttons (ok / close / cancel / etc.)

Again, the stock widgets should provide these. And do:
http://www.cosc.canterbury.ac.nz/~greg/python_gui/version/Doc/Dialog.html.

> Not to mention other wishes like bounded (smart) resizing.

Not completely sure what this means?  Have you read the documentation
for Container?
http://www.cosc.canterbury.ac.nz/~greg/python_gui/version/Doc/Container.html

I see that when I use "sticky" appropriately, the few small test cases
I've tried seem to resize the way I think they should.

Bill

From janssen at parc.com  Mon May  1 20:58:19 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 11:58:19 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Mon, 01 May 2006 10:41:39 PDT."
	<20060501174139.GA27528@phd.pp.ru> 
Message-ID: <06May1.115826pdt."58641"@synergy1.parc.xerox.com>

>    Does it support printing? wxPython/wxWidgets support cross-platform
> low-level (pixel by pixel) printing, preview with zoom...

It's currently got the low-level idea of an offscreen Pixmap into
which the app can draw by calling "with_canvas".  The Pixmap captures
an image of the drawing, and you can then use it to draw on other
surfaces.  I think one way to go would be to add PDFCanvas (a subclass
of Canvas which draws into a PDF stream), and then PDF, which would be
similar to Pixmap, in that it would have a "with_canvas" method which
would capture the drawing in PDF form.  The PDF class would also have
a method to save it to a file.

Actually, creating these two classes could be done right now; they're
independent of the platform.  Or I suppose you could do Print and
PrintCanvas classes, which would be bound to platform-specific
printing streams.  But that seems overkill to me.

Or Postscript, or SVG.  Whatever's good.  SVG would be an interesting
choice.

Hmmm, lots of ideas here...

Bill

From alexander.belopolsky at gmail.com  Mon May  1 21:14:22 2006
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 1 May 2006 15:14:22 -0400
Subject: [Python-3000] Future of slices
In-Reply-To: <20060501011031.674D.JCARLSON@uci.edu>
References: <49841143-4F65-40DF-9324-8587712F45D3@local>
	<20060501011031.674D.JCARLSON@uci.edu>
Message-ID: <d38f5330605011214keefc4b2oa6997a2514a135ef@mail.gmail.com>

On 5/1/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> If you want to get my general opinion; -1 on all of your recommendations.
> In each part, I describe why.
>
> Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> > 1. l[:] syntax for shallow copy.
>
> Note that [:] doesn't necessarily copy.

I know. It does not in numpy. However, I understand that the ability
to do l[:] when l is
a list justified not having list.copy method.  The fact that l[:] is
not  necessarily a copy
makes it even less attractive way to express copy(l).

>  It certainly is the case for
> Python lists, strings, tuples, and unicode today, but given standard
> slicing of l[i:j] producing a copy of a section of a list/string/tuple
> from i...j, removing the first is equivalent to 'the start', and
> removing the second being equivalent to 'the end'; having l[:] do
> something other than slicing the entire sequence (at least for
> list/string/tuple) seems pretty unintuitive.
>

I did not propose l[:] doing anything different.  I was actually very
shy proposing anything, but if I must, the proposal  would be:

1. Replace l[start:stop:step] with l.slice(start, stop, by=step)
2. Replace l[start:stop:step] = x with l.setslice(x, start, stop, by=step)


> >
> > 2. Overloading of [] syntax. The primary meaning of c[i] is: get the
> > i-th item from the collection.
> [snip]
> > The main problem with [] overloading is that c[i] is not
> > guaranteed to be "smaller" than c.
>
> How is this related at all to anything?
>

This has to do with an expectation that c[i][j]... should eventually
throw an exception unless
you managed to create a circular list.  I put "smaller" in quote marks
because [0,1] being smaller than  [[0,1]] is subjective (one might say
it's the other way around because len([0,1]) > len([[0,1]])). What I
wanted to say is that the traditional meaning of subscripting
is to obtain an item from a container and not a container with
possibly fewer items.


> > This problem is even worse for strings, where c[i] is
> > *always* a slice: c[i] is the same as c[i:i+1].
>
> No.
>     >>> ''[0]
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     IndexError: string index out of range
>     >>> ''[0:1]
>     ''
>
I did not realize that.  I would not call this behavior obvious.
Particularly given

>>> ''[10:11]
''


> > maybe we can reconsider compiling l[a:b:c] into
> > l.__getitem__(slice(a,b,c)) and go back to __getslice__.
>
> You can still use __getslice__ if you want (I believe it is deprecated,
> but I don't know when it will be removed)...

I assumed that deprecated features will be gone in Py3K.


[snip]

> Which would you rather do:
>     b = a[i:j]
> or
>     b = str(a[k] for i in xrange(i,j))
>
> Obviously the first.  People who use extended slicing feel the same way,
> as they can add a :X and have precisely what they want.

I would rather do substr(a, i, j).  In the presence of variable
character width encodings
(think UTF-8) substr may even need an encoding argument to operate
properly unless
encoding becomes a property of the string.  As far as strings go, I
would rather see them
non-iterable, non-subscriptable with a large library of methods and
functions.  I understand
that someone else have already lost this battle for me though.

-- sasha

From solipsis at pitrou.net  Mon May  1 21:37:01 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 01 May 2006 21:37:01 +0200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06May1.114401pdt."58641"@synergy1.parc.xerox.com>
References: <06May1.114401pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <1146512221.5679.55.camel@fsol>

Le lundi 01 mai 2006 ? 11:44 -0700, Bill Janssen a ?crit :
> > - list controls
> 
> Not sure what you mean here.

A control which displays and allows to interact with several lines of
widgets (e.g. labels, images...).
For example a buddy list in an Instant Messaging client.

> > - menu hotkeys (e.g. Alt+F to open File menu)
> 
> Menus already support "keyboard equivalents".
> http://www.cosc.canterbury.ac.nz/~greg/python_gui/version/Doc/Menu.html

Yes but it is not the same.
"keyboard equivalents" are global key shorcuts. You cannot assign a
global key shortcut to every command, while you can assign a local
hotkey to any menu item. It is critical for accessibility: people must
be able to navigate menus entirely with the keyboard.
(it can be practical for advanced users too ;-))

The traditional API for this is to use an ampersand in the command
label: "&File" means the "File" menu can be accessed with Alt+F, and
"&Save" means that, when in the "File" menu, you can access the "Save"
command by hitting S.
(as a side-effect, this makes local hotkeys i18n-dependent: the French
version of "&Save" is often "&Enregistrer").

> > - status bars
> 
> Why isn't that a label?
> http://www.cosc.canterbury.ac.nz/~greg/python_gui/version/Doc/Label.html
> 
> You must mean something other than what I'm thinking.  Are you referring
> to an animated progress bar, perhaps?

Well, a status bar is a container which can contain many things and sits
at the bottom of the window. It may have support for a resizing handle
too.
Think about your Web browser: at the bottom, a text label for the
current URL (or "loading", whatever), a progress bar for when something
is being fetched over the network, an togglable indicator of
on-line/off-line status, and a clickable lock icon to view the security
dialog.

It can probably be implemented using a Container, though. 


> I see that when I use "sticky" appropriately, the few small test cases
> I've tried seem to resize the way I think they should.

In wxWidgets, the GUI system is able to calculate the minimal size
needed by each and any widget, and to prevent the user from resizing the
window below the calculated minimal size. 
Without this feature, widgets disappear or overlap (depending on their
"sticky" flag) when you make the window too small.


Two other things I just noticed:
- tab-key navigation (navigating among controls by using Tab and
Shift-Tab) should be handled automatically. Right now it seems you have
to manually define "groups" for tab-key navigation to work.
- context menus (e.g. on right click).


All that is not to say that "PyGUI s*cks" (it doesn't seem to ;-)), but
that there are a few important things lacking compared to more mature
(and possibly bloated!) GUI systems.

Regards

Antoine.



From jcarlson at uci.edu  Mon May  1 21:44:54 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 01 May 2006 12:44:54 -0700
Subject: [Python-3000] Add a standard GUI system
In-Reply-To: <4455ECB5.6070303@canterbury.ac.nz>
References: <20060428000801.671E.JCARLSON@uci.edu>
	<4455ECB5.6070303@canterbury.ac.nz>
Message-ID: <20060501105538.6759.JCARLSON@uci.edu>


Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Josiah Carlson wrote:
> 
> > Also, it would require shipping a Python GTK binding, which would
> > basically necessitate shipping GTK+ with Python.
> 
> Keep in mind that PyGUI is still very much a work in progress.
> My eventual goal is for each implementation to depend only on
> what is provided natively by the platform. The use of the Gtk
> implementation on Windows is only a stopgap measure until
> something more native is available.

That does make me feel a bit better, but I think that people will have
concerns about choosing a GUI library with such a limited number of
widgets (I believe even tk+Tix has more than PyGUI at the moment).

The current relative lack of richness in the PyGUI widget set is a
con against its inclusion.  From what I understand, the reason Tix was
included with Python is because tk had a limited widget set.


> > we may as well go whole hog and take wxPython;
> 
> I'd be disappointed if something like wxPython were chosen
> as the next "official" Python gui, for a lot of reasons --
> bloat, ugly and unpythonic API, non-native appearance and
> behaviour, dubious quality of ports, etc.

wxPython, generally speaking, uses the 'native' widgets on the platforms
it is being used on.  In Windows, that means MFC.  On OSX, that means
Carbon or Cocoa.  On *nix, that could be GTK+ or X11/motif. Taking a
wander through the wxWidgets and wxPython screenshots
(http://wxwidgets.org/screensh.htm and
http://wxpython.org/screenshots.php), they seem quite native-looking to
me.  Behavior-wise, that could be a function of the programmer of the
application; not everyone reads Apple's (or MSFT's or Gnome's) design
guidelines.

If the quality of a particular port is lacking, that is, if it is buggy,
make sure that the bugs are known so that they can get better.

While the API does leave something to be desired, it is not terribly
difficult to understand, but could certainly be made easier to
understand with help.


> > and it offers an "upgrade" path towards more "Pythonic"
> > additions like Pythoncard, Wax, or even Dabo.
> 
> I'm also not fond of the idea of putting yet more layers of
> code over something that's already too bloated.

There are certainly portions of wxPython that don't necessarily need to
be there from an API perspective; wxPoint, wxString, etc., but at least
in the case of wxPython, need to exist for the underlying wxWidgets
implementation.  It is unfortunate, but I doubt that the perhaps two
dozen extraneous classes offer significant bloat compared to the 100+
widgets and their supporting events, items, handlers, etc.

One of the reasons why I like wxPython, is because every widget I've
ever wanted or needed to use, is already there.  Sometimes the
documentation is a bit terse, but it takes 5 minutes to look through the
(extensive) demo and know almost precisely what to do.

I should mention that a few months ago, an individual came into the
wxPython-users mailing list and started talking about writing his own
GUI toolkit, because though wxPython is considered among many to be 'the
best Python GUI toolkit around', he also shared many of your and Bill's
concerns and criticisms about wxPython.  See the "cold shower request"
thread started by Peter Damoc around November 7th last year.  If I
remember correctly, he ended up sticking with wxPython (and perhaps Dabo)
because developing a new GUI toolkit would be a nontrivial amount of
effort just to get to a fraction of the widget and functionality
coverage of any one of the other toolkits (GTK, Qt, wxWidgets, Fox, etc.).


Ultimately, the desire is to have a "Pythonic" GUI toolkit for Python,
optimally included in the standard library.  You and others are working
to get PyGUI wrapping native controls to produce a Pythonic library from
the ground up.  That's great, that's wonderful, that's quite a bit of
work (not the least of which being the result of platform-specific
issues).

The people working on PythonCard, Wax and Dabo had the same idea, though
they started with wxPython as a base, because wxPython, generally
speaking, abstracts away most of the platform-specific stuff (thus
hopefully reducing the amount of work necessary).  I haven't heard much
about PythonCard and Wax development recently, but Dabo seems to be
progressing at a pretty good speed.

 - Josiah


From jcarlson at uci.edu  Mon May  1 22:00:57 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 01 May 2006 13:00:57 -0700
Subject: [Python-3000] Future of slices
In-Reply-To: <d38f5330605011214keefc4b2oa6997a2514a135ef@mail.gmail.com>
References: <20060501011031.674D.JCARLSON@uci.edu>
	<d38f5330605011214keefc4b2oa6997a2514a135ef@mail.gmail.com>
Message-ID: <20060501122448.675F.JCARLSON@uci.edu>


"Alexander Belopolsky" <alexander.belopolsky at gmail.com> wrote:
> On 5/1/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> >
> > If you want to get my general opinion; -1 on all of your recommendations.
> > In each part, I describe why.
> >
> > Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> > > 1. l[:] syntax for shallow copy.
> >
> > Note that [:] doesn't necessarily copy.
> 
> I know. It does not in numpy. However, I understand that the ability
> to do l[:] when l is a list justified not having list.copy method.

That seems a bit silly to me, but I would use list(l) to make a copy
rather than l.copy() in any case.  Or even type(l)(l).


> >  It certainly is the case for
> > Python lists, strings, tuples, and unicode today, but given standard
> > slicing of l[i:j] producing a copy of a section of a list/string/tuple
> > from i...j, removing the first is equivalent to 'the start', and
> > removing the second being equivalent to 'the end'; having l[:] do
> > something other than slicing the entire sequence (at least for
> > list/string/tuple) seems pretty unintuitive.
> 
> I did not propose l[:] doing anything different.  I was actually very
> shy proposing anything, but if I must, the proposal  would be:
> 
> 1. Replace l[start:stop:step] with l.slice(start, stop, by=step)
> 2. Replace l[start:stop:step] = x with l.setslice(x, start, stop, by=step)

I don't like the ordering on the setslice method, and I'm -1 on the idea
of replacing slicing with methods.


> > > 2. Overloading of [] syntax. The primary meaning of c[i] is: get the
> > > i-th item from the collection.
> > [snip]
> > > The main problem with [] overloading is that c[i] is not
> > > guaranteed to be "smaller" than c.
> >
> > How is this related at all to anything?
> 
> This has to do with an expectation that c[i][j]... should eventually
> throw an exception

I disagree.  The only expectation I have about c[i] is that I will be
getting some item, referenced by i, from c.  In the case of strings, I
can say c[0][0][0][0][0][0][0][0]..., so as long as c is not an empty
string.

In the case of graphs implemented as dictionaries, I can choose a random
walk from the items and never stop (assuming bidirectional links).


> unless
> you managed to create a circular list.  I put "smaller" in quote marks
> because [0,1] being smaller than  [[0,1]] is subjective (one might say
> it's the other way around because len([0,1]) > len([[0,1]])). What I
> wanted to say is that the traditional meaning of subscripting
> is to obtain an item from a container and not a container with
> possibly fewer items.


> > > This problem is even worse for strings, where c[i] is
> > > *always* a slice: c[i] is the same as c[i:i+1].
> >
> > No.
> >     >>> ''[0]
> >     Traceback (most recent call last):
> >       File "<stdin>", line 1, in ?
> >     IndexError: string index out of range
> >     >>> ''[0:1]
> >     ''
> >
> I did not realize that.  I would not call this behavior obvious.
> Particularly given
> 
> >>> ''[10:11]
> ''

In my experience and expectation, slicing generally doesn't fail on
standard objects...

    >>> ()[1:2]
    ()
    >>> [][1:2]
    []
    >>>

...even when you do something seemingly foolish...

    >>> ''[1:0]
    ''

I think this is a positive feature of slicing, at least with the
standard Python types.


> > Which would you rather do:
> >     b = a[i:j]
> > or
> >     b = str(a[k] for i in xrange(i,j))
> >
> > Obviously the first.  People who use extended slicing feel the same way,
> > as they can add a :X and have precisely what they want.
> 
> I would rather do substr(a, i, j).  In the presence of variable
> character width encodings
> (think UTF-8) substr may even need an encoding argument to operate
> properly unless
> encoding becomes a property of the string.

In Py3k, all strings are unicode, so discussion about encodings during
string slicing is unrelated to the topic at hand.

If you want substr(a, i, j) to be your slicing operator, you can define
such things in your site.py, and wrap whatever makes it into Python 2.x
or 3.x .

 - Josiah


From fredrik at pythonware.com  Mon May  1 21:58:22 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 1 May 2006 21:58:22 +0200
Subject: [Python-3000] Add a standard GUI system
References: <20060428000801.671E.JCARLSON@uci.edu><4455ECB5.6070303@canterbury.ac.nz>
	<20060501105538.6759.JCARLSON@uci.edu>
Message-ID: <e35p8v$14l$1@sea.gmane.org>

Josiah Carlson wrote:

> wxPython, generally speaking, uses the 'native' widgets on the platforms
> it is being used on.  In Windows, that means MFC.

not really.  MFC is a bloated C++ layer built on top of Windows' real
native GUI.

(wxWindows 1.X was a bloated emulation of that layer; wxPython 2.X
isn't quite as bad, but it still has an MFC smell...)

</F>




From guido at python.org  Mon May  1 22:02:24 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 1 May 2006 13:02:24 -0700
Subject: [Python-3000] Future of slices
In-Reply-To: <20060501122448.675F.JCARLSON@uci.edu>
References: <20060501011031.674D.JCARLSON@uci.edu>
	<d38f5330605011214keefc4b2oa6997a2514a135ef@mail.gmail.com>
	<20060501122448.675F.JCARLSON@uci.edu>
Message-ID: <ca471dc20605011302x42eea7fcm6f9567cacef96810@mail.gmail.com>

What's the point of this discussion? The (extended) slice notation
isn't going away.

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

From skip at pobox.com  Mon May  1 22:17:01 2006
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 1 May 2006 15:17:01 -0500
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <1146504652.5679.26.camel@fsol>
References: <06May1.095920pdt."58641"@synergy1.parc.xerox.com>
	<1146504652.5679.26.camel@fsol>
Message-ID: <17494.27837.334590.99512@montanaro.dyndns.org>


    Antoine> As far as I've seen by trying the demos and taking a quick
    Antoine> glance at the source, PyGUI also lacks (from the top of my
    Antoine> head):
    ...
    Antoine> If making PyGUI into the stdlib is important, a wiki or
    Antoine> something could be opened to list the various issues people
    Antoine> have with PyGUI.

This discussion is interesting, but runs the risk of getting a bit too
detailed for this list.  Maybe the gui-sig should be reactivated (with a
stated goal of converging on a more Pythonic GUI for Py3k) or a pygui
mailing list hosted on mail.python.org.

Skip

From janssen at parc.com  Mon May  1 22:35:30 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 13:35:30 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Mon, 01 May 2006 12:37:01 PDT."
	<1146512221.5679.55.camel@fsol> 
Message-ID: <06May1.133531pdt."58641"@synergy1.parc.xerox.com>

Antoine, thanks for the explanations.

> A control which displays and allows to interact with several lines of
> widgets (e.g. labels, images...).
> For example a buddy list in an Instant Messaging client.

This seems like part of the application UI to me, not a toolkit issue.

> You cannot assign a
> global key shortcut to every command, while you can assign a local
> hotkey to any menu item.

This seems like creeping featurism to me.  I can see the accessibility
argument, but it is basically asking for the ability to drive an
interface designed for use with a pointing device, without using a
pointing device.  I'm not sure this is a reasonable constraint.

Global hot keys are the interface for a user without a pointing
device; menus are the interface for users with a pointing device.
This seems like a reasonable design.  Trying to mix modes is asking
for complexity...

> Well, a status bar is a container which can contain many things and sits
> ...
> It can probably be implemented using a Container, though. =

Yes, it sounds like it is variable enough to be part of the
application UI, rather than a standard component.

> In wxWidgets, the GUI system is able to calculate the minimal size
> needed by each and any widget, and to prevent the user from resizing the
> window below the calculated minimal size. =

I'm not sure that this is effectively possible in all cases, but the
"set_bounds" method on Container could probably be extended to
optionally do this.

> - tab-key navigation (navigating among controls by using Tab and
> Shift-Tab) should be handled automatically. Right now it seems you have
> to manually define "groups" for tab-key navigation to work.

Seems to work automatically on my test case.  I put up three text
fields and can tab between them automatically.

Automatic determination of a tabbing order is not an exact science,
though.  I've used a number of apps that get it wrong.  I could see
having no default as a reasonable decision.

> All that is not to say that "PyGUI s*cks" (it doesn't seem to ;-)), but
> that there are a few important things lacking compared to more mature
> (and possibly bloated!) GUI systems.

Right.  I think that the question is, just what is missing, that is
really necessary.

Bill

From guido at python.org  Mon May  1 22:39:26 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 1 May 2006 13:39:26 -0700
Subject: [Python-3000] Requiring () around lambda's argument list
Message-ID: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>

I'm running into something that may make me require parentheses around
lambda's argument list. Basically, I'm settled on the following syntax
for adding optional annotations (formerly known as type declarations
:-) to parameters definitions:

  def foo(arg1name: typeexpr = defaultexpr, arg2: typeexpr =
defaultexpr, ...): ...

But the same syntax production that's used for formal parameters
inside parentheses is also used *without* parentheses in the syntax
for lambda. Unfortunately the above extension makes it ambiguous; when
the parser sees

  lambda arg1name : ...

it can't tell whether the colon is the colon that ends the formal
parameter list or whether it's a colon that introduces an optional
parameter annotation.

I really don't want to restart the syntax debate for parameter
annotations, so I feel forced to require parentheses around lambda's
parameter list.

Fortunately this is at least one of those things that we can fix with
a purely syntactical source code transformation...

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

From aahz at pythoncraft.com  Mon May  1 22:51:08 2006
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 1 May 2006 13:51:08 -0700
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06May1.133531pdt."58641"@synergy1.parc.xerox.com>
References: <1146512221.5679.55.camel@fsol>
	<06May1.133531pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <20060501205108.GA22367@panix.com>

On Mon, May 01, 2006, Bill Janssen wrote:
>Antoine:
>> 
>> You cannot assign a
>> global key shortcut to every command, while you can assign a local
>> hotkey to any menu item.
> 
> This seems like creeping featurism to me.  I can see the accessibility
> argument, but it is basically asking for the ability to drive an
> interface designed for use with a pointing device, without using a
> pointing device.  I'm not sure this is a reasonable constraint.
> 
> Global hot keys are the interface for a user without a pointing
> device; menus are the interface for users with a pointing device.
> This seems like a reasonable design.  Trying to mix modes is asking
> for complexity...

Your point being?  I use Windows, OS X, and Linux.  In all cases, I
strive to maximize my use of the keyboard and minimize my use of pointing
devices.  I think it is entirely reasonable to expect that a GUI toolkit
will at least make it straightforward to implement keyboard-based
commands.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours."  --Richard Bach

From rhettinger at ewtllc.com  Mon May  1 23:09:31 2006
From: rhettinger at ewtllc.com (Raymond Hettinger)
Date: Mon, 01 May 2006 14:09:31 -0700
Subject: [Python-3000] Requiring () around lambda's argument list
In-Reply-To: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>
References: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>
Message-ID: <4456790B.7080409@ewtllc.com>

Guido van Rossum wrote:

>I'm running into something that may make me require parentheses around
>lambda's argument list. 
>

Are the parens always needed or will it depend on the surrounding 
tokens?  Adding extra parens feels a bit odd in the following situations:

    databases = filter(lambda name: name.startswith('2006'), 
cursor.fetchall())
    mylist.sort(key = lambda record:  record.name.lower())


Raymond
   

From janssen at parc.com  Mon May  1 23:10:31 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 14:10:31 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Mon, 01 May 2006 10:11:42 PDT."
	<e35fgf$v7h$1@sea.gmane.org> 
Message-ID: <06May1.141031pdt."58641"@synergy1.parc.xerox.com>

> since this is the Py3K list, why hurry ?

Because Guido seems to be hurrying.  All those pitchforks outside his
office, I suppose.

> (for the record, I'd prefer a conceptual mix of HTML, PyGUI, WinForms,
> and WCK, plus Tkinter's binding model and Canvas.  more about this some
> other day.)

Please hurry :-).  I looked at your work when I was thinking about this.

The Tk canvas widget is a nice one, perhaps we should use its model.
I've heard it was inspired by Joel Bartlett's work on ezd (see
http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-6.pdf).

The ezd work is very nice, recommended reading.  In fact, when I
started thinking about a Py3K toolkit, I was thinking in terms of an
all-Python solution implemented on top of ezd-style canvases built on
top of pycairo.  You'd still need platform-specific frobs for the Mac
menubar and the Windows taskbar, etc., though.  When I looked at PyGUI
it seemed close enough to "right" to pick.  I'm still not quite sure
what the PyGUI "canvas" is; it might be possible to have one that
corresponds to a graphical object in the ezd model.

The GTK+ canvas widget is in turn based on the Tk canvas and ezd,
too.

http://www.usenix.org/publications/library/proceedings/usenix2000/freenix/full_papers/quintero/quintero_html/node3.html).

Bill





From janssen at parc.com  Mon May  1 23:29:14 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 14:29:14 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Mon, 01 May 2006 13:51:08 PDT."
	<20060501205108.GA22367@panix.com> 
Message-ID: <06May1.142921pdt."58641"@synergy1.parc.xerox.com>

Aahz writes:
> I use Windows, OS X, and Linux.  In all cases, I
> strive to maximize my use of the keyboard and minimize my use of pointing
> devices.

Me too.

> I think it is entirely reasonable to expect that a GUI toolkit
> will at least make it straightforward to implement keyboard-based
> commands.

Yep.  Which PyGUI already does.

Bill

From guido at python.org  Mon May  1 23:33:56 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 1 May 2006 14:33:56 -0700
Subject: [Python-3000] Requiring () around lambda's argument list
In-Reply-To: <4456790B.7080409@ewtllc.com>
References: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>
	<4456790B.7080409@ewtllc.com>
Message-ID: <ca471dc20605011433g1976de64g96a5167e4601f51c@mail.gmail.com>

Yes, they will always be needed, except perhaps for an empty parameter
list; you may be able to write lambda: blah instead of lambda(): blah.

--Guido

On 5/1/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> Guido van Rossum wrote:
>
> >I'm running into something that may make me require parentheses around
> >lambda's argument list.
> >
>
> Are the parens always needed or will it depend on the surrounding
> tokens?  Adding extra parens feels a bit odd in the following situations:
>
>     databases = filter(lambda name: name.startswith('2006'),
> cursor.fetchall())
>     mylist.sort(key = lambda record:  record.name.lower())
>
>
> Raymond
>
>


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

From jcarlson at uci.edu  Mon May  1 23:54:54 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 01 May 2006 14:54:54 -0700
Subject: [Python-3000] immutable bytes in py3k (was: [Python-Dev] methods on
	the bytes object)
In-Reply-To: <4456606E.2030100@v.loewis.de>
References: <20060501092208.6756.JCARLSON@uci.edu>
	<4456606E.2030100@v.loewis.de>
Message-ID: <20060501145233.676B.JCARLSON@uci.edu>


"Martin v. L?wis" <martin at v.loewis.de> wrote:
> 
> Josiah Carlson wrote:
> > Before I get into my reply, I'm going to start out by defining a new
> > term:
> > 
> > operationX - the operation of interpreting information differently than
> > how it is presented, generally by constructing a data structure based on
> > the input information.
> >     eg; programming language source file -> parse tree,
> >         natual language -> parse tree or otherwise,
> >         structured data file -> data structure (tree, dictionary, etc.),
> >         etc.
> > synonyms: parsing, unmarshalling, interpreting, ...
> > 
> > Any time I would previously describe something as some variant of 'parse',
> > replace that with 'operationX'.  I will do that in all of my further
> > replies.
> >
> >>> Certainly that is the case.  But how would you propose embedded bytes
> >>> data be represented? (I talk more extensively about this particular
> >>> issue later).
> >> Can't answer: I don't know what "embedded bytes data" are.
> 
> Ok. I think I would use base64, of possibly compressed content. It's
> more compact than your representation, as it only uses 1.3 characters
> per byte, instead of the up-to-four bytes that the img2py uses.

I never said it was the most efficient representation, just one that was
being used (and one in which I had no control over previously defining).
What I provided was automatically generated by a script provided with
wxPython.


> If ease-of-porting is an issue, img2py should just put an
> .encode("latin-1") at the end of the string.

Ultimately, this is still the storage of bytes in a textual string.  It
may be /encoded/ as text, but it is still conceptually bytes in text,
which is at least as confusing as text in bytes.


> >     return zlib.decompress(
> > 'x\xda\x01\x14\x02\xeb\xfd\x89PNG\r\n\x1a\n\x00\x00\x00\rIHDR\x00\x00\x00 \
> [...]
> 
> > That data is non-textual.  It is bytes within a string literal.  And it
> > is embedded (within a .py file).
> 
> In Python 2.x, it is that, yes. In Python 3, it is a (meaningless)
> text.

Toss an .encode('latin-1'), and it isn't meaningless.

    >>> type(x)
    <type 'unicode'>
    >>> zlib.decompress(x.encode('latin-1'))[:4]
    '\x89PNG'


> >>> I am apparently not communicating this particular idea effectively
> >>> enough.  How would you propose that I store parsing literals for
> >>> non-textual data, and how would you propose that I set up a dictionary
> >>> to hold some non-trivial number of these parsing literals?
> > 
> > An operationX literal is a symbol that describes how to interpret the
> > subsequent or previous data.  For an example of this, see the pickle
> > module (portions of which I include below).
> 
> I don't think there can be, or should be, a general solution for
> all operationX literals, because the different applications of
> operationX all have different requirements wrt. their literals.
> 
> In binary data, integers are the most obvious choice for
> operationX literals. In text data, string literals are.
[snip]
> Yes. For pickle, the ordinals of the type code make good operationX
> literals.

But, as I brought up before, while single integers are sufficient for
some operationX literals, that may not be the case for others.  Say, for
example, a tool which discovers the various blobs from quicktime .mov
files (movie portions, audio portions, images, etc.).  I don't remember
all of the precise names to parse, but I do remember that they were all
4 bytes long.

This means that we would generally use the following...

    dispatch = {(ord(ch), ord(ch), ord(ch), ord(ch)): ...,
                #or
                tuple(ord(i) for i in '...'): ...,
               }

And in the actual operationX process...

    #if we are reading bytes...
        key = tuple(read(4))

    #if we are reading str...
        key = tuple(bytes(read(4), 'latin-1'))
        #or   tuple(read(4).encode('latin-1'))
        #or   tuple(ord(i) for i in read(4))

There are, of course, other options which could use struct and 8, 16, 32,
and/or 64 bit integers (with masks and/or shifts), for the dispatch = ...
or key = ... cases, but those, again, would rely on using Python 3.x
strings as a container for non-text data.


> > I described before how you would use this kind of thing to perform
> > operationX on structured information.  It turns out that pickle (in
> > Python) uses a dictionary of operationX symbols/literals -> unbound
> > instance methods to perform operationX on the pickled representation of
> > Python objects (literals where XXXX = '...' are defined, and symbols
> > using the XXXX names). The relevant code for unpickling is the while 1:
> > section of the following.
> 
> Right. I would convert the top of pickle.py to read
> 
> MARK            = ord('(')
> STOP            = ord('.')
> ...
> 
> > For an example of where people use '...' to represent non-textual
> > information in a literal, see the '# Protocol 2' section of pickle.py ...
> 
> Right.
> 
> > # Protocol 2
> > 
> > PROTO           = '\x80'  # identify pickle protocol
> 
> This should be changed to
> 
> PROTO           = 0x80  # identify pickle protocol
> etc.

I see that you don't see ord(...) as a case where strings are being used
to hold bytes data.  I would disagree, in much the same way that I would
disagree with the idea that bytes.encode('base64') only holds text. But
then again, I also see that the majority of this "rethink your data
structures and dispatching" would be unnecessary if there were an
immutable bytes literal in Python 3.x. People could then use...

    MARK            = b'('
    STOP            = b'.'
    ...
    PROTO           = b'\x80'
    ...

    dispatch = {b'...': fcn}

    key = read(X)
    dispatch[X](self)
    #regardless of X

... etc., as they have already been doing (only without the 'b' or other
prefix).


> >                 key = read(1)
> 
> and then this to
>                   key = ord(read(1))

This, of course, presumes that read() will return Python 3.x strings,
which may be ambiguous and/or an error in the binary pickle case
(especially if people don't pass 'latin-1' as the encoding to the open()
call).


> > See any line-based socket protocol for where .find() is useful.
> 
> Any line-based protocol is textual, usually based on ASCII.

Not all of ASCII 0...127 is text, and the RFC for telnet describes how
ASCII 128...255 can be used as optional extensions.  Further, the FTP
protocol defines a mechanism where by in STREAM or BLOCK modes, data can
be terminated by an EOR, EOF, or even a different specified marker
(could be multiple contiguous bytes).

It is also the case that some filesystems, among other things, define
file names as a null-terminated string in a variable-lengthed record, or
even pad the remaining portion of the field with nulls (which one would
presumably .rstrip('\0') in Python 2.x).  (On occasion, I have found the
need to write a filesystem explorer which opens volumes raw, especially
on platforms without drivers for that particular filesystem).


 - Josiah


From jcarlson at uci.edu  Tue May  2 00:01:50 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 01 May 2006 15:01:50 -0700
Subject: [Python-3000] Add a standard GUI system
In-Reply-To: <e35p8v$14l$1@sea.gmane.org>
References: <20060501105538.6759.JCARLSON@uci.edu> <e35p8v$14l$1@sea.gmane.org>
Message-ID: <20060501145901.676E.JCARLSON@uci.edu>


"Fredrik Lundh" <fredrik at pythonware.com> wrote:
> 
> Josiah Carlson wrote:
> 
> > wxPython, generally speaking, uses the 'native' widgets on the platforms
> > it is being used on.  In Windows, that means MFC.
> 
> not really.  MFC is a bloated C++ layer built on top of Windows' real
> native GUI.

I've never done C/C++ GUI programming on any platform (Windows included),
and I had presumed that the only buzzword I've ever heard in relation to
Windows native GUIs would natually be the only one that existed.  My
mistake.

 - Josiah


From jcarlson at uci.edu  Tue May  2 00:04:05 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 01 May 2006 15:04:05 -0700
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06May1.133531pdt."58641"@synergy1.parc.xerox.com>
References: <1146512221.5679.55.camel@fsol>
	<06May1.133531pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <20060501150146.6771.JCARLSON@uci.edu>


Bill Janssen <janssen at parc.com> wrote:
> Antoine, thanks for the explanations.
> 
> > A control which displays and allows to interact with several lines of
> > widgets (e.g. labels, images...).
> > For example a buddy list in an Instant Messaging client.
> 
> This seems like part of the application UI to me, not a toolkit issue.

Um...no.  Most client-side email applications allow you to view email in
a particular folder as a 'threaded' and 'non-threaded' view.  The
'non-threaded' view would be a list control, if I understand Antoine
correctly.  I would also tend to agree that it is a very useful and/or
necessary widget.

 - Josiah


From guido at python.org  Tue May  2 00:25:35 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 1 May 2006 15:25:35 -0700
Subject: [Python-3000] PEP 3002 (Procedure for Backwards-Incompatible
	Changes)
In-Reply-To: <d11dcfba0604292007i4fdf3a18qd4c98060fb14e06e@mail.gmail.com>
References: <ca471dc20604271443v2fc525e6q286b5d5deff97228@mail.gmail.com>
	<d11dcfba0604292007i4fdf3a18qd4c98060fb14e06e@mail.gmail.com>
Message-ID: <ca471dc20605011525m627f8e7cvcbbd599f200a2fdf@mail.gmail.com>

On 4/29/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 4/27/06, Guido van Rossum <guido at python.org> wrote:
> > I just read PEP 3002 and while I like most of what I see (thanks
> > Steven Bethard!) there's one section that stands out as problematic.
> [snip]
> > Rather than a version of Python
> > 3000, I suggest to add such warning code to Python 2.x, and not as a
> > branch, but as a permanent feature (that is however only enabled by a
> > command-line flag).
>
> Yes, I think it definitely makes more sense to make the modifications
> on 2.x.  I was hesitant to require integrating it into the main-line
> Python 2.x code because I was worried about affecting performance.
> But of course with a command-line flag, that point is moot.  So
> basically python3warn.py could be become "python -SOME_OPTION" where
> SOME_OPTION would enable all the Python 3.0 checks.
>
> So I guess the question then is what the option should enable.  Should
> it try to implement the Python 3.0 behavior?  Or should it just warn
> when the behavior is changed?  The former requires much more Python
> 3.0 code to be back-ported to Python 2.X, but would presumably give
> much better error reporting.  I'd love to require that, but I'm afraid
> of the work it would take.

It should continue to use the 2.x semantics to the greatest extent
possible, while issueing warnings about any constructs whose semantics
will change in 3.0.

I have a fairly elaborate example in mind: with this new flag,
dict.keys() should return a subclass of list which behaves exactly
like list except that it issues a warning whenever you use any method
other than __iter__(). This should be transparent except to the most
demanding code (the subclass could theoretically cause programs to
behave differently but in practice I doubt it will change much) and
should catch any code that uses the result of keys() other than to
loop over it; at the same time it will not complain about code that
simply assigns keys() to a variable and later (perhaps in a different
function) loops over that variable.

> P.S. I have commit access to the PEPs now, so I can update PEP 3002
> with whatever we decide.

Cool. I can definitely use help keeping all the docs uptodate!

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

From janssen at parc.com  Tue May  2 02:28:13 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 17:28:13 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Mon, 01 May 2006 15:04:05 PDT."
	<20060501150146.6771.JCARLSON@uci.edu> 
Message-ID: <06May1.172822pdt."58641"@synergy1.parc.xerox.com>

> > This seems like part of the application UI to me, not a toolkit issue.
> 
> Um...no.  Most client-side email applications allow you to view email in
> a particular folder as a 'threaded' and 'non-threaded' view.  The
> 'non-threaded' view would be a list control, if I understand Antoine
> correctly.  I would also tend to agree that it is a very useful and/or
> necessary widget.

Josiah,

A widget toolkit which pre-implements parts of particular applications
does make it easier to implement those applications, I agree.  The
question in my mind is whether an application can be built even if
that particular widget is missing.  Core vs. useful, I suppose.

I encourage you to try some experimentation to see if there's
something in the design of PyGUI which would preclude such a widget
from being added.

Bill

From janssen at parc.com  Tue May  2 02:33:11 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 17:33:11 PDT
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: Your message of "Mon, 01 May 2006 13:17:01 PDT."
	<17494.27837.334590.99512@montanaro.dyndns.org> 
Message-ID: <06May1.173317pdt."58641"@synergy1.parc.xerox.com>

Skip writes:
> This discussion is interesting, but runs the risk of getting a bit too
> detailed for this list.  Maybe the gui-sig should be reactivated (with a
> stated goal of converging on a more Pythonic GUI for Py3k) or a pygui
> mailing list hosted on mail.python.org.

I think a PyGUI mailing list would be a good thing, Skip.  And a
bug-tracker.  And a CVS repository.

I disagree, though, about this discussion being too detailed for this
list.  This is exactly the kind of discussion we need on this list --
what are we going to do to fix the biggest outstanding problem with
Python 2?  Discussions about what to name specific properties might be
more appropriate elsewhere -- seems like python-dev likes those kinds
of discussions :-).

Bill


From janssen at parc.com  Tue May  2 02:37:06 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 1 May 2006 17:37:06 PDT
Subject: [Python-3000] back with more GUI planning in a few days...
Message-ID: <06May1.173712pdt."58641"@synergy1.parc.xerox.com>

Folks, I've got a paper deadline looming, and helpful as this
discussion has been in my procrastination :-), I need to get back to it.
I'll take this thread up again next week, if no one else does.

Please feel free to send me mail in the meantime, and try a few things
with PyGUI -- let's see if it's as capable as I think it is, and
what's missing.

Bill

From jcarlson at uci.edu  Tue May  2 03:49:27 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 01 May 2006 18:49:27 -0700
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06May1.172822pdt."58641"@synergy1.parc.xerox.com>
References: <20060501150146.6771.JCARLSON@uci.edu>
	<06May1.172822pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <20060501184213.6775.JCARLSON@uci.edu>


Bill Janssen <janssen at parc.com> wrote:
> > > This seems like part of the application UI to me, not a toolkit issue.
> > 
> > Um...no.  Most client-side email applications allow you to view email in
> > a particular folder as a 'threaded' and 'non-threaded' view.  The
> > 'non-threaded' view would be a list control, if I understand Antoine
> > correctly.  I would also tend to agree that it is a very useful and/or
> > necessary widget.
> 
> A widget toolkit which pre-implements parts of particular applications
> does make it easier to implement those applications, I agree.  The
> question in my mind is whether an application can be built even if
> that particular widget is missing.  Core vs. useful, I suppose.
> 
> I encourage you to try some experimentation to see if there's
> something in the design of PyGUI which would preclude such a widget
> from being added.

I was using that particular example of a list control as an example of
what one would look like.  Many applications use list controls to many
different effects.  My only public (at the moment) GUI application (PyPE)
uses list controls to hold results lists for a find-in-files result, as
well as a list of 'todos' (delimited by #todo:what, or its equivalent in
other languages).  Almost every filesystem viewer in the history of
computing has also used the rows and columns approach, as does pgAdmin
to display the results of SQL queries.

Technically speaking, any toolkit which allows for scrolling and the
laying out of controls in a grid would be sufficient to implement this
(optional column-title buttons for sorting would be convenient, as well
as draggable column widths; as has been demonstrated almost everywhere).

 - Josiah


From talin at acm.org  Tue May  2 07:40:15 2006
From: talin at acm.org (Talin)
Date: Tue, 2 May 2006 05:40:15 +0000 (UTC)
Subject: [Python-3000] characters data type
Message-ID: <loom.20060502T073849-533@post.gmane.org>

Given that strings are going to be unicode, will there be a "characters"
data type to go along with the "bytes" data type? And how is the bytes
data type different from the existing array type?

-- Talin



From msoulier at digitaltorque.ca  Tue May  2 07:43:54 2006
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Tue, 2 May 2006 01:43:54 -0400
Subject: [Python-3000] Automatically invoking str() in str.join()
In-Reply-To: <e31r59$b2j$1@sea.gmane.org>
References: <4450C80D.50002@iinet.net.au> <20060427170803.GB17595@panix.com>
	<1146157955.10752.161.camel@resist.wooz.org>
	<4450FE5B.4010208@ieee.org>
	<1f7befae0604271046n58484382hf7fa5c66b8a4f570@mail.gmail.com>
	<e2r17l$ql6$1@sea.gmane.org>
	<1f7befae0604271154w6ba78d3p3b6851e85d4dc68d@mail.gmail.com>
	<e2stoa$l2i$1@sea.gmane.org>
	<1f7befae0604282307x10335f80x55d75509ff55eedb@mail.gmail.com>
	<e31r59$b2j$1@sea.gmane.org>
Message-ID: <fb6605670605012243k6ceac4a4h7a45efa8d51610e9@mail.gmail.com>

On 4/30/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> for the record, this just appeared on comp.lang.python:
>
>     hello everyone! I can't seem to find a function that combines a list of
>     items into a string with a seperator between the individual elements..
>
> which, based on the law of design based on random sampling of c.l.python,
> indicates that the current situation is not optimal.

I for one found the move to put join() as a string method _very_
unintiutive, and rather arbitrary. Lets just be different for the sake
of being different.

It makes far more sense to put the method on the data that you are
acting upon. If you're joining a list, then join() should be a list
method. This is something that Ruby does right, IMHO.

Mike
--
Michael P. Soulier <msoulier at digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein

From sanxiyn at gmail.com  Tue May  2 09:02:46 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 2 May 2006 16:02:46 +0900
Subject: [Python-3000] Signature PEP
Message-ID: <5b0248170605020002o154555chc48deb1377970ce3@mail.gmail.com>

Hi, PyPy people,

What do you think about this Signature PEP?
http://mail.python.org/pipermail/python-3000/2006-April/001249.html

PyPy has something similar as
pypy.interpreter.pycode.cpython_code_signature, and I think it's
definitely a good idea to have some better interface than code.co_*
and CO_FLAGS.
http://codespeak.net/svn/pypy/dist/pypy/interpreter/pycode.py

We also have more extensive interface in pypy.annotation.description:
http://codespeak.net/svn/pypy/dist/pypy/annotation/description.py

There's FunctionDesc, ClassDesc, and MethodDesc there. Though they are
quite PyPy-specific.

Seo Sanghyeon

From fredrik at pythonware.com  Tue May  2 09:38:10 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 2 May 2006 09:38:10 +0200
Subject: [Python-3000] Automatically invoking str() in str.join()
References: <4450C80D.50002@iinet.net.au>
	<20060427170803.GB17595@panix.com><1146157955.10752.161.camel@resist.wooz.org><4450FE5B.4010208@ieee.org><1f7befae0604271046n58484382hf7fa5c66b8a4f570@mail.gmail.com><e2r17l$ql6$1@sea.gmane.org><1f7befae0604271154w6ba78d3p3b6851e85d4dc68d@mail.gmail.com><e2stoa$l2i$1@sea.gmane.org><1f7befae0604282307x10335f80x55d75509ff55eedb@mail.gmail.com><e31r59$b2j$1@sea.gmane.org>
	<fb6605670605012243k6ceac4a4h7a45efa8d51610e9@mail.gmail.com>
Message-ID: <e3729a$2fb$1@sea.gmane.org>

Michael P. Soulier wrote:

> > which, based on the law of design based on random sampling of c.l.python,
> > indicates that the current situation is not optimal.
>
> I for one found the move to put join() as a string method _very_
> unintiutive, and rather arbitrary. Lets just be different for the sake
> of being different.
>
> It makes far more sense to put the method on the data that you are
> acting upon. If you're joining a list, then join() should be a list
> method.

the problem is that sequences are abstract interfaces in Python, and
join() doesn't only work on sequences, it also works on anything that
can be iterated over.

if you move join to the list type, you'll narrow down the interface for
functions using join from "pass me something that supports iteration"
to "pass me a list or a subtype thereof".

(but some days, I wonder if we shouldn't just nuke the entire instance-
based dispatch and replace it with something derived from PJE's im-
plementation of the Chambers/Chen global dispatch machinery, so we
can provide global join methods for anything that implements either
__iter__ or __getitem__)

</F>




From jcarlson at uci.edu  Tue May  2 10:06:36 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 02 May 2006 01:06:36 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <loom.20060502T073849-533@post.gmane.org>
References: <loom.20060502T073849-533@post.gmane.org>
Message-ID: <20060502010154.6778.JCARLSON@uci.edu>


Talin <talin at acm.org> wrote:

> Given that strings are going to be unicode, will there be a "characters"
> data type to go along with the "bytes" data type?

No.  The content of bytes is an 8 bit integer.

> And how is the bytes data type different from the existing array type?

Effectively, you can think of the bytes datatype as a combination of a
list and an array('B').  It is supposed to be optimized for repeated
extension, so users can presumably use += without worry.  That isn't the
case with the current array type.

Is this suffient to warrant a new replacement type?  I don't believe so,
hence my series of posts in python-dev (the most recent of which was
reposted here) in regards to immutable and mutable bytes types.

 - Josiah


From p.f.moore at gmail.com  Tue May  2 10:34:25 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 2 May 2006 09:34:25 +0100
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <-5854039353666179739@unknownmsgid>
References: <20060501150146.6771.JCARLSON@uci.edu>
	<-5854039353666179739@unknownmsgid>
Message-ID: <79990c6b0605020134x30266abvdf414218b4eda069@mail.gmail.com>

On 5/2/06, Bill Janssen <janssen at parc.com> wrote:
> A widget toolkit which pre-implements parts of particular applications
> does make it easier to implement those applications, I agree.  The
> question in my mind is whether an application can be built even if
> that particular widget is missing.  Core vs. useful, I suppose.

My view is entirely opposite. If the control (widget) is provided
natively, it needs to be made available to application code. Otherwise
it's necessary to reimplement it, and you're never going to get every
detail right. This way lies Tk's or Swing's "cross-platform" GUI mess.

This is, of course, hard, as platforms offer widely differing widget
sets. Tough. Nobody said writing a portable GUI layer was going to be
easy.

Paul.

From thomas at python.org  Tue May  2 10:38:57 2006
From: thomas at python.org (Thomas Wouters)
Date: Tue, 2 May 2006 10:38:57 +0200
Subject: [Python-3000] Requiring () around lambda's argument list
In-Reply-To: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>
References: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>
Message-ID: <9e804ac0605020138o7a1c8348j1e6c33caf5c595a5@mail.gmail.com>

On 5/1/06, Guido van Rossum <guido at python.org> wrote:
>
> I'm running into something that may make me require parentheses around
> lambda's argument list.


Lambda-lovers will probably jump all over me for suggesting this, and I
doubt you'll go fir it, but what about just not allowing type annotations in
lambda statements? They're neutered anyway.

In-fact-let's-just-toss-it-altogether'ly y'rs,
--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060502/0dc10c61/attachment-0001.htm 

From rasky at develer.com  Tue May  2 11:04:11 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Tue, 2 May 2006 11:04:11 +0200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
References: <1146512221.5679.55.camel@fsol>
	<06May1.133531pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <091301c66dc7$60e5cbf0$8d472597@bagio>

Bill Janssen <janssen at parc.com> wrote:

>> A control which displays and allows to interact with several lines of
>> widgets (e.g. labels, images...).
>> For example a buddy list in an Instant Messaging client.
>
> This seems like part of the application UI to me, not a toolkit issue.

No. The toolkit *shall* provide the controls. An application *shall not*
reinvent the wheel. Please, do not try to defend PyGUI behind necessary. PyGUI
*is* missing literally hundreds of features compared to PyQt or wxPython, and
your minimizing this difference won't make programmers less angry when they
don't find what they are used to find in a GUI toolkit.

>> You cannot assign a
>> global key shortcut to every command, while you can assign a local
>> hotkey to any menu item.
>
> This seems like creeping featurism to me.
> I can see the accessibility
> argument, but it is basically asking for the ability to drive an
> interface designed for use with a pointing device, without using a
> pointing device.  I'm not sure this is a reasonable constraint.

It is. Every GUI toolkit has this, every GUI program people use in the world
have this feature. Even if *you* believe it's not important, please accept the
fact that thousands of people might need it, and all other GUI toolkits provide
it for a reason.

> Global hot keys are the interface for a user without a pointing
> device; menus are the interface for users with a pointing device.
> This seems like a reasonable design.  Trying to mix modes is asking
> for complexity...

I don't care if it's a reasonable design. This is not how application works
under Windows or Linux. If I cannot reproduce the way native applications work
under Windows or Linux, the toolkit is trash to me. I'll keep my PyQt.

>> Well, a status bar is a container which can contain many things and
>> sits ...
>> It can probably be implemented using a Container, though. =
>
> Yes, it sounds like it is variable enough to be part of the
> application UI, rather than a standard component.

No, it should be a standard component because it's used by almost any non-toy
application, and it's mad to require that every application reinvent the wheel.
Every serious GUI toolkit has a statusbar. Again, you're making joke of
yourself with this kind of answers. Have you *ever* written a real-world
production-ready GUI application, which went through serious QA? It really
looks like you didn't, if you answer like this.

 >> In wxWidgets, the GUI system is able to calculate the minimal size
>> needed by each and any widget, and to prevent the user from resizing
>> the window below the calculated minimal size. =
>
> I'm not sure that this is effectively possible in all cases, but the
> "set_bounds" method on Container could probably be extended to
> optionally do this.

It has to be automatic. The *default* way to construct a widget must be so that
(if it's resizeable) it can't resize behind its limit. Otherwise, it's simply a
bug. Keep any one of the KDE applications and look at how it behaves. Did I
mention PyQt is already ready, powerful, complete *today*.

>> All that is not to say that "PyGUI s*cks" (it doesn't seem to ;-)),
>> but that there are a few important things lacking compared to more
>> mature (and possibly bloated!) GUI systems.
>
> Right.  I think that the question is, just what is missing, that is
> really necessary.


No. Anything *might* be necessary to someone. I don't want to add a label
because there is no statusbar. Or to tell my users "don't resize the dialogs
too small because my toolkit can't do the right thing, it's not necessary after
all".

The real question is why we should care about adding to the stdlib a GUI
toolkit which is light-years newer and more incomplete that any other mature
toolkit. I think this whole thread is pointless as it's clear that PyGUI is not
ready for being part of the stdlib. Let's discuss more mature toolkits, if we
have to.

Giovanni Bajo


From ncoghlan at gmail.com  Tue May  2 11:08:32 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 02 May 2006 19:08:32 +1000
Subject: [Python-3000] sets in P3K?
In-Reply-To: <ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>	<Pine.GSO.4.58.0604301605170.18138@qew.cs>	<e336a8$spg$1@sea.gmane.org>
	<44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
Message-ID: <44572190.30007@gmail.com>

Guido van Rossum wrote:
> (a) {testlist} and {genexp} with the empty set written as set().
<...>
> As Raymond says, upheaval of other notations isn't worth the minor
> convenience that set literals provide.

+1 for option (a)

If you went for a syntactic notation for the empty set, I'd want to use {} and 
make the empty dict {:}, by that idea didn't even make your list of 
alternatives :)

I've still got a couple of ideas I want to explore in terms of using 
metaclasses that define __getitem__ for container types, but I'll start a 
separate thread for that (I want to tinker with some actual code first).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Tue May  2 11:31:26 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 02 May 2006 19:31:26 +1000
Subject: [Python-3000] Requiring () around lambda's argument list
In-Reply-To: <9e804ac0605020138o7a1c8348j1e6c33caf5c595a5@mail.gmail.com>
References: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>
	<9e804ac0605020138o7a1c8348j1e6c33caf5c595a5@mail.gmail.com>
Message-ID: <445726EE.7040603@gmail.com>

Thomas Wouters wrote:
> 
> On 5/1/06, *Guido van Rossum* <guido at python.org 
> <mailto:guido at python.org>> wrote:
> 
>     I'm running into something that may make me require parentheses around
>     lambda's argument list.
> 
> 
> Lambda-lovers will probably jump all over me for suggesting this, and I 
> doubt you'll go fir it, but what about just not allowing type 
> annotations in lambda statements? They're neutered anyway.

Or spell it with a different keyword ;)

  (expr given (arg1: a1type=a1default, arg2: a2type= a2default))

Grinning-ducking-and-running'ly y'rs,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From greg.ewing at canterbury.ac.nz  Tue May  2 13:23:46 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 02 May 2006 23:23:46 +1200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <79990c6b0605020134x30266abvdf414218b4eda069@mail.gmail.com>
References: <20060501150146.6771.JCARLSON@uci.edu>
	<-5854039353666179739@unknownmsgid>
	<79990c6b0605020134x30266abvdf414218b4eda069@mail.gmail.com>
Message-ID: <44574142.6060101@canterbury.ac.nz>

Paul Moore wrote:

> This is, of course, hard, as platforms offer widely differing widget
> sets. Tough. Nobody said writing a portable GUI layer was going to be
> easy.

Indeed. I'd say this kind of issue has been the *most*
difficult thing about designing and implementing PyGUI
so far. One has to steer a tricky course between the
features provided by the various platforms.

This is also a reason for targeting the *smallest* set
of platforms that one can get away with, lest the
intersection of available features shrink to something
so small as to be useless. That's why I'm currently
planning to support exactly 3 platforms (Cocoa, Gtk
and Win32), and would be reluctant to add any more that
overlap with those.

I suspect that attempting to support too many platforms
is one of the things that led to anygui's demise.

--
Greg

From mcherm at mcherm.com  Tue May  2 13:54:07 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Tue, 02 May 2006 04:54:07 -0700
Subject: [Python-3000] Requiring () around lambda's argument list
Message-ID: <20060502045407.83l4jnxdn4hwcg4c@login.werra.lunarpages.com>

Thomas Wouters writes:
> Lambda-lovers will probably jump all over me for suggesting
> this, and I doubt you'll go fir it, but what about just not
> allowing type annotations in lambda statements? They're
> neutered anyway.

Speaking as a lambda user... +1... Great Idea Thomas! Lambdas are
for tiny anonymous functions... if you feel the need to specify the
types, why not go ahead and include a function name and perhaps
even a docstring -- use def instead.

-- Michael Chermside


From greg.ewing at canterbury.ac.nz  Tue May  2 14:05:29 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 03 May 2006 00:05:29 +1200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <091301c66dc7$60e5cbf0$8d472597@bagio>
References: <1146512221.5679.55.camel@fsol>
	<06May1.133531pdt.58641@synergy1.parc.xerox.com>
	<091301c66dc7$60e5cbf0$8d472597@bagio>
Message-ID: <44574B09.6030802@canterbury.ac.nz>

Giovanni Bajo wrote:

> > I can see the accessibility
> > argument, but it is basically asking for the ability to drive an
> > interface designed for use with a pointing device, without using a
> > pointing device.  I'm not sure this is a reasonable constraint.
> 
> It is. Every GUI toolkit has this, every GUI program people use in the world
> have this feature.

Not every system goes about providing it the same way, though.
This business of putting & in front of letters is a Windows-ism
that Linux seems to have become infected with. MacOSX has a quite
different approach that doesn't require the application author to
do anything special at all -- it's a system feature there, not
an application feature.

I'll have to think further about what this means for PyGUI.

> No, it should be a standard component because it's used by almost any non-toy
> application, and it's mad to require that every application reinvent the wheel.

But it's not clear what a status bar would *do* other than
being a container for other components. Can you elaborate?

> Every serious GUI toolkit has a statusbar.

Cocoa doesn't. (It has something called an NSStatusBar,
but it doesn't do what what you're talking about.)

--
Greg

From p.f.moore at gmail.com  Tue May  2 14:07:48 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 2 May 2006 13:07:48 +0100
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <44574142.6060101@canterbury.ac.nz>
References: <20060501150146.6771.JCARLSON@uci.edu>
	<-5854039353666179739@unknownmsgid>
	<79990c6b0605020134x30266abvdf414218b4eda069@mail.gmail.com>
	<44574142.6060101@canterbury.ac.nz>
Message-ID: <79990c6b0605020507na4d0940q14e23bbd0d64221b@mail.gmail.com>

On 5/2/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Paul Moore wrote:
>
> > This is, of course, hard, as platforms offer widely differing widget
> > sets. Tough. Nobody said writing a portable GUI layer was going to be
> > easy.
>
> Indeed. I'd say this kind of issue has been the *most*
> difficult thing about designing and implementing PyGUI
> so far. One has to steer a tricky course between the
> features provided by the various platforms.

Exactly.

> This is also a reason for targeting the *smallest* set
> of platforms that one can get away with, lest the
> intersection of available features shrink to something
> so small as to be useless. That's why I'm currently
> planning to support exactly 3 platforms (Cocoa, Gtk
> and Win32), and would be reluctant to add any more that
> overlap with those.

An alternative is to expose more widgets, but make them only available
on platforms that have them natively. That pushes the platform
independence issues back to the application developer, but I'm not
sure this is unreasonable. Python has a tradition of exposing platform
differences (look at modules like curses, pty, _winreg, etc for
examples), so it's ann acceptable course for a library that strives to
be "Pythonic".

The minimal widget set (button, label, edit box) is common across all
platforms, so minimal applications will be fine. People writing larger
applications needing more complex UI elements need to know how to
address the differences, so a certain level of conditional code is OK.

And people (like me!) who only want to target one platform can use the
full range of widgets, and to heck with portability :-)

But it's still difficult, and you'll never please everyone.

> I suspect that attempting to support too many platforms
> is one of the things that led to anygui's demise.

And equally, to wxPython's size (to an extent).

Paul.

From greg.ewing at canterbury.ac.nz  Tue May  2 14:10:36 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 03 May 2006 00:10:36 +1200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <20060501184213.6775.JCARLSON@uci.edu>
References: <20060501150146.6771.JCARLSON@uci.edu>
	<06May1.172822pdt.58641@synergy1.parc.xerox.com>
	<20060501184213.6775.JCARLSON@uci.edu>
Message-ID: <44574C3C.5030000@canterbury.ac.nz>

Josiah Carlson wrote:

> Technically speaking, any toolkit which allows for scrolling and the
> laying out of controls in a grid would be sufficient to implement this

Although for large grids it could be prohibitively
inefficient. You really want to implement this kind
of thing in a way that doesn't require materialising
an actual widget for every cell.

I'm going to look into what Cocoa and Gtk provide
in the way of table widgets at some point.

--
Greg

From greg.ewing at canterbury.ac.nz  Tue May  2 14:19:16 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 03 May 2006 00:19:16 +1200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06May1.141031pdt.58641@synergy1.parc.xerox.com>
References: <06May1.141031pdt.58641@synergy1.parc.xerox.com>
Message-ID: <44574E44.1080707@canterbury.ac.nz>

Bill Janssen wrote:

> The Tk canvas widget is a nice one,

I've never been fond of things like the Tkinter canvas that
come with their own data structure. Usually I already have
a data structure of my own, and all I want is a place to
draw it.

> I'm still not quite sure what the PyGUI "canvas" is;

It's a destination for immediate-mode output-only drawing
with Postscript-like primitives. It's much simpler than
a Tkinter canvas -- more like an X11 drawable or a
Windows device context.

--
Greg

From stefan.rank at ofai.at  Tue May  2 14:20:44 2006
From: stefan.rank at ofai.at (Stefan Rank)
Date: Tue, 02 May 2006 14:20:44 +0200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <091301c66dc7$60e5cbf0$8d472597@bagio>
References: <1146512221.5679.55.camel@fsol>	<06May1.133531pdt."58641"@synergy1.parc.xerox.com>
	<091301c66dc7$60e5cbf0$8d472597@bagio>
Message-ID: <44574E9C.4040405@ofai.at>

on 02.05.2006 11:04 Giovanni Bajo said the following:
> Bill Janssen <janssen at parc.com> wrote:
>>> In wxWidgets, the GUI system is able to calculate the minimal size
>>> needed by each and any widget, and to prevent the user from resizing
>>> the window below the calculated minimal size. =
>> I'm not sure that this is effectively possible in all cases, but the
>> "set_bounds" method on Container could probably be extended to
>> optionally do this.
> 
> It has to be automatic. The *default* way to construct a widget must be so that
> (if it's resizeable) ...

I agree that a limit on minimal size needs to be automatic, but the () 
tripped a (recently renewed) nerve of mine about a design error that 
applies to a lot of gui toolkits out there.
So, in case a standard gui for python might be 
chosen/implemented/wrapped, here is a

<rant>
There is absolutely no sensible reason at all, for a gui frame to be of 
a fixed size!
None.
More precisely: the concept of a maximum size (except screen limits) for 
a frame is asking for user dissatisfaction.
'Users aller L?nder, vereinigt euch!' Clamour for resizability.
</rant>

sorry


From greg.ewing at canterbury.ac.nz  Tue May  2 14:33:42 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 03 May 2006 00:33:42 +1200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06May1.133531pdt.58641@synergy1.parc.xerox.com>
References: <06May1.133531pdt.58641@synergy1.parc.xerox.com>
Message-ID: <445751A6.9050001@canterbury.ac.nz>

Bill Janssen wrote:

> > In wxWidgets, the GUI system is able to calculate the minimal size
> > needed by each and any widget, and to prevent the user from resizing the
> > window below the calculated minimal size. =
> 
> I'm not sure that this is effectively possible in all cases, but the
> "set_bounds" method on Container could probably be extended to
> optionally do this.

I'll probably provide minimum and maximum window size settings
at some point (it should be easy enough to do). I'm not sure yet
how automatic I should try to make it. I'll have to think about
that in the wider context of layout calculation, which currently
is not quite as automatic as it is in some other GUI toolkits,
and takes a rather different approach from many of them.

> > - tab-key navigation (navigating among controls by using Tab and
> > Shift-Tab) should be handled automatically. Right now it seems you have
> > to manually define "groups" for tab-key navigation to work.
> 
> Seems to work automatically on my test case.  I put up three text
> fields and can tab between them automatically.

PyGUI *should* automatically handle tabbing between text fields
and other controls that you normally type text into. It doesn't
currently go in for tabbing into buttons and check boxes, which
has always seemed silly and annoying to me. I might reconsider
this if it's really what's expected on certain platforms, though.

--
Greg

From rasky at develer.com  Tue May  2 14:40:47 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Tue, 2 May 2006 14:40:47 +0200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
References: <1146512221.5679.55.camel@fsol>
	<06May1.133531pdt.58641@synergy1.parc.xerox.com>
	<091301c66dc7$60e5cbf0$8d472597@bagio>
	<44574B09.6030802@canterbury.ac.nz>
Message-ID: <00d701c66de5$a2e47f60$bf03030a@trilan>

Greg Ewing wrote:

>>> I can see the accessibility
>>> argument, but it is basically asking for the ability to drive an
>>> interface designed for use with a pointing device, without using a
>>> pointing device.  I'm not sure this is a reasonable constraint.
>>
>> It is. Every GUI toolkit has this, every GUI program people use in
>> the world have this feature.
>
> Not every system goes about providing it the same way, though.
> This business of putting & in front of letters is a Windows-ism
> that Linux seems to have become infected with. MacOSX has a quite
> different approach that doesn't require the application author to
> do anything special at all -- it's a system feature there, not
> an application feature.
>
> I'll have to think further about what this means for PyGUI.

I'd be fine with a system for abstracting the issue so that it becomes
"automatic" (with a few constraints: I still need to be able to specify a
specific letter for a specific item). What I'm worried about is the attitude
"you don't really need this feature" I read in this thread. A GUI toolkit
should be neutral towards what's "best" to do with a GUI, and expose to the
user all the features that are commonly found in today's GUIs.

>> No, it should be a standard component because it's used by almost
>> any non-toy application, and it's mad to require that every
>> application reinvent the wheel.
>
> But it's not clear what a status bar would *do* other than
> being a container for other components. Can you elaborate?

By itself, I don't expect a status bar to be a special control. In other
words, I *am* minimalist in implementation design. But I expect a GUI
toolkit to provide a StatusBar "wrapper" filled with handy features (that
you *can* obtain by yourself by rewriting the same class, but that's not the
point):

- Ability to display a message, which can be either permanent or timed
(after a few seconds, it disappears)
- Ability to have a size grip in its bottom-right corner (assuming PyGUI has
a SizeGrip class, which it should grow anyway).
- Ability to add custom widgets which are automatically right-aligned and
arranged within the status bar

See also: http://doc.trolltech.com/4.1/qstatusbar.html


>> Every serious GUI toolkit has a statusbar.
>
> Cocoa doesn't. (It has something called an NSStatusBar,
> but it doesn't do what what you're talking about.)

I believe Aqua does, though (but I might be wrong).
-- 
Giovanni Bajo


From greg.ewing at canterbury.ac.nz  Tue May  2 14:49:43 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 03 May 2006 00:49:43 +1200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <e35fgf$v7h$1@sea.gmane.org>
References: <20060501090813.8y05zi9jhpq88kw4@login.werra.lunarpages.com>
	<06May1.095920pdt.58641@synergy1.parc.xerox.com>
	<e35fgf$v7h$1@sea.gmane.org>
Message-ID: <44575567.1010906@canterbury.ac.nz>

Fredrik Lundh wrote:

> I don't think PyGUI is good enough for a standard API; it feels way too
> much "MFC era" for my tastes.

Can you elaborate on what MFC-like characterstics
it has that you don't like? I'm open to suggestions
for improvement.

--
Greg

From skip at pobox.com  Tue May  2 14:51:57 2006
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 2 May 2006 07:51:57 -0500
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <06May1.173317pdt."58641"@synergy1.parc.xerox.com>
References: <17494.27837.334590.99512@montanaro.dyndns.org>
	<06May1.173317pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <17495.21997.69778.965990@montanaro.dyndns.org>


    Bill> I think a PyGUI mailing list would be a good thing, Skip.  And a
    Bill> bug-tracker.  And a CVS repository.

    Bill> I disagree, though, about this discussion being too detailed for
    Bill> this list.  This is exactly the kind of discussion we need on this
    Bill> list -- what are we going to do to fix the biggest outstanding
    Bill> problem with Python 2?  Discussions about what to name specific
    Bill> properties might be more appropriate elsewhere -- seems like
    Bill> python-dev likes those kinds of discussions :-).

On this list I think we can concluded whether or not Python 3 needs a
standard GUI toolkit.  The technical discussions about what form PyGUI takes
to be that candidate (whether keyboard shortcuts should be introduced with
"&" or "_", what functionality belongs in a canvas widget, etc) belong on a
PyGUI-specific list.  Someone arriving on the scene in a couple months won't
know that substantial technical discussion took place here.  Once he does
realize that, he's going to have to wade through archives full of other
Python 3-related stuff to get to the PyGUI-related stuff.  People discussing
other things about Python 3 aren't going to want PyGUI technical discussions
mixed in with discussions about extensions to argument passing.

Skip

From birchb at tpg.com.au  Tue May  2 14:55:00 2006
From: birchb at tpg.com.au (Bill Birch)
Date: Tue, 2 May 2006 22:55:00 +1000
Subject: [Python-3000] Metaclass syntax?
In-Reply-To: <ca471dc20605010736h38f51d1dqc9860a6b621c1767@mail.gmail.com>
References: <200605012050.08254.birchb@tpg.com.au>
	<4455E9B5.3040006@canterbury.ac.nz>
	<ca471dc20605010736h38f51d1dqc9860a6b621c1767@mail.gmail.com>
Message-ID: <200605022255.00725.birchb@tpg.com.au>

On Tue, 2 May 2006 12:36 am, Guido van Rossum wrote:
> This has usually been solved by creating a non-meta class whose only
> purpose is to introduce the new metaclass. You'd write
>
> class TheLarch(KindsOfTrees, deciduous): ...
>
> and the metaclass would be called KindsOfTreesMeta.
>
> (Of course you could come up with a different naming convention.)
>
Sorry, but the reader has nothing to indicate that TheLarch is a different 
_kind_ of class. It's no fair! Too much magic. It's hard to "recognize 
different types of class from quite a long way away" with this. ;-)

KindsOfTrees is a bad example of a meta-class. A better
example is a metaclass which behaves very differently from
normal classes. Consider a metaclass which does not allow methods: 

----------------------struct.py--------------------------
   class StructMeta 
      ... 
   class Struct:
      __metaclass__ = StructMeta
      ...
 -------------------------snip-----------------------------
   from struct import * 
   class Person(Struct):
   
To someone reading the second file this reads "Person inherits from struct". 
Which of course it does not, because Struct is a devious hook to pull
in a different metaclass. What if StructMeta does not allow 
inheritance?

The syntax should flag to the reader "this class is
potentially weird and does not follow the usual rules".
Putting the metaclass in a special place in the statement
makes it really obvious to the reader:

   class[StructMeta] Person:

or even use the UML stereotype syntax:

   class<<StructMeta>> Person:

How could you miss the meta-class, it's obvious!

With this syntax you could eliminate the odd-looking:

    class Address:
    """ nice big multi-line comment 
        nice big multi-line comment
        nice big multi-line comment """
        __metaclass__ = StructMeta           # see, I'm hiding!
        ...

(see : http://orangecow.org/pythonet/sketches/larch.htm)

er, that's it.
-- 
http://billbirch.wordpress.com/

From phd at mail2.phd.pp.ru  Tue May  2 15:40:07 2006
From: phd at mail2.phd.pp.ru (Oleg Broytmann)
Date: Tue, 2 May 2006 17:40:07 +0400
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <445751A6.9050001@canterbury.ac.nz>
References: <06May1.133531pdt.58641@synergy1.parc.xerox.com>
	<445751A6.9050001@canterbury.ac.nz>
Message-ID: <20060502134007.GB8543@phd.pp.ru>

On Wed, May 03, 2006 at 12:33:42AM +1200, Greg Ewing wrote:
> PyGUI *should* automatically handle tabbing between text fields
> and other controls that you normally type text into. It doesn't
> currently go in for tabbing into buttons and check boxes, which
> has always seemed silly and annoying to me. I might reconsider
> this if it's really what's expected on certain platforms, though.

   "Tab to a text_edit - enter text - tab to a checkbox - check it with a
space - tab to a Search button - press it with a space"

   instead of

   "Move a hand to the mouse - move mouse to the text_edit - click to focus
- move the hand to the keyboard - enter text - move the hand to the mouse -
move the mouse to the checkbox - click to check - move the mouse to the
Search button - click to submit"

   I am one of those mouse-haters, and I use keyboard as much as possible.
All platforms allow me to do it with keyboard shortcuts, default buttons
and tabs over all widgets.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From guido at python.org  Tue May  2 16:36:18 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 07:36:18 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <loom.20060502T073849-533@post.gmane.org>
References: <loom.20060502T073849-533@post.gmane.org>
Message-ID: <ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>

On 5/1/06, Talin <talin at acm.org> wrote:
> Given that strings are going to be unicode, will there be a "characters"
> data type to go along with the "bytes" data type?

No. I'm not sure what you mean by "characters" but the only characters
that Python will support are Unicode characters. Python's 'str' and
'bytes' will be like String and byte[] in Java. But there won't be a
separate "char" type to represent the elements of 'str' -- like
before, a 1-char string will server nicely to represent a "character".
And a byte is represented by a Python int -- there won't be a separate
int-ish type constrained to range(0, 256).

> And how is the bytes
> data type different from the existing array type?

That remains to be seen. I expect it'll be rather similar but it's
focused on bytes only; the array type supports a number of other C
data types. The array type may even disappear -- I don't consider it a
big success. Maybe some part of a NumPy cor ewill finally be ready for
inclusion.

Josiah claims that bytes is similar to a list and array('B'). Since
the array type already supports many list methods (more than bytes
ATM!) I'm not sure what he's after. It's more likely that bytes will
evolve to be more like str, growing methods like startswith().

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

From guido at python.org  Tue May  2 16:51:19 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 07:51:19 -0700
Subject: [Python-3000] Requiring () around lambda's argument list
In-Reply-To: <20060502045407.83l4jnxdn4hwcg4c@login.werra.lunarpages.com>
References: <20060502045407.83l4jnxdn4hwcg4c@login.werra.lunarpages.com>
Message-ID: <ca471dc20605020751u6c6643bcrc464e41cde3bc1dc@mail.gmail.com>

On 5/2/06, Michael Chermside <mcherm at mcherm.com> wrote:
> Thomas Wouters writes:
> > Lambda-lovers will probably jump all over me for suggesting
> > this, and I doubt you'll go fir it, but what about just not
> > allowing type annotations in lambda statements? They're
> > neutered anyway.
>
> Speaking as a lambda user... +1... Great Idea Thomas! Lambdas are
> for tiny anonymous functions... if you feel the need to specify the
> types, why not go ahead and include a function name and perhaps
> even a docstring -- use def instead.

Fine with me -- this is in fact the solution I was going to prototype.
But in the long run I expect the difference is going to grate.
Later...

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

From guido at python.org  Tue May  2 16:55:35 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 07:55:35 -0700
Subject: [Python-3000] Metaclass syntax?
In-Reply-To: <200605022255.00725.birchb@tpg.com.au>
References: <200605012050.08254.birchb@tpg.com.au>
	<4455E9B5.3040006@canterbury.ac.nz>
	<ca471dc20605010736h38f51d1dqc9860a6b621c1767@mail.gmail.com>
	<200605022255.00725.birchb@tpg.com.au>
Message-ID: <ca471dc20605020755l4fc72da1w1a3d661728dd3748@mail.gmail.com>

On 5/2/06, Bill Birch <birchb at tpg.com.au> wrote:
> On Tue, 2 May 2006 12:36 am, Guido van Rossum wrote:
> > This has usually been solved by creating a non-meta class whose only
> > purpose is to introduce the new metaclass. You'd write
> >
> > class TheLarch(KindsOfTrees, deciduous): ...
> >
> > and the metaclass would be called KindsOfTreesMeta.
> >
> > (Of course you could come up with a different naming convention.)
> >
> Sorry, but the reader has nothing to indicate that TheLarch is a different
> _kind_ of class. It's no fair! Too much magic. It's hard to "recognize
> different types of class from quite a long way away" with this. ;-)

Too bad (you're new to Python right?). The metaclass is inherited
anyway, so this is not a new issure, and in practice it's not a
problem -- you can usually tell from what the base class is, or from
naming conventions, etc.

> KindsOfTrees is a bad example of a meta-class. A better
> example is a metaclass which behaves very differently from
> normal classes. Consider a metaclass which does not allow methods:
>
> ----------------------struct.py--------------------------
>    class StructMeta
>       ...
>    class Struct:
>       __metaclass__ = StructMeta
>       ...
>  -------------------------snip-----------------------------
>    from struct import *
>    class Person(Struct):
>
> To someone reading the second file this reads "Person inherits from struct".
> Which of course it does not, because Struct is a devious hook to pull
> in a different metaclass. What if StructMeta does not allow
> inheritance?

Then it'll be a run-time error at class definition time.

This is how metaclasses work; better get used to it. I can't imagine
how painful it would be if the metaclass *weren't* inherited -- lots
of boilerplate all over.

Please research the history of metaclasses in Python (and in general)
before making your next post.

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

From jonathan-lists at cleverdevil.org  Tue May  2 17:24:15 2006
From: jonathan-lists at cleverdevil.org (Jonathan LaCour)
Date: Tue, 2 May 2006 11:24:15 -0400
Subject: [Python-3000] Metaclass syntax?
In-Reply-To: <200605022255.00725.birchb@tpg.com.au>
References: <200605012050.08254.birchb@tpg.com.au>
	<4455E9B5.3040006@canterbury.ac.nz>
	<ca471dc20605010736h38f51d1dqc9860a6b621c1767@mail.gmail.com>
	<200605022255.00725.birchb@tpg.com.au>
Message-ID: <F9BD3526-2DC8-4F9B-860A-3E174D108AA3@cleverdevil.org>

Guido van Rossum wrote:
> This has usually been solved by creating a non-meta class whose only
> purpose is to introduce the new metaclass. You'd write
>
> class TheLarch(KindsOfTrees, deciduous): ...
>
> and the metaclass would be called KindsOfTreesMeta.

I think many people find this ugly.  I have a little helper function  
that
I use to make things a little clearer (at least in my eyes).  Of course,
these things are always in the eye of the beholder (as evidenced by the
original message).

     def of_type(metaclass):
         class MetaclassMixin(object):
             __metaclass__ = metaclass
         return MetaclassMixin

... and then I simply use this on my classes when I define them:

     class MyClass(of_type(SomeMetaclass)):
         ...

I find this to be fairly useful, and simple.

--
Jonathan LaCour
http://cleverdevil.org

From jcarlson at uci.edu  Tue May  2 18:26:25 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 02 May 2006 09:26:25 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
References: <loom.20060502T073849-533@post.gmane.org>
	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
Message-ID: <20060502091647.677E.JCARLSON@uci.edu>


"Guido van Rossum" <guido at python.org> wrote:
> Josiah claims that bytes is similar to a list and array('B'). Since
> the array type already supports many list methods (more than bytes
> ATM!) I'm not sure what he's after. It's more likely that bytes will
> evolve to be more like str, growing methods like startswith().

I was just explaining what was currently in the bytes PEP.  There are
other things I would personally like to have in the bytes object (string
methods are almost a requirement, some file-like methods would be
convenient; to replace StringIO, but not necessary), but no one seems to
have replied to my most recent post on the topic.

I also happen to think that the lack of a bytes literal beyond
bytes([1,2,3]), bytes("...", encoding="..."), or "...".encode("..."),
will make some uses a bit cumbersome, as will its mutability (see the
points I've been trying to make in regards to parsing / unmarshalling /
operationX).


 - Josiah


From guido at python.org  Tue May  2 18:44:06 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 09:44:06 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <20060502091647.677E.JCARLSON@uci.edu>
References: <loom.20060502T073849-533@post.gmane.org>
	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
	<20060502091647.677E.JCARLSON@uci.edu>
Message-ID: <ca471dc20605020944y1cf7c325mae639029c4b4d13c@mail.gmail.com>

On 5/2/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "Guido van Rossum" <guido at python.org> wrote:
> > Josiah claims that bytes is similar to a list and array('B'). Since
> > the array type already supports many list methods (more than bytes
> > ATM!) I'm not sure what he's after. It's more likely that bytes will
> > evolve to be more like str, growing methods like startswith().
>
> I was just explaining what was currently in the bytes PEP.

Oops. I lost track of the bytes proto-PEP. CC'ing Neil now -- Neil,
did you submit that to the PEP editors? The bytes object that I
actually implemented is substantially similar to the draft, but
differs in details. (The details will have to change anyway because
the PEP curerntly distinguishes between str and unicode initializers,
which makes no sense for Py3k.) I didn't implement fromhex(), although
it may be a good idea. I didn't implement all the proposed methods yet
(none of the list methods are implemented) and I implemented more
string-ish behavior (e.g. __contains__ implements substring matching
as well as element searching).

> There are
> other things I would personally like to have in the bytes object (string
> methods are almost a requirement, some file-like methods would be
> convenient; to replace StringIO, but not necessary), but no one seems to
> have replied to my most recent post on the topic.

Perhaps because you generate posts faster than most people can read. I
don't have time to reply to every single item on your list; I'd just
recommend that you calm down. (But I want to add that unifying bytes
and StringOI seems a bad idea -- StringIO contains state beyond the
contents of the array and it makes more sense to use a separate object
for that.)

> I also happen to think that the lack of a bytes literal beyond
> bytes([1,2,3]), bytes("...", encoding="..."), or "...".encode("..."),
> will make some uses a bit cumbersome, as will its mutability (see the
> points I've been trying to make in regards to parsing / unmarshalling /
> operationX).

I think it's way too soon to know.

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

From tim.peters at gmail.com  Tue May  2 19:30:14 2006
From: tim.peters at gmail.com (Tim Peters)
Date: Tue, 2 May 2006 13:30:14 -0400
Subject: [Python-3000] bug in modulus?
In-Reply-To: <S7L5g.30013$eR6.27390@bgtnsc04-news.ops.worldnet.att.net>
References: <1145807918.069455.241510@i40g2000cwc.googlegroups.com>
	<4450928c$0$21107$626a54ce@news.free.fr>
	<j3L5g.18187$Fs1.621@bgtnsc05-news.ops.worldnet.att.net>
	<S7L5g.30013$eR6.27390@bgtnsc04-news.ops.worldnet.att.net>
Message-ID: <1f7befae0605021030r458a371fm54f263cfaf9c90cf@mail.gmail.com>

[Andrew Koenig, on the counter intuitive -1e-050 % 2.0 == 2.0 example]
>> I disagree.  For any two floating-point numbers a and b, with b != 0, it
>> is always possible to represent the exact value of a mod b as a
>> floating-point number--at least on every floating-point system I have ever
>> encountered. The implementation is not even that difficult.

[also Andrew]
> Oops... This statement is true for the Fortran definition of modulus (result
> has the sign of the dividend) but not the Python definition (result has the
> sign of the divisor).  In the Python world, it's true only when the dividend
> and divisor have the same sign.

Note that you can have it in Python too, by using math.fmod(a, b)
instead of "a % b".

IMO, it was a mistake (and partly my fault cuz I didn't whine early)
for Python to try to define % the same way for ints and floats.  The
hardware realities are too different, and so are the pragmatics.  For
floats, it's actually most useful most often to have both that a % b
is exact and that 0.0 <= abs(a % b) <= abs(b/2).  Then the sign of a%b
bears no relationship to the signs of a and b, but for purposes of
modular reduction it yields the result with the smallest possible
absolute value.  That's often valuable for floats (e.g., think of
argument reduction feeding into a series expansion, where time to
convergence typically depends on the magnitude of the input and
couldn't care less about the input's sign), but rarely useful for
ints.

I'd like to see this change in Python 3000.  Note that IBM's proposed
standard for decimal arithmetic (which Python's "decimal" module
implements) requires two operations here, one that works like
math.fmod(a, b) (exact and sign of a), and the other as described
above (exact and |a%b| <= |b/2|).  Those are really the only sane
definitions for a floating point modulo/remainder.

From tjreedy at udel.edu  Tue May  2 19:34:01 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 2 May 2006 13:34:01 -0400
Subject: [Python-3000] sets in P3K?
References: <mailman.18736.1146255866.27774.python-3000@python.org>	<Pine.GSO.4.58.0604301605170.18138@qew.cs>	<e336a8$spg$1@sea.gmane.org><44563E8F.8050001@ewtllc.com><ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com>
Message-ID: <e38568$q5$1@sea.gmane.org>


"Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
news:44572190.30007 at gmail.com...
> If you went for a syntactic notation for the empty set, I'd want to use 
> {} and
> make the empty dict {:}, by that idea didn't even make your list of
> alternatives :)

Those are my favorites also.  The 2.x -> 3.0 edit of {} to {:} is trivial 
for an auto-correct function.

tjr




From guido at python.org  Tue May  2 19:42:35 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 10:42:35 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <e38568$q5$1@sea.gmane.org>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<Pine.GSO.4.58.0604301605170.18138@qew.cs>
	<e336a8$spg$1@sea.gmane.org> <44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com> <e38568$q5$1@sea.gmane.org>
Message-ID: <ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>

On 5/2/06, Terry Reedy <tjreedy at udel.edu> wrote:
>
> "Nick Coghlan" <ncoghlan at gmail.com> wrote in message
> news:44572190.30007 at gmail.com...
> > If you went for a syntactic notation for the empty set, I'd want to use
> > {} and
> > make the empty dict {:}, by that idea didn't even make your list of
> > alternatives :)
>
> Those are my favorites also.  The 2.x -> 3.0 edit of {} to {:} is trivial
> for an auto-correct function.

That doesn't fix everybody's brain though. Given that sets are much
less universally useful than dicts I don't think that dict should
"give in".

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

From guido at python.org  Tue May  2 19:47:43 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 10:47:43 -0700
Subject: [Python-3000] bug in modulus?
In-Reply-To: <1f7befae0605021030r458a371fm54f263cfaf9c90cf@mail.gmail.com>
References: <1145807918.069455.241510@i40g2000cwc.googlegroups.com>
	<4450928c$0$21107$626a54ce@news.free.fr>
	<j3L5g.18187$Fs1.621@bgtnsc05-news.ops.worldnet.att.net>
	<S7L5g.30013$eR6.27390@bgtnsc04-news.ops.worldnet.att.net>
	<1f7befae0605021030r458a371fm54f263cfaf9c90cf@mail.gmail.com>
Message-ID: <ca471dc20605021047k3f464422jc1e39825d81a1a17@mail.gmail.com>

This is way above my head. :-)

The only requirement *I* would like to see is that for floats that
exactly represent ints (or longs for that matter) the result ought of
x%y ought to have the same value as the same operation on the
corresponding ints (except if the result can't be represented exactly
as a float -- I don't know what's best then).

We're fixing this for / in Py3k, so passing an int into an algorithm
written for floats won't be harmful and won't require defensiev
float() casting everywhere. It would be a shame if we *introduced* a
new difference between ints and floats for %.

--Guido

On 5/2/06, Tim Peters <tim.peters at gmail.com> wrote:
> [Andrew Koenig, on the counter intuitive -1e-050 % 2.0 == 2.0 example]
> >> I disagree.  For any two floating-point numbers a and b, with b != 0, it
> >> is always possible to represent the exact value of a mod b as a
> >> floating-point number--at least on every floating-point system I have ever
> >> encountered. The implementation is not even that difficult.
>
> [also Andrew]
> > Oops... This statement is true for the Fortran definition of modulus (result
> > has the sign of the dividend) but not the Python definition (result has the
> > sign of the divisor).  In the Python world, it's true only when the dividend
> > and divisor have the same sign.
>
> Note that you can have it in Python too, by using math.fmod(a, b)
> instead of "a % b".
>
> IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> for Python to try to define % the same way for ints and floats.  The
> hardware realities are too different, and so are the pragmatics.  For
> floats, it's actually most useful most often to have both that a % b
> is exact and that 0.0 <= abs(a % b) <= abs(b/2).  Then the sign of a%b
> bears no relationship to the signs of a and b, but for purposes of
> modular reduction it yields the result with the smallest possible
> absolute value.  That's often valuable for floats (e.g., think of
> argument reduction feeding into a series expansion, where time to
> convergence typically depends on the magnitude of the input and
> couldn't care less about the input's sign), but rarely useful for
> ints.
>
> I'd like to see this change in Python 3000.  Note that IBM's proposed
> standard for decimal arithmetic (which Python's "decimal" module
> implements) requires two operations here, one that works like
> math.fmod(a, b) (exact and sign of a), and the other as described
> above (exact and |a%b| <= |b/2|).  Those are really the only sane
> definitions for a floating point modulo/remainder.
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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

From jcarlson at uci.edu  Tue May  2 19:50:57 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 02 May 2006 10:50:57 -0700
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <44574C3C.5030000@canterbury.ac.nz>
References: <20060501184213.6775.JCARLSON@uci.edu>
	<44574C3C.5030000@canterbury.ac.nz>
Message-ID: <20060502093334.6781.JCARLSON@uci.edu>


Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Josiah Carlson wrote:
> 
> > Technically speaking, any toolkit which allows for scrolling and the
> > laying out of controls in a grid would be sufficient to implement this
> 
> Although for large grids it could be prohibitively
> inefficient. You really want to implement this kind
> of thing in a way that doesn't require materialising
> an actual widget for every cell.

One thing that wxPython does is allow for virtual list and grid controls. 
The underlying widgets (for custom renderers) are created on the fly
when they are displayed for non-text entries.  Text entries, I believe,
are drawn directly.

This allows for the demos of the 100 million cell wx.Grid and the 1
million line wx.ListCtrl to be "smooth as butter", as the kids say
(grids being cell-based, lists being row-based).

Anyone who is pushing for any GUI toolkit to make it into Py3k should
bite the bullet, and get wxPython installed on their platform along with
the Demo (a separate download). Wandering through all of the widgets and
their functionality, I believe, will give everyone an idea of how big an
undertaking writing a fully featured GUI toolkit really is.  Certainly
not everything needs be implemented to the extent it is in wxWidgets or
wxPython, but there are literally dozens of widgets that people would be
disappointed if they couldn't have.


 - Josiah


From jimjjewett at gmail.com  Tue May  2 19:52:42 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 2 May 2006 13:52:42 -0400
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <-5480590561903733423@unknownmsgid>
References: <1146512221.5679.55.camel@fsol> <-5480590561903733423@unknownmsgid>
Message-ID: <fb6fbf560605021052h10f211a3r7945e656ad150a36@mail.gmail.com>

Many of these issues have already been discussed -- and solved -- in a
web context, if you look at the w3c.org accessibility documents.

On 5/1/06, Bill Janssen <janssen at parc.com> wrote:

> > You cannot assign a global key shortcut to every command,
> > while you can assign a local hotkey to any menu item.

> ....  I can see the accessibility
> argument, but it is basically asking for the ability to drive an
> interface designed for use with a pointing device, without using a
> pointing device.

Exactly.

Only a tiny fraction of GUI applications (let alone applications which
happen to be coded with a GUI) actually require a pointing device for
functionality.  In practice, many require it anyway because of lazy
coding.  A standard library should support and encourage *best*
practices.

> > In wxWidgets, the GUI system is able to calculate the minimal size
> > needed by each and any widget, and to prevent the user from resizing the
> > window below the calculated minimal size.

Bad idea.

The app may get ugly or require scrolling below a certain size, but it
should still work.

I've seen too many applications that can't be used because some
critical piece (usually "OK") is off the bottom of my screen, and the
application can't be resized.  (In the worst case, when I actually had
to use it, I reset my screen resolution to
unreadably-small-for-most-things, reboot, and then start over.)

> Automatic determination of a tabbing order is not an exact science,
> though.  I've used a number of apps that get it wrong.  I could see
> having no default as a reasonable decision.

Using even a bizarre order is still better than not offering the
navigation at all.

-jJ

From jimjjewett at gmail.com  Tue May  2 20:03:02 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 2 May 2006 14:03:02 -0400
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <445751A6.9050001@canterbury.ac.nz>
References: <06May1.133531pdt.58641@synergy1.parc.xerox.com>
	<445751A6.9050001@canterbury.ac.nz>
Message-ID: <fb6fbf560605021103lbef9d22o125decdcfc85806c@mail.gmail.com>

On 5/2/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> PyGUI *should* automatically handle tabbing between text fields
> and other controls that you normally type text into. It doesn't
> currently go in for tabbing into buttons and check boxes, which
> has always seemed silly and annoying to me. I might reconsider
> this if it's really what's expected on certain platforms, though.

As a general accessibility issue, there should be some way to reach
and modify all controls.  (Skipping panels and labels is fine, but
skipping buttons and checkboxes can be a problem.  Consider an install
dialogue, where you have to check a box before the Next button becomes
active.)

That said, there is nothing wrong with an express navigation mode that
does skip them, or even with binding <tab> to that express mode by
default.  The catch is that if what you do is too far from the norm,
people will never learn your conventions, and they end up being less
useful in practice.

-jJ

From talin at acm.org  Tue May  2 20:18:44 2006
From: talin at acm.org (Talin)
Date: Tue, 2 May 2006 18:18:44 +0000 (UTC)
Subject: [Python-3000] Requirements for a standard GUI library
Message-ID: <loom.20060502T201105-105@post.gmane.org>

I'm afraid I'm going to have to blow the dust off of one of my pet 
rants, this one concerning the design and implementation of GUI toolkits.

As someone who is familiar with about 20 different GUI toolkits (not 
including the half dozen or so that I've created for various projects), 
I've formed a number of fairly strong opinions about them.

The first think you notice about GUI APIs is that, well, there's a lot 
of them. It seems that this is one of those areas that programmers just 
like to play in.

(I like to say that "whenever a programmer gets the urge to create their 
own programming language, the first thing they should do is lie down on 
the couch until the feeling passes." [Sadly, I don't remember the source 
of this quote.] The same advice could be given to writers of user 
interface systems.)

Another thing that I notice is that a lot of the APIs out seem to have 
been created using the following process:

   1) Start with a programmer who has never used a really good GUI API,
      but who has lots of experience with one or more of the really bad
      APIs such as Motif, Win32, xtk, and so on.

   2) Working within that paradigm, make heroic attempts to clean up
      and improve the API, without actually ever questioning the
      whole architectural approach of what they learned.

The result is a design that appears to its designer (and anyone else 
familiar with the original, badly-designed API) as a fantastic leap 
forward, but doesn't look so great when compared against a really 
top-notch API.

To avoid starting a potential flamewar, I will refrain from stating my 
own personal opinions as to the quality of specific GUI toolkits out 
there. I will, however, list what I believe are the qualities that make 
an API great:

  - It should follow the UI conventions of the specific platform that 
it is running on. Ideally, the user should not be able to tell that this 
is not a native-written application. This includes not only widget 
appearance, but subtle details of spacing, focus, selection, tab 
navigation, and so on.

  - If there are platform-specific features that are not available on
all platforms, it should attempt to fill the gaps with custom code
that brings the various platforms up to the same standard.

  - It should leverage the standard modal dialogs for that platform - 
color picker, font picker, file open dialog, etc. If, for some reason, 
the platform's implementation is deemed inadequate, the replacement 
should be a superset. (For example, when using the file open dialog in 
OS X, I rely a lot on the ability to be able to type the first couple 
letters of a file name to scroll down to that file in the list; having a 
program which creates its own file open dialog, but doesn't support this 
feature, annoys me greatly.)

  - It should support the accessibility features of the host platform, 
including things like mouse wheel scrolling, special keyboard modes, and 
so on. Most times this can be supported fairly easily by using native 
widgets wrapped in a platform-neutral API.

  - It should support a rich set of widget types. The standard set of 
GUI widgets (including more exotic types such as combo boxes, tree 
views, grids, etc.) is essentially a visual language which has evolved 
over time. Users expect certain kinds of data to be presented in certain 
ways; To say that elements such as combo boxes are unecessary is like 
saying that keyboards don't really need a 'q' key.

  Of course, one can claim that the purpose of the toolkit is to 
intentionally diverge from the standard, so as to faciliate evolution of 
the visual language; This is a laudable goal, but such a toolkit should 
be labeled "experimental", and should not claim to be part of a standard 
library.

  - The toolkit should support tooltips (if that is standard for the 
platform), drag and drop (ditto), and the system clipboard. For extra 
credit, floating tool palettes and dockable toolbars are very handy to have.

  - The toolkit must have a clean system for distributing and handling 
event notifications. This is an area where many toolkits fail to measure 
up. Event notification should be simple, yet there should be a powerful 
delegation model (I believe the terms "capture" and "bubble" to describe 
various strategies of message delegation are coming into vogue) that 
allows for notifications to be inherited, messages distributed based on 
the current focus state, and so on.

  Remember that every UI (including the web) is essentially an event 
sieve hooked to a display system; At least 50% of the job of the UI is 
to classify incoming user events and transform them into higher-level 
application events.

  It is also a plus if the event system is debugger-transparent, which 
is to say that it should be possible to display events in the debugger 
and make some sense out of them. Being able to add a generic event 
tracing function, either on a per-widget basis or globally, is also 
quite useful.

  Also, it should be possible to separate the UI from the application, 
in a classic "Model View Controller" architecture. Ideally, you should 
be able to drive the underlying application from a variety of 
interfaces, ranging from a GUI to a command shell.

  - It should support one or more forms of dynamic layout. The simplest 
type of layout is the AWT style "top-down" layout, in which each parent 
determines the size and shape of its children, subject to the childrens' 
minimum size constraints. A more sophisticated, two-pass "bottom-up" 
layout system (I think that XUL supports something like this) allows the 
children to influence the size and shape of the parent.

  Ideally, the dynamic layout should be user-extensible, so that new 
layout policies can be added.

  - It should support data-driven creation of UIs. Personally, I am in 
favor of XML-based formats, simply because I like to be able to tweak 
the files by hand occasionally. I'm also into machine-generated UIs, but 
that's another story. However, there are many other viable alternatives
besides XML.

  Conversely, it should also support purely procedural creation of UIs. 
I've seen some toolkits that only allowed UIs to be loaded from a file.

Finally, I would say that anyone attempting to create a GUI toolkit
should be familiar with a variety of the standard GUI APIs out there.
I would suggest that familiarity with Qt, XUL, and either Java/Swing
or .Net/Windows.Forms (I prefer the latter, but it's a matter of
taste) would give enough breadth of experience to begin to approach
the problem.

-- Talin



From tomerfiliba at gmail.com  Tue May  2 20:26:42 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Tue, 2 May 2006 20:26:42 +0200
Subject: [Python-3000] new sockets: code sample
Message-ID: <1d85506f0605021126v73039a28jbe12e5ad8ee0aad0@mail.gmail.com>

i've written a code sample of how i think the new socket module should look.
it's only a *prototype*, but i find code is easier to explain than abstract
ideas.

i guess that if it is desired, it should be rewritten in C, or at least
work with "_socket" instead of "socket". and like GvR said, the exceptions
should be reworked.

as i said in my last (huge) post, since sockets are more complex objects
than files, and not are applicable for the "Stream protocol", they should
be kept as different entities than the new streaming IO stack.

anyway, here's the code, examples are at the bottom.


#------------------------------------------------------------------------------
import socket as _socket


class SocketError(IOError):
    pass


# could have been a metaclass, but i don't like metaclasses
def make_option_property(level, option):
    def getter(self):
        return self._sock.getsockopt(level, option)
    def setter(self, value):
        return self._sock.setsockopt(level, option, value)
    return property(getter, setter)


#------------------------------------------------------------------------------
# protocol layer mix-ins. they all inherit from object, so as not to
# create a complex class hierarchy (their are only mixins)
#------------------------------------------------------------------------------
class IpLayerMixin(object):
    """ip-specific interface"""
    ttl = make_option_property(_socket.SOL_IP, _socket.IP_TTL)
    tos = make_option_property(_socket.SOL_IP, _socket.IP_TOS)
    options = make_option_property(_socket.SOL_IP, _socket.IP_OPTIONS)
    multicast_ttl = make_option_property(_socket.SOL_IP,
_socket.IP_MULTICAST_TTL)
    multicast_loop = make_option_property(_socket.SOL_IP,
_socket.IP_MULTICAST_LOOP)
    multicast_if = make_option_property(_socket.SOL_IP, _socket.IP_MULTICAST_IF)

    has_ipv6 = _socket.has_ipv6


class TcpLayerMixin(object):
    """tcp-specific interface"""
    nodelay = make_option_property(_socket.SOL_TCP, _socket.TCP_NODELAY)


#------------------------------------------------------------------------------
# Sockets
#------------------------------------------------------------------------------
class Socket(object):
    """base socket"""
    def __init__(self, familty, type, protocol):
        self._sock = _socket.socket(familty, type, protocol)

    @classmethod
    def wrap(cls, sock):
        obj = cls.__new__(cls)
        obj._sock = sock
        return obj

    def close(self):
        self._sock.close()
    def fileno(self):
        return self._sock.fileno()

    def _get_sockname(self):
        return self._sock.getsockname()
    socketinfo = property(_get_sockname)

    def _get_blocking(self):
        return self._sock.gettimeout() == None
    def _set_blocking(self, value):
        self._sock.setblocking(bool(value))
    blocking = property(_get_blocking, _set_blocking)

    def _get_timeout(self):
        return self._sock.gettimeout()
    def _set_timeout(self, value):
        self._sock.settimeout(value)
    timeout = property(_get_timeout, _set_timeout, doc =
        "the timeout in seconds (float). for infinite timeout, set to None")

    def shutdown(self, mode):
        if mode == "r":
            self._sock.shutdown(_socket.SHUT_RD)
        elif mode == "w":
            self._sock.shutdown(_socket.SHUT_WR)
        elif mode == "rw":
            self._sock.shutdown(_socket.SHUT_RDWR)
        else:
            raise ValueError("mode can be 'r', 'w', or 'rw'")

    use_loopback = make_option_property(_socket.SOL_SOCKET,
_socket.SO_USELOOPBACK)
    allow_broadcast = make_option_property(_socket.SOL_SOCKET,
_socket.SO_BROADCAST)
    exclusive_address = make_option_property(_socket.SOL_SOCKET,
_socket.SO_EXCLUSIVEADDRUSE)
    use_keepalives = make_option_property(_socket.SOL_SOCKET,
_socket.SO_KEEPALIVE)
    reuse_address = make_option_property(_socket.SOL_SOCKET,
_socket.SO_REUSEADDR)
    dont_route = make_option_property(_socket.SOL_SOCKET, _socket.SO_DONTROUTE)


#------------------------------------------------------------------------------
# connection-oriented sockets
#------------------------------------------------------------------------------
class ServerSocket(Socket):
    """represents server sockets (bind to local address, waiting to accept)"""
    def __init__(self, familty, type, protocol, local_endpoint = None,
backlog = 1):
        Socket.__init__(self, familty, type, protocol)
        self._is_bound = False
        self._backlog = backlog
        if local_endpoint is not None:
            self.bind(local_endpoint)

    def _get_backlog(self):
        return self._backlog
    def _set_backlog(self, value):
        self._sock.listen(value)
        self._backlog = value
    backlog = property(_get_backlog, _set_backlog)

    def bind(self, local_endpoint):
        self._sock.bind(local_endpoint)
        self._sock.listen(self.backlog)
        self._is_bound = True

    def accept(self):
        if not self._is_bound:
            raise SocketError("socket is not bound")
        newsock, addrinfo = self._sock.accept()
        return newsock


class ClientSocket(Socket):
    """
    represents client sockets (connected to server).
    this is the type sockets that NetworkStream works over.
    """
    def __init__(self, familty, type, protocol, remote_endpoint):
        Socket.__init__(self, familty, type, protocol)
        self._sock.connect(remote_endpoint)

    def _get_peername(self):
        return self._sock.getpeername()
    peerinfo = property(_get_peername)

    def recv(self, count):
        try:
            data = self._sock.recv(count)
        except _socket.timeout:
            return ""
        if not data:
            return EOFError
        return data

    def send(self, data):
        return self._sock.send(data)

#------------------------------------------------------------------------------
# connection-less sockets
#------------------------------------------------------------------------------
class DatagramSocket(Socket):
    """datagram sockets"""

    def bind(self, endpoint):
        self._sock.bind(endpoint)
    def send(self, data, addr):
        return self._sock.sendto(data, addr)
    def recv(self, count):
        try:
            return self._sock.recvfrom(count)
        except _socket.timeout:
            return "", None


class RawSocket(Socket):
    """i don't know enough about raw sockets to define their interface"""
    pass


#------------------------------------------------------------------------------
# protocol-specific sockets
#------------------------------------------------------------------------------
class TcpClientSocket(ClientSocket, IpLayerMixin, TcpLayerMixin):
    def __init__(self, *args, **kwargs):
        ClientSocket.__init__(self, _socket.AF_INET, _socket.SOCK_STREAM,
        _socket.IPPROTO_TCP, *args, **kwargs)


class TcpServerSocket(ServerSocket, IpLayerMixin, TcpLayerMixin):
    def __init__(self, *args, **kwargs):
        ServerSocket.__init__(self, _socket.AF_INET, _socket.SOCK_STREAM,
        _socket.IPPROTO_TCP, *args, **kwargs)
    def accept(self):
        return TcpClientSocket.wrap( ServerSocket.accept(self) )


class UdpSocket(DatagramSocket, IpLayerMixin):
    def __init__(self, *args, **kwargs):
        DatagramSocket.__init__(self, _socket.AF_INET, _socket.SOCK_DGRAM,
        _socket.IPPROTO_UDP, *args, **kwargs)


#------------------------------------------------------------------------------
# a little client demo
#------------------------------------------------------------------------------
import Socket

s = Socket.TcpClientSocket(("localhost", 12345))
s.nodelay = True
s.send("hello")
s.recv(100)
s.close()


#------------------------------------------------------------------------------
# a little server demo
#------------------------------------------------------------------------------
import Socket

s = Socket.TcpServerSocket(("", 12345))
s2 = s.accept()

s2.recv(100)
s2.send("blah")
s2.close()

#------------------------------------------------------------------------------

only ClientSockets are applicable for streams. server sockets, datagram
sockets, etc., are all irrelevant. again, the streaming IO stack is a
separate entity than sockets, but they can be integrated as
shown below:

stream = NetworkStream(some_client_socket)

for example:

# client
s = Socket.TcpClientSocket(("localhost", 12345))
s = FramingCodec(NetworkStream(s))

# server
s = Socket.TcpServerSocket(("", 12345))
s2 = FramingCodec(NetworkStream(s.accept()))

# 's' is a server socket, but s.accept returns a ClientSocket




-tomer

From gvwilson at cs.utoronto.ca  Tue May  2 20:47:06 2006
From: gvwilson at cs.utoronto.ca (Greg Wilson)
Date: Tue, 2 May 2006 14:47:06 -0400 (EDT)
Subject: [Python-3000] sets in P3K?
In-Reply-To: <mailman.19555.1146593980.27774.python-3000@python.org>
References: <mailman.19555.1146593980.27774.python-3000@python.org>
Message-ID: <Pine.GSO.4.58.0605021444550.14067@dvp.cs>

> Terry Reedy:
> Those are my favorites also.  The 2.x -> 3.0 edit of {} to {:} is trivial
> for an auto-correct function.

> Guido Who Needs No Surname:
> That doesn't fix everybody's brain though. Given that sets are much less
> universally useful than dicts I don't think that dict should "give in".

Greg:
I think {:} is more consistent/mnemonic than {} for empty dictionaries
even without sets.

From rhettinger at ewtllc.com  Tue May  2 21:05:06 2006
From: rhettinger at ewtllc.com (Raymond Hettinger)
Date: Tue, 02 May 2006 12:05:06 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>	<Pine.GSO.4.58.0604301605170.18138@qew.cs>	<e336a8$spg$1@sea.gmane.org>
	<44563E8F.8050001@ewtllc.com>	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>	<44572190.30007@gmail.com>
	<e38568$q5$1@sea.gmane.org>
	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
Message-ID: <4457AD62.4060003@ewtllc.com>


>That doesn't fix everybody's brain though. Given that sets are much
>less universally useful than dicts I don't think that dict should
>"give in".
>
>
>  
>
Right. Changes to the {} notation for empty dicts should be off the 
table lest we have a lifetime of regrets.  Set literals are not worth 
committing atrocities elsewhere in the language.

I think Guido had the best solution.  Use set() for empty sets, use {} 
for empty dicts, use {genexp} for set comprehensions/displays, use 
{1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict 
literals.  We can always add {/} later if demand exceeds distaste.

Also, FWIW, I think the current dict constructor is fine as-is.  No 
doubt that its API is fully-loaded, but it is very useful and not hard 
to learn.  Practicality wins here.



Raymond







From mccollum at fas.harvard.edu  Tue May  2 21:04:55 2006
From: mccollum at fas.harvard.edu (Andrew McCollum)
Date: Tue, 2 May 2006 15:04:55 -0400
Subject: [Python-3000] sets in P3K?
In-Reply-To: <Pine.GSO.4.58.0605021444550.14067@dvp.cs>
Message-ID: <200605021904.k42J4odY031831@us25.unix.fas.harvard.edu>

> Greg Wilson wrote:
> I think {:} is more consistent/mnemonic than {} for empty dictionaries
> even without sets.

What makes "{:}" so intuitive and consistent?  To me, it makes no sense,
because ':' is the key/value separator and so why should I need it if there
are no items?  To me, it looks like some bizarre form of the slicing syntax.

It only seems to make sense in the presence of sets, and then purely as a
way to resolve ambiguity.  My feeling is that "{:}" for the empty dict is no
more consistent or meaningful than "{/}" for the empty set, maybe less so.


From g.brandl at gmx.net  Tue May  2 21:21:13 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 02 May 2006 21:21:13 +0200
Subject: [Python-3000] sets in P3K?
In-Reply-To: <4457AD62.4060003@ewtllc.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>	<Pine.GSO.4.58.0604301605170.18138@qew.cs>	<e336a8$spg$1@sea.gmane.org>	<44563E8F.8050001@ewtllc.com>	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>	<44572190.30007@gmail.com>	<e38568$q5$1@sea.gmane.org>	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
	<4457AD62.4060003@ewtllc.com>
Message-ID: <e38bf9$oba$1@sea.gmane.org>

Raymond Hettinger wrote:
>>That doesn't fix everybody's brain though. Given that sets are much
>>less universally useful than dicts I don't think that dict should
>>"give in".
>>
>>
>>  
>>
> Right. Changes to the {} notation for empty dicts should be off the 
> table lest we have a lifetime of regrets.  Set literals are not worth 
> committing atrocities elsewhere in the language.
> 
> I think Guido had the best solution.  Use set() for empty sets, use {} 
> for empty dicts, use {genexp} for set comprehensions/displays, use 
> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict 
> literals.  We can always add {/} later if demand exceeds distaste.

+1.

Georg


From barry at python.org  Tue May  2 21:56:56 2006
From: barry at python.org (Barry Warsaw)
Date: Tue, 02 May 2006 15:56:56 -0400
Subject: [Python-3000] sets in P3K?
In-Reply-To: <4457AD62.4060003@ewtllc.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<Pine.GSO.4.58.0604301605170.18138@qew.cs>	<e336a8$spg$1@sea.gmane.org>
	<44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com> <e38568$q5$1@sea.gmane.org>
	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
	<4457AD62.4060003@ewtllc.com>
Message-ID: <1146599816.2268.107.camel@resist.wooz.org>

On Tue, 2006-05-02 at 12:05 -0700, Raymond Hettinger wrote:

> I think Guido had the best solution.  Use set() for empty sets, use {} 
> for empty dicts, use {genexp} for set comprehensions/displays, use 
> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict 
> literals.  We can always add {/} later if demand exceeds distaste.

+1

> Also, FWIW, I think the current dict constructor is fine as-is.  No 
> doubt that its API is fully-loaded, but it is very useful and not hard 
> to learn.  Practicality wins here.

+1

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-3000/attachments/20060502/803ac398/attachment.pgp 

From guido at python.org  Tue May  2 22:12:13 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 13:12:13 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <1146599816.2268.107.camel@resist.wooz.org>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<Pine.GSO.4.58.0604301605170.18138@qew.cs>
	<e336a8$spg$1@sea.gmane.org> <44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com> <e38568$q5$1@sea.gmane.org>
	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
	<4457AD62.4060003@ewtllc.com>
	<1146599816.2268.107.camel@resist.wooz.org>
Message-ID: <ca471dc20605021312x1a7b331p668f77cbe4e0a3ff@mail.gmail.com>

Looks like we're converging on consensus about this issue. Perhaps
someone can attempt an implementation in the p3yk (sic) branch? I'll
add a line to PEP 3100; I don't see that a whole new PEP is necessary
to summarize the discussion here.

--Guido

On 5/2/06, Barry Warsaw <barry at python.org> wrote:
> On Tue, 2006-05-02 at 12:05 -0700, Raymond Hettinger wrote:
>
> > I think Guido had the best solution.  Use set() for empty sets, use {}
> > for empty dicts, use {genexp} for set comprehensions/displays, use
> > {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
> > literals.  We can always add {/} later if demand exceeds distaste.
>
> +1
>
> > Also, FWIW, I think the current dict constructor is fine as-is.  No
> > doubt that its API is fully-loaded, but it is very useful and not hard
> > to learn.  Practicality wins here.
>
> +1
>
> -Barry
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iQCVAwUARFe5iHEjvBPtnXfVAQJuGAQAt3aYlqDY1kMa7oA3ZMQ0+2xeIhqJ47nX
> 7hp5HQK9o8qkvRRfaukjiH199QWOZ5WZzeM6UyjmlTRY2LPdDv6yrEMvJ26fK2rm
> x66KdFgYGtPPgxYzHyWZoMVHrmNdy2hYn4sYMDn57Wb1rDl4SwSSynBgQkd9P1O3
> butl4fUAEN8=
> =OKIh
> -----END PGP SIGNATURE-----
>
>
>


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

From mike.klaas at gmail.com  Tue May  2 22:16:50 2006
From: mike.klaas at gmail.com (Mike Klaas)
Date: Tue, 2 May 2006 13:16:50 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <ca471dc20605021312x1a7b331p668f77cbe4e0a3ff@mail.gmail.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<e336a8$spg$1@sea.gmane.org> <44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com> <e38568$q5$1@sea.gmane.org>
	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
	<4457AD62.4060003@ewtllc.com>
	<1146599816.2268.107.camel@resist.wooz.org>
	<ca471dc20605021312x1a7b331p668f77cbe4e0a3ff@mail.gmail.com>
Message-ID: <3d2ce8cb0605021316q43a712a4yb050d965df2430c6@mail.gmail.com>

On 5/2/06, Guido van Rossum <guido at python.org> wrote:
> Looks like we're converging on consensus about this issue. Perhaps
> someone can attempt an implementation in the p3yk (sic) branch? I'll
> add a line to PEP 3100; I don't see that a whole new PEP is necessary
> to summarize the discussion here.

Are there backward incompatabilities which would prevent this going into 2.x?

cheers,
-Mike

From guido at python.org  Tue May  2 22:32:04 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 13:32:04 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <3d2ce8cb0605021316q43a712a4yb050d965df2430c6@mail.gmail.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com> <e38568$q5$1@sea.gmane.org>
	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
	<4457AD62.4060003@ewtllc.com>
	<1146599816.2268.107.camel@resist.wooz.org>
	<ca471dc20605021312x1a7b331p668f77cbe4e0a3ff@mail.gmail.com>
	<3d2ce8cb0605021316q43a712a4yb050d965df2430c6@mail.gmail.com>
Message-ID: <ca471dc20605021332n7f84f51cj224dc35b29e266dc@mail.gmail.com>

On 5/2/06, Mike Klaas <mike.klaas at gmail.com> wrote:
> On 5/2/06, Guido van Rossum <guido at python.org> wrote:
> > Looks like we're converging on consensus about this issue. Perhaps
> > someone can attempt an implementation in the p3yk (sic) branch? I'll
> > add a line to PEP 3100; I don't see that a whole new PEP is necessary
> > to summarize the discussion here.
>
> Are there backward incompatabilities which would prevent this going into 2.x?

No. I think it's too late for 2.5; it's a significant amount of
coding, documentation, etc. So I propose to add it to the 3.0 branch
first; if people really like it it can be added to 2.6.

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

From tjreedy at udel.edu  Tue May  2 22:40:37 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 2 May 2006 16:40:37 -0400
Subject: [Python-3000] Requirements for a standard GUI library
References: <loom.20060502T201105-105@post.gmane.org>
Message-ID: <e38g44$bfb$1@sea.gmane.org>


"Talin" <talin at acm.org> wrote in message 
news:loom.20060502T201105-105 at post.gmane.org...
> there. I will, however, list what I believe are the qualities that make
> an API great:
>
>  - It should follow the UI conventions of the specific platform that
> it is running on. Ideally, the user should not be able to tell that this
> is not a native-written application. This includes not only widget
> appearance, but subtle details of spacing, focus, selection, tab
> navigation, and so on.

Let me add some a couple of complementary wishes aimed especially but not 
exclusively at game and media programs:

-the ability to ignore platforn standards and give an app a unique look and 
feel.  A start on this, for instance, is being able to give dialog boxes a 
custom background instead of uniform gray or whatever.  (Note: there was a 
project on SF, PyUI, I believe, aimed at game programmers, which made a 
start but foundered otherwise.)

-the ability to shift to full-screen mode.  Besides many games, many 
picture and movies players can do this.  So can MS Internet Explorer.

Terry Jan Reedy




From talin at acm.org  Tue May  2 23:22:47 2006
From: talin at acm.org (Talin)
Date: Tue, 2 May 2006 21:22:47 +0000 (UTC)
Subject: [Python-3000] characters data type
References: <loom.20060502T073849-533@post.gmane.org>
	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
Message-ID: <loom.20060502T230526-773@post.gmane.org>

Guido van Rossum <guido <at> python.org> writes:

> On 5/1/06, Talin <talin <at> acm.org> wrote:
> > Given that strings are going to be unicode, will there be a "characters"
> > data type to go along with the "bytes" data type?
> 
> No. I'm not sure what you mean by "characters" but the only characters
> that Python will support are Unicode characters. Python's 'str' and
> 'bytes' will be like String and byte[] in Java. But there won't be a
> separate "char" type to represent the elements of 'str' -- like
> before, a 1-char string will server nicely to represent a "character".
> And a byte is represented by a Python int -- there won't be a separate
> int-ish type constrained to range(0, 256).

It appears that my question has been misunderstood by everyone; I'll try
to phrase it better:

The short version is: will there be a mutable character array type? (which
I am calling "characters"?)

First, I do use array, not a lot but I do use it occasionally. One common
use case is equivalent to the Java StringBuffer class - that is, a means
for building up strings a character at a time, which otherwise would be
expensive to do with immutable strings.

Now, from the discussion of "bytes" I get the impression that it, too, is
a mutable type (someone said 'like list'). So given that 'characters' (i.e.
unicode characters) are now distinct from 'bytes', it makes sense to me to
declare a mutable character array. And to me, the most natural name for
such a type is 'characters', although I suppose you could also call it
"stringbuffer" or something.

BTW, is the internal encoding of unicode strings UTF-8, UTF-16, UCS-2, or
UTF-32? Just wondering...

-- Talin



From guido at python.org  Tue May  2 23:47:07 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 14:47:07 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <loom.20060502T230526-773@post.gmane.org>
References: <loom.20060502T073849-533@post.gmane.org>
	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
	<loom.20060502T230526-773@post.gmane.org>
Message-ID: <ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>

On 5/2/06, Talin <talin at acm.org> wrote:
> It appears that my question has been misunderstood by everyone; I'll try
> to phrase it better:
>
> The short version is: will there be a mutable character array type? (which
> I am calling "characters"?)

There are no plans for this AFAIK.

> First, I do use array, not a lot but I do use it occasionally. One common
> use case is equivalent to the Java StringBuffer class - that is, a means
> for building up strings a character at a time, which otherwise would be
> expensive to do with immutable strings.

Better ways to do this might be [c]StringIO (in theory -- I don't know
if it's fast enough in practice, but this should be easy to test) or
the standard "".join(<list of strings>) approach (which underlies
StringIO's implementation as well -- though not cStringIO's IIRC).

> Now, from the discussion of "bytes" I get the impression that it, too, is
> a mutable type (someone said 'like list').

Correct. (You have no excuse to guess -- the implementation is in the
p3yk (sic) branch.)

> So given that 'characters' (i.e.
> unicode characters) are now distinct from 'bytes', it makes sense to me to
> declare a mutable character array. And to me, the most natural name for
> such a type is 'characters', although I suppose you could also call it
> "stringbuffer" or something.

I'm not sure that we need this. I'm not 100% sure we don't either, but
I believe that the existing approach works pretty well -- it's hard to
beat the "".join(<list>) approach.

> BTW, is the internal encoding of unicode strings UTF-8, UTF-16, UCS-2, or
> UTF-32? Just wondering...

Again, please look at the implementation. It's an array of shortish
ints; whether these are 2 or 3 or 4 bytes long depends on config
constants. (Just kidding about the 3 bytes version. :-) I think that
makes it UTF-16 or UTF-32. There is some support for surrogates when 2
bytes are used so I believe that excludes UCS-2.

Note that UTF-8 would make the implementation of Python's typical
string API painful; we currently assume (because it's true ;-) that
random access to elements and slices (__getitem__ and __getslice__) is
O(1). With UTF-8 these operations would be slow -- the simplest
implementation would require counting characters from the start; one
can speed this up with some kind of cache or tree but IMO the
array-of-fixed-width-characters approach is much simpler. (I had a bad
experience in my youth with strings implemented as trees, so I'm
biased against complicated string implementations. This also explains
why I'm no fan of the oft-proposed idea that slices should avoid
making physical copies even if they make logical copies -- the
complexity of that approach horrifies me.)

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

From jimjjewett at gmail.com  Wed May  3 00:14:42 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 2 May 2006 18:14:42 -0400
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <20060502093334.6781.JCARLSON@uci.edu>
References: <20060501184213.6775.JCARLSON@uci.edu>
	<44574C3C.5030000@canterbury.ac.nz>
	<20060502093334.6781.JCARLSON@uci.edu>
Message-ID: <fb6fbf560605021514l12450e71r548418727c23fbc8@mail.gmail.com>

On 5/2/06, Josiah Carlson <jcarlson at uci.edu> wrote:

> Anyone who is pushing for any GUI toolkit to make it into Py3k ...
> Wandering through all of the widgets ... fully featured GUI toolkit really is.

> ... not everything needs be implemented to the extent it is in wxWidgets or
> wxPython, but there are literally dozens of widgets that people would be
> disappointed if they couldn't have.

They can, by installing wxPython.  How long would it take to
understand wxpython?  My gut feel is "longer than it took to
understand Python", which makes it pretty heavyweight.

Python's no-new-features rule means that the stdlib is the wrong place
for a does-everything library.  Instead, it should stick to a
good-enough-for-simple-use library, and explicitly refer people to 3rd
party libraries.

-jJ

From talin at acm.org  Wed May  3 00:20:51 2006
From: talin at acm.org (Talin)
Date: Tue, 2 May 2006 22:20:51 +0000 (UTC)
Subject: [Python-3000] characters data type
References: <loom.20060502T073849-533@post.gmane.org>
	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
	<loom.20060502T230526-773@post.gmane.org>
	<ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
Message-ID: <loom.20060503T000621-941@post.gmane.org>

Guido van Rossum <guido <at> python.org> writes:

> On 5/2/06, Talin <talin <at> acm.org> wrote:
> > It appears that my question has been misunderstood by everyone; I'll try
> > to phrase it better:
> >
> > The short version is: will there be a mutable character array type? (which
> > I am calling "characters"?)
> 
> There are no plans for this AFAIK.
> 
> > First, I do use array, not a lot but I do use it occasionally. One common
> > use case is equivalent to the Java StringBuffer class - that is, a means
> > for building up strings a character at a time, which otherwise would be
> > expensive to do with immutable strings.
> 
> Better ways to do this might be [c]StringIO (in theory -- I don't know
> if it's fast enough in practice, but this should be easy to test) or
> the standard "".join(<list of strings>) approach (which underlies
> StringIO's implementation as well -- though not cStringIO's IIRC).

As to whether or not flat arrays are a win over a stream-based interface,
I think it really depends on how well the array type supports incremental
growth. I'm mostly familiar with the behavior of STL arrays, which (for
small array sizes) doubles whenever the array runs out of room. The result
is that for an array of size N, built up 1 character at a time, you will
have at most log2(N) memory allocations, and less if you set the initial
capacity of the array to a reasonable guess.

> > Now, from the discussion of "bytes" I get the impression that it, too, is
> > a mutable type (someone said 'like list').
> 
> Correct. (You have no excuse to guess -- the implementation is in the
> p3yk (sic) branch.)
> 
> > So given that 'characters' (i.e.
> > unicode characters) are now distinct from 'bytes', it makes sense to me to
> > declare a mutable character array. And to me, the most natural name for
> > such a type is 'characters', although I suppose you could also call it
> > "stringbuffer" or something.
> 
> I'm not sure that we need this. I'm not 100% sure we don't either, but
> I believe that the existing approach works pretty well -- it's hard to
> beat the "".join(<list>) approach.

The reason that I asked about this was that my current 'toy' implementation
of the string formatting PEP (which I posted on this list earlier) uses
character arrays.

> > BTW, is the internal encoding of unicode strings UTF-8, UTF-16, UCS-2, or
> > UTF-32? Just wondering...
> 
> Again, please look at the implementation. It's an array of shortish
> ints; whether these are 2 or 3 or 4 bytes long depends on config
> constants. (Just kidding about the 3 bytes version.  I think that
> makes it UTF-16 or UTF-32. There is some support for surrogates when 2
> bytes are used so I believe that excludes UCS-2.
>
> Note that UTF-8 would make the implementation of Python's typical
> string API painful; we currently assume (because it's true  that
> random access to elements and slices (__getitem__ and __getslice__) is
> O(1). With UTF-8 these operations would be slow -- the simplest
> implementation would require counting characters from the start; one
> can speed this up with some kind of cache or tree but IMO the
> array-of-fixed-width-characters approach is much simpler. (I had a bad
> experience in my youth with strings implemented as trees, so I'm
> biased against complicated string implementations. This also explains
> why I'm no fan of the oft-proposed idea that slices should avoid
> making physical copies even if they make logical copies -- the
> complexity of that approach horrifies me.)

Although if you are supporting surrogates, then __getitem__ and __getslice__
won't be O(1), will they? That's why I asked about UCS-2, which is what I
use in my work -- which is another way of saying that we've punted on the
issue of surrogates.

-- Talin



From tdelaney at avaya.com  Wed May  3 00:34:29 2006
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Wed, 3 May 2006 08:34:29 +1000
Subject: [Python-3000] Requiring () around lambda's argument list
Message-ID: <2773CAC687FD5F4689F526998C7E4E5FF1E6B4@au3010avexu1.global.avaya.com>

Guido van Rossum wrote:

>> Thomas Wouters writes:
>>> Lambda-lovers will probably jump all over me for suggesting
>>> this, and I doubt you'll go fir it, but what about just not
>>> allowing type annotations in lambda statements? They're
>>> neutered anyway.

[snip Michael Chermside ;)]

> Fine with me -- this is in fact the solution I was going to prototype.
> But in the long run I expect the difference is going to grate.
> Later...

About the only time I use lambda is (as Michael said) for tiny anonymous
functions that are going to be used immediately. Generally I don't care
what the types of the arguments are - the types of the lambda arguments
should be whatever is passed into them. I'm sure as hell not going to do
any validation in the lambda!

So I'd definitely be +1 on not allowing type annotations on lambda.

Tim Delaney

From tdelaney at avaya.com  Wed May  3 00:39:38 2006
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Wed, 3 May 2006 08:39:38 +1000
Subject: [Python-3000] Metaclass syntax?
Message-ID: <2773CAC687FD5F4689F526998C7E4E5FF1E6B5@au3010avexu1.global.avaya.com>

Jonathan LaCour wrote:

> Guido van Rossum wrote:
>> This has usually been solved by creating a non-meta class whose only
>> purpose is to introduce the new metaclass. You'd write
>> 
>> class TheLarch(KindsOfTrees, deciduous): ...
>> 
>> and the metaclass would be called KindsOfTreesMeta.
> 
>      def of_type(metaclass):
>          class MetaclassMixin(object):
>              __metaclass__ = metaclass
>          return MetaclassMixin
> 
> ... and then I simply use this on my classes when I define them:
> 
>      class MyClass(of_type(SomeMetaclass)):

"of_type" doesn't really work for me - why not just name it "metaclass"?

    def metaclass(meta):
        class MetaclassMixin(object):
            __metaclass__ = metaclass
        return MetaclassMixin

    class MyClass(metaclass(SomeMetaclass)):
        pass

Off the top of my head, I can't see any reason this wouldn't work in the
case of multiple compatible metaclasses (due to inheritance).

Tim Delaney

From jimjjewett at gmail.com  Wed May  3 00:44:57 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 2 May 2006 18:44:57 -0400
Subject: [Python-3000] Requiring () around lambda's argument list
In-Reply-To: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>
References: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>
Message-ID: <fb6fbf560605021544q4044e928r353b8d780fe280f9@mail.gmail.com>

On 5/1/06, Guido van Rossum <guido at python.org> wrote:
>... I'm settled on the following syntax for adding optional annotations

>   def foo(arg1name: typeexpr = defaultexpr, arg2: typeexpr =
> defaultexpr, ...): ...

Did you also decide that the annotations will have no effect by
themselves, and will rely on, for example, a decorator?...

>   lambda arg1name : ...

If something is worth decorating, it is worth naming.

If you even need to *document* restrictions on the argument (beyond
what you can get easily from the name or context), then the function
is a little too fancy for a lambda.

-jJ

From arigo at tunes.org  Wed May  3 00:11:47 2006
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 3 May 2006 00:11:47 +0200
Subject: [Python-3000] [pypy-dev] Signature PEP
In-Reply-To: <5b0248170605020002o154555chc48deb1377970ce3@mail.gmail.com>
References: <5b0248170605020002o154555chc48deb1377970ce3@mail.gmail.com>
Message-ID: <20060502221146.GB7698@code0.codespeak.net>

Hi Seo,

On Tue, May 02, 2006 at 04:02:46PM +0900, Sanghyeon Seo wrote:
> What do you think about this Signature PEP?
> http://mail.python.org/pipermail/python-3000/2006-April/001249.html

It's a language design issue so it's off topic :-)

More seriously, sure, it would be nice to have some kind of standard.
Here, and in many similar code-manipulation places in PyPy, we had to
hack together our own minimal solution.  A harder problem along these
lines would be a better way to build pieces of code, in order to create
functions from scratch.  \n-joining together source lines full of %s,
avoiding name clashes, and getting the indentation right, is not fun.


A bientot,

Armin

From solipsis at pitrou.net  Wed May  3 00:51:18 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 03 May 2006 00:51:18 +0200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <fb6fbf560605021514l12450e71r548418727c23fbc8@mail.gmail.com>
References: <20060501184213.6775.JCARLSON@uci.edu>
	<44574C3C.5030000@canterbury.ac.nz>
	<20060502093334.6781.JCARLSON@uci.edu>
	<fb6fbf560605021514l12450e71r548418727c23fbc8@mail.gmail.com>
Message-ID: <1146610278.5848.9.camel@fsol>


Le mardi 02 mai 2006 ? 18:14 -0400, Jim Jewett a ?crit :
> They can, by installing wxPython.  How long would it take to
> understand wxpython?  My gut feel is "longer than it took to
> understand Python", which makes it pretty heavyweight.

Understanding wxPython in itself is not difficult (a tool like wxGlade
makes it even easier). It's the API that is annoying to use (numeric
ID's all the place, for example).

> Python's no-new-features rule means that the stdlib is the wrong place
> for a does-everything library.  Instead, it should stick to a
> good-enough-for-simple-use library, and explicitly refer people to 3rd
> party libraries.

But you cannot mix two GUI libraries together.
If the developer has started using the good-enough-for-simple-use
library, once he has a need that is not covered by this library, he is
stuck and must rewrite the application with another, more complete
library. Such a rewriting is painful, because different GUI libraries
have different architecture and programming models (most GUI libraries
are actually frameworks: they heavily constrain the way you write your
application).

Including a simplistic GUI library in the stdlib is really *not* helpful
to developers, it can even be deceptive.

(by the way, +1 to Talin's expectations for a GUI system:
standardization of look and feel is very important)

Regards

Antoine.



From guido at python.org  Wed May  3 01:42:52 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 16:42:52 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <loom.20060503T000621-941@post.gmane.org>
References: <loom.20060502T073849-533@post.gmane.org>
	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
	<loom.20060502T230526-773@post.gmane.org>
	<ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
	<loom.20060503T000621-941@post.gmane.org>
Message-ID: <ca471dc20605021642leb6d19kfa68175b428c9102@mail.gmail.com>

On 5/2/06, Talin <talin at acm.org> wrote:
> As to whether or not flat arrays are a win over a stream-based interface,
> I think it really depends on how well the array type supports incremental
> growth. I'm mostly familiar with the behavior of STL arrays, which (for
> small array sizes) doubles whenever the array runs out of room. The result
> is that for an array of size N, built up 1 character at a time, you will
> have at most log2(N) memory allocations, and less if you set the initial
> capacity of the array to a reasonable guess.

You should look at list.append in 2.5. It uses a similar O(log N)
approach but doesn't waste up to 50% space for large lists. My plans
would be do something similar for the bytes += implementation.

> The reason that I asked about this was that my current 'toy' implementation
> of the string formatting PEP (which I posted on this list earlier) uses
> character arrays.

Yeah, I was curious why you bothered with making a toy implementation
efficient. :-) You ought to assume that eventually this will be made
efficient; the focus now should be on functionality.

> Although if you are supporting surrogates, then __getitem__ and __getslice__
> won't be O(1), will they? That's why I asked about UCS-2, which is what I
> use in my work -- which is another way of saying that we've punted on the
> issue of surrogates.
There are certain streamwise things (like conversion to/from UTF-8)
that support surrogates, so I would hesitate to call it UCS-2. But
there is no attempt to hide surrogates from __getitem__ or
__getslice__. If you access a code point that's a surrogate, you get a
surrogate. So it's O(1).

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

From guido at python.org  Wed May  3 01:45:51 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 16:45:51 -0700
Subject: [Python-3000] Requiring () around lambda's argument list
In-Reply-To: <fb6fbf560605021544q4044e928r353b8d780fe280f9@mail.gmail.com>
References: <ca471dc20605011339p7bd79515jba48ed442d862513@mail.gmail.com>
	<fb6fbf560605021544q4044e928r353b8d780fe280f9@mail.gmail.com>
Message-ID: <ca471dc20605021645g31580bc5ne1d0839e9d0f1ade@mail.gmail.com>

On 5/2/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 5/1/06, Guido van Rossum <guido at python.org> wrote:
> >... I'm settled on the following syntax for adding optional annotations
>
> >   def foo(arg1name: typeexpr = defaultexpr, arg2: typeexpr =
> > defaultexpr, ...): ...
>
> Did you also decide that the annotations will have no effect by
> themselves, and will rely on, for example, a decorator?...

Right. It doesn't have to be a decorator though -- it could be some
other kind of introspection.

> >   lambda arg1name : ...
>
> If something is worth decorating, it is worth naming.
>
> If you even need to *document* restrictions on the argument (beyond
> what you can get easily from the name or context), then the function
> is a little too fancy for a lambda.

Depends on what you use the annotations for. If you have a framework
that uses annotations to guide some kidn of adaptation machinery, I
could imagine a use for a lambda with an annotation. But I'll happily
say YAGNI...

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

From jcarlson at uci.edu  Wed May  3 07:03:59 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 02 May 2006 22:03:59 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <ca471dc20605020944y1cf7c325mae639029c4b4d13c@mail.gmail.com>
References: <20060502091647.677E.JCARLSON@uci.edu>
	<ca471dc20605020944y1cf7c325mae639029c4b4d13c@mail.gmail.com>
Message-ID: <20060502215314.6787.JCARLSON@uci.edu>


"Guido van Rossum" <guido at python.org> wrote:
> On 5/2/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> > There are
> > other things I would personally like to have in the bytes object (string
> > methods are almost a requirement, some file-like methods would be
> > convenient; to replace StringIO, but not necessary), but no one seems to
> > have replied to my most recent post on the topic.
> 
> Perhaps because you generate posts faster than most people can read. I
> don't have time to reply to every single item on your list; I'd just
> recommend that you calm down. (But I want to add that unifying bytes
> and StringOI seems a bad idea -- StringIO contains state beyond the
> contents of the array and it makes more sense to use a separate object
> for that.)

I assure you, it takes me far longer to write these messages than it
takes to read them.  But it would be nice if *anyone* were to reply with
something, *anything*, even "...I have low hopes for something useful
coming out of this." (my favorite Guido quote, btw) would give me some
perspective to either acknowledge my insanity, or the other thing.


> > I also happen to think that the lack of a bytes literal beyond
> > bytes([1,2,3]), bytes("...", encoding="..."), or "...".encode("..."),
> > will make some uses a bit cumbersome, as will its mutability (see the
> > points I've been trying to make in regards to parsing / unmarshalling /
> > operationX).
> 
> I think it's way too soon to know.

It certainly is too soon to *know*, but based on my own code, I *think*
that not having bytes literals, as well as bytes mutability, will make
more operations cumbersome than not.

One nice thing about bytes actually holding small integers, from the "we
don't want text to be inside of bytes" desire, is that people will have
to jump through hoops to actually print out such text (something like
print "".join(map(chr, bytes)) ).

 - Josiah


From jcarlson at uci.edu  Wed May  3 07:10:01 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 02 May 2006 22:10:01 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
References: <loom.20060502T230526-773@post.gmane.org>
	<ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
Message-ID: <20060502220500.678A.JCARLSON@uci.edu>


"Guido van Rossum" <guido at python.org> wrote:
> Better ways to do this might be [c]StringIO (in theory -- I don't know
> if it's fast enough in practice, but this should be easy to test) or
> the standard "".join(<list of strings>) approach (which underlies
> StringIO's implementation as well -- though not cStringIO's IIRC).

This is one of the reasons why I'm pushing for some string methods on
the bytes object.  Even if bytes resize themselves quickly during
'extension', a single allocation with a single pass copy will be far
faster.  It probably won't be quite as convenient as "".join() (if there
isn't a literal), but keeping the .join method seems to be a winner (if
only because it saves people from having to learn a different method for
unicode and bytes).

 - Josiah


From guido at python.org  Wed May  3 07:27:24 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2006 22:27:24 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <20060502220500.678A.JCARLSON@uci.edu>
References: <loom.20060502T230526-773@post.gmane.org>
	<ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
	<20060502220500.678A.JCARLSON@uci.edu>
Message-ID: <ca471dc20605022227l5893d393sbc778b658c26a4de@mail.gmail.com>

On 5/2/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> This is one of the reasons why I'm pushing for some string methods on
> the bytes object.  Even if bytes resize themselves quickly during
> 'extension', a single allocation with a single pass copy will be far
> faster.  It probably won't be quite as convenient as "".join() (if there
> isn't a literal), but keeping the .join method seems to be a winner (if
> only because it saves people from having to learn a different method for
> unicode and bytes).

I wonder if that's really true. After all you still pay the overhead
for the list. In fact, here's a challenge for you: implement += on
bytes to be as fast as the list append + later join; or prove that it
can't be done.

Regarding your writing vs. my reading speed: (a) I hope you know the
quote about "I apologize for this long letter but I don't have the
time to make it shorter"; (b) I was referring to the discussion
between you and MvL; that was definitely going too fast for anyone
else to read it all. It really isn't necessary to do a point-by-point
reply of everything the other person said. (And I need to heed this
advice myself too!)

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

From nnorwitz at gmail.com  Wed May  3 07:41:03 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 2 May 2006 22:41:03 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <4457AD62.4060003@ewtllc.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<Pine.GSO.4.58.0604301605170.18138@qew.cs>
	<e336a8$spg$1@sea.gmane.org> <44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com> <e38568$q5$1@sea.gmane.org>
	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
	<4457AD62.4060003@ewtllc.com>
Message-ID: <ee2a432c0605022241k2fc41b1icb9a8615199eff98@mail.gmail.com>

On 5/2/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
>
> I think Guido had the best solution.  Use set() for empty sets, use {}
> for empty dicts, use {genexp} for set comprehensions/displays, use
> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
> literals.  We can always add {/} later if demand exceeds distaste.

Presumably {1, 2, 3: 4} would yield a syntax error?

n

From fredrik at pythonware.com  Wed May  3 07:46:15 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 3 May 2006 07:46:15 +0200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
References: <20060501184213.6775.JCARLSON@uci.edu><44574C3C.5030000@canterbury.ac.nz><20060502093334.6781.JCARLSON@uci.edu><fb6fbf560605021514l12450e71r548418727c23fbc8@mail.gmail.com>
	<1146610278.5848.9.camel@fsol>
Message-ID: <e39g38$2v2$1@sea.gmane.org>

Antoine Pitrou wrote:

> Including a simplistic GUI library in the stdlib is really *not* helpful
> to developers, it can even be deceptive.

what makes discussions like these impossible is that everyone is assuming
that their own requirements apply to everyone.

I strongly doubt that the "oh my god, I cannot believe it's not native code"
factor is that important to everyone.

(and for people who really care, using a portable GUI layer is a pretty stupid
thing to do in the first place.  make your widgets portable, use relevant ab-
stractions, and use native bindings for the rest.  it's not that hard, really )

</F>




From fredrik at pythonware.com  Wed May  3 08:47:26 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 3 May 2006 08:47:26 +0200
Subject: [Python-3000] characters data type
References: <loom.20060502T073849-533@post.gmane.org><ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com><loom.20060502T230526-773@post.gmane.org>
	<ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
Message-ID: <e39jlv$bos$1@sea.gmane.org>

Guido van Rossum wrote:

> Note that UTF-8 would make the implementation of Python's typical
> string API painful; we currently assume (because it's true ;-) that
> random access to elements and slices (__getitem__ and __getslice__) is
> O(1). With UTF-8 these operations would be slow -- the simplest
> implementation would require counting characters from the start; one
> can speed this up with some kind of cache or tree but IMO the
> array-of-fixed-width-characters approach is much simpler. (I had a bad
> experience in my youth with strings implemented as trees, so I'm
> biased against complicated string implementations.

I'm still thinking that it might be a good idea to (optionally) delay de-
coding of strings until you're actually doing something that needs access
to the individual characters, though.  (UTF-8 to UTF-8 shuffling is an
increasingly common use case).

(frankly, I wouldn't rule out using an "internally polymorphic" representation
for the new str type, partially motivated by my experiences from cElement-
Tree).

> This also explains why I'm no fan of the oft-proposed idea that slices
> should avoid making physical copies even if they make logical copies --
> the complexity of that approach horrifies me.)

that could also be an optional mechanism for advanced users, but I agree
that it needs a simple implementation.

I think some experimentation is required here (and hope to find some time
for that in a not very distant future).

</F>




From nnorwitz at gmail.com  Wed May  3 09:15:33 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Wed, 3 May 2006 00:15:33 -0700
Subject: [Python-3000] Seeking students for the Summer of Code
Message-ID: <ee2a432c0605030015x3a974b06ke2ecc3b9e23b0ffa@mail.gmail.com>

There is less than a week left before students must submit a final
application.  There are a bunch of ideas up on the wiki:

    http://wiki.python.org/moin/SummerOfCode/

The wiki has instructions for how to submit a proposal.  There are
many different areas including:  core language features, libraries,
and applications. This is a great opportunity to get real coding
experience.  Not to mention the chance to work with a nice and fun
group of people.

The earlier you submit an application, the more feedback you can get
to improve it and increase your liklihood of getting accepted.

Feel free to contact me if you have any questions.

Cheers,
n

From ncoghlan at gmail.com  Wed May  3 12:47:00 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 03 May 2006 20:47:00 +1000
Subject: [Python-3000] characters data type
In-Reply-To: <ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
References: <loom.20060502T073849-533@post.gmane.org>	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>	<loom.20060502T230526-773@post.gmane.org>
	<ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
Message-ID: <44588A24.9020101@gmail.com>

Guido van Rossum wrote:
>  This also explains
> why I'm no fan of the oft-proposed idea that slices should avoid
> making physical copies even if they make logical copies -- the
> complexity of that approach horrifies me.)

FWIW, I've now realised it is possible to create a "seqview" type which 
provides a view of an existing sequence. Slice operations on the seqview would 
also produce views of the original container.

That means implementing a memory-efficient approach on top of containers with 
copy-on-slice semantics isn't as hard as I thought, and only people that care 
about that would have to deal with the complexity.

It also means that I'm starting to think that any dimensioned array type that 
makes it into the standard library should adopt the copy-on-slice approach 
used by the builtin containers. The fancy indexing tricks and the 
avoid-copying-anything-at-all style can be left for the serious number 
crunching libraries like Numpy.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From solipsis at pitrou.net  Wed May  3 13:01:28 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 03 May 2006 13:01:28 +0200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <e39g38$2v2$1@sea.gmane.org>
References: <20060501184213.6775.JCARLSON@uci.edu>
	<44574C3C.5030000@canterbury.ac.nz><20060502093334.6781.JCARLSON@uci.edu>
	<fb6fbf560605021514l12450e71r548418727c23fbc8@mail.gmail.com>
	<1146610278.5848.9.camel@fsol>  <e39g38$2v2$1@sea.gmane.org>
Message-ID: <1146654088.5910.9.camel@fsol>

Le mercredi 03 mai 2006 ? 07:46 +0200, Fredrik Lundh a ?crit :
> Antoine Pitrou wrote:
> 
> > Including a simplistic GUI library in the stdlib is really *not* helpful
> > to developers, it can even be deceptive.
> 
> what makes discussions like these impossible is that everyone is assuming
> that their own requirements apply to everyone.

But it is possible to take a look at a set of applications on several
existing desktops (Gnome, Windows, MaxOSX), and decide that the GUI
techniques which are often used must be supported by the GUI library.

The question of requirements must be answered not only from a
developer's point of view, but from an user's point of view: no only to
facilitate programming of the GUI, but to make a better GUI.
(that was what my expectations list was about, by the way)

> I strongly doubt that the "oh my god, I cannot believe it's not native code"
> factor is that important to everyone.

Native code is much less important than native look and feel indeed ;-)

Regards

Antoine.



From mcherm at mcherm.com  Wed May  3 13:12:22 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Wed, 03 May 2006 04:12:22 -0700
Subject: [Python-3000] characters data type
Message-ID: <20060503041222.3ng5auvf2bdc8ckg@login.werra.lunarpages.com>

Guido writes:
> (I had a bad
> experience in my youth with strings implemented as trees, so I'm
> biased against complicated string implementations. This also explains
> why I'm no fan of the oft-proposed idea that slices should avoid
> making physical copies even if they make logical copies -- the
> complexity of that approach horrifies me.)

No argument here with regard to strings implemented as trees, but I
think you may be needlessly worried about physical vs logical copies
for slices. Since strings (and slices of strings) are immutable, the
implementation is quite simple. Read the Java "String" class to see
just how easy. The slice returns a subclass of str that stores a
start and stop position but redirects data access to the buffer used
by the original str. The only tricky part is to manage garbage
collection, solved by having the slice object contain a reference to
the original str. That's it.

Of course, you knew that, but the fact that I can describe it fully
in 2 sentences should help show it's not overly complex.

-- Michael Chermside


From mcherm at mcherm.com  Wed May  3 13:22:30 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Wed, 03 May 2006 04:22:30 -0700
Subject: [Python-3000] characters data type
Message-ID: <20060503042230.z8cs9je4547404w4@login.werra.lunarpages.com>

Josiah Carlson writes:
> it would be nice if *anyone* were to reply with
> something, *anything*, even "...I have low hopes for something useful
> coming out of this." (my favorite Guido quote, btw) would give me some
> perspective to either acknowledge my insanity, or the other thing.

I think keeping the existing str class (which implements immutable-
sequence-of-bytes) for Py3K but renaming it seems wise. Allowing literals
using b"" seems like an easy win. Since the code is already written
and already has years of real-world testing and optimizations it seems
a shame to throw it out. The only reason I can think of for doing so is
to prevent people from using the bytes type where they ought to be
moving to the new str class (which implements unicode strings). But I
think the name change will be sufficient motivation. None of this has
any bearing on the need for a mutable-sequence-of-bytes implementation.
If stronger hints were needed it could be moved from the core to the
stdlib (but I doubt that would be needed).

However, I'm trusting in Guido (and others) to come to the right
conclusion once they begin working with the code. I'm guessing they'll
encounter a few places where they actually want to convert existing
str code to sequence-of-bytes not to unicode, and then they'll realize
it's worth keeping around our well-tested old str class.

-- Michael Chermside


From mcherm at mcherm.com  Wed May  3 13:29:05 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Wed, 03 May 2006 04:29:05 -0700
Subject: [Python-3000] Requiring () around lambda's argument list
Message-ID: <20060503042905.f91i7r2cktgkwsg8@login.werra.lunarpages.com>

Tim Delaney writes:
> >> Thomas Wouters writes:
> >>> [...] They're
> >>> neutered anyway.

> [snip Michael Chermside ;)]

** Ouch!! **

Squeeky-voicedly yours,

Michael Chermside


From mcherm at mcherm.com  Wed May  3 13:41:58 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Wed, 03 May 2006 04:41:58 -0700
Subject: [Python-3000] bug in modulus?
Message-ID: <20060503044158.c6wxhrx2ygrbgoo0@login.werra.lunarpages.com>

Tim Peters writes:
> IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> for Python to try to define % the same way for ints and floats.
           [...]
> I'd like to see this change in Python 3000.  Note that IBM's proposed
> standard for decimal arithmetic (which Python's "decimal" module
> implements) requires two operations here, one that works like
> math.fmod(a, b) (exact and sign of a), and the other as described
> above (exact and |a%b| <= |b/2|).

Providing both operations is a no-brainer. But only one gets to be
spelled "x % y". Experts will care about sensible behavior of
numerical algorithms... but they're experts, they can use whichever
operation they need. Beginners will care that floats and integers
behave "the same" (okay, that's not actually possible, but beginners
don't know it). So why not make "x % y" for floats behave exactly
like it does for integers and provide a separate operation with your
described behavior?

(Or is that what you were suggesting, and I'm just confused?)

If you're worried about beginners who are implementing numerical
algorithms and hoping to make the language smart enough to "just
work" for them, then I'm afraid it's hopeless. I'm far from a
beginner, but I don't think I could implement a non-trivial
numerical algorithm. (Well, I could make it work, but I'm betting
it would be non-optimal or have corner cases of failure that an
expert could point out.)

-- Michael Chermside


From fredrik at pythonware.com  Wed May  3 13:52:28 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 3 May 2006 13:52:28 +0200
Subject: [Python-3000] characters data type
References: <20060503041222.3ng5auvf2bdc8ckg@login.werra.lunarpages.com>
Message-ID: <e3a5ht$4ls$1@sea.gmane.org>

Michael Chermside wrote:

> No argument here with regard to strings implemented as trees, but I
> think you may be needlessly worried about physical vs logical copies
> for slices. Since strings (and slices of strings) are immutable, the
> implementation is quite simple. Read the Java "String" class to see
> just how easy. The slice returns a subclass of str that stores a
> start and stop position but redirects data access to the buffer used
> by the original str. The only tricky part is to manage garbage
> collection, solved by having the slice object contain a reference to
> the original str. That's it.
>
> Of course, you knew that, but the fact that I can describe it fully
> in 2 sentences should help show it's not overly complex.

you missed the part about slicing slices, and the bit about what heuristics
to use (if any) to use slicing under the hood also for non-explicit slicing
operations (e.g. should s[:-1] really make a copy?  when can s[i] return
a slice?  etc.  some kind of "temporary" indicator provided by the com-
piler would be excellent for under-the-hood optimizations like this...).

(the original Unicode implementation support explicit slicing, and the
code wasn't even fully refactored when that support was removed,
so you may still find traces of this in the existing source code...  most
notably, the Unicode string type still uses a separate block for the
character data)

</F> 




From skip at pobox.com  Wed May  3 13:52:56 2006
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 3 May 2006 06:52:56 -0500
Subject: [Python-3000] bug in modulus?
In-Reply-To: <20060503044158.c6wxhrx2ygrbgoo0@login.werra.lunarpages.com>
References: <20060503044158.c6wxhrx2ygrbgoo0@login.werra.lunarpages.com>
Message-ID: <17496.39320.652859.443575@montanaro.dyndns.org>

    Michael> So why not make "x % y" for floats behave exactly like it does
    Michael> for integers and provide a separate operation with your
    Michael> described behavior?

%% anyone?

(Skip ducks and runs...)

Skip

From fredrik at pythonware.com  Wed May  3 13:57:53 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 3 May 2006 13:57:53 +0200
Subject: [Python-3000] characters data type
References: <20060502091647.677E.JCARLSON@uci.edu><ca471dc20605020944y1cf7c325mae639029c4b4d13c@mail.gmail.com>
	<20060502215314.6787.JCARLSON@uci.edu>
Message-ID: <e3a5s2$5mv$1@sea.gmane.org>

Josiah Carlson wrote:

> I assure you, it takes me far longer to write these messages than it
> takes to read them.

I'm not so sure ;-)

> But it would be nice if *anyone* were to reply with
> something, *anything*, even "...I have low hopes for something useful
> coming out of this." (my favorite Guido quote, btw) would give me some
> perspective to either acknowledge my insanity, or the other thing.

I'm not so sure what it is you want some additional perspective on, but you're
arguing that byte objects should provide all non-text methods provided by to-
day's string type, I fully agree.

</F> 




From solipsis at pitrou.net  Wed May  3 14:29:17 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 03 May 2006 14:29:17 +0200
Subject: [Python-3000] bug in modulus?
Message-ID: <1146659357.5910.31.camel@fsol>


(used the wrong address and first sent it in private to Michael, sorry)


Le mercredi 03 mai 2006 ? 04:41 -0700, Michael Chermside a ?crit :
> Tim Peters writes:
> > IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> > for Python to try to define % the same way for ints and floats.
>            [...]
> > I'd like to see this change in Python 3000.  Note that IBM's proposed
> > standard for decimal arithmetic (which Python's "decimal" module
> > implements) requires two operations here, one that works like
> > math.fmod(a, b) (exact and sign of a), and the other as described
> > above (exact and |a%b| <= |b/2|).
> 
> So why not make "x % y" for floats behave exactly
> like it does for integers

It already does :-)

> and provide a separate operation with your
> described behavior?

A common use case is to transform an angle into its normalized value
between -pi and pi.
So why not define math.normalize:

def normalize(a, b):
    """ Normalize a between -b/2 and b/2. """
    half = b * 0.5
    return (a + half) % b - half

>>> normalize(0.4, 1)
0.40000000000000002
>>> normalize(0.6, 1)
-0.39999999999999991
>>> normalize(1.6, 1)
-0.39999999999999991
>>> normalize(1.4, 1)
0.39999999999999991
>>> normalize(-1.4, 1)
-0.39999999999999991
>>> normalize(-0.6, 1)
0.40000000000000002



From mcherm at mcherm.com  Wed May  3 14:46:32 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Wed, 03 May 2006 05:46:32 -0700
Subject: [Python-3000] characters data type
Message-ID: <20060503054632.j9xvjphw71cgc0go@login.werra.lunarpages.com>

Michael Chermside wrote:
    [on implementing str slices as views]
> > Read the Java "String" class to see
> > just how easy. The slice returns a subclass of str that stores a
> > start and stop position but redirects data access to the buffer used
> > by the original str. The only tricky part is to manage garbage
> > collection, solved by having the slice object contain a reference to
> > the original str.

Fredrik Lundh replies:
> you missed the part about slicing slices

Yes. Sorry. Seemed obvious. Slicing a StringSlice should create a new
StringSlice instance with different start and stop values and another
reference to the original str.

> and the bit about what heuristics
> to use (if any) to use slicing under the hood also for non-explicit
> slicing operations (e.g. should s[:-1] really make a copy? [...] etc.

Um... is there a reason for heuristics? What's wrong with always
returning a StringSlice? (see below for one answer) Having s[i]
return a slice instead of a separate one-character

> when can s[i] return a slice?

Why should it ever? Single-character strings tend to be re-used, and
sharing a buffer will save only a few bytes, so there's little reason
not to return a truly separate string.

>   some kind of "temporary" indicator provided by the com-
piler would be excellent for under-the-hood optimizations like this...).

Why?


Any slice with a stride should NOT try to share buffer, primarily
because we want a simple and efficient implementation. This approach
does suffer from one major problem: it has a tendency to keep around
large strings that could be garbarge collected except that we still
have a reference to some small substring. Clever programmers could
avoid this (eg: use bigString[x:y:1] to avoid keeping the reference),
but it would be a new possible minefield, and (so-called) "memory
leak" for Python programs. I see that as a valid criticism. But I
don't understand why it needs to be complex, and I point to Java's
String class[1] as an existance proof.

-- Michael Chermside


[1] http://www.javaresearch.org/source/jdk142/java/lang/String.java.html
   particularly around line 436.



From antoine at pitrou.net  Wed May  3 14:23:54 2006
From: antoine at pitrou.net (Antoine)
Date: Wed, 03 May 2006 14:23:54 +0200
Subject: [Python-3000] bug in modulus?
Message-ID: <1146659034.5910.27.camel@fsol>


Le mercredi 03 mai 2006 ? 04:41 -0700, Michael Chermside a ?crit :
> Tim Peters writes:
> > IMO, it was a mistake (and partly my fault cuz I didn't whine early)
> > for Python to try to define % the same way for ints and floats.
>            [...]
> > I'd like to see this change in Python 3000.  Note that IBM's proposed
> > standard for decimal arithmetic (which Python's "decimal" module
> > implements) requires two operations here, one that works like
> > math.fmod(a, b) (exact and sign of a), and the other as described
> > above (exact and |a%b| <= |b/2|).
> 
> So why not make "x % y" for floats behave exactly
> like it does for integers

It already does :-)

> and provide a separate operation with your
> described behavior?

A common use case is to transform an angle into its normalized value
between -pi and pi.
So why not define math.normalize:

def normalize(a, b):
    """ Normalize a between -b/2 and b/2. """
    half = b * 0.5
    return (a + half) % b - half

>>> normalize(0.4, 1)
0.40000000000000002
>>> normalize(0.6, 1)
-0.39999999999999991
>>> normalize(1.6, 1)
-0.39999999999999991
>>> normalize(1.4, 1)
0.39999999999999991
>>> normalize(-1.4, 1)
-0.39999999999999991
>>> normalize(-0.6, 1)
0.40000000000000002



From gvwilson at cs.utoronto.ca  Wed May  3 15:22:40 2006
From: gvwilson at cs.utoronto.ca (Greg Wilson)
Date: Wed, 3 May 2006 09:22:40 -0400 (EDT)
Subject: [Python-3000] sets in P3K?
In-Reply-To: <mailman.19569.1146600736.27774.python-3000@python.org>
References: <mailman.19569.1146600736.27774.python-3000@python.org>
Message-ID: <Pine.GSO.4.58.0605030918590.29169@dvp.cs>

> From: Raymond Hettinger <rhettinger at ewtllc.com>
> Set literals are not worth committing atrocities elsewhere in the
> language.

I think "atrocities" is a little strong...

> I think Guido had the best solution.  Use set() for empty sets, use {}
> for empty dicts, use {genexp} for set comprehensions/displays, use
> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
> literals.  We can always add {/} later if demand exceeds distaste.

I obviously haven't done the experiment yet, but I can pretty much
guarantee you that newbies will trip over the inconsistency you're
proposing:

    Type    Two elements        One element        Empty
    List    [1, 2]              [1]                []
    Dict    {1:'a', 2:'b'}      {1:'a'}            {}
    Set     {1, 2}              {1}                set()

One of these things is not like the others...  One of these things just
doesn't belong...  Or is "regular enough that newcomers' guesses about
what to type are usually right" no longer a design consideration?

Thanks,
Greg

From solipsis at pitrou.net  Wed May  3 15:37:14 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 03 May 2006 15:37:14 +0200
Subject: [Python-3000] sets in P3K?
In-Reply-To: <Pine.GSO.4.58.0605030918590.29169@dvp.cs>
References: <mailman.19569.1146600736.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605030918590.29169@dvp.cs>
Message-ID: <1146663434.5910.42.camel@fsol>

Le mercredi 03 mai 2006 ? 09:22 -0400, Greg Wilson a ?crit :
> I obviously haven't done the experiment yet, but I can pretty much
> guarantee you that newbies will trip over the inconsistency you're
> proposing:
> 
>     Type    Two elements        One element        Empty
>     List    [1, 2]              [1]                []
>     Dict    {1:'a', 2:'b'}      {1:'a'}            {}
>     Set     {1, 2}              {1}                set()
> 
> One of these things is not like the others...  One of these things just
> doesn't belong...  Or is "regular enough that newcomers' guesses about
> what to type are usually right" no longer a design consideration?

Something has to be sacrificed anyway, because there is no way to have a
simple and obvious notation for all three types (I do not find {:} or
{/} simple and obvious).

I think lists and dicts are fundamental data types for which there is an
immediate need, whereas sets are an useful optimization, like dequeues
or heaps. Therefore sets are less likely to be used by newcomers.

One symptom of that is that lists and dicts also have syntactic support
in e.g. PHP or Perl, whereas sets don't.



From murman at gmail.com  Wed May  3 15:43:45 2006
From: murman at gmail.com (Michael Urman)
Date: Wed, 3 May 2006 08:43:45 -0500
Subject: [Python-3000] sets in P3K?
In-Reply-To: <Pine.GSO.4.58.0605030918590.29169@dvp.cs>
References: <mailman.19569.1146600736.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605030918590.29169@dvp.cs>
Message-ID: <dcbbbb410605030643t3087bae1o4426a519bfb5bd7a@mail.gmail.com>

On 5/3/06, Greg Wilson <gvwilson at cs.utoronto.ca> wrote:
>     Type    Two elements        One element        Empty
>     List    [1, 2]              [1]                []
>     Dict    {1:'a', 2:'b'}      {1:'a'}            {}
>     Set     {1, 2}              {1}                set()

You left off Tuple, perhaps because it also broke the simple pattern:
      Tuple   1, 2                (1,)               ()

Still I see no reason to repeat the confusion to save one pair of
braces (square or parenthetical). Starting the language over I could
see making {:} and {} the empty dict and set respectively, but not
with the history Python has.

If people are dead set on a set literal, why not look further, to
atrocities like <1,2>, <1>, <>; @{1,2}, @{1}, @{}; {{1,2}}, {{1}},
{{}}; etc.? I know there has been resistance to grouped <> before (not
for sets), but I can't remember why.

Michael
--
Michael Urman  http://www.tortall.net/mu/blog

From mahs at telcopartners.com  Wed May  3 15:59:43 2006
From: mahs at telcopartners.com (Michael Spencer)
Date: Wed, 03 May 2006 06:59:43 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <44588A24.9020101@gmail.com>
References: <loom.20060502T073849-533@post.gmane.org>	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>	<loom.20060502T230526-773@post.gmane.org>	<ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
	<44588A24.9020101@gmail.com>
Message-ID: <e3ad06$1ht$1@sea.gmane.org>

Nick Coghlan wrote:
> Guido van Rossum wrote:
>>  This also explains
>> why I'm no fan of the oft-proposed idea that slices should avoid
>> making physical copies even if they make logical copies -- the
>> complexity of that approach horrifies me.)
> 
> FWIW, I've now realised it is possible to create a "seqview" type which 
> provides a view of an existing sequence. Slice operations on the seqview would 
> also produce views of the original container.
> 
> That means implementing a memory-efficient approach on top of containers with 
> copy-on-slice semantics isn't as hard as I thought, and only people that care 
> about that would have to deal with the complexity.
> 
...
> 
Here, should you wish to experiment, is a pure-python implementation of a 
numpy-ish array that does just that with either list or array.array as the 
underlying sequence:

http://svn.brownspencer.com/pyarray/trunk/

Michael



From andrew-pydev at lexical.org.uk  Wed May  3 16:14:35 2006
From: andrew-pydev at lexical.org.uk (Andrew Walkingshaw)
Date: Wed, 3 May 2006 15:14:35 +0100
Subject: [Python-3000] sets in P3K?
In-Reply-To: <dcbbbb410605030643t3087bae1o4426a519bfb5bd7a@mail.gmail.com>
References: <mailman.19569.1146600736.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605030918590.29169@dvp.cs>
	<dcbbbb410605030643t3087bae1o4426a519bfb5bd7a@mail.gmail.com>
Message-ID: <20060503141435.GA27377@colon.colondot.net>

On Wed, May 03, 2006 at 08:43:45AM -0500, Michael Urman wrote:
> If people are dead set on a set literal, why not look further, to
> atrocities like <1,2>, <1>, <>; @{1,2}, @{1}, @{}; {{1,2}}, {{1}},
> {{}}; etc.? I know there has been resistance to grouped <> before (not
> for sets), but I can't remember why.

(x < y, z > p)  wouldn't be ambiguous, but it'd really freak me out
(and probably syntax highlighters) seeing that in the middle of a block of
source; I'd hallucinate a set which isn't there. At the moment, you don't
have to check the surrounding context to see what < and > mean, which
you would have to if they also had a meaning as group delimiters; I seem
to remember that this would cause parsing problems for the Python
interpreter as well.

Andrew

From aahz at pythoncraft.com  Wed May  3 16:42:13 2006
From: aahz at pythoncraft.com (Aahz)
Date: Wed, 3 May 2006 07:42:13 -0700
Subject: [Python-3000] bug in modulus?
In-Reply-To: <1146659034.5910.27.camel@fsol>
References: <1146659034.5910.27.camel@fsol>
Message-ID: <20060503144213.GA28245@panix.com>

On Wed, May 03, 2006, Antoine wrote:
> Le mercredi 03 mai 2006 ? 04:41 -0700, Michael Chermside a ?crit :
>> Tim Peters writes:
>>>
>>> IMO, it was a mistake (and partly my fault cuz I didn't whine early)
>>> for Python to try to define % the same way for ints and floats.
>>            [...]
>>> I'd like to see this change in Python 3000.  Note that IBM's proposed
>>> standard for decimal arithmetic (which Python's "decimal" module
>>> implements) requires two operations here, one that works like
>>> math.fmod(a, b) (exact and sign of a), and the other as described
>>> above (exact and |a%b| <= |b/2|).
>> 
>> So why not make "x % y" for floats behave exactly
>> like it does for integers
> 
> It already does :-)

Well, yes, but Uncle Timmy is jumping up and down and screaming for a
change.  Granted, I think we should show respect for our numerical
elders, but I think Michael also has a point about the importance of
making floats and ints behave the same, especially given that division
will auto-promote floats from ints.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours."  --Richard Bach

From davidf at sjsoft.com  Wed May  3 16:28:18 2006
From: davidf at sjsoft.com (David Fraser)
Date: Wed, 03 May 2006 16:28:18 +0200
Subject: [Python-3000] [pypy-dev] Signature PEP
In-Reply-To: <20060502221146.GB7698@code0.codespeak.net>
References: <5b0248170605020002o154555chc48deb1377970ce3@mail.gmail.com>
	<20060502221146.GB7698@code0.codespeak.net>
Message-ID: <4458BE02.2010308@sjsoft.com>

Armin Rigo wrote:
> Hi Seo,
>
> On Tue, May 02, 2006 at 04:02:46PM +0900, Sanghyeon Seo wrote:
>   
>> What do you think about this Signature PEP?
>> http://mail.python.org/pipermail/python-3000/2006-April/001249.html
>>     
>
> It's a language design issue so it's off topic :-)
>
> More seriously, sure, it would be nice to have some kind of standard.
> Here, and in many similar code-manipulation places in PyPy, we had to
> hack together our own minimal solution.  A harder problem along these
> lines would be a better way to build pieces of code, in order to create
> functions from scratch.  \n-joining together source lines full of %s,
> avoiding name clashes, and getting the indentation right, is not fun.
>
>   
I had a look a while ago at trying to build Python code using ASTs and 
then compile those, for this very reason.
In the end constructing the source was easier, but in theory this is a 
code-based alternative

Cheers
David

From jimjjewett at gmail.com  Wed May  3 17:41:24 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 3 May 2006 11:41:24 -0400
Subject: [Python-3000] sets in P3K?
In-Reply-To: <ee2a432c0605022241k2fc41b1icb9a8615199eff98@mail.gmail.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<Pine.GSO.4.58.0604301605170.18138@qew.cs>
	<e336a8$spg$1@sea.gmane.org> <44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com> <e38568$q5$1@sea.gmane.org>
	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
	<4457AD62.4060003@ewtllc.com>
	<ee2a432c0605022241k2fc41b1icb9a8615199eff98@mail.gmail.com>
Message-ID: <fb6fbf560605030841g66a9c72blee144e3f132dd5a5@mail.gmail.com>

On 5/2/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:

> I think Guido had the best solution.  Use set() for empty sets, use {}
> for empty dicts, use {genexp} for set comprehensions/displays, use
> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
> literals.  We can always add {/} later if demand exceeds distaste.

I understand {1,2,3} vs {k1:v1, k2:v2}, but what is the {genexp} for?

As I read that, if the generator yielded two-tuples, you would get a
set of two-tuples rather than a dict.  There would be no comprehension
syntax for dicts.

I'm not sure we need a comprehension syntax for dicts, but I'm not
sure we need one for sets either.

    >>> set(gen())

doesn't seem any worse than

    >>> dict(gen())

-jJ

From nas at arctrix.com  Wed May  3 17:41:39 2006
From: nas at arctrix.com (Neil Schemenauer)
Date: Wed, 3 May 2006 09:41:39 -0600
Subject: [Python-3000] characters data type
In-Reply-To: <ca471dc20605020944y1cf7c325mae639029c4b4d13c@mail.gmail.com>
References: <loom.20060502T073849-533@post.gmane.org>
	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
	<20060502091647.677E.JCARLSON@uci.edu>
	<ca471dc20605020944y1cf7c325mae639029c4b4d13c@mail.gmail.com>
Message-ID: <20060503154139.GC4130@mems-exchange.org>

On Tue, May 02, 2006 at 09:44:06AM -0700, Guido van Rossum wrote:
> Oops. I lost track of the bytes proto-PEP. CC'ing Neil now -- Neil,
> did you submit that to the PEP editors?

No, just before I wrote it, you suggested that we didn't need to
contact the editors to add a new PEP to the index (just grab an
unallocated number).  If someone wants to take over the PEP, that
would be great.  I wrote it because I wanted to summarize the
enormous threads on python-dev related to the subject.  If no one
does anything, I will try to make time to get it more up-to-date.

  Neil

From guido at python.org  Wed May  3 18:40:59 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2006 09:40:59 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <e39jlv$bos$1@sea.gmane.org>
References: <loom.20060502T073849-533@post.gmane.org>
	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
	<loom.20060502T230526-773@post.gmane.org>
	<ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
	<e39jlv$bos$1@sea.gmane.org>
Message-ID: <ca471dc20605030940w2123771eh6e5a5d0c64dbc808@mail.gmail.com>

On 5/2/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> I'm still thinking that it might be a good idea to (optionally) delay de-
> coding of strings until you're actually doing something that needs access
> to the individual characters, though.  (UTF-8 to UTF-8 shuffling is an
> increasingly common use case).

This seems a reasonable alternative abstraction that could be built on
top of bytes and (unicode) strings. Are you thinking of a situation
where you know that it's UTF-8? Or are you also thinking of doing this
for arbitrary encodings? Without knowing the encoding it's hard to
know where the boundaries between characters are, which means you
can't do anything that involves splitting the input into chunks, if
later you may attempt to decode a chunk.

There is of course nothing to stop you from copying a UTF-8 file in
binary mode -- but you seem to be after something more. Perhaps you
could elaborate an example, and explain some of your assumptions (e.g.
are you only talking UTF-8)?

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

From jcarlson at uci.edu  Wed May  3 18:45:00 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 03 May 2006 09:45:00 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <ca471dc20605022227l5893d393sbc778b658c26a4de@mail.gmail.com>
References: <20060502220500.678A.JCARLSON@uci.edu>
	<ca471dc20605022227l5893d393sbc778b658c26a4de@mail.gmail.com>
Message-ID: <20060503010744.6790.JCARLSON@uci.edu>


"Guido van Rossum" <guido at python.org> wrote:
> On 5/2/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> > This is one of the reasons why I'm pushing for some string methods on
> > the bytes object.  Even if bytes resize themselves quickly during
> > 'extension', a single allocation with a single pass copy will be far
> > faster.  It probably won't be quite as convenient as "".join() (if there
> > isn't a literal), but keeping the .join method seems to be a winner (if
> > only because it saves people from having to learn a different method for
> > unicode and bytes).
> 
> I wonder if that's really true. After all you still pay the overhead
> for the list. In fact, here's a challenge for you: implement += on
> bytes to be as fast as the list append + later join; or prove that it
> can't be done.

I don't believe it can be done.  See my sample at the end of this
message.  Note that removing the string[:] copy in the list.append
version only reduces the running time by about .07 seconds.


> Regarding your writing vs. my reading speed: (a) I hope you know the
> quote about "I apologize for this long letter but I don't have the
> time to make it shorter"; (b) I was referring to the discussion
> between you and MvL; that was definitely going too fast for anyone
> else to read it all. It really isn't necessary to do a point-by-point
> reply of everything the other person said. (And I need to heed this
> advice myself too!)

Indeed, I don't need to respond to every part in the message.  However,
not responding to a valid concern/criticism seems to me like a
head-in-the-sand approach to disagreements and discussions, which
certainly doesn't help anyone.


 - Josiah

>>> import time
>>> import array
>>>
>>> block = 1024*'\0'
>>> block2 = array.array("B", 1024*[0])
>>> desired_size = 16*1024*1024
>>>
>>> t = time.clock()
>>> for i in xrange(100):
...     l = []
...     for j in xrange(0, desired_size, len(block)):
...         l.append(block[:])
...     l = ''.join(l)
...
>>> print time.clock()-t
5.13626178421
>>>
>>> t = time.clock()
>>> for i in xrange(100):
...     x = block
...     for i in xrange(14):
...         x += x
...
>>> print time.clock()-t
7.16065713017
>>>
>>> z = time.clock()
>>> for i in xrange(100):
...     x = array.array("B", block2)
...
>>> z = time.clock()-z
>>>
>>> t = time.clock()
>>> for i in xrange(100):
...     x = array.array("B", block2)
...     for i in xrange(14):
...         x.extend(x)
...
>>> print time.clock()-t-z
7.28453746894
>>>


From guido at python.org  Wed May  3 18:43:55 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2006 09:43:55 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <20060503041222.3ng5auvf2bdc8ckg@login.werra.lunarpages.com>
References: <20060503041222.3ng5auvf2bdc8ckg@login.werra.lunarpages.com>
Message-ID: <ca471dc20605030943o10400b0fg4e4fb9c97f71d505@mail.gmail.com>

On 5/3/06, Michael Chermside <mcherm at mcherm.com> wrote:
> Guido writes:
> > (I had a bad
> > experience in my youth with strings implemented as trees, so I'm
> > biased against complicated string implementations. This also explains
> > why I'm no fan of the oft-proposed idea that slices should avoid
> > making physical copies even if they make logical copies -- the
> > complexity of that approach horrifies me.)
>
> No argument here with regard to strings implemented as trees, but I
> think you may be needlessly worried about physical vs logical copies
> for slices. Since strings (and slices of strings) are immutable, the
> implementation is quite simple. Read the Java "String" class to see
> just how easy. The slice returns a subclass of str that stores a
> start and stop position but redirects data access to the buffer used
> by the original str. The only tricky part is to manage garbage
> collection, solved by having the slice object contain a reference to
> the original str. That's it.
>
> Of course, you knew that, but the fact that I can describe it fully
> in 2 sentences should help show it's not overly complex.

The problem is that it's suboptimal if you read a 10 MB file into
memory (that's small here at Google :-) and split it into smaller
strings. If you keep only a small fraction of the substrings, the 10
MB string is just clogging up memory. So there will be pressure to
complicate the scheme by adding heuristics about when to copy and when
to share, etc., etc.

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

From jcarlson at uci.edu  Wed May  3 18:44:02 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 03 May 2006 09:44:02 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <fb6fbf560605030841g66a9c72blee144e3f132dd5a5@mail.gmail.com>
References: <ee2a432c0605022241k2fc41b1icb9a8615199eff98@mail.gmail.com>
	<fb6fbf560605030841g66a9c72blee144e3f132dd5a5@mail.gmail.com>
Message-ID: <20060503094338.6793.JCARLSON@uci.edu>


"Jim Jewett" <jimjjewett at gmail.com> wrote:
> 
> On 5/2/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> 
> > I think Guido had the best solution.  Use set() for empty sets, use {}
> > for empty dicts, use {genexp} for set comprehensions/displays, use
> > {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
> > literals.  We can always add {/} later if demand exceeds distaste.
> 
> I understand {1,2,3} vs {k1:v1, k2:v2}, but what is the {genexp} for?
> 
> As I read that, if the generator yielded two-tuples, you would get a
> set of two-tuples rather than a dict.  There would be no comprehension
> syntax for dicts.
> 
> I'm not sure we need a comprehension syntax for dicts, but I'm not
> sure we need one for sets either.
> 
>     >>> set(gen())
> 
> doesn't seem any worse than
> 
>     >>> dict(gen())

Agreed.

 - Josiah


From guido at python.org  Wed May  3 18:57:42 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2006 09:57:42 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <ee2a432c0605022241k2fc41b1icb9a8615199eff98@mail.gmail.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<Pine.GSO.4.58.0604301605170.18138@qew.cs>
	<e336a8$spg$1@sea.gmane.org> <44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com> <e38568$q5$1@sea.gmane.org>
	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
	<4457AD62.4060003@ewtllc.com>
	<ee2a432c0605022241k2fc41b1icb9a8615199eff98@mail.gmail.com>
Message-ID: <ca471dc20605030957w72dd5b70q9bef952eaeff05a@mail.gmail.com>

On 5/2/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On 5/2/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> >
> > I think Guido had the best solution.  Use set() for empty sets, use {}
> > for empty dicts, use {genexp} for set comprehensions/displays, use
> > {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
> > literals.  We can always add {/} later if demand exceeds distaste.
>
> Presumably {1, 2, 3: 4} would yield a syntax error?

Of course. I am thinking of the syntax as a kind of railroad diagram
for a finite state machine; from '{' you can go directly to '}' or to
EXPR; after that you can see ':' or ',' or '}'; if you see ':' from
then on you are constrained to EXPR:EXPR pairs; if you see '.' you are
constrained to single EXPRs alternating with commas. Taking the
current Grammar file we could do this:

atom: ... | '{' [dictorsetmaker] '}'

dictorsetmaker: test ':' test (',' test ':' test)* [',']   |   test
(',' test)* [',']

The apparent ambiguity between the two alternatives in the second rule
doesn't matter; our parser generator takes all the alternatives for a
rule together and turns them into a finite state machine as described
above.

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

From guido at python.org  Wed May  3 19:02:28 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2006 10:02:28 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <Pine.GSO.4.58.0605030918590.29169@dvp.cs>
References: <mailman.19569.1146600736.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605030918590.29169@dvp.cs>
Message-ID: <ca471dc20605031002scaff9d4v205118501acedab3@mail.gmail.com>

On 5/3/06, Greg Wilson <gvwilson at cs.utoronto.ca> wrote:
> I obviously haven't done the experiment yet, but I can pretty much
> guarantee you that newbies will trip over the inconsistency you're
> proposing:
>
>     Type    Two elements        One element        Empty
>     List    [1, 2]              [1]                []
>     Dict    {1:'a', 2:'b'}      {1:'a'}            {}
>     Set     {1, 2}              {1}                set()
>
> One of these things is not like the others...  One of these things just
> doesn't belong...

Let's do a different experiment. Simply tell people that this is how
it is. See if anyone has trouble remembering the rule after getting it
wrong once or twice. That's how we learn irregularities in real life;
it works very well. (Orlijn is currently into past tenses so I am
constantly in awe how easy we can manage exceptions.)

> Or is "regular enough that newcomers' guesses about
> what to type are usually right" no longer a design consideration?

"Usually" being the operative word. Newcomers come from so many
different backgrounds and the language has so many subtle corners that
we can't possibly demand that every part of the language be obvious to
everyone right from the start.

Dicts are vastly more useful than sets. Something has to give. End of
discussion please.

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

From guido at python.org  Wed May  3 19:05:07 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2006 10:05:07 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <fb6fbf560605030841g66a9c72blee144e3f132dd5a5@mail.gmail.com>
References: <mailman.18736.1146255866.27774.python-3000@python.org>
	<e336a8$spg$1@sea.gmane.org> <44563E8F.8050001@ewtllc.com>
	<ca471dc20605011035jc9236d5v8e9b837356cc7964@mail.gmail.com>
	<44572190.30007@gmail.com> <e38568$q5$1@sea.gmane.org>
	<ca471dc20605021042x526113b6k316405f6e4d64a3@mail.gmail.com>
	<4457AD62.4060003@ewtllc.com>
	<ee2a432c0605022241k2fc41b1icb9a8615199eff98@mail.gmail.com>
	<fb6fbf560605030841g66a9c72blee144e3f132dd5a5@mail.gmail.com>
Message-ID: <ca471dc20605031005od58ec94t9c7efbce2f1bd25d@mail.gmail.com>

On 5/3/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> I'm not sure we need a comprehension syntax for dicts, but I'm not
> sure we need one for sets either.

Perhaps not. Though in the history of math, set comprehensions were
the inspiration for Python's list comprehensions.

Also, I think we ought to move on.

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

From guido at python.org  Wed May  3 19:28:08 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2006 10:28:08 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <20060503010744.6790.JCARLSON@uci.edu>
References: <20060502220500.678A.JCARLSON@uci.edu>
	<ca471dc20605022227l5893d393sbc778b658c26a4de@mail.gmail.com>
	<20060503010744.6790.JCARLSON@uci.edu>
Message-ID: <ca471dc20605031028q6975eb67q1b83320842eb4dc9@mail.gmail.com>

On 5/3/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> "Guido van Rossum" <guido at python.org> wrote:
> > I wonder if that's really true. After all you still pay the overhead
> > for the list. In fact, here's a challenge for you: implement += on
> > bytes to be as fast as the list append + later join; or prove that it
> > can't be done.
>
> I don't believe it can be done.  See my sample at the end of this
> message.

OK, point taken, for this particular set of parameters (building a 16
MB string from 1K identical blocks).

But how much slower will the list.append version be if the blocks are
10 bytes instead of 1024? That could make a huge difference. (In fact,
I timed something similar to what you posted, and the doubling
approach is actually faster when the buffer is 256 bytes or less.

My conclusion: we need to agree on a rael benchmark before giving up.

> Note that removing the string[:] copy in the list.append
> version only reduces the running time by about .07 seconds.

That's because a string slice that returns the whole string is
optimized to an INCREF operation. So you were really copying the same
buffer over and over, which adds to locality and makes a huge
difference in memory performance.

> Indeed, I don't need to respond to every part in the message.  However,
> not responding to a valid concern/criticism seems to me like a
> head-in-the-sand approach to disagreements and discussions, which
> certainly doesn't help anyone.

Perhaps what seems a valid concern to you appears to endlessly harping
on the samepremature issue to me. Or perhaps I really *didn't* have
enough time to read everything you wrote and I missed it.

Here's a general guideline for anyone posting here: if you want me to
read your posts, make them short and to the point.

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

From edcjones at comcast.net  Wed May  3 21:33:21 2006
From: edcjones at comcast.net (Edward C. Jones)
Date: Wed, 03 May 2006 15:33:21 -0400
Subject: [Python-3000] Use of bracketing characters: (), {}, []
Message-ID: <44590581.7070106@comcast.net>

There is a current thread on notations for sets and dicts. A more 
general question is: How should the precious pairs of bracketing 
characters,(), {}, and [] be used? Currently, parentheses are used for 
grouping, function calls and tuples. Curly brackets are used for 
dictionaries and, perhaps in the future, for sets. Square brackets are 
used for subscripts and dictionaries.

Are these bracketing pairs used in too many ways? Does the language need 
more bracketing pairs, perhaps "<<<", ">>>"? Any way to get rid of the 
horrible ancient wart of "(a,)" for a tuple of length one?

From guido at python.org  Wed May  3 21:37:09 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2006 12:37:09 -0700
Subject: [Python-3000] Use of bracketing characters: (), {}, []
In-Reply-To: <44590581.7070106@comcast.net>
References: <44590581.7070106@comcast.net>
Message-ID: <ca471dc20605031237r1aa0cfa6j3ffdd0e5b29014bb@mail.gmail.com>

On 5/3/06, Edward C. Jones <edcjones at comcast.net> wrote:
> There is a current thread on notations for sets and dicts. A more
> general question is: How should the precious pairs of bracketing
> characters,(), {}, and [] be used? Currently, parentheses are used for
> grouping, function calls and tuples. Curly brackets are used for
> dictionaries and, perhaps in the future, for sets. Square brackets are
> used for subscripts and dictionaries.
>
> Are these bracketing pairs used in too many ways? Does the language need
> more bracketing pairs, perhaps "<<<", ">>>"? Any way to get rid of the
> horrible ancient wart of "(a,)" for a tuple of length one?

I'd like to discourage this thread. It seems an invitation to millions
of proposals and endless discussions. It also goes against the set
goal for Py3k to fix the early design bugs. Choosing only a limited
set of delimiters, used in ways similar to English or other mainstream
programming languages, was quite a conscious choice, and I don't
consider it a design mistake.

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

From tdelaney at avaya.com  Thu May  4 01:15:27 2006
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Thu, 4 May 2006 09:15:27 +1000
Subject: [Python-3000] sets in P3K?
Message-ID: <2773CAC687FD5F4689F526998C7E4E5F074372@au3010avexu1.global.avaya.com>

Jim Jewett wrote:

> On 5/2/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> 
>> I think Guido had the best solution.  Use set() for empty sets, use
>> {} for empty dicts, use {genexp} for set comprehensions/displays, use
>> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
>> literals.  We can always add {/} later if demand exceeds distaste.
> 
> I understand {1,2,3} vs {k1:v1, k2:v2}, but what is the {genexp} for?

Hmm - how about a slightly radical solution (which I think came up when
we were first discussing introducing sets ...).

Do away with sets altogether. Make the syntax {1, 2, 3} syntactic sugar
for {1:None, 2:None, 3:None}.

Pros:

1. No ambiguity concerning {}.

2. {genexp} will always produce a dict. However, there would be some
ambiguity if we wanted to support single-value-producing genexps (i.e.
returning a single value rather than a 2-tuple for each element). Simple
to disallow that, and provide a wrapper generator that takes an iterable
of single-value elements and generates 2-tuples.

Cons:

1. The set/dict operations don't completely overlap.

2. Performance for set-like dicts won't be as good as for builtin sets.

Tim Delaney

From guido at python.org  Thu May  4 01:20:53 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2006 16:20:53 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <2773CAC687FD5F4689F526998C7E4E5F074372@au3010avexu1.global.avaya.com>
References: <2773CAC687FD5F4689F526998C7E4E5F074372@au3010avexu1.global.avaya.com>
Message-ID: <ca471dc20605031620u48b0ddafte8454822fd9f99d2@mail.gmail.com>

I suspect Raymond has plenty of good reasons to shoot this one down.

I'll add a few more: what's the union of {1:1} and {1:2}? The
intersection? The difference? Refuse the temptation to guess!

--Guido

On 5/3/06, Delaney, Timothy (Tim) <tdelaney at avaya.com> wrote:
> Jim Jewett wrote:
>
> > On 5/2/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> >
> >> I think Guido had the best solution.  Use set() for empty sets, use
> >> {} for empty dicts, use {genexp} for set comprehensions/displays, use
> >> {1,2,3} for explicit set literals, and use {k1:v1, k2:v2} for dict
> >> literals.  We can always add {/} later if demand exceeds distaste.
> >
> > I understand {1,2,3} vs {k1:v1, k2:v2}, but what is the {genexp} for?
>
> Hmm - how about a slightly radical solution (which I think came up when
> we were first discussing introducing sets ...).
>
> Do away with sets altogether. Make the syntax {1, 2, 3} syntactic sugar
> for {1:None, 2:None, 3:None}.
>
> Pros:
>
> 1. No ambiguity concerning {}.
>
> 2. {genexp} will always produce a dict. However, there would be some
> ambiguity if we wanted to support single-value-producing genexps (i.e.
> returning a single value rather than a 2-tuple for each element). Simple
> to disallow that, and provide a wrapper generator that takes an iterable
> of single-value elements and generates 2-tuples.
>
> Cons:
>
> 1. The set/dict operations don't completely overlap.
>
> 2. Performance for set-like dicts won't be as good as for builtin sets.
>
> Tim Delaney
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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

From tdelaney at avaya.com  Thu May  4 01:24:51 2006
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Thu, 4 May 2006 09:24:51 +1000
Subject: [Python-3000] sets in P3K?
Message-ID: <2773CAC687FD5F4689F526998C7E4E5FF1E6BC@au3010avexu1.global.avaya.com>

Guido van Rossum wrote:

> I suspect Raymond has plenty of good reasons to shoot this one down.
> 
> I'll add a few more: what's the union of {1:1} and {1:2}? The
> intersection? The difference? Refuse the temptation to guess!

Yep - that's a large part of what I meant by the set/dict methods not
completely overlapping.

Just wanted to put it out there so it could be shot down quickly (and
added to PEP 3099) or hailed as the greatest achievement in language
design ever ;)

Tim Delaney

From guido at python.org  Thu May  4 01:55:49 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2006 16:55:49 -0700
Subject: [Python-3000] sets in P3K?
In-Reply-To: <2773CAC687FD5F4689F526998C7E4E5FF1E6BC@au3010avexu1.global.avaya.com>
References: <2773CAC687FD5F4689F526998C7E4E5FF1E6BC@au3010avexu1.global.avaya.com>
Message-ID: <ca471dc20605031655p4ee93d14ra6c5962a8ff99559@mail.gmail.com>

On 5/3/06, Delaney, Timothy (Tim) <tdelaney at avaya.com> wrote:
> Just wanted to put it out there so it could be shot down quickly (and
> added to PEP 3099) or hailed as the greatest achievement in language
> design ever ;)

You seem to have missed that I already pronounced on this. The new set
syntax is in PEP 3100.

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

From tdelaney at avaya.com  Thu May  4 02:00:26 2006
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Thu, 4 May 2006 10:00:26 +1000
Subject: [Python-3000] sets in P3K?
Message-ID: <2773CAC687FD5F4689F526998C7E4E5FF1E6BE@au3010avexu1.global.avaya.com>

Guido van Rossum wrote:

> On 5/3/06, Delaney, Timothy (Tim) <tdelaney at avaya.com> wrote:
>> Just wanted to put it out there so it could be shot down quickly (and
>> added to PEP 3099) or hailed as the greatest achievement in language
>> design ever ;)
> 
> You seem to have missed that I already pronounced on this. The new set
> syntax is in PEP 3100.

Must have missed the actual pronouncement on set() - I thought it was
almost pronounced (and {1, 2, 3} was definite for other set literals),
but not quite there yet.

python-dev and python-3000 have been *very* busy the last few weeks ...

Tim Delaney

From greg.ewing at canterbury.ac.nz  Thu May  4 03:06:34 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 04 May 2006 13:06:34 +1200
Subject: [Python-3000] bug in modulus?
In-Reply-To: <20060503044158.c6wxhrx2ygrbgoo0@login.werra.lunarpages.com>
References: <20060503044158.c6wxhrx2ygrbgoo0@login.werra.lunarpages.com>
Message-ID: <4459539A.2070305@canterbury.ac.nz>

Michael Chermside wrote:

> Providing both operations is a no-brainer. But only one gets to be
> spelled "x % y".

Personally I wouldn't mind if *neither* operation on
floats were spelled x % y. The number of times I can
remember doing a mod on floats is vanishingly small,
and I'd never be able to remember exactly how the one
chosen for % worked anyway. So giving them both explicit
names would be the most helpful thing for me.

> Beginners will care that floats and integers
> behave "the same"

To my mind, % is inherently an integer operation, and
doing the "same" thing for floats doesn't even make
sense. Raising an exception would be a good way of
giving newbies a gentle hint that they need to be more
explicit.

--
Greg

From jcarlson at uci.edu  Thu May  4 03:43:46 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 03 May 2006 18:43:46 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <ca471dc20605031028q6975eb67q1b83320842eb4dc9@mail.gmail.com>
References: <20060503010744.6790.JCARLSON@uci.edu>
	<ca471dc20605031028q6975eb67q1b83320842eb4dc9@mail.gmail.com>
Message-ID: <20060503182349.6796.JCARLSON@uci.edu>


"Guido van Rossum" <guido at python.org> wrote:
> OK, point taken, for this particular set of parameters (building a 16
> MB string from 1K identical blocks).
> 
> But how much slower will the list.append version be if the blocks are
> 10 bytes instead of 1024? That could make a huge difference. (In fact,
> I timed something similar to what you posted, and the doubling
> approach is actually faster when the buffer is 256 bytes or less.
> 
> My conclusion: we need to agree on a real benchmark before giving up.

In my programming efforts, I've found two cases which use
''.join(strings) quite often:

1. socket reads
2. content generation


In the socket reading case, I tend to use s.read(4096) or so, though I
have seen calls in the 512-65536 range.  Generally it all depends on how
much data the particular application expects to be reading at any one
time.

Also in my experience, content generation tends to be a bunch of
relatively small strings (maybe 10-100 bytes), which also tends to kill
the string += operation.


Regardless of what does end up being faster in a microbenchmark (which I
agree we should have to compare and contrast certain approaches from a
performance perspective), from a memory allocator perspective, the fewer
reallocs that are necessary to come up with a single string-like
representation of the data, I think, the better, as reallocs do tend to
fragment address space (an issue I've had to deal with recently).


> > Note that removing the string[:] copy in the list.append
> > version only reduces the running time by about .07 seconds.
> 
> That's because a string slice that returns the whole string is
> optimized to an INCREF operation. So you were really copying the same
> buffer over and over, which adds to locality and makes a huge
> difference in memory performance.

Good point.  Making the input 1025 bytes, and performing block[:-1]
resulted in a running time of 13.94 seconds.

Doing a similar thing for the x += x case, making it x += x[:-1], pushed
that one to 11.69 seconds.

And finally, doing the same thing with the array version, x.extend(x[:-1])
gets 11.68 seconds.


 - Josiah


From greg.ewing at canterbury.ac.nz  Thu May  4 04:32:33 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 04 May 2006 14:32:33 +1200
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <20060502134007.GB8543@phd.pp.ru>
References: <06May1.133531pdt.58641@synergy1.parc.xerox.com>
	<445751A6.9050001@canterbury.ac.nz> <20060502134007.GB8543@phd.pp.ru>
Message-ID: <445967C1.1090800@canterbury.ac.nz>

Oleg Broytmann wrote:

>    I am one of those mouse-haters, and I use keyboard as much as possible.
> All platforms allow me to do it with keyboard shortcuts, default buttons
> and tabs over all widgets.

It's reasonable to have some way of controlling
everything with the keyboard, although it seems
unnecessary to be able to tab into things like
the OK and Cancel buttons of a dialog, which
already have well-known keyboard equivalents.

However I'm convinced now that I shouldn't be
overriding the platform behaviour here. I'll
revisit this in a future release.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiam!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From greg.ewing at canterbury.ac.nz  Thu May  4 04:39:31 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 04 May 2006 14:39:31 +1200
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <e38g44$bfb$1@sea.gmane.org>
References: <loom.20060502T201105-105@post.gmane.org>
	<e38g44$bfb$1@sea.gmane.org>
Message-ID: <44596963.8070200@canterbury.ac.nz>

Terry Reedy wrote:

> -the ability to ignore platforn standards and give an app a unique look and 
> feel.  A start on this, for instance, is being able to give dialog boxes a 
> custom background instead of uniform gray or whatever.

You can do this in PyGUI by adding a View that fills the
whole window and then adding your controls to that. You
can draw whatever background you want in the View.

> -the ability to shift to full-screen mode.

If I add some way of removing the menu bar, and finding
out the size of the screen, then you could create a window
that fills the whole screen. Would that be sufficient?

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiam!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From greg.ewing at canterbury.ac.nz  Thu May  4 06:09:40 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 04 May 2006 16:09:40 +1200
Subject: [Python-3000] Use of bracketing characters: (), {}, []
In-Reply-To: <44590581.7070106@comcast.net>
References: <44590581.7070106@comcast.net>
Message-ID: <44597E84.6030803@canterbury.ac.nz>

Edward C. Jones wrote:

> Does the language need 
> more bracketing pairs, perhaps "<<<", ">>>"?

I hope not. I find any use of < and > as brackets to
be ugly, and the more of them there are in a row,
the uglier.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiam!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From greg.ewing at canterbury.ac.nz  Thu May  4 06:14:59 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 04 May 2006 16:14:59 +1200
Subject: [Python-3000] sets in P3K?
In-Reply-To: <ca471dc20605031620u48b0ddafte8454822fd9f99d2@mail.gmail.com>
References: <2773CAC687FD5F4689F526998C7E4E5F074372@au3010avexu1.global.avaya.com>
	<ca471dc20605031620u48b0ddafte8454822fd9f99d2@mail.gmail.com>
Message-ID: <44597FC3.4070306@canterbury.ac.nz>

Guido van Rossum wrote:

> I'll add a few more: what's the union of {1:1} and {1:2}?

An exception?

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiam!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From m.liu.jin at gmail.com  Thu May  4 07:18:18 2006
From: m.liu.jin at gmail.com (Liu Jin)
Date: Thu, 04 May 2006 13:18:18 +0800
Subject: [Python-3000] revamping the io stack, part 2
In-Reply-To: <1d85506f0604291210qd1493abk2ffb4ff859e3b906@mail.gmail.com>
	(tomer filiba's message of "Sat, 29 Apr 2006 21:10:15 +0200")
References: <1d85506f0604291210qd1493abk2ffb4ff859e3b906@mail.gmail.com>
Message-ID: <1wva74h1.fsf@gmail.com>

>>>>> "tomer" == tomer filiba <tomerfiliba at gmail.com> writes:
    > read(x) guarantees to return x bytes, or EOFError otherwise (and
    > also restoing the stream position).

This would require arbitrarily large buffer for a socket stream.  I'm
unsure if that's desiable.  Maybe you could move the buffering up to
a reader and leave the basic stream interface unbuffered (i.e. no
backrolling)?

From tim.peters at gmail.com  Thu May  4 07:24:41 2006
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 4 May 2006 01:24:41 -0400
Subject: [Python-3000] bug in modulus?
In-Reply-To: <20060503144213.GA28245@panix.com>
References: <1146659034.5910.27.camel@fsol> <20060503144213.GA28245@panix.com>
Message-ID: <1f7befae0605032224g382511ebg209debcdffac60a2@mail.gmail.com>

[Aahz]
> Well, yes, but Uncle Timmy is jumping up and down and screaming for a
> change.

That's a pretty bizarre characterization, if I say so myself.  But
since I've already been accused, I may as well live up to it ;-):

> Granted, I think we should show respect for our numerical
> elders, but I think Michael also has a point about the importance of
> making floats and ints behave the same, especially given that division
> will auto-promote floats from ints.

Look at the example I was responding to:

>>> -1e-50 % 2.0
2.0

The instant "feel good" response is "oh, no real problem, make it
return 0.0 instead".  But that would break a different invariant (and
in fact a more fundamental one) people legitimately expect from
integers:

    a = (a // b)*b + a%b

Because -1e50 / 2.0 is very visibly less than 0.0 (this isn't an
endcase, or even special):

>>> -1e-050 / 2.0
-5e-051

the floor has to be -1.0:

>>> -1e-050 // 2.0
-1.0

Plug that into the identity above to get

    -1e-050 = -1.0*2.0 + a%b

or

    a%b = 2.0 - 1e-050

Python does the best it can to meet that, returning the closest HW
float to the infinite precision result of 2.0-1e-50.  0.0 is nowhere
close to that.  So, believe it or not, we return 2.0 here because
we're trying our best to _meet_ expectations derived from the
well-behaved unbounded-precision integer mod.

It's not possible to meet _all_ expectations derived from integers
simultaneously using HW floats with this defintion of %.  In this
case, we violate the expectation that abs(a%b) < abs(b).  If we
returned 0.0, we'd violate the more fundamental identity above.

divmod gets bizarre with floats too (divmod makes perfect sense for
integers, but not for floats), like this on Windows:

>>> divmod(1e300, 1e-300)
(1.#INF, 4.891554850853602e-301)

C doesn't have these problems because it doesn't define divmod at all,
and defines (well, C99 does) % for both integers and floats in a way
that makes most sense for floats.   In C99,

    -1e-50 % 2.0 == -1e-50

exactly, and

    ((int)(a/b))*b + a%b == a

exactly in this case.  The "exactly" isn't a coincidence:  using C's
definition for floating %, the machine value returned for a%b is
exactly equal to the result of computing

    a - ((int)(a/b))*b

to infinite precision.   At base, that's why C's definition makes most
sense for floats:  it doesn't lose information when applied to floats,
and therefore also doesn't introduce surprises _due_ to information
loss.  Python's integer-derived meaning for % is less accurate for
floats, usually suffering rounding errors.  This is always harmful
when it occurs, although it's not usually so _obviously_ surprising as
rounding the infinite-precision result of 2.0-1e-50 to the machine
value 2.0.

So we end up with a floating % that makes little sense for floats used
_as_ floats, and that can't meet all integer-derived expectations
anyway.  What's the point?  "Think of the children!"?  They'd be
better off with rationals than floats anyway, and there are no
problems using the integer definition of % for rationals too.

I'd be happiest if P3K floats didn't support __mod__ or __divmod__ at
all.  Floating mod is so rare it doesn't need syntactic support, and
the try-to-be-like-integer __mod__ and __divmod__ floats support now
can deliver surprises to all users incautious enough to use them.

BTW,

>>> decimal.Decimal("-1e-50") % decimal.Decimal("2.0")
Decimal("-1E-50")
>>> any(decimal.getcontext().flags.values())
False

The point of the last line is that the Rounding and Inexact flags are
still clear:  like C's, the decimal module's notion of % is also an
exact computation despite that it's working with floats.  This is
impossible for floats using the "a%b has the same sign as b"
definition.

The point of the first line is that a sane meaning for floating % has
already snuck into Python ;-)

From talin at acm.org  Thu May  4 08:14:55 2006
From: talin at acm.org (Talin)
Date: Thu, 4 May 2006 06:14:55 +0000 (UTC)
Subject: [Python-3000] PEP 3101 Open Issues
Message-ID: <loom.20060504T074005-137@post.gmane.org>

I have not yet posted the PEP 3101 - Advanced String Formatting to
c.l.p. yet because I am still in the process of collecting feedback
from python-dev. My plan is to do a slow escalation of feedback
collection over the course of the next several weeks; As I see it,
there's really no hurry about this.

I would like to list some of the issues that have been brought up. In
particular, I would like to get to a definative resolution on some of
these issues.

Issue: Compound Field Names

In the draft version of the PEP, I proposed a scheme whereby a limited
set of Python expressions could be embedded into a string template.
The list of operations was deliberately limited for security reasons.
The reaction to this was mixed, so I took it out of the proposal.

However, I realized that some form of naming indirection might provide
a way out of the dict-flattening dilemma. In particular, Ian Bicking
was a strong proponent of retaining the existing % operator's ability
to pass in a regular dictionary as an argument, and allow the
formatting string to cherry-pick specific values out of it, rather
than having to explicitly pass in exactly the values. The **args
syntax allows this, but requires the dictionary to be copied. A strong
argument was made for a non-copying method for accessing the values in
a dictionary.

Various special case solutions were proposed (such as implicitly
interpreting the first argument, special method names, special
keywords, etc.) all of which I felt were rather hackish (even the ones
I suggested.)

As a way out of this dilemma, I decided to re-introduce a simplified
form of the compound field names idea, which would allow individual
dictionary entries to be addressed independently. However, there have
been objections about the ambiguity of the syntax, since it supports
both item and attribute access.

There have also been a lot of "all or nothing" arguments (i.e. 'why
support only this one type of operator, and not the others? I think
you should support them all, or don't support any'), but frankly I
don't put too much weight on this line of reasoning.

Issue: Escaping Braces

The primary reason for using backslash as an escape was that it seemed
more 'Pythonic' to me; In addition, I wanted to be able to support
nested braces so that the format fields could themselves be
parameterized (since the current operator % supports a limited form of
parameterization.)

I don't have an objection to using doubled braces as an escape,
provided that someone can come up with a reasonably simple algorithm
for deciding when a brace is nested and when it is escaped.

Issue: Exact syntax for conversion specifiers

The current spec says that the conversion specifiers will be "the same
as the existing operator %", with some exceptions. Do I need to go and
explicitly spell out what specifiers are supported, and what their
syntax is? That will make the PEP rather large, IMHO.

(BTW, for those who asked - I call them conversion specifiers because
that's the term used in the current docs for operator %.)

Issue: Custom formatting

I'm in the process of rewriting this section to make it clearer. I
feel that being able to customize the formatting of a given data type
is important, particularly for complex types such as sets and lists. A
trivial example is being able to display negative integers in
parentheses, as is done in accounting, rather than using a minus sign.

Issue: Target version

Neither this PEP or the Keyword-only PEP breaks backwards
compatibility, so it has been suggested that these PEPs be applied to
2.6 instead of 3.0, or perhaps developed in 3.0 and then backported.
If this is the case, should the PEPs be renumbered?

Issue: Implementation

While I am willing to do the basic implementation of this PEP, I would
rather that someone with a greater experience with the internals of
Python do the final version; My experience with hacking the Python C
code is rather limited at this point, and in the last month I've run
into a number of situations where my instincts about how to do things
turned out to be wrong.

The actual implementation should be fairly straightforward, and the
only tricky part is re-implementing the behaviors of the current
conversion specifiers.

-- Talin



From m.liu.jin at gmail.com  Thu May  4 08:23:07 2006
From: m.liu.jin at gmail.com (Liu Jin)
Date: Thu, 04 May 2006 14:23:07 +0800
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <20060501090813.8y05zi9jhpq88kw4@login.werra.lunarpages.com>
	(Michael Chermside's message of "Mon, 01 May 2006 09:08:13 -0700")
References: <20060501090813.8y05zi9jhpq88kw4@login.werra.lunarpages.com>
Message-ID: <wtd25mwk.fsf@gmail.com>

>>>>> "Michael" == Michael Chermside <mcherm at mcherm.com> writes:
    > What needs to be decided for Py3K is whether to DROP support for
    > TK. I am actually mildly in favor of dropping TK support in the
    > core if we can make it easy enough to download and install
    > separately.

You can't just drop Tk, without removing IDLE from the distribution.
You also have to remove pynche and webchecker from the Tools
directory.  So it's not about one package, but several.

Regards,
Liu Jin

From talin at acm.org  Thu May  4 08:35:50 2006
From: talin at acm.org (Talin)
Date: Thu, 4 May 2006 06:35:50 +0000 (UTC)
Subject: [Python-3000] PEP 3102 Open Issues
Message-ID: <loom.20060504T081530-863@post.gmane.org>

Given that this PEP is shorter, there is less to discuss. :)

It seems that most people are in favor of the first part of the
proposal, which is relaxing the restriction that *args must come
after any keyword arguments. There is less agreement on the
proposal to have non-defaulted arguments after the varargs
argument; However, as I stated earlier, this is what falls out
naturally from the algorithm, and restricting it to only allow
defaulted arguments makes the implementation more complex.

The only really contentious issue appears to be the 'naked
star' syntax, that is the use of a '*' argument without a name
to indicate 'no more positional arguments'.

It appears that while Guido likes this syntax, a lot of people seem
dubious about it.

I have to admit that while the reasoning behind the use of the
'*' character is logical, the logic seems a little convoluted. Part of this
is due to the use of negative logic - the absence of something
that would normally be there (i.e. a keyword after the '*') indicates
a restriction on what would normally be allowed (i.e. additional
keyword arguments.)

Looking at the suggestions that people have made, it seems that most
people would find some sort of delimiter or separator character
to be more natural - in other words, replacing the comma after
the last positional argument with some other character. The use
of a separator suggests 'dividing' or 'partitioning' the argument
list into two pieces, which is, I suspect, how most people think
of the problem.

Unfortunately, the supply of delimiters is (de)limited. We've already
been told that semicolon is a show-stopper and colon is already
taken (for argument type attributes). None of the remaining
characters looks particularly 'pretty' in this context, although I
suppose we could get used to them in time.

This, however, is only my interpretation of the discussion; others
may have a difference view.

At this point, I see only a few choices:

1) Drop this portion of the proposal
2) Go with the 'naked star' syntax anyway over the objections, and
explain the rationale in the docs;
3) Come up with a separator character we can agree on
4) Come up with a brilliantly-devised alternative

Thoughts?

-- Talin



From qrczak at knm.org.pl  Thu May  4 12:23:02 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Thu, 04 May 2006 12:23:02 +0200
Subject: [Python-3000] revamping the io stack, part 2
In-Reply-To: <1d85506f0604291210qd1493abk2ffb4ff859e3b906@mail.gmail.com>
	(tomer filiba's message of "Sat, 29 Apr 2006 21:10:15 +0200")
References: <1d85506f0604291210qd1493abk2ffb4ff859e3b906@mail.gmail.com>
Message-ID: <87k692w0l5.fsf@qrnik.zagroda>

"tomer filiba" <tomerfiliba at gmail.com> writes:

> read(x) guarantees to return x bytes, or EOFError otherwise
> (and also restoing the stream position).

This is a poor choice of the fundamental operation. For example when
recoding bytes to characters, an analogous interface for a character
stream is inconvenient to implement in terms of this interface for
a byte stream. Ditto for transparent compression and decompression.

Most APIs are based on the Unix semantics of read (reading at most
the given count) and it should be the core. Reading exactly N bytes
can be implemented on top of that.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From birchb at tpg.com.au  Thu May  4 15:05:40 2006
From: birchb at tpg.com.au (Bill Birch)
Date: Thu, 4 May 2006 23:05:40 +1000
Subject: [Python-3000] Types Sig Archive Broken Links?
In-Reply-To: <F77F59BD4C53BC4FA12923D5EA4C6EBB0F3DDA@exuau055csm80.oceania.corp.anz.com>
References: <F77F59BD4C53BC4FA12923D5EA4C6EBB0F3DDA@exuau055csm80.oceania.corp.anz.com>
Message-ID: <200605042305.40608.birchb@tpg.com.au>

On Thu, 4 May 2006 05:05 pm, Birch, Bill wrote:

> The Types-SIG archives link
> (http://mail.python.org/pipermail/types-sig/) gives a 404 error.
>
> Does anyone know how to get the archive back?
Had no idea that email to mailman would end up here!

Anyhow, I found another copy of the archive here:

http://aspn.activestate.com/ASPN/Mail/Browse/Plain/types-sig/

From mithrandi at mithrandi.za.net  Thu May  4 16:07:31 2006
From: mithrandi at mithrandi.za.net (Tristan Seligmann)
Date: Thu, 4 May 2006 16:07:31 +0200
Subject: [Python-3000] characters data type
In-Reply-To: <loom.20060503T000621-941@post.gmane.org>
References: <loom.20060502T073849-533@post.gmane.org>
	<ca471dc20605020736jf740235y3bd303a590bcd726@mail.gmail.com>
	<loom.20060502T230526-773@post.gmane.org>
	<ca471dc20605021447g31e785edqd7714e3117f7dcaa@mail.gmail.com>
	<loom.20060503T000621-941@post.gmane.org>
Message-ID: <20060504140730.GC27395@mithrandi.za.net>

* Talin <talin at acm.org> [2006-05-02 22:20:51 +0000]:

> Although if you are supporting surrogates, then __getitem__ and __getslice__
> won't be O(1), will they? That's why I asked about UCS-2, which is what I

Unfortunately, if Python is compiled with 16-bit storage for unicode
characters, then the surrogates are exposed, and a surrogate pair will
appear as two separate characters.

> use in my work -- which is another way of saying that we've punted on the
> issue of surrogates.

Not sure if Python's treatment of this would be considered punting or
not ;)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.python.org/pipermail/python-3000/attachments/20060504/6ce59e14/attachment.pgp 

From guido at python.org  Thu May  4 19:03:44 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 4 May 2006 10:03:44 -0700
Subject: [Python-3000] PEP 3102 Open Issues
In-Reply-To: <loom.20060504T081530-863@post.gmane.org>
References: <loom.20060504T081530-863@post.gmane.org>
Message-ID: <ca471dc20605041003s58e587b1s60d06af347b3fb49@mail.gmail.com>

On 5/3/06, Talin <talin at acm.org> wrote:
> 1) Drop this portion of the proposal
> 2) Go with the 'naked star' syntax anyway over the objections, and
> explain the rationale in the docs;
> 3) Come up with a separator character we can agree on
> 4) Come up with a brilliantly-devised alternative

To save everybody's time and energy, I propose to go with (2) and go
ahead with an implementation. If there's a patch against the p3yk
(sic) branch I'll likely adopt it there.

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

From tim.peters at gmail.com  Thu May  4 21:07:23 2006
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 4 May 2006 15:07:23 -0400
Subject: [Python-3000] bug in modulus?
In-Reply-To: <ca471dc20605021047k3f464422jc1e39825d81a1a17@mail.gmail.com>
References: <1145807918.069455.241510@i40g2000cwc.googlegroups.com>
	<4450928c$0$21107$626a54ce@news.free.fr>
	<j3L5g.18187$Fs1.621@bgtnsc05-news.ops.worldnet.att.net>
	<S7L5g.30013$eR6.27390@bgtnsc04-news.ops.worldnet.att.net>
	<1f7befae0605021030r458a371fm54f263cfaf9c90cf@mail.gmail.com>
	<ca471dc20605021047k3f464422jc1e39825d81a1a17@mail.gmail.com>
Message-ID: <1f7befae0605041207k64aff52cgf7fdbf5d7fe387be@mail.gmail.com>

[Guido]
> This is way above my head. :-)

Of course it's not, but the issues are subtle and messy enough that
it's a burden to make sufficient time for them.  I'm sympathetic to
that ;-)

> The only requirement *I* would like to see is that for floats that
> exactly represent ints (or longs for that matter) the result ought of
> x%y ought to have the same value as the same operation on the
> corresponding ints (except if the result can't be represented exactly
> as a float -- I don't know what's best then).
>
> We're fixing this for / in Py3k, so passing an int into an algorithm
> written for floats won't be harmful and won't require defensiev
> float() casting everywhere. It would be a shame if we *introduced* a
> new difference between ints and floats for %.

I'm sympathetic to that too.  I explained in detail in a different
message why the C99 definition of % is a much better definition for
floats, and why the Python-int flavor of % cannot (as in "impossible,
not even in theory") meet all reasonable integer-derived expectations
when applied to floats.

If Python switched to C99's definition of % for both integers and
floats, that would work out better so far as it goes.  But Python's %
makes much more sense for integers, so that would be a flea on the
tail of the dog wagging the guy walking the dog (float % is rare in
real life).

A variant on what you sketched above would be an odd but probably
workable compromise:  keep __mod__ and __divmod__ for floats, but make
them exceptional when the arguments aren't exact integers, or the
result can't be represented exactly as a float (e.g., -1.0 %
2.0**100).  Then if someone uses "small enough" integers that happen
to be in floating format, % and divmod work and deliver the same
result as integer %/divmod.  If floating %/divmod are allowed to
return longs, then cases like -1.0 % 2.0**100 could also deliver
surprise-free results (although that seems so useless, given that the
_inputs_ were floats, I'd rather raise an exception).

The surprise comes when they apply % or divmod to a non-integral
float, and then the exception can clearly point to a spelling of mod
that makes sense for floats (math.fmod already does -- that's the C99
float %).   That spelling can't have the same definition as integer %,
but since you have to explicitly ask for it I don't see that as a real
problem.

The decimal module should change to the same kind of approach, whatever it is:

>>> from decimal import Decimal as D
>>> D(-1) % D(2)
Decimal("-1")

is already inconsistent with -1 % 2.

BTW, this came up on c.l.py earlier this week:

>>> from math import atan2
>>> atan2(-0, -1)
3.1415926535897931
>>> atan2(-0.0, -1)
-3.1415926535897931

Gotta love signed zeroes :-(

From jcarlson at uci.edu  Thu May  4 21:19:02 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu, 04 May 2006 12:19:02 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <20060503182349.6796.JCARLSON@uci.edu>
References: <ca471dc20605031028q6975eb67q1b83320842eb4dc9@mail.gmail.com>
	<20060503182349.6796.JCARLSON@uci.edu>
Message-ID: <20060504114107.67A2.JCARLSON@uci.edu>


Josiah Carlson <jcarlson at uci.edu> wrote:
> Good point.  Making the input 1025 bytes, and performing block[:-1]
> resulted in a running time of 13.94 seconds.

I just thought of a better way of benchmarking list-like over-allocation
semantics.

For assumed smaller-sized writes:

Use an array, and manually extend using extensions which are about as
long as list overallocation, which would under-count the amount of time
it would take to construct bytes object with generally small incremental
writes.

Then, use the smallest overallocation size as the presumed size of
writes in the list.append()/''.join() case.  This should reasonably
count the amount of time to generate the string in this case.

If the under-counting for list-like overallocation is about the same or
slower than the append/join, then append/join is going to be faster in
practice for small writes.


For larger blocks, do the same thing, only increase the 'overallocations'
to be at least as large as the the assumed block size.

               135 byte blocks    1k blocks
append/join:     28.05s             12.11s
list-like:       31.21s             31.50s

Seems to be a clear win for append/join on both 135 byte and 1k blocks
for constructing a 16 meg string. Reducing block size to 64 bytes gives
list-like overallocation the benefit (append/join jumps to 50+
seconds), which tells us that for very short blocks, list-like
overallocation wins, but for blocks of expected ~135 bytes or larger on
my machine, append/join wins.


 - Josiah


From guido at python.org  Thu May  4 21:39:49 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 4 May 2006 12:39:49 -0700
Subject: [Python-3000] bug in modulus?
In-Reply-To: <1f7befae0605032224g382511ebg209debcdffac60a2@mail.gmail.com>
References: <1146659034.5910.27.camel@fsol> <20060503144213.GA28245@panix.com>
	<1f7befae0605032224g382511ebg209debcdffac60a2@mail.gmail.com>
Message-ID: <ca471dc20605041239r2d65938fxd8d5e4c8905443e@mail.gmail.com>

On 5/3/06, Tim Peters <tim.peters at gmail.com> wrote:
> I'd be happiest if P3K floats didn't support __mod__ or __divmod__ at
> all.  Floating mod is so rare it doesn't need syntactic support, and
> the try-to-be-like-integer __mod__ and __divmod__ floats support now
> can deliver surprises to all users incautious enough to use them.

OK, this makes sense. I've added this to PEP 3100.

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

From fredrik at pythonware.com  Thu May  4 22:04:27 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 4 May 2006 22:04:27 +0200
Subject: [Python-3000] characters data type
References: <ca471dc20605031028q6975eb67q1b83320842eb4dc9@mail.gmail.com><20060503182349.6796.JCARLSON@uci.edu>
	<20060504114107.67A2.JCARLSON@uci.edu>
Message-ID: <e3dmod$2j2$1@sea.gmane.org>

Josiah Carlson wrote:

> I just thought of a better way of benchmarking list-like over-allocation
> semantics.

here's another way:

$ more Objects/unicodeobject.c
...
PyObject *
PyUnicode_Join(PyObject *separator, PyObject *seq)
{
    size_t res_alloc = 100;  /* # allocated bytes for string in res */
...
        if (new_res_used > res_alloc) {
            /* double allocated size until it's big enough */
            do {
                size_t oldsize = res_alloc;
                res_alloc += res_alloc;
                if (res_alloc < oldsize || res_alloc > INT_MAX)
                    goto Overflow;
            } while (new_res_used > res_alloc);
            if (_PyUnicode_Resize(&res, (int)res_alloc) < 0) {
                Py_DECREF(item);
                goto onError;
            }
            res_p = PyUnicode_AS_UNICODE(res) + res_used;
        }
...

</F>




From rudyrudolph at excite.com  Thu May  4 22:20:06 2006
From: rudyrudolph at excite.com (Rudy Rudolph)
Date: Thu,  4 May 2006 16:20:06 -0400 (EDT)
Subject: [Python-3000] in-out parameters
Message-ID: <20060504202006.1EC572F5E9@xprdmxin.myway.com>

 



Guido wrote:&gt;Does Java have them? I know very little Java, but all the other object-oriented languages I use support in-out and out parameters. For example:C++:    void foo(int &amp;param) {param += 5;}    void bar(int &amp;param) {param = 10;}    // C++ does not distinguish between in-out and out parameters.    // call them    int x = 2; foo(x); // x is now 7    int y; bar(y); // y doesn't need to be initialized. It is now 10.    // Unfortunately, the C++ function definition doesn't indicate    // whether the argument needs to be initialized before the call.C#:    void foo(ref int param) {param += 5;} // passed value can be used    void bar(out int param) {param = 10;} // passed value cannot be used    // call them    int x = 2; foo(ref x); // x is now 7    int y; bar(out y); // y is now 10.Ada:    procedure foo(param : in out Integer) is begin param := param + 5; end;    procedure bar(param : out Integer) is begin param := 10; end;    -- call them    Integer x := 2; 
foo(x); -- x is now 7    Integer y; bar(y); -- y is now 10Python:    def foo(paramWrapper):        paramWrapper[0] += 5    # Alternative:    def foo2(param):        return param + 5    def bar(paramWrapper):        paramWrapper[0] = 10    # call them    x = 2    wrapper = [x]    foo(wrapper)    x = wrapper[0] # x is now 7    # Three lines of it just to call foo in such a way that    # it can modify the value of the variable passed in.    # Alternative:    x = 2    x = foo2(x)    # Have to mention x twice just to let foo2 modify its value.    # Also, all the arguments to be modified get mixed in with    # the real function result if there is one.    wrapper = [None]    bar(wrapper)    y = wrapper[0] # y is now 10    # bar is not quite as big of a deal. The new value could    # have been returned as one of (possibly many) results.Proposed Python 3.0:    def foo(&amp;param):        param += 5    def bar(&amp;param):        param = 10    # call them    x = 2    foo(x) # x is now 
7    y = None    bar(y) # y is now 10 I have always considered this the most glaring omission in Python.If it will never happen, fine, it will always be a wart, but in-outand out parameters are common in object-oriented languages and makethe code much more readable. Since we are considering optional type indications on parameters, Ithought this would be a good time to explicitly allow a function tochange the argument value by adding something to the parameter.It could look like foo(&amp;param) or foo(ref param) or foo(inout param)or foo(param:inout) or whatever. I don't really care.The code for both the function definition and the call would be clearer. #Rudy

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060504/c80ea267/attachment-0001.htm 

From guido at python.org  Thu May  4 22:30:54 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 4 May 2006 13:30:54 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <20060504114107.67A2.JCARLSON@uci.edu>
References: <ca471dc20605031028q6975eb67q1b83320842eb4dc9@mail.gmail.com>
	<20060503182349.6796.JCARLSON@uci.edu>
	<20060504114107.67A2.JCARLSON@uci.edu>
Message-ID: <ca471dc20605041330n7e949e12i9b7a03123871f08a@mail.gmail.com>

Can you please post the benchmarking code?

On 5/4/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> Josiah Carlson <jcarlson at uci.edu> wrote:
> > Good point.  Making the input 1025 bytes, and performing block[:-1]
> > resulted in a running time of 13.94 seconds.
>
> I just thought of a better way of benchmarking list-like over-allocation
> semantics.
>
> For assumed smaller-sized writes:
>
> Use an array, and manually extend using extensions which are about as
> long as list overallocation, which would under-count the amount of time
> it would take to construct bytes object with generally small incremental
> writes.
>
> Then, use the smallest overallocation size as the presumed size of
> writes in the list.append()/''.join() case.  This should reasonably
> count the amount of time to generate the string in this case.
>
> If the under-counting for list-like overallocation is about the same or
> slower than the append/join, then append/join is going to be faster in
> practice for small writes.
>
>
> For larger blocks, do the same thing, only increase the 'overallocations'
> to be at least as large as the the assumed block size.
>
>                135 byte blocks    1k blocks
> append/join:     28.05s             12.11s
> list-like:       31.21s             31.50s
>
> Seems to be a clear win for append/join on both 135 byte and 1k blocks
> for constructing a 16 meg string. Reducing block size to 64 bytes gives
> list-like overallocation the benefit (append/join jumps to 50+
> seconds), which tells us that for very short blocks, list-like
> overallocation wins, but for blocks of expected ~135 bytes or larger on
> my machine, append/join wins.
>
>
>  - Josiah
>
>


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

From jimjjewett at gmail.com  Thu May  4 22:38:02 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Thu, 4 May 2006 16:38:02 -0400
Subject: [Python-3000] in-out parameters
In-Reply-To: <20060504202006.1EC572F5E9@xprdmxin.myway.com>
References: <20060504202006.1EC572F5E9@xprdmxin.myway.com>
Message-ID: <fb6fbf560605041338w7699ad3keb712bcd5b3f19ed@mail.gmail.com>

On 5/4/06, Rudy Rudolph <rudyrudolph at excite.com> wrote:
>
> // C++ does not distinguish between in-out and out parameters.
> // call them
> int x = 2; foo(x); // x is now 7
>

It is important to avoid this obfuscation.

C's &addr is slightly better, but still pretty error prone with
collections, like a string or array.


> Python:
> def foo(paramWrapper):
>     paramWrapper[0] += 5
>

or use named fields of an object

    def foo(data):
         dataobject.param3 +=5

or return a tuple if you need a multiple-values-return

    x=foo(x)
    val1, val2, val3 = foo(val4, val1, val5)

At best, adding an out parameter is the equivalent of adding in-place
operators

    a += 1
vs
    a = a + 1


-jJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060504/32064fd7/attachment.html 

From mcherm at mcherm.com  Thu May  4 22:50:27 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Thu, 04 May 2006 13:50:27 -0700
Subject: [Python-3000] in-out parameters
Message-ID: <20060504135027.zt1l7yfvrta8004w@login.werra.lunarpages.com>

[Rudy Rudolph writes to propose adding in-out parameters in Py3K]

Rudy:

Special offer, good this week only!

If you send me a sample piece of code using in-out parameters written
in any language I can understand, I will provide (free of charge!) a
translation into highly readable idiomatic Python that doesn't use
in-out parameters. I am so confident of my ability to achieve in-out
parameter behavior cleanly in Python that I am offering to post an
apology here if I think any example you provide is less than clear
when written in a Pythonic manner.

Send to "mchermside at ingdirect.com" to collect on this offer.

They're-really-not-needed-lly yours,

-- Michael Chermside


From qrczak at knm.org.pl  Thu May  4 23:42:28 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Thu, 04 May 2006 23:42:28 +0200
Subject: [Python-3000] bug in modulus?
In-Reply-To: <1f7befae0605041207k64aff52cgf7fdbf5d7fe387be@mail.gmail.com> (Tim
	Peters's message of "Thu, 4 May 2006 15:07:23 -0400")
References: <1145807918.069455.241510@i40g2000cwc.googlegroups.com>
	<4450928c$0$21107$626a54ce@news.free.fr>
	<j3L5g.18187$Fs1.621@bgtnsc05-news.ops.worldnet.att.net>
	<S7L5g.30013$eR6.27390@bgtnsc04-news.ops.worldnet.att.net>
	<1f7befae0605021030r458a371fm54f263cfaf9c90cf@mail.gmail.com>
	<ca471dc20605021047k3f464422jc1e39825d81a1a17@mail.gmail.com>
	<1f7befae0605041207k64aff52cgf7fdbf5d7fe387be@mail.gmail.com>
Message-ID: <873bfph3gb.fsf@qrnik.zagroda>

"Tim Peters" <tim.peters at gmail.com> writes:

> If Python switched to C99's definition of % for both integers and
> floats, that would work out better so far as it goes.  But Python's %
> makes much more sense for integers, so that would be a flea on the
> tail of the dog wagging the guy walking the dog (float % is rare in
> real life).

Haskell has both div & mod (as in Python) and quot & rem (as in C99).
Only for integers though.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From jcarlson at uci.edu  Fri May  5 00:35:30 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu, 04 May 2006 15:35:30 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <ca471dc20605041330n7e949e12i9b7a03123871f08a@mail.gmail.com>
References: <20060504114107.67A2.JCARLSON@uci.edu>
	<ca471dc20605041330n7e949e12i9b7a03123871f08a@mail.gmail.com>
Message-ID: <20060504152340.67AB.JCARLSON@uci.edu>


"Guido van Rossum" <guido at python.org> wrote:
> Can you please post the benchmarking code?

No problem.


 - Josiah


import time
import array

block = 1025*'\0'
block2 = array.array("B", 1024*[0])
desired_size = 16*1024*1024

incrs = []
for mns in (1024, 0):
    y = []
    x = 1024
    while x < desired_size:
        y.append(max((x>>3) + 7, mns))
        x += y[-1]
    _ = y.pop() #we'll be generous and not do the final one.
    incrs.append(y)

for k in (1024, 135, 64):
    t = time.clock()
    for i in xrange(100):
        l = []
        for j in xrange(0, desired_size, k):
            l.append(block[:k])
        l = ''.join(l)
        del l
    
    print k, time.clock()-t

z = time.clock()
for i in xrange(100):
    x = array.array("B", block2)
    del x

z = time.clock()-z

for increments in incrs:
    t = time.clock()
    for i in xrange(100):
        x = array.array("B", block2)
        for j in increments:
            x.extend(x[:j])
        del x
    print increments[0], time.clock()-t-z



From greg.ewing at canterbury.ac.nz  Fri May  5 02:45:02 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 05 May 2006 12:45:02 +1200
Subject: [Python-3000] PEP 3102 Open Issues
In-Reply-To: <loom.20060504T081530-863@post.gmane.org>
References: <loom.20060504T081530-863@post.gmane.org>
Message-ID: <445AA00E.9070600@canterbury.ac.nz>

Talin wrote:

> I have to admit that while the reasoning behind the use of the
> '*' character is logical, the logic seems a little convoluted. Part of this
> is due to the use of negative logic - the absence of something
> that would normally be there (i.e. a keyword after the '*') indicates
> a restriction on what would normally be allowed (i.e. additional
> keyword arguments.)

I don't see what's convoluted about it. If there's nothing
there to say that it's allowed, then it's not allowed.

--
Greg

From niki.spahiev at gmail.com  Fri May  5 10:05:41 2006
From: niki.spahiev at gmail.com (Niki Spahiev)
Date: Fri, 05 May 2006 11:05:41 +0300
Subject: [Python-3000] PyGUI in Py3K stdlib, more details
In-Reply-To: <4455F537.8010408@canterbury.ac.nz>
References: <06Apr30.125533pdt.58641@synergy1.parc.xerox.com>
	<4455F537.8010408@canterbury.ac.nz>
Message-ID: <445B0755.8010205@gmail.com>

Greg Ewing wrote:
> Bill Janssen wrote:
>> An editable styled-text widget would be interesting, instead of the
>> simpler editable text widget that already exists.
> 
> Yes, that's another thing I have in mind. I need to find out
> what's available on Windows before I get too carried away with
> this, however.

Scintilla is available and is very good.

HTH

Niki Spahiev


From edloper at gradient.cis.upenn.edu  Fri May  5 17:46:30 2006
From: edloper at gradient.cis.upenn.edu (Edward Loper)
Date: Fri, 5 May 2006 11:46:30 -0400
Subject: [Python-3000] Module name discovery
Message-ID: <3DA6E8CB-6102-4AD1-89A8-54082A705CE4@gradient.cis.upenn.edu>

Given the filename of a python file, I would like to be able to
determine what its __name__ will be.  I know of at least three
concrete use cases for this:

   1. Python documentation tools (pydoc, epydoc, etc) should display
      the correct 'fully qualified name' for packages and modules
      when they are specified by filename.  E.g., it is occasionally
      useful to run epydoc on just one or two modules in a package; but
      the generated docs should display the fully qualified module
      names, since that's what users will need to use to import them.

   2. Python documentation tools that rely on introspection need to
      know what "context" should be used to import modules when they're
      specified by name.  In particular, if the introspected module
      tries to import other modules in its package, then these imports
      may fail unless the directory containing the package root is added
      to sys.path.

   3. I have written a patch to python-mode.el that modifies buffer
      names to include the package name.  This is especially useful
      when you have several different subpackages: seeing
      "__init__.py (epydoc.markup)" is much more informative than
      "__init__.py<4>".

Currently, I use the following algorithm for all three of these use
cases:

   - check if the directory containing the file contains an
     __init__.py/.pyc/.pyw/etc file.  If so, assume it's in that
     package.
   - Move up a directory, and repeat, until we reach a directory
     that doesn't contain an __init__.py file (or until we reach
     the root directory).

Although this algorithm works *most* of the time, it's technically
incorrect.  In particular, since packages can modify their __path__, a
python file might belong to a package whose directory is somewhere
entirely different.

So, my question is, is there a way to restructure the package system
for py3k, such that any important use cases that are currently covered
by __path__ are still covered; but such that it's possible to map
deterministically from a filename to a fully qualified python name?  I
don't have any concrete proposals, but I just wanted to bring up the
issue as something that's bothered me with the current package system,
and that might be considered for py3k.

-Edward


From fdrake at acm.org  Fri May  5 17:59:59 2006
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri, 5 May 2006 11:59:59 -0400
Subject: [Python-3000] Module name discovery
In-Reply-To: <3DA6E8CB-6102-4AD1-89A8-54082A705CE4@gradient.cis.upenn.edu>
References: <3DA6E8CB-6102-4AD1-89A8-54082A705CE4@gradient.cis.upenn.edu>
Message-ID: <200605051159.59746.fdrake@acm.org>

On Friday 05 May 2006 11:46, Edward Loper wrote:
 >    3. I have written a patch to python-mode.el that modifies buffer
 >       names to include the package name.  This is especially useful
 >       when you have several different subpackages: seeing
 >       "__init__.py (epydoc.markup)" is much more informative than
 >       "__init__.py<4>".

For this, I use this in my ~/.emacs file:

  (setq uniquify-buffer-name-style 'post-forward)
  (setq uniquify-after-kill-buffer-p t)
  (require 'uniquify)

This creates buffer names based entirely on paths, but that's ok.  It supports 
the case of identically-named modules in completely independent source trees 
as well as different packages within a tree.

It would be nice to have a convenient function that could take a 
sys.path/sys.meta_path configuration provide the module name based on a 
filename, but it really requires that sys.path/sys.meta_path information.  
This won't always be easy for applications that do anything non-trivial to 
prepare those unless tools can run a bit of Python code to get that 
information.  (Or whatever the Py3K equivalent turns out to be.)


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From collinw at gmail.com  Fri May  5 21:30:14 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 5 May 2006 15:30:14 -0400
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <4455C828.1060209@gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
	<4455C828.1060209@gmail.com>
Message-ID: <43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>

On 5/1/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> The Type Error is actually referring to the type of 'foo' - the code is
> clearly expecting it to be something with a different __call__ signature.
>
> However, for things like functions, there's nothing wrong with the type of the
> supplied object. For functions, the problem is actually a Value Error, in that
> the signature of that particular function *instance* is wrong.

Is there anywhere else in Python where the type of an object isn't
checkable with isinstance()? While I agree this situation can be
viewed as a problem with the function's type, it seems odd to take
this view, given Python's current attitude toward typing. If this were
a language like Haskell or ML, where we were used to talking of
function types like (Int -> Int -> [Int]), then, yes, it should be a
TypeError.

Put another way, saying an invalid argument set indicates an error in
the function type feels somewhat equivalent to saying that a list of
floats in place of an expected list of ints is a problem with the list
(rather than its elements). In Haskell, this would make sense, but it
seems unintuitive in Python.

> I don't really have a preference here - the current error is a little obscure,
> but I'm not sure fixing it is worth the effort of adding a new exception type.

I would think that eliminating this obscurity is worth the minimal
overhead of a single new exception class. Really, how often do people
go reading through exceptions.c?

Collin Winter

From tjreedy at udel.edu  Fri May  5 21:46:42 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 5 May 2006 15:46:42 -0400
Subject: [Python-3000] Requirements for a standard GUI library
References: <loom.20060502T201105-105@post.gmane.org><e38g44$bfb$1@sea.gmane.org>
	<44596963.8070200@canterbury.ac.nz>
Message-ID: <e3ga30$9sq$1@sea.gmane.org>


"Greg Ewing" <greg.ewing at canterbury.ac.nz> wrote in message 
news:44596963.8070200 at canterbury.ac.nz...
> Terry Reedy wrote:
>
>> -the ability to ignore platforn standards and give an app a unique look 
>> and
>> feel.  A start on this, for instance, is being able to give dialog boxes 
>> a
>> custom background instead of uniform gray or whatever.

I should note first that I have no particular expectation that PyGUI will 
meet my wish list.

> You can do this in PyGUI by adding a View that fills the
> whole window and then adding your controls to that. You
> can draw whatever background you want in the View.

I have read the online PyGUI docs, but it is not obvious how to set a View 
background.  My only guess is to call .invalidate(), then 
with_convas(back_draw), where back_draw(canvas) paints either an Image or 
Pixmap onto canvas with the [NOT YET IMPLEMENTED] .image(args) method. 
Canvas.image seems to be your name for the basic bitblt operation.  One 
cannot do much graphical stuff beyond the basics without it.

It is also not clear how one might get a PIL or NumArray image into your 
system.  Changing widget appearance is, I know, more difficult.

>> -the ability to shift to full-screen mode.
>
> If I add some way of removing the menu bar, and finding
> out the size of the screen, then you could create a window
> that fills the whole screen. Would that be sufficient?

If you can make the entire screen blank, either black or white, without 
borders, then probably yes for static graphics (although Windows might 
still pop up notices occasionally).  I suspect that dynamics apps run 
faster when all other apps are disconnected from the screen.

But of course, the cross-platform C code to do this already exists.  PyGame 
wraps one such.  I have no idea how well PyGUI works with PyGame compared 
to other GUIs.  I may ask sometime on their list (or gmane group).

I guess what I would really like to see is an integrated Python Media And 
Graphics Interface package that does windows, work widgets, 2-d and 3-d 
graphics, video, and sound.  Perhaps the proposed multi-dimensional array 
interface would help existing compenents work better together.

Terry Jan Reedy






From guido at python.org  Fri May  5 22:55:00 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 5 May 2006 13:55:00 -0700
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
	<4455C828.1060209@gmail.com>
	<43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>
Message-ID: <ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>

On 5/5/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/1/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > The Type Error is actually referring to the type of 'foo' - the code is
> > clearly expecting it to be something with a different __call__ signature.
> >
> > However, for things like functions, there's nothing wrong with the type of the
> > supplied object. For functions, the problem is actually a Value Error, in that
> > the signature of that particular function *instance* is wrong.
>
> Is there anywhere else in Python where the type of an object isn't
> checkable with isinstance()?

Yes, it's called duck typing.

I'm not sure it's worth distinguishing call signature errors from
other type errors; there's already a gray area where sometimes a
TypeError is reported as an AttributeError or vice versa.

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

From janssen at parc.com  Sat May  6 01:28:07 2006
From: janssen at parc.com (Bill Janssen)
Date: Fri, 5 May 2006 16:28:07 PDT
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: Your message of "Fri, 05 May 2006 13:55:00 PDT."
	<ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com> 
Message-ID: <06May5.162810pdt."58641"@synergy1.parc.xerox.com>

> > Is there anywhere else in Python where the type of an object isn't
> > checkable with isinstance()?
> 
> Yes, it's called duck typing.

And, in my opinion, it's probably worth stomping out in Py3K.  It
developed as necessary because of the original dichotomy between C
classes and Python classes in Python 1, but it's now obsolete.
Mix-ins should be used instead.

Bill

From guido at python.org  Sat May  6 01:38:33 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 5 May 2006 16:38:33 -0700
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <8324284203556580454@unknownmsgid>
References: <ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>
	<8324284203556580454@unknownmsgid>
Message-ID: <ca471dc20605051638g56fcf79x8fffeba04ae2b154@mail.gmail.com>

On 5/5/06, Bill Janssen <janssen at parc.com> wrote:
> > > Is there anywhere else in Python where the type of an object isn't
> > > checkable with isinstance()?
> >
> > Yes, it's called duck typing.
>
> And, in my opinion, it's probably worth stomping out in Py3K.  It
> developed as necessary because of the original dichotomy between C
> classes and Python classes in Python 1, but it's now obsolete.
> Mix-ins should be used instead.

You want to get rid of all duck typing? That doesn't sound right to
me. Anyway it isn't enforceable. I must be misunderstanding you.

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

From guido at python.org  Sat May  6 02:45:00 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 5 May 2006 17:45:00 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <20060504152340.67AB.JCARLSON@uci.edu>
References: <20060504114107.67A2.JCARLSON@uci.edu>
	<ca471dc20605041330n7e949e12i9b7a03123871f08a@mail.gmail.com>
	<20060504152340.67AB.JCARLSON@uci.edu>
Message-ID: <ca471dc20605051745l5bfa2666g53bcf1d947af3528@mail.gmail.com>

On 5/4/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "Guido van Rossum" <guido at python.org> wrote:
> > Can you please post the benchmarking code?
>
> No problem.

OK, so I have the advantage of a time machine... Or at least the p3yk
(sic) branch. I created a perhaps more reasonable benchmark; you can
see it in SVN here:

http://svn.python.org/view/sandbox/trunk/sio/bench_cat.py?rev=45918&view=log

Run with the latest Python 3.0, this shows clearly that the += idiom
is slower than the join idiom, although not by that much. It also
shows that the straightforward mutable bytes implementation in 3.0
consistently performs better than the string implementation --
probably due to being able to resize the buffer without moving the
object. Or maybe I missed something?

The benchmark concatenates 100,000 strings with a size uniformly
chosen from range(N) where N ("size" below) is varied from 10 to 1000
for different test runs. That means the final string varies between
0.5 MB to 50 MB. Each result represents the best of 3 runs where each
run executes the above concatenation loop 10 times.

Here are the results (on a 1.67 GHz PowerBook):

------ size = 10 ------
bytes+=    0.401
bytes.join 0.221
str+=      0.552
str.join   0.279
------ size = 20 ------
bytes+=    0.419
bytes.join 0.236
str+=      0.565
str.join   0.305
------ size = 50 ------
bytes+=    0.518
bytes.join 0.340
str+=      0.713
str.join   0.405
------ size = 100 ------
bytes+=    0.654
bytes.join 0.454
str+=      0.894
str.join   0.580
------ size = 200 ------
bytes+=    0.878
bytes.join 0.642
str+=      1.179
str.join   0.823
------ size = 500 ------
bytes+=    1.678
bytes.join 1.462
str+=      2.466
str.join   1.631
------ size = 1000 ------
bytes+=    3.051
bytes.join 2.762
str+=      4.220
str.join   2.822

Gotta run,

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

From ksankar at gte.net  Sat May  6 03:00:53 2006
From: ksankar at gte.net (Krishna Sankar)
Date: Fri, 05 May 2006 20:00:53 -0500 (CDT)
Subject: [Python-3000] in-out parameters
Message-ID: <17798524.5109801146877253301.JavaMail.root@vms169.mailsrvcs.net>

I am tempted ;o) I used to diffenentiate between in and inout years ago in my Pascal and Ada days ... Eventhough this offer comes on a Thursday.

A few random observations:

a)	From what I gather, for some years, the pass by value and pass by reference has been dormant
	Ada has the in, out and inout. This makes sense in Ada as it has a very formal specification-body-separation paradigm. IMHO, Java punts this - primitives are "in" and objects are "inout".
b)	Of course, we can simulate "in" by a deep copy to a temp variable and then restoring the variable back before return. The "out" and "inout" do not need any special tratment.
c)	The intent, from what I can gather, is to provide a crispier expression of paratemter handling and also the ability to explicitly specify them in the interfaces. But in the world of immutable objects and deeply nestes object graphs, this is not that straight forward and most probably wouldn't be 100% elegant.
d)	One clear advantage is that this will minimize side effects and surprises/programming, eventually adding reliabliltiy to the systems developed using py.

Cheers
<k/>

> -----Original Message-----
> From: python-3000-bounces+ksankar=gte.net at python.org 
> [mailto:python-3000-bounces+ksankar=gte.net at python.org] On 
> Behalf Of Michael Chermside
> Sent: Thursday, May 04, 2006 1:50 PM
> To: rudyrudolph at excite.com
> Cc: python-3000 at python.org
> Subject: Re: [Python-3000] in-out parameters
> 
> [Rudy Rudolph writes to propose adding in-out parameters in Py3K]
> 
> Rudy:
> 
> Special offer, good this week only!
> 
> If you send me a sample piece of code using in-out parameters 
> written in any language I can understand, I will provide 
> (free of charge!) a translation into highly readable 
> idiomatic Python that doesn't use in-out parameters. I am so 
> confident of my ability to achieve in-out parameter behavior 
> cleanly in Python that I am offering to post an apology here 
> if I think any example you provide is less than clear when 
> written in a Pythonic manner.
> 
> Send to "mchermside at ingdirect.com" to collect on this offer.
> 
> They're-really-not-needed-lly yours,
> 
> -- Michael Chermside
> 
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-3000/ksankar%40gte.net

From janssen at parc.com  Sat May  6 06:07:04 2006
From: janssen at parc.com (Bill Janssen)
Date: Fri, 5 May 2006 21:07:04 PDT
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: Your message of "Fri, 05 May 2006 16:38:33 PDT."
	<ca471dc20605051638g56fcf79x8fffeba04ae2b154@mail.gmail.com> 
Message-ID: <06May5.210705pdt."58641"@synergy1.parc.xerox.com>

GvR writes:
> On 5/5/06, Bill Janssen <janssen at parc.com> wrote:
> > > > Is there anywhere else in Python where the type of an object isn't
> > > > checkable with isinstance()?
> > >
> > > Yes, it's called duck typing.
> >
> > And, in my opinion, it's probably worth stomping out in Py3K.  It
> > developed as necessary because of the original dichotomy between C
> > classes and Python classes in Python 1, but it's now obsolete.
> > Mix-ins should be used instead.
> 
> You want to get rid of all duck typing? That doesn't sound right to
> me. Anyway it isn't enforceable. I must be misunderstanding you.

Yes, I meant "get rid of all duck typing".  Duck typing is for
languages that can't do any better.  It's a weakness, not a strength.

Sure, it isn't enforceable (now, anyway), and I'm not sure I'd want it
to be (in Python).  But I think that the base language should be
defined terms of classes, many of which would be functional mixins,
rather than by which method names are or are not present in an
instance.  That is, "isinstance" should work properly everywhere with
the built-in and standard library types.

Bill

From jcarlson at uci.edu  Sat May  6 11:31:00 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sat, 06 May 2006 02:31:00 -0700
Subject: [Python-3000] in-out parameters
In-Reply-To: <17798524.5109801146877253301.JavaMail.root@vms169.mailsrvcs.net>
References: <17798524.5109801146877253301.JavaMail.root@vms169.mailsrvcs.net>
Message-ID: <20060506022655.67CE.JCARLSON@uci.edu>


Krishna Sankar <ksankar at gte.net> wrote:
> b)	Of course, we can simulate "in" by a deep copy to a temp variable
> and then restoring the variable back before return. The "out" and
> "inout" do not need any special tratment.

Or the writer of a function can document what the function does, and if
the caller cares about documented behavior, they will send a copy in.


> d)	One clear advantage is that this will minimize side effects and
> surprises/programming, eventually adding reliabliltiy to the systems
> developed using py.

That seems to imply that programming with Python has more surprises
and/or less reliability than other languages; a position that is not
likely to be shared by many.


 - Josiah


From talin at acm.org  Sat May  6 11:30:00 2006
From: talin at acm.org (Talin)
Date: Sat, 6 May 2006 09:30:00 +0000 (UTC)
Subject: [Python-3000] What to do about IDLE?
Message-ID: <loom.20060506T110352-762@post.gmane.org>

>From what I understand, the "mission statement" of Python 3000 is not to load
up the lanugage with a bunch of sexy new programming features, but rather to
"go back in time" and make small changes to the original Python design that have
turned out to be problematic in practice.

One of those problematic areas which has inspired much debate on this list
is the including of the Tk libraries. The libraries are certainly showing their
age, both in appearance and in API design. However, at the same time there
is a lot of capability there that will not be easy to replace.

There have been various proposals (which I won't go into here) for replacing
Tk; Whether an adequate replacement exists at the current time is debatable,
and should be the subject of a different thread.

Because IDLE uses the Tk library for its UI, it suffers from many of the same
problems. To be honest, I've always found using IDLE to be a relatively
painful experience; Just about any modern programmer's editor (I've used
SciTE, BBEdit, TextMate, and Emacs for this) does a better job as an interactive
Python development environment, not to mention the many Python IDE's
that are available.

Giving IDLE a modern UI, with even the most minimalist feature set found
in current-generation IDEs, would be a monumental task.

I'm sure that the question of whether IDLE should be fixed or dropped will
start a huge flamewar; But the alternative is to do nothing, which seems
even worse from my viewpoint.

I'd be curious to know how many Python developers actually use IDLE?
Moreover, if IDLE is going to stay, it should have a clearer mission
statement. Clearly IDLE is never going to be the top-end IDE for Python
development, so what is its purpose? To provide a "backup" in case a
top of the line IDE is not available? An introductory IDE for fledgling
Python programmers?

Here's an idea: Create a description of what IDLE *should* be. Then evaluate
the various UI toolkit proposals in light of whether or not they can support
that spec. If we feel that tree views (for a class hierarchy view) or toolbars
with tooltips are imporant, then the candidates for the UI toolkit should
be able to support that.

-- Talin



From jcarlson at uci.edu  Sat May  6 11:41:33 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sat, 06 May 2006 02:41:33 -0700
Subject: [Python-3000] characters data type
In-Reply-To: <ca471dc20605051745l5bfa2666g53bcf1d947af3528@mail.gmail.com>
References: <20060504152340.67AB.JCARLSON@uci.edu>
	<ca471dc20605051745l5bfa2666g53bcf1d947af3528@mail.gmail.com>
Message-ID: <20060506023436.67D1.JCARLSON@uci.edu>


"Guido van Rossum" <guido at python.org> wrote:
> 
> On 5/4/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> >
> > "Guido van Rossum" <guido at python.org> wrote:
> > > Can you please post the benchmarking code?
> >
> > No problem.
> 
> OK, so I have the advantage of a time machine... Or at least the p3yk
> (sic) branch. I created a perhaps more reasonable benchmark; you can
> see it in SVN here:

I like your benchmark better, and it's good to find out that bytes.join
is fast (also good to know that bytes/str.join have been shown to be
faster than += in more realistic tests).

There is, of course, the other rub that if one mixes += operations with
other operations (like let's say reading that actual data from a socket
or from a generated buffer, etc.), there is the potential for memory
fragmentation.  Probably not a big deal for everyone, but I've been bit
by it.


 - Josiah


From greg.ewing at canterbury.ac.nz  Sat May  6 13:33:40 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 06 May 2006 23:33:40 +1200
Subject: [Python-3000] What to do about IDLE?
In-Reply-To: <loom.20060506T110352-762@post.gmane.org>
References: <loom.20060506T110352-762@post.gmane.org>
Message-ID: <445C8994.3020206@canterbury.ac.nz>

Talin wrote:

> I'm sure that the question of whether IDLE should be fixed or dropped will
> start a huge flamewar; But the alternative is to do nothing, which seems
> even worse from my viewpoint.

There is another alternative -- move both Tk and IDLE out
of the core into separate downloads.

--
Greg

From bwinton at latte.ca  Sat May  6 14:05:43 2006
From: bwinton at latte.ca (Blake Winton)
Date: Sat, 06 May 2006 08:05:43 -0400
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <06May5.210705pdt."58641"@synergy1.parc.xerox.com>
References: <06May5.210705pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <445C9117.3090900@latte.ca>

Bill Janssen wrote:
> GvR writes:
>>On 5/5/06, Bill Janssen <janssen at parc.com> wrote:
>>>>>Is there anywhere else in Python where the type of an object isn't
>>>>>checkable with isinstance()?
>>>>Yes, it's called duck typing.
>>>And, in my opinion, it's probably worth stomping out in Py3K.
>>You want to get rid of all duck typing? That doesn't sound right to
>>me. Anyway it isn't enforceable. I must be misunderstanding you.
> Yes, I meant "get rid of all duck typing".  Duck typing is for
> languages that can't do any better.  It's a weakness, not a strength.

You missed April Fool's day by more than a month, Bill.

Seriously, if I wanted a language that restricted me to classes and 
subtyping and mixins, I'ld use Java.  I like being able to take classes 
that only implement the methods I need.  I like being able to do stuff like:

 >>> def f(x):
...   return x + 1
...
 >>> def y(x):
...   return x.inc(1)
...
 >>> y.inc = f
 >>> y(y)
2

Even though I probably wouldn't do it in production code.

Your suggestion also makes it much harder to write Proxy objects, 
especially if you don't know what it is you're going to be proxying 
(think SOAP or ctypes for examples).

Later,
Blake.

From solipsis at pitrou.net  Sat May  6 14:37:12 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 06 May 2006 14:37:12 +0200
Subject: [Python-3000] duck typing
In-Reply-To: <445C9117.3090900@latte.ca>
References: <06May5.210705pdt."58641"@synergy1.parc.xerox.com>
	<445C9117.3090900@latte.ca>
Message-ID: <1146919033.5703.13.camel@fsol>


Le samedi 06 mai 2006 ? 08:05 -0400, Blake Winton a ?crit :
> Bill Janssen wrote:
> > GvR writes:
> >>On 5/5/06, Bill Janssen <janssen at parc.com> wrote:
> >>>>>Is there anywhere else in Python where the type of an object isn't
> >>>>>checkable with isinstance()?
> >>>>Yes, it's called duck typing.
> >>>And, in my opinion, it's probably worth stomping out in Py3K.
> >>You want to get rid of all duck typing? That doesn't sound right to
> >>me. Anyway it isn't enforceable. I must be misunderstanding you.
> > Yes, I meant "get rid of all duck typing".  Duck typing is for
> > languages that can't do any better.  It's a weakness, not a strength.

If you want a Python-lookalike with strong static typing (and optional
duck typing with the "duck" keyword!), then try Boo:
http://boo.codehaus.org/Home

Regards

Antoine.



From collinw at gmail.com  Sat May  6 16:09:59 2006
From: collinw at gmail.com (Collin Winter)
Date: Sat, 6 May 2006 10:09:59 -0400
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
	<4455C828.1060209@gmail.com>
	<43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>
	<ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>
Message-ID: <43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com>

On 5/5/06, Guido van Rossum <guido at python.org> wrote:
> On 5/5/06, Collin Winter <collinw at gmail.com> wrote:
> > On 5/1/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > > The Type Error is actually referring to the type of 'foo' - the code is
> > > clearly expecting it to be something with a different __call__ signature.
> > >
> > > However, for things like functions, there's nothing wrong with the type of the
> > > supplied object. For functions, the problem is actually a Value Error, in that
> > > the signature of that particular function *instance* is wrong.
> >
> > Is there anywhere else in Python where the type of an object isn't
> > checkable with isinstance()?
>
> Yes, it's called duck typing.
>
> I'm not sure it's worth distinguishing call signature errors from
> other type errors; there's already a gray area where sometimes a
> TypeError is reported as an AttributeError or vice versa.

I think that this way of looking at call errors is fairly divorced
from the way programmers actually work. If you look at a call error as
a type error (or ValueError), then you're saying that the call site
arguments are correct -- you've simply used the wrong function. But
what process do you go through to fix a call-site error? Do you change
function X to match the call site or write a function with the proper
signature that wraps function X? Of course not. You change the call
site to match the signature.

Collin Winter

From ksankar at gte.net  Sat May  6 16:16:56 2006
From: ksankar at gte.net (Krishna Sankar)
Date: Sat, 06 May 2006 09:16:56 -0500 (CDT)
Subject: [Python-3000] in-out parameters
Message-ID: <14231476.1172971146925017018.JavaMail.root@vms075.mailsrvcs.net>

> > d)	One clear advantage is that this will minimize side effects and
> > surprises/programming, eventually adding reliabliltiy to 
> the systems 
> > developed using py.
> 
> That seems to imply that programming with Python has more 
> surprises and/or less reliability than other languages; a 
> position that is not likely to be shared by many.
> 
<KS>
	Nope, that is not what I meant. Eventually adding *more* reliability to py programs.
</KS>  
Cheers
<k/>

From guido at python.org  Sat May  6 17:29:57 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 6 May 2006 08:29:57 -0700
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
	<4455C828.1060209@gmail.com>
	<43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>
	<ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>
	<43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com>
Message-ID: <ca471dc20605060829r30abe8e7sddb6b4a3b53cce4c@mail.gmail.com>

On 5/6/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/5/06, Guido van Rossum <guido at python.org> wrote:
> > I'm not sure it's worth distinguishing call signature errors from
> > other type errors; there's already a gray area where sometimes a
> > TypeError is reported as an AttributeError or vice versa.
>
> I think that this way of looking at call errors is fairly divorced
> from the way programmers actually work. If you look at a call error as
> a type error (or ValueError), then you're saying that the call site
> arguments are correct -- you've simply used the wrong function. But
> what process do you go through to fix a call-site error? Do you change
> function X to match the call site or write a function with the proper
> signature that wraps function X? Of course not. You change the call
> site to match the signature.

Actually, it's symmetric. When Python issues a TypeError for 'a'+1,
which argument is wrong? It depends! The same is true in general when
the arguments don't match the function. You could have made a typo and
called a different function than you meant to call. Or it could be a
method of a different object than you expected. You could have
mis-implemented an overriding method.

Your assumption is that when you get an argument type error it's
always a bug in the call site. That's simply not true.

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

From guido at python.org  Sat May  6 17:31:46 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 6 May 2006 08:31:46 -0700
Subject: [Python-3000] in-out parameters
In-Reply-To: <14231476.1172971146925017018.JavaMail.root@vms075.mailsrvcs.net>
References: <14231476.1172971146925017018.JavaMail.root@vms075.mailsrvcs.net>
Message-ID: <ca471dc20605060831j6e8c2540rc2ef28fe68a8d51b@mail.gmail.com>

On 5/6/06, Krishna Sankar <ksankar at gte.net> wrote:
>         Nope, that is not what I meant. Eventually adding *more* reliability to py programs.

Please stop this debate. It's not going to happen. And taking
arguments from Ada and applying them to Python is not a useful way to
predict whether a particular feature is going to improve the quality
of Python programs.

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

From ksankar at gte.net  Sat May  6 17:55:39 2006
From: ksankar at gte.net (Krishna Sankar)
Date: Sat, 06 May 2006 10:55:39 -0500 (CDT)
Subject: [Python-3000] python-3000@python.org
Message-ID: <31991112.777251146930939541.JavaMail.root@vms063.mailsrvcs.net>

;o) Agreed. Enough said ...

Cheers
<k/> 

> -----Original Message-----
> From: gvanrossum at gmail.com [mailto:gvanrossum at gmail.com] On 
> Behalf Of Guido van Rossum
> Sent: Saturday, May 06, 2006 8:32 AM
> To: Krishna Sankar
> Cc: python-3000 at python.org
> Subject: Re: [Python-3000] in-out parameters
> 
> On 5/6/06, Krishna Sankar <ksankar at gte.net> wrote:
> >         Nope, that is not what I meant. Eventually adding 
> *more* reliability to py programs.
> 
> Please stop this debate. It's not going to happen. And taking 
> arguments from Ada and applying them to Python is not a 
> useful way to predict whether a particular feature is going 
> to improve the quality of Python programs.
> 
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)

From janssen at parc.com  Sat May  6 18:05:14 2006
From: janssen at parc.com (Bill Janssen)
Date: Sat, 6 May 2006 09:05:14 PDT
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: Your message of "Sat, 06 May 2006 05:05:43 PDT."
	<445C9117.3090900@latte.ca> 
Message-ID: <06May6.090516pdt."58641"@synergy1.parc.xerox.com>

> Seriously, if I wanted a language that restricted me to classes and 
> subtyping and mixins, I'ld use Java.

Sadly, Java doesn't give you the tools you need to do that.  If you
think that Java is what I'm talking about, you're misunderstanding my
suggestion, and I can see why you would have a negative reaction.

> I like being able to take classes that only implement the methods I need.

Me, too.  That's what a mixin-based approach gives you.  What's
better, you often don't have to implement any methods at all -- just
use the appropriate mixins for your new class.

Bill


From janssen at parc.com  Sat May  6 18:07:08 2006
From: janssen at parc.com (Bill Janssen)
Date: Sat, 6 May 2006 09:07:08 PDT
Subject: [Python-3000] duck typing
In-Reply-To: Your message of "Sat, 06 May 2006 05:37:12 PDT."
	<1146919033.5703.13.camel@fsol> 
Message-ID: <06May6.090711pdt."58641"@synergy1.parc.xerox.com>

> If you want a Python-lookalike with strong static typing (and optional
> duck typing with the "duck" keyword!), then try Boo:
> http://boo.codehaus.org/Home

Thanks, Antoine, but I don't want strong static typing at all.  I
wouldn't mind optional partial static typing, but what I want is
strong *dynamic* typing and a rich mixin understructure that makes it
easy to construct new classes that do exactly what I want.

Bill

From fdrake at acm.org  Sat May  6 20:28:08 2006
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Sat, 6 May 2006 14:28:08 -0400
Subject: [Python-3000] What to do about IDLE?
In-Reply-To: <445C8994.3020206@canterbury.ac.nz>
References: <loom.20060506T110352-762@post.gmane.org>
	<445C8994.3020206@canterbury.ac.nz>
Message-ID: <200605061428.08491.fdrake@acm.org>

On Saturday 06 May 2006 07:33, Greg Ewing wrote:
 > There is another alternative -- move both Tk and IDLE out
 > of the core into separate downloads.

+1


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From guido at python.org  Sat May  6 20:35:03 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 6 May 2006 11:35:03 -0700
Subject: [Python-3000] What to do about IDLE?
In-Reply-To: <200605061428.08491.fdrake@acm.org>
References: <loom.20060506T110352-762@post.gmane.org>
	<445C8994.3020206@canterbury.ac.nz>
	<200605061428.08491.fdrake@acm.org>
Message-ID: <ca471dc20605061135u2015c97age3ef03d9ddc7c1aa@mail.gmail.com>

On 5/6/06, Fred L. Drake, Jr. <fdrake at acm.org> wrote:
> On Saturday 06 May 2006 07:33, Greg Ewing wrote:
>  > There is another alternative -- move both Tk and IDLE out
>  > of the core into separate downloads.
>
> +1

Works for me.

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

From tomerfiliba at gmail.com  Sat May  6 21:57:39 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Sat, 6 May 2006 21:57:39 +0200
Subject: [Python-3000] iostack: wiki
Message-ID: <1d85506f0605061257p41a88ecbja9614cc41b2a2a05@mail.gmail.com>

http://iostack.wikispaces.com/

that's the code i've came up with. i'll be adding the rest of
the stream stack sooner or later, but the new socket
module is ready, imho. it's still a prototype, but i've done
some tests, and i like the feeling of it.

feel free to comment / test / fix bugs / suggest ideas / make
changes of your own.
i would also like to hear if that's what Guido had in mind. again,
it's only the sockets part of the iostack, but i would like to
have feedback on that before i put more time into it. does it
look promising? or should i just drop it?


-tomer

From talin at acm.org  Sat May  6 22:08:46 2006
From: talin at acm.org (Talin)
Date: Sat, 6 May 2006 20:08:46 +0000 (UTC)
Subject: [Python-3000] back with more GUI planning in a few days...
References: <06May1.173712pdt.
Message-ID: <loom.20060506T212123-352@post.gmane.org>

Bill Janssen <janssen <at> parc.com> writes:

> Folks, I've got a paper deadline looming, and helpful as this
> discussion has been in my procrastination , I need to get back to it.
> I'll take this thread up again next week, if no one else does.
> 
> Please feel free to send me mail in the meantime, and try a few things
> with PyGUI -- let's see if it's as capable as I think it is, and
> what's missing.
> 
> Bill

I am generally supportive of the idea of having a "standard" GUI in
Python 3000, but any such framework should prove it's merit in the
competitive arena of application development before being
"blessed" with official status.

There are two reasons why I think that bundling a GUI library with
Python is a good idea:

  -- It makes it possible to include GUI-based tools and applications
in the base distribution.

  -- By reducing the dependency on downloading and installing
a UI framework, it lowers the friction for developing small, one-off
UI tools. This is not so much an issue with large apps, since the
cost of choosing and installing the optimal UI package is small
compared to the development cost of the project. But for small
tools (for example, a configuration control panel), the extra step
of installing a UI framework may be significant.

However, there are some significant obstacles to be overcome before
this can happen.

First, there's no such thing as a "simple" UI toolkit. Certainly, some
toolkits are simpler than others. But as I have argued before, UIs are
a language, and that language has evolved over time, to the point
where it has a rich vocabulary of appearances and behaviors.

(One of my concerns about PyGUI is that the postings by its
proponents on this list seem to be somewhat dismissive of this
point - in other words, I get the impression that faced with the
complex vocabularity of UI designs, they would rather simplify
the visual language than deal with its full complexity. I understand
the motivation for doing so - as engineers, we all want to make
things simpler - but I think that in this case it ignores some
important realities about user and programmer expectations.)

The result is that any UI framework is going to be a large
undertaking, and there's no way around that. I know that as
a UI programmer myself, I tend to be extremely particular about
small details, and I would be hesitant to use any UI toolkit
that doesn't address those details.

Another issue is one of community acceptance. I strongly feel
that it should be the "market" of Python programmers that chooses
the UI solution, not the core developers. I approve of the decision
criteria which allowed ElementTree to become part of the standard
lib: It wasn't because ElementTree has a simple and powerful design;
it was because ElementTree has a simple and powerful design *and*
is already in widespread use. I think that a UI toolkit should have
to meet the same criteria.

Now, the good news is that there's plenty of time. Py3k isn't coming
out any time soon; If PyGUI truly is a better solution, it will have
enough time to gain the market share that it needs to meet the
criteria for inclusion.

Now, I am sure that the developers of PyGUI realize that there's
more to gaining market share than technical excellence. But I
would suggest that there are many things that they themselves
can do to foster adoption without involving the Python core
developers.

For one thing, the web site has no screen shots, which is always
the very first thing that I look at when evaluating any kind of UI
based tool. I've heard the counter-argument "But people already
know what Gtk looks like", and it doesn't wash. A UI framework
which is built on top of a platform-specific widget set can have
a major influence on the final appearance of UIs created with it,
particularly when we consider automated layout.

My point is, that seeing a screenshot gives me an aesthetic
and emotional experience that cannot be described in words.
The choice of which UI tool to use is not just a technical one.
(In fact, all technical decisions are at least partly emotional --
that is, we have gut feelings about a particular technique based
on past experiences with similar methods.)

Think about this from the point of view of a programmer who
is selecting the UI framework for their next project. We start
with a list of all of the various toolkits out there. We certainly
aren't going to spend the time to download, install, and learn
the basics of every one of them just so we can decide what's
best. What we'll do instead is narrow the list down to just a few
candidates, using the information available on each package's
web site.

Unfortunately PyGUI doesn't even make it through this first cut,
because the website has so little information.

I would like to propose a challenge to the PyGUI developers:
Select an already-existing UI application, one that is fairly
complex. I would suggest PyDev as an example. Use PyGUI
to create a mockup of this application. It doesn't have to be
a fully functional app, but the widgets should all work, including
menus and basic dialogs (such as the font dialog, file open dialog,
etc.)

Then post the screenshots of that application on the PyGUI web site,
as well as make the mockup program available for download.

At the same time, the web site should be reorganized. For example,
the change list should not be on the front page. The project should
probably have its own dedicated mailing list, or at least a wiki.

Once that is done, you will have (IMHO) the bare minimum needed
to survive that "first cut" evaluation.

-- Talin



From greg.ewing at canterbury.ac.nz  Sun May  7 02:53:14 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 07 May 2006 12:53:14 +1200
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
	<4455C828.1060209@gmail.com>
	<43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>
	<ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>
	<43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com>
Message-ID: <445D44FA.4070108@canterbury.ac.nz>

Collin Winter wrote:
> Do you change
> function X to match the call site or write a function with the proper
> signature that wraps function X? Of course not. You change the call
> site to match the signature.

Or to put it another way, calling this a TypeError assumes
that you were mistaken about which function to call. But
it's just as likely (probably more likely) that you have
the right function but the wrong arguments.

So I think it makes the most sense to have a new exception
such as ArgumentError for this. It says what is wrong
without making assumptions about how it came to be that
way. Subclass it from TypeError if you want backwards
compatibility.

--
Greg

From greg.ewing at canterbury.ac.nz  Sun May  7 02:57:30 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 07 May 2006 12:57:30 +1200
Subject: [Python-3000] in-out parameters
In-Reply-To: <14231476.1172971146925017018.JavaMail.root@vms075.mailsrvcs.net>
References: <14231476.1172971146925017018.JavaMail.root@vms075.mailsrvcs.net>
Message-ID: <445D45FA.9070900@canterbury.ac.nz>

Krishna Sankar wrote:
> Nope, that is not what I meant. Eventually adding *more* reliability to py programs.

But at what cost? There is a large downside to all
the B&D in languages like Java. One of Python's
biggest strengths is that it doesn't have any of
that.

--
Greg

From greg.ewing at canterbury.ac.nz  Sun May  7 03:37:52 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 07 May 2006 13:37:52 +1200
Subject: [Python-3000] duck typing
In-Reply-To: <06May6.090711pdt.58641@synergy1.parc.xerox.com>
References: <06May6.090711pdt.58641@synergy1.parc.xerox.com>
Message-ID: <445D4F70.2080208@canterbury.ac.nz>

Bill Janssen wrote:

> Thanks, Antoine, but I don't want strong static typing at all.  I
> wouldn't mind optional partial static typing, but what I want is
> strong *dynamic* typing

How strong do you want it, exactly?

The disadvantages associated with very strong type systems
arise because of their strength, not whether they are
static or dynamic. A language with the same type system
as Java, but enforced at run time instead of compile
time, would be just as annoying to use.

--
Greg

From talin at acm.org  Sun May  7 07:42:40 2006
From: talin at acm.org (Talin)
Date: Sun, 7 May 2006 05:42:40 +0000 (UTC)
Subject: [Python-3000] PEP 3100 Comments
Message-ID: <loom.20060507T073352-865@post.gmane.org>

I want to say that I agree with everything in PEP 3100 except for two things:

1) Getting rid of 'callable'.

The reccomended replacement is "just call the object and catch the resulting
exception", but I can think of a lot of situations where that wouldn't be
appropriate. For example, what if you want to know if something is
callable, but you don't want to call it just yet?

What if you intend on calling something 1000 times, and you'd like to
know if its callable once, instead of catching the exception 1000 times?

2) I think that 'print' should stay a statement; If you want to add a functional
equivalent, that's fine, but the simplicity of the current statement is a win.
(Plus I like not having to type the parens; the less delimiters, the more
readable the code IMHO.)

-- Talin



From greg.ewing at canterbury.ac.nz  Sun May  7 07:47:17 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 07 May 2006 17:47:17 +1200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060507T073352-865@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
Message-ID: <445D89E5.8040609@canterbury.ac.nz>

Talin wrote:

> 1) Getting rid of 'callable'.
> 
> The reccomended replacement is "just call the object and catch the resulting
> exception",

No, the recommended replacement should be "redesign your API
so that you don't need to test whether something is callable".

--
Greg

From talin at acm.org  Sun May  7 08:23:05 2006
From: talin at acm.org (Talin)
Date: Sun, 7 May 2006 06:23:05 +0000 (UTC)
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
Message-ID: <loom.20060507T082010-251@post.gmane.org>

Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:

> Talin wrote:
> 
> > 1) Getting rid of 'callable'.
> > 
> > The reccomended replacement is "just call the object and catch the resulting
> > exception",
> 
> No, the recommended replacement should be "redesign your API
> so that you don't need to test whether something is callable".

A common Python idiom is to take different actions based on the capabilities
of an object rather than its type. 'Duck Typing' is a special case of this, and
I think it's a fairly powerful technique (and deserving of more respect than
most language purists are willing to grant it.)

-- Talin


From thomas at python.org  Sun May  7 09:41:54 2006
From: thomas at python.org (Thomas Wouters)
Date: Sun, 7 May 2006 09:41:54 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060507T082010-251@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
Message-ID: <9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com>

On 5/7/06, Talin <talin at acm.org> wrote:
>
> Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes:
>
> > Talin wrote:
> >
> > > 1) Getting rid of 'callable'.
> > >
> > > The reccomended replacement is "just call the object and catch the
> resulting
> > > exception",
> >
> > No, the recommended replacement should be "redesign your API
> > so that you don't need to test whether something is callable".
>
> A common Python idiom is to take different actions based on the
> capabilities
> of an object rather than its type. 'Duck Typing' is a special case of
> this, and
> I think it's a fairly powerful technique (and deserving of more respect
> than
> most language purists are willing to grant it.)


Duck typing isn't "ask the object whether it can do this". Duck typing is
"do this". I don't believe 'taking different actions based on capabilities'
is all that common, and it certainly breaks easily. The only 'different
action' you should contemplate is 'raising an error', and calling an
uncallable object does that for you. As Greg suggests, if you don't know
whether you're supposed to call a passed-in object, or add it to another
object, or index it with another object, or use it as a class to
instantiate, you need to redesign your API. The caller knows how this object
should be handled, knows what it wants your code to do with it, and passing
it in saying "guess what I want done" is just throwing away useful
information.

It may be 'common' for programmers to try and write this kind of code
(accept either a string or an instance, a sequence or a single object, etc)
but it's certainly not a common idiom -- idioms don't suck :-)

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060507/5c8d038e/attachment-0001.htm 

From talin at acm.org  Sun May  7 10:23:57 2006
From: talin at acm.org (Talin)
Date: Sun, 7 May 2006 08:23:57 +0000 (UTC)
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com>
Message-ID: <loom.20060507T100953-336@post.gmane.org>

Thomas Wouters <thomas <at> python.org> writes:

> It may be 'common' for programmers to try and write this kind of
code (accept either a string or an instance, a sequence or a single
object, etc) but it's certainly not a common idiom -- idioms don't suck 


As an example, lets take a look at re.sub:

   sub(pattern, repl, string[, count])

The documentation says that "repl can be a string or a function" and
"If repl is a function, it is called for every non-overlapping occurrence
of pattern. The function takes a single match object argument, and
returns the replacement string."

This is certainly an example where different actions are taken based on the
type of the object. And as for this being bad style - well, if the standard
library can't be used as a model of API design -- especially a module that
has been refactored as many times as re -- then what can be?

Certainly this ability can be abused to create obscure code, but in this
particular case the usage seems reasonable and relatively straight
forward; I would hate to categorically forbid all uses of APIs that
take actions based on object type rather than strict OOP.

(Admittedly this particular case could be done without 'callable', since you
could test for string type, and assume callable otherwise. However, that's
not always going to be the case.)

-- Talin



From p.f.moore at gmail.com  Sun May  7 13:35:43 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 7 May 2006 12:35:43 +0100
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060507T100953-336@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com>
	<loom.20060507T100953-336@post.gmane.org>
Message-ID: <79990c6b0605070435o522e342fre926d9f1fc7ec88d@mail.gmail.com>

On 5/7/06, Talin <talin at acm.org> wrote:
> As an example, lets take a look at re.sub:
>
>    sub(pattern, repl, string[, count])
>
> The documentation says that "repl can be a string or a function" and
> "If repl is a function, it is called for every non-overlapping occurrence
> of pattern. The function takes a single match object argument, and
> returns the replacement string."
>
> This is certainly an example where different actions are taken based on the
> type of the object. And as for this being bad style - well, if the standard
> library can't be used as a model of API design -- especially a module that
> has been refactored as many times as re -- then what can be?
>
> Certainly this ability can be abused to create obscure code, but in this
> particular case the usage seems reasonable and relatively straight
> forward; I would hate to categorically forbid all uses of APIs that
> take actions based on object type rather than strict OOP.

Either way, the result of the following is undocumented (and arbitrary):

>>> import re
>>> re.sub('.', 'y', 'xxx')
'yyy'
>>> re.sub('.', lambda x: 'y', 'xxx')
'yyy'
>>> class guess(str):
...     def __call__(self, x): return 'z'
...
>>> re.sub('.', guess('y'), 'xxx')
'zzz'
>>> guess('y')
'y'
>>>

guess('y') is *both* a string and a callable. OK, so it's a contrived
example, but if there were two separate functions, re.sub and re.subfn
(or separate keyword parameter fn= and repl=, or any other explicit
API) the ambiguity would never occur.

It's not a big enough problem to break backward compatibility, but it
should probably be revisited for Py3K. And it's certainly not obvious
that the re.sub API is flawless...

Paul.

From greg.ewing at canterbury.ac.nz  Sun May  7 13:39:51 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 07 May 2006 23:39:51 +1200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060507T082010-251@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
Message-ID: <445DDC87.5040403@canterbury.ac.nz>

Talin wrote:

> A common Python idiom is to take different actions based on the capabilities
> of an object rather than its type.

I have no objection to that when the capability can be
tested for easily and efficiently and without danger of
causing undesirable side effects. But callability is
not such a capability, therefore I think it's a bad
idea to design an API which relies on being able to
test for it.

--
Greg

From greg.ewing at canterbury.ac.nz  Sun May  7 13:47:28 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 07 May 2006 23:47:28 +1200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060507T100953-336@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com>
	<loom.20060507T100953-336@post.gmane.org>
Message-ID: <445DDE50.6060108@canterbury.ac.nz>

Talin wrote:

> (Admittedly this particular case could be done without 'callable', since you
> could test for string type, and assume callable otherwise.

Yes, and that's exactly why it can be made to work
in this particular case. Most likely no testing for
callability is being done, only isinstance(repl, str).

This isn't so bad, because it's pretty rare for
someone to try to create a "string-like" object that
isn't a subclass of str. But callable objects can
be of any class, and such objects are frequently
used.

--
Greg

From g.brandl at gmx.net  Sun May  7 15:04:54 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 07 May 2006 15:04:54 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <445DDE50.6060108@canterbury.ac.nz>
References: <loom.20060507T073352-865@post.gmane.org>	<445D89E5.8040609@canterbury.ac.nz>	<loom.20060507T082010-251@post.gmane.org>	<9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com>	<loom.20060507T100953-336@post.gmane.org>
	<445DDE50.6060108@canterbury.ac.nz>
Message-ID: <e3kqmg$peg$1@sea.gmane.org>

Greg Ewing wrote:
> Talin wrote:
> 
>> (Admittedly this particular case could be done without 'callable', since you
>> could test for string type, and assume callable otherwise.
> 
> Yes, and that's exactly why it can be made to work
> in this particular case. Most likely no testing for
> callability is being done, only isinstance(repl, str).

Use the source, Luke:

     if (PyCallable_Check(ptemplate)) {
         /* sub/subn takes either a function or a template */
         filter = ptemplate;
         Py_INCREF(filter);
         filter_is_callable = 1;
  [...]


Georg


From solipsis at pitrou.net  Sun May  7 15:52:49 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 07 May 2006 15:52:49 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <445D89E5.8040609@canterbury.ac.nz>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
Message-ID: <1147009970.5726.14.camel@fsol>

Le dimanche 07 mai 2006 ? 17:47 +1200, Greg Ewing a ?crit :
> Talin wrote:
> 
> > 1) Getting rid of 'callable'.
> > 
> > The reccomended replacement is "just call the object and catch the resulting
> > exception",
> 
> No, the recommended replacement should be "redesign your API
> so that you don't need to test whether something is callable".

I think callable() can be useful for defensive coding.
For example, if your function expects a callback as argument, you can
check whether the callback is really callable before actually calling it
5 minutes (or 5 days) later.

Of course, it could be part of a signature checking API: first check if
the object is callable, then if it has the right signature.



From guido at python.org  Sun May  7 17:40:01 2006
From: guido at python.org (Guido van Rossum)
Date: Sun, 7 May 2006 08:40:01 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060507T073352-865@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
Message-ID: <ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>

On 5/6/06, Talin <talin at acm.org> wrote:
> I want to say that I agree with everything in PEP 3100 except for two things:
>
> 1) Getting rid of 'callable'.
>
> The reccomended replacement is "just call the object and catch the resulting
> exception", but I can think of a lot of situations where that wouldn't be
> appropriate. For example, what if you want to know if something is
> callable, but you don't want to call it just yet?

This has already been shot down by others (if you still disagree, too
bad for you, you're wasting your time). Let me just add that knowing
it is callable isn't sufficient to ensure that calling it with a
particular signature won't raise an exception. We could add something
much more useful once we have signature checking in place; but it
won't be called "callable" and it will likely have false negatives (if
the signature info is unavailable) rather than false positives (like
current callable()).

> What if you intend on calling something 1000 times, and you'd like to
> know if its callable once, instead of catching the exception 1000 times?

You could catch the exception only once, and then you'd disable the
bad callback -- if you cared at all. More likely you'd just let the
user figure it out from the first error and not worry about the rest.

> 2) I think that 'print' should stay a statement; If you want to add a functional
> equivalent, that's fine, but the simplicity of the current statement is a win.
> (Plus I like not having to type the parens; the less delimiters, the more
> readable the code IMHO.)

You obviously weren't here when this was discussed. Having it be a
function, always, is useful in many ways, several of which can be
summed up as "future transformations". E.g. turn all print statements
into log calls. This is much easier when they are already calls. Also,
the various syntactic quirks (significant trailing comma, weird >>
syntax) require time to learn and to explain.

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

From aleaxit at gmail.com  Sun May  7 18:31:44 2006
From: aleaxit at gmail.com (Alex Martelli)
Date: Sun, 7 May 2006 09:31:44 -0700
Subject: [Python-3000] duck typing
In-Reply-To: <445D4F70.2080208@canterbury.ac.nz>
References: <06May6.090711pdt.58641@synergy1.parc.xerox.com>
	<445D4F70.2080208@canterbury.ac.nz>
Message-ID: <136EA710-2F3A-4E6D-9B5A-3834F1F01DA1@gmail.com>


On May 6, 2006, at 6:37 PM, Greg Ewing wrote:
    ...
> The disadvantages associated with very strong type systems
> arise because of their strength, not whether they are
> static or dynamic. A language with the same type system
> as Java, but enforced at run time instead of compile
> time, would be just as annoying to use.

Java's typechecking IS enforced at runtime just about each and every  
time you cast something (I'm told the need for casting has diminished  
with Java 1.5's generics, but I have no experience of 1.5; earlier,  
casts abounded each time you used containers, since they contained  
Object instances).

Personally, I find the typesystems of such FP languages as Haskell to  
be the second best thing to Python's -- and yet it's extremely strong  
and totally compile-time. So, I guess what really annoys me in Java  
is the enforced _redundancy_, the impossibility of applying DRY... I  
don't really _need_ such conveniences as changing types on the fly,  
and writing typeclasses to ensure protocol adaptation is as good or  
better for me than relying on method-homonimy (and I'm sure generic- 
functions and multimethods would be just as good, too).  But I want  
to say things *once, and only once* -- Haskell's types excel at  
letting me do that (and the compiler infers things so I don't have to  
repeat myself), Python's are fine (and the runtime safeguards me  
against my errors), but Java's mandatory redundance, mixed  
compiletime/runtime checks, etc, just don't make me happy:-(.


Alex


From qrczak at knm.org.pl  Sun May  7 19:50:14 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sun, 07 May 2006 19:50:14 +0200
Subject: [Python-3000] duck typing
In-Reply-To: <136EA710-2F3A-4E6D-9B5A-3834F1F01DA1@gmail.com> (Alex
	Martelli's message of "Sun, 7 May 2006 09:31:44 -0700")
References: <06May6.090711pdt.58641@synergy1.parc.xerox.com>
	<445D4F70.2080208@canterbury.ac.nz>
	<136EA710-2F3A-4E6D-9B5A-3834F1F01DA1@gmail.com>
Message-ID: <87k68x67xl.fsf@qrnik.zagroda>

Alex Martelli <aleaxit at gmail.com> writes:

> Java's typechecking IS enforced at runtime just about each and every  
> time you cast something (I'm told the need for casting has diminished  
> with Java 1.5's generics, but I have no experience of 1.5; earlier,  
> casts abounded each time you used containers, since they contained  
> Object instances).

The same casts as before are still performed at runtime, even if the
genericized source would appear to not imply them.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From gvwilson at cs.utoronto.ca  Sun May  7 19:57:34 2006
From: gvwilson at cs.utoronto.ca (Greg Wilson)
Date: Sun, 7 May 2006 13:57:34 -0400 (EDT)
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <mailman.20468.1146940506.27774.python-3000@python.org>
References: <mailman.20468.1146940506.27774.python-3000@python.org>
Message-ID: <Pine.GSO.4.58.0605071357030.23597@qew.cs>

> From: Greg Ewing <greg.ewing at canterbury.ac.nz>
> There is another alternative -- move both Tk and IDLE out of the core
> into separate downloads.

+1.

Greg

From collinw at gmail.com  Sun May  7 20:47:36 2006
From: collinw at gmail.com (Collin Winter)
Date: Sun, 7 May 2006 14:47:36 -0400
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <ca471dc20605060829r30abe8e7sddb6b4a3b53cce4c@mail.gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
	<4455C828.1060209@gmail.com>
	<43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>
	<ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>
	<43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com>
	<ca471dc20605060829r30abe8e7sddb6b4a3b53cce4c@mail.gmail.com>
Message-ID: <43aa6ff70605071147g5820c0aet61db0290bfca46e7@mail.gmail.com>

On 5/6/06, Guido van Rossum <guido at python.org> wrote:
> On 5/6/06, Collin Winter <collinw at gmail.com> wrote:
> > On 5/5/06, Guido van Rossum <guido at python.org> wrote:
> > > I'm not sure it's worth distinguishing call signature errors from
> > > other type errors; there's already a gray area where sometimes a
> > > TypeError is reported as an AttributeError or vice versa.
> >
> > I think that this way of looking at call errors is fairly divorced
> > from the way programmers actually work. If you look at a call error as
> > a type error (or ValueError), then you're saying that the call site
> > arguments are correct -- you've simply used the wrong function. But
> > what process do you go through to fix a call-site error? Do you change
> > function X to match the call site or write a function with the proper
> > signature that wraps function X? Of course not. You change the call
> > site to match the signature.
>
> Actually, it's symmetric. When Python issues a TypeError for 'a'+1,
> which argument is wrong? It depends! The same is true in general when
> the arguments don't match the function. You could have made a typo and
> called a different function than you meant to call.

Which is more common: mistyping a single keyword or omitting an
argument in a function call (wrong arguments, right function), or a
mistyping a function name such that you miraculously end up with a
function anyway (right arguments, wrong function)?

Python shouldn't pander to people who name functions 'aaa', 'aab', 'aac', ...

> Or it could be a method of a different object than you expected.

Then it's the type of the object that's erroneous, no?

> You could have mis-implemented an overriding method.

True, but I still think that calling this an ArgumentError makes more
sense: it lets you know that the arguments don't match the signature.

> Your assumption is that when you get an argument type error it's
> always a bug in the call site. That's simply not true.

Your assumption is that the call site should be trusted over the
function's signature. I prefer to trust the thing I write once, rather
than the thing I write dozens of times.

I will concede that introducing ArgumentError might indeed result in
some false positives in relatively rare cases. However, I think this
is acceptable in exchange for a more intuitive error message in the
vast majority of cases.

This -- more intuitive error messages -- is really what I'm after, and
while you may think of type of "def foo(a, b, c):..." as "a function
with three required arguments", I'd wager that most Python
programmers, if asked what type foo has, would say simply, "it's a
function".

Collin Winter

From p.f.moore at gmail.com  Sun May  7 21:30:27 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 7 May 2006 20:30:27 +0100
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <Pine.GSO.4.58.0605071357030.23597@qew.cs>
References: <mailman.20468.1146940506.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605071357030.23597@qew.cs>
Message-ID: <79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>

On 5/7/06, Greg Wilson <gvwilson at cs.utoronto.ca> wrote:
> > From: Greg Ewing <greg.ewing at canterbury.ac.nz>
> > There is another alternative -- move both Tk and IDLE out of the core
> > into separate downloads.
>
> +1.

If the implication here is that there is *no* GUI in the Python
standard library, I'd be cautious of this (-0, probably). Things like
the pydoc server use a little GUI window. The Twisted installer (IIRC)
uses a Gui window while running the postinstall script, etc.
Basically, if a generic Python script wants some form of GUI. Tk is
available.

I've no problem with replacing Tk with an alternative. But there
should be a GUI of some sort.

Paul.

From talin at acm.org  Sun May  7 22:43:58 2006
From: talin at acm.org (Talin)
Date: Sun, 7 May 2006 20:43:58 +0000 (UTC)
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
Message-ID: <loom.20060507T221833-633@post.gmane.org>

Guido van Rossum <guido <at> python.org> writes:

> > 1) Getting rid of 'callable'.
> >
> > The reccomended replacement is "just call the object and catch the resulting
> > exception", but I can think of a lot of situations where that wouldn't be
> > appropriate. For example, what if you want to know if something is
> > callable, but you don't want to call it just yet?
> 
> This has already been shot down by others (if you still disagree, too
> bad for you, you're wasting your time). Let me just add that knowing
> it is callable isn't sufficient to ensure that calling it with a
> particular signature won't raise an exception. We could add something
> much more useful once we have signature checking in place; but it
> won't be called "callable" and it will likely have false negatives (if
> the signature info is unavailable) rather than false positives (like
> current callable()).
> 
> > What if you intend on calling something 1000 times, and you'd like to
> > know if its callable once, instead of catching the exception 1000 times?
> 
> You could catch the exception only once, and then you'd disable the
> bad callback -- if you cared at all. More likely you'd just let the
> user figure it out from the first error and not worry about the rest.

All right, I'll desist. Not because I'm convinced, but because I realize
that the existing behavior of "callable" isn't really what I want anyway.
What I really want is to be able to answer the question: "Is 'x' an object
that conforms to the naive, everyday concept of a function?" This is
distinct from the existing callable, which attempts to answer the
question: "If I attempt to call 'x', will I get an error?"

How about instead of 'callable', an "isFunction' test to go along
with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
I hope...?)

My meta-concern here is this: One of the things I like about
Python is that I am free to engage in other forms of program
organization than just OOP. I realize that we all were taught
the rules of OOP in comp sci 101 (well, ok, OOP was invented
after I learned programming, but still...), but there are a lot of
interesting alternatives - aspect-oriented programming, logic
programming, expert systems, etc.

Yet, I feel like in this case I'm being told that my testing of the
type of an object is "bad style" because it's non-OOP. While there
may be valid criticisms of this technique, this particular criticism
seems falsely reductionist.

(Also, I think that using exceptions as general flow-control
constructs is a bigger style wart than type testing - but I've
already resigned myself to the fact that the Python community
doesn't agree with me on this point either. :)

> You obviously weren't here when this was discussed. Having it be a
> function, always, is useful in many ways, several of which can be
> summed up as "future transformations". E.g. turn all print statements
> into log calls. This is much easier when they are already calls. Also,
> the various syntactic quirks (significant trailing comma, weird >>
> syntax) require time to learn and to explain.

Actually, I did read all those discussions, but I changed my mind :)

I'm not sure that I buy the 'time to learn and explain' argument.
If we take that to its logical extreme, then we should be
using Lisp, since there's only a single syntactical constructs to
learn and explain.

To my mind, the purpose of syntax is to act as a scaffolding to
hold ideas in place in a way that allows us to easily recognize them.
To that extent, a syntax should neither be too simple or too
complicated, just as an alphabet should neither be too large
nor too small.

As far as re-routing print goes, what's the difference between
that and simply redirecting stdout? (Or providing some other
hook.)

-- Talin



From qrczak at knm.org.pl  Sun May  7 23:01:59 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sun, 07 May 2006 23:01:59 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060507T221833-633@post.gmane.org> (talin@acm.org's
	message of "Sun, 7 May 2006 20:43:58 +0000 (UTC)")
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
Message-ID: <87veshpn08.fsf@qrnik.zagroda>

Talin <talin at acm.org> writes:

> How about instead of 'callable', an "isFunction' test to go along
> with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
> I hope...?)

Such predicates, unless backed by some explicit or strict criterion
like isinstance, are as suspicious for me as checking function arity.
They don't survive generic wrappers.

What would isFunction exactly mean?

IMHO duck typing makes sense only if it's not used to discriminate
what interfaces the given object supports, but only to provide an
already expected interface. In order to declare that an interface
is supported and to be able to recognize it, subtyping is better.

Unfortunately it must be decided early that the given interface
should be discoverable by subtyping.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From janssen at parc.com  Sun May  7 23:24:08 2006
From: janssen at parc.com (Bill Janssen)
Date: Sun, 7 May 2006 14:24:08 PDT
Subject: [Python-3000] duck typing
In-Reply-To: Your message of "Sat, 06 May 2006 18:37:52 PDT."
	<445D4F70.2080208@canterbury.ac.nz> 
Message-ID: <06May7.142417pdt."58641"@synergy1.parc.xerox.com>

> A language with the same type system
> as Java, but enforced at run time instead of compile
> time, would be just as annoying to use.

Python already has a different, and in many respects better, type
system than Java has.  I'm simply suggesting that the common practice
of ignoring -- or worse, subverting -- the type system, necessary
before the type unification work, be discouraged.

I don't want to ever again use a library that claims to export a
"dict" object, only to find (later) that the implementor hasn't
implemented some of the methods of the real "dict" type because he
thought they wouldn't be called.  Or because he was too lazy to
document the interface he'd actually implemented.  "Duck typing"
encourages this kind of ramshackle development.

I think that there is little of advantage in the Java type system to
be adopted into Python.  One possible addition is the often-discussed
optional type declarations and associated ability to define an
interface for a module or class.

Bill

From phd at mail2.phd.pp.ru  Sun May  7 23:51:57 2006
From: phd at mail2.phd.pp.ru (Oleg Broytmann)
Date: Mon, 8 May 2006 01:51:57 +0400
Subject: [Python-3000] Java type system and exceptions (was: duck typing)
In-Reply-To: <06May7.142417pdt."58641"@synergy1.parc.xerox.com>
References: <445D4F70.2080208@canterbury.ac.nz>
	<06May7.142417pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <20060507215156.GA15329@phd.pp.ru>

On Sun, May 07, 2006 at 02:24:08PM -0700, Bill Janssen wrote:
> I think that there is little of advantage in the Java type system to
> be adopted into Python.

   One thing from Java I really miss in Python - declaration what
exception(s) a function/method can raise. Almost nobody almost never
documents this, especially if the function/method calls other functions and
methods.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From brett at python.org  Mon May  8 00:37:34 2006
From: brett at python.org (Brett Cannon)
Date: Sun, 7 May 2006 15:37:34 -0700
Subject: [Python-3000] Java type system and exceptions (was: duck typing)
In-Reply-To: <20060507215156.GA15329@phd.pp.ru>
References: <445D4F70.2080208@canterbury.ac.nz>
	<20060507215156.GA15329@phd.pp.ru>
Message-ID: <bbaeab100605071537o3c785703kb07989f8857ec58e@mail.gmail.com>

On 5/7/06, Oleg Broytmann <phd at oper.phd.pp.ru> wrote:
>
> On Sun, May 07, 2006 at 02:24:08PM -0700, Bill Janssen wrote:
> > I think that there is little of advantage in the Java type system to
> > be adopted into Python.
>
>    One thing from Java I really miss in Python - declaration what
> exception(s) a function/method can raise. Almost nobody almost never
> documents this, especially if the function/method calls other functions
> and
> methods.



Checked exceptions are the worst feature of Java in my opinion.  =)


People poorly documenting should not force us to have to make up for their
carelessness.  We are all adults after all.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060507/dca33ce7/attachment.htm 

From thomas at python.org  Mon May  8 01:08:18 2006
From: thomas at python.org (Thomas Wouters)
Date: Mon, 8 May 2006 01:08:18 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060507T221833-633@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
Message-ID: <9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com>

On 5/7/06, Talin <talin at acm.org> wrote:

> All right, I'll desist.


[insert distinct sound of persistance]

How about instead of 'callable', an "isFunction' test to go along
> with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
> I hope...?)


He is, and for the same reasons as callable(): there is no way to tell
whether an object is a mapping or a sequence (considering Python object of
both 'types' implement __getitem__, and that's it. If you don't believe me,
ask isSequence about UserDict.). You can guess, but guessing is not what
Python should do. If you want to make your library guess, feel free (and
document it), but it has no place in language specifics.

(On the other hand, it looks like Guido will put in a form of adaptation or
generics, which would solve *both* your problems.)
>
>
> Yet, I feel like in this case I'm being told that my testing of the
> type of an object is "bad style" because it's non-OOP. While there
> may be valid criticisms of this technique, this particular criticism
> seems falsely reductionist.


It's bad style has nothing to do with OOP, but with ducktyping (which is
unrelated to OOP as such.) Python is deeply invested in ducktyping, and it
isn't going to change. At best, there will be (optional)
adaptation/genericity, which is more or less a formalized ducktyping.

I'm not sure that I buy the 'time to learn and explain' argument.
> If we take that to its logical extreme, then we should be
> using Lisp, since there's only a single syntactical constructs to
> learn and explain.


'print' itself is a logical extremity in the other direction, and it proved
its own disservitude in that regard. It's not the vanguard of an assault at
Python's grammar.

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060508/c991e20f/attachment.html 

From talin at acm.org  Mon May  8 02:23:07 2006
From: talin at acm.org (Talin)
Date: Mon, 8 May 2006 00:23:07 +0000 (UTC)
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com>
Message-ID: <loom.20060508T015833-308@post.gmane.org>

Thomas Wouters <thomas <at> python.org> writes:

> On 5/7/06, Talin <talin <at> acm.org> wrote:
>
> > How about instead of 'callable', an "isFunction' test to go alongwith
> > 'isSequence' and 'isMapping'. (You aren't getting rid of those
> > - I hope...?)
> 
> He is, and for the same reasons as callable(): there is no way to
> tell whether an object is a mapping or a sequence (considering
> Python object of both 'types' implement __getitem__, and that's
> it. If you don't believe me, ask isSequence about UserDict.).
> You can guess, but guessing is not what Python should 
> do. If you want to make your library guess, feel free (and
> document it), but it has no place in language specifics.

Some of the best Python libraries out there (IMHO) have functions
that test their arguments to determine if they are a sequence or not.

As an example, check out section 4: "Content Producing Constructs" in the
Kid docs:

   http://kid.lesscode.org/language.html

I'll summarize it here: In Kid, all content producing constructs, such as
${name} and py:attr, use the same set of rules for what types of objects
may result from the Python expression they contain.

   str, unicode - The string is inserted as XML CDATA.
   ElementTree.Element - When an ElementTree.Element is referenced from a
      content producing construct, the item is inserted into the document
      literally, i.e. it is not encoded as text, but becomes part of the output
      structure.
   sequence - If a sequence type (list, tuple, or other iterable) is referenced,
      the rules are applied to each of the items in the sequence. For example,
      you could reference a list containing an Element and a string.
   Other - If the result of evaluating the expression is any other type, an
      attempt is made to coerce the value to unicode as if by calling
      unicode(expr) and processing continues as if the object were a string
      or unicode object initially.

My reaction on reading this the first time was "Wow, what a sensible
API!"

Lets say we outlaw the use of isSequence - how do you propose to
implement this type of pattern? Or are you saying that this pattern is
bad style?

If you want another example, look at Scons.

And I agree that isSequence is theoretically ambiguous - but I've never
run across a case where it didn't do the right thing. Yes, there are
edge-cases that can return the wrong answer, but in practice
these edge cases don't tend to happen, at least not in my experience,
because most of the time when someone passes in a sequence as
an argument, it really is a sequence, not some pseudo-combination
of sequence and something else.

I would hate to be told that I'm not allowed to test whether something
is a sequence or not.

-- Talin



From greg.ewing at canterbury.ac.nz  Mon May  8 02:55:43 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 08 May 2006 12:55:43 +1200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
References: <mailman.20468.1146940506.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605071357030.23597@qew.cs>
	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
Message-ID: <445E970F.6020303@canterbury.ac.nz>

Paul Moore wrote:

> If the implication here is that there is *no* GUI in the Python
> standard library, I'd be cautious of this (-0, probably). Things like
> the pydoc server use a little GUI window.

There *isn't* currently any GUI in the core distribution
except on Windows. Non-Windows users already have to
install Tk separately if they want to use IDLE or any
of the other things that use it. So I don't see this as
a big deal.

--
Greg

From greg.ewing at canterbury.ac.nz  Mon May  8 03:08:42 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 08 May 2006 13:08:42 +1200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060507T221833-633@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
Message-ID: <445E9A1A.8010905@canterbury.ac.nz>

Talin wrote:

> How about instead of 'callable', an "isFunction' test to go along
> with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
> I hope...?)

Yes, we are! And for much the same reasons!

And *how* exactly would you implement your isFunction test
so as to detect the "naive, everyday concept of a function"
that you seem to want, in a way that does any better job
than the current callable()?

--
Greg

From greg.ewing at canterbury.ac.nz  Mon May  8 03:14:35 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 08 May 2006 13:14:35 +1200
Subject: [Python-3000] duck typing
In-Reply-To: <06May7.142417pdt.58641@synergy1.parc.xerox.com>
References: <06May7.142417pdt.58641@synergy1.parc.xerox.com>
Message-ID: <445E9B7B.4040600@canterbury.ac.nz>

Bill Janssen wrote:

> I think that there is little of advantage in the Java type system to
> be adopted into Python.  One possible addition is the often-discussed
> optional type declarations and associated ability to define an
> interface for a module or class.

The problem with something like this being optional is
that a programmer too lazy to either implement a full dict
interface or document what he has implemented will also
likely be too lazy to bother using the optional interface
definition stuff.

And if it's *not* optional, duck typing goes out the
window completely, and you have Java.

--
Greg

From msoulier at digitaltorque.ca  Mon May  8 03:50:04 2006
From: msoulier at digitaltorque.ca (Michael P. Soulier)
Date: Sun, 7 May 2006 21:50:04 -0400
Subject: [Python-3000] Java type system and exceptions (was: duck typing)
In-Reply-To: <bbaeab100605071537o3c785703kb07989f8857ec58e@mail.gmail.com>
References: <445D4F70.2080208@canterbury.ac.nz>
	<20060507215156.GA15329@phd.pp.ru>
	<bbaeab100605071537o3c785703kb07989f8857ec58e@mail.gmail.com>
Message-ID: <20060508015004.GA25964@tigger.digitaltorque.ca>

On 07/05/06 Brett Cannon said:

> Checked exceptions are the worst feature of Java in my opinion.  =)

Seconded. This basically results in people writing methods that all throw
Exception, instead of something useful. Otherwise, if you make a small change
in your code, you'll find that it's not localized to that code. 

Lets not get into Java envy please. If I want Java I'll use it.

Mike

-- 
Michael P. Soulier <msoulier at digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20060507/731f36d3/attachment.pgp 

From aahz at pythoncraft.com  Mon May  8 03:52:53 2006
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 7 May 2006 18:52:53 -0700
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <445E970F.6020303@canterbury.ac.nz>
References: <mailman.20468.1146940506.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605071357030.23597@qew.cs>
	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
	<445E970F.6020303@canterbury.ac.nz>
Message-ID: <20060508015253.GA10313@panix.com>

On Mon, May 08, 2006, Greg Ewing wrote:
> Paul Moore wrote:
>> 
>> If the implication here is that there is *no* GUI in the Python
>> standard library, I'd be cautious of this (-0, probably). Things like
>> the pydoc server use a little GUI window.
>
> There *isn't* currently any GUI in the core distribution except on
> Windows. Non-Windows users already have to install Tk separately if
> they want to use IDLE or any of the other things that use it. So I
> don't see this as a big deal.

First of all, Mac users downloading a release get Tk automatically.
Secondly, your argument sounds like a variant of the argument against
adding pysqlite to the core, which I think has some technical merit but
little actual merit.  A library can certainly be part of the core
distribution even if it has dependencies on external libraries.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours."  --Richard Bach

From janssen at parc.com  Mon May  8 04:07:16 2006
From: janssen at parc.com (Bill Janssen)
Date: Sun, 7 May 2006 19:07:16 PDT
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: Your message of "Sun, 07 May 2006 18:52:53 PDT."
	<20060508015253.GA10313@panix.com> 
Message-ID: <06May7.190717pdt."58641"@synergy1.parc.xerox.com>

Aahz,

> First of all, Mac users downloading a release get Tk automatically.

Good idea!

I run on a Mac, and don't download -- I use the pre-installed Python
on the Mac.  And there's no Tk.

Much as we might like to think otherwise, there's no standard GUI in
the Python core, and IDLE (or anything else that depends on it) won't
work in some cases where it should work.

Bill

From steven.bethard at gmail.com  Mon May  8 04:23:09 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sun, 7 May 2006 20:23:09 -0600
Subject: [Python-3000] PEP 3002 (Procedure for Backwards-Incompatible
	Changes)
In-Reply-To: <ca471dc20605011525m627f8e7cvcbbd599f200a2fdf@mail.gmail.com>
References: <ca471dc20604271443v2fc525e6q286b5d5deff97228@mail.gmail.com>
	<d11dcfba0604292007i4fdf3a18qd4c98060fb14e06e@mail.gmail.com>
	<ca471dc20605011525m627f8e7cvcbbd599f200a2fdf@mail.gmail.com>
Message-ID: <d11dcfba0605071923v38a757ebv982547f3e9cf8879@mail.gmail.com>

On 5/1/06, Guido van Rossum <guido at python.org> wrote:
> On 4/29/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > Yes, I think it definitely makes more sense to make the modifications
> > on 2.x.  I was hesitant to require integrating it into the main-line
> > Python 2.x code because I was worried about affecting performance.
> > But of course with a command-line flag, that point is moot.  So
> > basically python3warn.py could be become "python -SOME_OPTION" where
> > SOME_OPTION would enable all the Python 3.0 checks.
> >
> > So I guess the question then is what the option should enable.  Should
> > it try to implement the Python 3.0 behavior?  Or should it just warn
> > when the behavior is changed?  The former requires much more Python
> > 3.0 code to be back-ported to Python 2.X, but would presumably give
> > much better error reporting.  I'd love to require that, but I'm afraid
> > of the work it would take.
>
> It should continue to use the 2.x semantics to the greatest extent
> possible, while issueing warnings about any constructs whose semantics
> will change in 3.0.
>
> I have a fairly elaborate example in mind: with this new flag,
> dict.keys() should return a subclass of list which behaves exactly
> like list except that it issues a warning whenever you use any method
> other than __iter__(). This should be transparent except to the most
> demanding code (the subclass could theoretically cause programs to
> behave differently but in practice I doubt it will change much) and
> should catch any code that uses the result of keys() other than to
> loop over it; at the same time it will not complain about code that
> simply assigns keys() to a variable and later (perhaps in a different
> function) loops over that variable.

Sorry this took so long, but I've finally updated the PEP (stealing
your example above) so that it requires patches to the Python 2.X
repository.  From the updated PEP:

Identifying Problematic Code
============================

In addition to the PEP requirement, backwards incompatible changes to
Python must also be accompanied by code to issue warnings for pieces
of Python 2.X code that will behave differently in Python 3000. Such
warnings will be enabled in Python 2.X using a new command-line
switch: --python3. All backwards incompatible changes should be
accompanied by a patch for Python 2.X that, when --python3 is
specified, issues warnings for each construct that is being changed.

For example, if ``dict.keys()`` returns an iterator in Python 3000,
the patch to the Python 2.X branch should do something like:

    If --python3 was specified, change ``dict.keys()`` to return a
    subclass of ``list`` that issues warnings whenever you use any
    methods other than ``__iter__()``.

Such a patch would mean that warnings are only issued when features
that will not be present in Python 3000 are used, and almost all
existing code should continue to work. (Code that relies on
``dict.keys()`` always returning a ``list`` and not a subclass should
be pretty much non-existent.)


STeVe
--
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From guido at python.org  Mon May  8 04:45:22 2006
From: guido at python.org (Guido van Rossum)
Date: Sun, 7 May 2006 19:45:22 -0700
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <43aa6ff70605071147g5820c0aet61db0290bfca46e7@mail.gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
	<4455C828.1060209@gmail.com>
	<43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>
	<ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>
	<43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com>
	<ca471dc20605060829r30abe8e7sddb6b4a3b53cce4c@mail.gmail.com>
	<43aa6ff70605071147g5820c0aet61db0290bfca46e7@mail.gmail.com>
Message-ID: <ca471dc20605071945x3fd2c407hd29e7973b5ff6232@mail.gmail.com>

On 5/7/06, Collin Winter <collinw at gmail.com> wrote:
> This -- more intuitive error messages -- is really what I'm after, and
> while you may think of type of "def foo(a, b, c):..." as "a function
> with three required arguments", I'd wager that most Python
> programmers, if asked what type foo has, would say simply, "it's a
> function".

Then introducing a new exception isn't going to make a difference.
Feel free to submit a patch that improves the wording of the text of
the error messages.

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

From mozbugbox at yahoo.com.au  Mon May  8 04:53:50 2006
From: mozbugbox at yahoo.com.au (JustFillBug)
Date: Mon, 8 May 2006 02:53:50 +0000 (UTC)
Subject: [Python-3000] pythond: A system wide python daemon?
Message-ID: <slrne5tclu.ptt.mozbugbox@mozbugbox.somehost.org>


Is it possible to include a python daemon that will shorten startup time
and share most stdlib among all the python instances? If extension
libraries like pygtk can also be sured in memory, then maybe the total
memory usage can be greatly reduced for python gui applications. That
will encourage people write more python GUI application without worrying
bloatness in memory requirment:

A simple:
Python 2.3.5 (#2, Mar  6 2006, 10:12:24) 
[GCC 4.0.3 20060304 (prerelease) (Debian 4.0.2-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygtk;pygtk.require('2.0')
>>> import gtk
>>> w = gtk.Window()
>>> 

Cause:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user     26585  0.6  1.1  18676  9280 pts/6    T    10:48   0:00 python



From guido at python.org  Mon May  8 06:21:09 2006
From: guido at python.org (Guido van Rossum)
Date: Sun, 7 May 2006 21:21:09 -0700
Subject: [Python-3000] pythond: A system wide python daemon?
In-Reply-To: <slrne5tclu.ptt.mozbugbox@mozbugbox.somehost.org>
References: <slrne5tclu.ptt.mozbugbox@mozbugbox.somehost.org>
Message-ID: <ca471dc20605072121m6d1503a4g8a007638a047077b@mail.gmail.com>

This is not a Py3k topic. I suspect this can be done easily today if
you need it. Please post to comp.lang.python instead.

--Guido

On 5/7/06, JustFillBug <mozbugbox at yahoo.com.au> wrote:
>
> Is it possible to include a python daemon that will shorten startup time
> and share most stdlib among all the python instances? If extension
> libraries like pygtk can also be sured in memory, then maybe the total
> memory usage can be greatly reduced for python gui applications. That
> will encourage people write more python GUI application without worrying
> bloatness in memory requirment:
>
> A simple:
> Python 2.3.5 (#2, Mar  6 2006, 10:12:24)
> [GCC 4.0.3 20060304 (prerelease) (Debian 4.0.2-10)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import pygtk;pygtk.require('2.0')
> >>> import gtk
> >>> w = gtk.Window()
> >>>
>
> Cause:
> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
> user     26585  0.6  1.1  18676  9280 pts/6    T    10:48   0:00 python
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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

From talin at acm.org  Mon May  8 08:58:39 2006
From: talin at acm.org (Talin)
Date: Sun, 07 May 2006 23:58:39 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <445E9A1A.8010905@canterbury.ac.nz>
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<445E9A1A.8010905@canterbury.ac.nz>
Message-ID: <445EEC1F.8060303@acm.org>

Greg Ewing wrote:

> Talin wrote:
> 
>> How about instead of 'callable', an "isFunction' test to go along
>> with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
>> I hope...?)
> 
> 
> Yes, we are! And for much the same reasons!

I'll have more to say on this later - but for now, lets just say that 
from what I have seen so far, Py3K's ability to do interface discovery 
seems to be limited to just isinstance(), which essentially means that 
you can't do interface discovery on any type that doesn't have a formal 
interface; And since the whole point of duck typing (in fact, the very 
definition of duck typing) is to not have a formal interface, I think 
that this creates a rather large disconnect, and in particular it makes 
duck typing a second class citizen to formalized typing.

Before we go to much further on this point, I want to get a sense of 
what exactly people are objecting to:

    -- Are they saying that interface discovery is not important, or is 
bad style? (Its hard to do general transformations of objects from one 
form to another without it.)

    -- Are they saying that the way isSequence and such implements 
interface discovery is wrong, and if it is, what's the alternative?

    -- Are they saying that interface discovery should be limited to 
formal types only, and not implicitly defined "duck types"?

    -- Are they proposing some different model of interface discovery 
that they feel is better?

    -- Are they saying that duck types are wrong?

> And *how* exactly would you implement your isFunction test
> so as to detect the "naive, everyday concept of a function"
> that you seem to want, in a way that does any better job
> than the current callable()?

This 'isFunction' test that I am thinking of would only return true for 
user defined functions, built-in functions, and similar objects; It 
would not return true for classes or other objects that are technically 
functions in a mathematically pure sense, but which normal people don't 
think of as functions.

In other words, a function that does what most people expect it to, by 
conforming to their intuitive idea of what a function is, rather than 
some grammatical or mathematical definition. And in cases of ambiguity, 
it would be conservative, returning false negatives but not false positives.

-- Talin

From p.f.moore at gmail.com  Mon May  8 09:42:16 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 8 May 2006 08:42:16 +0100
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <445E970F.6020303@canterbury.ac.nz>
References: <mailman.20468.1146940506.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605071357030.23597@qew.cs>
	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
	<445E970F.6020303@canterbury.ac.nz>
Message-ID: <79990c6b0605080042l8ce3b30p94d921126e781113@mail.gmail.com>

On 5/8/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Paul Moore wrote:
>
> > If the implication here is that there is *no* GUI in the Python
> > standard library, I'd be cautious of this (-0, probably). Things like
> > the pydoc server use a little GUI window.
>
> There *isn't* currently any GUI in the core distribution
> except on Windows. Non-Windows users already have to
> install Tk separately if they want to use IDLE or any
> of the other things that use it. So I don't see this as
> a big deal.

Ah. My apologies - I didn't check my facts carefully enough.

Paul.

From p.f.moore at gmail.com  Mon May  8 09:46:04 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 8 May 2006 08:46:04 +0100
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060508T015833-308@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com>
	<loom.20060508T015833-308@post.gmane.org>
Message-ID: <79990c6b0605080046j7f3cacfmce62a202eed14908@mail.gmail.com>

On 5/8/06, Talin <talin at acm.org> wrote:
> Lets say we outlaw the use of isSequence - how do you propose to
> implement this type of pattern? Or are you saying that this pattern is
> bad style?

Generic (overloadable) functions. See the archives - it's possible the
discussion was before you subscribed to the list, I don't recall
seeing your postings here until after then.

Generic functions are a perfect fit for this type of API.

Paul.

From rasky at develer.com  Mon May  8 09:57:03 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Mon, 8 May 2006 09:57:03 +0200
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org><ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com><loom.20060507T221833-633@post.gmane.org><9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com><loom.20060508T015833-308@post.gmane.org>
	<79990c6b0605080046j7f3cacfmce62a202eed14908@mail.gmail.com>
Message-ID: <059901c67274$fe392ad0$53b02997@bagio>

Paul Moore <p.f.moore at gmail.com> wrote:

>> Lets say we outlaw the use of isSequence - how do you propose to
>> implement this type of pattern? Or are you saying that this pattern
>> is bad style?
>
> Generic (overloadable) functions. See the archives - it's possible the
> discussion was before you subscribed to the list, I don't recall
> seeing your postings here until after then.
>
> Generic functions are a perfect fit for this type of API.


Uh? This is immaterial. Generic functions still have to do some sort of
dispatching, behind the hood. How do they do that? With isinstance only? So,
how do you propose to implement a genericized function which receivies an
argument of sequence "duck-type"?

Giovanni Bajo


From ronaldoussoren at mac.com  Mon May  8 11:35:22 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 8 May 2006 11:35:22 +0200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <445E970F.6020303@canterbury.ac.nz>
References: <mailman.20468.1146940506.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605071357030.23597@qew.cs>
	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
	<445E970F.6020303@canterbury.ac.nz>
Message-ID: <AB913627-9467-4EBD-94DA-331CFBDEFAC8@mac.com>


On 8-mei-2006, at 2:55, Greg Ewing wrote:

> Paul Moore wrote:
>
>> If the implication here is that there is *no* GUI in the Python
>> standard library, I'd be cautious of this (-0, probably). Things like
>> the pydoc server use a little GUI window.
>
> There *isn't* currently any GUI in the core distribution
> except on Windows. Non-Windows users already have to
> install Tk separately if they want to use IDLE or any
> of the other things that use it. So I don't see this as
> a big deal.

The mac distribution also includes tkinter (and on 10.4 Tk is
already part of the core OS and doesn't need to be installed  
seperately).

Ronald

>
> --
> Greg
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/ 
> ronaldoussoren%40mac.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20060508/7ce3d749/attachment.bin 

From ronaldoussoren at mac.com  Mon May  8 11:39:42 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 8 May 2006 11:39:42 +0200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
References: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
Message-ID: <9C4264C7-42EB-425A-8797-9F1178EB25A1@mac.com>


On 8-mei-2006, at 4:07, Bill Janssen wrote:

> Aahz,
>
>> First of all, Mac users downloading a release get Tk automatically.
>
> Good idea!
>
> I run on a Mac, and don't download -- I use the pre-installed Python
> on the Mac.  And there's no Tk.

What version of OSX are you using? /usr/bin/python on 10.4 has support
for tkinter.

>
> Much as we might like to think otherwise, there's no standard GUI in
> the Python core, and IDLE (or anything else that depends on it) won't
> work in some cases where it should work.

Yes there is. Some distributors are lame enough to think they know  
better
and ship parts of the standard library seperately, but that's not a  
valid
reason for removing parts of the stdlib.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20060508/3c3dd257/attachment-0001.bin 

From ronaldoussoren at mac.com  Mon May  8 11:46:33 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 8 May 2006 11:46:33 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <445EEC1F.8060303@acm.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.org>
Message-ID: <2151E223-F04E-44B4-9738-3A7960C918D6@mac.com>


On 8-mei-2006, at 8:58, Talin wrote:
>
>> And *how* exactly would you implement your isFunction test
>> so as to detect the "naive, everyday concept of a function"
>> that you seem to want, in a way that does any better job
>> than the current callable()?
>
> This 'isFunction' test that I am thinking of would only return true  
> for
> user defined functions, built-in functions, and similar objects; It
> would not return true for classes or other objects that are  
> technically
> functions in a mathematically pure sense, but which normal people  
> don't
> think of as functions.
>
> In other words, a function that does what most people expect it to, by
> conforming to their intuitive idea of what a function is, rather than
> some grammatical or mathematical definition. And in cases of  
> ambiguity,
> it would be conservative, returning false negatives but not false  
> positives.

But why would this be useful? Using objects with a __call__ method as a
function is useful at times (such as with callback functions or to  
remember
state).

If isFunction would return false for such objects it is likely that such
objects would be rejected at some places where I'd like to use them.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20060508/dd0125fd/attachment.bin 

From thomas at python.org  Mon May  8 11:52:36 2006
From: thomas at python.org (Thomas Wouters)
Date: Mon, 8 May 2006 11:52:36 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060508T015833-308@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com>
	<loom.20060508T015833-308@post.gmane.org>
Message-ID: <9e804ac0605080252i782b6ec5ubdc51575f8e9c4ca@mail.gmail.com>

On 5/8/06, Talin <talin at acm.org> wrote:
>
> Thomas Wouters <thomas <at> python.org> writes:
>
> > He is, and for the same reasons as callable(): there is no way to
> > tell whether an object is a mapping or a sequence (considering
> > Python object of both 'types' implement __getitem__, and that's
> > it. If you don't believe me, ask isSequence about UserDict.).


Some of the best Python libraries out there (IMHO) have functions
> that test their arguments to determine if they are a sequence or not.


You must have missed the part about asking isSequence about UserDict. They
may be the best in your eyes, but they're broken if they rely on isSequence
(or they impose arbitrary restrictions, if they found out isSequence doesn't
do what they want it to do.)

As an example, check out section 4: "Content Producing Constructs" in the
> Kid docs:
>
>    str, unicode - The string is inserted as XML CDATA.
>    ElementTree.Element - When an ElementTree.Element is referenced from a
>       content producing construct, the item is inserted into the document
>       literally, i.e. it is not encoded as text, but becomes part of the
> output
>       structure.
>    sequence - If a sequence type (list, tuple, or other iterable) is
> referenced,
>       the rules are applied to each of the items in the sequence. For
> example,
>       you could reference a list containing an Element and a string.
>    Other - If the result of evaluating the expression is any other type,
> an
>       attempt is made to coerce the value to unicode as if by calling
>       unicode(expr) and processing continues as if the object were a
> string
>       or unicode object initially.
>
> My reaction on reading this the first time was "Wow, what a sensible
> API!"


And mine is "Ugh, what a horribly bad API." A string *is* a sequence. Given
your description, I can never pass it a string-alike object; using
isSequence, it would be treated as a sequence before Kid tried to convert it
to unicode. Or if the test for a sequence is done by checking against known
sequence types, I wouldn't be able to pass a custom sequence type. The user
of the code knows what kind of object he's passing, how he wants it to be
treated. Having the code guess is quite fragile.

Nothing is going to stop you to make the same guessing and harebrained
assumptions in Py3K, you just won't have the broken 'operator.isSequence'
test to do it for you (and imply it knows what it's talking about.) You will
have to write your own guesswork.

I would hate to be told that I'm not allowed to test whether something
> is a sequence or not.


Python doesn't care where you point your gun, whether you pull the trigger
or not. It's just not going to give you a point-at-foot device; you'll have
to write that yourself.

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060508/3747c7f4/attachment.html 

From paul at boddie.org.uk  Mon May  8 13:41:07 2006
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 8 May 2006 13:41:07 +0200
Subject: [Python-3000] What do do about IDLE?
Message-ID: <200605081341.07969.paul@boddie.org.uk>

Ronald Oussoren wrote:
> On 8-mei-2006, at 4:07, Bill Janssen wrote:
> >
> > Much as we might like to think otherwise, there's no standard GUI in
> > the Python core, and IDLE (or anything else that depends on it) won't
> > work in some cases where it should work.
> 
> Yes there is. Some distributors are lame enough to think they know
> better and ship parts of the standard library seperately, but that's not a
> valid reason for removing parts of the stdlib.

Well, Tk is available on the "big three" (Windows, Mac, UNIX), but if you 
venture onto other platforms, don't expect to find it there. People may argue 
that the "big three" are all that matter, but that argument usually ends up 
with the "big two" and then total incoherence: eg. "this works on the Windows 
and Mac, whereas this works on Windows and UNIX"; something that has 
gradually (and thankfully) been eradicated over the past few years in parts 
of the standard library.

Paul

P.S. I thought Python 3000 had quite a lot to say on the tidying up of the 
standard library, or is it now the case that everyone wants to make language 
changes instead?

From greg.ewing at canterbury.ac.nz  Mon May  8 14:49:55 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 09 May 2006 00:49:55 +1200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <20060508015253.GA10313@panix.com>
References: <mailman.20468.1146940506.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605071357030.23597@qew.cs>
	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
	<445E970F.6020303@canterbury.ac.nz> <20060508015253.GA10313@panix.com>
Message-ID: <445F3E73.5040406@canterbury.ac.nz>

Aahz wrote:

> First of all, Mac users downloading a release get Tk automatically.

I stand corrected -- I wasn't aware that the Mac
version came with Tk these days.

> Secondly, your argument sounds like a variant of the argument against
> adding pysqlite to the core,

It's not really the same thing, because we don't
currently have an SQL module in the core that we're
considering replacing with another one, maybe,
but we're not sure which one yet.

--
Greg

From paul at boddie.org.uk  Mon May  8 14:58:06 2006
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 8 May 2006 14:58:06 +0200
Subject: [Python-3000] back with more GUI planning in a few days...
Message-ID: <200605081458.06846.paul@boddie.org.uk>

Talin wrote:
> 
> There are two reasons why I think that bundling a GUI library with
> Python is a good idea:
> 
>   -- It makes it possible to include GUI-based tools and applications
> in the base distribution.

I agree with this, although how ambitious are such tools? If you're just 
popping a dialogue asking for user input, there are typically other means of 
doing that without bringing in a whole GUI framework.

>   -- By reducing the dependency on downloading and installing
> a UI framework, it lowers the friction for developing small, one-off
> UI tools. This is not so much an issue with large apps, since the
> cost of choosing and installing the optimal UI package is small
> compared to the development cost of the project. But for small
> tools (for example, a configuration control panel), the extra step
> of installing a UI framework may be significant.

I think the reduced friction is less about the installation and a lot more to 
do with which API you use: this being a point that the Web frameworks debate 
still hasn't caught up with. In other words, given that whichever toolkit is 
likely to be a click-install away, you're likely to be spending more time 
looking up how to write the GUI code, and a standard in this domain hopefully 
makes such work a lot more obvious. Scaling a standard up to complicated, 
integrated applications is a mostly unsolved problem, though.

> However, there are some significant obstacles to be overcome before
> this can happen.
> 
> First, there's no such thing as a "simple" UI toolkit. Certainly, some
> toolkits are simpler than others. But as I have argued before, UIs are
> a language, and that language has evolved over time, to the point
> where it has a rich vocabulary of appearances and behaviors.

True. And the more complicated applications become, the more likely it is that 
you'll want to consider other things, such as the environment in which the 
applications operate. Opening a special toolkit file chooser dialogue may be 
acceptable for some kinds of applications, but together with other "platform 
agnostic" features it can also provide a huge disincentive to use those 
applications. (Personally, I dislike the Gtk+ and GNOME file choosers, partly 
because they have been ruined by usability "experts" with nostalgia for 
NeXTStep, but I really dislike them when they pop up in KDE, especially since 
KDE applications and the environment generally provide better solutions.)

In fact, this topic conveniently highlights an issue I see with the way this 
and other topics are approached by parts of the Python community. In this 
community, the attitude to something like cross-platform user interfaces 
often involves glossing over the diversity of actual environments in favour 
of having something that does the job passably, often manifesting itself in 
some people's interpretation of what support for Linux or UNIX actually is: 
"Gtk+ support covers Linux, right?" Unfortunately, despite noise from various 
desktop environment proponents, the real world is a lot more complicated and 
a lot more interesting; neglecting this reality causes the kind of 
frustration and disenchantment described above.

People in this community often used to point at Java and claim how 
isolationist the technology was (and largely still is), how Java user 
interfaces were so unlike the environments they run in, how Java has so many 
poor abstractions for system functionality that get in the way, and how 
Python seems to encourage cooperation and integration with the environment. 
However, parts of the Python community seem to behave like Java technology: 
preferring to abstract away diversity, isolating "Pythonic" solutions from 
the outside world, looking inside itself for solutions to problems that 
others have already solved.

Indeed, the wider Python community should be more aware and more willing to 
work with other communities. For example, Python already works well with both 
KDE and GNOME, and there is an increasing (if arguably belated) interest in 
dynamic languages in the communities around those environments. Instead of 
pretending that Python somehow doesn't need those technologies to be 
successful or important (perhaps related to the sentiment that "I use 
Windows/Mac and don't care about anything else"), perhaps a mutual 
recognition in each community of the other would be beneficial. None of this 
provides a simple answer to the question, "How do I write a complicated, 
integrated, cross-platform GUI application in Python?" However, we shouldn't 
seek to mislead by providing simple answers where in practice there are none. 
And given that people actively working on such issues don't have simple 
answers to such questions, we shouldn't be dishonest in pretending we have 
something they don't.

> (One of my concerns about PyGUI is that the postings by its
> proponents on this list seem to be somewhat dismissive of this
> point - in other words, I get the impression that faced with the
> complex vocabularity of UI designs, they would rather simplify
> the visual language than deal with its full complexity. I understand
> the motivation for doing so - as engineers, we all want to make
> things simpler - but I think that in this case it ignores some
> important realities about user and programmer expectations.)

PyGUI looks like an interesting project: who wouldn't want to gloss over the 
implementation detail of different and potentially unfamiliar GUI 
environments? And I'm a big fan of putting layers on top of what seems like 
needless inconsistency. But really, I think that people need to think back to 
what the situation was like before: first there was stdwin, then there was a 
cornucopia of different solutions (Xlib and Motif bindings, for instance), 
and eventually Tkinter made it in as the binding to arguably the only open 
source, cross-platform toolkit available at the time. I suppose that 
supporting stdwin in the face of better toolkits and increased demand for 
better native behaviour was just too much work, and I doubt that these 
factors have diminished in the ten or more years since it was abandoned. 
Promoting a successor to stdwin doesn't seem like progress to me.

Paul

From fredrik at pythonware.com  Mon May  8 15:06:28 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 8 May 2006 15:06:28 +0200
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org><445D89E5.8040609@canterbury.ac.nz><loom.20060507T082010-251@post.gmane.org>
	<9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com>
Message-ID: <e3nfof$ntj$1@sea.gmane.org>

Thomas Wouters wrote:

> Duck typing isn't "ask the object whether it can do this". Duck typing is
> "do this". I don't believe 'taking different actions based on capabilities'
> is all that common, and it certainly breaks easily.

have you used callable(), or are you just making things up ?

> It may be 'common' for programmers to try and write this kind of code
> (accept either a string or an instance, a sequence or a single object, etc)
> but it's certainly not a common idiom -- idioms don't suck :-)

what widely used API:s have you designed, and what widely used API:s have you
studied when you decided that API:s that use callable to implement duck typing all
suck ?

(it actually works a lot better than some people here seem to think, which makes
me think that they've never used it.  generalizing from no examples at all isn't a great
way to design software...)

</F> 




From greg.ewing at canterbury.ac.nz  Mon May  8 15:17:44 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 09 May 2006 01:17:44 +1200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <445EEC1F.8060303@acm.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.org>
Message-ID: <445F44F8.5070006@canterbury.ac.nz>

Talin wrote:

> This 'isFunction' test that I am thinking of would only return true for 
> user defined functions, built-in functions, and similar objects; It 
> would not return true for classes or other objects that are technically 
> functions in a mathematically pure sense, but which normal people don't 
> think of as functions.

But what would it return for a user-defined class
with a __call__  method?

And if the answer to that is "True", what would it return
for the following class:

   class AmIAFunctionOrNot(object):

     def __call__(self, *args, **kwds):
       raise TypeError("This object cannot be called.")

> In other words, a function that does what most people expect it to, by 
> conforming to their intuitive idea of what a function is,

Intuitive ideas are too fuzzy to translate into code.
A rigorous specification is needed.

--
Greg

From mcherm at mcherm.com  Mon May  8 15:18:47 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Mon, 08 May 2006 06:18:47 -0700
Subject: [Python-3000] duck typing
Message-ID: <20060508061847.imgtocrhyi4gwsss@login.werra.lunarpages.com>

Bill Janssen writes:
> I don't want to ever again use a library that claims to export a
> "dict" object, only to find (later) that the implementor hasn't
> implemented some of the methods of the real "dict" type because he
> thought they wouldn't be called.

And there is the crux of the matter. I *want* to use a language
where the implementor of a "dict-like-class" need not implement
those methods of dict that she knows won't be used in this
quick-and-dirty dict-like-class.

> Or because he was too lazy to
> document the interface he'd actually implemented.  "Duck typing"
> encourages this kind of ramshackle development.

"Ramshackle" development is appropriate for many kinds of tasks.
For LIBRARY code, there is no excuse for failing to document the
interface, and while there are excuses for implementing less than
the full dict interface, they need to be justified. (Eg: it's
perfectly reasonable to create a dict-like class that prohibits
deleting entries.) But duck typing DOES have its uses.

-- Michael Chermside


From fredrik at pythonware.com  Mon May  8 15:24:27 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 8 May 2006 15:24:27 +0200
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org><445D89E5.8040609@canterbury.ac.nz><loom.20060507T082010-251@post.gmane.org><9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com><loom.20060507T100953-336@post.gmane.org>
	<79990c6b0605070435o522e342fre926d9f1fc7ec88d@mail.gmail.com>
Message-ID: <e3ngq3$rm3$1@sea.gmane.org>

Paul Moore wrote:

> guess('y') is *both* a string and a callable. OK, so it's a contrived
> example

generalizing from one contrived example is worse than generalizing from
no example at all.

</F> 




From thomas at python.org  Mon May  8 15:29:11 2006
From: thomas at python.org (Thomas Wouters)
Date: Mon, 8 May 2006 15:29:11 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <e3nfof$ntj$1@sea.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com>
	<e3nfof$ntj$1@sea.gmane.org>
Message-ID: <9e804ac0605080629tdbaf9d5gb76ea497bd80feb4@mail.gmail.com>

On 5/8/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
>
> Thomas Wouters wrote:
>
> > Duck typing isn't "ask the object whether it can do this". Duck typing
> is
> > "do this". I don't believe 'taking different actions based on
> capabilities'
> > is all that common, and it certainly breaks easily.
>
> have you used callable(), or are you just making things up ?


Yes. All my arguments are based on guesswork. I have nothing useful to
contribute. As usual, you get to ignore anything I say.

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060508/dbaf5724/attachment-0001.htm 

From greg.ewing at canterbury.ac.nz  Mon May  8 15:30:54 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 09 May 2006 01:30:54 +1200
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <200605081458.06846.paul@boddie.org.uk>
References: <200605081458.06846.paul@boddie.org.uk>
Message-ID: <445F480E.1080808@canterbury.ac.nz>

Paul Boddie wrote:

> Promoting a successor to stdwin doesn't seem like progress to me.

It's a bit hard to sort out what you're actually saying
in all that. Are you arguing for or against something
like PyGUI?

The Gnome vs. KDE issue seems like an argument in
favour to me. Because the alternative is only being able
to write an app that blends in with Gnome *or* KDE
but not both.

--
Greg

From fredrik at pythonware.com  Mon May  8 15:40:21 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 8 May 2006 15:40:21 +0200
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org><445D89E5.8040609@canterbury.ac.nz><loom.20060507T082010-251@post.gmane.org>
	<9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com>
Message-ID: <e3nhnq$va7$1@sea.gmane.org>

Thomas Wouters wrote:

> Duck typing isn't "ask the object whether it can do this". Duck typing is
> "do this".

that's your own definition, by the way.  the usual definition is the one in the Python
tutorial:

    Duck Typing

    Pythonic programming style that determines an object's type by inspection
    of its method or attribute signature rather than by explicit relationship to
    some type object ("If it looks like a duck and quacks like a duck, it must
    be a duck.") By emphasizing interfaces rather than specific types, well-
    designed code improves its flexibility by allowing polymorphic substitution.
    Duck-typing avoids tests using type() or isinstance(). Instead, it
    typically employs hasattr() tests or EAFP [Easier to Ask Forgiveness
    than Permission] programming.

looks like you're confusing duck typing with EAFP.  don't do that; they may be
related, by they are two different things.

</F> 




From fredrik at pythonware.com  Mon May  8 15:40:52 2006
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 8 May 2006 15:40:52 +0200
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org><445D89E5.8040609@canterbury.ac.nz><loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz>
Message-ID: <e3nhop$vek$1@sea.gmane.org>

Greg Ewing wrote:

>> A common Python idiom is to take different actions based on the capabilities
>> of an object rather than its type.
>
> I have no objection to that when the capability can be
> tested for easily and efficiently and without danger of
> causing undesirable side effects. But callability is
> not such a capability, therefore I think it's a bad
> idea to design an API which relies on being able to
> test for it.

it's spelled callable(), is successfully used in popular and well-designed API:s, is well-
defined in terms of duck-typing, and all counter-examples we've seen on this list are
utterly contrived.

(and even if you dig up one *real* example where false callable positives are a real
problem, I can assure you that there exists a trivial workaround for that specific case,
no matter what it is)

</F> 




From thomas at python.org  Mon May  8 15:55:08 2006
From: thomas at python.org (Thomas Wouters)
Date: Mon, 8 May 2006 15:55:08 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <e3nhop$vek$1@sea.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
Message-ID: <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>

On 5/8/06, Fredrik Lundh <fredrik at pythonware.com> wrote:

> it's spelled callable(), is successfully used in popular and well-designed
> API:s, is well-
> defined in terms of duck-typing, and all counter-examples we've seen on
> this list are
> utterly contrived.


Dare I suggest you convince Guido not to remove callable(), then? That is,
after all, what this discussion is about. You might want to think about the
removal of isSequence and isMapping too; see
http://mail.python.org/pipermail/python-3000/2006-April/001256.html . I
don't care about the removal of either callable or isSequence/isMapping
(although the non-public, small-scale, unimpressing API's I design certainly
don't use them), but Guido put them on the list, so apparently he does.

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060508/9dc9a5fa/attachment.htm 

From jimjjewett at gmail.com  Mon May  8 15:57:17 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 8 May 2006 09:57:17 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <445EEC1F.8060303@acm.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.org>
Message-ID: <fb6fbf560605080657k233091fdi25c82dfc5b3c3a9c@mail.gmail.com>

On 5/8/06, Talin <talin at acm.org> wrote:
> Before we go to much further on this point, I want to get a sense of
> what exactly people are objecting to:

>     -- Are they saying that interface discovery is not important, or is
> bad style?

Not in principle.

In practice, certain implementation patterns can be bad style.

In general, python encourages "just try it" instead of "verify the
preconditions, then try it if you can".

Obviously, there are times when another style makes more sense, but
the effort to decide that exceeds the effort of implementing it; by
default the language should encourage the way that is normally better.

>     -- Are they saying that the way isSequence and such implements
> interface discovery is wrong, and if it is, what's the alternative?

Yes, it is wrong.  There isn't a good (and general) alternative in 2.x.

The working assumption is that there won't really be a good general
way in 3 either, unless what you really mean is "Does it have these
methods", in which case the best way is to test for those methods. 
isSequence may give false confidence in the answers.

> This 'isFunction' test that I am thinking of would only return true for
> user defined functions, built-in functions, and similar objects; It
> would not return true for classes or other objects that are technically
> functions in a mathematically pure sense, but which normal people don't
> think of as functions.

What do you use it for?

Whenever I have cared, it was because I wanted to call the function to
transform something -- and it was pretty common that the function was
easier to implement as a class returning instances.

-jJ

From aahz at pythoncraft.com  Mon May  8 16:13:36 2006
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 8 May 2006 07:13:36 -0700
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <200605081341.07969.paul@boddie.org.uk>
References: <200605081341.07969.paul@boddie.org.uk>
Message-ID: <20060508141336.GA21306@panix.com>

On Mon, May 08, 2006, Paul Boddie wrote:
>
> Well, Tk is available on the "big three" (Windows, Mac, UNIX),
> but if you venture onto other platforms, don't expect to find it
> there. People may argue that the "big three" are all that matter,
> but that argument usually ends up with the "big two" and then
> total incoherence: eg. "this works on the Windows and Mac, whereas
> this works on Windows and UNIX"; something that has gradually (and
> thankfully) been eradicated over the past few years in parts of the
> standard library.

Aside from Java and Swing (which has its own set of problems), is there
any readily-available GUI that includes a significant number of platforms
other than the Big Three?
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours."  --Richard Bach

From jimjjewett at gmail.com  Mon May  8 16:20:05 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 8 May 2006 10:20:05 -0400
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <200605081458.06846.paul@boddie.org.uk>
References: <200605081458.06846.paul@boddie.org.uk>
Message-ID: <fb6fbf560605080720v6a7d4969y1d0c954bee809c2@mail.gmail.com>

On 5/8/06, Paul Boddie <paul at boddie.org.uk> wrote:
> Talin wrote:

> > There are two reasons why I think that bundling a GUI library with
> > Python is a good idea:

> >   -- It makes it possible to include GUI-based tools and applications
> > in the base distribution.

> I agree with this, although how ambitious are such tools? If you're just
> popping a dialogue asking for user input, there are typically other means of
> doing that without bringing in a whole GUI framework.

And what are those ways, cross-platform?

> > But for small tools (for example, a configuration control panel),
> > the extra step of installing a UI framework may be significant.

> I think the reduced friction is less about the installation and a lot more to
> do with which API you use:

It's both.

> Scaling a standard up to complicated,
> integrated applications is a mostly unsolved problem, though.

So accept that complicated integrated applications will need to go
beyond the standard library's offerings, and (almost) stop worrying
about them.

> > One of my concerns about PyGUI ... faced with the
> > complex vocabularity of UI designs, they would rather simplify
> > the visual language than deal with its full complexity.

Yes, because dealing with full complexity is not a solved problem.

There is nothing to prevent a KDE or wx implementation of PyGUI, and
nothing to prevent users who need the full power from using wxPython
directly.  The only thing the standard library should even attempt to
provide is scaffolding for applications simple enough that they don't
need the answers to the unsolved problems.

-jJ

From jimjjewett at gmail.com  Mon May  8 16:27:39 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 8 May 2006 10:27:39 -0400
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <AB913627-9467-4EBD-94DA-331CFBDEFAC8@mac.com>
References: <mailman.20468.1146940506.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605071357030.23597@qew.cs>
	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
	<445E970F.6020303@canterbury.ac.nz>
	<AB913627-9467-4EBD-94DA-331CFBDEFAC8@mac.com>
Message-ID: <fb6fbf560605080727q20e322e8o9f61705dd8d948d@mail.gmail.com>

On 8-mei-2006, at 2:55, Greg Ewing wrote:
> There *isn't* currently any GUI in the core distribution
> except on Windows.

Given that Tk is open source, how much of a problem is this?  Would it
be solved by simply including a snapshot of Tk in the source
distribution?

Most windows users cannot compile their own C extensions.

Most linux users can.  I was under the impression that most Mac users
could now, too.

Realistically, any other platform is already depending on someone to
do some porting work and recompile.

-jJ

From solipsis at pitrou.net  Mon May  8 16:29:34 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 08 May 2006 16:29:34 +0200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <20060508141336.GA21306@panix.com>
References: <200605081341.07969.paul@boddie.org.uk>
	<20060508141336.GA21306@panix.com>
Message-ID: <1147098574.5718.5.camel@fsol>

Le lundi 08 mai 2006 ? 07:13 -0700, Aahz a ?crit :
> Aside from Java and Swing (which has its own set of problems), is there
> any readily-available GUI that includes a significant number of platforms
> other than the Big Three?

>From the wxWidgets FAQ:

? What platforms are supported by wxWidgets?
      * Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows
        ME.
      * Linux and other Unix platforms with GTK+.
      * Unix with Motif or the free Motif clone Lesstif.
      * Mac OS.
      * Embedded platforms are being investigated. See the wxUniversal
        project.
      * An OS/2 port is in progress, and you can also compile wxWidgets
        for GTK+ or Motif on OS/2. ?

Regards

Antoine.



From barry at python.org  Mon May  8 16:52:02 2006
From: barry at python.org (Barry Warsaw)
Date: Mon, 08 May 2006 10:52:02 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
Message-ID: <1147099922.10381.20.camel@resist.wooz.org>

On Mon, 2006-05-08 at 15:55 +0200, Thomas Wouters wrote:

> Dare I suggest you convince Guido not to remove callable(), then? That
> is, after all, what this discussion is about.

We use callable() and PyCallable_Check() in a couple of places.  I'm not
sure that our uses are enough to keep these alive, since I can think of
alternative implementations that would probably work almost as well.
But I'll explain the general idea anyway in case it's useful to the
discussion.

There are a couple of places where we register callbacks with our
engine.  These callbacks can come from our own code or extensions that
users write.  Some of these callbacks will be called very often, some
not so often (think: every time through the inner loop or occasionally
through an outer loop).

Obviously if someone registers a callback that isn't callable, we don't
want to waste time on every iteration trying to call it, only to catch
whatever error might occur.  So right now we do a
callable()/PyCallable_Check() at the time of registration, and if that
fails, we don't even create the internal (i.e. in C) data structures to
register the callback and thus pay no penalty in the inner loop for
(some class of) bogus callbacks.

One advantage of this is that we have early detection of errors so that
we can complain when the registration occurs instead of some time later
when the first use occurs.  We cannot call the callbacks at the time of
registration, so that's not an option.

Should callable()/PyCallable_Check() go away, then we'd have to rewrite
the callback usage code to throw away or otherwise mark the callback as
unusable on the first use error, so that subsequent iterations through
the loop won't waste time on an unusable callback.  This may not be too
big a deal because obviously, other errors could occur during the use of
the callback that would have to be caught.  The question is whether
those other errors are permanent or temporary errors, and how you would
tell the difference.

What I mean is, if a registered callback isn't callable, that's
obviously a permanent error, so the callback should be disabled.  If you
got some other kind of error, it would be nice to be able to decide
whether that was a temporary error, meaning just this call should be
ignored, or a permanent error causing the callback to be disabled.  The
question then is whether a TypeError is enough to tell the difference.
Maybe not, because TypeErrors can occur for all kinds of reasons, and I
think it would be very difficult to tell whether they occurred because
the callback wasn't callable or some other error deeper into the
execution stack occurred just because we accidentally passed a bogus
argument to the callable.

Perhaps then, if we get rid of callable()/PyCallable_Check() it would be
useful to add a NotCallableError (as a subclass of TypeError?) that
would get thrown should you try to call something that's not callable.
The argument to the exception would be the thing you tried to
erroneously called.

In our use case then, it would be a fairly simple matter of catching
NotCallableError and comparing the argument to the callback we just
tried to call.  If they match, we'd know that a bogus callback was
registered and we could permanently disable it.  If they didn't match,
or it was some other kind of error, we could potentially treat that as a
temporary problem and just skip the callback but not permanently disable
it.

-Barry


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-3000/attachments/20060508/a396d4bf/attachment.pgp 

From mcherm at mcherm.com  Mon May  8 17:03:42 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Mon, 08 May 2006 08:03:42 -0700
Subject: [Python-3000] PEP 3100 Comments
Message-ID: <20060508080342.ssagqt29tlsg8gok@login.werra.lunarpages.com>

Talin writes:
> Before we go to much further on this point, I want to get a sense of
> what exactly people are objecting to:

Good question. Answers below (speaking for myself only, of course!):

>     -- Are they saying that interface discovery is not important, or is
> bad style? (Its hard to do general transformations of objects from one
> form to another without it.)

No. Well, it's often bad style, but shouldn't be forbidden since it's
still sometimes useful.

>     -- Are they saying that the way isSequence and such implements
> interface discovery is wrong, and if it is, what's the alternative?

Yes it's "wrong" in that it's not 100% accurate. There IS no better
alternative.

>     -- Are they proposing some different model of interface discovery
> that they feel is better?

Not really. Interface discovery is HARD, and sometimes impossible.

>     -- Are they saying that duck types are wrong?

No, they're very useful!

>     -- Are they saying that interface discovery should be limited to
> formal types only, and not implicitly defined "duck types"?

YES!!

The whole idea behind duck typing is (1) the code being called doesn't
try to verify the type of the objects passed to it, it just uses
them; (2) the calling code choses to provide an object that implements
those methods that are needed, and not necessarily any others.

If the object passed doesn't behave as expected, then an error occurs
(usually an exception, sometimes erronious results). This is the
caller's fault, and the caller takes responsibility for it (consenting
adults here). A significant advantage of this approach is that the
object used might behave VERY differently than expected (eg: mock
objects for unit testing, or a proxy for some external object), and
that's OK.

If the called code attempts to verify the types that are passed to
it -- even via implicit discovery -- then it may not be possible to
use duck-typed arguments with that code. We call such code "duck-hunting
code" and generally tend to discourage it.

Well-we-don't-call-it-that-but-we-otta-lly yours,

Michael Chermside


From aahz at pythoncraft.com  Mon May  8 17:31:26 2006
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 8 May 2006 08:31:26 -0700
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <1147098574.5718.5.camel@fsol>
References: <200605081341.07969.paul@boddie.org.uk>
	<20060508141336.GA21306@panix.com> <1147098574.5718.5.camel@fsol>
Message-ID: <20060508153126.GA3287@panix.com>

On Mon, May 08, 2006, Antoine Pitrou wrote:
> Le lundi 08 mai 2006 ? 07:13 -0700, Aahz a ?crit :
>>
>> Aside from Java and Swing (which has its own set of problems), is there
>> any readily-available GUI that includes a significant number of platforms
>> other than the Big Three?
> 
> ? What platforms are supported by wxWidgets?
>       * Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows
>         ME.
>       * Linux and other Unix platforms with GTK+.
>       * Unix with Motif or the free Motif clone Lesstif.
>       * Mac OS.
>       * Embedded platforms are being investigated. See the wxUniversal
>         project.
>       * An OS/2 port is in progress, and you can also compile wxWidgets
>         for GTK+ or Motif on OS/2. ?

Sure looks like Big Three to me!  ;-)  From my POV, "includes" does not
mean "investigated" or "in progress".
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours."  --Richard Bach

From paul at boddie.org.uk  Mon May  8 17:34:47 2006
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 8 May 2006 17:34:47 +0200
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <445F480E.1080808@canterbury.ac.nz>
References: <200605081458.06846.paul@boddie.org.uk>
	<445F480E.1080808@canterbury.ac.nz>
Message-ID: <200605081734.47437.paul@boddie.org.uk>

On Monday 08 May 2006 15:30, Greg Ewing wrote:
> Paul Boddie wrote:
> > Promoting a successor to stdwin doesn't seem like progress to me.
>
> It's a bit hard to sort out what you're actually saying
> in all that. Are you arguing for or against something
> like PyGUI?

I'm not against PyGUI. Actually, it seems like a nice project, and given that 
I believe that everyone should try and develop different things if only to 
see where it takes them, it will be interesting to see where you take it (and 
where it takes you). I think there needs to be more innovation in graphical 
user interfaces and visualisation, and that isn't going to happen if everyone 
waits for Microsoft, Apple and others to do the legwork. And as I said, 
unifying different technologies is an interesting topic that I personally 
find compelling if it can be done reasonably.

> The Gnome vs. KDE issue seems like an argument in
> favour to me. Because the alternative is only being able
> to write an app that blends in with Gnome *or* KDE
> but not both.

One of my points, probably not made explicitly or at least very well, is that 
because there are two main UNIX desktop camps (ignoring legacy desktops and 
the minor players), people have been confronted with the "how do I get the 
right print dialogue up?" question already, and there are groups of people 
working on cross-desktop issues. Sure, the solutions aren't always very 
pleasant, and perhaps one has to forego a certain level of integration in 
order to cover all the target environments. Nevertheless, I think it would be 
a bad thing if something in the standard library claimed to provide, or just 
gave the vague impression of providing, a definitive solution for all 
environments (the "simple answer" I alluded to) when to achieve a 
satisfactory result involves a bit more work. People entrenched in the 
desktop standards debate are seemingly reconciled to the multitude of 
toolkits and technologies currently available - picking winners doesn't 
acknowledge the sophistication of the situation.

My rant about communities perhaps offers a few different ways forward: to keep 
up with possible solutions to integration issues; to consider people who know 
which desktop technologies they want to use and to provide them with some 
kind of coherent roadmap. On the former, I believe it's possible to write a 
cross-platform application using technologies such as PyGtk and PyQt, even 
styling them to look mostly consistent with the host desktop environment, but 
there's a certain amount of deeper integration work still to be done (and 
that doesn't even cover stuff like desktop integration): we should be aware 
of what the state of the art is, perhaps incorporating it into projects like 
PyGUI, or perhaps offering desktop integration and GUI abstraction in other 
ways. On the latter, we should also examine the process of choosing toolkits 
and languages from the direction usually not considered by existing Python 
users and developers: what if I want to write a GNOME application; which 
language should I choose? Until now, Python hasn't really been promoted to 
people coming from that direction, but I'd argue that it's possibly more 
significant as a market than that which covers those people already using 
Python who are looking for some kind of cross-platform toolkit.

As to whether PyGUI or anything else of that nature should be in the standard 
library, my feeling is that if it (PyGUI or anything else) cannot deliver the 
desired functionality without leaving various kinds of users looking for 
another toolkit at some level of ambition (eg. providing a file chooser or 
print dialogue in their application), then we should leave such things out of 
the standard library and spell out the options in a clear fashion, 
acknowledging that more than one choice exists but the means of choosing one 
is not some kind of magic ritual. Remember that with Tkinter as a mostly 
informal standard for years, people have had to deal with this issue 
continuously, mostly abandoning Tkinter and going with something else. 
Providing another API which only gets you so far before you have to go and 
learn another one, just to get access to some aspects of the environment, 
isn't necessarily progress; as I wrote, this particular lesson is quite 
similar to those currently floating upwind of the Web technologies debate.

Paul

From fdrake at acm.org  Mon May  8 17:38:52 2006
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 8 May 2006 11:38:52 -0400
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <9C4264C7-42EB-425A-8797-9F1178EB25A1@mac.com>
References: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
	<9C4264C7-42EB-425A-8797-9F1178EB25A1@mac.com>
Message-ID: <200605081138.52823.fdrake@acm.org>

On Monday 08 May 2006 05:39, Ronald Oussoren wrote:
 > Yes there is. Some distributors are lame enough to think they know better
 > and ship parts of the standard library seperately, but that's not a valid
 > reason for removing parts of the stdlib.

Hopefully they'll learn.  This is been a regular problem for the distutils 
package, which is pure Python.

As someone who's preferred building Python from source for years, I've never 
considered Tkinter something that's guaranteed to be there.  It's always 
depended on external packages, and has been built when the necessary 
dependencies are present (or, in the Modules/Setup days, when it's been 
explicitly configured).  It's part of the standard library, but has never be 
promised to always be available on Unix.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From steven.bethard at gmail.com  Mon May  8 17:47:24 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Mon, 8 May 2006 09:47:24 -0600
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <1147099922.10381.20.camel@resist.wooz.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
Message-ID: <d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>

On 5/8/06, Barry Warsaw <barry at python.org> wrote:
> Perhaps then, if we get rid of callable()/PyCallable_Check() it would be
> useful to add a NotCallableError (as a subclass of TypeError?) that
> would get thrown should you try to call something that's not callable.
> The argument to the exception would be the thing you tried to
> erroneously called.

+1.  It'd certainly be nice to be able to tell the difference between
the following two TypeErrors:

    >>> def s():
    ...     raise TypeError()
    ...
    >>> 's'()
    Traceback (most recent call last):
      File "<interactive input>", line 1, in ?
    TypeError: 'str' object is not callable
    >>> s()
    Traceback (most recent call last):
      File "<interactive input>", line 1, in ?
      File "<interactive input>", line 2, in s
    TypeError

A few places that look like they'd need to be changed:

Modules/_tkinter.c:             PyErr_SetString(PyExc_TypeError,
"command not callable");
Objects/abstract.c:     PyErr_Format(PyExc_TypeError, "'%s' object is
not callable",
Objects/funcobject.c:           PyErr_Format(PyExc_TypeError, "'%s'
object is not callable",

STeVe
--
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From paul at boddie.org.uk  Mon May  8 17:49:05 2006
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 8 May 2006 17:49:05 +0200
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <fb6fbf560605080720v6a7d4969y1d0c954bee809c2@mail.gmail.com>
References: <200605081458.06846.paul@boddie.org.uk>
	<fb6fbf560605080720v6a7d4969y1d0c954bee809c2@mail.gmail.com>
Message-ID: <200605081749.05322.paul@boddie.org.uk>

On Monday 08 May 2006 16:20, Jim Jewett wrote:
> On 5/8/06, Paul Boddie <paul at boddie.org.uk> wrote:
> >
> > I agree with this, although how ambitious are such tools? If you're just
> > popping a dialogue asking for user input, there are typically other means
> > of doing that without bringing in a whole GUI framework.
>
> And what are those ways, cross-platform?

Well, you'd have to provide access to platform-specific programs or services 
through an API, since I doubt that kdialog or xdialog are provided with 
Windows, for example, although it would be surprising if nothing of that 
nature was shipped with Windows. Additionally, if you treat the GUI usage in 
a functional way - ie. you consider what you want the GUI to show, not the 
details of laying things out, plotting stuff, and so on - then I imagine a 
number of other domain-specific services could be provided, such as command 
line argument editors and so on (as has already been shown elsewhere).

Not that any domain-specific services are likely to provide a full answer, but 
if you consider the examples given above, in addition to simple things like 
webbrowser or alternatives such as os.startfile (and my desktop module), it 
is evident that there's a certain amount of scope for simple desktop 
integration that doesn't require a full toolkit and the complexity which it 
entails.

> > > But for small tools (for example, a configuration control panel),
> > > the extra step of installing a UI framework may be significant.
> >
> > I think the reduced friction is less about the installation and a lot
> > more to do with which API you use:
>
> It's both.

That's why I wrote "less about" rather than "not about". ;-)

> > Scaling a standard up to complicated,
> > integrated applications is a mostly unsolved problem, though.
>
> So accept that complicated integrated applications will need to go
> beyond the standard library's offerings, and (almost) stop worrying
> about them.

Perhaps you can say that "I'm going to do a small project which only needs the 
standard library API" or instead that "I'm going to write a mega-application 
which needs a complicated API" but even if no-one ever needs to migrate their 
half-finished applications between the two APIs, you still provide a 
confusing message to developers.

Paul

From ronaldoussoren at mac.com  Mon May  8 17:47:26 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 8 May 2006 17:47:26 +0200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <200605081138.52823.fdrake@acm.org>
References: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
	<9C4264C7-42EB-425A-8797-9F1178EB25A1@mac.com>
	<200605081138.52823.fdrake@acm.org>
Message-ID: <0492B926-C6F2-4063-9CBF-B97D9237EBDB@mac.com>


On 8-mei-2006, at 17:38, Fred L. Drake, Jr. wrote:

> On Monday 08 May 2006 05:39, Ronald Oussoren wrote:
>> Yes there is. Some distributors are lame enough to think they know  
>> better
>> and ship parts of the standard library seperately, but that's not  
>> a valid
>> reason for removing parts of the stdlib.
>
> Hopefully they'll learn.  This is been a regular problem for the  
> distutils
> package, which is pure Python.

I don't think they'll ever learn, because there is a good reason for  
putting tkinter in a separate os package: the dependency on tcl/tk.  
Because of this it is probably save to assume that any GUI package  
will suffer from this split by (linux) distributors.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20060508/e3906c67/attachment.bin 

From fdrake at acm.org  Mon May  8 17:59:03 2006
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon, 8 May 2006 11:59:03 -0400
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <0492B926-C6F2-4063-9CBF-B97D9237EBDB@mac.com>
References: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
	<200605081138.52823.fdrake@acm.org>
	<0492B926-C6F2-4063-9CBF-B97D9237EBDB@mac.com>
Message-ID: <200605081159.03756.fdrake@acm.org>

On Monday 08 May 2006 11:47, Ronald Oussoren wrote:
 > I don't think they'll ever learn, because there is a good reason for
 > putting tkinter in a separate os package: the dependency on tcl/tk.
 > Because of this it is probably save to assume that any GUI package
 > will suffer from this split by (linux) distributors.

Yes, there is a good reason for Tkinter to be separate.  There's not a good 
reason for distutils to be separate.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From jimjjewett at gmail.com  Mon May  8 18:30:00 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 8 May 2006 12:30:00 -0400
Subject: [Python-3000] What to do about IDLE?
In-Reply-To: <loom.20060506T110352-762@post.gmane.org>
References: <loom.20060506T110352-762@post.gmane.org>
Message-ID: <fb6fbf560605080930p5628dd16m68130ef341768bd6@mail.gmail.com>

On 5/6/06, Talin <talin at acm.org> wrote:

> I'd be curious to know how many Python developers actually use IDLE?

I do.

The fact that 2.5 got to alpha 2 before anyone noticed that the new
Quitter object didn't work suggests that either I'm in the minority. 
(Though that could just be not shutting down at all, or using older
methods.)

> Clearly IDLE is never going to be the top-end IDE for Python
> development, so what is its purpose? To provide a "backup" in case a
> top of the line IDE is not available?

That works for me.

I agree that there are better programmer's editors, though
availability is an issue.

I will note that I personally prefer it to the IDEs I have tried
(though they weren't specific to python), because the IDEs were a
little too insistent on having eyes and mouse control as good as the
authors expected.

-jJ

From janssen at parc.com  Mon May  8 19:01:14 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 8 May 2006 10:01:14 PDT
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: Your message of "Mon, 08 May 2006 07:13:36 PDT."
	<20060508141336.GA21306@panix.com> 
Message-ID: <06May8.100119pdt."58641"@synergy1.parc.xerox.com>

I think that there are at least six large GUI platforms these days:

Windows, Mac, X11, Java Swing, .NET Windows.Forms, and AJAX
(CSS/HTML/Javascript/DOM/SVG).

I think you could further argue that the X11 world splits into GNOME
and KDE subsets.

What's interesting about PyGUI is that while it's not an overly
simple-minded toolkit, there's a good chance that it can be ported to
each of these platforms.

Bill

From janssen at parc.com  Mon May  8 19:06:54 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 8 May 2006 10:06:54 PDT
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: Your message of "Mon, 08 May 2006 08:34:47 PDT."
	<200605081734.47437.paul@boddie.org.uk> 
Message-ID: <06May8.100704pdt."58641"@synergy1.parc.xerox.com>

> As to whether PyGUI or anything else of that nature should be in the standard 
> library, my feeling is that if it (PyGUI or anything else) cannot deliver the 
> desired functionality without leaving various kinds of users looking for 
> another toolkit at some level of ambition (eg. providing a file chooser or 
> print dialogue in their application), then we should leave such things out of 
> the standard library and spell out the options in a clear fashion, 
> acknowledging that more than one choice exists but the means of choosing one 
> is not some kind of magic ritual.

Much the same can be said about object type systems or databases, or
nearly every API in the standard library.

There's an old saying, "the best is the enemy of the good", which
tends to bedevil projects like these, and makes it hard to make
reasonable progress.  I'd suggest that we don't fall into that trap.

Bill

From qrczak at knm.org.pl  Mon May  8 20:36:48 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Mon, 08 May 2006 20:36:48 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <1147099922.10381.20.camel@resist.wooz.org> (Barry Warsaw's
	message of "Mon, 08 May 2006 10:52:02 -0400")
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
Message-ID: <87vesg1hz3.fsf@qrnik.zagroda>

Barry Warsaw <barry at python.org> writes:

> Obviously if someone registers a callback that isn't callable,
> we don't want to waste time on every iteration trying to call it,
> only to catch whatever error might occur.

Who cares about performance of wrong code?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From rasky at develer.com  Mon May  8 20:45:39 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Mon, 8 May 2006 20:45:39 +0200
Subject: [Python-3000] What do do about IDLE?
References: <200605081341.07969.paul@boddie.org.uk>
	<20060508141336.GA21306@panix.com>
Message-ID: <02f201c672cf$99fc18b0$bf03030a@trilan>

Aahz wrote:

> On Mon, May 08, 2006, Paul Boddie wrote:
>>
>> Well, Tk is available on the "big three" (Windows, Mac, UNIX),
>> but if you venture onto other platforms, don't expect to find it
>> there. People may argue that the "big three" are all that matter,
>> but that argument usually ends up with the "big two" and then
>> total incoherence: eg. "this works on the Windows and Mac, whereas
>> this works on Windows and UNIX"; something that has gradually (and
>> thankfully) been eradicated over the past few years in parts of the
>> standard library.
>
> Aside from Java and Swing (which has its own set of problems), is
> there any readily-available GUI that includes a significant number of
> platforms other than the Big Three?

Qt4 is readily available for Big Three + embedded platforms. I don't think
PyQt4 supports such port, though. It's not fully free, either. Personally, I
find PyQt4 a span ahead of any competing library, thanks to the clean design
of Qt (it's not a case that Qt is leader in the C++ GUI market). It's not
fully Pythonic, but it bloody works. And in this messed up GUI world, a
toolkit that works is gold.
-- 
Giovanni Bajo


From barry at python.org  Mon May  8 21:54:04 2006
From: barry at python.org (Barry Warsaw)
Date: Mon, 08 May 2006 15:54:04 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <87vesg1hz3.fsf@qrnik.zagroda>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<87vesg1hz3.fsf@qrnik.zagroda>
Message-ID: <1147118044.11895.13.camel@resist.wooz.org>

On Mon, 2006-05-08 at 20:36 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> Barry Warsaw <barry at python.org> writes:
> 
> > Obviously if someone registers a callback that isn't callable,
> > we don't want to waste time on every iteration trying to call it,
> > only to catch whatever error might occur.
> 
> Who cares about performance of wrong code?

I do, since I'm trying to be robust in the case of errors in user
extensions.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-3000/attachments/20060508/d7a65003/attachment.pgp 

From barry at python.org  Mon May  8 21:55:03 2006
From: barry at python.org (Barry Warsaw)
Date: Mon, 08 May 2006 15:55:03 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
Message-ID: <1147118103.11894.14.camel@resist.wooz.org>

On Mon, 2006-05-08 at 09:47 -0600, Steven Bethard wrote:
> On 5/8/06, Barry Warsaw <barry at python.org> wrote:
> > Perhaps then, if we get rid of callable()/PyCallable_Check() it would be
> > useful to add a NotCallableError (as a subclass of TypeError?) that
> > would get thrown should you try to call something that's not callable.
> > The argument to the exception would be the thing you tried to
> > erroneously called.
> 
> +1.  It'd certainly be nice to be able to tell the difference between
> the following two TypeErrors:
> 
>     >>> def s():
>     ...     raise TypeError()
>     ...
>     >>> 's'()
>     Traceback (most recent call last):
>       File "<interactive input>", line 1, in ?
>     TypeError: 'str' object is not callable
>     >>> s()
>     Traceback (most recent call last):
>       File "<interactive input>", line 1, in ?
>       File "<interactive input>", line 2, in s
>     TypeError

BTW, this is something we could add for Python 2.x if we wanted to.
Since NotCallableError would be a subclass of TypeError, all existing
code should continue to work.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-3000/attachments/20060508/0c8e8eaa/attachment.pgp 

From aleaxit at gmail.com  Mon May  8 22:25:41 2006
From: aleaxit at gmail.com (Alex Martelli)
Date: Mon, 8 May 2006 13:25:41 -0700
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <02f201c672cf$99fc18b0$bf03030a@trilan>
References: <200605081341.07969.paul@boddie.org.uk>
	<20060508141336.GA21306@panix.com>
	<02f201c672cf$99fc18b0$bf03030a@trilan>
Message-ID: <e8a0972d0605081325l232c3c77m47b08a291bd32c98@mail.gmail.com>

On 5/8/06, Giovanni Bajo <rasky at develer.com> wrote:
   ...
> of Qt (it's not a case that Qt is leader in the C++ GUI market). It's not

I think Giovanni means "it's not by chance that" (&c), i.e. he's
asserting that Qt IS the leader, and that there are non-random
explanations for this (sorry for butting in, but it looks to me like
Giovanni's transliterating an Italian idiom too literally and thereby
potentially conveying to English-mothertongue readers the reverse
meaning from what he intends; as a long-time Qt fan I'd find it sad if
this miscommunication happened!-).


Alex

From collinw at gmail.com  Mon May  8 23:22:01 2006
From: collinw at gmail.com (Collin Winter)
Date: Mon, 8 May 2006 17:22:01 -0400
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <ca471dc20605071945x3fd2c407hd29e7973b5ff6232@mail.gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
	<4455C828.1060209@gmail.com>
	<43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>
	<ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>
	<43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com>
	<ca471dc20605060829r30abe8e7sddb6b4a3b53cce4c@mail.gmail.com>
	<43aa6ff70605071147g5820c0aet61db0290bfca46e7@mail.gmail.com>
	<ca471dc20605071945x3fd2c407hd29e7973b5ff6232@mail.gmail.com>
Message-ID: <43aa6ff70605081422j468b8a04o1bfe7f6b1ce4aec1@mail.gmail.com>

On 5/7/06, Guido van Rossum <guido at python.org> wrote:
> On 5/7/06, Collin Winter <collinw at gmail.com> wrote:
> > This -- more intuitive error messages -- is really what I'm after, and
> > while you may think of type of "def foo(a, b, c):..." as "a function
> > with three required arguments", I'd wager that most Python
> > programmers, if asked what type foo has, would say simply, "it's a
> > function".
>
> Then introducing a new exception isn't going to make a difference.

Sure it will: the name of the exception class is effectively part of
the error message once the exception instance bubbles up to the user.
"TypeError: foo() got an unexpected keyword argument 'bar'".

Collin Winter

From greg.ewing at canterbury.ac.nz  Tue May  9 01:35:52 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 09 May 2006 11:35:52 +1200
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <200605081749.05322.paul@boddie.org.uk>
References: <200605081458.06846.paul@boddie.org.uk>
	<fb6fbf560605080720v6a7d4969y1d0c954bee809c2@mail.gmail.com>
	<200605081749.05322.paul@boddie.org.uk>
Message-ID: <445FD5D8.7060803@canterbury.ac.nz>

Paul Boddie wrote:

> Perhaps you can say that "I'm going to do a small project which only needs the 
> standard library API" or instead that "I'm going to write a mega-application 
> which needs a complicated API"

There seems to be an assumption here that a big application
with a complicated UI necessarily requires a big GUI library
with an elaborate API in order to implement it. I don't
agree with that assumption.

--
Greg

From greg.ewing at canterbury.ac.nz  Tue May  9 01:48:20 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 09 May 2006 11:48:20 +1200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <e8a0972d0605081325l232c3c77m47b08a291bd32c98@mail.gmail.com>
References: <200605081341.07969.paul@boddie.org.uk>
	<20060508141336.GA21306@panix.com>
	<02f201c672cf$99fc18b0$bf03030a@trilan>
	<e8a0972d0605081325l232c3c77m47b08a291bd32c98@mail.gmail.com>
Message-ID: <445FD8C4.9030503@canterbury.ac.nz>

Alex Martelli wrote:
> On 5/8/06, Giovanni Bajo <rasky at develer.com> wrote:
>
>>of Qt (it's not a case that Qt is leader in the C++ GUI market). It's not
> 
> I think Giovanni means "it's not by chance that" (&c), ...
 > it looks to me like
> Giovanni's transliterating an Italian idiom too literally

Would something like "there's no argument that..." be
a better translation?

--
Greg (whose knowledge of Italian approaches zero very rapidly)


From greg.ewing at canterbury.ac.nz  Tue May  9 02:42:06 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 09 May 2006 12:42:06 +1200
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <200605081734.47437.paul@boddie.org.uk>
References: <200605081458.06846.paul@boddie.org.uk>
	<445F480E.1080808@canterbury.ac.nz>
	<200605081734.47437.paul@boddie.org.uk>
Message-ID: <445FE55E.3000701@canterbury.ac.nz>

Paul Boddie wrote:
> I think it would be 
> a bad thing if something in the standard library claimed to provide, or just 
> gave the vague impression of providing, a definitive solution for all 
> environments

I would never claim that PyGUI provided a definitive solution
for all environments (and as has been pointed out, no such
claim is made for anything else in the stdlib either).

First and foremost, I'm creating PyGUI because *I* want it,
for programs that I write. The most important thing about
PyGUI for me is the API. I've used quite a number of other
Python GUI APIs, and I've never found one that wasn't too
complicated or unpythonic or generally cruddy for my liking.
I want an API that fits in my brain along with the rest of
Python.

The next most important thing is to have it work easily on a
reasonably wide range of platforms, so that I can share my
programs with others without requiring them to jump through
hoops to get them working.

I don't particularly mind whether it gets into the standard
library. From my point of view it would be nice, but I'm
happy to include it along with the applications I distribute
if necessary. I'm hoping to keep it small enough to make
that practicable.

In the interests of keeping it small (both in terms of API
and code size) I don't consider it vital to provide a huge
number of widgets. I'd rather have a compact library with
10 well-chosen generally-useful widgets that I can build on,
than a bloated one with 500 highly specialised widgets.
(Okay, so 500 is an exaggeration, but someone mentioned
100 widgets. I flatly disbelieve that anyone *needs* 100
widgets for even the most demanding application.)

 > what if I want to write a GNOME application; which
> language should I choose?

This is more or less the opposite question to the one
PyGUI addresses, which is: I want to write a GUI application
in Python -- what toolkit do I use? PyGUI's answer is:
Use one that's specifically designed for writing GUI
applications in Python.

Such a thing currently does not exist. That is what
PyGUI is meant to be.

--
Greg

From aleaxit at gmail.com  Tue May  9 02:48:42 2006
From: aleaxit at gmail.com (Alex Martelli)
Date: Mon, 8 May 2006 17:48:42 -0700
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <445FD8C4.9030503@canterbury.ac.nz>
References: <200605081341.07969.paul@boddie.org.uk>
	<20060508141336.GA21306@panix.com>
	<02f201c672cf$99fc18b0$bf03030a@trilan>
	<e8a0972d0605081325l232c3c77m47b08a291bd32c98@mail.gmail.com>
	<445FD8C4.9030503@canterbury.ac.nz>
Message-ID: <e8a0972d0605081748q132f5360r9a939e27820abe69@mail.gmail.com>

On 5/8/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Alex Martelli wrote:
> > On 5/8/06, Giovanni Bajo <rasky at develer.com> wrote:
> >
> >>of Qt (it's not a case that Qt is leader in the C++ GUI market). It's not
> >
> > I think Giovanni means "it's not by chance that" (&c), ...
>  > it looks to me like
> > Giovanni's transliterating an Italian idiom too literally
>
> Would something like "there's no argument that..." be
> a better translation?

The original is "non e` un caso che ...", which literally means "it's
not a random occurrence that ..." -- I believe the British "it's not
by chance that ..." comes very close.


Alex

From guido at python.org  Tue May  9 02:53:00 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 8 May 2006 17:53:00 -0700
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <43aa6ff70605081422j468b8a04o1bfe7f6b1ce4aec1@mail.gmail.com>
References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com>
	<4455C828.1060209@gmail.com>
	<43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com>
	<ca471dc20605051355g519bccf0q797738314753d2ba@mail.gmail.com>
	<43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com>
	<ca471dc20605060829r30abe8e7sddb6b4a3b53cce4c@mail.gmail.com>
	<43aa6ff70605071147g5820c0aet61db0290bfca46e7@mail.gmail.com>
	<ca471dc20605071945x3fd2c407hd29e7973b5ff6232@mail.gmail.com>
	<43aa6ff70605081422j468b8a04o1bfe7f6b1ce4aec1@mail.gmail.com>
Message-ID: <ca471dc20605081753g1c5b4270q74d91c5e616f0087@mail.gmail.com>

Can we just agree to disagree? Read the piece on python.org/dev about
knowing when to stop.

On 5/8/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/7/06, Guido van Rossum <guido at python.org> wrote:
> > On 5/7/06, Collin Winter <collinw at gmail.com> wrote:
> > > This -- more intuitive error messages -- is really what I'm after, and
> > > while you may think of type of "def foo(a, b, c):..." as "a function
> > > with three required arguments", I'd wager that most Python
> > > programmers, if asked what type foo has, would say simply, "it's a
> > > function".
> >
> > Then introducing a new exception isn't going to make a difference.
>
> Sure it will: the name of the exception class is effectively part of
> the error message once the exception instance bubbles up to the user.
> "TypeError: foo() got an unexpected keyword argument 'bar'".
>
> Collin Winter
>


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

From guido at python.org  Tue May  9 03:33:37 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 8 May 2006 18:33:37 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
Message-ID: <ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>

On 5/8/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> It'd certainly be nice to be able to tell the difference between
> the following two TypeErrors:
>
>     >>> def s():
>     ...     raise TypeError()
>     ...
>     >>> 's'()
>     Traceback (most recent call last):
>       File "<interactive input>", line 1, in ?
>     TypeError: 'str' object is not callable
>     >>> s()
>     Traceback (most recent call last):
>       File "<interactive input>", line 1, in ?
>       File "<interactive input>", line 2, in s
>     TypeError

You're kidding yourself. Consider these two:

def s():
  raise NotCallable("ha ha, fooled you!")

or more likely any variant of this:

def s():
  's'()

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

From steven.bethard at gmail.com  Tue May  9 04:51:35 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Mon, 8 May 2006 20:51:35 -0600
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
	<ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>
Message-ID: <d11dcfba0605081951jd2a894an9c5da73996f80349@mail.gmail.com>

On 5/8/06, Guido van Rossum <guido at python.org> wrote:
> On 5/8/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > It'd certainly be nice to be able to tell the difference between
> > the following two TypeErrors:
> >
> >     >>> def s():
> >     ...     raise TypeError()
> >     ...
> >     >>> 's'()
> >     Traceback (most recent call last):
> >       File "<interactive input>", line 1, in ?
> >     TypeError: 'str' object is not callable
> >     >>> s()
> >     Traceback (most recent call last):
> >       File "<interactive input>", line 1, in ?
> >       File "<interactive input>", line 2, in s
> >     TypeError
>
> You're kidding yourself. Consider these two:
>
> def s():
>   raise NotCallable("ha ha, fooled you!")

This one does exactly what I would hope it to.  The writer of the
callable has indicated that this function is not to be called by
raising NotCallableError.  This would be especially appropriate in a
subclass that wants to break substitutability and remove the __call__
method.  Sure, people could abuse it, but we're all supposed to be
adults here, right?

> or more likely any variant of this:
>
> def s():
>   's'()

Sorry if I came across as suggesting that adding NotCallableError
would solve all the world's problems ;-) If you caught a
NotCallableError, you would know that either the object you called was
not callable, or it called some other object that was not callable and
didn't trap the exception.  That's a fair bit more informative than
the current situation with TypeError, since a lot more things raise
TypeErrors:

    >>> iter(1)
    Traceback (most recent call last):
      File "<interactive input>", line 1, in ?
    TypeError: iteration over non-sequence
    >>> 'abc'['1']
    Traceback (most recent call last):
      File "<interactive input>", line 1, in ?
    TypeError: string indices must be integers
    >>> str(1, 16)
    Traceback (most recent call last):
      File "<interactive input>", line 1, in ?
    TypeError: str() takes at most 1 argument (2 given)
    >>> 42 + '56'
    Traceback (most recent call last):
      File "<interactive input>", line 1, in ?
    TypeError: unsupported operand type(s) for +: 'int' and 'str'

So if I catch a TypeError, it could be because the object I called was
not callable, or it could be because when calling that object, any one
of the above TypeErrors was raised.

Still, like you say, NotCallableError's not a silver bullet.

STeVe
--
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From guido at python.org  Tue May  9 05:51:42 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 8 May 2006 20:51:42 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <d11dcfba0605081951jd2a894an9c5da73996f80349@mail.gmail.com>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
	<ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>
	<d11dcfba0605081951jd2a894an9c5da73996f80349@mail.gmail.com>
Message-ID: <ca471dc20605082051t4bbce985w11e7fda12a401a05@mail.gmail.com>

Well, personally, I don't see the advantage. I don't see the point of
having lots of different exception types that say "you made a
programming error" in different ways, and I severely doubt the
usefulness of being able to distinguish between those different
failure modes at run time. Others do. I doubt that one side is able to
convince the other side. So let's agree to disagree.

--Guido

On 5/8/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 5/8/06, Guido van Rossum <guido at python.org> wrote:
> > On 5/8/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > > It'd certainly be nice to be able to tell the difference between
> > > the following two TypeErrors:
> > >
> > >     >>> def s():
> > >     ...     raise TypeError()
> > >     ...
> > >     >>> 's'()
> > >     Traceback (most recent call last):
> > >       File "<interactive input>", line 1, in ?
> > >     TypeError: 'str' object is not callable
> > >     >>> s()
> > >     Traceback (most recent call last):
> > >       File "<interactive input>", line 1, in ?
> > >       File "<interactive input>", line 2, in s
> > >     TypeError
> >
> > You're kidding yourself. Consider these two:
> >
> > def s():
> >   raise NotCallable("ha ha, fooled you!")
>
> This one does exactly what I would hope it to.  The writer of the
> callable has indicated that this function is not to be called by
> raising NotCallableError.  This would be especially appropriate in a
> subclass that wants to break substitutability and remove the __call__
> method.  Sure, people could abuse it, but we're all supposed to be
> adults here, right?
>
> > or more likely any variant of this:
> >
> > def s():
> >   's'()
>
> Sorry if I came across as suggesting that adding NotCallableError
> would solve all the world's problems ;-) If you caught a
> NotCallableError, you would know that either the object you called was
> not callable, or it called some other object that was not callable and
> didn't trap the exception.  That's a fair bit more informative than
> the current situation with TypeError, since a lot more things raise
> TypeErrors:
>
>     >>> iter(1)
>     Traceback (most recent call last):
>       File "<interactive input>", line 1, in ?
>     TypeError: iteration over non-sequence
>     >>> 'abc'['1']
>     Traceback (most recent call last):
>       File "<interactive input>", line 1, in ?
>     TypeError: string indices must be integers
>     >>> str(1, 16)
>     Traceback (most recent call last):
>       File "<interactive input>", line 1, in ?
>     TypeError: str() takes at most 1 argument (2 given)
>     >>> 42 + '56'
>     Traceback (most recent call last):
>       File "<interactive input>", line 1, in ?
>     TypeError: unsupported operand type(s) for +: 'int' and 'str'
>
> So if I catch a TypeError, it could be because the object I called was
> not callable, or it could be because when calling that object, any one
> of the above TypeErrors was raised.
>
> Still, like you say, NotCallableError's not a silver bullet.
>
> STeVe
> --
> Grammar am for people who can't think for myself.
>         --- Bucky Katt, Get Fuzzy
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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

From barry at python.org  Tue May  9 06:08:27 2006
From: barry at python.org (Barry Warsaw)
Date: Tue, 09 May 2006 00:08:27 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <ca471dc20605082051t4bbce985w11e7fda12a401a05@mail.gmail.com>
References: <loom.20060507T073352-865@post.gmane.org>
	<445D89E5.8040609@canterbury.ac.nz>
	<loom.20060507T082010-251@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
	<ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>
	<d11dcfba0605081951jd2a894an9c5da73996f80349@mail.gmail.com>
	<ca471dc20605082051t4bbce985w11e7fda12a401a05@mail.gmail.com>
Message-ID: <1147147707.12713.123.camel@resist.wooz.org>

On Mon, 2006-05-08 at 20:51 -0700, Guido van Rossum wrote:
> Well, personally, I don't see the advantage. I don't see the point of
> having lots of different exception types that say "you made a
> programming error" in different ways, and I severely doubt the
> usefulness of being able to distinguish between those different
> failure modes at run time. Others do. I doubt that one side is able to
> convince the other side. So let's agree to disagree.

What about including the object you tried to call as an attribute on the
TypeError?

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-3000/attachments/20060509/96295e43/attachment.pgp 

From guido at python.org  Tue May  9 06:23:40 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 8 May 2006 21:23:40 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <1147147707.12713.123.camel@resist.wooz.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
	<ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>
	<d11dcfba0605081951jd2a894an9c5da73996f80349@mail.gmail.com>
	<ca471dc20605082051t4bbce985w11e7fda12a401a05@mail.gmail.com>
	<1147147707.12713.123.camel@resist.wooz.org>
Message-ID: <ca471dc20605082123r54515350n27e5bc7b868837eb@mail.gmail.com>

Now we're talking. Although it might make more sense if (an
abbreviated form of) its repr() were included in the error message --
that would help most humans diagnose the situation most easily.

--Guido

On 5/8/06, Barry Warsaw <barry at python.org> wrote:
> On Mon, 2006-05-08 at 20:51 -0700, Guido van Rossum wrote:
> > Well, personally, I don't see the advantage. I don't see the point of
> > having lots of different exception types that say "you made a
> > programming error" in different ways, and I severely doubt the
> > usefulness of being able to distinguish between those different
> > failure modes at run time. Others do. I doubt that one side is able to
> > convince the other side. So let's agree to disagree.
>
> What about including the object you tried to call as an attribute on the
> TypeError?
>
> -Barry
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iQCVAwUARGAVunEjvBPtnXfVAQKyxwP+P1n/GcDsZiW886e8rd1Z7NUni/cjh0ze
> 11r+fD2hUFg/NvNdYM/VVR2tA2zfcQP96Rzsf40praHpQqc82aZkVxCXUa8iQqOX
> TRCCKxhRYSkRU9AXiwmzho/Bx8D20HHXnMBfR4FSDFXQ+u8iSnYbCD895a7u9M1c
> LXxFsy3YuFQ=
> =e4x8
> -----END PGP SIGNATURE-----
>
>
>


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

From g.brandl at gmx.net  Tue May  9 07:33:06 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 09 May 2006 07:33:06 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <ca471dc20605082051t4bbce985w11e7fda12a401a05@mail.gmail.com>
References: <loom.20060507T073352-865@post.gmane.org>	<445D89E5.8040609@canterbury.ac.nz>	<loom.20060507T082010-251@post.gmane.org>	<445DDC87.5040403@canterbury.ac.nz>
	<e3nhop$vek$1@sea.gmane.org>	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>	<1147099922.10381.20.camel@resist.wooz.org>	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>	<ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>	<d11dcfba0605081951jd2a894an9c5da73996f80349@mail.gmail.com>
	<ca471dc20605082051t4bbce985w11e7fda12a401a05@mail.gmail.com>
Message-ID: <e3p9ij$nb7$1@sea.gmane.org>

Guido van Rossum wrote:
> Well, personally, I don't see the advantage. I don't see the point of
> having lots of different exception types that say "you made a
> programming error" in different ways, and I severely doubt the
> usefulness of being able to distinguish between those different
> failure modes at run time. Others do. I doubt that one side is able to
> convince the other side. So let's agree to disagree.

I could see an issue with something like this:

try:
    # do a call that can fail with TypeError under certain conditions
    do_call()
except TypeError:
    # assume that the call failed

If you now make an error in do_call(), e.g. calling a function with too
many arguments, your code always assumes that the call failed.
Sure, it should be caught by unit testing, but it needs debugging anyway.

Georg


From jcarlson at uci.edu  Tue May  9 08:20:25 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 08 May 2006 23:20:25 -0700
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <445FE55E.3000701@canterbury.ac.nz>
References: <200605081734.47437.paul@boddie.org.uk>
	<445FE55E.3000701@canterbury.ac.nz>
Message-ID: <20060508231359.67E9.JCARLSON@uci.edu>


Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> In the interests of keeping it small (both in terms of API
> and code size) I don't consider it vital to provide a huge
> number of widgets. I'd rather have a compact library with
> 10 well-chosen generally-useful widgets that I can build on,
> than a bloated one with 500 highly specialised widgets.
> (Okay, so 500 is an exaggeration, but someone mentioned
> 100 widgets. I flatly disbelieve that anyone *needs* 100
> widgets for even the most demanding application.)

You may very well be referring to me.  I mentioned that people who were
considering PyGUI as the 'de-facto' standard for Python GUI libraries
take a wander through the wxPython demo to see what a generally
fully-featured library offers.

I also mentioned that while I didn't think that a standard library
module would necessarily need to include all of those widgets (or their
equivalent), "there are literally dozens of widgets that people would be
disappointed if they couldn't have."

 - Josiah


From talin at acm.org  Tue May  9 08:19:59 2006
From: talin at acm.org (Talin)
Date: Tue, 9 May 2006 06:19:59 +0000 (UTC)
Subject: [Python-3000] PEP 3100 Comments
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.org>
	<fb6fbf560605080657k233091fdi25c82dfc5b3c3a9c@mail.gmail.com>
Message-ID: <loom.20060509T071959-538@post.gmane.org>

Jim Jewett <jimjjewett <at> gmail.com> writes:

> On 5/8/06, Talin <talin <at> acm.org> wrote:
> > Before we go to much further on this point, I want to get a sense of
> > what exactly people are objecting to:
> 
> >     -- Are they saying that interface discovery is not important, or is
> > bad style?
> 
> Not in principle.
> 
> In practice, certain implementation patterns can be bad style.
> 
> In general, python encourages "just try it" instead of "verify the
> preconditions, then try it if you can".
> 
> Obviously, there are times when another style makes more sense, but
> the effort to decide that exceeds the effort of implementing it; by
> default the language should encourage the way that is normally better.
> 
> >     -- Are they saying that the way isSequence and such implements
> > interface discovery is wrong, and if it is, what's the alternative?
> 
> Yes, it is wrong.  There isn't a good (and general) alternative in 2.x.
> 
> The working assumption is that there won't really be a good general
> way in 3 either, unless what you really mean is "Does it have these
> methods", in which case the best way is to test for those methods. 
> isSequence may give false confidence in the answers.

You know, I am sure that a lot of people are tired of this thread, but
I really think that there's a possibility of something constructive
coming out of this.

Rather than arguing about the current library, I would like to
identify what are the fundamental requirements that people need (and
I'm speaking in terms of observed code patterns from existing Python
libs), and how best to go about meeting those needs.

Python is, as has been said, deeply invested in duck typing; This is
one the things that makes the language neat and special. In
particular, duck typing increases modularity by allowing different
pieces of code, developed independently, to interoperate. Any
technique that allows for interoperability of independently created
parts is going to be a big win in terms of distributed development.

For example, in a traditional OOP system, I can create an interface
that accepts objects of a given type or any specialization of that
type. Anyone who wishes to use my implementation must derive from my
abstract types -- in other words, they need to import my code or link
against it somehow.

With duck typing, you don't need to link against my code, all you need
to do is follow the same specification. It means that I, as an
interface designer, can specify a kind of 'abstract model' of a type,
and other people can create their own types that conform to the
restrictions of my model, even if they don't actually have a copy of
my code. All they need to do is read my docs.

(Its interesting to note that C++ templates also give you duck typing
in just this way. For example let's say I have a template class that
implements a refcounting "smart pointer" -- which is a fairly common
C++ idiom these days. The object being refcounted does *not* need to
derive from a common "refcountable" base class -- it simply has to
have IncRef/DecRef methods that have compatible signatures. And
indeed, several people have proposed methods of "testing" C++ classes
to see if they support specific "Concepts", in other words, specific
capabilities.)

OK, so I hope I have established the requirement for duck typing. Now,
I want to establish the requirement for interface discovery or 'type
testing'. Type testing usually comes into play when you are dealing
with interactions between two different class hierarchies. For
example, you might have M different classes that need to be serialized
with N different serializers. Or M different types of events which are
viewed in N different views. (Think of a music scoring program, which
displays various kinds of Midi events in a piano roll view, a drum
machine view, a text view, or a music notation view.) You can use
polymorphism to dispatch to different implementations based on type,
but you can only do it for one type at a time. In the music program
example, either the various editor views have to test the types of the
individual events, or the individual events have to test the types of
the editors.

Now, generic functions are good at dealing with these kinds of
situations. However, generic functions (as they are usually concieved)
can only deal with specific, concrete types, not "types which satisfy
some constraint".

Thus we have a tension between duck types and type testing;
Unfortunately, punting on this issue (i.e. saying "you can't do type
testing on duck types") isn't a good option - both techniques are just
too darn useful to say that you can't use them together.

Suppose I want to be able to create an interface that takes either a
built-in sequence - either a list or tuple - or a user-created
sequence type. Moreoever, I want people to be able to create new types
that also satisfy the requirements of my interface.

I'd like to be able to support user-created objects that are not
derived from the built-in sequence types - because it may be that the
internal representation of the sequence is very different from the
built-ins. There's no reason why my interface should be restricted to
using "official" sequence types, as long as the custom types behave
enough like a sequence.

So the question is - how does the person writing their own sequence
type indicate that their type is to be treated as equivalent to a
sequence, at least for purposes of my API?

A second, related question is - how much like a sequence does the
object have to be? For example, there are many APIs that really only
care if the object is iterable or not.

Most APIs use only a fraction of the full capabilities of a type - so
perhaps what is needed is a way to test only those capabilities. For
example, instead of "isSequence" we could have "isIndexable",
"isIterable", and so on.

Another possibility is to have a special, empty base class that
signals "this object is a sequence". However, you'd also need to
implement the sequence methods, otherwise your advertisement of
"sequence-ness" would be false. At which point does the base class
then become redundant? I'm not sure.

Of course, we could instead somehow mandate that by deriving from that
base class, you are required to implement those methods. However,
that's just a fancy way of saying "interfaces a la Java". Interfaces
are good, but they don't allow the kind of isolation that true duck
typing allows.

Anyway, that's food for thought.

-- Talin



From greg.ewing at canterbury.ac.nz  Tue May  9 08:28:23 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 09 May 2006 18:28:23 +1200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <ca471dc20605082123r54515350n27e5bc7b868837eb@mail.gmail.com>
References: <loom.20060507T073352-865@post.gmane.org>
	<445DDC87.5040403@canterbury.ac.nz> <e3nhop$vek$1@sea.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
	<ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>
	<d11dcfba0605081951jd2a894an9c5da73996f80349@mail.gmail.com>
	<ca471dc20605082051t4bbce985w11e7fda12a401a05@mail.gmail.com>
	<1147147707.12713.123.camel@resist.wooz.org>
	<ca471dc20605082123r54515350n27e5bc7b868837eb@mail.gmail.com>
Message-ID: <44603687.6020905@canterbury.ac.nz>

Guido van Rossum wrote:
> Now we're talking. Although it might make more sense if (an
> abbreviated form of) its repr() were included in the error message --
> that would help most humans diagnose the situation most easily.

While we're on the subject, something that causes me
intense annoyance from time to time is when I get a
message like "Method foobar expects m args, got n",
but it doesn't tell me *which* of the myriad foobar
methods in my program it was trying to call.

It would be much more helpful if it could say something
like "Method YourModule.YourClass.foobar ..."

This might require storing a bit more information
in a function at def time. But it wouldn't be as
difficult as in the earlier discussions about having
a method reference its class, because we don't need
the actual class, just its name.

--
Greg

From greg.ewing at canterbury.ac.nz  Tue May  9 09:15:11 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 09 May 2006 19:15:11 +1200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060509T071959-538@post.gmane.org>
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.org>
	<fb6fbf560605080657k233091fdi25c82dfc5b3c3a9c@mail.gmail.com>
	<loom.20060509T071959-538@post.gmane.org>
Message-ID: <4460417F.5010507@canterbury.ac.nz>

Talin wrote:

 > (Think of a music scoring program, which
 > displays various kinds of Midi events in a piano roll view, a drum
 > machine view, a text view, or a music notation view.)

There is another way of handling things like this, using
a technique known as "double dispatching". For example
the PianoRollView class would send each of the midi
event objects a display_on_piano_roll request, and the
DrumMachineView class would send display_on_drum_score,
etc.

This technique does tend to be difficult to extend,
however, since all the midi objects need to know about
all the possible display options.

> perhaps what is needed is a way to test only those capabilities. For
> example, instead of "isSequence" we could have "isIndexable",
> "isIterable", and so on.

You can do something like that already using
hasattr(x, '__getitem__') etc. Which is all that
these functions could really do, anyway. So it
would just be a matter of whether it's worth
having a nicer way of spelling them.

> Another possibility is to have a special, empty base class that
> signals "this object is a sequence".

Or you could just have an is_sequence class attribute
that is set on classes wanting to proclaim themselves
to be sequences. I do this sort of thing a lot in the
Pyrex compiler, and it seems to work well there. Of
course I'm the person both defining and using the
interfaces -- it might not be so good in the wider
world.

--
Greg

From talin at acm.org  Tue May  9 09:32:58 2006
From: talin at acm.org (Talin)
Date: Tue, 9 May 2006 07:32:58 +0000 (UTC)
Subject: [Python-3000] back with more GUI planning in a few days...
References: <200605081734.47437.paul@boddie.org.uk>
	<445FE55E.3000701@canterbury.ac.nz>
	<20060508231359.67E9.JCARLSON@uci.edu>
Message-ID: <loom.20060509T090138-61@post.gmane.org>

Josiah Carlson <jcarlson <at> uci.edu> writes:

> Greg Ewing <greg.ewing <at> canterbury.ac.nz> wrote:
> > In the interests of keeping it small (both in terms of API
> > and code size) I don't consider it vital to provide a huge
> > number of widgets. I'd rather have a compact library with
> > 10 well-chosen generally-useful widgets that I can build on,
> > than a bloated one with 500 highly specialised widgets.
> > (Okay, so 500 is an exaggeration, but someone mentioned
> > 100 widgets. I flatly disbelieve that anyone *needs* 100
> > widgets for even the most demanding application.)
> 
> You may very well be referring to me.  I mentioned that people who were
> considering PyGUI as the 'de-facto' standard for Python GUI libraries
> take a wander through the wxPython demo to see what a generally
> fully-featured library offers.
> 
> I also mentioned that while I didn't think that a standard library
> module would necessarily need to include all of those widgets (or their
> equivalent), "there are literally dozens of widgets that people would be
> disappointed if they couldn't have."

Its not just numbers of widgets, its also widget capabilities.

The actual number of widgets needed for a basic GUI toolkit isn't
all that large. Off the top of my head, I'd say that there's a palette
of about 20 basic widgets, 5 standard dialogs, and 4-5 layout
algorithms that need to be supported.

But those basic widgets will each have on the order of 10-20
parameters. For example, a button widget would have:

  -- enabled flag
  -- focus flag (for platforms that support keyboard focus)
  -- style
  -- activation type (toggle vs. hold-down, etc.)
  -- tooltip
  -- caption
  -- area
  -- accelerator key (i.e. keyboard equivalent)
  -- icon

and possibly:

  -- foreground color
  -- background color
  -- font
  -- text horizontal alignment
  -- text vertical alignment
  -- tab order

If we compare this list vs. the current supported PyGUI attributes,
we see that it has a ways to go, but not, IMHO, an insurmountable
distance.

A far as widgets go, I think I'd be satisfied (mostly) with the following
(this is just off the top of my head, and not a definitive list):

  Window
  Dialog
  Button / Checkbox / Radio
  Scrollbar
  Slider
  Listview
  Combo box / drop-down
  Scrollview
  Group box
  Tree View (extra credit: support drag and drop.)
  Spinner (i.e. increment/decrement control)
  Grid View
  Text Edit / Multiline Edit / Styled Edit
  Static Text
  Static styled text
  Static Image
  Toolbar (Dockable if supported by the platform)
  Menubar / Menu / Menu item  
  Status bar
  Tab panel

Standard system dialogs:

  Open File
  Save File
  Select Directory
  Color Chooser
  Font Chooser

Standard application dialogs:

  Caption + Single button (notify)
  Caption + Two buttons
  Caption + Text Entry + Two buttons

Standard cursors:

  Arrow
  Hourglass / Wait
  Sizing cursors: left/right, up/down, NE/SW, NW/SE
  I-beam cursor
  Hand / Drag cursor

Standard Alerts:

  Notice
  Warning
  Error

-- Talin



From paul at boddie.org.uk  Tue May  9 13:22:03 2006
From: paul at boddie.org.uk (Paul Boddie)
Date: Tue, 9 May 2006 13:22:03 +0200
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <445FE55E.3000701@canterbury.ac.nz>
References: <200605081458.06846.paul@boddie.org.uk>
	<200605081734.47437.paul@boddie.org.uk>
	<445FE55E.3000701@canterbury.ac.nz>
Message-ID: <200605091322.03286.paul@boddie.org.uk>

On Tuesday 09 May 2006 02:42, Greg Ewing wrote:
> Paul Boddie wrote:
> > I think it would be
> > a bad thing if something in the standard library claimed to provide, or
> > just gave the vague impression of providing, a definitive solution for
> > all environments
>
> I would never claim that PyGUI provided a definitive solution
> for all environments (and as has been pointed out, no such
> claim is made for anything else in the stdlib either).

True: as noted, Tkinter only covers the "big three". However, even if we 
discard QNX, BeOS, OS/2, AtheOS, RISC OS and the Amiga as reasonable 
candidates for running any standard GUI, limiting our attention to the "big 
three", there's a lot of variation especially in the UNIX area that I feel 
needs to be addressed. Perhaps "definitive" should mean "substantially better 
than Tkinter", where this includes a "look and feel" appropriate to the 
target environment, theming, the possibility for bringing in appropriate 
dialogues without having to maintain lookalikes (or at least some kind of 
roadmap to better desktop integration, perhaps like PyGtk -> PyGNOME and PyQt 
-> PyKDE), and a huge list of features that would certainly put me off 
writing a GUI framework.

> First and foremost, I'm creating PyGUI because *I* want it,
> for programs that I write. The most important thing about
> PyGUI for me is the API. I've used quite a number of other
> Python GUI APIs, and I've never found one that wasn't too
> complicated or unpythonic or generally cruddy for my liking.
> I want an API that fits in my brain along with the rest of
> Python.

And, as I said, you should go for it!

> The next most important thing is to have it work easily on a
> reasonably wide range of platforms, so that I can share my
> programs with others without requiring them to jump through
> hoops to get them working.

And I can appreciate that. Indeed, there is a need for such an API beyond 
something like PyGame, and the controversy is limited only to a standard 
library context when people need more than what that API provides and have to 
think about how to advise them.

> I don't particularly mind whether it gets into the standard
> library. From my point of view it would be nice, but I'm
> happy to include it along with the applications I distribute
> if necessary. I'm hoping to keep it small enough to make
> that practicable.

My worry would be that if another toolkit were dropped into "pole position" to 
replace Tkinter, and then people ignored it just as much as they ignored 
Tkinter, choosing other toolkits, then this would involve a lot of 
maintenance to keep the replacement relevant (or to make it appeal to people) 
and a lot of education to steer people around the toolkit where it doesn't 
meet their needs. This last part is often underestimated, and as I mentioned 
a few times, you see the effects in the Web development subcommunity where an 
arguably less ambitious standardisation effort has given way to seeing who 
can shout the loudest, rather than people giving up a fraction of their 
shouting time to contribute to a coherent overview of where all the solutions 
fit together.

[...]

>  > what if I want to write a GNOME application; which
> >
> > language should I choose?
>
> This is more or less the opposite question to the one
> PyGUI addresses, which is: I want to write a GUI application
> in Python -- what toolkit do I use? PyGUI's answer is:
> Use one that's specifically designed for writing GUI
> applications in Python.

And I don't have a problem with that. I was merely pointing out that people do 
have other motivations for considering Python plus a GUI library and that 
Python isn't exactly well-promoted in official circles to appeal to such 
people. It's continuously surprising to me where Python shows up, yet you 
wouldn't hear about many of these solutions in comp.lang.python and the 
related mailing list universe, mostly because people there are thinking about 
Python foremost with the environment as an afterthought, if that. Python was 
once described as a glue language, but sometimes I wonder if the tube is 
blocked up.

> Such a thing currently does not exist. That is what
> PyGUI is meant to be.

I'll leave that point for others to contend. ;-)

Paul

From pje at telecommunity.com  Tue May  9 16:18:58 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 09 May 2006 10:18:58 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <mailman.20906.1147158873.27774.python-3000@python.org>
Message-ID: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>

At 06:19 AM, 9 May 2006 +0000, Talin <talin at acm.org> wrote:
>Now, generic functions are good at dealing with these kinds of
>situations. However, generic functions (as they are usually concieved)
>can only deal with specific, concrete types, not "types which satisfy
>some constraint".

In Haskell, interfaces are defined using "typeclasses".  A typeclass is 
basically a collection of generic functions.  For example, you could define 
a "sortable" typeclass that includes the generic functions for "less than" 
and "equal to".  You can then define a function as taking a "sortable" 
parameter, and it then accepts only values that can be passed to "less 
than" and "equal to".

Further, Haskell has a concept of "typeclass instances" which basically 
give you adaptation.  For example, suppose I have some generic functions 
other than "less than" and "equal to", that do basically the same thing for 
some set of types.  For example, maybe there's some library that has "lt" 
and "eq" functions.  I can define typeclass instance for "sortable" that 
maps "less than" to "lt" and "equals" to "eq" automatically.

With these two features, you get all the remaining benefits of interfaces 
and adaptation, without any of the headaches caused by more traditional 
type systems.  You never have to explicitly declare support for an 
interface, unless you're effectively defining adaptation from a different 
interface.  And anyone can easily define new subsets of "dict-like" or 
"file-like" interfaces containing only the operations they need, because 
these interfaces are just a collection of generic functions that can be 
mixed and matched at will.

In Haskell, a lot of the work can be done by type inference, in that if you 
use "less than" and "equal" generic functions in the body of a method, the 
compiler can usually infer what types that method can thus be applied to, 
without the need to create an explicit typeclass or  type declarations.

(You couldn't get quite that implicit in Python, though; you'd have to have 
at least explicit declaration that you wanted a "sortable" parameter or a 
"mapping" argument.)


>So the question is - how does the person writing their own sequence
>type indicate that their type is to be treated as equivalent to a
>sequence, at least for purposes of my API?

Well, in the generic function world, it would be by defining methods for 
sequence generic functions like len(), iter(), operator.getitem(), and so 
forth.

If we had syntax support for defining such methods, you might do it with e.g.:

      def operator.getitem(self, key):
          ...

which is curiously reminiscent of certain other languages' operator 
overloading.


>A second, related question is - how much like a sequence does the
>object have to be? For example, there are many APIs that really only
>care if the object is iterable or not.
>
>Most APIs use only a fraction of the full capabilities of a type - so
>perhaps what is needed is a way to test only those capabilities. For
>example, instead of "isSequence" we could have "isIndexable",
>"isIterable", and so on.

You mean, like by being able to ask a generic function if it supports a 
particular type signature?  ;)


>Of course, we could instead somehow mandate that by deriving from that
>base class, you are required to implement those methods. However,
>that's just a fancy way of saying "interfaces a la Java". Interfaces
>are good, but they don't allow the kind of isolation that true duck
>typing allows.

Or that generic functions allow.  :)


From aahz at pythoncraft.com  Tue May  9 16:34:45 2006
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 9 May 2006 07:34:45 -0700
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <200605091322.03286.paul@boddie.org.uk>
References: <200605081458.06846.paul@boddie.org.uk>
	<200605081734.47437.paul@boddie.org.uk>
	<445FE55E.3000701@canterbury.ac.nz>
	<200605091322.03286.paul@boddie.org.uk>
Message-ID: <20060509143445.GA22813@panix.com>

On Tue, May 09, 2006, Paul Boddie wrote:
>
> My worry would be that if another toolkit were dropped into "pole
> position" to replace Tkinter, and then people ignored it just as much
> as they ignored Tkinter, choosing other toolkits, then this would
> involve a lot of maintenance to keep the replacement relevant (or
> to make it appeal to people) and a lot of education to steer people
> around the toolkit where it doesn't meet their needs. This last part
> is often underestimated, and as I mentioned a few times, you see the
> effects in the Web development subcommunity where an arguably less
> ambitious standardisation effort has given way to seeing who can shout
> the loudest, rather than people giving up a fraction of their shouting
> time to contribute to a coherent overview of where all the solutions
> fit together.

It's not entirely clear to me just how much people *do* ignore Tkinter,
and it's even less clear whether any toolkit can avoid the fate of
Tkinter.  I think we should focus on whether it makes sense to have a
standard GUI API for Python and which of the available APIs is most
Pythonic.  After that, who cares?

I believe that Python has received a lot of leverage out of the existence
of Tkinter -- if nothing else, the fact that even some experienced
developers rely on IDLE is a signifier of that.  So I am opposed to
removing Tkinter unless it is replaced with something better, and from
my POV, "better" is mostly defined in terms of ease of creating a decent
GUI application *in* *Python*.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours."  --Richard Bach

From janssen at parc.com  Tue May  9 18:30:36 2006
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 May 2006 09:30:36 PDT
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: Your message of "Tue, 09 May 2006 00:32:58 PDT."
	<loom.20060509T090138-61@post.gmane.org> 
Message-ID: <06May9.093036pdt."58641"@synergy1.parc.xerox.com>

> A far as widgets go, I think I'd be satisfied (mostly) with the following
> (this is just off the top of my head, and not a definitive list):
> 
>   Window
>   Dialog
>   Button / Checkbox / Radio
>   Scrollbar
>   Slider
>   Listview
>   Combo box / drop-down
>   Scrollview
>   Group box
>   Tree View (extra credit: support drag and drop.)
>   Spinner (i.e. increment/decrement control)
>   Grid View
>   Text Edit / Multiline Edit / Styled Edit
>   Static Text
>   Static styled text
>   Static Image
>   Toolbar (Dockable if supported by the platform)
>   Menubar / Menu / Menu item  
>   Status bar
>   Tab panel
> 
> Standard system dialogs:
> 
>   Open File
>   Save File
>   Select Directory
>   Color Chooser
>   Font Chooser
> 
> Standard application dialogs:
> 
>   Caption + Single button (notify)
>   Caption + Two buttons
>   Caption + Text Entry + Two buttons
> 
> Standard cursors:
> 
>   Arrow
>   Hourglass / Wait
>   Sizing cursors: left/right, up/down, NE/SW, NW/SE
>   I-beam cursor
>   Hand / Drag cursor
> 
> Standard Alerts:
> 
>   Notice
>   Warning
>   Error

That's an interesting list, Talin.  It's close to my list.

I have to confess I don't see the point of some of them: Listview and
Gridview are trivial if there's a reasonable layout system, Statusbar
and Toolbar are likewise just arrays of other widgets.  Spinner is a
non-issue for me.  I also don't really see the point of the "standard
application dialogs", as they are so easy to build yourself.

"Color chooser" and "Font chooser" seem to fall into the category of
"widgets that aren't used by UIs, but are very hard to build yourself,
so the toolkit should do it", which is a reasonable contention
(though, I think, not overwhelming).

Styled text is another question mark.  Though I've used static styled
text, and found it handy, I'm not sure I'd miss it that much.  Ditto
for editable styled text (I'm not sure I've ever used it).  More
important to me would be a text editor widget which supported in-line
objects, like images and hyperlinks.

Bill

From janssen at parc.com  Tue May  9 18:35:55 2006
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 May 2006 09:35:55 PDT
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: Your message of "Tue, 09 May 2006 07:18:58 PDT."
	<5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com> 
Message-ID: <06May9.093601pdt."58641"@synergy1.parc.xerox.com>

Phillip Eby writes:
> In Haskell, interfaces are defined using "typeclasses".  A typeclass is 
> basically a collection of generic functions.  For example, you could define 
> ...
> Further, Haskell has a concept of "typeclass instances" which basically 
> give you adaptation.  For example, suppose I have some generic functions 

Thanks, Phillip.  That's essentially what I'm talking about with CL
mixins, as well (though instead of typeclass instances you usually
have mixin implementations which are "mixed" into the class which
wishes to provide the interface, to give it the methods).  That's what
I think Py3K should be using, too, instead of "duck typing", which for
some reason has come to be thought of (wrongly) as a "feature".

Bill

From janssen at parc.com  Tue May  9 18:40:51 2006
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 May 2006 09:40:51 PDT
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: Your message of "Tue, 09 May 2006 04:22:03 PDT."
	<200605091322.03286.paul@boddie.org.uk> 
Message-ID: <06May9.094056pdt."58641"@synergy1.parc.xerox.com>

> True: as noted, Tkinter only covers the "big three".

Paul,

Let's stop talking about the "big three" with respect to UI platforms.
There are three big operating system platforms, true.  And clearly
each has its own associated window system.  But there's also AJAX and
the two big virtual environments' window systems, java.awt and
Windows.Forms.  A good Python GUI should be able to cover all *six*,
not just the first three.  I write GUIs that run in Java applets and
browser windows, not just on raw window systems.

Bill

From pje at telecommunity.com  Tue May  9 18:46:04 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 09 May 2006 12:46:04 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <06May9.093601pdt."58641"@synergy1.parc.xerox.com>
References: <Your message of "Tue, 09 May 2006 07:18:58 PDT."
	<5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060509124122.01e6c818@mail.telecommunity.com>

At 09:35 AM 5/9/2006 -0700, Bill Janssen wrote:
>Phillip Eby writes:
> > In Haskell, interfaces are defined using "typeclasses".  A typeclass is
> > basically a collection of generic functions.  For example, you could 
> define
> > ...
> > Further, Haskell has a concept of "typeclass instances" which basically
> > give you adaptation.  For example, suppose I have some generic functions
>
>Thanks, Phillip.  That's essentially what I'm talking about with CL
>mixins, as well (though instead of typeclass instances you usually
>have mixin implementations which are "mixed" into the class which
>wishes to provide the interface, to give it the methods).

Unless this can be done by a third party, it's not at all the same 
thing.  Currently in Python for a third party to add a mixin, they would 
have to hack the class's __bases__, which I am not suggesting here at all.

In fact, it's pretty much the opposite of what I'm suggesting -- you 
shouldn't *have* to make such declarations, let alone monkeypatch a class's 
__bases__.


>That's what
>I think Py3K should be using, too, instead of "duck typing", which for
>some reason has come to be thought of (wrongly) as a "feature".

I don't see that discussion as being even remotely related to what I'm 
talking about, so please don't count my comments as being against duck 
typing or supporting its removal.

Indeed, I consider my suggestion to be support for *extending* duck typing, 
and a vote *against* typing by inheritance.  You seem to be very confused 
about what I said.


From mbk.lists at gmail.com  Tue May  9 18:56:48 2006
From: mbk.lists at gmail.com (Mike Krell)
Date: Tue, 9 May 2006 09:56:48 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
References: <mailman.20906.1147158873.27774.python-3000@python.org>
	<5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
Message-ID: <da7032ce0605090956n7931cbafj21c2a69693eec8a4@mail.gmail.com>

On 5/9/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 06:19 AM, 9 May 2006 +0000, Talin <talin at acm.org> wrote:
> >Now, generic functions are good at dealing with these kinds of
> >situations. However, generic functions (as they are usually concieved)
> >can only deal with specific, concrete types, not "types which satisfy
> >some constraint".
>
>  [Discussion of Haskell's typeclasses snipped]

I tried to follow the recent generic functions / adaptation in Python
3000 discussion, but the details quickly went over my head.  Could
Phillip or some other kind soul give a simple example / summary of how
the final proposal addresses this "types which satisfy some
constraint" question?

From talin at acm.org  Tue May  9 18:57:53 2006
From: talin at acm.org (Talin)
Date: Tue, 09 May 2006 09:57:53 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
References: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
Message-ID: <4460CA11.8020701@acm.org>

Phillip J. Eby wrote:
> At 06:19 AM, 9 May 2006 +0000, Talin <talin at acm.org> wrote:
> 
> In Haskell, interfaces are defined using "typeclasses".  A typeclass is 
> basically a collection of generic functions.  For example, you could 
> define a "sortable" typeclass that includes the generic functions for 
> "less than" and "equal to".  You can then define a function as taking a 
> "sortable" parameter, and it then accepts only values that can be passed 
> to "less than" and "equal to".
> 
> Further, Haskell has a concept of "typeclass instances" which basically 
> give you adaptation.  For example, suppose I have some generic functions 
> other than "less than" and "equal to", that do basically the same thing 
> for some set of types.  For example, maybe there's some library that has 
> "lt" and "eq" functions.  I can define typeclass instance for "sortable" 
> that maps "less than" to "lt" and "equals" to "eq" automatically.
> 
> With these two features, you get all the remaining benefits of 
> interfaces and adaptation, without any of the headaches caused by more 
> traditional type systems.  You never have to explicitly declare support 
> for an interface, unless you're effectively defining adaptation from a 
> different interface.  And anyone can easily define new subsets of 
> "dict-like" or "file-like" interfaces containing only the operations 
> they need, because these interfaces are just a collection of generic 
> functions that can be mixed and matched at will.
> 
> In Haskell, a lot of the work can be done by type inference, in that if 
> you use "less than" and "equal" generic functions in the body of a 
> method, the compiler can usually infer what types that method can thus 
> be applied to, without the need to create an explicit typeclass or  type 
> declarations.
> 
> (You couldn't get quite that implicit in Python, though; you'd have to 
> have at least explicit declaration that you wanted a "sortable" 
> parameter or a "mapping" argument.)

That's really interesting, and sounds like exactly what I want. I'd be 
interested in knowing a little more about the specifics.

Let me offer the following example as a basis for discussion, and see 
how it would work in such a system. (People who have different ideas as 
to how it should be done feel free to chime in -- I want to hear what 
other techniques are out there.)

Let's define a function called "flatten", which takes a complex data 
structure and flattens it, in other words, it transforms it into a 
single linear sequence.

Now, it would be unreasonable to say that "flatten" can handly any 
arbitrary type that is thrown at it. However, it should be able to 
handle any container type that is one of the standard "type classes" if 
I understand what you are saying.

In other words, as long as a type falls into a standard type class, it 
should be possible for flatten to work with it, even if flatten knows 
nothing about the specific type, and the type knows nothing about flatten.

How would something like this be done? Is there some way that we can do 
this in Python?

-- Talin

From solipsis at pitrou.net  Tue May  9 19:01:35 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 09 May 2006 19:01:35 +0200
Subject: [Python-3000] GUI widgets
In-Reply-To: <06May9.093036pdt."58641"@synergy1.parc.xerox.com>
References: <06May9.093036pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <1147194095.24697.18.camel@fsol>


Hi

Le mardi 09 mai 2006 ? 09:30 -0700, Bill Janssen a ?crit :
> I have to confess I don't see the point of some of them: Listview and
> Gridview are trivial if there's a reasonable layout system,

Listviews (and likewise Gridviews) have more functionality than a simple
layout. An average listview provides column headers, resizeable columns,
scrolling management if the list becomes too long. A good listview would
be able to automatically sort itself it the user clicks on a column
header, it would provide an easy insertion/update/deletion API (wx is
awful in that regard because you have to use autoincremented integer
indices into the list... a Pythonic API would allow any hashable object
to reference an item).

Having them integrated into the toolkit means:
- much less work for the GUI developer
- better and more consistent user experience on the desktop

It is a similar argument to saying "we already offer scrollbar widgets,
we don't need to provide scrollable views because the developer can
build them himself".

I'd say Listviews are fundamental. Gridviews seem much less often used.

> Statusbar
> and Toolbar are likewise just arrays of other widgets.

It depends what functionality there is in the toolbar. If the toolbar is
designed to integrate into the dekstop, then the appearance of icons can
be dictated by global settings (picture / text / text below picture /
text on right of the picture). Some toolkits may offer detachable
toolbars (again, depending on global settings from the user). Not to
mention that toolbars can be themed a bit differently than the rest of
the window. Usually toolbar icons do not look like other buttons (e.g.
they are flat instead of bevelled, and their borders only appear when
they are hovered with the mouse).


> I also don't really see the point of the "standard
> application dialogs", as they are so easy to build yourself.

The point is really that they are standard ;-), so they look like other
standard dialogs.
For example all error or warning dialogs will look the same, with the
same icons, the same button order and labeling, etc.

> "Color chooser" and "Font chooser" seem to fall into the category of
> "widgets that aren't used by UIs, but are very hard to build yourself,
> so the toolkit should do it", which is a reasonable contention
> (though, I think, not overwhelming).

Agreed.

> Styled text is another question mark.  Though I've used static styled
> text, and found it handy, I'm not sure I'd miss it that much.  Ditto
> for editable styled text (I'm not sure I've ever used it).

I think styled text display is important. Editable styled text much
less.
An example use case for styled text display: a chat window with chat
messages scrolling along, where you want the name of the participant to
be displayed in bold at the beginning of his/her messages.

Regards

Antoine.



From talin at acm.org  Tue May  9 19:04:14 2006
From: talin at acm.org (Talin)
Date: Tue, 09 May 2006 10:04:14 -0700
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <06May9.093036pdt."58641"@synergy1.parc.xerox.com>
References: <06May9.093036pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <4460CB8E.8090005@acm.org>



Bill Janssen wrote:
>>A far as widgets go, I think I'd be satisfied (mostly) with the following
>>(this is just off the top of my head, and not a definitive list):
>>
>>  Window
>>  Dialog
>>  Button / Checkbox / Radio
>>  Scrollbar
>>  Slider
>>  Listview
>>  Combo box / drop-down
>>  Scrollview
>>  Group box
>>  Tree View (extra credit: support drag and drop.)
>>  Spinner (i.e. increment/decrement control)
>>  Grid View
>>  Text Edit / Multiline Edit / Styled Edit
>>  Static Text
>>  Static styled text
>>  Static Image
>>  Toolbar (Dockable if supported by the platform)
>>  Menubar / Menu / Menu item  
>>  Status bar
>>  Tab panel
>>
>>Standard system dialogs:
>>
>>  Open File
>>  Save File
>>  Select Directory
>>  Color Chooser
>>  Font Chooser
>>
>>Standard application dialogs:
>>
>>  Caption + Single button (notify)
>>  Caption + Two buttons
>>  Caption + Text Entry + Two buttons
>>
>>Standard cursors:
>>
>>  Arrow
>>  Hourglass / Wait
>>  Sizing cursors: left/right, up/down, NE/SW, NW/SE
>>  I-beam cursor
>>  Hand / Drag cursor
>>
>>Standard Alerts:
>>
>>  Notice
>>  Warning
>>  Error
> 
> 
> That's an interesting list, Talin.  It's close to my list.
> 
> I have to confess I don't see the point of some of them: Listview and
> Gridview are trivial if there's a reasonable layout system, Statusbar
> and Toolbar are likewise just arrays of other widgets.  Spinner is a
> non-issue for me.  I also don't really see the point of the "standard
> application dialogs", as they are so easy to build yourself.

Both List views and grid views have behaviors that are subtly different 
from mere groups of independent widgets.

For example, in a list view, the up and down arrow can typically be used 
to select the previous / next item.

Some UI systems have two kinds of list views: a simple "list box", which 
stores only strings, and which scrolls by line rather than by pixel (in 
other words, scrolling is quantized so that you never see "half" of a 
line); and "list views", which can contain arbitrary variable-height 
items and which scroll by pixel.

Both list views and grids are presumed to have dynamic content, in the 
sense that the program is frequently changing the data being displayed.

A grid view is essentially a spread sheet, with row and column headers, 
variable-sized rows and columns, and so on. Its use is somewhat 
specialized - in most cases, a multi-column list view can do the same job.

Spinner is easy to do (it's just a scrollbar without the thumb), and 
supported by every GUI that I've seen. And it gets used fairly frequently.

Statusbar and Standard Yes/No dialogs are convenient packagings of other 
widgets, with an interface wrapper around them. Because the are used so 
much, there's no real reason for the application developer to have to 
reimplement them for every app.

Toolbars are a little different, depending on what level of feature 
support you want. At the most basic level, they are just collections of 
widgets. Most modern platforms, however, allow docking/floating (the 
ability to move the toolbar to different edges of the window), or user 
customization.

> "Color chooser" and "Font chooser" seem to fall into the category of
> "widgets that aren't used by UIs, but are very hard to build yourself,
> so the toolkit should do it", which is a reasonable contention
> (though, I think, not overwhelming).

Actually, they fall into the category of dialogs which look completely 
different on different platforms. The OS X color dialog looks nothing 
like the windows color dialog. Ideally, the application writer should be 
able to just say "ask the user for a color", and the correct sort of 
dialog should pop up.

> Styled text is another question mark.  Though I've used static styled
> text, and found it handy, I'm not sure I'd miss it that much.  Ditto
> for editable styled text (I'm not sure I've ever used it).  More
> important to me would be a text editor widget which supported in-line
> objects, like images and hyperlinks.

Agreed, editable styled text is probably in the realm of an "advanced" 
feature. I only added it because it's been on my mind lately (One of the 
things that I am working on at work is a web browser for embedded 
systems that supports CSS.)

> Bill

From solipsis at pitrou.net  Tue May  9 19:10:14 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 09 May 2006 19:10:14 +0200
Subject: [Python-3000] typeclasses, duck-typing
In-Reply-To: <5.1.1.6.0.20060509124122.01e6c818@mail.telecommunity.com>
References: <Your message of "Tue, 09 May 2006 07:18:58 PDT."
	<5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
	<5.1.1.6.0.20060509124122.01e6c818@mail.telecommunity.com>
Message-ID: <1147194614.24697.25.camel@fsol>


Hi,

Le mardi 09 mai 2006 ? 12:46 -0400, Phillip J. Eby a ?crit :
> Unless this can be done by a third party, it's not at all the same 
> thing.  Currently in Python for a third party to add a mixin, they would 
> have to hack the class's __bases__, which I am not suggesting here at all.
> 
> In fact, it's pretty much the opposite of what I'm suggesting -- you 
> shouldn't *have* to make such declarations, let alone monkeypatch a class's 
> __bases__.

Interestingly, there was a GNU addition to C++ named "signatures" which
achieved roughly the same thing: some kind of compile-time duck-typing.

http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112

Apparently it has been removed in gcc 3 or 4.

Regards

Antoine.



From janssen at parc.com  Tue May  9 19:15:04 2006
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 May 2006 10:15:04 PDT
Subject: [Python-3000] GUI widgets
In-Reply-To: Your message of "Tue, 09 May 2006 10:01:35 PDT."
	<1147194095.24697.18.camel@fsol> 
Message-ID: <06May9.101511pdt."58641"@synergy1.parc.xerox.com>

Antoine Pitrou writes:
> It is a similar argument to saying "we already offer scrollbar widgets,
> we don't need to provide scrollable views because the developer can
> build them himself".

But that seems a reasonable argument, to me.  I'm not saying that
they shouldn't be in the GUI, I'm just saying that it's not a disaster
if they aren't in the initial release.  Things get better over time,
after all.

> I think styled text display is important. Editable styled text much
> less.
> An example use case for styled text display: a chat window with chat
> messages scrolling along, where you want the name of the participant to
> be displayed in bold at the beginning of his/her messages.

Yes, I think I agree with you.  This is fairly simple to implement,
given, say, an HTML parser, fonts, colors, and the ability to draw
text on a window, but it's not completely trivial.  Would be nice to
package in a widget.

Bill


From fdrake at acm.org  Tue May  9 19:25:29 2006
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Tue, 9 May 2006 13:25:29 -0400
Subject: [Python-3000] typeclasses, duck-typing
In-Reply-To: <1147194614.24697.25.camel@fsol>
References: <Your message of "Tue, 09 May 2006 07:18:58 PDT."
	<5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
	<5.1.1.6.0.20060509124122.01e6c818@mail.telecommunity.com>
	<1147194614.24697.25.camel@fsol>
Message-ID: <200605091325.29728.fdrake@acm.org>

On Tuesday 09 May 2006 13:10, Antoine Pitrou wrote:
 > Interestingly, there was a GNU addition to C++ named "signatures" which
 > achieved roughly the same thing: some kind of compile-time duck-typing.
 >
 > http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112

I remember that, thinking it was really kind of cool, and wanting to play with 
it.  Never had time to do so.

 > Apparently it has been removed in gcc 3 or 4.

That's right.  That's when I became glad I hadn't spent time writing code that 
relied on that feature.  :-)


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From pje at telecommunity.com  Tue May  9 19:35:33 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 09 May 2006 13:35:33 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <da7032ce0605090956n7931cbafj21c2a69693eec8a4@mail.gmail.co
 m>
References: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
	<mailman.20906.1147158873.27774.python-3000@python.org>
	<5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060509133112.01e6c660@mail.telecommunity.com>

At 09:56 AM 5/9/2006 -0700, Mike Krell wrote:
>On 5/9/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>At 06:19 AM, 9 May 2006 +0000, Talin <talin at acm.org> wrote:
>> >Now, generic functions are good at dealing with these kinds of
>> >situations. However, generic functions (as they are usually concieved)
>> >can only deal with specific, concrete types, not "types which satisfy
>> >some constraint".
>>
>>  [Discussion of Haskell's typeclasses snipped]
>
>I tried to follow the recent generic functions / adaptation in Python
>3000 discussion, but the details quickly went over my head.  Could
>Phillip or some other kind soul give a simple example / summary of how
>the final proposal addresses this "types which satisfy some
>constraint" question?

The idea is that constraints are based on what operations can be performed 
on the type.  In today's duck typing, you do this by seeing if the object 
has an attribute -- the method for performing the operation.  So you're 
querying the object for the operation

In a generic function/typeclass world, you would instead ask the operation 
if it supports the object...  almost as if you could say 
'len.supports(someobject)' instead of 'hasattr(someobject,"__len__")'.

Typeclasses then extend this idea to say that you could declare a 
particular parameter of a function as having to be supported by len(), 
operator.getitem() and so forth...  or for convenience's sake, you could 
define a typeclass like "read-only sequence" to mean an object can be used 
with len(), getitem() and iter().  You would then use that typeclass to 
define parameter types.


From krstic at fas.harvard.edu  Tue May  9 19:44:54 2006
From: krstic at fas.harvard.edu (Ivan Krstic)
Date: Tue, 09 May 2006 13:44:54 -0400
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <06May9.094056pdt."58641"@synergy1.parc.xerox.com>
References: <06May9.094056pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <4460D516.6090305@fas.harvard.edu>

Bill Janssen wrote:
> There are three big operating system platforms, true.  And clearly
> each has its own associated window system.  But there's also AJAX 

How exactly would a good Python GUI "cover" AJAX?

-- 
Ivan Krstic <krstic at fas.harvard.edu> | GPG: 0x147C722D

From pje at telecommunity.com  Tue May  9 19:56:53 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 09 May 2006 13:56:53 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <4460CA11.8020701@acm.org>
References: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
	<5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060509133602.01e95990@mail.telecommunity.com>

At 09:57 AM 5/9/2006 -0700, Talin wrote:
>Let me offer the following example as a basis for discussion, and see how 
>it would work in such a system. (People who have different ideas as to how 
>it should be done feel free to chime in -- I want to hear what other 
>techniques are out there.)
>
>Let's define a function called "flatten", which takes a complex data 
>structure and flattens it, in other words, it transforms it into a single 
>linear sequence.
>
>Now, it would be unreasonable to say that "flatten" can handly any 
>arbitrary type that is thrown at it. However, it should be able to handle 
>any container type that is one of the standard "type classes" if I 
>understand what you are saying.
>
>In other words, as long as a type falls into a standard type class, it 
>should be possible for flatten to work with it, even if flatten knows 
>nothing about the specific type, and the type knows nothing about flatten.
>
>How would something like this be done? Is there some way that we can do 
>this in Python?

Assuming we used argument declarations to do overloading, and that actual 
types (other than 'object') are considered to be more specific than 
typeclasses, you would have something like:

     @overloaded
     def flatten(arg:supports(iter)):
         for item in arg:
             for flat in flatten(item):
                 yield flat

     @overloaded
     def flatten(arg:str):
         yield arg

     @overloaded
     def flatten(arg:object):
         yield arg

There are a lot of other ways to spell this, of course; the last two could 
perhaps be combined as a single "def flatten(arg:str|object)", if we had 
union types.

Likewise, it might be that instead of using 'str' as a concrete type, one 
might instead use the existence of some string operation or operations to 
indicate that an object is stringlike.  This has the advantage that any 
stringlike type that supports one of the operations would automatically be 
recognized as string-like.


From talin at acm.org  Tue May  9 20:06:20 2006
From: talin at acm.org (Talin)
Date: Tue, 9 May 2006 18:06:20 +0000 (UTC)
Subject: [Python-3000] PEP 3100 Comments
References: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
	<5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
	<4460CA11.8020701@acm.org>
	<5.1.1.6.0.20060509133602.01e95990@mail.telecommunity.com>
Message-ID: <loom.20060509T195949-125@post.gmane.org>

Phillip J. Eby <pje <at> telecommunity.com> writes:

> Assuming we used argument declarations to do overloading, and that actual 
> types (other than 'object') are considered to be more specific than 
> typeclasses, you would have something like:
> 
>      @overloaded
>      def flatten(arg:supports(iter)):
>          for item in arg:
>              for flat in flatten(item):
>                  yield flat
> 
>      @overloaded
>      def flatten(arg:str):
>          yield arg
> 
>      @overloaded
>      def flatten(arg:object):
>          yield arg

I like it. This is exactly what I want. (Is that the same as
saying +1? Am I allowed to vote? :)

My only concern is that it seems that the current plans
for generic functions in Py3K are somewhat less than this.
So we either need to have something like this be doable
in Py3K, or we need to search for another solution.

Actually, there's one other concern, which is - how
efficient is this? Compared to, say, calling isSequence()?

-- Talin



From talin at acm.org  Tue May  9 20:08:40 2006
From: talin at acm.org (Talin)
Date: Tue, 9 May 2006 18:08:40 +0000 (UTC)
Subject: [Python-3000] PEP 3100 Comments
References: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
	<5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com>
	<4460CA11.8020701@acm.org>
	<5.1.1.6.0.20060509133602.01e95990@mail.telecommunity.com>
Message-ID: <loom.20060509T200729-182@post.gmane.org>

Phillip J. Eby <pje <at> telecommunity.com> writes:

> Assuming we used argument declarations to do overloading, and that actual 
> types (other than 'object') are considered to be more specific than 
> typeclasses, you would have something like:

Lets start a new top-level thread to discuss this specific
proposal.

-- Talin




From jimjjewett at gmail.com  Tue May  9 21:07:32 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 9 May 2006 15:07:32 -0400
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <4460D516.6090305@fas.harvard.edu>
References: <4460D516.6090305@fas.harvard.edu>
Message-ID: <fb6fbf560605091207p2418faf0k3b7a695aa9272756@mail.gmail.com>

On 5/9/06, Ivan Krstic <krstic at fas.harvard.edu> wrote:
> Bill Janssen wrote:
> > There are three big operating system platforms, true.  And clearly
> > each has its own associated window system.  But there's also AJAX

> How exactly would a good Python GUI "cover" AJAX?

By spitting out html and javascript, rather than draw/paint commands.

Which is why it is more important to have a pythonic API that can be
implemented (or supersetted) by the various widget sets than it is to
declare a single winner.

-jJ

From signspointtoprobably at yahoo.com  Tue May  9 21:39:40 2006
From: signspointtoprobably at yahoo.com (joe user)
Date: Tue, 9 May 2006 12:39:40 -0700 (PDT)
Subject: [Python-3000]  Changing function-related TypeErrors
Message-ID: <20060509193940.79034.qmail@web38501.mail.mud.yahoo.com>


Does this mean you have no more actual technical reasons to oppose this change, but are just stomping your foot and implying bad things about Winter?  Because there are people who agree with him, and I haven't seen any really compelling reasons to avoid this ten-line modification.  

Seriously, are you just dodging this issue?

>Can we just agree to disagree? Read the piece on python.org/dev about
>knowing when to stop.
>
>On 5/8/06, Collin Winter <collinw at gmail.com> wrote:
>> On 5/7/06, Guido van Rossum <guido at python.org> wrote:
>> > On 5/7/06, Collin Winter <collinw at gmail.com> wrote:
>> > > This -- more intuitive error messages -- is really what I'm after, and
>> > > while you may think of type of "def foo(a, b, c):..." as "a function
>> > > with three required arguments", I'd wager that most Python
>> > > programmers, if asked what type foo has, would say simply, "it's a
>> > > function".
>> >
>> > Then introducing a new exception isn't going to make a difference.
>>
>> Sure it will: the name of the exception class is effectively part of
>> the error message once the exception instance bubbles up to the user.
>> "TypeError: foo() got an unexpected keyword argument 'bar'".
>>
>> Collin Winter
>>
>
>
>--
>--Guido van Rossum (home page: http://www.python.org/~guido/)

		
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2?/min or less.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060509/665ef277/attachment.htm 

From krstic at fas.harvard.edu  Tue May  9 22:04:38 2006
From: krstic at fas.harvard.edu (Ivan Krstic)
Date: Tue, 09 May 2006 16:04:38 -0400
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <fb6fbf560605091207p2418faf0k3b7a695aa9272756@mail.gmail.com>
References: <4460D516.6090305@fas.harvard.edu>
	<fb6fbf560605091207p2418faf0k3b7a695aa9272756@mail.gmail.com>
Message-ID: <4460F5D6.1040803@fas.harvard.edu>

Jim Jewett wrote:
> By spitting out html and javascript, rather than draw/paint commands.

I was afraid you were going to say that. I, for one, welcome our new
AJAX overlords, but to want to task a general GUI toolkit with producing
HTML and Javascript, running a HTTP server, and automagically dealing
with all the server-side logic seems a bit like a really bad joke.

-- 
Ivan Krstic <krstic at fas.harvard.edu> | GPG: 0x147C722D

From thomas at python.org  Tue May  9 22:16:10 2006
From: thomas at python.org (Thomas Wouters)
Date: Tue, 9 May 2006 22:16:10 +0200
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <20060509193940.79034.qmail@web38501.mail.mud.yahoo.com>
References: <20060509193940.79034.qmail@web38501.mail.mud.yahoo.com>
Message-ID: <9e804ac0605091316m7a0dfbcaiab162cb00f1706d6@mail.gmail.com>

On 5/9/06, joe user <signspointtoprobably at yahoo.com> wrote:
>
> Does this mean you have no more actual technical reasons to oppose this change, but are just stomping your foot and implying bad things about Winter?  Because there are people who agree with him, and I haven't seen any really compelling reasons to avoid this ten-line modification.
>
> Well, I shan't speak for Guido, but I haven't seen a compelling reason to
change the existing exception class, either. The exception *class* will
never explicit enough, it will never reflect all the specific details about
the error. You always need the actual error message to determine that. If
it's really necessary to be able to 'parse' an exception, adding attributes
to the instance to indicate what the problem seems to be is a more scalable
approach, IMHO, but I don't really see the need myself.

I've had many, many newbies come along complaining about the TypeError that
woudl become an ArgumentError, and never, ever, were they confused about the
fact that it was a TypeError. They were always confused about "expected
three, got four" when the functioncall clearly showed three arguments (it
was a methodcall, of course.) Why change the class? What other classes
should be changed? How fine-grained should it be? The effort, regarless of
how small it is, is in my opinion wasted. (As is all the effort in
discussing this, including this message :-)

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060509/2db3477b/attachment.html 

From tomerfiliba at gmail.com  Tue May  9 22:31:02 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Tue, 9 May 2006 22:31:02 +0200
Subject: [Python-3000] my take on "typeclasses"
Message-ID: <1d85506f0605091331u770ff33dj66ce3da18b4cd496@mail.gmail.com>

i was having lots of thoughts about types in general, and what they mean
in python, and i came to the conclusion they types are basically useless.
after all, "proper duck typing" is something like:

def myfunc(myarg):
    myarg.mymethod(1,2,3)

RATHER THAN

def myfunc(myarg):
    assert type(myarg) == mytype
    myarg.mymethod(1,2,3)

-----

sorry for spamming on RPyC here, but i feel i need to provide just some
background info on how it works: it gives you a proxy to a remote object, thus
doing x.y() or x+z, etc., invokes the correct methods of the remote object and
returns the result (or exception). this allows you to work with remote objects
just like they were local ones --

but object proxying doesnt work when you "assert type(x) == y" or
isinstance(x,y), as those functions test for properties of the PROXY, not the
remote object. so code like that break RPyC.

assuring type correctness is useless -- you just check the type and raise
an exception. the difference being instead of AttributeError you'll get a
TypeError. one runtime error instead of another... quite meaningless.
perhaps the latter is more descriptive, but if you think about it for a minute,
AttributeError is basically equivalent to TypeError.

and the very essence of types is quite meaningless in dynamic languages.
in compiled languages, they define how casting is done, what operations the
object supports, etc. etc., but in python, they all just narrow down
to "hasattr()",
i.e., "is the object addable?" == "hasattr(obj, '__add__')".

there are only two things types are good for:
* overloading ("generic functions"), i.e.,
if type(x) == int:
    dothis()
else:
    dothat()
* early error reporting -- can be quite useful to raise the exception as early
as possible

for those two features, i'd suggest an "isproto" mechanism, that checks if
the object supports a certain protocol:

iterable_protocol = ["__iter__"]
sequence_protocol = ["__getitem__", "__setitem__",
"__contains__", "__iter__"]
file_protocol = ["write", "read", "close", "fileno"]
sortable_protocol = ["__lt__", "__gt__", "__eq__"]

def f(somefile):
    assert isproto(somefile, file_protocol)
    f.write(...)

and isproto just checks the object has the requested attributes. can be as
simple as

def isproto(obj, attrs):
    for attr in attrs:
        if not hasattr(obj, attr):
            return False
    return True

and of course you don't need to remember all the attributes you'll ever
use --

class x(object):
    def f(self):
        pass

obj = x()
assert isproto(obj, dir(x))

or have isproto acces type objects as well

-------

i'm sure my idea has flaws, but i'm very much pro-changing the type system.
i'm not familiar with haskell, but if i understand Phillip's ideas right, they
woudl allow better object proxying, and i'm very +1 on that.

types are just an ancient relic, an implementation detail if you wish, that
was brought from static languages, but is not appropriate to dynamic
languages. static languages NEED types in order to produce machine
code, dynamic languages don't, so a different mechanism is needed here,
imho.


-tomer

From guido at python.org  Tue May  9 22:49:25 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 9 May 2006 13:49:25 -0700
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <20060509193940.79034.qmail@web38501.mail.mud.yahoo.com>
References: <20060509193940.79034.qmail@web38501.mail.mud.yahoo.com>
Message-ID: <ca471dc20605091349j39894decn5fc84ee2f5b45ae8@mail.gmail.com>

I'm not implying anything about Winter (whom I actually respect)
except that I don't see the merit of his proposal, and that I don't
see the value of more argument on such a small issue.

And why are you hiding behind an alias?

--Guido

On 5/9/06, joe user <signspointtoprobably at yahoo.com> wrote:
> Does this mean you have no more actual technical reasons to oppose this
> change, but are just stomping your foot and implying bad things about
> Winter? Because there are people who agree with him, and I haven't seen any
> really compelling reasons to avoid this ten-line modification.
>
> Seriously, are you just dodging this issue?
>
> >Can we just agree to disagree? Read the piece on python.org/dev about
> >knowing when to stop.
> >
> >On 5/8/06, Collin Winter <collinw at gmail.com> wrote:
> >> On 5/7/06, Guido van Rossum <guido at python.org> wrote:
> >> > On 5/7/06, Collin Winter <collinw at gmail.com> wrote:
> >> > > This -- more intuitive error messages -- is really what I'm after,
>  and
> >> > > while you may think of type of "def foo(a, b, c):..." as "a function
> >> > > with three required arguments", I'd wager that most Python
> >> > > programmers, if asked what type foo has, would say simply, "it's a
> >> > > function".
> >> >
> >> > Then introducing a new exception isn't going to make a difference.
> >>
> >> Sure it will: the name of the exception class is effectively part of
> >> the error message once the exception instance bubbles up to the user.
> >> "TypeError: foo() got an unexpected keyword argument 'bar'".
> >>
> >> Collin Winter
> >>
> >
> >
> >--
> >--Guido van Rossum (home page: http://www.python.org/~guido/)
>
>
>  ________________________________
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> countries) for 2?/min or less.
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>
>


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

From phd at mail2.phd.pp.ru  Tue May  9 22:57:48 2006
From: phd at mail2.phd.pp.ru (Oleg Broytmann)
Date: Wed, 10 May 2006 00:57:48 +0400
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <1d85506f0605091331u770ff33dj66ce3da18b4cd496@mail.gmail.com>
References: <1d85506f0605091331u770ff33dj66ce3da18b4cd496@mail.gmail.com>
Message-ID: <20060509205748.GA19619@phd.pp.ru>

On Tue, May 09, 2006 at 10:31:02PM +0200, tomer filiba wrote:
> i.e., "is the object addable?" == "hasattr(obj, '__add__')".

   Even this is meaningless: '1'+1. So duck typing is:

try:
   return a+b
except TypeError:
   return "Oops..."

> iterable_protocol = ["__iter__"]
> sequence_protocol = ["__getitem__", "__setitem__",
> "__contains__", "__iter__"]

   A read-only sequence could lack __setitem__().

> file_protocol = ["write", "read", "close", "fileno"]

   StringIO lacks fileno() so it is not a file-like object, is it?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From mcherm at mcherm.com  Tue May  9 23:03:18 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Tue, 09 May 2006 14:03:18 -0700
Subject: [Python-3000]  my take on "typeclasses"
Message-ID: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>

Talin writes:
> Lets start a new top-level thread to discuss this specific
> proposal.

tomer filiba writes:
> i'm sure my idea has flaws, but i'm very much pro-changing the type system.
       [...]
> types are just an ancient relic, an implementation detail if you wish, that
> was brought from static languages, but is not appropriate to dynamic
> languages. static languages NEED types in order to produce machine
> code, dynamic languages don't, so a different mechanism is needed here,
> imho.

I think the idea of creating a new language with some of the wonderful
syntax of Python along with the wonderful type system of Haskell sounds
GREAT! I would be very interested, and would like to join in the
discussion.

But I don't think it belongs in the Python-3000 discussion group. Can
this discussion be moved elsewhere? Python 3.0 is going to have types,
and they're going to look very similar to the types in Python 2.X --
a brand new language would be a separate project.

-- Michael Chermside


From oliphant.travis at ieee.org  Tue May  9 22:58:47 2006
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Tue, 09 May 2006 14:58:47 -0600
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <e3ga30$9sq$1@sea.gmane.org>
References: <loom.20060502T201105-105@post.gmane.org><e38g44$bfb$1@sea.gmane.org>	<44596963.8070200@canterbury.ac.nz>
	<e3ga30$9sq$1@sea.gmane.org>
Message-ID: <e3qvqa$k6m$1@sea.gmane.org>

Terry Reedy wrote:
> "Greg Ewing" <greg.ewing at canterbury.ac.nz> wrote in message 
> news:44596963.8070200 at canterbury.ac.nz...
>> Terry Reedy wrote:
>>
>>> -the ability to ignore platforn standards and give an app a unique look 
>>> and
>>> feel.  A start on this, for instance, is being able to give dialog boxes 
>>> a
>>> custom background instead of uniform gray or whatever.
> 
> I should note first that I have no particular expectation that PyGUI will 
> meet my wish list.
> 

I'm not an expert on any of this, but I like the idea of PyGUI, but I 
would prefer if it were based on lower-level interfaces.

I've liked the concept that enthought's enable toolkit introduced me to 
(and they have made several strides in this direction).   Just get a 
window-area from each platform's lowest-level tool and then draw your 
widgets to the screen directly.  Capture events using the platform's 
lowest-level interface as well.

Then you have a truly cross-platform toolkit written using Python itself 
with speed critical sections in C.  Naturally one could borrow from the 
toolkits already out there to do a lot of it.

I think people interested in this area should really check out 
Enthought's enable toolkit to see if there is anything of value there. 
I like the concept of low-level binding, but I don't know if they've 
actually achieved that.

I'm really not qualified to argue the points, but if there were a 
cross-platform toolkit that was not just a wrapper of a wrapper of a 
wrapper over some underlying toolkit, then that would be the toolkit I 
would choose.   The thing that bothers me most about all of Python's GUI 
toolkits is that they are almost always wrappers of wrappers of wrappers...

I suspect you could start by just interfacing with the 
"platform-default" toolkits MFC, Cocoa, Gnome, and KDE (using ctypes for 
example) and then using an approach similar to PyGUI to wrap them all up 
using standard calls.

I personally like the idea of a cross-platform default toolkit that is 
written with Python not just a wrapper of Tk or wxWindows.


-Travis Oliphant




From jimjjewett at gmail.com  Tue May  9 23:42:44 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 9 May 2006 17:42:44 -0400
Subject: [Python-3000] GUI -- an API, not a toolkit
Message-ID: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>

On 5/9/06, Ivan Krstic <krstic at fas.harvard.edu> wrote:
> Jim Jewett wrote:
> > By spitting out html and javascript, rather than draw/paint commands.

> I was afraid you were going to say that. I, for one, welcome our new
> AJAX overlords, but to want to task a general GUI toolkit with producing
> HTML and Javascript, running a HTTP server, and automagically dealing
> with all the server-side logic seems a bit like a really bad joke.

Exactly!

And hauling in a widget set larger than python so that my command line
programs could pop up windows with buttons with properly rounded
corners and arbitrary shading seems just as foolish.



    It is reasonable to have a pythonic UI API that says "create a dialog".

    Bill Janssen nominated Greg's PyGUI as a good candidate.


    Stop here.  This was almost the entire extent of the preference for PyGUI.



It is reasonable to ship with a default implementation of that API, in
case users or developers don't want to bother downloading a
better/fuller implementation.

Greg does provide one, for much of PyGUI.  He uses an underlying
cross-platform GUI to reduce his own maintenance nightmares.  If
someone else wanted to provide an alternative implementation using
native controls for MS Windows (or BeOS, for that matter), I doubt he
would object.  It might even make sense to use that replacement as the
default distribution on that platform.  Greg hasn't done this yet,
because it hasn't been worth his time.

Of course, no one has done that for any of the other frameworks
either, despite much greater manpower.  Switching from wxWidgets to Qt
isn't just a matter of installing the new library; you also have to
change huge portions of your own code to handle the different calling
conventions.

It is unreasonable to pretend that anything shipped with the standard
library could ever be complete and up-to-date for native
look-and-feel; python releases do not march in lockstep with OS
releases.

It is unreasonable to expect that Gnome or KDE partisans will suddenly
switch to whatever becomes the default.  It is not unreasonable to
expect them to write lightweight wrappers, so that users could replace
the default implementation with pyGTk or wax.

Replacing the full (and odd, for python code) Tkinter interface that
we have today would be a fairly large undertaking, so no one has. 
Replacing the basic UI API shouldn't be.  (So I'm inclined to wonder
if PyGUI is already too heavy.)

Applications using the Python UI API wouldn't get all the features
available from, say, wxWindows, but they would get some of the
benefits, such as a look and feel consistent with whichever particular
toolkit the *user* chose.

More importantly, the applications would continue to run even if the
user later switched to a different GUI provider.  Users could choose
to try out the latest GTk, or a retro-mac-classic scheme, or an
over-the-web AJAX scheme; the application would not need to care,
except to the extent that it relied on non-standard widget extensions.

Most importantly, the application programmer wouldn't need to care. 
Right now, if you want to create a python application with a GUI, you
need to learn python, plus the GUI framework, plus the python
bindings.

To just create a preference picker and an OK/Cancel dialog -- the
mental overhead really shouldn't be much worse than using a single
python module from the standard library.  (And yes, this rules out
using pretty much any existing framework as the API.)

-jJ

From talin at acm.org  Wed May 10 00:46:50 2006
From: talin at acm.org (Talin)
Date: Tue, 9 May 2006 22:46:50 +0000 (UTC)
Subject: [Python-3000] my take on "typeclasses"
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
Message-ID: <loom.20060509T234801-751@post.gmane.org>

Michael Chermside <mcherm <at> mcherm.com> writes:

> Talin writes:
> > Lets start a new top-level thread to discuss this specific
> > proposal.
> 
> tomer filiba writes:
> > i'm sure my idea has flaws, but i'm very much pro-changing the type system.
>        [...]
> > types are just an ancient relic, an implementation detail if you wish, that
> > was brought from static languages, but is not appropriate to dynamic
> > languages. static languages NEED types in order to produce machine
> > code, dynamic languages don't, so a different mechanism is needed here,
> > imho.
> 
> I think the idea of creating a new language with some of the wonderful
> syntax of Python along with the wonderful type system of Haskell sounds
> GREAT! I would be very interested, and would like to join in the
> discussion.
> 
> But I don't think it belongs in the Python-3000 discussion group. Can
> this discussion be moved elsewhere? Python 3.0 is going to have types,
> and they're going to look very similar to the types in Python 2.X --
> a brand new language would be a separate project.

Ordinarily I would agree with you on this point, and in fact I
wouldn't even bring it up at all, except for two data points:

1) The proposal to include generic function dispatch
   in Python 3000, based on explicit typing.

2) The proposal to remove all forms of type testing
   other than those based on isinstance() (in other words,
   removing callable, isSequence, isMapping, etc.)
   (I'm not including attribute testing here because its
   neither standardized nor systematic.)

The net effect of these proposals is to greatly strengthen
the capabilities of explicit typing, while seriously crippling
the use of duck typing. By putting a much greater emphasis on
explicit typing, we're effectively moving Python away from the
implcit "duck-typing" that we've known up to this point.

So essentially Python is *already* becoming a different
language, whether we like it or not.

I think that I agree with the gist of Tomer's point. I'm not
going to claim that types are useless, but I think we should
think about ways of dispatching other than types.

What would seem very 'Pythonic' to me would be a system
whereby objects can not only be dispatched on their
types but also their *capabilities*. Thus, instead
of asking the question "Is this a sequence?", we ask
"Can this be iterated?"

In such a model a "sequence type" would simply be a
set of capabilities that often occur together.

I think at the very least, we need a way a better
definition of a "capability", and a formalized way
to test for its presence. Whether or not that is
directly wired into the dispatch mechanism (which would
be cool) is another issue. Certainly attribute testing
is part of it, but there needs to be agreement on which
attributes to test.

-- Talin



From talin at acm.org  Wed May 10 00:53:48 2006
From: talin at acm.org (Talin)
Date: Tue, 9 May 2006 22:53:48 +0000 (UTC)
Subject: [Python-3000] my take on "typeclasses"
References: <1d85506f0605091331u770ff33dj66ce3da18b4cd496@mail.gmail.com>
	<20060509205748.GA19619@phd.pp.ru>
Message-ID: <loom.20060510T004736-98@post.gmane.org>

Oleg Broytmann <phd <at> oper.phd.pp.ru> writes:

> On Tue, May 09, 2006 at 10:31:02PM +0200, tomer filiba wrote:
> > i.e., "is the object addable?" == "hasattr(obj, '__add__')".
> 
>    Even this is meaningless: '1'+1. So duck typing is:

I don't think I agree with this interpretation. Someone earlier
gave the example of an instance in which callable() would return
the 'wrong' answer:

   def __call__( self ):
      throw "This is not callable"

My interpretation of this is that a function can claim all it
wants that its not callable, that doesn't make it so. It *is*
callable, it just happens to throw an exception as a result.

The resolution to this is to not think of duck typing as
being something to do with types, but instead having to
do with capabilities. An object with an __add__ method has
the *potential* to be added, and 99% of the time that's all
we really need to know.

Duck typing isn't about wanting a duck, its about wanting
an object that has waddling and quacking capabilities.

-- Talin



From janssen at parc.com  Wed May 10 01:03:25 2006
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 May 2006 16:03:25 PDT
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: Your message of "Tue, 09 May 2006 12:07:32 PDT."
	<fb6fbf560605091207p2418faf0k3b7a695aa9272756@mail.gmail.com> 
Message-ID: <06May9.160331pdt."58641"@synergy1.parc.xerox.com>

> By spitting out html and javascript, rather than draw/paint commands.

And perhaps SVG for the drawing/painting.

Bill

From baptiste13 at altern.org  Wed May 10 01:22:34 2006
From: baptiste13 at altern.org (Baptiste Carvello)
Date: Wed, 10 May 2006 01:22:34 +0200
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <20060509205748.GA19619@phd.pp.ru>
References: <1d85506f0605091331u770ff33dj66ce3da18b4cd496@mail.gmail.com>
	<20060509205748.GA19619@phd.pp.ru>
Message-ID: <e3r8jp$f84$1@sea.gmane.org>

Oleg Broytmann a ?crit :
> On Tue, May 09, 2006 at 10:31:02PM +0200, tomer filiba wrote:
> 
>>i.e., "is the object addable?" == "hasattr(obj, '__add__')".
> 
> 
>    Even this is meaningless: '1'+1. So duck typing is:
> 
> try:
>    return a+b
> except TypeError:
>    return "Oops..."
> 
> 
Well, while only the second example is true duck typing, the first one also is 
some sort of duck-typing, with a weaker promise:

"if it looks like a duck from half a mile away, then it *might* be a duck"

Sometimes, you just don't want to walk half a mile for nothing :)

Less metaphorically, the "just do it" test for an assumption can have 
side-effects. You might want some information on the status of the assumption 
*before* you can afford the side-effects. So you want a test with the following 
promise:
"every test that could be done now (without side-effects) has been tried, and 
the assumption has still not been proven false".
Of course, this does not prove the assumption true, but it provides a well 
defined and possibly useful piece of knowledge. False positives can still be 
caught later on by true duck typing.

Of course this is only useful if you really need the early warning. I can think 
of 2 use cases:

1) in interactive use, having the exception close to the code responsible for 
the problem avoids confusing the user. This is the case of using callable() on a 
candidate callback. This does not catch every problem, but still provides a 
better user experience in the common cases where it does. And if the test has no 
false negatives, it has *no cost* at all.

2) in numerical calculations, you might want to do as many tests as possible 
before attempting a time-costly operation.

Sorry for this "philosophical" post. I hope it helps clarify the current 
discussion about what is really duck typing.

Baptiste


From rasky at develer.com  Wed May 10 01:38:54 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Wed, 10 May 2006 01:38:54 +0200
Subject: [Python-3000] GUI -- an API, not a toolkit
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
Message-ID: <0a4801c673c1$bbb7dff0$53b02997@bagio>

Jim Jewett <jimjjewett at gmail.com> wrote:

> To just create a preference picker and an OK/Cancel dialog -- the
> mental overhead really shouldn't be much worse than using a single
> python module from the standard library.  (And yes, this rules out
> using pretty much any existing framework as the API.)


Does it?

>>> from qt import *
>>> app = QApplication([])
>>> QMessageBox.question(None, "Confirmation", "Are you sure you want to
exit?", QMessageBox.Yes, QMessageBox.No)
[ dialog popups ]
3
>>> QMessageBox.Yes, QMessageBox.No
(3, 4)

I don't agree with much of what you propose basically because I think it's
hopeless to create a wrapper API above all the toolkits. There are far too many
"details" which are different (just thinking of events, application event
loops, signals/slots, HW accelerated painting primitives, multithreading
dispatching). I dare anyone to develop such an API so that it's
production-ready (which is *not* a Yes/No dialog) within the Py3k time
constraint. I reckon that this is pratically unfeasable (and, say what, totally
useless).

My gut feeling is that we should either choose a good existing, tested binding
over a multi-years-developed-and-real-world-debugged toolkit, or we can just
drop the idea of distributing any GUI API with Python. Python's stdlib *is*
production ready, and shouldn't be cluttered with insufficient,
under-specified, limited APIs.

Giovanni Bajo


From jimjjewett at gmail.com  Wed May 10 02:44:33 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 9 May 2006 20:44:33 -0400
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <0a4801c673c1$bbb7dff0$53b02997@bagio>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
Message-ID: <fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>

On 5/9/06, Giovanni Bajo <rasky at develer.com> wrote:
> Jim Jewett <jimjjewett at gmail.com> wrote:

> > To just create a preference picker and an OK/Cancel dialog -- the
> > mental overhead really shouldn't be much worse than using a single
> > python module from the standard library.  (And yes, this rules out
> > using pretty much any existing framework as the API.)

> Does it?

> >>> from qt import *
> >>> app = QApplication([])
> >>> QMessageBox.question(None, "Confirmation", "Are you sure you want to
> exit?", QMessageBox.Yes, QMessageBox.No)
> [ dialog popups ]
> 3
> >>> QMessageBox.Yes, QMessageBox.No
> (3, 4)

You do realize that you just returned the integer 4, when you wanted
something False?  That is mental overhead.


> I don't agree with much of what you propose basically because I think it's
> hopeless to create a wrapper API above all the toolkits. There are far too many
> "details" which are different (just thinking of events, application event
> loops, signals/slots, HW accelerated painting primitives, multithreading
> dispatching).

So don't think about them.

Events (or slots, or signals) which are internal to the GUI do not
need to be exposed.
When it is needed, translating between from a signal to an event or an
event to a slot may not be the most graceful solution, but it will
work.

Why should the application writer have to specify hardware
acceleration?  If the wrapper library can't provide reasonable
defaults, then just don't use it.

-jJ

From solipsis at pitrou.net  Wed May 10 03:02:22 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 10 May 2006 03:02:22 +0200
Subject: [Python-3000] GUI events
In-Reply-To: <fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
Message-ID: <1147222942.5646.11.camel@fsol>


Le mardi 09 mai 2006 ? 20:44 -0400, Jim Jewett a ?crit :
> Events (or slots, or signals) which are internal to the GUI do not
> need to be exposed.
> When it is needed, translating between from a signal to an event or an
> event to a slot may not be the most graceful solution, but it will
> work.

Speaking of events, the .Net idiom for this seems quite nice. 
In short it looks like:

---
def my_on_clicked_button(possible_args):
    ...

button = gui.Button(...)
button.on_clicked += my_on_clicked_button
---

Of course in C# you have a lot of boilerplate (overly verbose type
declarations, etc.), but this is the idea.

Has anyone had any experience with this idiom? Are there any drawbacks?
It looks more elegant than inheritance and overriding methods to me.
(when I have to inherit a library-supplied class, I'm always worried
that I could override existing methods/attributes by mistake and trigger
unexpected behaviour. Even you are careful there is still the risk that
a later library version adds a property or method whose name clashes
with one of yours)

Regards

Antoine.



From greg.ewing at canterbury.ac.nz  Wed May 10 03:06:22 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 10 May 2006 13:06:22 +1200
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <06May9.093036pdt.58641@synergy1.parc.xerox.com>
References: <06May9.093036pdt.58641@synergy1.parc.xerox.com>
Message-ID: <44613C8E.9000503@canterbury.ac.nz>

Bill Janssen wrote:
> I also don't really see the point of the "standard
> application dialogs", as they are so easy to build yourself.

They can be very handy. Also, platforms may have
conventions about where to put the various buttons,
etc.

FWIW, PyGUI already has all the ones Talin mentioned
except the one with the text field, and I could add
that fairly easily.

> Styled text is another question mark.

One problem with styled text is deciding how far you
go with feature support. If you're not careful, you
can end up trying to embed an entire word processor
into the GUI library.

Another problem in a cross-platform environment is
how to represent styled text outside of the styled
text widget. Nowadays I suppose HTML is the obvious
way?

--
Greg

From talin at acm.org  Wed May 10 03:20:33 2006
From: talin at acm.org (Talin)
Date: Wed, 10 May 2006 01:20:33 +0000 (UTC)
Subject: [Python-3000] GUI -- an API, not a toolkit
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
Message-ID: <loom.20060510T031553-404@post.gmane.org>

Giovanni Bajo <rasky <at> develer.com> writes:

> I don't agree with much of what you propose basically because I think it's
> hopeless to create a wrapper API above all the toolkits. There are far too 
many
> "details" which are different (just thinking of events, application event
> loops, signals/slots, HW accelerated painting primitives, multithreading
> dispatching). I dare anyone to develop such an API so that it's
> production-ready (which is *not* a Yes/No dialog) within the Py3k time
> constraint. I reckon that this is pratically unfeasable (and, say what, 
totally
> useless).

Java did it, so it can't be all *that* hard :)

The main challenge is choosing the right level of abstraction.
You don't want to be creating code that does different things
on different platforms; You want to let the platform handle those
details for you. OK, so menus behave differently on Win32 vs.
OS X. So what? You shouldn't be handling individual mouse clicks
at that level anyway.

Similarly, it would be nightmarishly difficult to try and
re-create the color chooser dialog on OS X, so why bother? Just
use the one provided by the OS. (Unless you are using .Net,
in which case you probably *want* to replace the color dialog :)

-- Talin



From rasky at develer.com  Wed May 10 03:23:08 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Wed, 10 May 2006 03:23:08 +0200
Subject: [Python-3000] GUI -- an API, not a toolkit
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
Message-ID: <0aa201c673d0$4bf188b0$53b02997@bagio>

Jim Jewett <jimjjewett at gmail.com> wrote:

>>> To just create a preference picker and an OK/Cancel dialog -- the
>>> mental overhead really shouldn't be much worse than using a single
>>> python module from the standard library.  (And yes, this rules out
>>> using pretty much any existing framework as the API.)
>
>> Does it?
>
>>>>> from qt import *
>>>>> app = QApplication([])
>>>>> QMessageBox.question(None, "Confirmation", "Are you sure you want
>>>>> to
>> exit?", QMessageBox.Yes, QMessageBox.No)
>> [ dialog popups ]
>> 3
>>>>> QMessageBox.Yes, QMessageBox.No
>> (3, 4)
>
> You do realize that you just returned the integer 4, when you wanted
> something False?  That is mental overhead.


No, you're over-generalizing. What if I wanted the buttons Ok/Cancel instead?
Or "Abort"/"Retry"/"Cancel"? The mental overhead is having to remember
different APIs from the Yes/No case, if you're going to use a specialized
version returning just a boolean.

>> I don't agree with much of what you propose basically because I
>> think it's hopeless to create a wrapper API above all the toolkits.
>> There are far too many "details" which are different (just thinking
>> of events, application event loops, signals/slots, HW accelerated
>> painting primitives, multithreading dispatching).
>
> So don't think about them.
>
> Events (or slots, or signals) which are internal to the GUI do not
> need to be exposed.

??? Events, slots and signals are all public parts of a GUI API.

> When it is needed, translating between from a signal to an event or an
> event to a slot may not be the most graceful solution, but it will
> work.

No, it won't. Events and signals are pretty different concepts. If you're not
making a difference between them, you're generalizing too much and losing
power. Anyway, it's not *me* that it's saying so. I'm just an average
programmer which wasted far too many hours working with unreasonable, broken,
incomplete, over-generalized, over-simplified, slow GUI APIs. Look at the API
of Qt: it is a successful, production-ready toolkit for a reason.

> Why should the application writer have to specify hardware
> acceleration?  If the wrapper library can't provide reasonable
> defaults, then just don't use it.


I was just trying to say that designing something like QPainter, with a common
API which totally abstracts from the OS details but still allows hardware
acceleration on most platforms (GDI+ on Windows, for instance) is very very
complex (and it went through several revisions and refinements). I don't expect
anyone to come out with a better API on their first try. Of course, they could
just copy it. But then, why don't adopt it?

Giovanni Bajo


From solipsis at pitrou.net  Wed May 10 03:30:57 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 10 May 2006 03:30:57 +0200
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <0aa201c673d0$4bf188b0$53b02997@bagio>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
	<0aa201c673d0$4bf188b0$53b02997@bagio>
Message-ID: <1147224657.5646.18.camel@fsol>


Le mercredi 10 mai 2006 ? 03:23 +0200, Giovanni Bajo a ?crit :
> No, you're over-generalizing. What if I wanted the buttons Ok/Cancel instead?
> Or "Abort"/"Retry"/"Cancel"? The mental overhead is having to remember
> different APIs from the Yes/No case, if you're going to use a specialized
> version returning just a boolean.

But magic numbers are ugly, even if they are hidden behind an
enumeration. If you try to print them for debugging, it will only show
the numeric values, which is hardly intuitive. GUI APIs generally define
dozens or hundreds of such numeric constants which clutter their
namespaces (ever tried "dir(wx)" ? ;-)).

IIRC the PyGUI solution is simple and elegant, i.e. it uses a string.

if answer == 'yes':
    ....
elif answer == 'cancel':
    ....

(of course you shouldn't internationalize that one ;-))



From greg.ewing at canterbury.ac.nz  Wed May 10 03:31:56 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 10 May 2006 13:31:56 +1200
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <e3qvqa$k6m$1@sea.gmane.org>
References: <loom.20060502T201105-105@post.gmane.org>
	<e38g44$bfb$1@sea.gmane.org> <44596963.8070200@canterbury.ac.nz>
	<e3ga30$9sq$1@sea.gmane.org> <e3qvqa$k6m$1@sea.gmane.org>
Message-ID: <4461428C.60803@canterbury.ac.nz>

Travis E. Oliphant wrote:
> Just get a 
> window-area from each platform's lowest-level tool and then draw your 
> widgets to the screen directly.

But then you have something that looks totally non-native
on all platforms. While it may be useful to have such a thing,
it's not what PyGUI is designed to be.

> The thing that bothers me most about all of Python's GUI 
> toolkits is that they are almost always wrappers of wrappers of wrappers...

And I'm trying to minimise this by building PyGUI as directly
as possible on what the platform already provides. But not
at such a low level that native appearance and behaviour
is lost.

> I suspect you could start by just interfacing with the 
> "platform-default" toolkits MFC, Cocoa, Gnome, and KDE (using ctypes for 
> example) and then using an approach similar to PyGUI to wrap them all up 
> using standard calls.

Um... how would that be different from PyGUI itself?

Confused,
Greg

From rasky at develer.com  Wed May 10 03:37:25 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Wed, 10 May 2006 03:37:25 +0200
Subject: [Python-3000] GUI -- an API, not a toolkit
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com><0a4801c673c1$bbb7dff0$53b02997@bagio>
	<loom.20060510T031553-404@post.gmane.org>
Message-ID: <0ab601c673d2$4a25de80$53b02997@bagio>

Talin <talin at acm.org> wrote:

>> I don't agree with much of what you propose basically because I
>> think it's hopeless to create a wrapper API above all the toolkits.
>> There are far too many "details" which are different (just thinking
>> of events, application event loops, signals/slots, HW accelerated
>> painting primitives, multithreading dispatching). I dare anyone to
>> develop such an API so that it's production-ready (which is *not* a
>> Yes/No dialog) within the Py3k time constraint. I reckon that this
>> is pratically unfeasable (and, say what, totally useless).
>
> Java did it, so it can't be all *that* hard :)

Sorry, I don't know anything about Java. But didn't they take a couple of
iterations (= several years) before getting to the right point? I saw late Java
applications looking native enough, but I remember the first ones with that
horrible non-native GUI (SWING maybe?), and I remember screams of Javas
co-workers when trying to do something serious with it.

But, if Java *really* did it, let's *copy* it. My point is exactly that: Qt
*did* it, so let's use it. wxWidgets does *exactly* what you want: it's a
common abstraction over different native toolkit libraries. wxPython is very
widespread and accepted by the community. Why oh why redesigning something from
scratch.

> The main challenge is choosing the right level of abstraction.
> You don't want to be creating code that does different things
> on different platforms; You want to let the platform handle those
> details for you. OK, so menus behave differently on Win32 vs.
> OS X. So what? You shouldn't be handling individual mouse clicks
> at that level anyway.
>
> Similarly, it would be nightmarishly difficult to try and
> re-create the color chooser dialog on OS X, so why bother? Just
> use the one provided by the OS. (Unless you are using .Net,
> in which case you probably *want* to replace the color dialog :)


You probably know that Qt does exactly what you say (use native menus on Mac OS
X, and native color picker on all operating system), and it's still thousands
and thousands of lines of well-designed code.

Another issue (which by itself is going to get headaches to any GUI designed)
is how many native widgets can be used and how many needs to be redone. This is
a very delicate issue: in my experience, the solution of wxWidgets of going
totally native (that is, being just a wrapper around native widgets) is
unfortunate, because it coerces the programmer to use the lower common subset
of features across all platforms, to be consistent. This is why wxWidgets
reference manual is filled with "this works on Windows only, this works on Mac
only, this works with GTK only". OTOH, Qt decided to redo all the widgets from
scratch (but not the common dialogs of course), and then even reproduce the
native look & feel from scratch (hell, it even follow the user's custom theme
selection under XP). It's the hard, longest way, but it's the one that pays
most. Show me a combo-box with selects among items with both text and a bitmap,
done with wxPython, on all platforms.

Giovanni Bajo


From janssen at parc.com  Wed May 10 03:48:58 2006
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 May 2006 18:48:58 PDT
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: Your message of "Tue, 09 May 2006 09:46:04 PDT."
	<5.1.1.6.0.20060509124122.01e6c818@mail.telecommunity.com> 
Message-ID: <06May9.184902pdt."58641"@synergy1.parc.xerox.com>

> Currently in Python for a third party to add a mixin, they would 
> have to hack the class's __bases__, which I am not suggesting here at all.

I'm not suggesting it either.  Here's what I meant:

Consider the type "sequential_ordering", which has methods

	 len() => INTEGER
	 iter() => ITERABLE

Now let's say that you've got a type of your own, called "mytype", which defines

	 nitems() => INTEGER
	 iter() => ITERABLE

Using mixins, you'd do something like:

   class adapted_mytype (sequential_ordering, mytype):
	 def len(self):
	     return self.nitems()

You can now use "adapted_mytype", which respects both the
"sequential_ordering" protocol and the "mytype" protocol.  And a user
can use isinstance to test for that, avoiding "duck typing".

Bill

From janssen at parc.com  Wed May 10 03:53:27 2006
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 May 2006 18:53:27 PDT
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: Your message of "Tue, 09 May 2006 13:04:38 PDT."
	<4460F5D6.1040803@fas.harvard.edu> 
Message-ID: <06May9.185337pdt."58641"@synergy1.parc.xerox.com>

> to want to task a general GUI toolkit with producing
> HTML and Javascript, running a HTTP server, and automagically dealing
> with all the server-side logic seems a bit like a really bad joke.

You've never looked at X11 under the covers (it looks like Mac OS X's
window system is very similar).

Bill

From rasky at develer.com  Wed May 10 03:58:43 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Wed, 10 May 2006 03:58:43 +0200
Subject: [Python-3000] GUI -- an API, not a toolkit
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com><0a4801c673c1$bbb7dff0$53b02997@bagio><fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com><0aa201c673d0$4bf188b0$53b02997@bagio>
	<1147224657.5646.18.camel@fsol>
Message-ID: <0b4a01c673d5$4401e140$53b02997@bagio>

Antoine Pitrou <solipsis at pitrou.net> wrote:

>> No, you're over-generalizing. What if I wanted the buttons Ok/Cancel
>> instead? Or "Abort"/"Retry"/"Cancel"? The mental overhead is having
>> to remember different APIs from the Yes/No case, if you're going to
>> use a specialized version returning just a boolean.
>
> But magic numbers are ugly, even if they are hidden behind an
> enumeration.

You're changing the subject of the discussion. It was said existing solutions
for Python GUI toolkits required too much overhead to display a simple yes/no
messagebox. I demonstrated this is false.

I wasn't debating that PyQt has a Pythonic design. It is *by design* a wrapper
of Qt meant to be as similar as possible to the original C++ Qt library (in
fact, it doesn't have a formal documentation: I use the Qt C++ documentation -- 
which is btw award-winning as best software documentation -- and it works for
PyQt too).

> If you try to print them for debugging, it will only show
> the numeric values, which is hardly intuitive. GUI APIs generally
> define dozens or hundreds of such numeric constants which clutter
> their
> namespaces (ever tried "dir(wx)" ? ;-)).
>
> IIRC the PyGUI solution is simple and elegant, i.e. it uses a string.
>
> if answer == 'yes':
>     ....
> elif answer == 'cancel':
>     ....
>
> (of course you shouldn't internationalize that one ;-))

These are small-scale details I really don't think they are very important.
OTOH it would be far too easy to provide a simple wrapper to QMessageBox so to
expose a similar API. The problem is not here, there's more to GUI design. How
simple is it to do a new widget? Is it possible to inherit existing components
in easy way and to create new reusable components? Is it possible to connect
components of the GUI without them depending on each other in any way?

Say I need a pushbutton, with toggle state, which contains a embossed rectangle
which is filled of red when the button is pressed and filled of green when the
button is raised. Say I need a listbox which displays items as text with small
icons attached, in which the selection follows some custom rules (click: toggle
item selection, double-click: deselect all, select double-clicked element). Say
a need a table view where the first row is made of non-selectable images of
square size (so that if the user enlarges the first row, also the columns
automatically adjust to keep the images square), and the other rows contain
toggle buttons with custom text (and a custom yes/no icon). Can I do that with
the minimal code I expect to write (that is, only write code for the
differences against the default behaviour, and inherit everything else)?

Giovanni Bajo


From pje at telecommunity.com  Wed May 10 04:17:32 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 09 May 2006 22:17:32 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <06May9.184902pdt."58641"@synergy1.parc.xerox.com>
References: <Your message of "Tue, 09 May 2006 09:46:04 PDT."
	<5.1.1.6.0.20060509124122.01e6c818@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060509221251.01e649f0@mail.telecommunity.com>

At 06:48 PM 5/9/2006 -0700, Bill Janssen wrote:
>Using mixins, you'd do something like:
>
>    class adapted_mytype (sequential_ordering, mytype):
>         def len(self):
>              return self.nitems()
>
>You can now use "adapted_mytype", which respects both the
>"sequential_ordering" protocol and the "mytype" protocol.  And a user
>can use isinstance to test for that, avoiding "duck typing".

And as I pointed out already, this doesn't allow a third party to use one 
library's types in the context of another without monkeypatching.

If I understand your proposal correctly, this approach doesn't do anything 
beyond what Java does, and is inferior to already-available adaptation and 
interface systems for today's Python.


From janssen at parc.com  Wed May 10 04:43:48 2006
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 May 2006 19:43:48 PDT
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: Your message of "Tue, 09 May 2006 18:06:22 PDT."
	<44613C8E.9000503@canterbury.ac.nz> 
Message-ID: <06May9.194352pdt."58641"@synergy1.parc.xerox.com>

> One problem with styled text is deciding how far you
> go with feature support. If you're not careful, you
> can end up trying to embed an entire word processor
> into the GUI library.

Yes.

> Nowadays I suppose HTML is the obvious way?

It's certainly the wxWidgets, AJAX, and Java/Swing way.

Bill

From greg.ewing at canterbury.ac.nz  Wed May 10 07:45:09 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 10 May 2006 17:45:09 +1200
Subject: [Python-3000] GUI events
In-Reply-To: <1147222942.5646.11.camel@fsol>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
	<1147222942.5646.11.camel@fsol>
Message-ID: <44617DE5.5070104@canterbury.ac.nz>

Antoine Pitrou wrote:

> button = gui.Button(...)
> button.on_clicked += my_on_clicked_button

> Has anyone had any experience with this idiom? Are there any drawbacks?
> It looks more elegant than inheritance and overriding methods to me.

PyGUI currently has a form of this, except that you
only get to plug in one handler at a time. This is
enough to avoid the need for subclassing in many
cases, though.

I could support multiple handlers, but it would
make things substantially more complicated, and I'm
not convinced it's worth it. I rarely find the need
to install multiple independent handlers for an
event. Often I want to *override* a handler and
gain complete control, and then I find that
multiple-handler systems (e.g. gtk signals) tend
to hinder more than they help.

> (when I have to inherit a library-supplied class, I'm always worried
> that I could override existing methods/attributes by mistake

PyGUI uses names starting with underscores for all
its internal attribute names. I could use an even
stricter convention for internal names if people
thought it would be of benefit. Many of PyGUI's
classes are designed to be used by inheritance
(e.g. Window, View).

--
Greg

From talin at acm.org  Wed May 10 07:49:46 2006
From: talin at acm.org (Talin)
Date: Tue, 09 May 2006 22:49:46 -0700
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <0ab601c673d2$4a25de80$53b02997@bagio>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com><0a4801c673c1$bbb7dff0$53b02997@bagio>
	<loom.20060510T031553-404@post.gmane.org>
	<0ab601c673d2$4a25de80$53b02997@bagio>
Message-ID: <44617EFA.9020109@acm.org>

Giovanni Bajo wrote:

> But, if Java *really* did it, let's *copy* it. My point is exactly that: Qt
> *did* it, so let's use it. wxWidgets does *exactly* what you want: it's a
> common abstraction over different native toolkit libraries. wxPython is very
> widespread and accepted by the community. Why oh why redesigning something from
> scratch.

Qt, Java Swing, and .Net Windows.Forms are all examples of what I would 
consider "good" API designs. All three of them are powerful, 
comprehensive, and have relatively clean APIs. I would be perfectly 
satisfied to have the equivalent of any one of them in the Python space.

Given a choice, I would probably choose Windows.Forms as a model, mainly 
because it's the newest (and smallest) of the three, and seems to have 
taken some lessons from the design of the others. However, any of them 
would be a good starting point.

Which is not to say that we would need a system that has every feature 
that those systems support. As much as I love drawing with PathGradient, 
I don't expect to be able to do it cross-platform.
	
(Just so you know where I am coming from - I think I've used almost two 
dozen different UI frameworks over the years, not counting the half 
dozen or so I've created for different employers, going all the way back 
to the days of the Amiga. [Anyone remember "Gadtools"? Or the Commodore 
Installer?])

-- Talin

From greg.ewing at canterbury.ac.nz  Wed May 10 07:52:14 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 10 May 2006 17:52:14 +1200
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <0aa201c673d0$4bf188b0$53b02997@bagio>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
	<0aa201c673d0$4bf188b0$53b02997@bagio>
Message-ID: <44617F8E.2050803@canterbury.ac.nz>

Giovanni Bajo wrote:

> No, you're over-generalizing. What if I wanted the buttons Ok/Cancel instead?
> Or "Abort"/"Retry"/"Cancel"? The mental overhead is having to remember
> different APIs from the Yes/No case, if you're going to use a specialized
> version returning just a boolean.

In PyGUI I've tried to get some consistency here by
returning 1 or 0 for Yes-No dialogs (so you can
use it as a boolean if you want) and 1, 0, -1 for
three buttons (Yes, No, Cancel).

--
Greg

From greg.ewing at canterbury.ac.nz  Wed May 10 08:25:55 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 10 May 2006 18:25:55 +1200
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <44617EFA.9020109@acm.org>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<loom.20060510T031553-404@post.gmane.org>
	<0ab601c673d2$4a25de80$53b02997@bagio> <44617EFA.9020109@acm.org>
Message-ID: <44618773.7070708@canterbury.ac.nz>

Talin wrote:

> Qt, Java Swing, and .Net Windows.Forms are all examples of what I would 
> consider "good" API designs. All three of them are powerful, 
> comprehensive, and have relatively clean APIs. I would be perfectly 
> satisfied to have the equivalent of any one of them in the Python space.

But none of them have been designed with Python in mind.

In my experience, from a Python perspective, most GUI toolkit
APIs are needlessly complicated due to deficiencies in the
underlying language, such as lack of keyword arguments, or
properties, or introspection, or duck typing, etc. By standing
back and re-thinking the design Pythonically, many things can
be made much simpler.

> (Just so you know where I am coming from - I think I've used almost two 
> dozen different UI frameworks over the years, not counting the half 
> dozen or so I've created for different employers

I've been messing with GUI toolkits for quite a number of
years too, both using and writing them.

People have been asking "Why not copy an existing design?"
Well, I *have* been -- just not any single one. PyGUI is a
distillation of all that I've found to be good in my GUI
experience, plus some ideas of my own, and infused with
a good dose of Pythonicity.

--
Greg

From janssen at parc.com  Wed May 10 08:25:18 2006
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 May 2006 23:25:18 PDT
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: Your message of "Tue, 09 May 2006 19:17:32 PDT."
	<5.1.1.6.0.20060509221251.01e649f0@mail.telecommunity.com> 
Message-ID: <06May9.232523pdt."58641"@synergy1.parc.xerox.com>

> If I understand your proposal correctly, this approach doesn't do anything 
> beyond what Java does, and is inferior to already-available adaptation and 
> interface systems for today's Python.

Inferior is in the eye of the beholder, I suppose.  This is what
Python 2.x already provides.

> this approach doesn't do anything beyond what Java does

Actually, it does.  It lets you inherit behavior, as well as interfaces.

Bill


From talin at acm.org  Wed May 10 08:46:31 2006
From: talin at acm.org (Talin)
Date: Tue, 09 May 2006 23:46:31 -0700
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <44618773.7070708@canterbury.ac.nz>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>	<0a4801c673c1$bbb7dff0$53b02997@bagio>	<loom.20060510T031553-404@post.gmane.org>	<0ab601c673d2$4a25de80$53b02997@bagio>
	<44617EFA.9020109@acm.org> <44618773.7070708@canterbury.ac.nz>
Message-ID: <44618C47.1070709@acm.org>

Greg Ewing wrote:

>>Qt, Java Swing, and .Net Windows.Forms are all examples of what I would 
>>consider "good" API designs. All three of them are powerful, 
>>comprehensive, and have relatively clean APIs. I would be perfectly 
>>satisfied to have the equivalent of any one of them in the Python space.
> 
> 
> But none of them have been designed with Python in mind.
> 
> In my experience, from a Python perspective, most GUI toolkit
> APIs are needlessly complicated due to deficiencies in the
> underlying language, such as lack of keyword arguments, or
> properties, or introspection, or duck typing, etc. By standing
> back and re-thinking the design Pythonically, many things can
> be made much simpler.

Sorry, I meant to say that I wanted the feature set of Windows.Forms or 
Swing; I didn't mean to imply that the API should be an exact copy.

My bottom line is this: I like the general idea of a lightweight, 
Pythonic UI library. What I have a hard time agreeing with is the 
specific design goals that you've proposed. Minimalism is good, but 
PyGUI, at least as I understand it, takes it to excess IMHO.

If it weren't for the fact that I suspect that you and I would never 
come to agreement on architectural decisions, I would probably be quite 
excited about your project :)

You said, at one point, that one of your major motivations was that you 
were writing this for yourself. There's nothing wrong with that. 
However, I want to tell you what happened to me:

1987, I was just starting to work on Music-X (which eventually went on 
too become one of the most popular Midi editing programs on the Amiga.) 
I hung out at the local music store, pestering the staff, so that I 
could learn everything I could about samplers, sequencers, controllers, 
and all that fun stuff. I told them all about my plans, listened to 
their feedback, got lots of great ideas.

I told them that I was primarily writing this for myself, and that even 
though it was going to be sold commercially, the feature set would be 
primarily the features that I would need - which provoked a very strong 
reaction: "No you don't." Writing for myself was fine for a hobby 
project, but if I wanted to be professional, I needed to think of my 
customers first, and myself second.

Which is not to say that I completely abdicated the role of designer - 
it was still my duty and my right to be the judge of what features 
should go in and what shouldn't. But if those judgements aren't informed 
by the needs of the people out there who would be using my work, then 
there's no justification for them to take me seriously.

-- Talin

From talin at acm.org  Wed May 10 09:00:46 2006
From: talin at acm.org (Talin)
Date: Wed, 10 May 2006 00:00:46 -0700
Subject: [Python-3000] GUI events
In-Reply-To: <44617DE5.5070104@canterbury.ac.nz>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>	<0a4801c673c1$bbb7dff0$53b02997@bagio>	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>	<1147222942.5646.11.camel@fsol>
	<44617DE5.5070104@canterbury.ac.nz>
Message-ID: <44618F9E.5010303@acm.org>


Greg Ewing wrote:
> Antoine Pitrou wrote:
> 
> 
>>button = gui.Button(...)
>>button.on_clicked += my_on_clicked_button
> 
> 
>>Has anyone had any experience with this idiom? Are there any drawbacks?
>>It looks more elegant than inheritance and overriding methods to me.
> 
> 
> PyGUI currently has a form of this, except that you
> only get to plug in one handler at a time. This is
> enough to avoid the need for subclassing in many
> cases, though.
> 
> I could support multiple handlers, but it would
> make things substantially more complicated, and I'm
> not convinced it's worth it. I rarely find the need
> to install multiple independent handlers for an
> event. Often I want to *override* a handler and
> gain complete control, and then I find that
> multiple-handler systems (e.g. gtk signals) tend
> to hinder more than they help.

I use the .Net system quite a bit at work, so I'm familiar with the 
various use cases. It is true that most of the time, messages are sent 
to a single target.

The most common use cases for multiple recievers, in my experience are:

1) Implementation of the Observer design pattern - that is, you have 
multiple views of a single model. (Now, its true that the event system 
used for view update notifications doesn't *have* to be the same one as 
is used for dispatching events from the UI, but its nice if there's a 
commonality between them.)

2) Message filtering via chained handlers. This of course requires that 
the handler have the ability to modify the message before its passed to 
the next handler. This can allow you to do things like add drag and drop 
support to a control that doesn't normally handle such things, or to add 
special types of tooltips. In the current system I'm working with, I use 
it for visual animation effects.

-- Talin

From ronaldoussoren at mac.com  Wed May 10 11:44:17 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 10 May 2006 11:44:17 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <06May9.232523pdt.58641@synergy1.parc.xerox.com>
References: <06May9.232523pdt.58641@synergy1.parc.xerox.com>
Message-ID: <14251043.1147254257608.JavaMail.ronaldoussoren@mac.com>

 
On Wednesday, May 10, 2006, at 08:26AM, Bill Janssen <janssen at parc.com> wrote:

>> If I understand your proposal correctly, this approach doesn't do anything 
>> beyond what Java does, and is inferior to already-available adaptation and 
>> interface systems for today's Python.
>
>Inferior is in the eye of the beholder, I suppose.  This is what
>Python 2.x already provides.
>
>> this approach doesn't do anything beyond what Java does
>
>Actually, it does.  It lets you inherit behavior, as well as interfaces.

It only lets you inherit behaviour to new subclasses, as philip already noted you cannot add functionality to already existing classes. Both generic functions and adaptation systems like zope.interfaces allow you to state that an existing class implements one of your own interfaces without changes to the original class.

Ronald


From rasky at develer.com  Wed May 10 11:51:56 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Wed, 10 May 2006 11:51:56 +0200
Subject: [Python-3000] GUI -- an API, not a toolkit
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com><0a4801c673c1$bbb7dff0$53b02997@bagio><fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com><0aa201c673d0$4bf188b0$53b02997@bagio>
	<44617F8E.2050803@canterbury.ac.nz>
Message-ID: <0ca601c67417$5fbb5460$53b02997@bagio>

>> [Antoine Pitrou]
>> But magic numbers are ugly, even if they are hidden behind an
>> enumeration. If you try to print them for debugging, it will only show
>> the numeric values, which is hardly intuitive.
>> [...]

>> [Giovanni Bajo]
>> No, you're over-generalizing. What if I wanted the buttons Ok/Cancel
>> instead? Or "Abort"/"Retry"/"Cancel"? The mental overhead is having
>> to remember different APIs from the Yes/No case, if you're going to
>> use a specialized version returning just a boolean.

> [Greg Erwing]
> In PyGUI I've tried to get some consistency here by
> returning 1 or 0 for Yes-No dialogs (so you can
> use it as a boolean if you want) and 1, 0, -1 for
> three buttons (Yes, No, Cancel).

Then, I'd like to have a name for 1,0,-1 instead of using the bare numbers (in
case there are 4 buttons...). So, we're back to what Qt does: you're using
magic numbers too. I don't think there's a way out.

Giovanni Bajo


From Ben.Young at risk.sungard.com  Wed May 10 12:21:09 2006
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Wed, 10 May 2006 11:21:09 +0100
Subject: [Python-3000] Fw:  typeclasses, duck-typing
Message-ID: <OFF8DE7391.64F739A4-ON8025716A.0038D205-8025716A.0038DE51@risk.sungard.com>

python-3000-bounces+python=theyoungfamily.co.uk at python.org wrote on 
09/05/2006 18:25:29:

> On Tuesday 09 May 2006 13:10, Antoine Pitrou wrote:
>  > Interestingly, there was a GNU addition to C++ named "signatures" 
which
>  > achieved roughly the same thing: some kind of compile-time 
duck-typing.
>  >
>  > http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112
> 
> I remember that, thinking it was really kind of cool, and wanting toplay 
with 
> it.  Never had time to do so.
> 
>  > Apparently it has been removed in gcc 3 or 4.
> 
> That's right.  That's when I became glad I hadn't spent time writingcode 
that 
> relied on that feature.  :-)
> 

Have you taken a look at ConceptGCC? (
http://www.osl.iu.edu/~dgregor/ConceptGCC/)

It's basically a first cut at implementing the Concepts which will be 
availiable in the next version of C++. They basically provide full compile 
time "duck typing" as well as adaptation for types that don't exactly fit 
the concept. (e.g if the type doesn't have a length method, here's how you 
provide it.

It's a very powerfull idea, and probably well worth looking at for 
inspiration.

(For further details search for Concepts in the paper index at 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1969.html)

Cheers,
Ben

>   -Fred
> 
> -- 
> Fred L. Drake, Jr.   <fdrake at acm.org>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.
> org/mailman/options/python-3000/python%40theyoungfamily.co.uk
> 


From rasky at develer.com  Wed May 10 12:24:22 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Wed, 10 May 2006 12:24:22 +0200
Subject: [Python-3000] GUI events
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com><0a4801c673c1$bbb7dff0$53b02997@bagio><fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com><1147222942.5646.11.camel@fsol>
	<44617DE5.5070104@canterbury.ac.nz>
Message-ID: <0d0001c6741b$e7b6e560$53b02997@bagio>

Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> PyGUI currently has a form of this, except that you
> only get to plug in one handler at a time. This is
> enough to avoid the need for subclassing in many
> cases, though.
>
> I could support multiple handlers, but it would
> make things substantially more complicated, and I'm
> not convinced it's worth it. I rarely find the need
> to install multiple independent handlers for an
> event. Often I want to *override* a handler and
> gain complete control,

I beg to disagree. Installing multiple handlers on signals is a very crucial
feature in my mind. For instance, without it it's almost impossible to have a
really feature-rich designer tool which produce live dialogs (like Qt's
Designer does).

And how do you enable two controls when a checkbox is pressed? You're forced to
write your own little function which calls the enable function? That's wasted
code IMO.

> and then I find that
> multiple-handler systems (e.g. gtk signals) tend
> to hinder more than they help.

Is there a production-ready GUI toolkit that *doesn't* have multiple handlers?


Giovanni Bajo


From ronaldoussoren at mac.com  Wed May 10 13:18:47 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 10 May 2006 13:18:47 +0200
Subject: [Python-3000] GUI events
In-Reply-To: <0d0001c6741b$e7b6e560$53b02997@bagio>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
	<1147222942.5646.11.camel@fsol> <44617DE5.5070104@canterbury.ac.nz>
	<0d0001c6741b$e7b6e560$53b02997@bagio>
Message-ID: <13007598.1147259927606.JavaMail.ronaldoussoren@mac.com>

 
On Wednesday, May 10, 2006, at 12:24PM, Giovanni Bajo <rasky at develer.com> wrote:

>
>> and then I find that
>> multiple-handler systems (e.g. gtk signals) tend
>> to hinder more than they help.
>
>Is there a production-ready GUI toolkit that *doesn't* have multiple handlers?

AFAIK Cocoa doesn't have multiple handlers. It does have cocoa bindings though, which allows you to do a lot of the things you mentioned without actually writing code. You can basically bind the value of a widget to a value of your model and updates on one side propagate to the other side.

This is a very convenient way to build applications, but would require some changes to CPython to work as seemlessly at it does in ObjC. PyObjC does support bindings, but cannot give full support for this with native python datastructures because there is no way to intercept all updates of list() and dict() instances.

Ronald

P.S. http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/CocoaBindings.html

From ncoghlan at gmail.com  Wed May 10 14:08:30 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 10 May 2006 22:08:30 +1000
Subject: [Python-3000] Changing function-related TypeErrors
In-Reply-To: <20060509193940.79034.qmail@web38501.mail.mud.yahoo.com>
References: <20060509193940.79034.qmail@web38501.mail.mud.yahoo.com>
Message-ID: <4461D7BE.9000706@gmail.com>

joe user wrote:
> Does this mean you have no more actual technical reasons to oppose this
> change, but are just stomping your foot and implying bad things about
> Winter?  Because there are people who agree with him, and I haven't seen
> any really compelling reasons to avoid this ten-line modification.

When the reasons for and against something are equally weak, the status quo 
has to win by default. Anything else leads to change for change's sake (for 
example, compare the accepted PEP 352 to its far more ambitious predecessor 
PEP 348).

I've been on both sides of this situation (being for or against various 
changes), and 'status quo wins a stalemate' is the only way to avoid endless 
subjective arguments. I believe Guido was merely pointing out that this 
discussion had already reached that point :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Wed May 10 14:15:30 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 10 May 2006 22:15:30 +1000
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <e3r8jp$f84$1@sea.gmane.org>
References: <1d85506f0605091331u770ff33dj66ce3da18b4cd496@mail.gmail.com>	<20060509205748.GA19619@phd.pp.ru>
	<e3r8jp$f84$1@sea.gmane.org>
Message-ID: <4461D962.5010306@gmail.com>

Baptiste Carvello wrote:
> "if it looks like a duck from half a mile away, then it *might* be a duck"
> 
> Sometimes, you just don't want to walk half a mile for nothing :)

That's beautiful. Now we just need somewhere to put a QOTW for the Py3k list ;)

> Sorry for this "philosophical" post. I hope it helps clarify the current 
> discussion about what is really duck typing.

It mixed in a bit of the difference between EAFP and LBYL, too. It was one of 
the better descriptions I've seen, though :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From birchb at tpg.com.au  Wed May 10 15:34:31 2006
From: birchb at tpg.com.au (Bill Birch)
Date: Wed, 10 May 2006 23:34:31 +1000
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <loom.20060509T234801-751@post.gmane.org>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
Message-ID: <200605102334.31944.birchb@tpg.com.au>

On Wed, 10 May 2006 08:46 am, Talin wrote:
> Michael Chermside <mcherm <at> mcherm.com> writes:
> > Talin writes:
> > > Lets start a new top-level thread to discuss this specific
> > > proposal.
> >
> > tomer filiba writes:
> > > i'm sure my idea has flaws, but i'm very much pro-changing the type
> > > system.
> >
> >        [...]
> >
> > > types are just an ancient relic, an implementation detail if you wish,
> > > that was brought from static languages, but is not appropriate to
> > > dynamic languages. static languages NEED types in order to produce
> > > machine code, dynamic languages don't, so a different mechanism is
> > > needed here, imho.
> >
> > I think the idea of creating a new language with some of the wonderful
> > syntax of Python along with the wonderful type system of Haskell sounds
> > GREAT! I would be very interested, and would like to join in the
> > discussion.
> >
> > But I don't think it belongs in the Python-3000 discussion group. Can
> > this discussion be moved elsewhere? Python 3.0 is going to have types,
> > and they're going to look very similar to the types in Python 2.X --
> > a brand new language would be a separate project.
>
> Ordinarily I would agree with you on this point, and in fact I
> wouldn't even bring it up at all, except for two data points:
>
> 1) The proposal to include generic function dispatch
>    in Python 3000, based on explicit typing.
>
> 2) The proposal to remove all forms of type testing
>    other than those based on isinstance() (in other words,
>    removing callable, isSequence, isMapping, etc.)
>    (I'm not including attribute testing here because its
>    neither standardized nor systematic.)
>
> The net effect of these proposals is to greatly strengthen
> the capabilities of explicit typing, while seriously crippling
> the use of duck typing. By putting a much greater emphasis on
> explicit typing, we're effectively moving Python away from the
> implcit "duck-typing" that we've known up to this point.
>
> So essentially Python is *already* becoming a different
> language, whether we like it or not.
>
> I think that I agree with the gist of Tomer's point. I'm not
> going to claim that types are useless, but I think we should
> think about ways of dispatching other than types.
>
> What would seem very 'Pythonic' to me would be a system
> whereby objects can not only be dispatched on their
> types but also their *capabilities*. Thus, instead
> of asking the question "Is this a sequence?", we ask
> "Can this be iterated?"
>
> In such a model a "sequence type" would simply be a
> set of capabilities that often occur together.
>
> I think at the very least, we need a way a better
> definition of a "capability", and a formalized way
> to test for its presence. Whether or not that is
> directly wired into the dispatch mechanism (which would
> be cool) is another issue. Certainly attribute testing
> is part of it, but there needs to be agreement on which
> attributes to test.
This idea of capability is described in the literature using other words. 
(Reference below.)  When types are viewed as predicates defining sets of 
objects they can accommodate all wishes, including multiple inheritance. 

Note that GvR and type-sig had abandoned compile-time type -checking-, this 
being left to IDEs. That's why the current proposal is for -optional- type 
checks.

Tomer's complaints about 'types' all relate to the (now outdated) nominative 
type systems. Modern functional languages have structural subtyping. IMVHO 
Python's duck typing is structural subtyping. A question for Py3k is whether 
ir supports structural equivalence or nominative subtyping in the new type 
annotations. 

A simple test to see where your thinking is at. Consider:

interface I1:
    def foo(a: t1, b: t2) -> t3:
        "docstring"

class C(I1):    # implements I1
    def foo(a, b):
        return a+b

class D(object):    
    def foo(a: t1, b: t2) -> t3:
        return a+b

The manual for isinstance() says: "return true if classinfo is a type object 
and object is an object of that type". So consider this:

	 isinstance( D(), I1 ) 

Is this True or False? 

--- references:
http://www.artima.com/weblogs/viewpost.jsp?thread=87182
http://citeseer.ist.psu.edu/cardelli85understanding.html
http://billbirch.wordpress.com/

From p.f.moore at gmail.com  Wed May 10 16:38:49 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 10 May 2006 15:38:49 +0100
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <200605102334.31944.birchb@tpg.com.au>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<200605102334.31944.birchb@tpg.com.au>
Message-ID: <79990c6b0605100738m4d8fc456g43e5644419b4c5cf@mail.gmail.com>

On 5/10/06, Bill Birch <birchb at tpg.com.au> wrote:
> A simple test to see where your thinking is at. Consider:
[...]
> The manual for isinstance() says: "return true if classinfo is a type object
> and object is an object of that type". So consider this:
>
>          isinstance( D(), I1 )
>
> Is this True or False?

(Making obvious assumptions about the syntax that isn't "real" Python...)

Clearly False - D() is not an object of type I1.

Of course, whether isinstance() is actually a useful way of checking
depends on what you're trying to discover. It's very rare that I'd
care about the actual class inheritance structure of an object. What I
care about is whether I can *use* it like an I1. And that's not
decidable (it includes semantic considerations), so no builtin can
answer that question for me.

Hence, I document my expectations, and trust my caller to follow the
documentation. We're all consenting adults, and all that... (Note:
This is ideal documentation, not real-life, you understand :-))

So where does that put my thinking?

Paul.

From qrczak at knm.org.pl  Wed May 10 16:59:39 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Wed, 10 May 2006 16:59:39 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <loom.20060509T071959-538@post.gmane.org> (talin@acm.org's
	message of "Tue, 9 May 2006 06:19:59 +0000 (UTC)")
References: <loom.20060507T073352-865@post.gmane.org>
	<ca471dc20605070840q76693586lf2ba3902777d7a5f@mail.gmail.com>
	<loom.20060507T221833-633@post.gmane.org>
	<445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.org>
	<fb6fbf560605080657k233091fdi25c82dfc5b3c3a9c@mail.gmail.com>
	<loom.20060509T071959-538@post.gmane.org>
Message-ID: <87bqu6c4dg.fsf@qrnik.zagroda>

Talin <talin at acm.org> writes:

> OK, so I hope I have established the requirement for duck typing.
> Now, I want to establish the requirement for interface discovery
> or 'type testing'.

These two are mutually incompatible. At least if we expect libraries
to be reliable and robust.

Python must decide one or the other: either interfaces are informal
and fuzzy, but we can't dispatch on them, and operation names are
quite explicit about how they treat their arguments; or interfaces
are named and explicitly declared, usable for testing and dispatching,
and operations are quite easily overloaded. Or some interfaces are
done in one way and some in the other, but they can't be mixed.

> Now, generic functions are good at dealing with these kinds of
> situations. However, generic functions (as they are usually
> concieved) can only deal with specific, concrete types, not
> "types which satisfy some constraint".

This is not without reasons. Generic functions need a sharp notion
of supported interfaces. Either there is a reliable way to tell a
dictionary from a sequence, or there is not. Either approach leads
to a coherent language, but not both.

Explicitly declared interfaces have a partial order, which is useful
for dispatch. There is little hope for inferring inclusions among
arbitrary predicates.

> Thus we have a tension between duck types and type testing;
> Unfortunately, punting on this issue (i.e. saying "you can't do type
> testing on duck types") isn't a good option - both techniques are
> just too darn useful to say that you can't use them together.

Sorry, I believe this is the only possible option, and you are seeking
impossible.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From pje at telecommunity.com  Wed May 10 18:20:26 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 10 May 2006 12:20:26 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <mailman.21153.1147273187.27774.python-3000@python.org>
Message-ID: <5.1.1.6.0.20060510115856.036c13f0@mail.telecommunity.com>

At 04:59 PM 5/10/2006 +0200, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> 
wrote:
>Explicitly declared interfaces have a partial order, which is useful
>for dispatch.

Note that if the notion of "interface" is reduced to "a set of generic 
functions to which an object may be passed", then it's not necessary to 
have explicit interface declaration - it's an automatic side effect of 
implementing methods for the generic functions involved.  It also avoids 
reifying interfaces as concrete objects, except as a convenient way to 
refer to groups of generic functions.

Implementing this approach is actually a straightforward extension of 
Guido's overloaded function implementation, by replacing issubclass() with 
a generic function "implies()".  When comparing two classes, "implies()" 
would do the same as issubclass() (modulo the appropriate argument order), 
but it would also need to support comparing interface assertions with each 
other and with classes.  Overloaded functions would also need a 
"supports()" method to indicate whether the function has an unambiguous 
implementation for a given input signature.

These are very straightforward extensions -- a mild refactoring at 
most.  The only complicating factor in a production implementation would be 
that adding new methods at runtime to something like iter() would need to 
invalidate the signature caches of any generic functions with registered 
signatures based on iterability.  That means some kind of notification 
facility.  It'd be nice if it also worked for changes to a class' __bases__.


>There is little hope for inferring inclusions among
>arbitrary predicates.


It's true that inferring inclusions among truly arbitrary predicates is 
impractical, but it *can* readily be done for any N kinds of predicates, 
where N is however many you choose to implement.  RuleDispatch in fact uses 
a generic function to transform predicates into objects that can be ordered 
by inclusion, which allows applications with special needs to register new 
transformations.  (The built-in transformations change 'isinstance()' and 
'issubclass()' subexpressions into class-based criterion objects, for example.)

However, I'm not advocating that this kind of capability to be added to 
Python directly; I'd just like to be able to integrate RuleDispatch's more 
advanced features into whatever overloading machinery Python ends up with.


From pje at telecommunity.com  Wed May 10 18:39:57 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 10 May 2006 12:39:57 -0400
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <mailman.21153.1147273187.27774.python-3000@python.org>
Message-ID: <5.1.1.6.0.20060510123134.01e68008@mail.telecommunity.com>

At 11:21 AM 5/10/2006 +0100, Ben.Young at risk.sungard.com wrote:
>Have you taken a look at ConceptGCC? (
>http://www.osl.iu.edu/~dgregor/ConceptGCC/)
>
>It's basically a first cut at implementing the Concepts which will be
>availiable in the next version of C++. They basically provide full compile
>time "duck typing" as well as adaptation for types that don't exactly fit
>the concept. (e.g if the type doesn't have a length method, here's how you
>provide it.
>
>It's a very powerfull idea, and probably well worth looking at for
>inspiration.

FWIW, I skimmed through the tutorial; it appears that a "Concept" is 
roughly equivalent to a typeclass in Haskell, and a "Model" is roughly 
equivalent to a typeclass instance.

One of the papers on the site mentions something called "concept-based 
overloading", which if I'm reading it correctly, is the idea that's at the 
heart of this thread; i.e., it should be possible to say that a particular 
implementation of one operation is dependent upon the availability of an 
implementation of some other operation.


From janssen at parc.com  Wed May 10 19:12:47 2006
From: janssen at parc.com (Bill Janssen)
Date: Wed, 10 May 2006 10:12:47 PDT
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: Your message of "Wed, 10 May 2006 02:44:17 PDT."
	<14251043.1147254257608.JavaMail.ronaldoussoren@mac.com> 
Message-ID: <06May10.101255pdt."58641"@synergy1.parc.xerox.com>

> >> this approach doesn't do anything beyond what Java does
> >
> >Actually, it does.  It lets you inherit behavior, as well as interfaces.
> 
> It only lets you inherit behaviour to new subclasses

Not that it matters, but...  Yes, that's right.  In systems like
these, that's how you "add functionality to already existing classes";
you mix them with the new functionality into a new type.

Bill


From pje at telecommunity.com  Wed May 10 19:50:53 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 10 May 2006 13:50:53 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <06May10.101255pdt."58641"@synergy1.parc.xerox.com>
References: <Your message of "Wed, 10 May 2006 02:44:17 PDT."
	<14251043.1147254257608.JavaMail.ronaldoussoren@mac.com>
Message-ID: <5.1.1.6.0.20060510134709.01e668a0@mail.telecommunity.com>

At 10:12 AM 5/10/2006 -0700, Bill Janssen wrote:
> > >> this approach doesn't do anything beyond what Java does
> > >
> > >Actually, it does.  It lets you inherit behavior, as well as interfaces.
> >
> > It only lets you inherit behaviour to new subclasses
>
>Not that it matters, but...

Clearly it doesn't matter to *you*.  It does matter to me.


>Yes, that's right.  In systems like
>these, that's how you "add functionality to already existing classes";
>you mix them with the new functionality into a new type.

Which makes them inferior to existing adaptation systems for Python, which 
in turn are inferior to generic functions.

When I say that thing A is "inferior" to thing B, I mean that B can do 
whatever A can, but A cannot be used to do things that B can.  By that 
definition, using inheritance to denote behavior availability is markedly 
inferior to the other alternatives.


From jimjjewett at gmail.com  Wed May 10 20:09:22 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 10 May 2006 14:09:22 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <-5957998366719052543@unknownmsgid>
References: <14251043.1147254257608.JavaMail.ronaldoussoren@mac.com>
	<-5957998366719052543@unknownmsgid>
Message-ID: <fb6fbf560605101109u65cf5ad2q324783cda3340eb0@mail.gmail.com>

On 5/10/06, Bill Janssen <janssen at parc.com> wrote:

> > It only lets you inherit behaviour to new subclasses

> Not that it matters, but...  Yes, that's right.  In systems like
> these, that's how you "add functionality to already existing classes";
> you mix them with the new functionality into a new type.

The problem with this is that

(1)  Existing objects already have a class, so you can't add behavior
to old objects.
(2)  Existing factories put out the old class, so you can't add
behavior to new objects.

For instance, it is theoretically possible to create an object whose
__dict__ is a subclass of dict.  In practice, it isn't so easy.  (2.5
changed the implementation of dict itself to support this, and I'm
still not sure how to actually do it cleanly.)

-jJ

From qrczak at knm.org.pl  Wed May 10 20:27:43 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Wed, 10 May 2006 20:27:43 +0200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <5.1.1.6.0.20060510115856.036c13f0@mail.telecommunity.com>
	(Phillip J. Eby's message of "Wed, 10 May 2006 12:20:26 -0400")
References: <5.1.1.6.0.20060510115856.036c13f0@mail.telecommunity.com>
Message-ID: <87bqu5hh0g.fsf@qrnik.zagroda>

"Phillip J. Eby" <pje at telecommunity.com> writes:

> Note that if the notion of "interface" is reduced to "a set of generic
> functions to which an object may be passed", then it's not necessary
> to have explicit interface declaration - it's an automatic side effect
> of implementing methods for the generic functions involved.

Right. So I must correct myself: it's not an either-or choice for
the entire language, but for each interface separately.

There are formalized interfaces or abstract supertypes which can be
used for dispatch, and are usually declared explicitly (or at least
computed from other explicit interfaces); and informal interfaces or
predicates, not reified in the program but present in the programmers'
minds.

The choice is which concrete interfaces are of the first kind,
and which are of the second kind. For example whether sequences
or file-like objects are explicit.

Note that being declared explicitly doesn't imply that they would have
to be declared right at the point where the type is implemented. They
should be possible to be added later.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From pje at telecommunity.com  Wed May 10 20:49:16 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 10 May 2006 14:49:16 -0400
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <06May10.113200pdt."58641"@synergy1.parc.xerox.com>
References: <Your message of "Wed, 10 May 2006 10:50:53 PDT."
	<5.1.1.6.0.20060510134709.01e668a0@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060510144636.03808708@mail.telecommunity.com>

At 11:31 AM 5/10/2006 -0700, Bill Janssen wrote:
> > Which makes them inferior to existing adaptation systems for Python, which
> > in turn are inferior to generic functions.
>
>"Inferior" according to some belief system you obviously feel strongly
>about.

According to a very straightforward definition which I've previously 
supplied in another email.


>Personally, I think that Python's type system is fine as it is, and
>that there are more pressing issues, but I have no objection to your
>improving it, so long as you don't break it.

Many people (including Guido, IIRC) have pointed out the severe limitations 
of your proposal, but you keep ignoring them.  As far as I can tell, it is 
you who has proposed to break Python's type system by eliminating 
attribute-based duck typing and replace it with inheritance markers.


From jimjjewett at gmail.com  Wed May 10 21:39:34 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 10 May 2006 15:39:34 -0400
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <0aa201c673d0$4bf188b0$53b02997@bagio>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
	<0aa201c673d0$4bf188b0$53b02997@bagio>
Message-ID: <fb6fbf560605101239h160c55cdq96d09cc2b55466e7@mail.gmail.com>

On 5/9/06, Giovanni Bajo <rasky at develer.com> wrote:

> ??? Events, slots and signals are all public parts of a GUI API.

They happen to be public parts of many existing GUI APIs.

This does not mean that they need to be exposed unchanged as part of
the default python UI API.  I know that there are differences between
signal/slots and events, but I also know that they *usually* don't
matter much.  If they matter to you, then you are probably a candidate
for a 3rd party library which can be updated more than once every year
or two.

> I was just trying to say that designing something like QPainter, with a common
> API which totally abstracts from the OS details but still allows hardware
> acceleration on most platforms (GDI+ on Windows, for instance) is very very
> complex (and it went through several revisions and refinements).

I believe you.

It is probably complex enough to justify using its own 3rd-party
graphics library instead of the default library.

The standard library should not be bulked up to handle this special case.

> Qt *did* it, so let's use it. wxWidgets does *exactly* what you want: ...

So which is better?  There are disagreements.  Both will continue to
exist.  Using either is a huge commitment, because they aren't typical
python.

This mental cost is something that developers shouldn't pay unless
their *own* project cares enough about the non
least-common-denominator stuff to need a specific choice.

> Say I need a pushbutton, with toggle state, which contains a
> embossed rectangle which is filled of red when the button is
> pressed and filled of green when the button is raised.
> ... [more examples] ...

If your needs are that specific ("must be green", as opposed to "state
must be obvious"), then I'm not sure the standard library even
*should* support them.  That said, your specific cases are simple
enough that I wouldn't object to the UI API supporting them; I'm just
pointing out that you are likely to be someone who needs a third-party
library anyhow, and tailoring the standard library to you is likely to
be wasted effort.

> Then, I'd like to have a name for 1,0,-1 instead of using the bare numbers
> (in case there are 4 buttons...). So, we're back to what Qt does: you're using
> magic numbers too. I don't think there's a way out.

I do not claim that PyGUI is perfect.  I don't think even the author
(Greg) claims that.

My personal preference would be (singleton) objects in the UI package
for yes, no, and cancel.  The yes object should evaluate true; no and
cancel should evaluate false.  If you needed to know exactly which
appeared, you could test identity.  Labels could be internationalized.

More importantly, the package could be implemented by multiple
libraries.  The Qt version of No would have an __index__ method
returning 4; someone else's might subclass from string, and print as
"No".  You wouldn't have the full power of the underlying Qt (or wx or
Tk) engine, but you wouldn't have the full complexity either, and you
wouldn't have to care which was present.

-jJ

From guido at python.org  Wed May 10 21:58:07 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 10 May 2006 12:58:07 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <44603687.6020905@canterbury.ac.nz>
References: <loom.20060507T073352-865@post.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
	<ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>
	<d11dcfba0605081951jd2a894an9c5da73996f80349@mail.gmail.com>
	<ca471dc20605082051t4bbce985w11e7fda12a401a05@mail.gmail.com>
	<1147147707.12713.123.camel@resist.wooz.org>
	<ca471dc20605082123r54515350n27e5bc7b868837eb@mail.gmail.com>
	<44603687.6020905@canterbury.ac.nz>
Message-ID: <ca471dc20605101258j31afbf06j3bc26d4d0c5f2e88@mail.gmail.com>

On 5/8/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> While we're on the subject, something that causes me
> intense annoyance from time to time is when I get a
> message like "Method foobar expects m args, got n",
> but it doesn't tell me *which* of the myriad foobar
> methods in my program it was trying to call.
>
> It would be much more helpful if it could say something
> like "Method YourModule.YourClass.foobar ..."
>
> This might require storing a bit more information
> in a function at def time. But it wouldn't be as
> difficult as in the earlier discussions about having
> a method reference its class, because we don't need
> the actual class, just its name.

Would it be okay to list the filename and line no instead of the
class? That information is readily available from the code object.
(I'm assuming you're talking about Python functions/methods, not C
ones -- for those, teh best you can do in general is specify the
module; perhaps the class/type is also available if applicable.)

I think a patch for this type of improvement would be happily accepted.

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

From tomerfiliba at gmail.com  Wed May 10 22:03:52 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Wed, 10 May 2006 22:03:52 +0200
Subject: [Python-3000] why interfaces shouldn't be trusted
Message-ID: <1d85506f0605101303r363a01aeuda7cd796e13182b6@mail.gmail.com>

i think it's only Bill who said that, but i wanted to show why interfaces
(and inheritance) shouldn't be the basis for type-checking.

here's a nice interface:

class IFile(object):
    def write(self, data):
        pass
    def read(self, count):
        pass

and here's a class that "implements/derives" from this interface, but
completely ignores/breaks it:

class MyFile(IFile):
    def write(self, x, y, z):
        ....

m = MyFile()

now m is an instance of IFile, but calling m.write with the signature of
IFile.write won't work...

so, you could say, just enforce method signatures:
* the metaclass would check method signatures prior to creating the
class
* add casting, i.e., looking at the object at more than one way,
according to its bases:
cast(m, IFile).write()
so that MyFile could define a non-compatible method signature, but
up-casting it, would give you the original IFile method you'd
 expect.

and then you get java with a python syntax. so it's pointless.

in python, the type of x is the method-resolution-order (mro) of x, i.e.,
it defines what happens when you do x.y. (by the way, it would be
nice if __mro__ was mutable)

doing isinstance(a, b) only says it "a" has "b" in it's bases, not that "a"
compiles with "b"'s APIs or method signatures. there's no way to tell
the method signature is what you expect before calling it. therefore, i
see no reason why people should use type()/isinstance() on objects.

call it protocol, call it capabilities, in the end, it's "something the object
has" (hasattr) , rather than "something about the object" (type). so
checking "something about the object", i.e. if it inherits some interface
or base class, is not helpful.

of course ridding python of types is quite a drastic move. i would
suggest leaving the current mechanism, perhaps making it more lax,
but as the standard mechanism to early-check for type conformness,
use hasattr over isinstance.

that leaves in tact pyprotocols and the adapt PEP, which, imho, are
a very good example for a dynamic type system: casting is enforced
by the language, where as adaptation can be performed by the objects
themselves, which is of course much more powerful.

----

Oleg Broytmann wrote:
>   Even this is meaningless: '1'+1. So duck typing is:

yes, you *can* syntactically add "1" with 1, i.e., the code would compile.
evaluating the code would result in an exception, "unsupported operand
type(s) for +: 'int' and 'str'". that's the situation today, and i
don't see why
it should change.

builtin types, like ints and strings, have an internal real "underlying type",
but python-level types shouldn't: a pythonic type is just a collection of
attributes.

----

one thing that worries me with generic methods is, they would dispatch
based on types... which means my proxies would all break. please, think
of the proxies! ;)

or at least add a __type__ special method that can affect type(x), i.e.
type(x) --> x.__type__(), so proxies could return the type of the proxied
object, rather than the proxy object itself.

that way, generic methods could work with proxies.



-tomer

From qrczak at knm.org.pl  Wed May 10 22:16:56 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Wed, 10 May 2006 22:16:56 +0200
Subject: [Python-3000] why interfaces shouldn't be trusted
In-Reply-To: <1d85506f0605101303r363a01aeuda7cd796e13182b6@mail.gmail.com>
	(tomer filiba's message of "Wed, 10 May 2006 22:03:52 +0200")
References: <1d85506f0605101303r363a01aeuda7cd796e13182b6@mail.gmail.com>
Message-ID: <87y7x9ab47.fsf@qrnik.zagroda>

"tomer filiba" <tomerfiliba at gmail.com> writes:

> one thing that worries me with generic methods is, they would
> dispatch based on types... which means my proxies would all break.
> please, think of the proxies! ;)

OTOH proxies generated by my Python<->Kogut bridge would break if
hasattr was used to determine interfaces. For example if obj is a
Kogut object wrapped in a Python object, then obj.__iter__ always
succeeds, but calling the resulting function fails if the underlying
object doesn't actually support iteration.

(Types aren't currently reflected either, so type-based interface
discovery would fail too, but I plan to change that.)

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From oliphant.travis at ieee.org  Wed May 10 23:11:21 2006
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Wed, 10 May 2006 15:11:21 -0600
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <4461428C.60803@canterbury.ac.nz>
References: <loom.20060502T201105-105@post.gmane.org>	<e38g44$bfb$1@sea.gmane.org>
	<44596963.8070200@canterbury.ac.nz>	<e3ga30$9sq$1@sea.gmane.org>
	<e3qvqa$k6m$1@sea.gmane.org> <4461428C.60803@canterbury.ac.nz>
Message-ID: <446256F9.50507@ieee.org>

Greg Ewing wrote:
> Travis E. Oliphant wrote:
>> Just get a 
>> window-area from each platform's lowest-level tool and then draw your 
>> widgets to the screen directly.
> 
> But then you have something that looks totally non-native
> on all platforms. While it may be useful to have such a thing,
> it's not what PyGUI is designed to be.
>

Sure, I understand that.  With appropriate theming, though it could be 
made to look "native"  -- that's what Enthought is doing..


>> The thing that bothers me most about all of Python's GUI 
>> toolkits is that they are almost always wrappers of wrappers of wrappers...
> 
> And I'm trying to minimise this by building PyGUI as directly
> as possible on what the platform already provides. But not
> at such a low level that native appearance and behaviour
> is lost.
> 
>> I suspect you could start by just interfacing with the 
>> "platform-default" toolkits MFC, Cocoa, Gnome, and KDE (using ctypes for 
>> example) and then using an approach similar to PyGUI to wrap them all up 
>> using standard calls.
> 
> Um... how would that be different from PyGUI itself?
> 

Not much different at all except in breadth.  I like the idea of PyGUI 
(it doesn't cover all backends, yet though).   Sorry I wasn't more 
clear.  The only thing I would wish different is to get rid of the PyGTK 
dependency.   I think PyGUI should be a wrapper directly on top of GNOME 
because the only reason not to go down to raw X11 is for look-and-feel. 
  Thus, PyGUI should go to the GNOME libraries and wrap them directly 
instead of using another Python layer that wraps it.  Then another PyGUI 
backend would wrap the KDE libraries directly for its look and feel (but 
the same PyGUI paradigm).

In short, I don't like the chaining effect of wrapper on top of wrapper. 
  I want to make the connection to platform libraries as simple as 
possible.   Ultimately, I also think PyGUI should provide a simple 
look-and-feel of its own as well for situations where there is no 
"platform" look and feel (i.e. Unix users without either KDE or GNOME 
and just X11 or some other windowing environment).

Such a thing would be a very useful addition to Python.   And make no 
mistake, I think PyGUI is going in the right direction.  So, three 
cheers for Greg...


Best,

-Travis


From oliphant.travis at ieee.org  Wed May 10 23:13:55 2006
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Wed, 10 May 2006 15:13:55 -0600
Subject: [Python-3000] Allowing slice syntax in more places
Message-ID: <e3tl2j$e28$2@sea.gmane.org>


I'm sorry if this has been discussed before.

One of the things that is really nice about slice syntax is the ability 
to construct slice objects to pass to __getitem__  using []

Would it be possible to extend the syntax so that slice syntax is 
acceptable in more places in Python?  In particular function calls would 
be a very useful addition.  Thus,

myfunc(3:4:0.5, 1:5)

would produce the equivalent bytecode as

myfunc(slice(3,4,0.5), slice(1,5))


-Travis




From guido at python.org  Wed May 10 23:16:28 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 10 May 2006 14:16:28 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <5.1.1.6.0.20060510144636.03808708@mail.telecommunity.com>
References: <5.1.1.6.0.20060510134709.01e668a0@mail.telecommunity.com>
	<5.1.1.6.0.20060510144636.03808708@mail.telecommunity.com>
Message-ID: <ca471dc20605101416u329a21bm21435ddcce0c358d@mail.gmail.com>

On 5/10/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> Many people (including Guido, IIRC) have pointed out the severe limitations
> of your proposal, but you keep ignoring them.  As far as I can tell, it is
> you who has proposed to break Python's type system by eliminating
> attribute-based duck typing and replace it with inheritance markers.

I'm beginning to wonder if it isn't teh case that nobody here
understands Bill's proposal, and somehow in the heat of the argument
Bill hasn't been able to describe it adequately. In particular I
question my own understanding because I don't see how you *can* remove
duck typing from Python -- at least not without adding required type
declarations everywhere.

The crux of the matter seems to be how to add behavior *after* you
already have an instance of a class -- or, equivalently (?), how to
add behavior to a class when you have no control over the code that
creates instances of it.

Can you enlighten us, Bill?

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

From robert.kern at gmail.com  Wed May 10 23:44:57 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 10 May 2006 16:44:57 -0500
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <446256F9.50507@ieee.org>
References: <loom.20060502T201105-105@post.gmane.org>	<e38g44$bfb$1@sea.gmane.org>	<44596963.8070200@canterbury.ac.nz>	<e3ga30$9sq$1@sea.gmane.org>	<e3qvqa$k6m$1@sea.gmane.org>
	<4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org>
Message-ID: <e3tmsr$kjo$1@sea.gmane.org>

Travis E. Oliphant wrote:
> Greg Ewing wrote:
> 
>>Travis E. Oliphant wrote:
>>
>>>Just get a 
>>>window-area from each platform's lowest-level tool and then draw your 
>>>widgets to the screen directly.
>>
>>But then you have something that looks totally non-native
>>on all platforms. While it may be useful to have such a thing,
>>it's not what PyGUI is designed to be.
> 
> Sure, I understand that.  With appropriate theming, though it could be 
> made to look "native"  -- that's what Enthought is doing..

We only do that when we have to, i.e. when wxWidgets isn't up to the task. We
try to avoid it if we can. The amount of effort to make custom-drawn widgets
look "native" on each of the Big Three is large, so we end up doing it somewhat
incompletely preferring to satisfy our customers' desires. None of our tools
look very native on the Mac. Fortunately, our customers are used to scientific
apps that look much worse than ours.

We also embed native (well, wx) widgets like scrollbars into our Enable canvases
for the things that we *have* to draw ourselves, like plots.

>>>I suspect you could start by just interfacing with the 
>>>"platform-default" toolkits MFC, Cocoa, Gnome, and KDE (using ctypes for 
>>>example) and then using an approach similar to PyGUI to wrap them all up 
>>>using standard calls.
>>
>>Um... how would that be different from PyGUI itself?
> 
> Not much different at all except in breadth.  I like the idea of PyGUI 
> (it doesn't cover all backends, yet though).   Sorry I wasn't more 
> clear.  The only thing I would wish different is to get rid of the PyGTK 
> dependency.   I think PyGUI should be a wrapper directly on top of GNOME 
> because the only reason not to go down to raw X11 is for look-and-feel. 
>   Thus, PyGUI should go to the GNOME libraries and wrap them directly 
> instead of using another Python layer that wraps it.  Then another PyGUI 
> backend would wrap the KDE libraries directly for its look and feel (but 
> the same PyGUI paradigm).

Unfortunately, that approach duplicates a tremendous amount of effort that was
put into the wrappers in the first place. Wrapper on top of wrapper may feel
icky, but the effort shouldn't be duplicated without demonstrable benefits like
responsiveness. It seems to me that this might be done piecemeal, one widget at
a time.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From jcarlson at uci.edu  Thu May 11 00:20:09 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 10 May 2006 15:20:09 -0700
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <0ab601c673d2$4a25de80$53b02997@bagio>
References: <loom.20060510T031553-404@post.gmane.org>
	<0ab601c673d2$4a25de80$53b02997@bagio>
Message-ID: <20060510150405.6800.JCARLSON@uci.edu>


"Giovanni Bajo" <rasky at develer.com> wrote:
> Show me a combo-box with selects among items with both text and a
> bitmap, done with wxPython, on all platforms.

How about I describe how one can make it happen?

There was a somewhat recent post in wxpython-users which offered a
reimplementation of wx.PopupWindow (previously not available on Mac). 
There was another post which overrode the various "show me the choices
command" for a wx.ComboBox (or wx.Choice, I can't remember, and they are
almost the same) to show in a wx.PopupWindow, a tree rather than a list.
It also offered a fairly simple method to replace that tree, list, etc.,
with an arbitrary control of the user's choosing.

By using a wx.ListCtrl, one can embed icons to the left of rows
arbitrarily.  Couple this "embed arbitrary controls for the wx.ComboBox",
and the "new wx.PopupWindow" implementation, and you have all of the
building blocks necessary.

Is that sufficient?

 - Josiah


From rasky at develer.com  Thu May 11 00:54:13 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Thu, 11 May 2006 00:54:13 +0200
Subject: [Python-3000] GUI -- an API, not a toolkit
References: <loom.20060510T031553-404@post.gmane.org>
	<0ab601c673d2$4a25de80$53b02997@bagio>
	<20060510150405.6800.JCARLSON@uci.edu>
Message-ID: <055601c67484$a8898e10$bf03030a@trilan>

Josiah Carlson wrote:

>> Show me a combo-box with selects among items with both text and a
>> bitmap, done with wxPython, on all platforms.
>
> How about I describe how one can make it happen?
>
> There was a somewhat recent post in wxpython-users which offered a
> reimplementation of wx.PopupWindow (previously not available on Mac).
> There was another post which overrode the various "show me the choices
> command" for a wx.ComboBox (or wx.Choice, I can't remember, and they
> are almost the same) to show in a wx.PopupWindow, a tree rather than
> a list. It also offered a fairly simple method to replace that tree,
> list, etc., with an arbitrary control of the user's choosing.
>
> By using a wx.ListCtrl, one can embed icons to the left of rows
> arbitrarily.  Couple this "embed arbitrary controls for the
> wx.ComboBox", and the "new wx.PopupWindow" implementation, and you
> have all of the building blocks necessary.
>
> Is that sufficient?

It's sufficient to show that a library that uses native widget has to go
through many hoops to implement any slightly non-standard feature. And
causes the mental overhead which makes it unpythonic.

Compare this with PyQt. You create a QComboBox (you wanted a combobox), and
you can set a text and/or a pixmap for each item, using self.insertItem(px,
txt). Qt can export a much better, friendly and well-designed API because it
doesn't rely on native widgets. It draws the widgets itself, so they always
have the very same features for all the platforms that Qt supports. For
instance, the other day I shrinked a horizontal scrollbar in the vertical
direction (make it look "smaller"). It worked immediately for Windows, Mac
and Linux. I don't think Windows can have a "smaller" scrollbar at all, for
instance, at least not without adjusting its theme.

OK, this is totally off-topic. I guess we can continue in private mails...
-- 
Giovanni Bajo


From janssen at parc.com  Thu May 11 01:30:21 2006
From: janssen at parc.com (Bill Janssen)
Date: Wed, 10 May 2006 16:30:21 PDT
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: Your message of "Wed, 10 May 2006 14:16:28 PDT."
	<ca471dc20605101416u329a21bm21435ddcce0c358d@mail.gmail.com> 
Message-ID: <06May10.163031pdt."58641"@synergy1.parc.xerox.com>

Guido writes:
> The crux of the matter seems to be how to add behavior *after* you
> already have an instance of a class -- or, equivalently (?), how to
> add behavior to a class when you have no control over the code that
> creates instances of it.

I have no contribution to make about either of those, I think (though
the compelling use cases elude me).

My point was rather about the definition of the built-in and other
standard types.  The Python community has evolved this culture of
"magic method names", which I believe was primarily caused by the
conflict between defined-in-C types and defined-in-Python types.
People wanted a way to make things that looked like file objects, but
couldn't actually subclass "file".  They wound up implementing a class
that had some of the same method names that the built-in "file" object
had: "read", "seek", "write", etc.  Usually not all of them, which
would cause some problems when an instance of that type was used as a
file object.  (I like the comment at the beginning of StringIO.py:
"This implements (nearly) all stdio methods."  It's left as an
exercise to the reader to determine what's missing.)

Worse, programs that wanted to do runtime type-checking or type-based
dispatch had no accurate way to check types.  You'd have to crawl the
whole outline of the type, and, even if you found the method names you
were looking for, you had no way to know if their *meaning* was the
same.  With a type-based system, you could check the type to see if
(a) the methods you needed are there, and (b) if they have the
semantics you need.  It's just shorthand for a group of methods along
with their supposed meanings.

Sure, it can be subverted, along with any other programming construct,
by a programmer who inherits from the type, then proceeds to override
methods or operators using completely different semantics:

   class JarFile (ZipFile):

     def listfiles(self):
        import shutil
        shutil.rmtree("/")

tomer filiba makes a point:
> in python, the type of x is the method-resolution-order (mro) of x, i.e.,
> it defines what happens when you do x.y. (by the way, it would be
> nice if __mro__ was mutable)
> 
> doing isinstance(a, b) only says it "a" has "b" in it's bases, not that "a"
> compiles with "b"'s APIs or method signatures. there's no way to tell
> the method signature is what you expect before calling it. therefore, i
> see no reason why people should use type()/isinstance() on objects.

That's why people write "b.y(x)" if they have any doubt about the mro.
To make sure you are calling the right method, with the right
signature, with the right semantics.

I think there's some confusion about the differences between "duck
typing", "dynamic typing", and "static typing", as well.  The choice
isn't between Java typing (mainly static, and cumbersome) and no
typing (which is what duck typing is close to).  I'm a big believer in
dynamic typing (though optional partial static typing would be nice).
Strong dynamic typing would be nice to have, but I'd be happy if we
just discouraged the sloppy typing that's currently the vogue in
Python programming.

Anyway...  Since the standard types can now be inherited from, I was
suggesting that the Py3K core consist of a set of types, which are
designed to be used, but also to be inherited from.  I was suggesting
that StringIO, for instance, in Py3K should inherit from "file", and
override methods as necessary to achieve its effect.  I was *not*
suggesting that the ability to add slots to instances be removed, or
that the ability to introspect over values be removed.

Bill

From guido at python.org  Thu May 11 02:01:05 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 10 May 2006 17:01:05 -0700
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <5553726489438271847@unknownmsgid>
References: <ca471dc20605101416u329a21bm21435ddcce0c358d@mail.gmail.com>
	<5553726489438271847@unknownmsgid>
Message-ID: <ca471dc20605101701q3bf99d76m59f5dc187620df93@mail.gmail.com>

On 5/10/06, Bill Janssen <janssen at parc.com> wrote:
> Guido writes:
> > The crux of the matter seems to be how to add behavior *after* you
> > already have an instance of a class -- or, equivalently (?), how to
> > add behavior to a class when you have no control over the code that
> > creates instances of it.
>
> I have no contribution to make about either of those, I think (though
> the compelling use cases elude me).

Thanks for the clarification! I'm sure Phillip and others have many
(of the latter form). Adaptation and generic functions are all about
that. It seems that this is one of the reasons you weren't getting
your point across.

(FWIW, I'm at best lukewarm on generic functions, despite having
implemented them several times now, and having proposed them as an
alternative to adaptation. They seem to be a useful trick for certain
esoteric situations, but I don't want to redesign everything to use
generic functions instead of classes, for example. Therefore, the
applicability of Haskell's typeclasses still eludes me.)

> My point was rather about the definition of the built-in and other
> standard types.  The Python community has evolved this culture of
> "magic method names", which I believe was primarily caused by the
> conflict between defined-in-C types and defined-in-Python types.
> People wanted a way to make things that looked like file objects, but
> couldn't actually subclass "file".  They wound up implementing a class
> that had some of the same method names that the built-in "file" object
> had: "read", "seek", "write", etc.  Usually not all of them, which
> would cause some problems when an instance of that type was used as a
> file object.  (I like the comment at the beginning of StringIO.py:
> "This implements (nearly) all stdio methods."  It's left as an
> exercise to the reader to determine what's missing.)

I'm not so sure that it had much to do with the inability to subclass.
Since subclassing also implies implementation inheritance, I'm not
sure how subclassing "file" would help StringIO. Now, if you add
abstract types into the mix, you could be on to something. It's still
radical, and I don't know how far the enforcement should go, and there
are issues with the need for splinter interfaces (e.g. the various
kinds of files: seekable or not, read-only/write-only/read-write --
that already produces 6 different interfaces); but it's a not entirely
unreasonable proposal to say "we call it a sequence if it inherits
from this public abstract base class AbstractSequence" and so on.
There might not be a requirement to implement all methods (this could
be a way to avoid too many splinters).

I think there's a lot to argue for and against this proposal (more
than I have time). But I understand it, it might work, and it
shouldn't change the way we code in Python too much (except for the
places where we mess with isinstance() or hasattr()).

> Worse, programs that wanted to do runtime type-checking or type-based
> dispatch had no accurate way to check types.  You'd have to crawl the
> whole outline of the type, and, even if you found the method names you
> were looking for, you had no way to know if their *meaning* was the
> same.  With a type-based system, you could check the type to see if
> (a) the methods you needed are there, and (b) if they have the
> semantics you need.  It's just shorthand for a group of methods along
> with their supposed meanings.
>
> Sure, it can be subverted, along with any other programming construct,
> by a programmer who inherits from the type, then proceeds to override
> methods or operators using completely different semantics:
>
>    class JarFile (ZipFile):
>
>      def listfiles(self):
>         import shutil
>         shutil.rmtree("/")
>
> tomer filiba makes a point:
> > in python, the type of x is the method-resolution-order (mro) of x, i.e.,
> > it defines what happens when you do x.y. (by the way, it would be
> > nice if __mro__ was mutable)

You can change it by using a metaclass. That should be good enough.

> > doing isinstance(a, b) only says it "a" has "b" in it's bases, not that "a"
> > compiles with "b"'s APIs or method signatures. there's no way to tell
> > the method signature is what you expect before calling it. therefore, i
> > see no reason why people should use type()/isinstance() on objects.

But the *convention* is that if it inherits from b it conforms to b's
interface and semantic, unless you are working with a framework that
has a way to spell exceptions to that rule (like inheritance for
implementation only).

> That's why people write "b.y(x)" if they have any doubt about the mro.
> To make sure you are calling the right method, with the right
> signature, with the right semantics.

In my experience this is rare except when explicitly calling the
method one is overriding in a single inheritance situation.

> I think there's some confusion about the differences between "duck
> typing", "dynamic typing", and "static typing", as well.  The choice
> isn't between Java typing (mainly static, and cumbersome) and no
> typing (which is what duck typing is close to).  I'm a big believer in
> dynamic typing (though optional partial static typing would be nice).
> Strong dynamic typing would be nice to have, but I'd be happy if we
> just discouraged the sloppy typing that's currently the vogue in
> Python programming.

I'm not sure you can legislate duck typing away though. If I write a function

def foo(f):
  f.write("Ha ha ha")

with the intention that it be called with a file instance, you can't
prevent me from calling it with an instance of this class:

class Fool:
  def write(self, blah): return blah

> Anyway...  Since the standard types can now be inherited from, I was
> suggesting that the Py3K core consist of a set of types, which are
> designed to be used, but also to be inherited from.  I was suggesting
> that StringIO, for instance, in Py3K should inherit from "file", and
> override methods as necessary to achieve its effect.  I was *not*
> suggesting that the ability to add slots to instances be removed, or
> that the ability to introspect over values be removed.

I see. At least it would solve the problem that there's no way to tell
if something is a sequence or a mapping when all it implements is
__getitem__, __len__ and __contains__ (to take an extreme example). It
could form a solid basis to define isSequence, and callable, too.

That's not a +1 or even a +0 (nor a -1 BTW). Just an acknowledgement
of understanding of what you're proposing.

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

From talin at acm.org  Thu May 11 02:36:24 2006
From: talin at acm.org (Talin)
Date: Thu, 11 May 2006 00:36:24 +0000 (UTC)
Subject: [Python-3000] What do do about IDLE?
References: <mailman.20468.1146940506.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605071357030.23597@qew.cs>
	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
Message-ID: <loom.20060511T022957-365@post.gmane.org>

Paul Moore <p.f.moore <at> gmail.com> writes:

> On 5/7/06, Greg Wilson <gvwilson <at> cs.utoronto.ca> wrote:
> > > From: Greg Ewing <greg.ewing <at> canterbury.ac.nz>
> > > There is another alternative -- move both Tk and IDLE out of the core
> > > into separate downloads.
> >
> > +1.
> 
> If the implication here is that there is *no* GUI in the Python
> standard library, I'd be cautious of this (-0, probably). Things like
> the pydoc server use a little GUI window. The Twisted installer (IIRC)
> uses a Gui window while running the postinstall script, etc.
> Basically, if a generic Python script wants some form of GUI. Tk is
> available.
> 
> I've no problem with replacing Tk with an alternative. But there
> should be a GUI of some sort.

I had an odd thought about this last night.

It seems to me that, for the most part, any application that
requires a UI can be an external package that is installed via
easy_install. Given that we are going to finally *solve* the
problem of making it easy to add external packages (I hope)
there's a much weaker argument for making something part of
the std lib.

However, there is one type of application that I can think of
that is both GUI-based and at the same time makes a strong case
for its inclusion in the standard distribution: A visual
debugger.

I don't think we really need an IDE, but a debugger that is
at least able to show source code, call stack, and local
variables in a window would be extremely useful.

So my thought is this: How hard would it be to make
a curses-based debugger?

This gives me what I want, without requiring a GUI toolkit
be shipped with the standard libs.

(Could that be a possible Summer of Code project?)

-- Talin



From greg.ewing at canterbury.ac.nz  Thu May 11 03:25:08 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 11 May 2006 13:25:08 +1200
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <0ca601c67417$5fbb5460$53b02997@bagio>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
	<0aa201c673d0$4bf188b0$53b02997@bagio>
	<44617F8E.2050803@canterbury.ac.nz>
	<0ca601c67417$5fbb5460$53b02997@bagio>
Message-ID: <44629274.5000003@canterbury.ac.nz>

Giovanni Bajo wrote:

> Then, I'd like to have a name for 1,0,-1 instead of using the bare numbers (in
> case there are 4 buttons...).

There aren't any standard dialogs in PyGUI with 4 buttons,
so that problem doesn't arise. :-)

I could provide some names, Yes = 1, No = 0, etc. But
since you can override the titles of the buttons, these
names wouldn't always be correct.

> So, we're back to what Qt does: you're using
> magic numbers too.

But I've tried to choose easily-remembered magic numbers
with boolean compatibility. :-)

Wingardium-Leviosa-ly,
Greg

From greg.ewing at canterbury.ac.nz  Thu May 11 03:35:17 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 11 May 2006 13:35:17 +1200
Subject: [Python-3000] GUI events
In-Reply-To: <0d0001c6741b$e7b6e560$53b02997@bagio>
References: <fb6fbf560605091442y7d3098dahb77f2d91a625ab20@mail.gmail.com>
	<0a4801c673c1$bbb7dff0$53b02997@bagio>
	<fb6fbf560605091744h57324137u31c9e08b36c85679@mail.gmail.com>
	<1147222942.5646.11.camel@fsol> <44617DE5.5070104@canterbury.ac.nz>
	<0d0001c6741b$e7b6e560$53b02997@bagio>
Message-ID: <446294D5.9010504@canterbury.ac.nz>

Giovanni Bajo wrote:

> And how do you enable two controls when a checkbox is pressed?

In Gtk you'd have to write either one handler to enable
both controls, or two handlers to enable one control
each, and connect them to the signal. There's actually
*more* code to write in the multiple-handler case, as
far as I can see.

> Is there a production-ready GUI toolkit that *doesn't*
 > have multiple handlers?

I know of a number of toolkits that don't have a
concept of signals/handlers, but I fear you would
dismiss them as "not production-ready". :-)

--
Greg

From greg.ewing at canterbury.ac.nz  Thu May 11 03:52:02 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 11 May 2006 13:52:02 +1200
Subject: [Python-3000] PEP 3100 Comments
In-Reply-To: <ca471dc20605101258j31afbf06j3bc26d4d0c5f2e88@mail.gmail.com>
References: <loom.20060507T073352-865@post.gmane.org>
	<9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com>
	<1147099922.10381.20.camel@resist.wooz.org>
	<d11dcfba0605080847i63bbf793k2c0f0e4a3aafdc4c@mail.gmail.com>
	<ca471dc20605081833o3f2d7dd0l96825d44e31fa77a@mail.gmail.com>
	<d11dcfba0605081951jd2a894an9c5da73996f80349@mail.gmail.com>
	<ca471dc20605082051t4bbce985w11e7fda12a401a05@mail.gmail.com>
	<1147147707.12713.123.camel@resist.wooz.org>
	<ca471dc20605082123r54515350n27e5bc7b868837eb@mail.gmail.com>
	<44603687.6020905@canterbury.ac.nz>
	<ca471dc20605101258j31afbf06j3bc26d4d0c5f2e88@mail.gmail.com>
Message-ID: <446298C2.1040009@canterbury.ac.nz>

Guido van Rossum wrote:

> Would it be okay to list the filename and line no instead of the
> class? That information is readily available from the code object.

Yes, that would be fine.

> (I'm assuming you're talking about Python functions/methods, not C
> ones --

Mainly, yes.

> for those, teh best you can do in general is specify the
> module; perhaps the class/type is also available if applicable.)

Knowing the class or type would be useful where possible.

--
Greg

From edloper at gradient.cis.upenn.edu  Thu May 11 04:18:25 2006
From: edloper at gradient.cis.upenn.edu (Edward Loper)
Date: Wed, 10 May 2006 22:18:25 -0400
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <loom.20060511T022957-365@post.gmane.org>
References: <mailman.20468.1146940506.27774.python-3000@python.org>	<Pine.GSO.4.58.0605071357030.23597@qew.cs>	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
	<loom.20060511T022957-365@post.gmane.org>
Message-ID: <44629EF1.4000307@gradient.cis.upenn.edu>

Talin wrote:
> So my thought is this: How hard would it be to make
> a curses-based debugger?

The curses module isn't available on windows.  But if anyone wants to 
make a better debugger for python, it would certainly make me happy. :)

-Edward

From greg.ewing at canterbury.ac.nz  Thu May 11 05:43:57 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 11 May 2006 15:43:57 +1200
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <446256F9.50507@ieee.org>
References: <loom.20060502T201105-105@post.gmane.org>
	<e38g44$bfb$1@sea.gmane.org> <44596963.8070200@canterbury.ac.nz>
	<e3ga30$9sq$1@sea.gmane.org> <e3qvqa$k6m$1@sea.gmane.org>
	<4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org>
Message-ID: <4462B2FD.3070406@canterbury.ac.nz>

Travis E. Oliphant wrote:
> The only thing I would wish different is to get rid of the PyGTK 
> dependency.   I think PyGUI should be a wrapper directly on top of GNOME

Perhaps you have Gnome and Gtk confused? Gnome is the
desktop, Gtk is the UI library that Gnome applications
use.

> In short, I don't like the chaining effect of wrapper on top of wrapper.
>  I want to make the connection to platform libraries as simple as 
> possible.

So do I, but I'm concentrating on getting the API right
first. Optimisations such as reducing the number of wrapper
layers can come later.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From jcarlson at uci.edu  Thu May 11 05:57:08 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 10 May 2006 20:57:08 -0700
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <44629EF1.4000307@gradient.cis.upenn.edu>
References: <loom.20060511T022957-365@post.gmane.org>
	<44629EF1.4000307@gradient.cis.upenn.edu>
Message-ID: <20060510205645.6803.JCARLSON@uci.edu>


Edward Loper <edloper at gradient.cis.upenn.edu> wrote:
> 
> Talin wrote:
> > So my thought is this: How hard would it be to make
> > a curses-based debugger?
> 
> The curses module isn't available on windows.  But if anyone wants to 
> make a better debugger for python, it would certainly make me happy. :)

I hear that http://www.digitalpeers.com/pythondebugger/ is quite good,
though I'm happy with print statements.

 - Josiah


From tjreedy at udel.edu  Thu May 11 06:16:00 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 11 May 2006 00:16:00 -0400
Subject: [Python-3000] Requirements for a standard GUI library
References: <loom.20060502T201105-105@post.gmane.org>	<e38g44$bfb$1@sea.gmane.org><44596963.8070200@canterbury.ac.nz>	<e3ga30$9sq$1@sea.gmane.org><e3qvqa$k6m$1@sea.gmane.org>
	<4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org>
Message-ID: <e3udq1$jb8$1@sea.gmane.org>


"Travis E. Oliphant" <oliphant.travis at ieee.org> wrote in message 
news:446256F9.50507 at ieee.org...
> Not much different at all except in breadth.  I like the idea of PyGUI
> (it doesn't cover all backends, yet though).   Sorry I wasn't more
> clear.  The only thing I would wish different is to get rid of the PyGTK
> dependency.   I think PyGUI should be a wrapper directly on top of GNOME
> because the only reason not to go down to raw X11 is for look-and-feel.
>  Thus, PyGUI should go to the GNOME libraries and wrap them directly
> instead of using another Python layer that wraps it.  Then another PyGUI
> backend would wrap the KDE libraries directly for its look and feel (but
> the same PyGUI paradigm).
>
> In short, I don't like the chaining effect of wrapper on top of wrapper.
>  I want to make the connection to platform libraries as simple as
> possible.   Ultimately, I also think PyGUI should provide a simple
> look-and-feel of its own as well for situations where there is no
> "platform" look and feel (i.e. Unix users without either KDE or GNOME
> and just X11 or some other windowing environment).
>
> Such a thing would be a very useful addition to Python.   And make no
> mistake, I think PyGUI is going in the right direction.  So, three
> cheers for Greg...

My thoughts on PyGUI from reading the docs and some of the source:

First, it is actually three things, partially separable:

1. A Python-class-based application framework GUI: a fairly abstract layer.
2. An implementation design: generic classes overridden by specific toolkit 
classes.
3. A set of implementations: Cocoa and GTK so far.

Second, it needs some additions before prime time (stdlib inclusion):

1. Greg included the few widgets he needs; others want others and more.  If 
the drawing primitives (line,box, fill, image) in the current design are 
adequate, it should not be terribly difficult to add more, perhaps in a 
separate module, perhaps supervised by someone else.  I wonder whether the 
add-on module for Tkinter could be modified and somewhat reused.

2. There are roughly 30 generic modules (most very small) and 30 specific 
implementation modules (for each implementation, but only one set used at a 
time).  This makes for a lots of imports.  I wonder if startup would be 
noticeably faster if these were consolidated to two files/modules.  (I 
haven't gotten PyGUI up on my WinXP machine yet to test how long it takes). 
My idea is that they could be kept separate for development, if desired, 
and then consolidated by a rerunnable script.  There will also be a lot of 
entiries in sys.modules, making it harder to list and search by eye.

3. More implementations are needed, not necessarily by Greg.  Indeed, a 
test of the documentation, both in the doc and module docstrings and 
comments, is that someone else can do a port.  An obvious one to add is 
native Windows, without going thru GTK.

Less obvious might be SDL (Simple Directmedia Library).  It apparently runs 
on several platforms beyond the main ones, so a port would put the GUI on 
most of the platforms that Python runs on.  On some systems, SDL uses any 
of multiple video/graphics drivers.  So on Windows, it can use either the 
standard Windows GDI interface or full-screen DirectDraw.  On *nix, it can 
use any of about 10 different graphics drivers, X11 being only one, so it 
is not at all restricted to systems using X11.  The current Python wrapping 
is part of Pygame (done with Swig, I presume).  There has been some 
discussion by Pygame people of replacing the current wrapping with more 
direct calls using ctypes.

Terry Jan Reedy




From edcjones at comcast.net  Thu May 11 06:59:52 2006
From: edcjones at comcast.net (Edward C. Jones)
Date: Thu, 11 May 2006 00:59:52 -0400
Subject: [Python-3000] Debugger was Re: What do do about IDLE?
In-Reply-To: <mailman.21254.1147319044.27774.python-3000@python.org>
References: <mailman.21254.1147319044.27774.python-3000@python.org>
Message-ID: <4462C4C8.3080606@comcast.net>


From guido at python.org  Thu May 11 07:00:23 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 10 May 2006 22:00:23 -0700
Subject: [Python-3000] why interfaces shouldn't be trusted
In-Reply-To: <1d85506f0605101303r363a01aeuda7cd796e13182b6@mail.gmail.com>
References: <1d85506f0605101303r363a01aeuda7cd796e13182b6@mail.gmail.com>
Message-ID: <ca471dc20605102200n1ab41e6dp19b88b8c7c2b29b2@mail.gmail.com>

On 5/10/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> i think it's only Bill who said that, but i wanted to show why interfaces
> (and inheritance) shouldn't be the basis for type-checking.
>
> here's a nice interface:
>
> class IFile(object):
>     def write(self, data):
>         pass
>     def read(self, count):
>         pass
>
> and here's a class that "implements/derives" from this interface, but
> completely ignores/breaks it:
>
> class MyFile(IFile):
>     def write(self, x, y, z):
>         ....
>
> m = MyFile()
>
> now m is an instance of IFile, but calling m.write with the signature of
> IFile.write won't work...

So what? It wouldn't work either if it had the correct signature but
used the wrong implementation.

You seem to be still under the influence of the type-safety mafia, who
want to make you believe that with enough type-checking you can
prevent all bugs (though they don't believe it themselves).

Python already has a very useful kind of strong type safety: it tags
all data at the lowest level so it won't be interpreted the wrong way;
in particular it can't be tricked into dereferencing something that's
not a pointer to an object, or calling something that's not a pointer
to a well-behaved function. (Extensions like ctypes excluded.) Java
makes a similar guarantee. C++ and Perl don't.

Interface declarations, generic functions, and all the stuff we're
discussing here are not tools for catching more bugs; they are tools
for making programs more flexible. They let us overload APIs so that
foo(x) can do different things based on what kind of thing x *claims
to be*. There are already lots of ad-hoc approaches to this: foo(x)
could call x.__foo__(), or it could call fooregistry[type(x)](), or it
could partition the type space into a few categories (e.g. sequences,
dicts, files, and everything else) by doing a few hasattr() checks.
Or, of course, we could have written x.foo(), which is yet another
approach to dispatch. The design choices are endless, and one size is
unlikely to fit all: adaptation, generic/overloaded functions,
interfaces, abstract base classes (not quite the same as interfaces),
typeclasses, who knows...

The only things I clearly see at this point are:

(a) The x.foo() notation will continue to handle at least 80% of the
cases. Anything else we come up with is going to have to be satisfied
with improving the situation for the remaining 20% or less. The
mechanisms for resolving x.foo() are already extremely flexible; you
can overload __getattribute__ (there you have your mutable mro!), and
if that isn't enough you can write a metaclass. I doubt that we need
more flexibility in this area, and I doubt that we'll want to revise
the existing approach much.

(b) It would be good if we could provide a standard mechanism or
convention to handle the most common 80% of those 20% (i.e. 16% of the
total). At this point I'm not sure whether this ought to be based on
generic/overloaded functions, interfaces/abstract base classes, or
something completely different; those two are the most likely
candidates, perhaps even together.

(c) Any solution should not prevent people like Phillip Eby to
implement their own mechanisms to cover the remaining 4% of the total.
(These numbers are of course just rough indicators. :-) It would be
ideal if such mechanisms could be implemented as systematic
modifications of the standard approach (like metaclasses are), but
that's not an absolute necessity as long as there's *some* way to
implement advanced dispatch machinery.

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

From guido at python.org  Thu May 11 07:05:03 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 10 May 2006 22:05:03 -0700
Subject: [Python-3000] Allowing slice syntax in more places
In-Reply-To: <e3tl2j$e28$2@sea.gmane.org>
References: <e3tl2j$e28$2@sea.gmane.org>
Message-ID: <ca471dc20605102205t6ef06c7bq98c3545faed5ed21@mail.gmail.com>

The problem is that it's a slippery slope. I think Paul Dubois once
proposed this too, but not much came of it. Once you can write
foo(1:10), why not x = (1:10); and then why not x = 1:10. But you
can't have "if x == 1:10: ..." because the first colon would be
ambiguous. So you'd end up with even more complicated rules about when
you need to parenthesize.

In the end the problem is solvable, but the cost is considerable, and
frankly, outside Numeric (or is it NumPy now?), there isn't a lot of
demand. So you're asked to put up with slice(1, 10) instead of (1:10),
and that's not so bad.

--Guido

On 5/10/06, Travis E. Oliphant <oliphant.travis at ieee.org> wrote:
>
> I'm sorry if this has been discussed before.
>
> One of the things that is really nice about slice syntax is the ability
> to construct slice objects to pass to __getitem__  using []
>
> Would it be possible to extend the syntax so that slice syntax is
> acceptable in more places in Python?  In particular function calls would
> be a very useful addition.  Thus,
>
> myfunc(3:4:0.5, 1:5)
>
> would produce the equivalent bytecode as
>
> myfunc(slice(3,4,0.5), slice(1,5))
>
>
> -Travis
>
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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

From edcjones at comcast.net  Thu May 11 07:09:12 2006
From: edcjones at comcast.net (Edward C. Jones)
Date: Thu, 11 May 2006 01:09:12 -0400
Subject: [Python-3000] Debuggers was Re: What do do about IDLE?
In-Reply-To: <mailman.21254.1147319044.27774.python-3000@python.org>
References: <mailman.21254.1147319044.27774.python-3000@python.org>
Message-ID: <4462C6F8.6030203@comcast.net>

Talin <talin at acm.org> wrote:
 > I don't think we really need an IDE, but a debugger that is
 > at least able to show source code, call stack, and local
 > variables in a window would be extremely useful.
 >
 > So my thought is this: How hard would it be to make
 > a curses-based debugger?

For a good terminal oriented debugger, see the old Borland Debugger.

I would like to see a debugger that sees the C or C++ code in my buggy 
extension modules but does not see the internals of the Python interpreter.

From collinw at gmail.com  Thu May 11 07:17:07 2006
From: collinw at gmail.com (Collin Winter)
Date: Thu, 11 May 2006 01:17:07 -0400
Subject: [Python-3000] Questions on optional type annotations
Message-ID: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>

I haven't been able to find any mention of these things in the
python-3000 archive (nor in Bill Birch's proto-PEP on the subject
[1]). These are all issues I've encountered while writing my typecheck
package [2], which I think still need to be discussed and addressed
for py3k's proposed type annotations.

1. Will there be some way of specifying "I expect parameter B to be a
callable with signature X"? If yes, how does this affect the
optional-ness of the type annotations?

Put another way: let's say I've annotated a function using the
following Haskell-derived strawman syntax. I want the sole parameter
to be a callable that accepts two ints and returns an int:

def foo((int, int -> int)): ...

What happens if I pass foo a function that doesn't have type
annotations, ie, a function where the system can't know its parameter
and return types (for example, functions from C extension modules)? Is
a TypeError raised (ie, you're forced to supply annotations)? Does the
system simply accept the function and trust you've done the right
thing? Is the function accepted but a warning is issued?

If a TypeError is raised, do we risk heading toward C's const
propagation issues?

2. On a related note, will there be a way to add annotations to
callables in extension modules?

3. Let's say you have two classes, each of which has methods that
return instances of the other class. How do you supply type
annotations for these? One has to be written above (and hence parsed
and compiled) before the other, meaning that without some way of
deferring the lookup of the type used in the annotation, you get
NameErrors (or the equivalent in this case).

typecheck solves this in an ugly way, using a Class() utility class to
delay the lookup. Roughly translated in to BDFL syntax:

"""
class A:
   def foo(self, b_instance: B): ...

class B:
    def bar(self, a_instance: A): ...
"""

becomes

"""
class A:
   def foo(self, b_instance: Class('B')): ...

class B:
    def bar(self, a_instance: A): ...
"""

The first time we need Class('B') for typechecking purposes, some
sys._getframe hackery is used to grab the real class instance and
cache it for later. (By the way, I'd love alternative suggestions
about how to do this in current Python.)

Bill mentions converting the name of the type/interface/whatever to
later-evaluated lambdas in the case of recursive datatypes, but I
don't see any mention of generalising this idea.

4. How will tuples be treated? Some in the wider Python community
treat tuples as simple frozen lists, while others view them as a data
structures unto themselves. My question: will (0,), (0, 1) and (0, 1,
2) all match (int,) (frozen list view), or are (int,), (int, int) and
(int, int, int) totally separate datatypes (more of a functional
programming view)?

Thanks,
Collin Winter

[1] - http://billbirch.wordpress.com/2006/05/01/draft-pep-types-for-python-3000/
[2] - http://oakwinter.com/code/typecheck/

From guido at python.org  Thu May 11 07:30:03 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 10 May 2006 22:30:03 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <loom.20060509T234801-751@post.gmane.org>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
Message-ID: <ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>

[Michael Chermside]
> > I think the idea of creating a new language with some of the wonderful
> > syntax of Python along with the wonderful type system of Haskell sounds
> > GREAT! I would be very interested, and would like to join in the
> > discussion.
> >
> > But I don't think it belongs in the Python-3000 discussion group. Can
> > this discussion be moved elsewhere? Python 3.0 is going to have types,
> > and they're going to look very similar to the types in Python 2.X --
> > a brand new language would be a separate project.

[Talin]
> Ordinarily I would agree with you on this point, and in fact I
> wouldn't even bring it up at all, except for two data points:
>
> 1) The proposal to include generic function dispatch
>    in Python 3000, based on explicit typing.
>
> 2) The proposal to remove all forms of type testing
>    other than those based on isinstance() (in other words,
>    removing callable, isSequence, isMapping, etc.)
>    (I'm not including attribute testing here because its
>    neither standardized nor systematic.)

Note that these are *proposals*. IMO they are minority proposals and
I'm doubtful that they will fly as you state them here. (For example,
see my other post where I mention that generic/overloading functions
will at best be used to augment traditional class-based dispatch; they
will play a minor role at best.)

My proposal of removing callable() wasn't intended to increase the
number of isinstance() calls. Rather, it was intended to face paranoia
head-on, by saying "just call it!" And (re.sub notwithstanding) APIs
that depend on being able to distinguish between a callable and a
non-callable are usually poor API design, and should be replaced by
other approaches (like keyword arguments).

> The net effect of these proposals is to greatly strengthen
> the capabilities of explicit typing, while seriously crippling
> the use of duck typing. By putting a much greater emphasis on
> explicit typing, we're effectively moving Python away from the
> implcit "duck-typing" that we've known up to this point.
>
> So essentially Python is *already* becoming a different
> language, whether we like it or not.

You're way ahead of me here. You talk like this is a done deal. It
isn't. And in fact I am strongly *against* any kind of "accidental
paradigm shift" like this -- I'm doing my best to prevent those from
happening. (There are some *intentional* paradigm shifts planned, but
they are more about the behavior of some specific built-in types and
operations such as files, strings and mappings, than about the very
foundation of the type system.)

> I think that I agree with the gist of Tomer's point.

Well, to most of us it's far from clear what he's trying to say...

> I'm not
> going to claim that types are useless, but I think we should
> think about ways of dispatching other than types.

Maybe. Although generic/overloaded functions can easily use types
exclusively for dispatch, despite being quite a different paradigm.
(See my sample implementation in sandbox/overload/.)

> What would seem very 'Pythonic' to me would be a system
> whereby objects can not only be dispatched on their
> types but also their *capabilities*. Thus, instead
> of asking the question "Is this a sequence?", we ask
> "Can this be iterated?"

Aside: let's not use the term "capability" for this -- it is a highly
meaningful concept already in the context of security realms.

> In such a model a "sequence type" would simply be a
> set of capabilities that often occur together.

Of course there's nothing to stop us from establishing a convention
that allows one to use a single hasattr() call to test for such a
thing -- or any number of other approaches whose surface API is a
single call: isinstance(), hasattr(), implements(), all are at some
level equivalent. So there's not that much new.

> I think at the very least, we need a way a better
> definition of a "capability", and a formalized way
> to test for its presence. Whether or not that is
> directly wired into the dispatch mechanism (which would
> be cool) is another issue. Certainly attribute testing
> is part of it, but there needs to be agreement on which
> attributes to test.

I think I would encourage proposals here to come up with a lightweight
and reliable convention. It's okay to require that all sequences types
must do something specific before they will be considered to be
sequence by the new testing method -- because if we want to be able to
reliably distinguish between sequences and mappings, we're *somehow*
going to have to cut the tie. The convention should address existing
de-facto categories such as iterable, sequence, file-like, etc., and
also let users (and especially frameworks and libraries) define their
own catagories.

Bill Janssen is proposing that the specific thing a type must do is
inherit from some abstract base class.

Phillip Eby is countering that that isn't sufficient because he wants
to be able to make up his own categories and apply these to existing
types defined by 3rd party libraries.

It would be great if we had a solution that allowed either approach!

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

From tjreedy at udel.edu  Thu May 11 07:31:08 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 11 May 2006 01:31:08 -0400
Subject: [Python-3000] why interfaces shouldn't be trusted
References: <1d85506f0605101303r363a01aeuda7cd796e13182b6@mail.gmail.com>
	<ca471dc20605102200n1ab41e6dp19b88b8c7c2b29b2@mail.gmail.com>
Message-ID: <e3ui6t$svt$1@sea.gmane.org>


"Guido van Rossum" <guido at python.org> wrote in message 
news:ca471dc20605102200n1ab41e6dp19b88b8c7c2b29b2 at mail.gmail.com...
> You seem to be still under the influence of the type-safety mafia, who
> want to make you believe that with enough type-checking you can
> prevent all bugs (though they don't believe it themselves).
>
> Python already has a very useful kind of strong type safety: it tags
> all data at the lowest level so it won't be interpreted the wrong way;
> in particular it can't be tricked into dereferencing something that's
> not a pointer to an object, or calling something that's not a pointer
> to a well-behaved function. (Extensions like ctypes excluded.) Java
> makes a similar guarantee. C++ and Perl don't.

Nicely explained.  I think this paragraph should go in the tutorial if not 
already.

tjr




From talin at acm.org  Thu May 11 07:48:35 2006
From: talin at acm.org (Talin)
Date: Wed, 10 May 2006 22:48:35 -0700
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <446256F9.50507@ieee.org>
References: <loom.20060502T201105-105@post.gmane.org>	<e38g44$bfb$1@sea.gmane.org>	<44596963.8070200@canterbury.ac.nz>	<e3ga30$9sq$1@sea.gmane.org>	<e3qvqa$k6m$1@sea.gmane.org>
	<4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org>
Message-ID: <4462D033.3080202@acm.org>

Travis E. Oliphant wrote:
> In short, I don't like the chaining effect of wrapper on top of wrapper. 
>   I want to make the connection to platform libraries as simple as 
> possible.   Ultimately, I also think PyGUI should provide a simple 
> look-and-feel of its own as well for situations where there is no 
> "platform" look and feel (i.e. Unix users without either KDE or GNOME 
> and just X11 or some other windowing environment).

Normally, I would agree with you about eliminating "needless 
wrapperism". However, GUIs are one of the few areas where wrappers tend 
to have a fairly small performance impact. The reason for this is 
because the underlying native code is doing most of the heavy lifting, 
and the wrappers are only the tip of the iceberg. Typically, the wrapper 
code only gets run when the user actually does something, like click a 
mouse button; The rest of the time its all native code.

-- Talin

From guido at python.org  Thu May 11 07:50:41 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 10 May 2006 22:50:41 -0700
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>
Message-ID: <ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>

On 5/10/06, Collin Winter <collinw at gmail.com> wrote:
> I haven't been able to find any mention of these things in the
> python-3000 archive (nor in Bill Birch's proto-PEP on the subject
> [1]). These are all issues I've encountered while writing my typecheck
> package [2], which I think still need to be discussed and addressed
> for py3k's proposed type annotations.
>
> 1. Will there be some way of specifying "I expect parameter B to be a
> callable with signature X"? If yes, how does this affect the
> optional-ness of the type annotations?
>
> Put another way: let's say I've annotated a function using the
> following Haskell-derived strawman syntax. I want the sole parameter
> to be a callable that accepts two ints and returns an int:
>
> def foo((int, int -> int)): ...
>
> What happens if I pass foo a function that doesn't have type
> annotations, ie, a function where the system can't know its parameter
> and return types (for example, functions from C extension modules)? Is
> a TypeError raised (ie, you're forced to supply annotations)? Does the
> system simply accept the function and trust you've done the right
> thing? Is the function accepted but a warning is issued?
>
> If a TypeError is raised, do we risk heading toward C's const
> propagation issues?

Well, remember that the default use of type annotations is to ignore
them! You can write your own decorator that implements a specific
interpretation of the annotations, and you can make it do anything you
like.

I think it would be useful to have a notation that can express
signatures. I haven't spent much time thinking about what this would
look like, but I'd like it to require no new syntax beyond the concept
of type annotations. If this means you can't have the inline
equivalent of your (int int -> int), then perhaps it could be done by
referencing some prototype with the appropriate annotations. Or
perhaps someting as crude as Function(type, type, ..., returns=type)
would be good enough for inlining this.

Regarding the question what to do if something un-annotated is passed,
you could have a strict and a lenient mode, sort of the equivalents of
guilty-unless-proven-innocent and innocent-unless-proven-guilty. I
guess the latter is more Pythonic, but the former is more in style
with type checking systems... :-)

> 2. On a related note, will there be a way to add annotations to
> callables in extension modules?

It makes sense to allow this. We already allow the C code to specify a
doc string; I think it makes sense to also specify a signature.

> 3. Let's say you have two classes, each of which has methods that
> return instances of the other class. How do you supply type
> annotations for these? One has to be written above (and hence parsed
> and compiled) before the other, meaning that without some way of
> deferring the lookup of the type used in the annotation, you get
> NameErrors (or the equivalent in this case).

Good question. I'm glad you're thinking about these issues; I hope
you're working on a PEP (I'm losing track of these things since I'm
only able to spend the occasional two-hour session looking at Py3k
lately).

> typecheck solves this in an ugly way, using a Class() utility class to
> delay the lookup. Roughly translated in to BDFL syntax:
>
> """
> class A:
>    def foo(self, b_instance: B): ...
>
> class B:
>     def bar(self, a_instance: A): ...
> """
>
> becomes
>
> """
> class A:
>    def foo(self, b_instance: Class('B')): ...
>
> class B:
>     def bar(self, a_instance: A): ...
> """
>
> The first time we need Class('B') for typechecking purposes, some
> sys._getframe hackery is used to grab the real class instance and
> cache it for later. (By the way, I'd love alternative suggestions
> about how to do this in current Python.)

Instead of getframe, the argument to Class() could be a fully
qualified name: package.subpackage.module.class.

> Bill mentions converting the name of the type/interface/whatever to
> later-evaluated lambdas in the case of recursive datatypes, but I
> don't see any mention of generalising this idea.

Well, *some* kind of hack will be needed given the decision (which I
don't want to revert just yet) that the expression is a plain standard
expression that's evaluated at function-definition time.

If there's no other use for lambdas in the type notation, then you
could safely spell a forward reference to B as lambda: B. (This
appears to ironically require the use of callable(), which in a
different thread I'm still trying to ban; but since a class is also
callable, callable() would actually be useless here, and we could
instead dispatch specifically on the defining characteristics of
lambdas: it has type 'function' and name "<lambda>". )

> 4. How will tuples be treated? Some in the wider Python community
> treat tuples as simple frozen lists, while others view them as a data
> structures unto themselves. My question: will (0,), (0, 1) and (0, 1,
> 2) all match (int,) (frozen list view), or are (int,), (int, int) and
> (int, int, int) totally separate datatypes (more of a functional
> programming view)?

This I actually covered in last year's blog entries; I believe my
notation was tuple[int, int, str] to indicate a three-tuple containing
two ints and a str, forcing the "data structure" interpretation. If
you want to accept tuples but interpret them as sequences, you should
declare your argument as Sequence[some_type].

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

From guido at python.org  Thu May 11 08:01:09 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 10 May 2006 23:01:09 -0700
Subject: [Python-3000] Debuggers was Re: What do do about IDLE?
In-Reply-To: <4462C6F8.6030203@comcast.net>
References: <mailman.21254.1147319044.27774.python-3000@python.org>
	<4462C6F8.6030203@comcast.net>
Message-ID: <ca471dc20605102301v1a6ae550obb4bc01be2cde01a@mail.gmail.com>

On 5/10/06, Edward C. Jones <edcjones at comcast.net> wrote:
> Talin <talin at acm.org> wrote:
>  > I don't think we really need an IDE, but a debugger that is
>  > at least able to show source code, call stack, and local
>  > variables in a window would be extremely useful.
>  >
>  > So my thought is this: How hard would it be to make
>  > a curses-based debugger?
>
> For a good terminal oriented debugger, see the old Borland Debugger.
>
> I would like to see a debugger that sees the C or C++ code in my buggy
> extension modules but does not see the internals of the Python interpreter.

I don't know the Borland debugger, and I consider a cross-language
debugger (while useful) rather out of scope and also rather unlikely
to happen.

But I think there's something very useful in this area that we ought
to implement. It's not strictly a py3k thing, but probably requires
sufficient forethought that we might as well build it for py3k first.
This is a standard remote debugging API. I think that one of the
challenges here is to factor it so that the actual RPC mechanism used
is independent from the rest of the API; that seems necessary because,
if successful, the mechanism must be usable by every Python-capable
IDE, and they all have their own RPC already. It *must* be capable to
be run over a unix-domain socket or a localhost TCP connection. But
the same API should also be usable (and be implementable efficiently,
preferably without serializing+deserializing) for use by a traditional
in-process local debugger.

Every IDE developer realizes this is needed, realizes that it doesn't
exist, realizes that there's no time to sit down and do it right,
sighs, and hacks something together that is uniqe and exclusive to the
requirements of that IDE's debugger. This is wasted time and we should
be able to do better if we plan it right.

Anybody?

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

From nnorwitz at gmail.com  Thu May 11 08:22:13 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Wed, 10 May 2006 23:22:13 -0700
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>
	<ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
Message-ID: <ee2a432c0605102322x5834898dk2a60c7ad72640e6e@mail.gmail.com>

On 5/10/06, Guido van Rossum <guido at python.org> wrote:
>
> Regarding the question what to do if something un-annotated is passed,
> you could have a strict and a lenient mode, sort of the equivalents of
> guilty-unless-proven-innocent and innocent-unless-proven-guilty. I
> guess the latter is more Pythonic, but the former is more in style
> with type checking systems... :-)

I agree with this approach.

> > 2. On a related note, will there be a way to add annotations to
> > callables in extension modules?
>
> It makes sense to allow this. We already allow the C code to specify a
> doc string; I think it makes sense to also specify a signature.

Another benefit of this is the ability to get more info through
introspection.  Right now, you can't even find the number of arguments
of a function implemented in C.  You only know if it takes 0, 1, or
variable # of arguments and if it accepts keywords.

I have a patch that allows specifying the actual # of arguments, but
that was for for performance and didn't provide any signature info.
You could hoist the values passed to PyArgs_ParseTuple into the
PyMethodDef, but there are problems with that.  Some signatures can't
be expressed in a single string passed to ParseTuple.  Another thing
is that the function definition isn't normally close to the
PyMethodDef entry.  That can be a maintenance problem.  I don't know
how to solve these problems.

n

From talin at acm.org  Thu May 11 08:30:15 2006
From: talin at acm.org (Talin)
Date: Wed, 10 May 2006 23:30:15 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>	
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
Message-ID: <4462D9F7.6040605@acm.org>

Guido van Rossum wrote:
> [Talin]
> 
>> Ordinarily I would agree with you on this point, and in fact I
>> wouldn't even bring it up at all, except for two data points:
>>
>> 1) The proposal to include generic function dispatch
>>    in Python 3000, based on explicit typing.
>>
>> 2) The proposal to remove all forms of type testing
>>    other than those based on isinstance() (in other words,
>>    removing callable, isSequence, isMapping, etc.)
>>    (I'm not including attribute testing here because its
>>    neither standardized nor systematic.)
> 
> 
> Note that these are *proposals*. IMO they are minority proposals and
> I'm doubtful that they will fly as you state them here. (For example,
> see my other post where I mention that generic/overloading functions
> will at best be used to augment traditional class-based dispatch; they
> will play a minor role at best.)

OK. I admit that much of the motivation for those statements is not 
about what you've stated, but a reaction to some of the statements that 
have been made on this list.

> My proposal of removing callable() wasn't intended to increase the
> number of isinstance() calls. Rather, it was intended to face paranoia
> head-on, by saying "just call it!" And (re.sub notwithstanding) APIs
> that depend on being able to distinguish between a callable and a
> non-callable are usually poor API design, and should be replaced by
> other approaches (like keyword arguments).

While it may be true that these are "usually" poor API design, I have 
provided several examples of popular, well-known and well-respected 
Python libraries that use exactly this feature, and for which simply 
calling and catching the exception is not an effective substitute.

I also feel that one can only judge design quality in context, 
specifically designs that would be considered "poor" for Java or C++ may 
be perfectly reasonable for Python. There are a lot of Python APIs that 
have a kind of "do what I mean" quality to them, and I don't see that as 
bad style per se; What *is* bad style is unpredictability and surprise.
A DWIM API can be well designed if the internal behavior exactly matches 
the average user's preconcieved expectations.

> You're way ahead of me here. You talk like this is a done deal. It
> isn't. And in fact I am strongly *against* any kind of "accidental
> paradigm shift" like this -- I'm doing my best to prevent those from
> happening. (There are some *intentional* paradigm shifts planned, but
> they are more about the behavior of some specific built-in types and
> operations such as files, strings and mappings, than about the very
> foundation of the type system.)

OK. I think where Phillip and I are headed is that we see the current 
paradigm as incomplete. I would like to see a system in which explicit 
typing and duck typing are both fully realized, and neither is "second 
class" as compared to the other.

While I think generic functions are cool, the discussion of how to 
design criteria for testing vs. duck types is something that ought to be 
dealt with regardless.

>> I think that I agree with the gist of Tomer's point.
> 
> Well, to most of us it's far from clear what he's trying to say...

Well, I won't claim to speak for him directly. But its well known that 
hierarchical type systems have limitations.

I wrote an article on Advogato a long time ago called "The Platypus 
Effect", which talks about how you have all your nice taxonomies set up, 
you know, mammals are the ones with fur and live birth, reptiles and 
birds lay eggs, and so on - and then along comes a platypus, a 
duck-billed, egg-laying, fur-bearing annoyance, which just *doesn't fit* 
anywhere in your scheme. And you can't just "patch" your taxonomy 
either, you end up having to refactor the whole thing.

> Maybe. Although generic/overloaded functions can easily use types
> Of course there's nothing to stop us from establishing a convention
> that allows one to use a single hasattr() call to test for such a
> thing -- or any number of other approaches whose surface API is a
> single call: isinstance(), hasattr(), implements(), all are at some
> level equivalent. So there's not that much new.
 >
> I think I would encourage proposals here to come up with a lightweight
> and reliable convention. It's okay to require that all sequences types
> must do something specific before they will be considered to be
> sequence by the new testing method -- because if we want to be able to
> reliably distinguish between sequences and mappings, we're *somehow*
> going to have to cut the tie. The convention should address existing
> de-facto categories such as iterable, sequence, file-like, etc., and
> also let users (and especially frameworks and libraries) define their
> own catagories.

I've been thinking about this quite a bit. What about a hierarchy of 
"concepts" that looks like this:

iterable:
    -- An item that can be iterated
    -- Test: hasattr( __iter__ )

bounded_iterable( iterable ):
    -- an iterable whose end is predictable in advance
    -- Test: iterable() + hasattr( __len__ )

indexable( bounded_iterable ):
    -- an iterable that allows random access to its elements
    -- Test: bounded_iterable() + hasattr( __getitem__ )

sequence( indexable ):
    -- an indexable in which the indexes are successive integers
    -- Test: isinstance( index_type, int )

mapping( indexable ):
    -- an indexable in which the indices are hashable values:
    -- Test: hashable( index_type )
    -- (Also test for immutable if its feasible)

So if all you want to do is iterate over an item, you don't test to see 
if its a sequence, you test to see if its iterable. And because you want 
to define your API in such a way as to eliminate surprise, you can use 
the term "iterable" so that everyone knows what you mean. In other 
words, if my function does one thing when passed an iterable, and 
something else when passed a non-iterable, the programmer can then know 
exactly what will happen when they pass their own data type in.

> Bill Janssen is proposing that the specific thing a type must do is
> inherit from some abstract base class.
> 
> Phillip Eby is countering that that isn't sufficient because he wants
> to be able to make up his own categories and apply these to existing
> types defined by 3rd party libraries.
> 
> It would be great if we had a solution that allowed either approach!

Yes indeed.

-- Talin

From talin at acm.org  Thu May 11 08:33:09 2006
From: talin at acm.org (Talin)
Date: Wed, 10 May 2006 23:33:09 -0700
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>
	<ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
Message-ID: <4462DAA5.9040104@acm.org>

Guido van Rossum wrote:
> I think it would be useful to have a notation that can express
> signatures. I haven't spent much time thinking about what this would
> look like, but I'd like it to require no new syntax beyond the concept
> of type annotations. If this means you can't have the inline
> equivalent of your (int int -> int), then perhaps it could be done by
> referencing some prototype with the appropriate annotations. Or
> perhaps someting as crude as Function(type, type, ..., returns=type)
> would be good enough for inlining this.

I haven't forgotten that you asked me to write up a PEP for a signature 
API in conjunction with the keyword arguments PEP. However, I don't yet 
feel that the ideas have gelled enough to do so yet -- or at least, I 
don't feel competent to come up with a definative solution.

-- Talin

From jcarlson at uci.edu  Thu May 11 08:37:49 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 10 May 2006 23:37:49 -0700
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <055601c67484$a8898e10$bf03030a@trilan>
References: <20060510150405.6800.JCARLSON@uci.edu>
	<055601c67484$a8898e10$bf03030a@trilan>
Message-ID: <20060510225827.6809.JCARLSON@uci.edu>


"Giovanni Bajo" <rasky at develer.com> wrote:
> It's sufficient to show that a library that uses native widget has to go
> through many hoops to implement any slightly non-standard feature. And
> causes the mental overhead which makes it unpythonic.

I would disagree.

The fact that it can be done, in spite of the fact that the underlying
controls do not offer such functionality, says quite a bit about
wxPython's wrapping of native controls.  The fact that /in this
particular case/ a few hoops need to be jumped through, is a bit of a
red herring; now that I've described how to get Qt-like behavior in
wxPython, what about getting a tree control in a ComboBox?  In the
wxPython case, it's already done...

Further, calling the composition of custom widgets to fit a desired
functionality "mental overhead" and "unpythonic", is a naive way of
saying "custom controls aren't worth making because you have to think to
make them".  Using your logic, making the Firefox Download Manager
entries would be too much "mental overhead" and would be "unpythonic" if
it were to be done in a Python application.  I call bollocks.


> Compare this with PyQt. You create a QComboBox (you wanted a combobox), and
> you can set a text and/or a pixmap for each item, using self.insertItem(px,
> txt).

So you are saying: because PyQt previously designed and implemented this
particular variant of a combobox (with images), it proves that going
non-native is better?  No, it just proves that this variant of the
ComboBox in PyQt was designed with this particular feature in mind.

Similarly, just because someone has spent the time to embed a
TreeControl in a dropdown for wxPython, doesn't necessarily mean that
wxPython is more flexible in this regard.


A slightly better question than what you originally asked for with both
PyQt, PyGtk, wxPython, PyGUI, etc., is how easy is it to customize
controls, mix/match controls, etc.?  I only have experience with
wxPython, but in my experience, it is trivial to create almost any
composite control that I can (and have) imagined (even a Firefox
Download Manager-like widget).


> Qt can export a much better, friendly and well-designed API because it
> doesn't rely on native widgets. It draws the widgets itself, so they always
> have the very same features for all the platforms that Qt supports. For
> instance, the other day I shrinked a horizontal scrollbar in the vertical
> direction (make it look "smaller"). It worked immediately for Windows, Mac
> and Linux. I don't think Windows can have a "smaller" scrollbar at all, for
> instance, at least not without adjusting its theme.

Having identical behavior on all platforms is wonderful, I'm very happy
for you and everyone else with a toolkit (programming language, etc.) that
does the same. For the rest of us who cannot use PyQt for one reason or
another (licensing...), we must rely on non-Qt tools, and as such, are
likely going to have to deal with wrapped native controls.  Yeah,
dealing with platform-specific crap isn't ideal, but it's not unique to
GUI toolkits, and it's certainly not a stranger to Python.


 - Josiah


From talin at acm.org  Thu May 11 08:45:53 2006
From: talin at acm.org (Talin)
Date: Wed, 10 May 2006 23:45:53 -0700
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <20060510225827.6809.JCARLSON@uci.edu>
References: <20060510150405.6800.JCARLSON@uci.edu>	<055601c67484$a8898e10$bf03030a@trilan>
	<20060510225827.6809.JCARLSON@uci.edu>
Message-ID: <4462DDA1.8040201@acm.org>

Josiah Carlson wrote:
> Having identical behavior on all platforms is wonderful, I'm very happy
> for you and everyone else with a toolkit (programming language, etc.) that
> does the same. For the rest of us who cannot use PyQt for one reason or
> another (licensing...), we must rely on non-Qt tools, and as such, are
> likely going to have to deal with wrapped native controls.  Yeah,
> dealing with platform-specific crap isn't ideal, but it's not unique to
> GUI toolkits, and it's certainly not a stranger to Python.

What's the problem with licensing? Qt is GPL'd on Windows, Linux/Unix 
and OS X. The old QPL license is officially deprecated; any licensing 
problems with Qt are old news, as far as I can tell by looking at their 
web site:

   http://www.trolltech.com/products/qt/licenses/licensing/opensource

And nothing prevents you from porting it to any other platform, except 
that TrollTech won't help you do it :)

-- Talin

From ronaldoussoren at mac.com  Thu May 11 10:10:20 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 11 May 2006 10:10:20 +0200
Subject: [Python-3000] GUI -- an API, not a toolkit
In-Reply-To: <4462DDA1.8040201@acm.org>
References: <20060510150405.6800.JCARLSON@uci.edu>
	<055601c67484$a8898e10$bf03030a@trilan>
	<20060510225827.6809.JCARLSON@uci.edu> <4462DDA1.8040201@acm.org>
Message-ID: <68A64CF2-31AB-42F9-9C54-762DDB735A46@mac.com>


On 11-mei-2006, at 8:45, Talin wrote:

> Josiah Carlson wrote:
>> Having identical behavior on all platforms is wonderful, I'm very  
>> happy
>> for you and everyone else with a toolkit (programming language,  
>> etc.) that
>> does the same. For the rest of us who cannot use PyQt for one  
>> reason or
>> another (licensing...), we must rely on non-Qt tools, and as such,  
>> are
>> likely going to have to deal with wrapped native controls.  Yeah,
>> dealing with platform-specific crap isn't ideal, but it's not  
>> unique to
>> GUI toolkits, and it's certainly not a stranger to Python.
>
> What's the problem with licensing? Qt is GPL'd on Windows, Linux/Unix
> and OS X.

That's the problem with Qt :-). Python's license is compatible with  
the GPL, but none of the code in the standard library is GPL  
licensed.  I'd also be -lots of including GPL'd code in the standard  
library, that would make it much to easy to accidently "contaminate"  
my own code.

Ronald


From Ben.Young at risk.sungard.com  Thu May 11 11:12:57 2006
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Thu, 11 May 2006 10:12:57 +0100
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <5.1.1.6.0.20060510123134.01e68008@mail.telecommunity.com>
Message-ID: <OFAAD257E5.1BE6EEBB-ON8025716B.0031E412-8025716B.00329FE2@risk.sungard.com>

python-3000-bounces+python=theyoungfamily.co.uk at python.org wrote on 
10/05/2006 17:39:57:

> At 11:21 AM 5/10/2006 +0100, Ben.Young at risk.sungard.com wrote:
> >Have you taken a look at ConceptGCC? (
> >http://www.osl.iu.edu/~dgregor/ConceptGCC/)
> >
> >It's basically a first cut at implementing the Concepts which will be
> >availiable in the next version of C++. They basically provide full 
compile
> >time "duck typing" as well as adaptation for types that don't exactly 
fit
> >the concept. (e.g if the type doesn't have a length method, here's how 
you
> >provide it.
> >
> >It's a very powerfull idea, and probably well worth looking at for
> >inspiration.
> 
> FWIW, I skimmed through the tutorial; it appears that a "Concept" is 
> roughly equivalent to a typeclass in Haskell, and a "Model" is roughly 
> equivalent to a typeclass instance

Hi Phillip,

I don't know much about Haskell, but this sounds roughly right. As I 
understand it, a Concept describes what interface/capabilties a type 
should have, while a Model describes a mapping of types onto Concepts for 
types that don't fit automatically.

For instance, a Model can be used to give all raw pointer types a 
value_type typedef member to allow them to fit the Iterator Concept.

> 
> One of the papers on the site mentions something called "concept-based 
> overloading", which if I'm reading it correctly, is the idea that's at 
the 
> heart of this thread; i.e., it should be possible to say that a 
particular 
> implementation of one operation is dependent upon the availability of an 

> implementation of some other operation.
> 

Yes, C++ previously had compilicated ways of "overloading" template 
implementations based on things like boosts enable_if (you don't want to 
know!), but Concepts allow this to be done in a clear and obvious way.

A dynamic version of concepts (I guess a combo of multi-methods and 
adaptation) would be great for Python, but it's hard to see how it could 
be done simply and efficiently.

Cheers,
Ben

> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.
> org/mailman/options/python-3000/python%40theyoungfamily.co.uk
> 


From krstic at fas.harvard.edu  Thu May 11 11:29:19 2006
From: krstic at fas.harvard.edu (Ivan Krstic)
Date: Thu, 11 May 2006 05:29:19 -0400
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: <06May9.185337pdt."58641"@synergy1.parc.xerox.com>
References: <06May9.185337pdt."58641"@synergy1.parc.xerox.com>
Message-ID: <446303EF.6090604@fas.harvard.edu>

Bill Janssen wrote:
>> to want to task a general GUI toolkit with producing
>> HTML and Javascript, running a HTTP server, and automagically dealing
>> with all the server-side logic seems a bit like a really bad joke.
> 
> You've never looked at X11 under the covers (it looks like Mac OS X's
> window system is very similar).

As a response to my comment, this seems so far off mark that I'm not
sure how to respond. In any case, it's not very pertinent to the current
discussion; if there are compelling reasons, we can continue to talk
about it off-list.

-- 
Ivan Krstic <krstic at fas.harvard.edu> | GPG: 0x147C722D

From ncoghlan at gmail.com  Thu May 11 14:24:03 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 11 May 2006 22:24:03 +1000
Subject: [Python-3000] why interfaces shouldn't be trusted
In-Reply-To: <87y7x9ab47.fsf@qrnik.zagroda>
References: <1d85506f0605101303r363a01aeuda7cd796e13182b6@mail.gmail.com>
	<87y7x9ab47.fsf@qrnik.zagroda>
Message-ID: <44632CE3.6050205@gmail.com>

Marcin 'Qrczak' Kowalczyk wrote:
> "tomer filiba" <tomerfiliba at gmail.com> writes:
> 
>> one thing that worries me with generic methods is, they would
>> dispatch based on types... which means my proxies would all break.
>> please, think of the proxies! ;)
> 
> OTOH proxies generated by my Python<->Kogut bridge would break if
> hasattr was used to determine interfaces. For example if obj is a
> Kogut object wrapped in a Python object, then obj.__iter__ always
> succeeds, but calling the resulting function fails if the underlying
> object doesn't actually support iteration.
> 
> (Types aren't currently reflected either, so type-based interface
> discovery would fail too, but I plan to change that.)

When you change type-based checks to work, you can make the rest of the slots 
work properly too by generating wrapper types on the fly (i.e., generator a 
type proxy as well as an instance proxy - you can use a type proxy cache do 
avoid creating new ones all the time).

Cheers,
Nick.



-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From birchb at tpg.com.au  Thu May 11 14:45:32 2006
From: birchb at tpg.com.au (Bill Birch)
Date: Thu, 11 May 2006 22:45:32 +1000
Subject: [Python-3000] Argument Decorators (was Re: my take on "typeclasses")
In-Reply-To: <ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
Message-ID: <200605112245.33367.birchb@tpg.com.au>

On Thu, 11 May 2006 03:30 pm, Guido van Rossum wrote:

>
> Bill Janssen is proposing that the specific thing a type must do is
> inherit from some abstract base class.
>
> Phillip Eby is countering that that isn't sufficient because he wants
> to be able to make up his own categories and apply these to existing
> types defined by 3rd party libraries.
>
> It would be great if we had a solution that allowed either approach!
Sorry if the following has already been suggested, almost everything has:

Perhaps is we refactor the compiler-generation of annotations slightly so that 
the Type is responsable for handling the annotation, then developers can 
implement their own approaches? Given the blog [1] code:

def foo(x: t1, y: t2) -> t3:
    ...body...

# is more or less equivalent to this:

def foo__(x, y):  # original function
    ...body...

def foo(x, y):    # wrapper function
    x = adapt(x, t1)
    y = adapt(y, t2)
    r = foo__(x, y)
    return adapt(r, t3)

Refactored to push adapt into the type:

def foo(x, y):    # wrapper function
    x = t1.adapt(x)
    y = t2.adapt(y)
    r = foo__(x, y)
    return t3.adapt(r)

Refactor again because even adapt is now in the types. 

def foo(x, y):    # wrapper function
    x = t1.decorateArg(x)
    y = t2.decorateArg(y)
    r = foo__(x, y)
    return t3.decorateReturn(r)

Every Type has decorateArg and decorateReturn methods. They would be different 
for contravariance and covarience reasons. The Python standard types would 
behave as 80% of people expect, whatever that is.  People with particular 
ideas about types would supply their own type classes.  i.e.

   def foo(x: StrictlyT1, y: StrictlyT2) ->StrictlyT3:   # Java fans ;-)
      ...
 
   def foo(x: AdaptT1, y: AdaptT2) ->AdaptT3:  # For fans of PEP 246
     ...

So a library might supply its own type classes consistent with the library 
authors' requirements.

Again, sorry if this is old hat.


----------------References: 
[1] http://www.artima.com/weblogs/viewpost.jsp?thread=87182


From ncoghlan at gmail.com  Thu May 11 14:50:54 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 11 May 2006 22:50:54 +1000
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <4462DAA5.9040104@acm.org>
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>	<ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
	<4462DAA5.9040104@acm.org>
Message-ID: <4463332E.8000107@gmail.com>

Talin wrote:
> Guido van Rossum wrote:
>> I think it would be useful to have a notation that can express
>> signatures. I haven't spent much time thinking about what this would
>> look like, but I'd like it to require no new syntax beyond the concept
>> of type annotations. If this means you can't have the inline
>> equivalent of your (int int -> int), then perhaps it could be done by
>> referencing some prototype with the appropriate annotations. Or
>> perhaps someting as crude as Function(type, type, ..., returns=type)
>> would be good enough for inlining this.
> 
> I haven't forgotten that you asked me to write up a PEP for a signature 
> API in conjunction with the keyword arguments PEP. However, I don't yet 
> feel that the ideas have gelled enough to do so yet -- or at least, I 
> don't feel competent to come up with a definative solution.

The first draft doesn't have to be definitive :)

However, being able to create a signature object independently of a def 
statement is definitely something that should be in there - we'll need it for 
annotating C methods anyway, so it may make sense to start with that, and then 
look at making it an integral part of the function header afterwards.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From qrczak at knm.org.pl  Thu May 11 16:41:05 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Thu, 11 May 2006 16:41:05 +0200
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <ee2a432c0605102322x5834898dk2a60c7ad72640e6e@mail.gmail.com>
	(Neal Norwitz's message of "Wed, 10 May 2006 23:22:13 -0700")
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>
	<ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
	<ee2a432c0605102322x5834898dk2a60c7ad72640e6e@mail.gmail.com>
Message-ID: <878xp8k4ji.fsf@qrnik.zagroda>

"Neal Norwitz" <nnorwitz at gmail.com> writes:

> Another benefit of this is the ability to get more info through
> introspection. Right now, you can't even find the number of
> arguments of a function implemented in C. You only know if it takes
> 0, 1, or variable # of arguments and if it accepts keywords.

This would be incompatible with generic proxies.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From qrczak at knm.org.pl  Thu May 11 16:49:43 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Thu, 11 May 2006 16:49:43 +0200
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <4462D9F7.6040605@acm.org> (talin@acm.org's message of "Wed, 10
	May 2006 23:30:15 -0700")
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
	<4462D9F7.6040605@acm.org>
Message-ID: <874pzwk454.fsf@qrnik.zagroda>

Talin <talin at acm.org> writes:

> sequence( indexable ):
>     -- an indexable in which the indexes are successive integers
>     -- Test: isinstance( index_type, int )

I don't understand. How would this test distinguish [] being a
sequence from {} not being a sequence?

> mapping( indexable ):
>     -- an indexable in which the indices are hashable values:
>     -- Test: hashable( index_type )
>     -- (Also test for immutable if its feasible)

And this on the contrary?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From pje at telecommunity.com  Thu May 11 17:09:47 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 11 May 2006 11:09:47 -0400
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <OFAAD257E5.1BE6EEBB-ON8025716B.0031E412-8025716B.00329FE2@
	risk.sungard.com>
References: <5.1.1.6.0.20060510123134.01e68008@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>

At 10:12 AM 5/11/2006 +0100, Ben.Young at risk.sungard.com wrote:
>A dynamic version of concepts (I guess a combo of multi-methods and
>adaptation) would be great for Python, but it's hard to see how it could
>be done simply and efficiently.

Go back and read the post where I explained how, then.  ;)

Seriously, it can be done as a pretty straightforward refactoring of 
Guido's existing overloaded function implementation.  You just need to be 
able to pass in objects other than classes to define a signature.

But I suppose maybe it's one of those things that's only obvious and 
straightforward to me, so I'll have to see if I can carve out some time 
this weekend to implement a demo.

The harder problem is having a way to define overloaded methods that's at 
least as convenient as 'def __iter__(self):' -- but that's a syntax issue.

It seems to me, however, that having something like a 'defop' keyword would 
do the trick, if you also had argument types.  So if you were implementing 
UserList or UserDict, you could have some code like this in the class body:

     defop len(self):
         return len(self.data)

     defop iter(self):
         return iter(self.data)

     defop operator.getitem(self, key):
         return self.data[key]

The idea here is that defop takes an *expression* (actually just a dotted 
name, like decorators) before the parentheses, that is the function to 
overload, rather than the *name* that the defined function is to be bound 
to.  (i.e., the code above would need to have done an 'import operator' so 
that operator.getitem is available)

Of course, this approach would give overloaded functions a much more 
central place in things, and Guido's just said that's out, so this may be 
moot.  I'm only showing this example because I think getting rid of 
__magic_names__ for operations could be a good thing for readability, and 
it would remove an element of "magic" from today's Python.

The trickiest part of implementing this is that you have to implicitly use 
the enclosing class as the signature type for the 'self' argument, which 
could be a PITA to implement.   RuleDispatch actually does this trick by 
decorating the class on the fly and delaying the method addition until the 
class is created, so it's certainly possible to do it, even without 
language support.

Anyway, the idea is pretty much moot unless Guido becomes a lot more fond 
of generic functions than he is currently -- i.e., fond enough to expend a 
keyword on them, make all the __methods__ go away, and also implement his 
type signature proposal.  That *would* be a paradigm shift, albeit one that 
I doubt many Python users would seriously object to.

For one thing, "defop iter" is two less keystrokes than "def __iter__" and 
involves less use of the shift key.  ;)  For another, the idea of operator 
overloading (hm, there's that word again) is pretty well established in 
other languages, so it's easy to teach to experienced programmers and makes 
Python seem more attractive.

Of course, it's slightly more keystrokes for operator.add and other 
operations that aren't builtins.  And we'd have to either add an 
'operator.radd', or else do something like:

     defop operator.add(self, other):
          # code for adding an ob of this class to anything

     defop operator.add(other:object, self:class):
          # code to add something to this class

This assumes that you can use the 'class' keyword in an argument definition 
to refer to the enclosing class; if you don't have that, then you would 
have to do the definition outside the class in order to refer to it by name.

Anyway, I think that this is a paradigm shift that would actually increase 
the language's beauty and clarity, because then the __magic__ names would 
only be for *data*, like __file__, __name__, __class__, __dict__, etc.

To really make it work "all the way down", however, we'd have to implement 
the builtin generic functions in such a way that they still use type slots 
and magic attributes "under the hood", at least transitionally, because 
there's all the C code that uses them and there would also be a performance 
hit to doing a dictionary lookup whenever you want to use len() or iter(), 
even at C level.  So 'defop' would need to be defined in such a way that it 
asks the generic function to register the implementation, and "builtin 
generic functions" would do their registration by modifying the class's 
tp_* slots.

And if both these "builtin" and "user" generic functions were able to be 
queried by type, you could get access to type slot values without having to 
expose them as gettable magic attribute names...

We would have to effectively add operator.next(), operator.enter() and 
operator.exit() to get rid of most of the remaining magic names, but that's 
not a big deal.

This is the first half of what I'd propose for such a paradigm shift; the 
second half is specific to how the adaptation/typeclass stuff would work, 
so I won't bother with explaining any of it unless Guido shows some 
interest in this part; if he doesn't like the above, he's not going to be 
convinced by how neat the solution for the rest is.  ;)


From Ben.Young at risk.sungard.com  Thu May 11 17:27:15 2006
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Thu, 11 May 2006 16:27:15 +0100
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
Message-ID: <OF85780877.84AC848F-ON8025716B.005481EF-8025716B.0054E474@risk.sungard.com>

"Phillip J. Eby" <pje at telecommunity.com> wrote on 11/05/2006 16:09:47:

> At 10:12 AM 5/11/2006 +0100, Ben.Young at risk.sungard.com wrote:
> >A dynamic version of concepts (I guess a combo of multi-methods and
> >adaptation) would be great for Python, but it's hard to see how it 
could
> >be done simply and efficiently.
> 
> Go back and read the post where I explained how, then.  ;)
> 
> Seriously, it can be done as a pretty straightforward refactoring of 
> Guido's existing overloaded function implementation.  You just need to 
be 
> able to pass in objects other than classes to define a signature.
> 
> But I suppose maybe it's one of those things that's only obvious and 
> straightforward to me, so I'll have to see if I can carve out some time 
> this weekend to implement a demo.
> 
> The harder problem is having a way to define overloaded methods that's 
at 
> least as convenient as 'def __iter__(self):' -- but that's a syntax 
issue.
> 
> It seems to me, however, that having something like a 'defop' keyword 
would 
> do the trick, if you also had argument types.  So if you were 
implementing 
> UserList or UserDict, you could have some code like this in the class 
body:
> 
>      defop len(self):
>          return len(self.data)
> 
>      defop iter(self):
>          return iter(self.data)
> 
>      defop operator.getitem(self, key):
>          return self.data[key]
> 

Why not

class Foo(object):
        @specialize(arg(0))
        def core.len(self)
                ...


I think this is somewhat how PyPy specializes some of its methods (modulo 
syntax)

I don't know how this would appear in the class dict though? self.len()?

Cheers,
Ben



From p.f.moore at gmail.com  Thu May 11 17:36:14 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 11 May 2006 16:36:14 +0100
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <200605112306.02574.birchb@tpg.com.au>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<200605102334.31944.birchb@tpg.com.au>
	<79990c6b0605100738m4d8fc456g43e5644419b4c5cf@mail.gmail.com>
	<200605112306.02574.birchb@tpg.com.au>
Message-ID: <79990c6b0605110836j7af1949bmbd8e452fa9dd06e9@mail.gmail.com>

On 5/11/06, Bill Birch <birchb at tpg.com.au> wrote:
> On Thu, 11 May 2006 12:38 am, you wrote:
> > On 5/10/06, Bill Birch <birchb at tpg.com.au> wrote:
> > > A simple test to see where your thinking is at. Consider:
[...]
> > Clearly False - D() is not an object of type I1.
> >
> > Of course, whether isinstance() is actually a useful way of checking
> > depends on what you're trying to discover. It's very rare that I'd
> > care about the actual class inheritance structure of an object. What I
> > care about is whether I can *use* it like an I1. And that's not
> > decidable (it includes semantic considerations), so no builtin can
> > answer that question for me.
> >
> > Hence, I document my expectations, and trust my caller to follow the
> > documentation. We're all consenting adults, and all that... (Note:
> > This is ideal documentation, not real-life, you understand :-))
> >
> > So where does that put my thinking?
> >
> Hmmmm. You would -really- prefer a predicate which return True, something
> which predicts usability. The closest is a structural type equivalence test
> which compares the signatures of the object and the interface:

No. I told you what I think. The code as written should return False,
and I don't believe code can determine semantic issues, so it
shouldn't try.

"You would -really- prefer a predicate which return True" - No. As
it's not possible to get this (in the same absolute sense that it
isn't possible to solve the halting problem) I don't want something
that attempts to - I'd still have to deal with the places where it's
wrong, so I don't want to start down that route.

I don't *want* a predicate that returns anything in particular. I
don't code in a way that would need such a predicate.

>    I1.conforms(obj)
>
> Because the type in question is an Interface it uses a structural type check
> which sees that D() does conform to the interface.  And returns True. So as
> far as the Interface is concerned it -is- looks like an instance an I1.

Structural type checks, inheritance checks, whatever. None of them
avoid the need to document the semantic requirements. So I'd rather
rely on documented expectations, and a consenting adults philosophy.

Which is not to say that I can't see cases where isinstance,
type-based dispatching, interfaces/adaptation or any other type-based
process could be useful. It's just that for the code I write, it's
never been necessary.

Paul.

From oliphant.travis at ieee.org  Thu May 11 18:00:24 2006
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Thu, 11 May 2006 10:00:24 -0600
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <4462B2FD.3070406@canterbury.ac.nz>
References: <loom.20060502T201105-105@post.gmane.org>	<e38g44$bfb$1@sea.gmane.org>
	<44596963.8070200@canterbury.ac.nz>	<e3ga30$9sq$1@sea.gmane.org>
	<e3qvqa$k6m$1@sea.gmane.org>	<4461428C.60803@canterbury.ac.nz>
	<446256F9.50507@ieee.org> <4462B2FD.3070406@canterbury.ac.nz>
Message-ID: <e3vn2q$pr9$1@sea.gmane.org>

Greg Ewing wrote:
> Travis E. Oliphant wrote:
>> The only thing I would wish different is to get rid of the PyGTK 
>> dependency.   I think PyGUI should be a wrapper directly on top of GNOME
> 
> Perhaps you have Gnome and Gtk confused? Gnome is the
> desktop, Gtk is the UI library that Gnome applications
> use.

No, I understand the difference.  I was referring to the gnomeui 
libraries which have a series of standard dialog boxes and higher-level 
widgets that give the gnome desktop it's look-and-feel.   I realize that 
gtk also has standard dialog boxes.

See, for example,  http://freshmeat.net/projects/libgnomeui/


> 
>> In short, I don't like the chaining effect of wrapper on top of wrapper.
>>  I want to make the connection to platform libraries as simple as 
>> possible.
> 
> So do I, but I'm concentrating on getting the API right
> first. Optimisations such as reducing the number of wrapper
> layers can come later.
> 


That sounds reasonable.   As I said before, I like the idea of PyGUI. 
My main consternation is wxWindows.  I'm not a big fan of how wxPython 
builds on top of wxWindows which builds on top of GTK which itself 
builds on GDI which is itself a cross-platform layer on top of X11. 
There are way too many layers of indirection there for my tastes.   As a 
result, my (limited) experience with wxWindows on Linux has not been 
pleasant.


Keep up the great work...


-Travis


From edloper at gradient.cis.upenn.edu  Thu May 11 18:06:40 2006
From: edloper at gradient.cis.upenn.edu (Edward Loper)
Date: Thu, 11 May 2006 12:06:40 -0400
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <878xp8k4ji.fsf@qrnik.zagroda>
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>	<ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>	<ee2a432c0605102322x5834898dk2a60c7ad72640e6e@mail.gmail.com>
	<878xp8k4ji.fsf@qrnik.zagroda>
Message-ID: <44636110.4010503@gradient.cis.upenn.edu>

Marcin 'Qrczak' Kowalczyk wrote:
> "Neal Norwitz" <nnorwitz at gmail.com> writes:
> 
>> Another benefit of this is the ability to get more info through
>> introspection. Right now, you can't even find the number of
>> arguments of a function implemented in C. You only know if it takes
>> 0, 1, or variable # of arguments and if it accepts keywords.
> 
> This would be incompatible with generic proxies.

No it wouldn't -- the generic proxy classes can just copy the 
__signature__ of the object they proxy for.

-Edward

From janssen at parc.com  Thu May 11 18:06:53 2006
From: janssen at parc.com (Bill Janssen)
Date: Thu, 11 May 2006 09:06:53 PDT
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: Your message of "Wed, 10 May 2006 17:36:24 PDT."
	<loom.20060511T022957-365@post.gmane.org> 
Message-ID: <06May11.090702pdt."58641"@synergy1.parc.xerox.com>

> So my thought is this: How hard would it be to make
> a curses-based debugger?

Long as it works in my Emacs shell buffer...

Bill

From pje at telecommunity.com  Thu May 11 18:18:39 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 11 May 2006 12:18:39 -0400
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <OF85780877.84AC848F-ON8025716B.005481EF-8025716B.0054E474@
	risk.sungard.com>
References: <5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060511115329.03aa7e10@mail.telecommunity.com>

At 04:27 PM 5/11/2006 +0100, Ben.Young at risk.sungard.com wrote:
>Why not
>
>class Foo(object):
>         @specialize(arg(0))
>         def core.len(self)
>                 ...

Where does 'core' come from?  What is specialize for?  I don't understand 
what you're proposing.


>I don't know how this would appear in the class dict though? self.len()?

In my proposal, 'defop' doesn't bind anything; it's just a statement that 
defines a function object and then adds that function to the specified 
overloaded function.  If it occurs in a class body, the function would be 
*defined* where it is, but it would not be added to the targeted operation 
until after the class was created.

Doing the actual overloading would be accomplished by an "overload()" 
generic function, meaning that users could define their own generic 
function implementations and use them with 'defop'.  Decorated defops would 
apply the decorators to the function before doing the overload, so a 
RuleDispatch implementation for Py3K might use something like this to add a 
predicate:

     @when("something(arg1) and arg2>arg3")
     defop foo.bar(arg1, arg2:int, arg3:int):
          # blah blah

This assumes that 'foo.bar' is a RuleDispatchGenericFunction, and something 
like this has been defined:

     class RuleDispatchGenericFunction:
         # ...

         defop operator.overload(self, function):
             # code to extract type signature from provided function
             # along with an optional predicate tacked on by @when,
             # and then register it using RuleDispatch's indexing
             # system

In other words, I'm saying that 'defop' is equivalent to having a decorator 
that calls 'operator.overload(generic, function, cls)', and also throws 
away the function instead of binding it to a name.  (cls here is either the 
class

So by making the overload() function a generic function, we can have 
multiple implementations of generic functions.  Anybody can experiment with 
custom approaches to overloading implementations, but they can all use a 
common syntax (defop) to work.  The overload implementation for builtin 
generic functions like len() and iter() would be something like this (if it 
were expressed in Python rather than C):

     defop operator.overload(gf:BuiltinGenericType, function):
         # code to put function in the appropriate tp_* slot of the
         # declared type of the function's first argument, using
         # info from 'gf' to know which slot to use

So builtin generic functions like iter() and len() would be 
BuiltinGenericType instances, that have information that indicates what 
tp_* slot they use and what kind of C wrapper is required.  The tp_call of 
BuiltinGenericType would then just do a slot lookup for the desired 
thing.  So we end up right where we are now in terms of performance for 
these operations, because they work the same as they always did.  It's just 
that we can drop having __magic__ names for them.

In fact, we don't even change the existing C APIs that implement these 
"generic" functions; all we're really doing is splitting up the existing 
setattr/dict->tp_* slot machinery into a set of data structures to be 
driven by a single basic approach.

In other words, we're just creating a uniform way to register methods with 
generic functions, that just happens to have a special fast path for 
language-defined operations.

The most "interesting" part is likely to be the resolution of binary 
overloads for existing __add__ vs. __radd__ stuff, both in how best to 
spell such definitions in code, and in how the builtin generics would 
implement dispatching.


From solipsis at pitrou.net  Thu May 11 19:16:28 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 11 May 2006 19:16:28 +0200
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <e3vn2q$pr9$1@sea.gmane.org>
References: <loom.20060502T201105-105@post.gmane.org>
	<e38g44$bfb$1@sea.gmane.org> <44596963.8070200@canterbury.ac.nz>
	<e3ga30$9sq$1@sea.gmane.org> <e3qvqa$k6m$1@sea.gmane.org>
	<4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org>
	<4462B2FD.3070406@canterbury.ac.nz>  <e3vn2q$pr9$1@sea.gmane.org>
Message-ID: <1147367788.30914.11.camel@fsol>


Le jeudi 11 mai 2006 ? 10:00 -0600, Travis E. Oliphant a ?crit :
> 
> That sounds reasonable.   As I said before, I like the idea of PyGUI. 
> My main consternation is wxWindows.  I'm not a big fan of how wxPython 
> builds on top of wxWindows which builds on top of GTK which itself 
> builds on GDI which is itself a cross-platform layer on top of X11. 

You are mixing up a lot of things.
AFAIK there is nothing named GDI in or under GTK. GDI is the drawing
layer in Microsoft Windows.
There is something named GDK which is a general non-graphical library to
complement the C stdlib, not a "cross-platform layer on top of X11".

Also, the only two layers which have a substantial influence on user
expericence are GTK and wxWindows. Granted, this is more complicated
than only one layer, but it's not the pile of crap you are making it to
be.

> There are way too many layers of indirection there for my tastes.   As a 
> result, my (limited) experience with wxWindows on Linux has not been 
> pleasant.

As if the layers of indirection were visible to the developer?
How do you think less layers would have improved your developer
experience?

There are problems with wxWindows but you cannot claim that any
cross-platform GUI library would have as many problems.



From tomerfiliba at gmail.com  Thu May 11 19:27:25 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Thu, 11 May 2006 19:27:25 +0200
Subject: [Python-3000] i guess i was misunderstood
Message-ID: <1d85506f0605111027v3145da88o8e2314cac203064d@mail.gmail.com>

"Guido van Rossum" <guido <at> python.org> wrote
> You seem to be still under the influence of the type-safety mafia, who
> want to make you believe that with enough type-checking you can
> prevent all bugs (though they don't believe it themselves).
~~
>> I think that I agree with the gist of Tomer's point.
>Well, to most of us it's far from clear what he's trying to say...

no, i'm quite the opposite in fact. i want a type-less language. sure,
builtin types like int/str/float need some concrete distinction, but apart
from those, all language-level objects should be typeless.

and python is half way there really. a type in python is basically the
object's MRO, and most code relies to the *attributes* of the object
other than it's type., i.e., "for" loops requires __iter__ instead of
inheritence like in java.

which is all good.

--------

but, the usage of isinstance(x, y) or type(x) should be deprecated
or at least limited only to where it's *needed*, for example:

class A(object):
    def __init__(self, x):
        self.x = x

class B(object):
    def __init__(self):
        A.__init__(self, 5)

b=B() # error, A.__init__ expects an instanc of A

why is this kind of type-checking enforced by the language? i wanted to
create class proxies, so i could inherit from instances. for example:

class myFrame(derive_of(c.modules.wx.Frame)):
    ...

c.modules.wx.Frame is a proxy (instance) to a remote type, so you can't
derive from it directly. therefore, derive_of is

def derive_of(proxy_type):
    class cls(object):
        def  __getattr__(self, name):
            return getattr(proxy_type, name)
    return cls

which basically means that when the attribute doesn't belong to the
instance of local class, it is queried for at the remote class. but it doesnt
work, because the method checks for the instance's type.

(the real code was quite more complex, and the above snippet is only
an example of the concept, not production code)

what this code does is basically changing the __mro__ of the object. had
__mro__ been mutable, it would all be simpler.

-------

yes, i understand python suddenly dropping types is a very drastic change
that isn't likely to happen. so i say, keep the types, just don't count on them
too much. just use duck-typing. AttributeError is equivalent to TypeError.

and as i showed in the "interfaces" example, you can't rely on inheritence
to determine if some operation is going to be valid. python is not java, as it
doesnt enforce conformness to method signatures, thus relying on
isinstance() is not really gonna help you -- as i showed, the derived class
can break the interface's signatures.

therefore, the only thing you can count on is ducktyping, which is basically
querying the object if it has the relevant attributes, not the relevant base
class.

relying on hasattr rather than on isinstance would mean proxies would
work just fine.

the other sollution i proposed was adding a __type__() special method
that returns the object's type for type(x) or isinstance(x,y) --

class Prxoy(object):
    def __init__(self, obj):
        self.__real_obj = obj
    def __getattr__(self, name):
         return getattr(self.__real_obj, name)
    def __type__(self):
         """returns the 'real type' of the proxy"""
         return type(self.__real_obj)

p = Proxy(5)

print p.__class__
# <class __main__.Proxy>

print type(p)
# <type int>

print p+4  # --> p.__add__(4) --> p.__real_obj.__add__(4)
# 9

(by default, __type__() just returns __class__)

-------

i really hope i made my point clear now. i want object proxies to be
transparent to the language. this can either be done by not depending
on the "real" type of objects, i.e., using hasattr instead of isinstance,
or adding the new special method i suggested, or some similar mechanism.


-tomer

From steven.bethard at gmail.com  Thu May 11 19:27:30 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Thu, 11 May 2006 11:27:30 -0600
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <4462D9F7.6040605@acm.org>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
	<4462D9F7.6040605@acm.org>
Message-ID: <d11dcfba0605111027m2a1ee79qf742e41680707f56@mail.gmail.com>

On 5/11/06, Talin <talin at acm.org> wrote:
> sequence( indexable ):
>     -- an indexable in which the indexes are successive integers
>     -- Test: isinstance( index_type, int )

I think as of Python 2.5, this should be hasattr(index_type, '__index__'), no?

> mapping( indexable ):
>     -- an indexable in which the indices are hashable values:
>     -- Test: hashable( index_type )
>     -- (Also test for immutable if its feasible)

This seems all and good, but how do you figure out what "index_type"
is?  Are you suggesting that "indexables" which want to be identified
as sequences or mappings need to provide their index type somehow?  If
so, how?  (By inheriting from an abstract type?)

STeVe
-- 
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From talin at acm.org  Thu May 11 19:35:33 2006
From: talin at acm.org (Talin)
Date: Thu, 11 May 2006 10:35:33 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <874pzwk454.fsf@qrnik.zagroda>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>	<loom.20060509T234801-751@post.gmane.org>	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>	<4462D9F7.6040605@acm.org>
	<874pzwk454.fsf@qrnik.zagroda>
Message-ID: <446375E5.2090500@acm.org>

The word 'sequence' here doesn't mean an exclusive category. In a sense, 
all sequences are really mappings - they "map" a range of integers to 
values.

 From the standpoint of accepting an argument, we really don't care 
whether something is a sequence or a mapping, we care about what we can 
do with it. The approach that I'd like to take is to identify the use 
cases, and then devise tests that indicate whether those use cases can 
be applied.

So to avoid confusion, let's drop 'sequence' and 'mapping' for the 
moment, and instead think about use cases:

appendable( iterable ):
    -- An iterable that can be appended to
    -- Test: hasattr( append )
    -- (Probably also need to test the signature of append)

associative( indexable ):
    -- An iterable that contains associative pairs of items,
       where the item pairs can be iterated over
    -- Test: hasattr( iteritems )


Marcin 'Qrczak' Kowalczyk wrote:
> Talin <talin at acm.org> writes:
> 
> 
>>sequence( indexable ):
>>    -- an indexable in which the indexes are successive integers
>>    -- Test: isinstance( index_type, int )
> 
> 
> I don't understand. How would this test distinguish [] being a
> sequence from {} not being a sequence?
> 
> 
>>mapping( indexable ):
>>    -- an indexable in which the indices are hashable values:
>>    -- Test: hashable( index_type )
>>    -- (Also test for immutable if its feasible)
> 
> 
> And this on the contrary?
> 

From talin at acm.org  Thu May 11 19:43:50 2006
From: talin at acm.org (Talin)
Date: Thu, 11 May 2006 10:43:50 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <d11dcfba0605111027m2a1ee79qf742e41680707f56@mail.gmail.com>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>	<loom.20060509T234801-751@post.gmane.org>	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>	<4462D9F7.6040605@acm.org>
	<d11dcfba0605111027m2a1ee79qf742e41680707f56@mail.gmail.com>
Message-ID: <446377D6.70807@acm.org>

Ideally, if we get the signature API that's been discussed, then lists 
and tuples and such would have a constraint on their __getitem__ method:

    def __getitem__( self, index:int ):
       ...

Thus, the concept testing code could look to see what types are 
acceptable to the __getitem__ method and make its decision based on that.

Steven Bethard wrote:
> On 5/11/06, Talin <talin at acm.org> wrote:
> 
>>sequence( indexable ):
>>    -- an indexable in which the indexes are successive integers
>>    -- Test: isinstance( index_type, int )
> 
> 
> I think as of Python 2.5, this should be hasattr(index_type, '__index__'), no?
> 
> 
>>mapping( indexable ):
>>    -- an indexable in which the indices are hashable values:
>>    -- Test: hashable( index_type )
>>    -- (Also test for immutable if its feasible)
> 
> 
> This seems all and good, but how do you figure out what "index_type"
> is?  Are you suggesting that "indexables" which want to be identified
> as sequences or mappings need to provide their index type somehow?  If
> so, how?  (By inheriting from an abstract type?)
> 
> STeVe

From guido at python.org  Thu May 11 20:03:19 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 11 May 2006 11:03:19 -0700
Subject: [Python-3000] i guess i was misunderstood
In-Reply-To: <1d85506f0605111027v3145da88o8e2314cac203064d@mail.gmail.com>
References: <1d85506f0605111027v3145da88o8e2314cac203064d@mail.gmail.com>
Message-ID: <ca471dc20605111103q9181999vc2f882f46b5714c1@mail.gmail.com>

[Guido]
> > You seem to be still under the influence of the type-safety mafia, who
> > want to make you believe that with enough type-checking you can
> > prevent all bugs (though they don't believe it themselves).

[Talin, quoetd by Guido]
> >> I think that I agree with the gist of Tomer's point.

[Guido responds]
> >Well, to most of us it's far from clear what he's trying to say...

[Tomer]
> no, i'm quite the opposite in fact. i want a type-less language. sure,
> builtin types like int/str/float need some concrete distinction, but apart
> from those, all language-level objects should be typeless.

Well, sorry, but I don't think anyone here understands what you mean
by "typeless" so I think continuing this discussion is rather
pointless. Your statement that "an object's type is its MRO" is also
meaningless and not rooted in fact. And your examples are
incomprehensible.

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

From talin at acm.org  Thu May 11 20:05:00 2006
From: talin at acm.org (Talin)
Date: Thu, 11 May 2006 11:05:00 -0700
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <4463332E.8000107@gmail.com>
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>	<ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
	<4462DAA5.9040104@acm.org> <4463332E.8000107@gmail.com>
Message-ID: <44637CCC.7000709@acm.org>

Nick Coghlan wrote:
> Talin wrote:
> 
>> I haven't forgotten that you asked me to write up a PEP for a 
>> signature API in conjunction with the keyword arguments PEP. However, 
>> I don't yet feel that the ideas have gelled enough to do so yet -- or 
>> at least, I don't feel competent to come up with a definative solution.
> 
> The first draft doesn't have to be definitive :)

Old bad habits die hard :(

> However, being able to create a signature object independently of a def 
> statement is definitely something that should be in there - we'll need 
> it for annotating C methods anyway, so it may make sense to start with 
> that, and then look at making it an integral part of the function header 
> afterwards.

Right. Ideally, I'd like C methods to be able to construct signatures 
out of static data.

Some of the other open issues with signatures are as follows:

o   How to use the signature to be able to predict which input arguments 
are going to map against which formal parameters.

o   How to specify constraints (other than types) that are inspectable. 
In other words, a constraint on a parameter shouldn't just be a yes/no 
function, because you can't inspect the function externally and see what 
it means.

If signatures are going to be used to implement rule-based dispatch, the 
dispatcher will be able to run more efficiently if it can decompose the 
signature into individual tests, and combine similar tests from 
different alternative methods, as well as re-ordering the tests so that 
the range of possible results is narrowed quickly. But this only works 
if the tests are more than simple black boxes.

(In other words, don't use lambda as a parameter constraint - but what 
to use instead?)

o   How to specify multiple constraints for a parameter.

o   How to specify signature constraints that test the signatures of the 
input arguments.

-- Talin

From jimjjewett at gmail.com  Thu May 11 20:19:10 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Thu, 11 May 2006 14:19:10 -0400
Subject: [Python-3000] prototype OO?
Message-ID: <fb6fbf560605111119r3b52f8ddo284c93e8fec77bd8@mail.gmail.com>

On 5/11/06, tomer filiba <tomerfiliba at gmail.com> wrote:

> class myFrame(derive_of(c.modules.wx.Frame)):
>     ...

> c.modules.wx.Frame is a proxy (instance) to a remote type, so you can't
> derive from it directly. therefore, derive_of is

> def derive_of(proxy_type):
>     class cls(object):
>         def  __getattr__(self, name):
>             return getattr(proxy_type, name)
>     return cls

> which basically means that when the attribute doesn't belong to the
> instance of local class, it is queried for at the remote class. but it doesnt
> work, because the method checks for the instance's type.

There are languages (Self; I think even javascript) whose OO is based
on Prototypes rather than classes.  If an object doesn't have the
attribute/method, then check its prototype (and so on recursively).

When I have to emulate this in python (or Java), I just try to shove
all my logic into classmethods, and use at most a singleton instance.

Proxies are certainly the perfect example of something where you would
want a "just like X, except" object, and would prefer to be able to
use instances as the prototype.

I don't think prototype OO should replace the current form, but it
might be worth adding, even in Python 2.X.  Do you have a proposed
implementation, or even a proposed syntax?

-jJ

From guido at python.org  Thu May 11 20:19:43 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 11 May 2006 11:19:43 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <446375E5.2090500@acm.org>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
	<4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda>
	<446375E5.2090500@acm.org>
Message-ID: <ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>

On 5/11/06, Talin <talin at acm.org> wrote:
> The word 'sequence' here doesn't mean an exclusive category. In a sense,
> all sequences are really mappings - they "map" a range of integers to
> values.

No, the requirements for sequence-ness are stronger. The set of ints
mapped must be exactly range(len(x)). And iterating over the sequence
is required to return the values in numerical order of the index set
(unlike iterating over a dict whose keys happen to be a contiguous set
of ints starting at 0). And for mutable sequences, insertions and
deletions move all the other keys around -- very different from a
mutable mapping. And sequences are expected to implement slicing,
concatenation and repetition.

In general, there are two possible taxonomies of container types for
Python: minimal and maximal. The minimal taxonomy attempts to describe
the minimal features that a  specimen of container ought to have in
order to be considered a member of a given species of container. It is
useful for determination but not so useful for prediction of behavior.
The maximal taxonomy attempts to describe all the features shared by
(most) members of a species; it's harder to use for determination, but
more useful for describing expected behavior.

I think I'm more comfortable with a maximal taxonomy. In a maximal
taxonomy, I'd describe a large set of invariants, attributes,
behavior, etc., and say e.g. "this is how a file behaves". A
particular class can then claim to be a file by explicitly declaring
this (how that's spelled is a different issue -- it doesn't need to be
done by inheritance from an abstract base class or interface, it could
also be an arbitrary property, agreed upon by convention, or an
external registry of all file types, for example).

For the purposes of generic/overloaded functions, if we can overload
on such abstract container species, the declared container species (or
the "best" one, if multiple species can be declared) should determine
the implementation chosen -- and damn the torpedoes if the object
declares it's a file but doesn't implement isatty(). (I.e. I don't
care, it's still a file, just like a three-legged dog is still a dog.)

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

From talin at acm.org  Thu May 11 20:27:12 2006
From: talin at acm.org (Talin)
Date: Thu, 11 May 2006 11:27:12 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>	
	<loom.20060509T234801-751@post.gmane.org>	
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>	
	<4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda>	
	<446375E5.2090500@acm.org>
	<ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>
Message-ID: <44638200.40106@acm.org>

Guido van Rossum wrote:
> On 5/11/06, Talin <talin at acm.org> wrote:
> 
>> The word 'sequence' here doesn't mean an exclusive category. In a sense,
>> all sequences are really mappings - they "map" a range of integers to
>> values.
> 
> 
> No, the requirements for sequence-ness are stronger. The set of ints
> mapped must be exactly range(len(x)). And iterating over the sequence
> is required to return the values in numerical order of the index set
> (unlike iterating over a dict whose keys happen to be a contiguous set
> of ints starting at 0). And for mutable sequences, insertions and
> deletions move all the other keys around -- very different from a
> mutable mapping. And sequences are expected to implement slicing,
> concatenation and repetition.
> 
> In general, there are two possible taxonomies of container types for
> Python: minimal and maximal. The minimal taxonomy attempts to describe
> the minimal features that a  specimen of container ought to have in
> order to be considered a member of a given species of container. It is
> useful for determination but not so useful for prediction of behavior.
> The maximal taxonomy attempts to describe all the features shared by
> (most) members of a species; it's harder to use for determination, but
> more useful for describing expected behavior.
> 
> I think I'm more comfortable with a maximal taxonomy. In a maximal
> taxonomy, I'd describe a large set of invariants, attributes,
> behavior, etc., and say e.g. "this is how a file behaves". A
> particular class can then claim to be a file by explicitly declaring
> this (how that's spelled is a different issue -- it doesn't need to be
> done by inheritance from an abstract base class or interface, it could
> also be an arbitrary property, agreed upon by convention, or an
> external registry of all file types, for example).
> 
> For the purposes of generic/overloaded functions, if we can overload
> on such abstract container species, the declared container species (or
> the "best" one, if multiple species can be declared) should determine
> the implementation chosen -- and damn the torpedoes if the object
> declares it's a file but doesn't implement isatty(). (I.e. I don't
> care, it's still a file, just like a three-legged dog is still a dog.)
> 

OK, this sounds right to me. At least, it sounds like what you are 
describing is what I am asking for :)

-- Talin

From guido at python.org  Thu May 11 20:27:52 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 11 May 2006 11:27:52 -0700
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <44637CCC.7000709@acm.org>
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>
	<ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
	<4462DAA5.9040104@acm.org> <4463332E.8000107@gmail.com>
	<44637CCC.7000709@acm.org>
Message-ID: <ca471dc20605111127w41e2a6c1w9531cc2754cd4ad1@mail.gmail.com>

On 5/11/06, Talin <talin at acm.org> wrote:
> Some of the other open issues with signatures are as follows:
>
> o   How to use the signature to be able to predict which input arguments
> are going to map against which formal parameters.

Well, there's supposed to be an algorithm defined by the language
spec. There should be an implementation of this algorithm available at
run time. I don't understand your problem here (unless it's about what
that algorithm should be, which I thought we'd hashed out elsewhere?).

> o   How to specify constraints (other than types) that are inspectable.
> In other words, a constraint on a parameter shouldn't just be a yes/no
> function, because you can't inspect the function externally and see what
> it means.
>
> If signatures are going to be used to implement rule-based dispatch, the
> dispatcher will be able to run more efficiently if it can decompose the
> signature into individual tests, and combine similar tests from
> different alternative methods, as well as re-ordering the tests so that
> the range of possible results is narrowed quickly. But this only works
> if the tests are more than simple black boxes.
>
> (In other words, don't use lambda as a parameter constraint - but what
> to use instead?)

I'd like to leave this undefined in the PEP. The signature should
simply provide access to the value of the expression (if any) computed
at function definition time from the annotation slot for the
parameter. So if I choose to write

  def foo(a: 42 = "blah", b: "hello" + " world" = None) -> range(3): ...

then accessing the annotation for the first parameter should give me
42, for the second parameter should give me "hello world", and for the
return value should give me [0, 1, 2]. What I do with that is my
business.

> o   How to specify multiple constraints for a parameter.

That's up to the framework designer who interprets the parameter
annotations. For type-based annotations I've previously proposed the
'|' and '&' operators -- '|' to indicate union types, '&' to indicate
multiple types that must all be satisified. You can use (...) for
grouping, too.

> o   How to specify signature constraints that test the signatures of the
> input arguments.

Collin Winter is thinking about this I believe.

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

From rhettinger at ewtllc.com  Thu May 11 20:43:22 2006
From: rhettinger at ewtllc.com (Raymond Hettinger)
Date: Thu, 11 May 2006 11:43:22 -0700
Subject: [Python-3000] prototype OO?
In-Reply-To: <fb6fbf560605111119r3b52f8ddo284c93e8fec77bd8@mail.gmail.com>
References: <fb6fbf560605111119r3b52f8ddo284c93e8fec77bd8@mail.gmail.com>
Message-ID: <446385CA.5030209@ewtllc.com>

Jim Jewett wrote:

>There are languages (Self; I think even javascript) whose OO is based
>on Prototypes rather than classes.  If an object doesn't have the
>attribute/method, then check its prototype (and so on recursively).
>
>When I have to emulate this in python (or Java), I just try to shove
>all my logic into classmethods, and use at most a singleton instance.
>
>Proxies are certainly the perfect example of something where you would
>want a "just like X, except" object, and would prefer to be able to
>use instances as the prototype.
>
>I don't think prototype OO should replace the current form, but it
>might be worth adding, even in Python 2.X.  Do you have a proposed
>implementation, or even a proposed syntax?
>
>  
>

I've been thinking about and wanting Prototype OO support for a long 
time but think it should NOT be conflated with rest of the language.

Instead, there should be two nexus points:
1) a module defining Object() -- last year, there was a comp.lang.python 
posting with working PurePython code for Object();
2) a slight liberalization of the syntax for the def-keyword to allow 
definitions to be written directly into a targeted namespace.

Those two steps will make it easy to experiment with Prototype OO but 
not muck-up the rest of the language.   The module docs can show code 
demonstrating how to use the two together:

Account = Object.clone(balance=0)
def Account.deposit(self, v):
    self.balance += v
def Account.withdrawal(self, v):
    self.balance -= v
def Account.show(self):
    print self.balance

myAccount = Account.clone()
myAccount.deposit(10)
myAccount.show()


Boy = Object().clone(gender = 'male')
def Boy.sayGender(self):
    print self.gender
Girl = Goy.clone(gender = 'female')

m = Girl.clone(name=megan, age=3)
m.sayGender()



Raymond


"""Oh give me a clone
of my own flesh and bone
with its Y chromosome changed to an X
and when it is grown
then my own little close
will be of the opposite sex
""" -- sung to the tune of "where the buffalo roam"

From lists at janc.be  Thu May 11 21:06:31 2006
From: lists at janc.be (Jan Claeys)
Date: Thu, 11 May 2006 21:06:31 +0200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <200605081159.03756.fdrake@acm.org>
References: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
	<200605081138.52823.fdrake@acm.org>
	<0492B926-C6F2-4063-9CBF-B97D9237EBDB@mac.com>
	<200605081159.03756.fdrake@acm.org>
Message-ID: <1147374392.1025.24.camel@localhost.localdomain>

Op ma, 08-05-2006 te 11:59 -0400, schreef Fred L. Drake, Jr.:
> Yes, there is a good reason for Tkinter to be separate.  There's not a good 
> reason for distutils to be separate. 

Why would ordinary end-users of an application written in Python need
distutils?  They will get their application as a py2exe executable (or
similar) on Windows, as a distro package on linux and on Mac OS X there
is py2app IIRC.  And even if they had distutils installed, most of them
won't know how to use it.


-- 
Jan Claeys


From fdrake at acm.org  Thu May 11 21:40:38 2006
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Thu, 11 May 2006 15:40:38 -0400
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <1147374392.1025.24.camel@localhost.localdomain>
References: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
	<200605081159.03756.fdrake@acm.org>
	<1147374392.1025.24.camel@localhost.localdomain>
Message-ID: <200605111540.39210.fdrake@acm.org>

On Thursday 11 May 2006 15:06, Jan Claeys wrote:
 > Why would ordinary end-users of an application written in Python need
 > distutils?  They will get their application as a py2exe executable (or
 > similar) on Windows, as a distro package on linux and on Mac OS X there
 > is py2app IIRC.  And even if they had distutils installed, most of them
 > won't know how to use it.

If there's no distro package (not unusual), they'd download the source package 
and need to run "python setup.py install".  They need both Python and 
distutils in that case.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From fredrik.johansson at gmail.com  Thu May 11 22:07:46 2006
From: fredrik.johansson at gmail.com (Fredrik Johansson)
Date: Thu, 11 May 2006 22:07:46 +0200
Subject: [Python-3000] Math in Python 3.0
Message-ID: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>

Hi all,

Some assorted thoughts:

Python's current numeric model has serious problems. It's fine for
calculating with nothing but floats, or nothing but ints, but writing
code that works for ints, floats, complexes *and* Decimals - let alone
for custom types such as mpfs or numeric arrays - is nearly
impossible. Duck typing doesn't work because these types all have
different interfaces, despite being functionally (or conceptually)
equivalent for many purposes.

Generic functions would solve most of the problem. I don't see this
example being brought up often (perhaps I've just missed those posts),
but I do think improved support for custom numeric types is a very
strong motivation for implementing generic functions in Python 3.0. If
operators could be overloaded as well (to define mpf()+Decimal(), say)
without creating wrapper classes, it'd be even better.

Are people still positive regarding the idea of merging decimal and
binary floats into the same type? (Or at least ensuring that they can
be mixed seamlessly, which should be no problem with decimal literals
added to the language.) Is someone currently working on a faster
implementation of Decimal? I'm occupied, but might be able to lend a
hand soon.

The issue of generally extending Python's default math library was
also brought up quite recently. I don't think incorporating half of
SciPy or nzmath would be a good idea at all, but there's certainly
room for more small utility functions. For example, isodd()/iseven()
would be extremely nice (how many times have you typed/read the
mind-numbing expression "n%2 == 0"?).

Anyone for PEP-writing? I can think of numerous small changes (and
ideas too insane to suggest publicly on this list); perhaps a wiki
page first?

Fredrik Johansson

From ronaldoussoren at mac.com  Thu May 11 22:07:59 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 11 May 2006 22:07:59 +0200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <1147374392.1025.24.camel@localhost.localdomain>
References: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
	<200605081138.52823.fdrake@acm.org>
	<0492B926-C6F2-4063-9CBF-B97D9237EBDB@mac.com>
	<200605081159.03756.fdrake@acm.org>
	<1147374392.1025.24.camel@localhost.localdomain>
Message-ID: <6200DB56-57FE-4A0E-93D5-4B352BAA8A08@mac.com>


On 11-mei-2006, at 21:06, Jan Claeys wrote:

> Op ma, 08-05-2006 te 11:59 -0400, schreef Fred L. Drake, Jr.:
>> Yes, there is a good reason for Tkinter to be separate.  There's  
>> not a good
>> reason for distutils to be separate.
>
> Why would ordinary end-users of an application written in Python need
> distutils?  They will get their application as a py2exe executable (or
> similar) on Windows, as a distro package on linux and on Mac OS X  
> there
> is py2app IIRC.  And even if they had distutils installed, most of  
> them
> won't know how to use it.

Users of python need distutils at times. Not all python software is  
available as distro packages, including all in-house software.  
Therefore a (large?) fraction of python users actually need  
distutils. I've been bitten several times in the past by a python  
installation that didn't include distutils, but luckily most linux  
distributors seem to have caught onto the fact that removing disutils  
creates more problems than it solves.

For scripting languages like python the distinction between  
development and packages and runtime packages is a lot hazier than it  
is for compiled languages like C (and rightly so, a much larger  
fraction of the computer using population is be able to program in  
python than C).

Ronald

From guido at python.org  Thu May 11 22:40:16 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 11 May 2006 13:40:16 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <da7032ce0605111335m38a241e3sbe49bc6fb0b804e3@mail.gmail.com>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
	<4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda>
	<446375E5.2090500@acm.org>
	<ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>
	<da7032ce0605111335m38a241e3sbe49bc6fb0b804e3@mail.gmail.com>
Message-ID: <ca471dc20605111340m4827ef83ge648c6f121d53568@mail.gmail.com>

On 5/11/06, Mike Krell <mbk.lists at gmail.com> wrote:
> On 5/11/06, Guido van Rossum <guido at python.org> wrote:
> > I think I'm more comfortable with a maximal taxonomy. In a maximal
> > taxonomy, I'd describe a large set of invariants, attributes,
> > behavior, etc., and say e.g. "this is how a file behaves". A
> > particular class can then claim to be a file by explicitly declaring
> > this (how that's spelled is a different issue -- it doesn't need to be
> > done by inheritance from an abstract base class or interface, it could
> > also be an arbitrary property, agreed upon by convention, or an
> > external registry of all file types, for example).
>
> If the route chosen is "agreed upon by convention" what is the
> difference between this and duck typing?  Are the "claim" and
> "convention" anything more than comments in the code?

The claim should be introspectable. *Conformance* to the claimed API
may be hard to introspect but IMO the claims should be introspectable,
separate from whatever we (think we) know about hasattr().

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

From mbk.lists at gmail.com  Thu May 11 22:35:52 2006
From: mbk.lists at gmail.com (Mike Krell)
Date: Thu, 11 May 2006 13:35:52 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
	<4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda>
	<446375E5.2090500@acm.org>
	<ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>
Message-ID: <da7032ce0605111335m38a241e3sbe49bc6fb0b804e3@mail.gmail.com>

On 5/11/06, Guido van Rossum <guido at python.org> wrote:
> I think I'm more comfortable with a maximal taxonomy. In a maximal
> taxonomy, I'd describe a large set of invariants, attributes,
> behavior, etc., and say e.g. "this is how a file behaves". A
> particular class can then claim to be a file by explicitly declaring
> this (how that's spelled is a different issue -- it doesn't need to be
> done by inheritance from an abstract base class or interface, it could
> also be an arbitrary property, agreed upon by convention, or an
> external registry of all file types, for example).

If the route chosen is "agreed upon by convention" what is the
difference between this and duck typing?  Are the "claim" and
"convention" anything more than comments in the code?

   Mike

From aleaxit at gmail.com  Thu May 11 22:41:41 2006
From: aleaxit at gmail.com (Alex Martelli)
Date: Thu, 11 May 2006 13:41:41 -0700
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
Message-ID: <e8a0972d0605111341l502edbeek4a3e2d643ebe3ff1@mail.gmail.com>

On 5/11/06, Fredrik Johansson <fredrik.johansson at gmail.com> wrote:
   ...
> operators could be overloaded as well (to define mpf()+Decimal(), say)

Actually, gmpy currently does it by monkeypatching decimal.Decimal
(sigh) -- I believe that's only in the CVS HEAD, not yet in the
released gmpy version (I'm not going to release another gmpy version
until I can get GMP to work right on my new Macbook Pro, and that's
proving VERY hard considering the totally unhelpful attitude of GMP's
maintainer).  Yes, I *WOULD* appreciate a more elegant approach
(adaptation or multimethods would work fine, for example).

> added to the language.) Is someone currently working on a faster
> implementation of Decimal? I'm occupied, but might be able to lend a

We're selecting one of the many proposals regarding it from the Google
Summer of Code roster; Facundo Batista is scheduled be the primary
mentor, with me as co-mentor, but you're certainly welcome to pitch in
too, if and when you get some free time!

E.g., I believe one nice "side" project would be to add fast
transcendental elementary functions (they wouldn't necessarily have to
be in the Python Standard Library, at least to start with, but rather
could be a third-party module downloadable from the cheeseshop,
presumably using a C-API which should be offered by the new C
implementation of Decimal developed as the SoC project).


Alex

From rhettinger at ewtllc.com  Thu May 11 23:07:11 2006
From: rhettinger at ewtllc.com (Raymond Hettinger)
Date: Thu, 11 May 2006 14:07:11 -0700
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
Message-ID: <4463A77F.70805@ewtllc.com>

Fredrik Johansson wrote:

>
>Are people still positive regarding the idea of merging decimal and
>binary floats into the same type? (Or at least ensuring that they can
>be mixed seamlessly, which should be no problem with decimal literals
>added to the language.) 
>

IMO, the free mixing decimal and binary floats is not a good idea.


>Is someone currently working on a faster
>implementation of Decimal? 
>

It is a topic for the Iceland Sprint and on the project list for the 
Summer of Code.

>(how many times have you typed/read the
>mind-numbing expression "n%2 == 0"?).
>  
>

I write:

    if n&1:
       handle_odd()
    else:
       handle_even()

IMO, functions like is_even() and is_odd() are clutter.  Also, the 
performance of &1 is unlikely to be matched function calls.




>Anyone for PEP-writing? I can think of numerous small changes (and
>ideas too insane to suggest publicly on this list); perhaps a wiki
>page first?
>  
>

Better to start with sane ideas like a C implementation of decimal.

When it comes to numerous small changes, it is better to create a third 
party extension and see how it fares in the real-world.  I suspect that 
such a module would be ignored.  If that turns out to be true, then it 
means that the additions to the standard library are not warranted.


Raymond


From talin at acm.org  Thu May 11 23:17:05 2006
From: talin at acm.org (Talin)
Date: Thu, 11 May 2006 21:17:05 +0000 (UTC)
Subject: [Python-3000] my take on "typeclasses"
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
	<4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda>
	<446375E5.2090500@acm.org>
	<ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>
	<da7032ce0605111335m38a241e3sbe49bc6fb0b804e3@mail.gmail.com>
	<ca471dc20605111340m4827ef83ge648c6f121d53568@mail.gmail.com>
Message-ID: <loom.20060511T224939-102@post.gmane.org>

Guido van Rossum <guido <at> python.org> writes:

> The claim should be introspectable. *Conformance* to the claimed API
> may be hard to introspect but IMO the claims should be introspectable,
> separate from whatever we (think we) know about hasattr().

I sense convergence. Woot! :)

Here's a rough sketch of how this might work:

   import concepts

   # Use as an ordinary test
   def serialize( x ):
      if concepts.iterable( x ):
         ...

   # Use as a function argument constraint
   @generic
   def flatten( x:concepts.iterable ):
      ...

   # Another overload
   @generic
   def flatten( x:concepts.associative ):
      ...

   # Default
   @generic
   def flatten( x ):
      ...

'concepts.iterable' is an object that can be used either
to test a claim, or to introspect a claim. If you call it
as a function, it returns True if the input argument satisfies
the constraint. But you can also introspect the concept by
accessing its attributes.

(If you don't like the name 'concepts', another possible name
might be 'traits'.)

'&' and '|' would be overloaded to create a compount
concept:

   concepts.iterable & concepts.associative

would be equivalent to:

   intersection( concepts.iterable, concepts.associative )

where 'intersection' is a predicate class that itself can
be introspected to see what predicates it contains.

You could also mix regular types, so long as one of the
two operators had the overload.
   
Testing for signatures, how about something like this:

   def function( f:concepts.function( concepts.iterable, int ) )

Which describes a function that takes an argument which is
a function that takes an iterable and an int.

-- Talin



From collinw at gmail.com  Fri May 12 00:47:37 2006
From: collinw at gmail.com (Collin Winter)
Date: Thu, 11 May 2006 18:47:37 -0400
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>
	<ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
Message-ID: <43aa6ff70605111547j4096995ai1544ea1f80aed5c8@mail.gmail.com>

On 5/11/06, Guido van Rossum <guido at python.org> wrote:
> Well, remember that the default use of type annotations is to ignore
> them! You can write your own decorator that implements a specific
> interpretation of the annotations, and you can make it do anything you
> like.
>
> I think it would be useful to have a notation that can express
> signatures. I haven't spent much time thinking about what this would
> look like, but I'd like it to require no new syntax beyond the concept
> of type annotations. If this means you can't have the inline
> equivalent of your (int int -> int), then perhaps it could be done by
> referencing some prototype with the appropriate annotations. Or
> perhaps someting as crude as Function(type, type, ..., returns=type)
> would be good enough for inlining this.

This exact thing (Function(type, type, ..., returns=type)) has been
kicked around for inclusion in typecheck. One problem with using a
keyword arg to indicate the return type means that functions passed in
can't use that keyword argument themselves (unless you're not going to
allow Function(arg1=type, arg2=type, ...)-style type annotations).

One solution to this might be that you can't use Function inline,
using an attribute to declare the return type (which should default to
None). This lends itself to solving the next issue...

> Regarding the question what to do if something un-annotated is passed,
> you could have a strict and a lenient mode, sort of the equivalents of
> guilty-unless-proven-innocent and innocent-unless-proven-guilty. I
> guess the latter is more Pythonic, but the former is more in style
> with type checking systems... :-)

Maybe we could let the user decide which mode to use. If we use an
attribute to declare the return type, we could use another to indicate
whether they want this particular Function() instance to be strict or
lenient.

If some form of type annotations is introduced in 2.x, we could then
observe which strictness option people prefer and make that the
default in Python 3000. Of course, the question still remains what
mode 2.x should default to.

Collin Winter

From greg.ewing at canterbury.ac.nz  Fri May 12 01:39:26 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 12 May 2006 11:39:26 +1200
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
References: <5.1.1.6.0.20060510123134.01e68008@mail.telecommunity.com>
	<5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
Message-ID: <4463CB2E.4010204@canterbury.ac.nz>

Phillip J. Eby wrote:
> I'm only showing this example because I think getting rid of 
> __magic_names__ for operations could be a good thing for readability, and 
> it would remove an element of "magic" from today's Python.

Although overloadable functions are themselves somewhat
magical, so this could be seen as just replacing one
kind of magic by another.

> That *would* be a paradigm shift, albeit one that 
> I doubt many Python users would seriously object to.

On the contrary, I expect many Python users would
object to it very strenuously, unless they somehow
became convinced that the new paradigm was clearly
superior overall to the old one. I for one am very
much unconvinced of that.

--
Greg

From greg.ewing at canterbury.ac.nz  Fri May 12 01:56:53 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 12 May 2006 11:56:53 +1200
Subject: [Python-3000] i guess i was misunderstood
In-Reply-To: <1d85506f0605111027v3145da88o8e2314cac203064d@mail.gmail.com>
References: <1d85506f0605111027v3145da88o8e2314cac203064d@mail.gmail.com>
Message-ID: <4463CF45.3030309@canterbury.ac.nz>

tomer filiba wrote:

> b=B() # error, A.__init__ expects an instanc of A
> 
> why is this kind of type-checking enforced by the language?

Since type-class unification, there is no clear boundary
between built-in and user-defined classes. Any class can
potentially add C-level data to its instances and have
methods implemented in C that operate on it. If you were
allowed to pass any object to any method, there would
be a danger of crashing the interpreter.

> what this code does is basically changing the __mro__ of the object. had
> __mro__ been mutable, it would all be simpler.

Being able to change the mro after class creation would
lead to similar problems.

--
Greg

From qrczak at knm.org.pl  Fri May 12 02:01:21 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Fri, 12 May 2006 02:01:21 +0200
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <loom.20060511T224939-102@post.gmane.org> (talin@acm.org's
	message of "Thu, 11 May 2006 21:17:05 +0000 (UTC)")
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
	<4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda>
	<446375E5.2090500@acm.org>
	<ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>
	<da7032ce0605111335m38a241e3sbe49bc6fb0b804e3@mail.gmail.com>
	<ca471dc20605111340m4827ef83ge648c6f121d53568@mail.gmail.com>
	<loom.20060511T224939-102@post.gmane.org>
Message-ID: <87psik3ycu.fsf@qrnik.zagroda>

Talin <talin at acm.org> writes:

>    # Use as a function argument constraint
>    @generic
>    def flatten( x:concepts.iterable ):
>       ...
>
>    # Another overload
>    @generic
>    def flatten( x:concepts.associative ):

How are concepts defined?

How is it determined which specialization takes preference when
a function is specialized on several matching concepts?

(With generic functions based on types this is determined by
explicitly declared subtyping.)

> Testing for signatures, how about something like this:
>
>    def function( f:concepts.function( concepts.iterable, int ) )
>
> Which describes a function that takes an argument which is
> a function that takes an iterable and an int.

When such concept is called to test the claim against an object,
how does it determine whether the object is a function which takes
an iterable and an int?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From greg.ewing at canterbury.ac.nz  Fri May 12 02:10:55 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 12 May 2006 12:10:55 +1200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
Message-ID: <4463D28F.2040004@canterbury.ac.nz>

Fredrik Johansson wrote:

> Are people still positive regarding the idea of merging decimal and
> binary floats into the same type? (Or at least ensuring that they can
> be mixed seamlessly,

Er, I thought Decimals were explicitly designed *not*
to merge seamlessly with floats, so that one can't
accidentally lose the decimal exactness that one is
using Decimals for in the first place.

--
Greg

From pje at telecommunity.com  Fri May 12 03:30:45 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 11 May 2006 21:30:45 -0400
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <4463CB2E.4010204@canterbury.ac.nz>
References: <5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
	<5.1.1.6.0.20060510123134.01e68008@mail.telecommunity.com>
	<5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060511200052.01e5f030@mail.telecommunity.com>

At 11:39 AM 5/12/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>>I'm only showing this example because I think getting rid of 
>>__magic_names__ for operations could be a good thing for readability, and 
>>it would remove an element of "magic" from today's Python.
>
>Although overloadable functions are themselves somewhat
>magical, so this could be seen as just replacing one
>kind of magic by another.

Do you consider overloading in Java or C++ to be magical?  Okay, maybe a 
little in C++.  ;)


>>That *would* be a paradigm shift, albeit one that I doubt many Python 
>>users would seriously object to.
>
>On the contrary, I expect many Python users would
>object to it very strenuously, unless they somehow
>became convinced that the new paradigm was clearly
>superior overall to the old one. I for one am very
>much unconvinced of that.

I meant only the shift from typing "def __iter__(" to "defop iter(", 
irrespective of how it's implemented.  My assumption is that a majority of 
Python users would either not care which "magical" spelling was used, would 
like getting rid of the '__', or even rejoice at the fact that this allows 
them to create their own "magical" protocols without making up random new 
'__' names of their own.

In other words, I mean that if most people saw something like this in 
"What's new in Python 3.0", I don't think they would freak out:

"""Removal of __magic__ attributes

Special attribute names like '__iter__' have been replaced with use of the 
'defop' keyword, for example, 'defop iter(self)'.  Instead of defining a 
method named 'iter', 'defop iter' defines what the 'iter()' builtin will do 
when passed an object of the corresponding type.  This feature makes it 
easy to create new generic operations like iter() and len() without having 
to define special attribute names and avoid collisions.  See the table 
below for a complete list of translations..."""

Instead, I'd expect most people to view this as either neutral and of no 
consequence, or as a positive improvement in readability and reduction of 
magic.

(In other words, there would be One Obvious Way to Do It when you are 
defining operations that aren't limited to a particular class family, and 
the builtin-plus-magic-name convention would no longer be a special case 
for language-defined generic operations.)

I'm not saying my proposals in this regard are perfect.  I think there are 
a lot of places where corner cases need fleshing out, especially with 
regard to n-argument generics (like operator.add and other arithmetic 
operators) and this is all dependent upon having a sensible __signature__ 
system in place.

IOW, it's not a panacea, but I'm pretty positive it's implementable in a 
way that could be done even in Python 2.x using a __future__ statement for 
the 'defop' syntax, assuming we get type annotations of some kind in some 
2.x version.  I'm going to throw together a Python-only prototype to verify 
this, though.

(It would even be backward compatible as far as the Python/C API, btw -- in 
2.x 'defop' for builtins can be implemented by just setting the magic 
attributes, and I will prototype that in my pure-Python proof-of-concept.)


From steven.bethard at gmail.com  Fri May 12 04:30:53 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Thu, 11 May 2006 20:30:53 -0600
Subject: [Python-3000] Fw: typeclasses, duck-typing
In-Reply-To: <5.1.1.6.0.20060511200052.01e5f030@mail.telecommunity.com>
References: <5.1.1.6.0.20060510123134.01e68008@mail.telecommunity.com>
	<5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
	<4463CB2E.4010204@canterbury.ac.nz>
	<5.1.1.6.0.20060511200052.01e5f030@mail.telecommunity.com>
Message-ID: <d11dcfba0605111930k76c3f4b4n314a87d3ac12aca6@mail.gmail.com>

On 5/11/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> In other words, I mean that if most people saw something like this in
> "What's new in Python 3.0", I don't think they would freak out:
>
> """Removal of __magic__ attributes
>
> Special attribute names like '__iter__' have been replaced with use of the
> 'defop' keyword, for example, 'defop iter(self)'.  Instead of defining a
> method named 'iter', 'defop iter' defines what the 'iter()' builtin will do
> when passed an object of the corresponding type.  This feature makes it
> easy to create new generic operations like iter() and len() without having
> to define special attribute names and avoid collisions.  See the table
> below for a complete list of translations..."""

FWIW, I wouldn't freak out.  +0.5 on the general idea (and I'll avoid
any comment on the syntax since that's best left to a BDFL
pronouncement anyway).  I like the thought of making the introduction
of new protocols easier.  I expect that Python 3000 will continue in
the same way as Python 2.x, adding new protocols when someone figures
out a new way to make life easier. ;-)

I look forward to seeing your prototype.  Maybe as an example, you
could discuss how it could have eased the introduction of the
__index__() method introduced in 2.5?

STeVe
-- 
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From greg.ewing at canterbury.ac.nz  Fri May 12 04:50:39 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 12 May 2006 14:50:39 +1200
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <5.1.1.6.0.20060511200052.01e5f030@mail.telecommunity.com>
References: <5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
	<5.1.1.6.0.20060510123134.01e68008@mail.telecommunity.com>
	<5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
	<5.1.1.6.0.20060511200052.01e5f030@mail.telecommunity.com>
Message-ID: <4463F7FF.70803@canterbury.ac.nz>

Phillip J. Eby wrote:

> I meant only the shift from typing "def __iter__(" to "defop iter(", 
> irrespective of how it's implemented.

On its own, that's no more than a syntax change,
with very little to recommend it. With the associated
semantics you propose, it's a very deep change indeed.

> My assumption is that a majority 
> of Python users would either not care which "magical" spelling was used, 
> would like getting rid of the '__',

These are large assumptions, which I suspect are at
least 87.43% wrong. Don't make the mistake of thinking
that everyone has the same preferences as you.

 > """Removal of __magic__ attributes
 >
 > Special attribute names like '__iter__' have been replaced with use of the
 > 'defop' keyword, for example, 'defop iter(self)'.
 >
 > Instead, I'd expect most people to view this as either neutral and of no
 > consequence, or as a positive improvement in readability and reduction of
 > magic.

If that were all it said, I'd think "!#$#??? Why are they messing
around with something that's not broken?" (i.e. naming of special
methods).

If it went on to talk about generic functions, I'd be very
uncomfortable, because I still have deep reservations about
that whole idea.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+

From pje at telecommunity.com  Fri May 12 05:23:32 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 11 May 2006 23:23:32 -0400
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <4463F7FF.70803@canterbury.ac.nz>
References: <5.1.1.6.0.20060511200052.01e5f030@mail.telecommunity.com>
	<5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
	<5.1.1.6.0.20060510123134.01e68008@mail.telecommunity.com>
	<5.1.1.6.0.20060511101806.01e92d60@mail.telecommunity.com>
	<5.1.1.6.0.20060511200052.01e5f030@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060511230235.01e9b010@mail.telecommunity.com>

At 02:50 PM 5/12/2006 +1200, Greg Ewing wrote:
>These are large assumptions, which I suspect are at
>least 87.43% wrong. Don't make the mistake of thinking
>that everyone has the same preferences as you.

And that's about 51.7% patronizing; don't make the mistake of thinking that 
my assumption was based on my own preferences.  ;-)


>If that were all it said, I'd think "!#$#??? Why are they messing
>around with something that's not broken?" (i.e. naming of special
>methods).

I didn't say it's broken; that doesn't mean it couldn't be improved upon.

Nonetheless, I agree that if it were purely a syntactic change, it wouldn't 
be worth changing.


>If it went on to talk about generic functions, I'd be very
>uncomfortable, because I still have deep reservations about
>that whole idea.

It would be helpful if you could get those reservations out into the open, 
where they could become part of the process.

Guido has also expressed reservations, so I wouldn't worry about it too 
much.  My semi-proposal here is really a "wild fringe" idea in the overall 
scheme of things.  Think of it as an attempt to see what would happen if 
overloaded functions were fundamental to the language, such that:

1. all the built-in overloaded functions (iter(), len(), etc.) weren't 
special cases, but just implementations of something that any programmer 
can add to the language

2. there was a uniform way to add new implementations to an overloadable 
function

3. the overloading mechanism was itself overloadable, so that it could be 
extended for applications or frameworks with more specialized dispatch needs

4. type annotations on arguments can be used to specify what types an 
implementation applies to

My take on it so far is that if you do these things, you can get rid of a 
bunch of magic things -- possibly including the peculiarities of the 
current double-dispatch system for binary operators (including both 
arithmetic and comparison).

But my take doesn't really count; Guido's description of overloading as 
being a 20% niche certainly doesn't mesh with this approach.  But I don't 
know if his reasoning has more to do with an assumption that overloaded 
dispatching is necessarily complex.  There's nothing that stops a 
*particular* kind of overloading from being implemented by setting tp_* 
slots or __magic__ names under the hood.  I just think that we could make 
that an implementation detail, rather than the interface, just like we 
don't normally do this to create classes:

      someclass = type('someclass',(base1,base2),classdict)

nor do we normally get object attributes using 'getattr()' when 'foo.bar' 
will do.  So I think making overloading a uniform concept in terms of 
having syntax for it that uniformly applies to user-defined and built-in 
generic operations will simplify things nicely.

Now, if Guido decides that he *agrees* with me, *then* you should 
worry.  ;)  Until then, I would interpret his position as being against 
such a "radical" conceptual change, despite the fact that it would change 
the implementation hardly at all.  (I've spent some time sketching a Python 
implementation, and I think I can actually make it work uniformly in Python 
2.4 even for the existing built-ins like iter(), with a few kludges.  But I 
probably won't get it finished tonight.)


From talin at acm.org  Fri May 12 07:14:26 2006
From: talin at acm.org (Talin)
Date: Thu, 11 May 2006 22:14:26 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <87psik3ycu.fsf@qrnik.zagroda>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>	<loom.20060509T234801-751@post.gmane.org>	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>	<4462D9F7.6040605@acm.org>
	<874pzwk454.fsf@qrnik.zagroda>	<446375E5.2090500@acm.org>	<ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>	<da7032ce0605111335m38a241e3sbe49bc6fb0b804e3@mail.gmail.com>	<ca471dc20605111340m4827ef83ge648c6f121d53568@mail.gmail.com>	<loom.20060511T224939-102@post.gmane.org>
	<87psik3ycu.fsf@qrnik.zagroda>
Message-ID: <446419B2.9090908@acm.org>


Marcin 'Qrczak' Kowalczyk wrote:
> Talin <talin at acm.org> writes:
> 
> 
>>   # Use as a function argument constraint
>>   @generic
>>   def flatten( x:concepts.iterable ):
>>      ...
>>
>>   # Another overload
>>   @generic
>>   def flatten( x:concepts.associative ):
> 

> How are concepts defined?

Each concept is essentially a class, written in either Python or C, that 
defines a set of tests, and a set of introspection methods.

As to how the tests are defined, that really depends on the test.

> How is it determined which specialization takes preference when
> a function is specialized on several matching concepts?
> 
> (With generic functions based on types this is determined by
> explicitly declared subtyping.)

Probably by using a generalization of what happens with types. In many 
rule-based systems, the strategy for resolving conflicts is "most 
specific wins". If you think about it, this is exactly what happens when 
you use subtyping - a specific type wins over a more generalized type.

In order to extend this to concepts, you would need a way to compare 
predicates by specificity (which is a handy feature to have regardless.)

For any two predicates A & B, comparing them will produce one of four 
possible outcomes:

    1) A is a superset of B. In other words, any object that meets the 
criteria for B also meets the criteria for A.
    2) B is a superset of A.
    3) Neither A nor B overlap. So an object that meets the criteria for 
A can never meet the criteria for B and vice versa.
    4) There may or may not be some overlap between A and B.

Case 4 is simply means that cases 1, 2 and 3 cannot be proven. It might 
mean that A and B overlap, or it might mean that there's no overlap and 
we just don't know it.

When a dispatcher needs to decide which method to call, they can compare 
the predicates using the above outcomes. Assume that an object X matches 
both criteria A and B:

    1) A includes B: Choose B.
    2) B includes A: Choose A.
    3) A distinct from B: Can't ever happpen.
    4) A overlaps B (maybe).
       -- strict method: raise AmbiguousDispatch exception
       -- lenient method: Use a heuristic to determine which predicate
          accepts the smaller number of possible inputs.

Note that much of this decision making can be computed in advance (at 
the time that the decorators are run). The decorator could construct a 
decision tree at startup.

One question that this brings up is what about comparisons between types 
and concepts? I think the answer here is that the concepts will need to 
be smart enough to be able to look at a type and determine whether or 
not there is a potential overlap. For example, we know that an integer 
can never be an iterable and vice versa, so the iterable concept, when 
presented with an "int", can return "no overlap" when attempting to 
compare them.

>>Testing for signatures, how about something like this:
>>
>>   def function( f:concepts.function( concepts.iterable, int ) )
>>
>>Which describes a function that takes an argument which is
>>a function that takes an iterable and an int.
> 
> 
> When such concept is called to test the claim against an object,
> how does it determine whether the object is a function which takes
> an iterable and an int?

By looking at the function's signature information.

(By the way, I did mention that this was a "sketch", which means that it 
doesn't have all the details worked out yet.)

-- Talin

From talin at acm.org  Fri May 12 07:24:02 2006
From: talin at acm.org (Talin)
Date: Thu, 11 May 2006 22:24:02 -0700
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <da7032ce0605111335m38a241e3sbe49bc6fb0b804e3@mail.gmail.com>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>	<loom.20060509T234801-751@post.gmane.org>	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>	<4462D9F7.6040605@acm.org>
	<874pzwk454.fsf@qrnik.zagroda>	<446375E5.2090500@acm.org>	<ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>
	<da7032ce0605111335m38a241e3sbe49bc6fb0b804e3@mail.gmail.com>
Message-ID: <44641BF2.6090301@acm.org>

Mike Krell wrote:
> On 5/11/06, Guido van Rossum <guido at python.org> wrote:
> 
>>I think I'm more comfortable with a maximal taxonomy. In a maximal
>>taxonomy, I'd describe a large set of invariants, attributes,
>>behavior, etc., and say e.g. "this is how a file behaves". A
>>particular class can then claim to be a file by explicitly declaring
>>this (how that's spelled is a different issue -- it doesn't need to be
>>done by inheritance from an abstract base class or interface, it could
>>also be an arbitrary property, agreed upon by convention, or an
>>external registry of all file types, for example).
> 
> 
> If the route chosen is "agreed upon by convention" what is the
> difference between this and duck typing?  Are the "claim" and
> "convention" anything more than comments in the code?

The types that we are talking about are nothing more than duck types, so 
you are right about that part.

What's different is what we want to be able to *do* with the types.

A lot of modern programming languages get their power by being able to 
do reasoning with types. Virtual functions, generic functions, 
inheritance, multiple inheritance, polymorphism, and all these other 
aspects of typing can be thought of as a kind of "type calculus" - in 
other words, they are all a kind of mathematical function where one or 
more of the parameters is a type, and the result is different depending 
on what types you put into it.

The basic push behind this thread is to be able to do a similar kind of 
type calculus on duck types. Naturally, since the duck types have a more 
ambiguous definition than explicit types, the resulting calculus will 
need to be able to handle ambiguity (at the very minimum, by reporting 
it as an error.) But "fuzzy logic" can be just as formal and 
well-defined as "crisp logic".

-- Talin

From ncoghlan at gmail.com  Fri May 12 10:02:35 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 12 May 2006 18:02:35 +1000
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <446377D6.70807@acm.org>
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>	<loom.20060509T234801-751@post.gmane.org>	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>	<4462D9F7.6040605@acm.org>	<d11dcfba0605111027m2a1ee79qf742e41680707f56@mail.gmail.com>
	<446377D6.70807@acm.org>
Message-ID: <4464411B.9080001@gmail.com>

Talin wrote:
> Ideally, if we get the signature API that's been discussed, then lists 
> and tuples and such would have a constraint on their __getitem__ method:
> 
>     def __getitem__( self, index:int ):
>        ...

Don't forget those little beasties known as slices :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From Ben.Young at risk.sungard.com  Fri May 12 10:01:59 2006
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Fri, 12 May 2006 09:01:59 +0100
Subject: [Python-3000] Fw:  typeclasses, duck-typing
In-Reply-To: <5.1.1.6.0.20060511115329.03aa7e10@mail.telecommunity.com>
Message-ID: <OF0F76AD23.A0F3D312-ON8025716C.002B7080-8025716C.002C208A@risk.sungard.com>

"Phillip J. Eby" <pje at telecommunity.com> wrote on 11/05/2006 17:18:39:

> At 04:27 PM 5/11/2006 +0100, Ben.Young at risk.sungard.com wrote:
> >Why not
> >
> >class Foo(object):
> >         @specialize(arg(0))
> >         def core.len(self)
> >                 ...
> 
> Where does 'core' come from?  What is specialize for?  I don't 
understand 
> what you're proposing.
> 

Sorry, I didn't make myself very clear. What I was trying to give the 
impression of was something like C#s explicit interface methods, but 
without declaring the class implements an interface, and without adding 
new syntax (i.e defop). I think I meant the same as you really (although 
the method would appear in the class dict somehow). The core bit is just 
to show you are overloading the len method, rather than just defining a 
len method (as I have dropped defop). The specialize bit just tells you 
what args the multimethod is dispatching on, similar to your x:class bit 
you mentioned.

I know it's not a clear idea at the moment. If I have some time to play, 
I'll have a think and see if I can make it more concrete.

Cheers,
Ben

> 
> >I don't know how this would appear in the class dict though? 
self.len()?
> 
> In my proposal, 'defop' doesn't bind anything; it's just a statement 
that 
> defines a function object and then adds that function to the specified 
> 
> 


From tomerfiliba at gmail.com  Fri May 12 10:27:46 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Fri, 12 May 2006 10:27:46 +0200
Subject: [Python-3000] prototype OO?
In-Reply-To: <fb6fbf560605111119r3b52f8ddo284c93e8fec77bd8@mail.gmail.com>
References: <fb6fbf560605111119r3b52f8ddo284c93e8fec77bd8@mail.gmail.com>
Message-ID: <1d85506f0605120127n395c5cc7scc58420f0bc563d2@mail.gmail.com>

well, i was aiming more to the point of having no types at all: only a
lookup chain for attributes (kinda like the mro), but being mutable.
an object in the lookup chain is any getattr-able object, and the
langauge takes care for it. for example, doing x.y means
* first look at the instance, if it can provide "y"
* else, start climbing up the __mro__ of "x", see if any of those can
provide "y"
* else, raise AttributeError.

that said, types become a meaningless concept. i guess the object
should still retain a __class__ attribute or something like that, but
only for informational purposes (not direct usage)

instead, you'll just rely on duck typing ("the lookup chain") to find the
attributes you want:

def blah(f):
    f.write("blah blah blah")
    f.close()

and, in times you want early error detection, just test for the object
"protocol". this is useful when you do things with side effects, and you
want to prevent silly "oh i passed a wrong object" errors:

def blah(f):
    assert hasattr(f, "write")
    assert hasattr(f, "close")
    f.write("blah blah blah")
    f.close()

but this can get combersome, so i suggested to introduce an "isproto"
function, which is like multiple hasattrs at once, i.e.,

file_protocol = ["write", "read", "close"]
def blah(f):
    assert isproto(f, file_protocol)
    f.write("blah blah blah")
    f.close()

which can be shortened by the new optional typing syntax:
def blah(f : file_protocol):
    f.write("blah blah blah")
    f.close()

and then my goal is fulfilled: types are basically bags of attributes, nothing
magical.

of course we can (as perhaps should) add signatures to those "protocols",
i.e.

file_protocol = {
    "write" : Function(self, str_protocol),
    "read" : Function(self, number_protocol),
    "close" : Function(self),
}

and then isproto can also test the signatures, which is not possible with
today's isinstance.

then types become a flat list of "capabilities", as Talin called it. i guess a
better name can be proposed, but it's only semantics. the key issue is being
flat:

def read_lines_from_file(f : (file_protocol, iter_protocol)):
    for line in f:
        print line
    f.close()

f : (file_protocol, iter_protocol) means f has all the attributes
specified by the
two protocols: it has "write", "read", "close", and "__iter__". it's basically
the union of the two protocols: iter_file_proto = file_proto + iter_proto.

-----

class file:
    """the basic, binary file"""
    def __init__(self, name, mode = "r"):
        self.fd = os.open(name, mode)
    def write(self, data : str_proto):
        os.write(self.fd, data)
    def read(self, count : num_proto):
        return os.read(self.fd, count)
    def close(self):
        os.close(self.fd)

class textfile(file):
    def writeline(self, text : str_proto):
         self.write(text + "\n")
    def readline(self):
         line = ""
         while True:
            ch = self.read(1)
            if ch == "\n": break
            line += ch
         return line
    def __iter__(self):
         while True:
             line = self.readline()
             if not line: break
             yield line

# the lookup chain is [textfile, file]
t = textfile("....")
# calls __init__:
# since textfile doesnt have __init__, it's looked up at file,
# just as it happens today

isproto(t, iter_proto) # True
isproto(t, file_proto) # True
isproto(t, sequence_proto) # False

t.__lookupchain__.append( [1,2,3] ) # note it's an instance not a type!

isproto(t, sequence_proto) # True

# now you can do
t.append("hello")

and it will call the append of the list instance we added to the lookup chain.

------

Raymond Hettinger wrote:
> Boy = Object().clone(gender = 'male')
> def Boy.sayGender(self):
>    print self.gender
> Girl = Goy.clone(gender = 'female')
> m = Girl.clone(name=megan, age=3)
> m.sayGender()

class GenderSayyer:
     def sayGender(self):
         print self.gender

class Person:
     def __init__(self, gender):
         self.gender = gender

boy = Person("male")

# adding or remove "capabilties" at runtime
boy.__lookupchain__.append(GenderSayyer)
boy.sayGender() # male
boy.__lookupchain__.remove(GenderSayyer)
boy.sayGender() # AttributeError

------
Jim Jewett wrote:
> Proxies are certainly the perfect example of something where you would
> want a "just like X, except" object, and would prefer to be able to
> use instances as the prototype.

with this typeless approach:

class LoggingProxy:
    def __init__(self, realobj):
        self.__realobj = realobj
    def __getattr__(self, name):
        log_to_file("proxy now gets %r", % (name,))
        return getattr(self.__realobj, name)

p = LoggingProxy(5)
isproto(p, num_proto) # True
p + 4 # == 9
str(p) # "5"

------

to sum it up, types become meaningless: the "type of x" determines the
"lookup chain of x.y", and protocols are just sets of attributes that
"x should have in order to be considered z", which can also match specific
method signatures, unlike isinstance. this is what i call a typeless
language, and python is half-way there already. it just needs a slight push
over the edge ;-)


-tomer

On 5/11/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 5/11/06, tomer filiba <tomerfiliba at gmail.com> wrote:
>
> > class myFrame(derive_of(c.modules.wx.Frame)):
> >     ...
>
> > c.modules.wx.Frame is a proxy (instance) to a remote type, so you can't
> > derive from it directly. therefore, derive_of is
>
> > def derive_of(proxy_type):
> >     class cls(object):
> >         def  __getattr__(self, name):
> >             return getattr(proxy_type, name)
> >     return cls
>
> > which basically means that when the attribute doesn't belong to the
> > instance of local class, it is queried for at the remote class. but it doesnt
> > work, because the method checks for the instance's type.
>
> There are languages (Self; I think even javascript) whose OO is based
> on Prototypes rather than classes.  If an object doesn't have the
> attribute/method, then check its prototype (and so on recursively).
>
> When I have to emulate this in python (or Java), I just try to shove
> all my logic into classmethods, and use at most a singleton instance.
>
> Proxies are certainly the perfect example of something where you would
> want a "just like X, except" object, and would prefer to be able to
> use instances as the prototype.
>
> I don't think prototype OO should replace the current form, but it
> might be worth adding, even in Python 2.X.  Do you have a proposed
> implementation, or even a proposed syntax?
>
> -jJ
>

From ncoghlan at gmail.com  Fri May 12 10:39:23 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 12 May 2006 18:39:23 +1000
Subject: [Python-3000] Questions on optional type annotations
In-Reply-To: <43aa6ff70605111547j4096995ai1544ea1f80aed5c8@mail.gmail.com>
References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com>	<ca471dc20605102250n25323018ha658acff1af3ef3a@mail.gmail.com>
	<43aa6ff70605111547j4096995ai1544ea1f80aed5c8@mail.gmail.com>
Message-ID: <446449BB.4000005@gmail.com>

Collin Winter wrote:
> This exact thing (Function(type, type, ..., returns=type)) has been
> kicked around for inclusion in typecheck. One problem with using a
> keyword arg to indicate the return type means that functions passed in
> can't use that keyword argument themselves (unless you're not going to
> allow Function(arg1=type, arg2=type, ...)-style type annotations).
> 
> One solution to this might be that you can't use Function inline,
> using an attribute to declare the return type (which should default to
> None). This lends itself to solving the next issue...

[snip]

> Maybe we could let the user decide which mode to use. If we use an
> attribute to declare the return type, we could use another to indicate
> whether they want this particular Function() instance to be strict or
> lenient.

Both of these (return type annotation and selecting strict or lenient 
behaviour) can be done inline with the right methods on the annotation object.


class Annotate(object):

     def __init__(*args, **kwds):
         self, args = args[0], args[1:]
         self.arg_notes = args
         self.kwd_notes = kwds
         self.return_note = None
         self.strict = False

     @classmethod
     def strict(*args, **kwds):
         cls, args = args[0], args[1:]
         self = cls(*args, **kwds)
         self.strict = True
         return self

     def returns(self, note):
         self.return_note = note
         return self

     def __call__(self, func):
         func.__signature__.update_annotations(self)
         return func


@Annotate(str, str, int).returns(int)
def f(a, b, c=0):
     # some operation producing an int. . .

@Annotate.strict(str, str, int).returns(int)
def f(a, b, c=0):
     # some operation producing an int. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From qrczak at knm.org.pl  Fri May 12 12:45:24 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Fri, 12 May 2006 12:45:24 +0200
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <446419B2.9090908@acm.org> (talin@acm.org's message of "Thu, 11
	May 2006 22:14:26 -0700")
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
	<4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda>
	<446375E5.2090500@acm.org>
	<ca471dc20605111119j695a1b2ct1611f46f70a9b839@mail.gmail.com>
	<da7032ce0605111335m38a241e3sbe49bc6fb0b804e3@mail.gmail.com>
	<ca471dc20605111340m4827ef83ge648c6f121d53568@mail.gmail.com>
	<loom.20060511T224939-102@post.gmane.org>
	<87psik3ycu.fsf@qrnik.zagroda> <446419B2.9090908@acm.org>
Message-ID: <87slnfserf.fsf@qrnik.zagroda>

Talin <talin at acm.org> writes:

> For any two predicates A & B, comparing them will produce one of four 
> possible outcomes:
>
>     1) A is a superset of B. In other words, any object that meets the 
> criteria for B also meets the criteria for A.
>     2) B is a superset of A.
>     3) Neither A nor B overlap. So an object that meets the criteria for 
> A can never meet the criteria for B and vice versa.
>     4) There may or may not be some overlap between A and B.

I'm afraid that most practical cases would yield 4.

For predictably behaving libraries, rules of prioritizing specializers
must be clearly defined. Otherwise there will be issues like "how do I
teach Python that a matrix is not a number (even though it has arithmetic
operators) and not a mapping (even though it has indexing), so Python
doesn't try to apply specializations designed for numbers and mappings?",
or "how do I teach Python that compressed streams are a subtype of
file-like objects, so it chooses specializations of the former instead
of reporting a conflict?".

>        -- lenient method: Use a heuristic to determine which predicate
>           accepts the smaller number of possible inputs.

Heuristics make sense in optimization. Heuristic dispatch would be evil.

>> When such concept is called to test the claim against an object,
>> how does it determine whether the object is a function which takes
>> an iterable and an int?
>
> By looking at the function's signature information.

What if there is none (which is quite a common case)? The function
is not applicable to this argument, the dispatch doesn't choose this
specialization etc.? Then type signatures are no longer optional,
functions constructed by generic wrappers rather than written by hand
(e.g. partial applications) must provide some other means to specify
the signature, and this is quite a radical shift towards a paradigm
that I don't think Python would like.

> (By the way, I did mention that this was a "sketch", which means
> that it doesn't have all the details worked out yet.)

I claim that it's impossible to base sane details on this basis.
You can't have type information which is at the same time:
- flexible, so it can test arbitrary predicates
- with a computable inclusion relation, so it can be used for dispatch
- optional, so people can continue to write functions without type
  annotations
- predictable and explicit, so people can easily determine which
  interfaces are supported by which types
- implicit, based on duck typing, so capabilities are compared by
  structure rather than by name
etc.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From qrczak at knm.org.pl  Fri May 12 12:48:17 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Fri, 12 May 2006 12:48:17 +0200
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <4464411B.9080001@gmail.com> (Nick Coghlan's message of "Fri,
	12 May 2006 18:02:35 +1000")
References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com>
	<loom.20060509T234801-751@post.gmane.org>
	<ca471dc20605102230v7a104b98n7dcd9cf225280674@mail.gmail.com>
	<4462D9F7.6040605@acm.org>
	<d11dcfba0605111027m2a1ee79qf742e41680707f56@mail.gmail.com>
	<446377D6.70807@acm.org> <4464411B.9080001@gmail.com>
Message-ID: <87ody3semm.fsf@qrnik.zagroda>

Nick Coghlan <ncoghlan at gmail.com> writes:

> Talin wrote:
>> Ideally, if we get the signature API that's been discussed, then lists 
>> and tuples and such would have a constraint on their __getitem__ method:
>> 
>>     def __getitem__( self, index:int ):
>>        ...
>
> Don't forget those little beasties known as slices :)

And that a Patricia tree is a mapping, not a sequence, even though its
indices are integers.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From Ben.Young at risk.sungard.com  Fri May 12 13:33:45 2006
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Fri, 12 May 2006 12:33:45 +0100
Subject: [Python-3000] Fw:  Fw:  typeclasses, duck-typing
Message-ID: <OF71745ADE.F587559B-ON8025716C.003F78A2-8025716C.003F83D4@risk.sungard.com>

I've now had time to have a play with this, and I've developed the 
following implementation. It uses Guido's overloading module from his 
blog.



It's quite similar to your proposal, but not as short as it uses current 
python abilities. There's a little demo at the bottom.

Cheers,
Ben


from overloaded import overloaded

thisclass = object()

class overload(object):
    def __init__(self, to_overload, args):
        self.to_overload = to_overload
        self.args = args
 
    def __call__(self, func):
        if isinstance(func, overload):
            self.chain = func
            self.func = func.func
        else:
            self.chain = None
            self.func = func
        return self
 
    def apply(self, klass):
        newargs = self.args[:]
        for i, obj in enumerate(newargs):
            if obj is thisclass:
                newargs[i] = klass
        self.to_overload.register_func(newargs, self.func)
 
class overload_meta(type):
    def __new__(cls, name, bases, dict):
        replacements = []
        newtype = type.__new__(cls, name, bases, dict)
        for name, obj in dict.iteritems():
            if isinstance(obj, overload):
                while obj is not None:
                    obj.apply(newtype)
                    obj = obj.chain
                replacements.append(name)
        for name in replacements:
            delattr(newtype, name)
        return newtype
 
 
class mixin(object):
    __metaclass__ = overload_meta
 

if __name__ == "__main__":
    @overloaded 
    def len(sequence):
        count = 0
        for i in sequence:
            count += 1
        return count
 
    @overloaded
    def adder(lhs, rhs):
        raise TypeError("Can't add these classes")
 
    class Foo(mixin):
        def __init__(self, val):
            self.val = val
 
        def __repr__(self):
            return "<repr '%s'>" % (self.val,)
 
        @overload(len, [thisclass])
        def len(self):
            return self.val
 
        @overload(adder, [thisclass, int])
        @overload(adder, [thisclass, float])
        def add(self, rhs):
            return Foo(self.val + rhs)
 
        @overload(adder, [int, thisclass])
        @overload(adder, [float, thisclass])
        def radd(lhs, self):
            return Foo(self.val + lhs)
 
    f = Foo(5)
    print len(f)
    print adder(f, 2.0)
    print adder(2, f)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: protocol.py
Type: application/octet-stream
Size: 2240 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20060512/a598045f/attachment.obj 

From fredrik.johansson at gmail.com  Fri May 12 13:38:03 2006
From: fredrik.johansson at gmail.com (Fredrik Johansson)
Date: Fri, 12 May 2006 13:38:03 +0200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <4463D28F.2040004@canterbury.ac.nz>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4463D28F.2040004@canterbury.ac.nz>
Message-ID: <3d0cebfb0605120438u48914bau54e95547d8cfdd16@mail.gmail.com>

On 5/11/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> IMO, the free mixing decimal and binary floats is not a good idea.

On 5/12/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Er, I thought Decimals were explicitly designed *not*
> to merge seamlessly with floats, so that one can't
> accidentally lose the decimal exactness that one is
> using Decimals for in the first place.

I want to avoid writing code that looks like this:

    if isinstance(x, float):
        x += 0.1
    elif isinstance(x, Decimal):
        x += 0.1d

I don't see any difference between mixing binary and decimal floats,
and mixing decimals of different precision. I see why
decimalInstance+0.1 should be illegal if 0.1 evaluates to a binary
float, but the problem goes away if float literals evaluate to
decimals.

On 5/11/06, Raymond Hettinger <rhettinger at ewtllc.com> wrote:
> I write:

>   if n&1:
>      handle_odd()
>   else:
>      handle_even()

>IMO, functions like is_even() and is_odd() are clutter.  Also, the
>performance of &1 is unlikely to be matched function calls.

In your example, the problem is that same thing has to be stated
twice, so the gain from expressing it differently in different places
is an artificial one. More concretely, I can't recall ever seeing an
explicit reference to "handle_odd" directly after an n&1 test. The
information is usually contained entirely in the if-clause.

> When it comes to numerous small changes, it is better to create a third
> party extension and see how it fares in the real-world.  I suspect that
> such a module would be ignored.  If that turns out to be true, then it
> means that the additions to the standard library are not warranted.

Agreed, it is better to start by implementing library additions
externally. On the other hand, third-party utility libraries rarely
get used even when they could save trouble, because no one likes
dependencies outside the standard library. My personal utility library
for math-related stuff is decently sizable (about 10K lines of code);
I might pack some of it up for release some day.

Fredrik Johansson

From pje at telecommunity.com  Fri May 12 18:21:51 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 12 May 2006 12:21:51 -0400
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <mailman.53.1147428030.6753.python-3000@python.org>
Message-ID: <5.1.1.6.0.20060512120303.01e5c3f8@mail.telecommunity.com>

At 10:14 PM 5/11/2006 -0700, Talin <talin at acm.org> wrote:
>Marcin 'Qrczak' Kowalczyk wrote:
> > Talin <talin at acm.org> writes:
> >>   # Use as a function argument constraint
> >>   @generic
> >>   def flatten( x:concepts.iterable ):
> >>      ...
> >>
> >>   # Another overload
> >>   @generic
> >>   def flatten( x:concepts.associative ):
> >
> > How are concepts defined?
>
>Each concept is essentially a class, written in either Python or C, that
>defines a set of tests, and a set of introspection methods.

Note that they don't need to be classes.  Last night I checked in a sketch 
of extensible overloading:

     http://svn.python.org/projects/sandbox/trunk/Overload3K/

The doctest (overloading.txt) has an example of using a 1-argument 
overloaded function as a "concept", such that if the function can be called 
with an argument of that type, then it is considered to be of that type 
when dispatching.

I didn't have time to include overloading of built-in functions, so it uses 
a 'my_iter' function to be able to demo the "flatten()" use case.  I hope 
to add overloading of builtins (like iter()) tonight or over the weekend.

As currently written, the sketch will work with any sort of concept 
implementation you can come up with, as long as the concept relies only on 
tests that can be applied to an object's *type*, because the dispatching is 
based on a refactoring of Guido's overloaded function implementation, which 
relies on type-tuple caching for performance.

Basically, what I did is take Guido's implementation and then replace all 
of the hardcoded MRO manipulation with a single overloaded function, 
'implies()'.  The implies() function can be used to test dominance between 
signatures, or to test whether a signature applies to the invoked type 
signature.  There is also a second overloaded function, 'type_matches()', 
which is basically an overloadable form of 'issubclass()'.

With these minor alterations, the basic overloading machinery can now be 
used with any "concept" objects you care to implement.  All you have to do 
is define 'implies()' or 'type_matches()' methods for any combinations of 
concept and type that might need to be examined.

For example, the sketch defines overloads equivalent to these two declarations:

      defop type_matches(g1:overloaded, g2:overloaded)

      defop type_matches(g1:type, g2:overloaded)

These definitions allow two overloaded functions to be tested for which is 
more specific than the other, and allows a type to be tested against an 
overloaded function to see if it's suitable.

If you were to define a new 'concept' type, you would need to implement 
these methods:

      defop type_matches(g1:concept, g2:concept)

      defop type_matches(g1:type, g2:concept)

      defop type_matches(g1:concept, g2:overloaded)

      defop type_matches(g1:overload, g2:concept)

and if it's possible for a concept to imply a type, you would also need:

      defop type_matches(g1:concept, g2:type)

But once you had the methods, you would be able to freely mix your new 
concept implementation with other types in a function's signature for 
overloading purposes.

Note that these concept objects could be today's protocol or interface 
objects, or even arbitrary data like numbers or strings.  As long as you 
can define the appropriate set of 'type_matches' to allow signature matches 
and dominance to be computed, everything's super.  (No pun intended.)


From tim.peters at gmail.com  Fri May 12 18:45:04 2006
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 12 May 2006 12:45:04 -0400
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <3d0cebfb0605120438u48914bau54e95547d8cfdd16@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4463D28F.2040004@canterbury.ac.nz>
	<3d0cebfb0605120438u48914bau54e95547d8cfdd16@mail.gmail.com>
Message-ID: <1f7befae0605120945o60386aaga7ae1c9b01c36056@mail.gmail.com>

...

[Raymond Hettinger]
>> I write:
>>
>>   if n&1:
>>      handle_odd()
>>   else:
>>      handle_even()
>>
>> IMO, functions like is_even() and is_odd() are clutter.  Also, the
>> performance of &1 is unlikely to be matched function calls.

[Fredrik Johansson]
> In your example, the problem is that same thing has to be stated
> twice,

What did he state twice?  I see him checking the parity just once there.

> so the gain from expressing it differently in different places
> is an artificial one.

Sorry, I'm lost.

> More concretely, I can't recall ever seeing an explicit reference to
> "handle_odd" directly after an n&1 test. The information is usually
> contained entirely in the if-clause.

And more lost ;-)

I do the same kind of thing all the time; e.g., here from the tail end
of a hybrid modular/binary gcd function, which uses parity checks in
three places:

    # invariants:
    # a > b >= 0
    # a is odd
    # b is odd or 0
    while b:
        a %= b
        if a & 1:
            a = b-a
        assert a & 1 == 0
        a >>= 1
        if a:
            while a & 1 == 0:
                a >>= 1
        a, b = b, a

    return a << nbits

For a long time CPython took time proportional to the number of bits
in n to compute n&1, so it wasn't actually efficient, but recent
releases repaired that.  In any case the code is quite clear and
directly to the point.

From rasky at develer.com  Fri May 12 18:58:44 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Fri, 12 May 2006 18:58:44 +0200
Subject: [Python-3000] Math in Python 3.0
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com><4463D28F.2040004@canterbury.ac.nz><3d0cebfb0605120438u48914bau54e95547d8cfdd16@mail.gmail.com>
	<1f7befae0605120945o60386aaga7ae1c9b01c36056@mail.gmail.com>
Message-ID: <027701c675e5$53fb3350$bf03030a@trilan>

Tim Peters wrote:

> I do the same kind of thing all the time; e.g., here from the tail end
> of a hybrid modular/binary gcd function, which uses parity checks in
> three places:
>
>     # invariants:
>     # a > b >= 0
>     # a is odd
>     # b is odd or 0
>     while b:
>         a %= b
>         if a & 1:
>             a = b-a
>         assert a & 1 == 0
>         a >>= 1
>         if a:
>             while a & 1 == 0:
>                 a >>= 1
>         a, b = b, a
>
>     return a << nbits
>
> For a long time CPython took time proportional to the number of bits
> in n to compute n&1, so it wasn't actually efficient, but recent
> releases repaired that.  In any case the code is quite clear and
> directly to the point.

Since we're at it, do you have any idea on why Python is so slow when doing
such bit-full code?
See for instance
http://shootout.alioth.debian.org/debian/benchmark.php?test=nsievebits&lang=all,
where the Python version needs to play caching tricks to get some speed.
-- 
Giovanni Bajo


From tim.peters at gmail.com  Fri May 12 19:47:25 2006
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 12 May 2006 13:47:25 -0400
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <027701c675e5$53fb3350$bf03030a@trilan>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4463D28F.2040004@canterbury.ac.nz>
	<3d0cebfb0605120438u48914bau54e95547d8cfdd16@mail.gmail.com>
	<1f7befae0605120945o60386aaga7ae1c9b01c36056@mail.gmail.com>
	<027701c675e5$53fb3350$bf03030a@trilan>
Message-ID: <1f7befae0605121047i2364b52bw9f8375b6a439f443@mail.gmail.com>

[Giovanni Bajo]
|> Since we're at it, do you have any idea on why Python is so slow when doing
> such bit-full code?

Is it, compared to the other interpreted languages?  Doesn't look like
it.  The cost of going around the eval loop once utterly swamps the
cost of doing a bitwise operation on native ints, so relative
interpreter overhead is massive.

> See for instance
> http://shootout.alioth.debian.org/debian/benchmark.php?test=nsievebits&lang=all,
> where the Python version needs to play caching tricks to get some speed.

So they mandate use of an algorithm that's naive in several ways.
What a waste of time ;-)  You can get a strong speedup (at the cost of
strongly increased memory use) by using a vector of bits instead of
playing C-ish chunking games:

def primes_in_range(M) :
    bits = [1] * M
    count = 0
    for prime in xrange(2, M):
        if bits[prime]:
            count += 1
            bits[2*prime: M: prime] = [0] * ((M-1)//prime - 1)
    return count

That does "the inner loop" (turned into one slice assignment) at C
speed, so is much faster.

From fredrik.johansson at gmail.com  Fri May 12 20:01:25 2006
From: fredrik.johansson at gmail.com (Fredrik Johansson)
Date: Fri, 12 May 2006 20:01:25 +0200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <1f7befae0605120945o60386aaga7ae1c9b01c36056@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4463D28F.2040004@canterbury.ac.nz>
	<3d0cebfb0605120438u48914bau54e95547d8cfdd16@mail.gmail.com>
	<1f7befae0605120945o60386aaga7ae1c9b01c36056@mail.gmail.com>
Message-ID: <3d0cebfb0605121101y26978410lf26163a5264e5acb@mail.gmail.com>

On 5/12/06, Tim Peters <tim.peters at gmail.com> wrote:
> What did he state twice?  I see him checking the parity just once there.

The information "n is odd" appears once as "n&1" and once in the name
of a function. The point is that any if statement has the following
form:

    if conditionX:
        consequence of conditionX

So the if statement *inevitably* references conditionX twice, although
it may do so in form of a function or variable explicitly named
"conditionX" or implicitly in terms of code that the reader interprets
as "conditionX"/"consequence of conditionX".

Raymond's example code says "consequence of conditionX" explicitly
("handle_odd"). That's what I think is rare. Your code illustrates my
point:

    if a & 1:
        a = b-a

    while a & 1 == 0:
        a >>= 1

Here the heads read "conditionX" ("a is odd/even"), but "a = b-a" and
"a >>= 1" certainly aren't as trivial as "handle_odd", so in this case
the repetitiveness Raymond speaks about doesn't exist.

The version

    if isodd(a):
        a = b-a

    assert iseven(a)

    while iseven(a):
        a >>= 1

seems more readable to me. The advantage is perhaps questionable in
the context of any code that does bit manipulation (in which my mental
model of integers automatically turns them into bit strings), but not
all code that is concerned with whether a number is odd does that.

Anyway, the particular example of isodd/iseven wasn't the intended
topic of this thread. Better go ahead with that library so people can
try it to decide if there's anything in it they like instead of
arguing over trivialities on a mailing list :-)

Fredrik Johansson

From pje at telecommunity.com  Fri May 12 20:05:21 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 12 May 2006 14:05:21 -0400
Subject: [Python-3000] my take on "typeclasses"
In-Reply-To: <mailman.21534.1147453131.27774.python-3000@python.org>
Message-ID: <5.1.1.6.0.20060512131505.01e680d8@mail.telecommunity.com>

A quick disclaimer first: I'm not necessarily supporting Talin's proposal, 
because I don't entirely understand it, and I think it's more ambitious in 
scope and more vague in implementation details than what I'm proposing.  So 
I think he's proposing a superset of what I propose, and thus I only 
support the subset of his proposal that overlaps my own.  ;)


At 12:45 AM 5/12/2006 +0200, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> 
wrote:
>Talin <talin at acm.org> writes:
>
> > For any two predicates A & B, comparing them will produce one of four
> > possible outcomes:
> >
> >     1) A is a superset of B. In other words, any object that meets the
> > criteria for B also meets the criteria for A.
> >     2) B is a superset of A.
> >     3) Neither A nor B overlap. So an object that meets the criteria for
> > A can never meet the criteria for B and vice versa.
> >     4) There may or may not be some overlap between A and B.
>
>I'm afraid that most practical cases would yield 4.

Practical field experience with RuleDispatch begs to differ.  I'd suggest 
you read the Chambers & Chen papers on this, it clarifies quite well what 
is and isn't provable regarding criteria implication like this, for varying 
degrees of implementation complexity.

RuleDispatch does more than their implementation does, by adding 
implication support for simple inequalities, and there is a 
RuleDispatch-like system for Java that actually uses a theorem prover at 
compile time to do even more.

It's true in principle that you can always come up with some kind of 
criterion scenario that exceeds the limits of your current 
system.  However, in extensible systems like RuleDispatch and the Java one 
(JPred, I think?) you can always add new rules to the system for 
determining the precedence of rules.  The rarity with which this question 
comes up among RuleDispatch users suggests that it's not a common problem 
in practice.


>For predictably behaving libraries, rules of prioritizing specializers
>must be clearly defined. Otherwise there will be issues like "how do I
>teach Python that a matrix is not a number (even though it has arithmetic
>operators) and not a mapping (even though it has indexing), so Python
>doesn't try to apply specializations designed for numbers and mappings?",
>or "how do I teach Python that compressed streams are a subtype of
>file-like objects, so it chooses specializations of the former instead
>of reporting a conflict?".

By making the dispatch system itself accept rules, based on a simpler 
system.  See my sketch of such a system at:

     http://svn.python.org/projects/sandbox/trunk/Overload3K/

Although only 176 lines long (including docstrings and comments), it is 
sophisticated enough to allow definitions of new kinds of signature 
criteria, and rules for how they prioritize relative to one another.  It is 
limited only in that these rules can only use an object's *type* for 
criteria testing, but this limit is purely a side effect of the use of the 
classic "type-tuple cache" approach for the basic overloading 
implementation.  However, the framework defined in those 176 lines also 
allows other overloading implementations to be used, so the type limitation 
isn't an intrinsic one.

I think some future version of RuleDispatch will use this new framework to 
replace RuleDispatch's internal use of PyProtocols, and it would be awesome 
if some future version of Python with syntactic support for annotations and 
overloading could interoperate with it.



> >> When such concept is called to test the claim against an object,
> >> how does it determine whether the object is a function which takes
> >> an iterable and an int?
> >
> > By looking at the function's signature information.
>
>What if there is none (which is quite a common case)? The function
>is not applicable to this argument, the dispatch doesn't choose this
>specialization etc.? Then type signatures are no longer optional,
>functions constructed by generic wrappers rather than written by hand
>(e.g. partial applications) must provide some other means to specify
>the signature, and this is quite a radical shift towards a paradigm
>that I don't think Python would like.

For the language-supplied dispatch system that I propose, dispatch is only 
on argument *types*, so this introspect-the-signature thing you guys are 
talking about would not be available without user extensions.  I.e., a 
feature that allowed you to select an overload implementation by an 
argument's calling signature is definitely out of scope for my proposal.


>I claim that it's impossible to base sane details on this basis.
>You can't have type information which is at the same time:
>- flexible, so it can test arbitrary predicates
>- with a computable inclusion relation, so it can be used for dispatch
>- optional, so people can continue to write functions without type
>   annotations
>- predictable and explicit, so people can easily determine which
>   interfaces are supported by which types
>- implicit, based on duck typing, so capabilities are compared by
>   structure rather than by name
>etc.

My implementation sketch should suffice either as an existence proof that 
your claim is incorrect, or at the least provide you with a basis for 
clarifying your claim.

It is:

* flexible - it may be extended to support any kind of predicate that 
applies to argument types

* has a computable inclusion relation - as long as you implement the 
appropriate 'implies()' or 'type_matches()' methods

* optional - since clearly Python already works without it  :)

* predictable and explicit - since it is based entirely on declared overloads

* able to be implicit - since it allows membership in one overloadable 
function to be used as a dispatch criterion for inclusion in another  (and 
can easily be extended to support arbitrary combinations of inclusion, or 
even complex type signature tests like "argument X must be able to have an 
int added to it").

So unless I am misunderstanding your claim, it is incorrect.


From rasky at develer.com  Fri May 12 20:25:37 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Fri, 12 May 2006 20:25:37 +0200
Subject: [Python-3000] Math in Python 3.0
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4463D28F.2040004@canterbury.ac.nz>
	<3d0cebfb0605120438u48914bau54e95547d8cfdd16@mail.gmail.com>
	<1f7befae0605120945o60386aaga7ae1c9b01c36056@mail.gmail.com>
	<027701c675e5$53fb3350$bf03030a@trilan>
	<1f7befae0605121047i2364b52bw9f8375b6a439f443@mail.gmail.com>
Message-ID: <038301c675f1$771cebb0$bf03030a@trilan>

Tim Peters wrote:

> [Giovanni Bajo]
>>> Since we're at it, do you have any idea on why Python is so slow
>>> when doing such bit-full code?
>
> Is it, compared to the other interpreted languages?  Doesn't look like
> it.

Well, it seems like one of the few area where Python is slower than other
scripting languages.

> The cost of going around the eval loop once utterly swamps the
> cost of doing a bitwise operation on native ints, so relative
> interpreter overhead is massive.

Yup. I was wondering if there's something else that is a known issue and
could be optimized. It really "feels" a little too slower than it could be.

>> See for instance
>>
http://shootout.alioth.debian.org/debian/benchmark.php?test=nsievebits&lang=all,
>> where the Python version needs to play caching tricks to get some
>> speed.
>
> So they mandate use of an algorithm that's naive in several ways.
> What a waste of time ;-)  You can get a strong speedup (at the cost of
> strongly increased memory use) by using a vector of bits instead of
> playing C-ish chunking games:
>
> def primes_in_range(M) :
>     bits = [1] * M
>     count = 0
>     for prime in xrange(2, M):
>         if bits[prime]:
>             count += 1
>             bits[2*prime: M: prime] = [0] * ((M-1)//prime - 1)
>     return count
>
> That does "the inner loop" (turned into one slice assignment) at C
> speed, so is much faster.

Yeah, that's another benchmark in fact:
http://shootout.alioth.debian.org/debian/benchmark.php?test=nsieve&lang=all
and the existing Python solution is very similar to your proposed version :)

Mandating the use of bits is to measure performance for algorithms that
require bits. For instance, years ago I had implemented several ciphers in
pure Python, and they were little slow. Don't get me wrong, I knew they were
going to be slow, but just not *that* slow. Even if I've been using Python
as my primary language for some years now, it still feels like this kind of
bit manipulation is really slower than the "average" slowdown you expect
when you using Python.

I mean, it's just my feeling, so I might be very wrong. But the fact that
nsievebits is one of the *few* benchmarks where Python doesn't rate well
among other scripting languages make me believe there's something going on.
Also this one:
http://shootout.alioth.debian.org/debian/benchmark.php?test=partialsums&lang=all.
Even using the sum() builtin with a genexp is slower than the *naive*
for-loop implementation in other scripting languages.
-- 
Giovanni Bajo


From jdahlin at async.com.br  Fri May 12 22:24:33 2006
From: jdahlin at async.com.br (Johan Dahlin)
Date: Fri, 12 May 2006 17:24:33 -0300
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <e3vn2q$pr9$1@sea.gmane.org>
References: <loom.20060502T201105-105@post.gmane.org>	<e38g44$bfb$1@sea.gmane.org>	<44596963.8070200@canterbury.ac.nz>	<e3ga30$9sq$1@sea.gmane.org>	<e3qvqa$k6m$1@sea.gmane.org>	<4461428C.60803@canterbury.ac.nz>	<446256F9.50507@ieee.org>
	<4462B2FD.3070406@canterbury.ac.nz> <e3vn2q$pr9$1@sea.gmane.org>
Message-ID: <4464EF01.8050004@async.com.br>

Travis E. Oliphant wrote:
> Greg Ewing wrote:
>> Travis E. Oliphant wrote:
>>> The only thing I would wish different is to get rid of the PyGTK 
>>> dependency.   I think PyGUI should be a wrapper directly on top of GNOME
>> Perhaps you have Gnome and Gtk confused? Gnome is the
>> desktop, Gtk is the UI library that Gnome applications
>> use.
> 
> No, I understand the difference.  I was referring to the gnomeui 
> libraries which have a series of standard dialog boxes and higher-level 
> widgets that give the gnome desktop it's look-and-feel.   I realize that 
> gtk also has standard dialog boxes.
> 
> See, for example,  http://freshmeat.net/projects/libgnomeui/

You're still confused.

libgnomeui uses GTK+, it does in fact do very little on top of it.
It's also not used too much these days, it's been on the to-be-deprecated
list for a long while.
The current plan is to move it into GTK+ itself, most of it is already
done in GTK+ 2.10.

It's not possible to write an application using only libgnomeui, you need
to use GTK+ at some point.

Even so, if you want to start doing this from python you would need to have
some bindings, eg duplicating the work done in PyGTK.

> That sounds reasonable.   As I said before, I like the idea of PyGUI. 
> My main consternation is wxWindows.  I'm not a big fan of how wxPython 
> builds on top of wxWindows which builds on top of GTK which itself 
> builds on GDI which is itself a cross-platform layer on top of X11. 
> There are way too many layers of indirection there for my tastes.   As a 
> result, my (limited) experience with wxWindows on Linux has not been 
> pleasant.

GDI is windows only, you meant GDK.

wxWindows applications always seems to look very alien in a GNOME
environment, and they're usually slower and using more memory then
similar programs written using PyGTK.

Johan


From jdahlin at async.com.br  Fri May 12 22:27:55 2006
From: jdahlin at async.com.br (Johan Dahlin)
Date: Fri, 12 May 2006 17:27:55 -0300
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <1147367788.30914.11.camel@fsol>
References: <loom.20060502T201105-105@post.gmane.org>	<e38g44$bfb$1@sea.gmane.org>
	<44596963.8070200@canterbury.ac.nz>	<e3ga30$9sq$1@sea.gmane.org>
	<e3qvqa$k6m$1@sea.gmane.org>	<4461428C.60803@canterbury.ac.nz>
	<446256F9.50507@ieee.org>	<4462B2FD.3070406@canterbury.ac.nz>
	<e3vn2q$pr9$1@sea.gmane.org> <1147367788.30914.11.camel@fsol>
Message-ID: <4464EFCB.2060806@async.com.br>

Antoine Pitrou wrote:
> Le jeudi 11 mai 2006 ? 10:00 -0600, Travis E. Oliphant a ?crit :
>> That sounds reasonable.   As I said before, I like the idea of PyGUI. 
>> My main consternation is wxWindows.  I'm not a big fan of how wxPython 
>> builds on top of wxWindows which builds on top of GTK which itself 
>> builds on GDI which is itself a cross-platform layer on top of X11. 
> 
> You are mixing up a lot of things.
> AFAIK there is nothing named GDI in or under GTK. GDI is the drawing
> layer in Microsoft Windows.
> There is something named GDK which is a general non-graphical library to
> complement the C stdlib, not a "cross-platform layer on top of X11".

You're mixing up things too, you meant glib instead of GDK.
And GDK is a cross-platform layer originally designed to be very similar to
the Xlib API. It's been ported to Win32, Linux framebuffer, Cocoa and DirectFB.

> As if the layers of indirection were visible to the developer?
> How do you think less layers would have improved your developer
> experience?

More importantly, how native does the application feel? Does it integrate
with the rest of the desktop or does it live in it's own world?

Johan


From jdahlin at async.com.br  Fri May 12 22:27:55 2006
From: jdahlin at async.com.br (Johan Dahlin)
Date: Fri, 12 May 2006 17:27:55 -0300
Subject: [Python-3000] Requirements for a standard GUI library
In-Reply-To: <1147367788.30914.11.camel@fsol>
References: <loom.20060502T201105-105@post.gmane.org>	<e38g44$bfb$1@sea.gmane.org>
	<44596963.8070200@canterbury.ac.nz>	<e3ga30$9sq$1@sea.gmane.org>
	<e3qvqa$k6m$1@sea.gmane.org>	<4461428C.60803@canterbury.ac.nz>
	<446256F9.50507@ieee.org>	<4462B2FD.3070406@canterbury.ac.nz>
	<e3vn2q$pr9$1@sea.gmane.org> <1147367788.30914.11.camel@fsol>
Message-ID: <4464EFCB.2060806@async.com.br>

Antoine Pitrou wrote:
> Le jeudi 11 mai 2006 ? 10:00 -0600, Travis E. Oliphant a ?crit :
>> That sounds reasonable.   As I said before, I like the idea of PyGUI. 
>> My main consternation is wxWindows.  I'm not a big fan of how wxPython 
>> builds on top of wxWindows which builds on top of GTK which itself 
>> builds on GDI which is itself a cross-platform layer on top of X11. 
> 
> You are mixing up a lot of things.
> AFAIK there is nothing named GDI in or under GTK. GDI is the drawing
> layer in Microsoft Windows.
> There is something named GDK which is a general non-graphical library to
> complement the C stdlib, not a "cross-platform layer on top of X11".

You're mixing up things too, you meant glib instead of GDK.
And GDK is a cross-platform layer originally designed to be very similar to
the Xlib API. It's been ported to Win32, Linux framebuffer, Cocoa and DirectFB.

> As if the layers of indirection were visible to the developer?
> How do you think less layers would have improved your developer
> experience?

More importantly, how native does the application feel? Does it integrate
with the rest of the desktop or does it live in it's own world?

Johan

From tim.peters at gmail.com  Sat May 13 00:08:09 2006
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 12 May 2006 18:08:09 -0400
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <3d0cebfb0605121101y26978410lf26163a5264e5acb@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4463D28F.2040004@canterbury.ac.nz>
	<3d0cebfb0605120438u48914bau54e95547d8cfdd16@mail.gmail.com>
	<1f7befae0605120945o60386aaga7ae1c9b01c36056@mail.gmail.com>
	<3d0cebfb0605121101y26978410lf26163a5264e5acb@mail.gmail.com>
Message-ID: <1f7befae0605121508o77a369cdg58cfbafadb60373a@mail.gmail.com>

[Fredrik Johansson]
> The information "n is odd" appears once as "n&1" and once in the name
> of a function. The point is that any if statement has the following
> form:
>
>     if conditionX:
>         consequence of conditionX
>
> So the if statement *inevitably* references conditionX twice, although
> it may do so in form of a function or variable explicitly named
> "conditionX" or implicitly in terms of code that the reader interprets
> as "conditionX"/"consequence of conditionX".
>
> Raymond's example code says "consequence of conditionX" explicitly
> ("handle_odd"). That's what I think is rare.

I'd say it's non-existent.  I'm sure Raymond meant "handle_odd()" to
be _read_ as "whatever code you want to do in case it's odd", not as
"call the function named 'handle_odd'".

> Your code illustrates my point:
>
>     if a & 1:
>         a = b-a
>
>     while a & 1 == 0:
>         a >>= 1
>
> Here the heads read "conditionX" ("a is odd/even"), but "a = b-a" and
> "a >>= 1" certainly aren't as trivial as "handle_odd", so in this case
> the repetitiveness Raymond speaks about doesn't exist.

Except Raymond didn't say anything about repetitiveness.  What he did say:

    IMO, functions like is_even() and is_odd() are clutter.  Also, the
    performance of &1 is unlikely to be matched function calls.

> The version
>
>     if isodd(a):
>         a = b-a
>
>     assert iseven(a)
>
>     while iseven(a):
>         a >>= 1
>
> seems more readable to me. The advantage is perhaps questionable in
> the context of any code that does bit manipulation (in which my mental
> model of integers automatically turns them into bit strings), but not
> all code that is concerned with whether a number is odd does that.

Eh -- pretty much the same to me.  "n & 1" is so obvious and easy to
write & to read that I wouldn't waste a new builtin (let alone two
;-)) on it either.

> Anyway, the particular example of isodd/iseven wasn't the intended
> topic of this thread. Better go ahead with that library so people can
> try it to decide if there's anything in it they like instead of
> arguing over trivialities on a mailing list :-)

But that's what mailing lists are for :-)

From tim.peters at gmail.com  Sat May 13 01:03:51 2006
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 12 May 2006 19:03:51 -0400
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <038301c675f1$771cebb0$bf03030a@trilan>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4463D28F.2040004@canterbury.ac.nz>
	<3d0cebfb0605120438u48914bau54e95547d8cfdd16@mail.gmail.com>
	<1f7befae0605120945o60386aaga7ae1c9b01c36056@mail.gmail.com>
	<027701c675e5$53fb3350$bf03030a@trilan>
	<1f7befae0605121047i2364b52bw9f8375b6a439f443@mail.gmail.com>
	<038301c675f1$771cebb0$bf03030a@trilan>
Message-ID: <1f7befae0605121603m369d0584gc0c93531c320ed99@mail.gmail.com>

[Giovanni Bajo]
>>> Since we're at it, do you have any idea on why Python is so slow
>>> when doing such bit-full code?

[Tim Peters]
>> Is it, compared to the other interpreted languages?  Doesn't look like it.

[Giovanni]
> Well, it seems like one of the few area where Python is slower than other
> scripting languages.

To which I can only repeat:  Is it, compared to the other interpreted
languages?  Doesn't look like it.

I was judging from the URL you gave, which presumably was meant to
illustrate your point:

    http://shootout.alioth.debian.org/debian/benchmark.php?test=nsievebits&lang=all

Python is significantly faster than JavaScript, Tcl and Ruby there,
and in the same ballpark as Perl.  Those languages have comparable
implementations for low-level operations.  The biggest surprise there
to me is why Perl didn't do better, since it has a direct
implementation of bit vectors (albeit oddly spelled), so doesn't need
the long-winded source-code manipulations to extract byte and bit
offsets needed in the Python, JavaScript, Tcl and Ruby programs.  It's
not surprsing to me at all that the latter 4 languages are much slower
than compiled languages, although it was something of a surprise that
Ruby is _so_ much slower on this task.

>> The cost of going around the eval loop once utterly swamps the
>> cost of doing a bitwise operation on native ints, so relative
>> interpreter overhead is massive.

> Yup. I was wondering if there's something else that is a known issue and
> could be optimized. It really "feels" a little too slower than it could be.

For example, the CPython interpreter special-cases builtin short
integers in the BINARY_ADD and BINARY_SUBSCR opcodes.  It does not
special-case them in the BINARY_AND or UNARY_INVERT or BINARY_LSHIFT
(etc:  any of the bit-fiddling opcodes) opcodes.  Those go thru
full-blown OO dispatch:  it's more expensive to _find_ the function to
execute, and it's more expensive to call the function you eventually
find, than it is to do the work inside the function.

Some of Python's operators are also more powerful, such as that
int_lshift() will detect overflow and automatically switch to
unbounded ints when needed.

> ...
> Even if I've been using Python as my primary language for some
> years now, it still feels like this kind of bit manipulation is really
> slower than the "average" slowdown you expect when you using Python.

Bit manipulation on HW-size ints may well be a worst case for
languages of CPython's general implementation.

> I mean, it's just my feeling, so I might be very wrong. But the fact that
> nsievebits is one of the *few* benchmarks where Python doesn't rate well
> among other scripting languages

I guess I don't know what you mean by "scripting languages".  When I
look at the URL I see Python doing fine in comparison with the
languages I believe have similar niches and implementations

> ...
> Also this one:
> http://shootout.alioth.debian.org/debian/benchmark.php?test=partialsums&lang=all.
> Even using the sum() builtin with a genexp is slower than the *naive*
> for-loop implementation in other scripting languages.

I really don't know what you're comparing Python with.  I never think,
e.g., of Fortran, C, C++, Eiffel, Ada or Pascal as being "scripting
languages".  The fastest one there I may think of as being "a
scripting language" is Lua, and it did very well on this task indeed.

Anyway, I doubt this belongs on the P3K list, so enough.

From martin at v.loewis.de  Sat May 13 17:35:37 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 13 May 2006 17:35:37 +0200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
Message-ID: <4465FCC9.4000808@v.loewis.de>

Fredrik Johansson wrote:
> Python's current numeric model has serious problems.

Some of us (including myself) probably need enlightenment first:
what are the serious problems specifically?

> It's fine for
> calculating with nothing but floats, or nothing but ints, but writing
> code that works for ints, floats, complexes *and* Decimals - let alone
> for custom types such as mpfs or numeric arrays - is nearly
> impossible. Duck typing doesn't work because these types all have
> different interfaces, despite being functionally (or conceptually)
> equivalent for many purposes.

Why do you say that? To me, it seems that these types have all
*precisely* the same operations: +, -, *, /.

> Generic functions would solve most of the problem. I don't see this
> example being brought up often (perhaps I've just missed those posts),
> but I do think improved support for custom numeric types is a very
> strong motivation for implementing generic functions in Python 3.0.

My guess is that it isn't brought up very often because very few
people have the problem you are talking about.

Regards,
Martin


From martin at v.loewis.de  Sat May 13 17:49:05 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 13 May 2006 17:49:05 +0200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <445E970F.6020303@canterbury.ac.nz>
References: <mailman.20468.1146940506.27774.python-3000@python.org>	<Pine.GSO.4.58.0605071357030.23597@qew.cs>	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
	<445E970F.6020303@canterbury.ac.nz>
Message-ID: <4465FFF1.3020500@v.loewis.de>

Greg Ewing wrote:
>> If the implication here is that there is *no* GUI in the Python
>> standard library, I'd be cautious of this (-0, probably). Things like
>> the pydoc server use a little GUI window.
> 
> There *isn't* currently any GUI in the core distribution
> except on Windows. Non-Windows users already have to
> install Tk separately if they want to use IDLE or any
> of the other things that use it. So I don't see this as
> a big deal.

Not sure what you mean by "core distribution" here... The Python
source distribution? Well:

- there is no file IO in the core distribution; you need a stdio
  implementation on your machine
- there is no support for trigonometric functions in the core
  distribution, you need a math library
- there is no support for networking in the core distribution;
  you need a sockets library, and optionally also OpenSSL
and so on.

Or, perhaps, you are talking about the binary distributions
available from python.org? All binary distributions do include
Tkinter, including the Linux RPMs:

http://www.python.org/download/releases/2.4/rpms/

Of course, Linux users typically get Python from the CD-ROM
or network installation, and that always included Tkinter
(in addition to also including PyQt and others)

So yes, there is no guarantee that Tkinter is installed on
all systems that have Python installed (not even Windows),
but no, the core distribution does indeed include a GUI library.

Regards,
Martin

From fredrik.johansson at gmail.com  Sat May 13 22:23:41 2006
From: fredrik.johansson at gmail.com (Fredrik Johansson)
Date: Sat, 13 May 2006 22:23:41 +0200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <4465FCC9.4000808@v.loewis.de>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4465FCC9.4000808@v.loewis.de>
Message-ID: <3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>

On 5/13/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > It's fine for
> > calculating with nothing but floats, or nothing but ints, but writing
> > code that works for ints, floats, complexes *and* Decimals - let alone
> > for custom types such as mpfs or numeric arrays - is nearly
> > impossible. Duck typing doesn't work because these types all have
> > different interfaces, despite being functionally (or conceptually)
> > equivalent for many purposes.
>
> Why do you say that? To me, it seems that these types have all
> *precisely* the same operations: +, -, *, /.

For example, square roots are known as math.sqrt(x) for floats,
cmath.sqrt(x) for complex numbers, x.sqrt() for decimals, and
gmpy.sqrt(x)/gmpy.fsqrt(x) for gmpy's types. Oh, and SciPy has its own
sqrt function that works on arrays (but not Decimals or gmpy's types).

> My guess is that it isn't brought up very often because very few
> people have the problem you are talking about.

Perhaps they don't complain, but that doesn't mean that they wouldn't
appreciate the difference :-)

Fredrik Johansson

From talin at acm.org  Sat May 13 23:08:22 2006
From: talin at acm.org (Talin)
Date: Sat, 13 May 2006 14:08:22 -0700
Subject: [Python-3000] Use case for generics
Message-ID: <44664AC6.90701@acm.org>

One way of thinking about generic functions is that they are the dynamic 
languages' equivalent to C++ function overloading. Now, there are lots 
of valid (and some not-so-valid) use cases for function overloading; I'm 
just going to pick one of the most common ones.

Many GUI libraries have the concept of a "Rectangle" class which 
represents the area of a widget. Typically, a rectangle can be 
constructed in several ways:

1) From 4 scalars:

     r = Rectangle( x, y, w, h )

2) From two points, representing the top left and lower right corners:

     r = Rectangle( minpos, maxpos )

3) From a position and a size:

     r = Rectangle( position, size )

In order to support this last use case, a special "Size" class is 
defined which is distinct from the "Point" class, and which has "width, 
height" members instead of "x, y" members. (Essentiallly points and 
sizes are both 2D vectors, where points represent absolute locations and 
sizes represent relative locations.)

The following is an implementation, in Python, of a hypothetical 
Rectangle class using generic functions, followed by the same class 
without generics. I've tried my best to make the non-generic version as 
non-obfuscated as possible, so that the comparison would be fair.

(The non-generic version doesn't support keyword args, because I 
couldn't figure out how to do it cleanly; but I'm not sure whether the 
generic version would support keywords or not.)

(And I apologize that my whitespace conventions don't match the 
standard; I work hard to fix that in the PEPs, but its too much effort 
to fix that for this example.)

# Indicates a location in 2D space
class Point( object ):
     __slots__ = ( 'x', 'y' )

     def __init__( self, x, y ):
         self.x = x
         self.y = y

# The size of an item in 2D space
class Size( object ):
     __slots__ = ( 'w', 'h' )

     def __init__( self, w, h ):
         self.w = w
         self.h = h

# A rectanglar area in 2D space
class Rectangle( object ):
     __slots__ = ( 'x', 'y', 'w', 'h' )

     def __init__( self, x=0, y=0, w=0, h=0 ):
         self.x = x
         self.y = y
         self.w = w
         self.h = h

     def __init__( self, position:Point, size:Size ):
         self.x, self.y = position.x, position.y
         self.w, self.h = size.w, size.h

     def __init__( self, ulpos:Point, lrpos:Point ):
         self.x, self.y = ulpos.x, lrpos.y
         self.w = lrpos.x - ulpos.x
         self.h = lrpos.y - ulpos.y

# Same implementation but without generics
class Rectangle( object ):
     __slots__ = ( 'x', 'y', 'w', 'h' )

     def __init__( self, *args ):
         if len( args ) == 2 and isinstance( args[ 0 ], Point ):
             if isinstance( args[ 1 ], Point ):
                 self.from_ul_lr( *args )
             elif isinstance( args[ 1 ], Size ):
                 self.from_pos_size( *args )
             else:
                 raise TypeError
         else:
             self.from_scalars( *args )

     def from_scalars( self, x=0, y=0, w=0, h=0 ):
         self.x = x
         self.y = y
         self.w = w
         self.h = h

     def from_pos_size( self, position:Point, size:Size ):
         self.x, self.y = position.x, position.y
         self.w, self.h = size.w, size.h

     def from_ul_lr( self, ulpos:Point, lrpos:Point ):
         self.x, self.y = ulpos.x, lrpos.y
         self.w = lrpos.x - ulpos.x
         self.h = lrpos.y - ulpos.y


-- Talin


From edloper at gradient.cis.upenn.edu  Sun May 14 01:05:38 2006
From: edloper at gradient.cis.upenn.edu (Edward Loper)
Date: Sat, 13 May 2006 19:05:38 -0400
Subject: [Python-3000] Use case for generics
In-Reply-To: <44664AC6.90701@acm.org>
References: <44664AC6.90701@acm.org>
Message-ID: <44666642.6080002@gradient.cis.upenn.edu>

Talin wrote:
> One way of thinking about generic functions is that they are the dynamic 
> languages' equivalent to C++ function overloading. Now, there are lots 
> of valid (and some not-so-valid) use cases for function overloading; I'm 
> just going to pick one of the most common ones.
> 
> Many GUI libraries have the concept of a "Rectangle" class which 
> represents the area of a widget. Typically, a rectangle can be 
> constructed in several ways: [...]

For this use case, I don't think that a direct translation of the 
overloaded-constructor design for C++ carries over into Python as a good 
design.  In particular, I think this would be better coded in Python 
using either keyword arguments, or factory methods.  I.e., I'd rather 
see the interface be either:

class Rectangle:
     def __init__(self, top=None, left=None, topleft=None, bottom=None,
                  right=None, bottomright=None, width=None, height=None):
         """
         Construct a new rectangle with the given dimensions.  All
         arguments should be specified as keyword arguments.

         @raise ValueError: If the given arguments do not provide enough
             information to define the rectangle; or if they contain
             conflicting information.
         """
         ...

Or:

class Rectangle:
     def __init__(self, x, y, w, h): ...

     @classmethod
     def from_pos_size(self, pos, size): ...

     @classmethod
     from ul_lr(self, ulpos, lrpos): ...

(Note, this is not an argument against generic functions, which I think 
definitely have their uses; just an argument that this isn't a use case 
where I would choose to use them.)

-Edward

From ncoghlan at gmail.com  Sun May 14 03:01:20 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 14 May 2006 11:01:20 +1000
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>	<4465FCC9.4000808@v.loewis.de>
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
Message-ID: <44668160.7060709@gmail.com>

Fredrik Johansson wrote:
> For example, square roots are known as math.sqrt(x) for floats,
> cmath.sqrt(x) for complex numbers, x.sqrt() for decimals, and
> gmpy.sqrt(x)/gmpy.fsqrt(x) for gmpy's types. Oh, and SciPy has its own
> sqrt function that works on arrays (but not Decimals or gmpy's types).

Py3k's function overloading should fix this:

@overloaded
def sqrt(value):
     raise TypeError("Cannot take square root of %s" % type(value).__name__)

@sqrt.overload
def sqrt_float(value : float):
     return math.sqrt(value)

@sqrt.overload
def sqrt_complex(value : complex):
     return cmath.sqrt(value)

@sqrt.overload
def sqrt_decimal(value : decimal):
     return value.sqrt()

# Similar overloads can be added for the types in gmpy and numpy.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Sun May 14 03:22:33 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 14 May 2006 11:22:33 +1000
Subject: [Python-3000] Use case for generics
In-Reply-To: <44666642.6080002@gradient.cis.upenn.edu>
References: <44664AC6.90701@acm.org> <44666642.6080002@gradient.cis.upenn.edu>
Message-ID: <44668659.7020508@gmail.com>

Edward Loper wrote:
> (Note, this is not an argument against generic functions, which I think 
> definitely have their uses; just an argument that this isn't a use case 
> where I would choose to use them.)

Agreed - the use cases I see for function overloading in Python are more in 
the domain where the inputs to the function are conceptually "the same", but 
may require different handling due to implementation details.

The rectangle construction example doesn't quite fit into that category, as 
the different arguments are not conceptually the same.

However, where function overloading does come in is when you have a rectangle 
that looks something like Edward's:

class Rectangle:
      def __init__(self, x, y, w, h):
          ...

      @classmethod
      @overloaded
      def from_pos_size(cls, pos, size):
          return cls(pos.x, pos.y, size.w, size.h)

      @classmethod
      @overloaded
      def from_ul_lr(cls, ulpos, lrpos): ...
          x = ulpos.x
          y = ulpos.y
          return cls(x, y, lrpos.x - x, lrpos.y - y)


This rectangle assumes that positions are given as x & y coordinates, and 
sizes are given by 'w' and 'h' attributes.

A simple overload would let you use a different size object that wrote out the 
attribute names in full:

@Rectangle.from_pos_size.overload
def Rectangle_from_pos_MySize(cls, pos, size : MySize):
     return cls(pos.x, pos.y, size.width, size.height)

Or you might use complex numbers for positions and sizes instead of special 
classes:

@Rectangle.from_pos_size.overload
def Rectangle_from_complex_pos_size(cls, pos : complex, size : complex):
     return cls(pos.real, pos.imag, size.real, size.imag)

@Rectangle.from_ul_lr.overload
def Rectangle_from_ul_lr(cls, ul : complex, lr : complex):
     size = lr - ul
     return cls(ul.real, ul.imag, size.real, size.imag)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From greg.ewing at canterbury.ac.nz  Sun May 14 03:55:44 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 14 May 2006 13:55:44 +1200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <4465FFF1.3020500@v.loewis.de>
References: <mailman.20468.1146940506.27774.python-3000@python.org>
	<Pine.GSO.4.58.0605071357030.23597@qew.cs>
	<79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com>
	<445E970F.6020303@canterbury.ac.nz> <4465FFF1.3020500@v.loewis.de>
Message-ID: <44668E20.7@canterbury.ac.nz>

Martin v. L?wis wrote:

> Or, perhaps, you are talking about the binary distributions
> available from python.org? All binary distributions do include
> Tkinter, including the Linux RPMs:

My point was that not all platforms either come
with Tk installed or have Tk in the Python binary
installer, so you can't *use* Tkinter with an
out-of-the-box Python installation on those
platforms. So Tkinter might as well not be in
the binary installer for those platforms either.

It turns out I was behind the times in asserting
that all non-Windows platforms are like that.
But I'd be surprised if some such platforms did
not exist (e.g. non-Linux unices).

--
Greg

From greg.ewing at canterbury.ac.nz  Sun May 14 04:06:27 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 14 May 2006 14:06:27 +1200
Subject: [Python-3000] Use case for generics
In-Reply-To: <44664AC6.90701@acm.org>
References: <44664AC6.90701@acm.org>
Message-ID: <446690A3.8000907@canterbury.ac.nz>

Talin wrote:

>      r = Rectangle( x, y, w, h )
>      r = Rectangle( minpos, maxpos )
>      r = Rectangle( position, size )

This sort of thing is better done in Python using
keyword arguments:

   Rectangle(left = x, top = y, width = w, height = h)
   Rectangle(topleft = (x, y), size = (w,h))
   Rectangle(topleft = (x0, y0), botright = (x1, y1))

This is actually more flexible, because if implemented
appropriately it also allows things like

   Rectangle(size = (w, h), botright = (x, y))

which I've never seen anyone bother to provide in
a statically-typed Rectangle constructor -- it's
just too tedious to implement all the possible
combinations as separate function signatures.

--
Greg

From greg.ewing at canterbury.ac.nz  Sun May 14 04:09:20 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 14 May 2006 14:09:20 +1200
Subject: [Python-3000] Function overloading (Math in Python 3.0)
In-Reply-To: <44668160.7060709@gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4465FCC9.4000808@v.loewis.de>
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
	<44668160.7060709@gmail.com>
Message-ID: <44669150.8020808@canterbury.ac.nz>

Nick Coghlan wrote:

> Py3k's function overloading should fix this:

People are starting to talk about "Py3k's function overloading"
as though it were a done deal. Has anything actually been
decided about it yet.

--
Greg

From martin at v.loewis.de  Sun May 14 08:19:49 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 14 May 2006 08:19:49 +0200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>	
	<4465FCC9.4000808@v.loewis.de>
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
Message-ID: <4466CC05.6020303@v.loewis.de>

Fredrik Johansson wrote:
> For example, square roots are known as math.sqrt(x) for floats,
> cmath.sqrt(x) for complex numbers, x.sqrt() for decimals, and
> gmpy.sqrt(x)/gmpy.fsqrt(x) for gmpy's types. Oh, and SciPy has its own
> sqrt function that works on arrays (but not Decimals or gmpy's types).

Ah, I see.

>> My guess is that it isn't brought up very often because very few
>> people have the problem you are talking about.
> 
> Perhaps they don't complain, but that doesn't mean that they wouldn't
> appreciate the difference :-)

Speaking for myself only: I never worried that the square root is
spelled differently for different types. I use math.sqrt perhaps
twice a year, I don't recall ever using cmath.sqrt except to demonstrate
that it doesn't raise an exception for -1, and I heard of decimals.sqrt
and gmpy.sqrt the first time in your message.

So, for me, the problem doesn't exist.

I can't think of an obvious solution, either: math.sqrt and cmath.sqrt
are intentionally different functions. They both accept -1 (an integer)
as an argument, but produce different results. So despite them having
the same name, and despite them giving equal results for some arguments,
it doesn't feel to me that these functions should get unified.

Regards,
Martin

From collinw at gmail.com  Sun May 14 08:30:23 2006
From: collinw at gmail.com (Collin Winter)
Date: Sun, 14 May 2006 02:30:23 -0400
Subject: [Python-3000] Annotation classes (was: Questions on optional type
	annotations)
Message-ID: <43aa6ff70605132330q5eb35a40veba2d1eee796097f@mail.gmail.com>

On 5/12/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Both of these (return type annotation and selecting strict or lenient
> behaviour) can be done inline with the right methods on the annotation object.

[snip]

I've implemented this idea (a Function annotation, using Nick's
suggestion) in typecheck's SVN repository. Documentation [1] and a
tarball of the latest trunk revision [2] are available, and I'd like
feedback on the current design so I can start adding this idea to my
typechecking PEP.

The reception this idea has received (using utility classes to
provided enhanced typechecking) leads me to this question: what other
annotation classes should be provided? Would type unions and
intersections be best handled as utility classes (And, Or, Not, etc)
or as __and__ and __or__ on the type objects? Is it desirable that
users can write their own annotation classes that plug into the
typechecking system? If so, what hooks should be provided into the
system?

My typecheck library ships with a number of annotation classes (13 are
scheduled for inclusion in the upcoming 0.4 release; a sampling
follows) and provides several places where user-defined classes can
hook into the system:

1. Utility classes can hook into the @accepts, @returns and @yields
decorators (which define a callable's type signature) using a
__typesig__ classmethod. The system iterates over each item that makes
up the signature, asking if any annotation class knows how to handle
it (the first class to say "yes" wins). The annotation classes are
free to transform the object however they desire, though this normally
just involves handing the object off to the class's constructor.

2. Annotation classes almost always want to define a __typecheck__
instancemethod. When the typechecked callable is invoked,
__typecheck__ methods are where arguments and return values are
validated against annotation instances.

To signal displeasure with an object, __typecheck__ methods are free
to raise subclasses of the _TC_Exception class. These exceptions
bubble up the call stack, eventually resulting in highly detailed
error messages for the user. 19 such subclasses currently exist, and
users are free to define and raise their own exceptions (assuming they
subclass _TC_Exception and follow the API).

3. Three lesser-used hooks are __startchecking__, __switchchecking__
and __stopchecking__. For example, a function with @accepts applied
result in __startchecking__ and __stopchecking__ signals once the
system had finished checking all the function's arguments. (All
classes that define these hooks are notified at the same time.) A
function with @accepts and @returns would issue __startchecking__
signals when the system started checking the function's arguments and
__stopchecking__ once the function's return values had been validated.
__switchchecking__ exists to handle generators, where a function might
have both @accepts and @yields applied; once the function returns the
generator, the system stops checking the function and starts checking
the generator.

These hooks exist primarily to provide support for the type variables machinery.

To register an annotation class with the system, a
typecheck.register_type() function is provided. This will cause the
class's hook methods to be called at the proper times.

While this may seem like flexibility overkill, this design has made it
very easy to add new annotation classes. I started out with basic And,
Or, Not and Xor type operations and have since used this system to add
support for functions-as-typecheckers [3], ==-equality assertions
(Exact), interface specifiation (HasAttr), type variables [4],
callable()-ness, iterable-ness and typeclasses, among others. In
addition, this same mechanism is used to support Python's built-in
set, dict, list and tuple types. (To read about all of typecheck's
annotation classes, see [5].)

Is there interest in including a hook-based system like this in Python
2.x and 3.x's respective type annotation systems?

Thanks,
Collin Winter

[1] - http://oakwinter.com/code/typecheck/dev/utility/function.html
[2] - http://oakwinter.com/code/typecheck/dist/typecheck-svn-latest.tar.gz
[3] - http://oakwinter.com/code/typecheck/dev/tutorial/functions_as_types.html
[4] - http://oakwinter.com/code/typecheck/dev/tutorial/typevariables.html
[5] - http://oakwinter.com/code/typecheck/dev/utility/index.html

From martin at v.loewis.de  Sun May 14 08:41:11 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 14 May 2006 08:41:11 +0200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <44668160.7060709@gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>	<4465FCC9.4000808@v.loewis.de>
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
	<44668160.7060709@gmail.com>
Message-ID: <4466D107.1040606@v.loewis.de>

Nick Coghlan wrote:
> Py3k's function overloading should fix this:
> 
> @overloaded
> def sqrt(value):
>     raise TypeError("Cannot take square root of %s" % type(value).__name__)
> 
> @sqrt.overload
> def sqrt_float(value : float):
>     return math.sqrt(value)
> 
> @sqrt.overload
> def sqrt_complex(value : complex):
>     return cmath.sqrt(value)
> 
> @sqrt.overload
> def sqrt_decimal(value : decimal):
>     return value.sqrt()
> 
> # Similar overloads can be added for the types in gmpy and numpy.

So where would that sqrt function live? I hope you are not proposing it
becomes a builtin - I dearly wish there were fewer builtins, not more.

Regards,
Martin

From g.brandl at gmx.net  Sun May 14 09:29:17 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 14 May 2006 09:29:17 +0200
Subject: [Python-3000] Use case for generics
In-Reply-To: <446690A3.8000907@canterbury.ac.nz>
References: <44664AC6.90701@acm.org> <446690A3.8000907@canterbury.ac.nz>
Message-ID: <e46l5f$qs$1@sea.gmane.org>

Greg Ewing wrote:
> Talin wrote:
> 
>>      r = Rectangle( x, y, w, h )
>>      r = Rectangle( minpos, maxpos )
>>      r = Rectangle( position, size )
> 
> This sort of thing is better done in Python using
> keyword arguments:
> 
>    Rectangle(left = x, top = y, width = w, height = h)
>    Rectangle(topleft = (x, y), size = (w,h))
>    Rectangle(topleft = (x0, y0), botright = (x1, y1))

... and which looks like another possible use case for keyword-only
arguments.

Georg


From solipsis at pitrou.net  Sun May 14 13:04:45 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 14 May 2006 13:04:45 +0200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <44668160.7060709@gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4465FCC9.4000808@v.loewis.de>
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
	<44668160.7060709@gmail.com>
Message-ID: <1147604685.4625.5.camel@fsol>

Le dimanche 14 mai 2006 ? 11:01 +1000, Nick Coghlan a ?crit :
> Fredrik Johansson wrote:
> > For example, square roots are known as math.sqrt(x) for floats,
> > cmath.sqrt(x) for complex numbers, x.sqrt() for decimals, and
> > gmpy.sqrt(x)/gmpy.fsqrt(x) for gmpy's types. Oh, and SciPy has its own
> > sqrt function that works on arrays (but not Decimals or gmpy's types).
> 
> Py3k's function overloading should fix this:

Or you can just write value**0.5
(which doesn't work with decimals, however)




From rasky at develer.com  Sun May 14 13:16:02 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Sun, 14 May 2006 13:16:02 +0200
Subject: [Python-3000] Math in Python 3.0
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>	<4465FCC9.4000808@v.loewis.de><3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com><44668160.7060709@gmail.com>
	<4466D107.1040606@v.loewis.de>
Message-ID: <0c2301c67747$c8ed0e00$0d412597@bagio>

Martin v. L?wis <martin at v.loewis.de> wrote:

>> @overloaded
>> def sqrt(value):
>>     raise TypeError("Cannot take square root of %s" %
>> type(value).__name__)
>>
>> @sqrt.overload
>> def sqrt_float(value : float):
>>     return math.sqrt(value)
>>
>> @sqrt.overload
>> def sqrt_complex(value : complex):
>>     return cmath.sqrt(value)
>>
>> @sqrt.overload
>> def sqrt_decimal(value : decimal):
>>     return value.sqrt()
>>
>> # Similar overloads can be added for the types in gmpy and numpy.
>
> So where would that sqrt function live? I hope you are not proposing
> it becomes a builtin - I dearly wish there were fewer builtins, not
> more.


"math" would be fine for all builtin types. For other types, imported from
modules, such as numpy, they could add their overload to math.sqrt at
import-time.

Giovanni Bajo


From rasky at develer.com  Sun May 14 13:20:32 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Sun, 14 May 2006 13:20:32 +0200
Subject: [Python-3000] Math in Python 3.0
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>	<4465FCC9.4000808@v.loewis.de><3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
	<44668160.7060709@gmail.com>
Message-ID: <0c7301c67748$69e7d6f0$0d412597@bagio>

Nick Coghlan <ncoghlan at gmail.com> wrote:

>> For example, square roots are known as math.sqrt(x) for floats,
>> cmath.sqrt(x) for complex numbers, x.sqrt() for decimals, and
>> gmpy.sqrt(x)/gmpy.fsqrt(x) for gmpy's types. Oh, and SciPy has its
>> own sqrt function that works on arrays (but not Decimals or gmpy's
>> types).
>
> Py3k's function overloading should fix this:
>
> @overloaded
> def sqrt(value):
>      raise TypeError("Cannot take square root of %s" %
> type(value).__name__)
>
> @sqrt.overload
> def sqrt_float(value : float):
>      return math.sqrt(value)
>
> @sqrt.overload
> def sqrt_complex(value : complex):
>      return cmath.sqrt(value)
>
> @sqrt.overload
> def sqrt_decimal(value : decimal):
>      return value.sqrt()
>
> # Similar overloads can be added for the types in gmpy and numpy.


So, are we totally dropping the "special-cased __ method" that worked so fine
till now? I can "overload" abs() for my point type (to return its modulus) just
by defining a __abs__, and it works fine. In such a world (called Python 2.x),
I wouldn't find so strange if I had a __sqrt__.

It's just a different way of dispatching, in the end. But I think that we
should use a consistent way for, eg., all the math functions.

Giovanni Bajo


From martin at v.loewis.de  Sun May 14 13:40:02 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 14 May 2006 13:40:02 +0200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <0c2301c67747$c8ed0e00$0d412597@bagio>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>	<4465FCC9.4000808@v.loewis.de><3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com><44668160.7060709@gmail.com>
	<4466D107.1040606@v.loewis.de>
	<0c2301c67747$c8ed0e00$0d412597@bagio>
Message-ID: <44671712.2010704@v.loewis.de>

Giovanni Bajo wrote:
>>> @overloaded
>>> def sqrt(value):
>>>     raise TypeError("Cannot take square root of %s" %
>>> type(value).__name__)
>>>
>>> @sqrt.overload
>>> def sqrt_float(value : float):
>>>     return math.sqrt(value)
>>>
>> So where would that sqrt function live?
> 
> "math" would be fine for all builtin types. For other types, imported from
> modules, such as numpy, they could add their overload to math.sqrt at
> import-time.

That wouldn't quite work: sqrt(float) would cause a stack overflow for
calling itself.

In any case, I still wonder whether these functions should be unified
when they have different semantics (e.g. when passing negative ints or
floats to math.sqrt vs. cmath.sqrt).

Regards,
Martin

From p.f.moore at gmail.com  Sun May 14 14:00:49 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 14 May 2006 13:00:49 +0100
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <0c7301c67748$69e7d6f0$0d412597@bagio>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4465FCC9.4000808@v.loewis.de>
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
	<44668160.7060709@gmail.com> <0c7301c67748$69e7d6f0$0d412597@bagio>
Message-ID: <79990c6b0605140500h202688f9g3d959977e887cd7f@mail.gmail.com>

On 5/14/06, Giovanni Bajo <rasky at develer.com> wrote:
> So, are we totally dropping the "special-cased __ method" that worked so fine
> till now? I can "overload" abs() for my point type (to return its modulus) just
> by defining a __abs__, and it works fine. In such a world (called Python 2.x),
> I wouldn't find so strange if I had a __sqrt__.

That's one of the arguments for function overloading - you can't add a
__sqrt__ method to types (e.g., float) that don't already have them,
so special __ methods are less flexible than overloading (which *can*
be defined externally to the argument's class).

Whether it's a sufficient benefit to justify (a) adding a function
overloading mechanism to the language/stdlib, or (b) changing existing
special methods to use overloading instead, is still undecided.

> It's just a different way of dispatching, in the end.

True.

> But I think that we should use a consistent way for, eg., all the math functions.

Possibly. But I can't see that it's plausible to add all the possible
math functions as special methods - __sqrt__, __log__, __sin__,
__tanh__, __arcsin__, ... how far do you go? So if you want
consistency, you're really arguing for function overloading. And
you're back to the question of whether the benefit is sufficient to
justify the extensive change in philosophy.

(FWIW, I like function overloading, and I'd love to see language or
stdlib support. I can see the arguments for using it in place of
existing special methods, but I'm nervous of the extent of that
change. If I had to decide *right now*, I'd go for adding overloading,
but retaining special methods where they are currently in use - a
"practicality beats purity" approach, but possibly too cautious for
Py3K where the idea should be to avoid worrying about legacy
issues.......)

Paul.

From ncoghlan at gmail.com  Sun May 14 15:17:02 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 14 May 2006 23:17:02 +1000
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <79990c6b0605140500h202688f9g3d959977e887cd7f@mail.gmail.com>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>	
	<4465FCC9.4000808@v.loewis.de>	
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>	
	<44668160.7060709@gmail.com> <0c7301c67748$69e7d6f0$0d412597@bagio>
	<79990c6b0605140500h202688f9g3d959977e887cd7f@mail.gmail.com>
Message-ID: <44672DCE.3010006@gmail.com>

Paul Moore wrote:
> (FWIW, I like function overloading, and I'd love to see language or
> stdlib support. I can see the arguments for using it in place of
> existing special methods, but I'm nervous of the extent of that
> change. If I had to decide *right now*, I'd go for adding overloading,
> but retaining special methods where they are currently in use - a
> "practicality beats purity" approach, but possibly too cautious for
> Py3K where the idea should be to avoid worrying about legacy
> issues.......)

I don't think I've ever said it explicitly, but this is pretty much where I'm 
sitting at the moment on the function overloading front - support it, but have 
default implementations for various operations that fall back on the existing 
magic methods.

After all, Py3k's informal motto is "get rid of the accumulated cruft" rather 
than "break the world". Getting rid of the magic methods is a bit too much of 
the latter for my liking :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From rasky at develer.com  Sun May 14 16:12:29 2006
From: rasky at develer.com (Giovanni Bajo)
Date: Sun, 14 May 2006 16:12:29 +0200
Subject: [Python-3000] Math in Python 3.0
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>	
	<4465FCC9.4000808@v.loewis.de>	
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>	
	<44668160.7060709@gmail.com> <0c7301c67748$69e7d6f0$0d412597@bagio>
	<79990c6b0605140500h202688f9g3d959977e887cd7f@mail.gmail.com>
	<44672DCE.3010006@gmail.com>
Message-ID: <002601c67760$6f8809f0$b14c2a97@bagio>

Nick Coghlan <ncoghlan at gmail.com> wrote:

>> (FWIW, I like function overloading, and I'd love to see language or
>> stdlib support. I can see the arguments for using it in place of
>> existing special methods, but I'm nervous of the extent of that
>> change. If I had to decide *right now*, I'd go for adding
>> overloading,
>> but retaining special methods where they are currently in use - a
>> "practicality beats purity" approach, but possibly too cautious for
>> Py3K where the idea should be to avoid worrying about legacy
>> issues.......)
>
> I don't think I've ever said it explicitly, but this is pretty much
> where I'm sitting at the moment on the function overloading front -
> support it, but have default implementations for various operations
> that fall back on the existing magic methods.
>
> After all, Py3k's informal motto is "get rid of the accumulated
> cruft" rather than "break the world". Getting rid of the magic
> methods is a bit too much of the latter for my liking :)


Well, but there's really no reason why I should use __abs__ to do one thing,
and an overloaded sqrt to do another. Py3k is where we can fix these things to
give consistencies. If we want a better numeric model for Python, __ special
reserved methods just don't scale. Under this point of view, __abs__ is a
design mistake which ought to be fixed.

Another issue I would like to bring up is that of performance. Using __ special
methods, dispatching can be done in constant time, since it's basically a
lookup on the operand's class. The various implementations of overloaded
functions I have seen require a linear-time lookup among overloaded functions.
I remember that OO programming was initially ignored (in the 70's) because it
was deemed to be too slow -- then somebody came up with the idea of the virtual
tables. It would be too bad to go backwards in this regard.

Thus another solution would be to use a dispatch similar of that of the magic
methods, but without the namespace issue ("__methods__ " are reserved of the
implementaiton IIRC). If it was "legal" to add a __sqrt__ (or similarly named
method), I wouldn't have problem with this approach.

Giovanni Bajo


From g.brandl at gmx.net  Sun May 14 19:11:54 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 14 May 2006 19:11:54 +0200
Subject: [Python-3000] Math in Python 3.0
In-Reply-To: <44671712.2010704@v.loewis.de>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>	<4465FCC9.4000808@v.loewis.de><3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com><44668160.7060709@gmail.com>	<4466D107.1040606@v.loewis.de>	<0c2301c67747$c8ed0e00$0d412597@bagio>
	<44671712.2010704@v.loewis.de>
Message-ID: <e47n9t$jor$1@sea.gmane.org>

Martin v. L?wis wrote:
> Giovanni Bajo wrote:
>>>> @overloaded
>>>> def sqrt(value):
>>>>     raise TypeError("Cannot take square root of %s" %
>>>> type(value).__name__)
>>>>
>>>> @sqrt.overload
>>>> def sqrt_float(value : float):
>>>>     return math.sqrt(value)
>>>>
>>> So where would that sqrt function live?
>> 
>> "math" would be fine for all builtin types. For other types, imported from
>> modules, such as numpy, they could add their overload to math.sqrt at
>> import-time.
> 
> That wouldn't quite work: sqrt(float) would cause a stack overflow for
> calling itself.
> 
> In any case, I still wonder whether these functions should be unified
> when they have different semantics (e.g. when passing negative ints or
> floats to math.sqrt vs. cmath.sqrt).

I think that cmath should stay separated. It operates on an entirely different
set of numbers, while all the other methods all work on real numbers that
just happen to be represented differently.

Georg


From tomerfiliba at gmail.com  Sun May 14 19:56:03 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Sun, 14 May 2006 19:56:03 +0200
Subject: [Python-3000] Use case for generics
In-Reply-To: <1d85506f0605141012s460485e8g19e741fbe48eaf5e@mail.gmail.com>
References: <1d85506f0605141012s460485e8g19e741fbe48eaf5e@mail.gmail.com>
Message-ID: <1d85506f0605141056u207254f5mbfa887716c7b025@mail.gmail.com>

Edward Loper wrote:
> For this use case, I don't think that a direct translation of the
> overloaded-constructor design for C++ carries over into Python as a good
> design.  In particular, I think this would be better coded in Python
> using either keyword arguments, or factory methods.  I.e., I'd rather
> see the interface be either:

i agree that c++ paradigms don't necessarily fit the "python spirit", at least
directly. i'm pro different functions for different things (i.e.,
from_size_and_pos et al), and the current mechanisms fit it well enough.

but i just wanted to note one case where i wish i has overloading:constructors.
for example, the socket class:

class _socketobject(object):
   def __init__(self, family=AF_INET, type=SOCK_STREAM, proto=0, _sock=None):
       if _sock is None:
           _sock = _realsocket(family, type, proto)
       self._sock = _sock
[...]
   def dup(self):
       return _socketobject(_sock=self._sock)

for once, you want
s = socket.socket(AF_INET, SOCK_STREAM)
i.e., creating a NEW socket.

but you also want to be able to wrap existing objects or to initialize them
externally, i.e., just create an instance of the class and the actual
initialization would be done by *your* code, not __init__'s. the latter
case can be achieved with cls.__new__(cls), but it's kind of ugly...

what i'd like is

class _socketobject(object):
   @overload
   def __init__(self, family=AF_INET, type=SOCK_STREAM, proto=0):
       ... create a NEW socket

   @overload
   def __init__(self, existing_sock):
        ... wrap an existing sockets

this is one point that keyword arguments by themselves can't solve the
problem.

but apart from constructors, i can't think of any case where
from_size_and_point isn't the best solution.



-tomer

> From: Talin <talin <at> acm.org>
> Subject: Use case for generics
> Newsgroups: gmane.comp.python.python-3000.devel
> Date: 2006-05-13 21:08:22 GMT (20 hours and 2 minutes ago)
>
> One way of thinking about generic functions is that they are the dynamic
> languages' equivalent to C++ function overloading. Now, there are lots
> of valid (and some not-so-valid) use cases for function overloading; I'm
> just going to pick one of the most common ones.
>
> Many GUI libraries have the concept of a "Rectangle" class which
> represents the area of a widget. Typically, a rectangle can be
> constructed in several ways:
>
> 1) From 4 scalars:
>
>      r = Rectangle( x, y, w, h )
>
> 2) From two points, representing the top left and lower right corners:
>
>      r = Rectangle( minpos, maxpos )
>
> 3) From a position and a size:
>
>      r = Rectangle( position, size )
>
> In order to support this last use case, a special "Size" class is
> defined which is distinct from the "Point" class, and which has "width,
> height" members instead of "x, y" members. (Essentiallly points and
> sizes are both 2D vectors, where points represent absolute locations and
> sizes represent relative locations.)
>
> The following is an implementation, in Python, of a hypothetical
> Rectangle class using generic functions, followed by the same class
> without generics. I've tried my best to make the non-generic version as
> non-obfuscated as possible, so that the comparison would be fair.
>
> (The non-generic version doesn't support keyword args, because I
> couldn't figure out how to do it cleanly; but I'm not sure whether the
> generic version would support keywords or not.)
>
> (And I apologize that my whitespace conventions don't match the
> standard; I work hard to fix that in the PEPs, but its too much effort
> to fix that for this example.)
>
> # Indicates a location in 2D space
> class Point( object ):
>      __slots__ = ( 'x', 'y' )
>
>      def __init__( self, x, y ):
>          self.x = x
>          self.y = y
>
> # The size of an item in 2D space
> class Size( object ):
>      __slots__ = ( 'w', 'h' )
>
>      def __init__( self, w, h ):
>          self.w = w
>          self.h = h
>
> # A rectanglar area in 2D space
> class Rectangle( object ):
>      __slots__ = ( 'x', 'y', 'w', 'h' )
>
>      def __init__( self, x=0, y=0, w=0, h=0 ):
>          self.x = x
>          self.y = y
>          self.w = w
>          self.h = h
>
>      def __init__( self, position:Point, size:Size ):
>          self.x, self.y = position.x, position.y
>          self.w, self.h = size.w, size.h
>
>      def __init__( self, ulpos:Point, lrpos:Point ):
>          self.x, self.y = ulpos.x, lrpos.y
>          self.w = lrpos.x - ulpos.x
>          self.h = lrpos.y - ulpos.y
>
> # Same implementation but without generics
> class Rectangle( object ):
>      __slots__ = ( 'x', 'y', 'w', 'h' )
>
>      def __init__( self, *args ):
>          if len( args ) == 2 and isinstance( args[ 0 ], Point ):
>              if isinstance( args[ 1 ], Point ):
>                  self.from_ul_lr( *args )
>              elif isinstance( args[ 1 ], Size ):
>                  self.from_pos_size( *args )
>              else:
>                  raise TypeError
>          else:
>              self.from_scalars( *args )
>
>      def from_scalars( self, x=0, y=0, w=0, h=0 ):
>          self.x = x
>          self.y = y
>          self.w = w
>          self.h = h
>
>      def from_pos_size( self, position:Point, size:Size ):
>          self.x, self.y = position.x, position.y
>          self.w, self.h = size.w, size.h
>
>      def from_ul_lr( self, ulpos:Point, lrpos:Point ):
>          self.x, self.y = ulpos.x, lrpos.y
>          self.w = lrpos.x - ulpos.x
>          self.h = lrpos.y - ulpos.y
>
> -- Talin
>

From skip at pobox.com  Wed May 17 04:00:01 2006
From: skip at pobox.com (skip at pobox.com)
Date: Tue, 16 May 2006 21:00:01 -0500
Subject: [Python-3000] test
Message-ID: <17514.33697.778283.413068@montanaro.dyndns.org>

Sorry for the intrusion.  Checking to see if Mailman is constipated or
not...

Skip


From kayschluehr at gmx.de  Wed May 17 07:00:30 2006
From: kayschluehr at gmx.de (Kay Schluehr)
Date: Wed, 17 May 2006 07:00:30 +0200
Subject: [Python-3000] State of the object system
In-Reply-To: <17514.33697.778283.413068@montanaro.dyndns.org>
References: <17514.33697.778283.413068@montanaro.dyndns.org>
Message-ID: <446AADEE.7070205@gmx.de>

I wonder what is the current state of type/class unification i.e. "new 
style classes"?

The Python 2.5 library reference ( chapter 2.3 ) still states that this 
issue is being "far from complete".
( BTW this signals the user that the object system is quite immature and 
early alpha. Maybe one should
rethink commenting the current state of development all over the public 
docs? )

Since we discuss new features here I would like to listen what people 
think about opening builtin types?
So far Python has a protective policy to not let users add a method to 
e.g. an int or str. Is there a deeper
design issue or is it for pure implementation/optimization reasons?

Regards








From mcherm at mcherm.com  Wed May 17 14:35:03 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Wed, 17 May 2006 05:35:03 -0700
Subject: [Python-3000] State of the object system
Message-ID: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>

Kay Schluehr writes:
> I wonder what is the current state of type/class unification i.e.  
> "new style classes"?
>
> The Python 2.5 library reference ( chapter 2.3 ) still states that  
> this issue is being "far from complete".

The current state is this: Python has already introduced "new style classes"
which do provide type/class unification. Now it IS possible to subclass
built-in types like int, string, list, and dict. However, for backward
compatibility reasons, the "old style classes" were not removed. There
are very minor and obscure differences in behavior between new style
classes and old style classes which shouldn't affect most users, but
we believe strongly in supporting backward compatibility where possible.

In Python 3000 (AKA Py3K, AKA Python 3.0) we are intentionally breaking
backward compatibility to remove cruft. Old style classes will go away
and all classes will be new style.

> ( BTW this signals the user that the object system is quite immature  
> and early alpha. Maybe one should
> rethink commenting the current state of development all over the  
> public docs? )

You are completely correct. The manual is misleading and makes the state
of things sound far worse than it is. We probably ought to update the
manual. Thanks for pointing it out.

> Since we discuss new features here I would like to listen what  
> people think about opening builtin types?
> So far Python has a protective policy to not let users add a method  
> to e.g. an int or str. Is there a deeper
> design issue or is it for pure implementation/optimization reasons?

Yes, please do discuss the idea here... it would be very much on-topic
for this list (more so than some of the other conversations going on
<wink>).

For the most part, Python does not strongly encourage users to modify
existing classes (like Ruby does). Instead, we encourage subclassing
to add new features -- and that already works fine for built-in classes.
However, this is more of a practice than a prohibition... it IS
possible to modify existing classes in Python. Here's an example:

   >>> myInstance = MyClass()
   >>> myInstance.func1(42)
   func1(42)
   >>> def func2(self, x):
           print 'func2(%s)' % x
   >>> MyClass.func2 = func2
   >>> myInstance.func2(42)
   func2(42)

Unfortunately, for implementation reasons you can't modify most
built-in (and some user-defined) classes in this fashion:

   >>> int.func2 = func2

   Traceback (most recent call last):
     File "<pyshell#35>", line 1, in -toplevel-
       int.func2 = func2
   TypeError: can't set attributes of built-in/extension type 'int'

Most Python programmers would probably agree that this is a
perfectly fine restriction. Built-in classes like int and dict
are widely used... allowing the code from any one module to
modify them has dangerously non-local effects. (Yes, I know...
it works OK for Ruby... but I, for one, am still wary.) If
your code really needs to modify the behavior of int (or dict
or whatever) then use a subclass of int (or dict or whatever)
in your own code which you can modify freely.

But if you've got a convincing argument (preferably with use
cases that are only poorly addressed by today's Python) for why
this behavior ought to be added to Py3K... please let us know!

-- Michael Chermside

From g.brandl at gmx.net  Wed May 17 16:06:55 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 17 May 2006 16:06:55 +0200
Subject: [Python-3000] State of the object system
In-Reply-To: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>
References: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>
Message-ID: <e4fam0$geo$1@sea.gmane.org>

Michael Chermside wrote:

>> ( BTW this signals the user that the object system is quite immature  
>> and early alpha. Maybe one should
>> rethink commenting the current state of development all over the  
>> public docs? )
> 
> You are completely correct. The manual is misleading and makes the state
> of things sound far worse than it is. We probably ought to update the
> manual. Thanks for pointing it out.

I tried to come up with a better wording in rev. 46023.

Georg


From janssen at parc.com  Wed May 17 17:10:43 2006
From: janssen at parc.com (Bill Janssen)
Date: Wed, 17 May 2006 08:10:43 PDT
Subject: [Python-3000] back with more GUI planning in a few days...
In-Reply-To: Your message of "Tue, 09 May 2006 10:44:54 PDT."
	<4460D516.6090305@fas.harvard.edu> 
Message-ID: <06May17.081048pdt."58641"@synergy1.parc.xerox.com>

> Bill Janssen wrote:
> > There are three big operating system platforms, true.  And clearly
> > each has its own associated window system.  But there's also AJAX 
> 
> How exactly would a good Python GUI "cover" AJAX?

Ivan,

Looks like Google has beaten us to the punch by answering this
question with code:

http://code.google.com/webtoolkit/

This is an AJAX GUI toolkit for Java.  They haven't tried to integrate
it with Swing, but the source code is suggestive.  Here's "hello, world":

public class Hello implements EntryPoint {

  public void onModuleLoad() {
    Button b = new Button("Click me", new ClickListener() {
      public void onClick(Widget sender) {
        Window.alert("Hello, AJAX");
      }
    });

    RootPanel.get().add(b);
  }
}

Bill

From tomerfiliba at gmail.com  Wed May 17 19:29:01 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Wed, 17 May 2006 10:29:01 -0700
Subject: [Python-3000] exceptions with keyword arguments
Message-ID: <1d85506f0605171029m678ebab7q99903a1486890611@mail.gmail.com>

hi all

i would like to suggest changing the base-exception class, whatever
it may be (Exception/BaseException) to work with keyword arguments
instead of positional ones.

instead of

try:
    ...
except IOError, ex:
    print ex[1]
# or
except IOError, (code, text, filename):
    ...
    # which means changes to code/text/filename do not change
    # the exception object

use

try:
    raise IOError(filename = "lala", code=17, text="blah blah blah")
except IOError, ex:
    ex.code = 18
    raise

raise IndexError("invalid index", index = the_index)
raise KeyError("key not found", key = the_key)
raise AttributeError("attribute not found", name = name)

where the new exception can be something like

class Exception:
    def __init__(self, message = None, **kw):
        self._message = message
        self.__dict__.update(kw)
    def __repr__(self):
        attrs = sorted("%s = %r" % (k, v)
                       for k, v in self.__dict__.iteritems()
                       if not k.startswith("_"))
        return "<%s(%s, %s)>" % (self.__class__.__name__,
            self._message, ", ".join(attrs))

class IOError(Exception):
   pass

raise IOError(code = 17, text = "EBLAH", filename = "lalala")

the builtin errors might want to enforce an "exception signature",

class ExceptionSignature(Exception):
    attributes = []
    def __init__(self, *args, **kw):
         for name in self.attributes:
             assert name in kw, "expected an attribute named %s" % (name,)
         Exception.__init__(self, *args, **kw)

class IOError(ExceptionSignature):
    attributes = ["code", "text", "filename"]

or something like that, so the attributes of the exception are part
of its official interface.

rationale:
* today, AttributeError's are raised as
AttributeError("%s object has no attribute %s" % ...)
which means analyzing the exception requires parsing text!
 * IOError (among others), for instance, does nasty and not-so-well documented
overloading of named/positional arguments: when you pass 1-3 arguments,
they are stored in .args, but also in .errno, .strerror, and
.filename. if you pass
more than 3 arguments, the attributes are all set to None and only
.args is filled.
yuck.

you can see this for reference:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496698

----

that said, i would also want to introduce ArgumentError. there are
many times just a ValueError isn't enough. instead, having a builtin
ArgumentError would made things more clear:

def write_to_file(the_file):
    if the_file.closed:
        raise ArgumentError("the file must be open", name = "the_file")
    the_file.write(...)

and with ArgumentError included, calling functions with invalid
signatures would also raise ArgumentError. TypeError is quite
silly in this case, as it has nothing to do with the *type* of
the function or its arguments.

>>> def f(a): pass
>>> f(1,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
*TypeError*: f() takes exactly 1 argument (2 given)
>>> type(f)
<type 'function'> # like any other function

TypeError is too-broadly overloaded this way.


-tomer

From brett at python.org  Wed May 17 20:43:34 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 17 May 2006 11:43:34 -0700
Subject: [Python-3000] exceptions with keyword arguments
In-Reply-To: <1d85506f0605171029m678ebab7q99903a1486890611@mail.gmail.com>
References: <1d85506f0605171029m678ebab7q99903a1486890611@mail.gmail.com>
Message-ID: <bbaeab100605171143n4b028b92kf1d386081840489c@mail.gmail.com>

On 5/17/06, tomer filiba <tomerfiliba at gmail.com> wrote:
>
> hi all
>
> i would like to suggest changing the base-exception class, whatever
> it may be (Exception/BaseException) to work with keyword arguments
> instead of positional ones.



Positional support is deprecated; there will only be support for a single
argument.  Read PEP 352 to see how BaseException will end up in Python 3000.

And I brought this up with Guido once and he was not enthusiastic about it.
Basically, keep exceptions simple.  They are important and basic enough to
keep it simple.  If you want fancier support, subclass Exception and add the
support you want.

-Brett


instead of
>
> try:
>     ...
> except IOError, ex:
>     print ex[1]
> # or
> except IOError, (code, text, filename):
>     ...
>     # which means changes to code/text/filename do not change
>     # the exception object
>
> use
>
> try:
>     raise IOError(filename = "lala", code=17, text="blah blah blah")
> except IOError, ex:
>     ex.code = 18
>     raise
>
> raise IndexError("invalid index", index = the_index)
> raise KeyError("key not found", key = the_key)
> raise AttributeError("attribute not found", name = name)
>
> where the new exception can be something like
>
> class Exception:
>     def __init__(self, message = None, **kw):
>         self._message = message
>         self.__dict__.update(kw)
>     def __repr__(self):
>         attrs = sorted("%s = %r" % (k, v)
>                        for k, v in self.__dict__.iteritems()
>                        if not k.startswith("_"))
>         return "<%s(%s, %s)>" % (self.__class__.__name__,
>             self._message, ", ".join(attrs))
>
> class IOError(Exception):
>    pass
>
> raise IOError(code = 17, text = "EBLAH", filename = "lalala")
>
> the builtin errors might want to enforce an "exception signature",
>
> class ExceptionSignature(Exception):
>     attributes = []
>     def __init__(self, *args, **kw):
>          for name in self.attributes:
>              assert name in kw, "expected an attribute named %s" % (name,)
>          Exception.__init__(self, *args, **kw)
>
> class IOError(ExceptionSignature):
>     attributes = ["code", "text", "filename"]
>
> or something like that, so the attributes of the exception are part
> of its official interface.
>
> rationale:
> * today, AttributeError's are raised as
> AttributeError("%s object has no attribute %s" % ...)
> which means analyzing the exception requires parsing text!
> * IOError (among others), for instance, does nasty and not-so-well
> documented
> overloading of named/positional arguments: when you pass 1-3 arguments,
> they are stored in .args, but also in .errno, .strerror, and
> .filename. if you pass
> more than 3 arguments, the attributes are all set to None and only
> .args is filled.
> yuck.
>
> you can see this for reference:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496698
>
> ----
>
> that said, i would also want to introduce ArgumentError. there are
> many times just a ValueError isn't enough. instead, having a builtin
> ArgumentError would made things more clear:
>
> def write_to_file(the_file):
>     if the_file.closed:
>         raise ArgumentError("the file must be open", name = "the_file")
>     the_file.write(...)
>
> and with ArgumentError included, calling functions with invalid
> signatures would also raise ArgumentError. TypeError is quite
> silly in this case, as it has nothing to do with the *type* of
> the function or its arguments.
>
> >>> def f(a): pass
> >>> f(1,2)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> *TypeError*: f() takes exactly 1 argument (2 given)
> >>> type(f)
> <type 'function'> # like any other function
>
> TypeError is too-broadly overloaded this way.
>
>
> -tomer
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060517/1138f9ad/attachment.htm 

From lists at janc.be  Wed May 17 21:12:34 2006
From: lists at janc.be (Jan Claeys)
Date: Wed, 17 May 2006 21:12:34 +0200
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <200605111540.39210.fdrake@acm.org>
References: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
	<200605081159.03756.fdrake@acm.org>
	<1147374392.1025.24.camel@localhost.localdomain>
	<200605111540.39210.fdrake@acm.org>
Message-ID: <1147893155.14132.42.camel@localhost.localdomain>

Op do, 11-05-2006 te 15:40 -0400, schreef Fred L. Drake, Jr.:
> On Thursday 11 May 2006 15:06, Jan Claeys wrote:
>  > Why would ordinary end-users of an application written in Python need
>  > distutils?  They will get their application as a py2exe executable (or
>  > similar) on Windows, as a distro package on linux and on Mac OS X there
>  > is py2app IIRC.  And even if they had distutils installed, most of them
>  > won't know how to use it.
> 
> If there's no distro package (not unusual), they'd download the source package 
> and need to run "python setup.py install".  They need both Python and 
> distutils in that case.

No, most of them would just use another program that doesn't require
them to "program in DOS"...


-- 
Jan Claeys


From tjreedy at udel.edu  Wed May 17 21:21:14 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 17 May 2006 15:21:14 -0400
Subject: [Python-3000] State of the object system
References: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>
Message-ID: <e4ft38$qjg$1@sea.gmane.org>


"Michael Chermside" <mcherm at mcherm.com> wrote in message 
news:20060517053503.oq4mtmzuzmv4s4sw at login.werra.lunarpages.com...
> However, this is more of a practice than a prohibition... it IS
> possible to modify existing classes in Python.

If the class is defined/written in Python.

> Unfortunately, for implementation reasons you can't modify most
> built-in (and some user-defined) classes in this fashion:

Being able to add Python-coded functions as methods of compiled C-coded 
types/classes (builting or otherwise) would require some wrapping machinery 
that would slow down normal usage.

tjr




From janssen at parc.com  Wed May 17 23:57:19 2006
From: janssen at parc.com (Bill Janssen)
Date: Wed, 17 May 2006 14:57:19 PDT
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: Your message of "Wed, 17 May 2006 12:12:34 PDT."
	<1147893155.14132.42.camel@localhost.localdomain> 
Message-ID: <06May17.145723pdt."58641"@synergy1.parc.xerox.com>

> > If there's no distro package (not unusual), they'd download the source package 
> > and need to run "python setup.py install".  They need both Python and 
> > distutils in that case.
> 
> No, most of them would just use another program that doesn't require
> them to "program in DOS"...

Yep.

Bill

From robinbryce at gmail.com  Thu May 18 00:13:09 2006
From: robinbryce at gmail.com (Robin Bryce)
Date: Wed, 17 May 2006 23:13:09 +0100
Subject: [Python-3000] i guess i was misunderstood
In-Reply-To: <4463CF45.3030309@canterbury.ac.nz>
References: <1d85506f0605111027v3145da88o8e2314cac203064d@mail.gmail.com>
	<4463CF45.3030309@canterbury.ac.nz>
Message-ID: <bcf87d920605171513of996c3as3b2ad2cf1ab4baaf@mail.gmail.com>

[Talin]
> b=B() # error, A.__init__ expects an instanc of A
>
>why is this kind of type-checking enforced by the language?

[greg]
>Since type-class unification, there is no clear boundary <snip> If you were
allowed to pass any object to any method, there would be a danger of
crashing the interpreter.

I've always expected `AttributeError` if I call `A.somemethod(otherself)`
AND otherself does not conform to the expectations of `A.somemethod`. I
still find `error, A.somemethod expects an instance of A` *very* surprising.

`TypeError` is something I would expect if I broke the typing rules of the
underlying implementation. By 'underlying implementation' I mean the
interpreter AND any extension library that uses the interpreters foreign
function provisions to provide extension types. IIUC greg is saying this is
exactly what Talin's example does.

In the python tutorial 'self' is introduced like this: "the special thing
about methods is that the object is passed as the first argument of the
function". And ever since reading that I've always expected to be able to
treat 'self' as just another parameter. Talins' first example illustrates
that 'self' can not be treated this way.

If there was a way to allow `A.somemethod(otherself)` where
`isinstance(otherself, A) is False`, as a language feature, then I would
find my self reaching for things like PyProtocols less often. I'm not
knocking PyProtocols, I just wish there was a middle ground available that
didn't nobble future adoption (no pun intended) of PyProtocols et al.

Does resolving the can of worms that greg alludes to belong in the 'very
difficult' or 'insufficient motivation & use' camp  ?

I don't care too much about making life harder for extention authors.
Software never so much resembeled the cavalry to me as when I first
encountered Pyrex.


Robin

http://docs.python.org/tut/node11.html#SECTION0011340000000000000000

On 12/05/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> tomer filiba wrote:
>
> > b=B() # error, A.__init__ expects an instanc of A
> >
> > why is this kind of type-checking enforced by the language?
>
> Since type-class unification, there is no clear boundary
> between built-in and user-defined classes. Any class can
> potentially add C-level data to its instances and have
> methods implemented in C that operate on it. If you were
> allowed to pass any object to any method, there would
> be a danger of crashing the interpreter.
>
> > what this code does is basically changing the __mro__ of the object. had
> > __mro__ been mutable, it would all be simpler.
>
> Being able to change the mro after class creation would
> lead to similar problems.
>
> --
> Greg
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/robinbryce%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060517/fea19cde/attachment.htm 

From fdrake at acm.org  Thu May 18 00:18:45 2006
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 17 May 2006 18:18:45 -0400
Subject: [Python-3000] What do do about IDLE?
In-Reply-To: <1147893155.14132.42.camel@localhost.localdomain>
References: <06May7.190717pdt.58641@synergy1.parc.xerox.com>
	<200605111540.39210.fdrake@acm.org>
	<1147893155.14132.42.camel@localhost.localdomain>
Message-ID: <200605171818.45629.fdrake@acm.org>

On Wednesday 17 May 2006 15:12, Jan Claeys wrote:
 > No, most of them would just use another program that doesn't require
 > them to "program in DOS"...

That's ok with me.  I use other programs that don't require me to click on 
Windows.  :-)


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From jcarlson at uci.edu  Thu May 18 00:40:34 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 17 May 2006 15:40:34 -0700
Subject: [Python-3000] i guess i was misunderstood
In-Reply-To: <bcf87d920605171513of996c3as3b2ad2cf1ab4baaf@mail.gmail.com>
References: <4463CF45.3030309@canterbury.ac.nz>
	<bcf87d920605171513of996c3as3b2ad2cf1ab4baaf@mail.gmail.com>
Message-ID: <20060517153529.6852.JCARLSON@uci.edu>


"Robin Bryce" <robinbryce at gmail.com> wrote:
> In the python tutorial 'self' is introduced like this: "the special thing
> about methods is that the object is passed as the first argument of the
> function". And ever since reading that I've always expected to be able to
> treat 'self' as just another parameter. Talins' first example illustrates
> that 'self' can not be treated this way.
> 
> If there was a way to allow `A.somemethod(otherself)` where
> `isinstance(otherself, A) is False`, as a language feature, then I would
> find my self reaching for things like PyProtocols less often. I'm not
> knocking PyProtocols, I just wish there was a middle ground available that
> didn't nobble future adoption (no pun intended) of PyProtocols et al.

One could use the @staticmethod decorator, but then one would need to
pass the instance every time.

Generally speaking, I like that Python enforces type when using unbound
methods; it has saved me from some foolish bugs.  Also, the cases where
I have generally wanted the "first argument" to be anything that
supports a particular interface, I generally don't make them methods of
a class.

I would suggest that code which uses an unbound method on an object
unrelated to the class is actually trying to be too clever; make it a
plain function or a static method.

 - Josiah


From kay.schluehr at gmx.net  Thu May 18 08:48:01 2006
From: kay.schluehr at gmx.net (Kay Schluehr)
Date: Thu, 18 May 2006 08:48:01 +0200
Subject: [Python-3000] State of the object system
In-Reply-To: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>
References: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>
Message-ID: <446C18A1.1040409@gmx.net>

Michael Chermside schrieb:

>Unfortunately, for implementation reasons you can't modify most
>built-in (and some user-defined) classes in this fashion:
>
>   >>> int.func2 = func2
>
>   Traceback (most recent call last):
>     File "<pyshell#35>", line 1, in -toplevel-
>       int.func2 = func2
>   TypeError: can't set attributes of built-in/extension type 'int'
>
>Most Python programmers would probably agree that this is a
>perfectly fine restriction. Built-in classes like int and dict
>are widely used... allowing the code from any one module to
>modify them has dangerously non-local effects. 
>
And that's not true for user defined classes?

The disadvantage of subclassing e.g. int is losing algebraic properties 
that are implicitely defined by the operators. Adding two ints a and b 
results in a third int c, so we have the automorphism:  int + int -> 
int. On subclasses the operation doesn't preserve structure. Adding a 
method isprime() or iseven() to a subclass of int will suddenly be lost 
in the resulting object after an operation as long as it is not 
overwritten to return the right type and not the base type. So it is 
questionable if subclassing is really a good design decision.

>(Yes, I know...
>it works OK for Ruby... but I, for one, am still wary.) If
>your code really needs to modify the behavior of int (or dict
>or whatever) then use a subclass of int (or dict or whatever)
>in your own code which you can modify freely.
>  
>
AFAIK Ruby doesn't support standalone functions but needs a class 
context to define them as methods. Python might be more liberal in this 
respect but it seems to me that it forces to write functions in certain 
situations. A function isprime() has really no place in a subclass of 
int. But it has also no other natural namespace than int. So people 
start writing modules that grant asylum for homeless functions. 
Uncountably many "util" modules tell us bitter stories about non-design 
design ( I'm not innocent of course ).

>But if you've got a convincing argument (preferably with use
>cases that are only poorly addressed by today's Python) for why
>this behavior ought to be added to Py3K... please let us know!
>  
>
Sometimes a broken structure needs more justification than a sound one. 
Arbitrary restrictions complicate the language semantics for no good 
reasons. But if it is strongly encouraged not to add methods to classes 
at runtime we might get rid of the self parameter that lessens the 
barrier between functions and methods?

Regards,
Kay



From kay.schluehr at gmx.net  Thu May 18 08:59:50 2006
From: kay.schluehr at gmx.net (Kay Schluehr)
Date: Thu, 18 May 2006 08:59:50 +0200
Subject: [Python-3000] State of the object system
In-Reply-To: <e4ft38$qjg$1@sea.gmane.org>
References: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>
	<e4ft38$qjg$1@sea.gmane.org>
Message-ID: <446C1B66.3060205@gmx.net>

Terry Reedy schrieb:

>>Unfortunately, for implementation reasons you can't modify most
>>built-in (and some user-defined) classes in this fashion:
>>    
>>
>
>Being able to add Python-coded functions as methods of compiled C-coded 
>types/classes (builting or otherwise) would require some wrapping machinery 
>that would slow down normal usage.
>  
>
Getting rid of C-coded types is certainly an interesting requirement as 
well. I hope PyPythonistas may agree :)

Honestly, I don't understand how a pointer on an implicit/interpreter 
level Trait that stores user defined methods for builtins would slow 
execution down. You would need wrappers only if you permit 
replacing/deleting pre-defined methods and I don't see reasons to be 
permissive here.

Kay



From jcarlson at uci.edu  Thu May 18 10:27:14 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu, 18 May 2006 01:27:14 -0700
Subject: [Python-3000] State of the object system
In-Reply-To: <446C1B66.3060205@gmx.net>
References: <e4ft38$qjg$1@sea.gmane.org> <446C1B66.3060205@gmx.net>
Message-ID: <20060518003138.685B.JCARLSON@uci.edu>


Kay Schluehr <kay.schluehr at gmx.net> wrote:
> Terry Reedy schrieb:
> >>Unfortunately, for implementation reasons you can't modify most
> >>built-in (and some user-defined) classes in this fashion:
> >>    
> >Being able to add Python-coded functions as methods of compiled C-coded 
> >types/classes (builting or otherwise) would require some wrapping machinery 
> >that would slow down normal usage.
> >  
> >
> Getting rid of C-coded types is certainly an interesting requirement as 
> well. I hope PyPythonistas may agree :)
> 
> Honestly, I don't understand how a pointer on an implicit/interpreter 
> level Trait that stores user defined methods for builtins would slow 
> execution down. You would need wrappers only if you permit 
> replacing/deleting pre-defined methods and I don't see reasons to be 
> permissive here.

Personally, I don't have much of an issue using utility modules to
perform operations like 'isprime()' and 'iseven()' as you pointed out in
another post.  Maybe it's my non-OOP background coming in and saying
"not everything needs to be a method" and "duck typing allows me to use
this for more than just type X".

Ultimately the question comes down to: why should anyone be able to
attach arbitrary metadata to builtin types?  While such metadata (which
could include functions) could be useful, it doesn't seem particularly
"Pythonic".


As long as it wouldn't noticeably degrade the performance of base types,
I wouldn't see a problem with making base types return the proper
subclass from which the methods were being called.  That is, if I have
declared myInt to be a subclass of int, and I perform an operation on
myInt (like perhaps adding), that int would automatically create a myInt
type on return (for all methods for which this would make sense).


 - Josiah


From bborcic at gmail.com  Thu May 11 13:04:12 2006
From: bborcic at gmail.com (Boris Borcic)
Date: Thu, 11 May 2006 13:04:12 +0200
Subject: [Python-3000] Unicode identifiers (Was: sets in P3K?)
In-Reply-To: <445279F7.8080306@v.loewis.de>
References: <mailman.18397.1146112002.27774.python-3000@python.org>	<Pine.GSO.4.58.0604270656080.5502@dvp.cs>	<4450BE0E.8090903@gmail.com>	<4450C311.8040603@fas.harvard.edu>	<4450CB36.7090504@gmail.com>	<44511237.5000609@ewtllc.com>	<e2r8b2$ni7$1@sea.gmane.org>	<e2rhi5$q8e$1@sea.gmane.org>	<17489.31069.526965.186604@montanaro.dyndns.org>	<4451AF74.8040702@gmx.net>	<ca471dc20604280732j4c12c5cbxf50a4c012fa1e7f1@mail.gmail.com>
	<445279F7.8080306@v.loewis.de>
Message-ID: <e3v5nq$mrc$1@sea.gmane.org>

Martin v. L?wis wrote:
 > Guido van Rossum wrote:
 >> I want good Unicode support for string literals and comments.
 >> Everything else in the language ought to be ASCII.
 >
 > Does that include restricting identifiers to ASCII as well?

I am late on this subthread, but FWIW and FYI with Python 2.4.2 and Idle 1.1.2 
on WinXP I can use non-ascii identifiers transparently both in modules and at 
the prompt, for instance

 >>> gr?zi = r?le = ni?o = ?a = True
 >>> gr?zi
True

I thought it was a provided feature, but scanning the subthread gave the 
contrary impression. Should we expect disappearance of the property ?

Best, bb
--
assert "304" in "340343","P424D15E M15M47C8"


From thomas.dunham at gmail.com  Thu May 18 14:12:10 2006
From: thomas.dunham at gmail.com (Thomas Dunham)
Date: Thu, 18 May 2006 13:12:10 +0100
Subject: [Python-3000] Another overloaded functions usecase
Message-ID: <3e5572520605180512s2e54b8deq5e05a4f493a607c3@mail.gmail.com>

Talk on overloaded functions seems a bit sparse recently, and as I rather like
the idea I wondered if another usecase would be helpful. I reworked
this from an example published 10 years ago by someone who a couple of
you guys might see at lunchtime.

Say we want to read a text document in RTF and convert to one of many
formats. The gang of four describe a builder pattern to do this, and
their approach requires a class for each type of object to build, and
another for the director. It's likely that you'd ditch the director if
you were writing in Python:

class TEXConverter(TextConverter):
  def convertChar(token):
...

builder = TEXConverter()
...

act = dict(
    CHAR=builder.convertChar,
    FONT=builder.convertFont,
    PARA=builder.convertParagraph
)

t = get_token()
act[t.type](t)


Maybe with overloaded functions it could look like this:

target = TEXText()
Font, Para, Char = inputTypes()
...
token = get_token()
convert(token, token.type, target)
...
def convert(token, type:Font, target:TEXText):
    ...

def convert(token, type:Para, target:TEXText):
    ...

def convert(token, type:Char, target:TEXText):
    ...

In the original (written in Dylan) Font, Para, Char are instances, and
it uses == to dispatch on individual objects. I'm suggesting creating
more classes and dispatching on (possibly singleton) instances of
them. (The origonal is here: http://norvig.com/design-patterns/)

I don't think this is as elegant as Norvig's version, but I do like
the way it makes the language do all the dispatching, and looking at
the function prototypes gives a good impression of the type/operation
grid that is somewhat hidden in the single-dispatch version.

Tom

From collinw at gmail.com  Thu May 18 17:31:32 2006
From: collinw at gmail.com (Collin Winter)
Date: Thu, 18 May 2006 11:31:32 -0400
Subject: [Python-3000] Type annotations: annotating generators
Message-ID: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>

In working on notes for the type annotations PEP, I've hit some
ambiguous/unresolved issues in the BDFL annotation syntax (drawing
primarily from [1] and other blog posts):

As a quick recap, the syntax looks something like this:

"""def foo(a: int, b: float, c: int = 5) -> list[int]"""

In looking through all of Guido's blog posts on the subject -- and all
the comments on them -- I haven't seen anyone consider the case of
generators. Assuming that "->" makes assertions only about the
function's return type, if I were to write a generator with the
following type,

"""def my_range(min: Number, max: Number) -> Number"""

it would blow up because the function returns a generator, not a Number.

Of course, "->" could be DWIMmy, in the sense that it knows whether
it's being used in a function or generator context. This doesn't solve
the other problem with annotating generators, though: send().

With the BDFL syntax, there's no way to add annotations for a
generator's send() method. One might suggest something like

"""def my_range(min: Number, max: Number) <- Number -> Number"""

where "<- Number" indicates that the generator's send() only accepts
Numbers, but this feels terribly kludgy to me.

My own proposal is to use keywords in the vein of "returns", "yields"
and "is_sent" (don't quibble with the names; the actual names can be
decided later). Under this modified syntax, the above send() example
looks something like this:

"""def my_range(min: Number, max: Number) is_sent Number, yields Number"""

In the same spirit, "->" would be replaced with "returns":

"""def foo(a: int, b: float, c: int = 5) returns list[int]"""

To combat overly long lines, users could wrap the annotation clauses
to the next line:

"""
def my_range(min: Number, max: Number) is_sent Number,
                                       yields Number
"""

Nitpicky details:

1. Using is_sent and yields on a non-generator causes a SyntaxError.
2. Using returns on a generator causes a SyntaxError


Thanks,
Collin Winter

[1] - http://www.artima.com/weblogs/viewpost.jsp?thread=86641

From qrczak at knm.org.pl  Thu May 18 17:45:03 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Thu, 18 May 2006 17:45:03 +0200
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	(Collin Winter's message of "Thu, 18 May 2006 11:31:32 -0400")
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
Message-ID: <871wur72ww.fsf@qrnik.zagroda>

"Collin Winter" <collinw at gmail.com> writes:

> Of course, "->" could be DWIMmy, in the sense that it knows whether
> it's being used in a function or generator context.

This would be a bad idea. A function returning a generator of ints is
very different from a function returning an int.

And a function returning a generator because it contains yield
statement has the same interface as the appropriate plain function
which builds an iterator by hand. *These* should be the same.
An iterator is not an int.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From p.f.moore at gmail.com  Thu May 18 17:56:17 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 18 May 2006 16:56:17 +0100
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
Message-ID: <79990c6b0605180856q4263a4a7h458ee58485399e8a@mail.gmail.com>

On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> In looking through all of Guido's blog posts on the subject -- and all
> the comments on them -- I haven't seen anyone consider the case of
> generators. Assuming that "->" makes assertions only about the
> function's return type, if I were to write a generator with the
> following type,
>
> """def my_range(min: Number, max: Number) -> Number"""
>
> it would blow up because the function returns a generator, not a Number.

I'd suggest you consider this in analogy with functions returning
functions. Example:

    def foo(n : Number) -> ????:
        def bar():
            return 12
        return bar

What is ????

Two obvious options come to my mind: (1) don't allow it - the return
type is unspecified, after all type annotations are optional, and this
is going to get too hard, too fast; or (2) something like "function()
-> Number".

Now reasoning by analogy, you can apply the same logic to generators -
either (1) don't allow them to be specified, or (2) use something like
"generator() -> int" (and this option allows you to use the "argument"
of the generator as a type annotation for send.

My preference is for (1), but that's in the more general context that
I expect to ignore type annotations in 99% of cases for my own code...

Paul.

From collinw at gmail.com  Thu May 18 18:05:45 2006
From: collinw at gmail.com (Collin Winter)
Date: Thu, 18 May 2006 12:05:45 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <79990c6b0605180856q4263a4a7h458ee58485399e8a@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<79990c6b0605180856q4263a4a7h458ee58485399e8a@mail.gmail.com>
Message-ID: <43aa6ff70605180905kc4b8efao63558c625167cf01@mail.gmail.com>

On 5/18/06, Paul Moore <p.f.moore at gmail.com> wrote:
> On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> > In looking through all of Guido's blog posts on the subject -- and all
> > the comments on them -- I haven't seen anyone consider the case of
> > generators. Assuming that "->" makes assertions only about the
> > function's return type, if I were to write a generator with the
> > following type,
> >
> > """def my_range(min: Number, max: Number) -> Number"""
> >
> > it would blow up because the function returns a generator, not a Number.
>
> I'd suggest you consider this in analogy with functions returning
> functions. Example:
>
>     def foo(n : Number) -> ????:
>         def bar():
>             return 12
>         return bar
>
> What is ????

You seem to have missed the threads [1], [2] where this exact issue
was discussed. The current thinking is something like Function(int,
int).returns(int).

So, reasoning by analogy would point to something like
Generator(is_sent=int, yields=int). In my mind, though, since
generators -- as opposed to function-returning-functions -- are a
sufficiently core part of the language worth their own special syntax
(e.g., the yield keyword), there might be interest in continuing this
special status in the type annotation syntax.

Thanks,
Collin Winter

[1] - http://mail.python.org/pipermail/python-3000/2006-May/001972.html
[2] - http://mail.python.org/pipermail/python-3000/2006-May/002061.html

From edloper at gradient.cis.upenn.edu  Thu May 18 18:18:32 2006
From: edloper at gradient.cis.upenn.edu (Edward Loper)
Date: Thu, 18 May 2006 12:18:32 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605180905kc4b8efao63558c625167cf01@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>	<79990c6b0605180856q4263a4a7h458ee58485399e8a@mail.gmail.com>
	<43aa6ff70605180905kc4b8efao63558c625167cf01@mail.gmail.com>
Message-ID: <446C9E58.7000506@gradient.cis.upenn.edu>

Collin Winter wrote:
> So, reasoning by analogy would point to something like
> Generator(is_sent=int, yields=int). 

You'd probably want this to be Iterator(...) instead of Generator(...), 
since the *return value* is an iterator.  (It's the function itself 
that's a generator function, not its return value.)

-Edward


From collinw at gmail.com  Thu May 18 18:24:16 2006
From: collinw at gmail.com (Collin Winter)
Date: Thu, 18 May 2006 12:24:16 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <446C9E58.7000506@gradient.cis.upenn.edu>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<79990c6b0605180856q4263a4a7h458ee58485399e8a@mail.gmail.com>
	<43aa6ff70605180905kc4b8efao63558c625167cf01@mail.gmail.com>
	<446C9E58.7000506@gradient.cis.upenn.edu>
Message-ID: <43aa6ff70605180924y5e69ef75r6dc58d83f7fcdbd8@mail.gmail.com>

On 5/18/06, Edward Loper <edloper at gradient.cis.upenn.edu> wrote:
> Collin Winter wrote:
> > So, reasoning by analogy would point to something like
> > Generator(is_sent=int, yields=int).
>
> You'd probably want this to be Iterator(...) instead of Generator(...),
> since the *return value* is an iterator.  (It's the function itself
> that's a generator function, not its return value.)

No, it should be Generator, since you can't send() values to arbitrary
iterables; I'm specifically trying to find a way to typecheck the
objects coming in via send().

Also, the function's return value most certainly is a generator:

"""
>>> def foo(): yield 5
...
>>> f = foo()
>>> type(f)
<type 'generator'>
>>>
"""

Collin Winter

From edloper at gradient.cis.upenn.edu  Thu May 18 18:48:54 2006
From: edloper at gradient.cis.upenn.edu (Edward Loper)
Date: Thu, 18 May 2006 12:48:54 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605180924y5e69ef75r6dc58d83f7fcdbd8@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>	
	<79990c6b0605180856q4263a4a7h458ee58485399e8a@mail.gmail.com>	
	<43aa6ff70605180905kc4b8efao63558c625167cf01@mail.gmail.com>	
	<446C9E58.7000506@gradient.cis.upenn.edu>
	<43aa6ff70605180924y5e69ef75r6dc58d83f7fcdbd8@mail.gmail.com>
Message-ID: <446CA576.4030503@gradient.cis.upenn.edu>

Collin Winter wrote:
> Also, the function's return value most certainly is a generator:

So it is; I stand corrected. :)

-Edward

From tomerfiliba at gmail.com  Thu May 18 21:28:42 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Thu, 18 May 2006 21:28:42 +0200
Subject: [Python-3000] exceptions with keyword arguments
In-Reply-To: <bbaeab100605171143n4b028b92kf1d386081840489c@mail.gmail.com>
References: <1d85506f0605171029m678ebab7q99903a1486890611@mail.gmail.com>
	<bbaeab100605171143n4b028b92kf1d386081840489c@mail.gmail.com>
Message-ID: <1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com>

> Positional support is deprecated; there will only be support for a
> single argument. Read
> PEP 352 to see how BaseException will end up in Python 3000.

i don't see how BaseException addresses issues like accessing
attributes rather than positional args, or introducing something equivalent
to ArgumentError. raising a TypeError is just semantically wrong in that
case -- it has nothing to do with types whatsoever.

from the pep:
> This PEP proposes introducing a new exception named BaseException
> that is a new-style class and has a single attribute, message (that will
> cause the deprecation of the existing args attribute)
well, how do you suggest passing back the error-code, or file name of
exceptions like IOError, or the attribute name of an AttributeError?
a single argument can only be used for pretty printing, not really providing
information *about* the exception. so unless people would want to
use regular expressions to *parse* the message, why not allow keyword
arguments for extra info about the exception?

> And I brought this up with Guido once and he was not enthusiastic
> about it.  Basically, keep exceptions simple.  They are important
> and basic enough to keep it simple.  If you want fancier support,
> subclass Exception and add the support you want.
well, if guido pronounced on it than i guess it's settled, but why do you
condsider *args to be simple and **kwargs not as simple? don't you
think "ex.filename" is simpler/clearer than "ex[1]"?


-tomer

On 5/17/06, Brett Cannon <brett at python.org> wrote:
>
>
>
> On 5/17/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> > hi all
> >
> > i would like to suggest changing the base-exception class, whatever
> > it may be (Exception/BaseException) to work with keyword arguments
> > instead of positional ones.
>
>
>
> Positional support is deprecated; there will only be support for a single
> argument.  Read PEP 352 to see how BaseException will end up in Python 3000.
>
> And I brought this up with Guido once and he was not enthusiastic about it.
> Basically, keep exceptions simple.  They are important and basic enough to
> keep it simple.  If you want fancier support, subclass Exception and add the
> support you want.
>
> -Brett
>
> >
> instead of
>
> try:
>     ...
> except IOError, ex:
>     print ex[1]
> # or
> except IOError, (code, text, filename):
>     ...
>     # which means changes to code/text/filename do not change
>     # the exception object
>
> use
>
> try:
>     raise IOError(filename = "lala", code=17, text="blah blah blah")
> except IOError, ex:
>     ex.code = 18
>     raise
>
> raise IndexError("invalid index", index = the_index)
> raise KeyError("key not found", key = the_key)
> raise AttributeError("attribute not found", name = name)
>
> where the new exception can be something like
>
> class Exception:
>     def __init__(self, message = None, **kw):
>         self._message = message
>         self.__dict__.update(kw)
>     def __repr__(self):
>         attrs = sorted("%s = %r" % (k, v)
>                        for k, v in self.__dict__.iteritems()
>                        if not k.startswith("_"))
>         return "<%s(%s, %s)>" % (self.__class__.__name__,
>             self._message, ", ".join(attrs))
>
> class IOError(Exception):
>    pass
>
> raise IOError(code = 17, text = "EBLAH", filename = "lalala")
>
> the builtin errors might want to enforce an "exception signature",
>
> class ExceptionSignature(Exception):
>     attributes = []
>     def __init__(self, *args, **kw):
>          for name in self.attributes:
>              assert name in kw, "expected an attribute named %s" % (name,)
>          Exception.__init__(self, *args, **kw)
>
> class IOError(ExceptionSignature):
>     attributes = ["code", "text", "filename"]
>
> or something like that, so the attributes of the exception are part
> of its official interface.
>
> rationale:
> * today, AttributeError's are raised as
> AttributeError("%s object has no attribute %s" % ...)
> which means analyzing the exception requires parsing text!
>  * IOError (among others), for instance, does nasty and not-so-well
> documented
> overloading of named/positional arguments: when you pass 1-3 arguments,
> they are stored in .args, but also in .errno, .strerror, and
>  .filename. if you pass
> more than 3 arguments, the attributes are all set to None and only
> .args is filled.
> yuck.
>
> you can see this for reference:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496698
>
> ----
>
> that said, i would also want to introduce ArgumentError. there are
> many times just a ValueError isn't enough. instead, having a builtin
> ArgumentError would made things more clear:
>
> def write_to_file(the_file):
>     if the_file.closed:
>         raise ArgumentError("the file must be open", name = "the_file")
>     the_file.write(...)
>
> and with ArgumentError included, calling functions with invalid
> signatures would also raise ArgumentError. TypeError is quite
> silly in this case, as it has nothing to do with the *type* of
> the function or its arguments.
>
> >>> def f(a): pass
> >>> f(1,2)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> *TypeError*: f() takes exactly 1 argument (2 given)
> >>> type(f)
> <type 'function'> # like any other function
>
> TypeError is too-broadly overloaded this way.
>
>
> -tomer
> _______________________________________________
> Python-3000 mailing list
>  Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/brett%40python.org
>
>

From brett at python.org  Thu May 18 21:49:56 2006
From: brett at python.org (Brett Cannon)
Date: Thu, 18 May 2006 12:49:56 -0700
Subject: [Python-3000] exceptions with keyword arguments
In-Reply-To: <1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com>
References: <1d85506f0605171029m678ebab7q99903a1486890611@mail.gmail.com>
	<bbaeab100605171143n4b028b92kf1d386081840489c@mail.gmail.com>
	<1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com>
Message-ID: <bbaeab100605181249y177fdc59jae8fd6f38ae091c2@mail.gmail.com>

On 5/18/06, tomer filiba <tomerfiliba at gmail.com> wrote:
>
> > Positional support is deprecated; there will only be support for a
> > single argument. Read
> > PEP 352 to see how BaseException will end up in Python 3000.
>
> i don't see how BaseException addresses issues like accessing
> attributes rather than positional args, or introducing something
> equivalent
> to ArgumentError. raising a TypeError is just semantically wrong in that
> case -- it has nothing to do with types whatsoever.



It doesn't address any of that.  It isn't meant to.  BaseException is the
base exception and is not meant to support the kitchen sink.


from the pep:
> > This PEP proposes introducing a new exception named BaseException
> > that is a new-style class and has a single attribute, message (that will
> > cause the deprecation of the existing args attribute)




well, how do you suggest passing back the error-code, or file name of
> exceptions like IOError, or the attribute name of an AttributeError?
> a single argument can only be used for pretty printing, not really
> providing
> information *about* the exception. so unless people would want to
> use regular expressions to *parse* the message, why not allow keyword
> arguments for extra info about the exception?



Subclassing.  You can override the constructor and do what you want.


> And I brought this up with Guido once and he was not enthusiastic
> > about it.  Basically, keep exceptions simple.  They are important
> > and basic enough to keep it simple.  If you want fancier support,
> > subclass Exception and add the support you want.




well, if guido pronounced on it than i guess it's settled, but why do you
> condsider *args to be simple and **kwargs not as simple? don't you
> think "ex.filename" is simpler/clearer than "ex[1]"?



I do.  I am in no way suggesting that positional arguments are better.  As I
said, positional arguments are not going to be supported in Python 3000.
The positional argument support is for backards-compatibility; that's why
BaseException will end up having the constructor defined as::

   def __init__(self, message=''):
        """Set the 'message' attribute'"""
        self.message = message


as specified in the PEP.  But that does not stop someone from overriding
BaseException in a subclass, as some built-ins do already.  So you can
easily add your filename attribute.::

  def __init__(self, filename):
      self.filename = filename
      BaseException.__init__(self, "%s does not exist" % filename)

This also allows you to come up with an informative message if you so desire
that is more standardized and based on some other argument.

-Brett

-tomer
>
> On 5/17/06, Brett Cannon <brett at python.org> wrote:
> >
> >
> >
> > On 5/17/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> > > hi all
> > >
> > > i would like to suggest changing the base-exception class, whatever
> > > it may be (Exception/BaseException) to work with keyword arguments
> > > instead of positional ones.
> >
> >
> >
> > Positional support is deprecated; there will only be support for a
> single
> > argument.  Read PEP 352 to see how BaseException will end up in Python
> 3000.
> >
> > And I brought this up with Guido once and he was not enthusiastic about
> it.
> > Basically, keep exceptions simple.  They are important and basic enough
> to
> > keep it simple.  If you want fancier support, subclass Exception and add
> the
> > support you want.
> >
> > -Brett
> >
> > >
> > instead of
> >
> > try:
> >     ...
> > except IOError, ex:
> >     print ex[1]
> > # or
> > except IOError, (code, text, filename):
> >     ...
> >     # which means changes to code/text/filename do not change
> >     # the exception object
> >
> > use
> >
> > try:
> >     raise IOError(filename = "lala", code=17, text="blah blah blah")
> > except IOError, ex:
> >     ex.code = 18
> >     raise
> >
> > raise IndexError("invalid index", index = the_index)
> > raise KeyError("key not found", key = the_key)
> > raise AttributeError("attribute not found", name = name)
> >
> > where the new exception can be something like
> >
> > class Exception:
> >     def __init__(self, message = None, **kw):
> >         self._message = message
> >         self.__dict__.update(kw)
> >     def __repr__(self):
> >         attrs = sorted("%s = %r" % (k, v)
> >                        for k, v in self.__dict__.iteritems()
> >                        if not k.startswith("_"))
> >         return "<%s(%s, %s)>" % (self.__class__.__name__,
> >             self._message, ", ".join(attrs))
> >
> > class IOError(Exception):
> >    pass
> >
> > raise IOError(code = 17, text = "EBLAH", filename = "lalala")
> >
> > the builtin errors might want to enforce an "exception signature",
> >
> > class ExceptionSignature(Exception):
> >     attributes = []
> >     def __init__(self, *args, **kw):
> >          for name in self.attributes:
> >              assert name in kw, "expected an attribute named %s" %
> (name,)
> >          Exception.__init__(self, *args, **kw)
> >
> > class IOError(ExceptionSignature):
> >     attributes = ["code", "text", "filename"]
> >
> > or something like that, so the attributes of the exception are part
> > of its official interface.
> >
> > rationale:
> > * today, AttributeError's are raised as
> > AttributeError("%s object has no attribute %s" % ...)
> > which means analyzing the exception requires parsing text!
> >  * IOError (among others), for instance, does nasty and not-so-well
> > documented
> > overloading of named/positional arguments: when you pass 1-3 arguments,
> > they are stored in .args, but also in .errno, .strerror, and
> >  .filename. if you pass
> > more than 3 arguments, the attributes are all set to None and only
> > .args is filled.
> > yuck.
> >
> > you can see this for reference:
> > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496698
> >
> > ----
> >
> > that said, i would also want to introduce ArgumentError. there are
> > many times just a ValueError isn't enough. instead, having a builtin
> > ArgumentError would made things more clear:
> >
> > def write_to_file(the_file):
> >     if the_file.closed:
> >         raise ArgumentError("the file must be open", name = "the_file")
> >     the_file.write(...)
> >
> > and with ArgumentError included, calling functions with invalid
> > signatures would also raise ArgumentError. TypeError is quite
> > silly in this case, as it has nothing to do with the *type* of
> > the function or its arguments.
> >
> > >>> def f(a): pass
> > >>> f(1,2)
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > *TypeError*: f() takes exactly 1 argument (2 given)
> > >>> type(f)
> > <type 'function'> # like any other function
> >
> > TypeError is too-broadly overloaded this way.
> >
> >
> > -tomer
> > _______________________________________________
> > Python-3000 mailing list
> >  Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-3000/brett%40python.org
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060518/b8f774a4/attachment.html 

From jcarlson at uci.edu  Thu May 18 22:02:04 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu, 18 May 2006 13:02:04 -0700
Subject: [Python-3000] exceptions with keyword arguments
In-Reply-To: <1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com>
References: <bbaeab100605171143n4b028b92kf1d386081840489c@mail.gmail.com>
	<1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com>
Message-ID: <20060518125745.686C.JCARLSON@uci.edu>


"tomer filiba" <tomerfiliba at gmail.com> wrote:
> On 5/17/06, Brett Cannon <brett at python.org> wrote:
> > And I brought this up with Guido once and he was not enthusiastic
> > about it.  Basically, keep exceptions simple.  They are important
> > and basic enough to keep it simple.  If you want fancier support,
> > subclass Exception and add the support you want.
> 
> well, if guido pronounced on it than i guess it's settled, but why do you
> condsider *args to be simple and **kwargs not as simple? don't you
> think "ex.filename" is simpler/clearer than "ex[1]"?

From what I understand of Brett's post, ex[1] won't be available anymore
either.

While it would be convenient for inspecting exceptions when they are
caught via ex.attr, creating exceptions with keyword arguments seems
like it would be a bit if a pain.

 - Josiah


From theller at python.net  Thu May 18 22:13:01 2006
From: theller at python.net (Thomas Heller)
Date: Thu, 18 May 2006 22:13:01 +0200
Subject: [Python-3000] Unicode identifiers (Was: sets in P3K?)
In-Reply-To: <e3v5nq$mrc$1@sea.gmane.org>
References: <mailman.18397.1146112002.27774.python-3000@python.org>	<Pine.GSO.4.58.0604270656080.5502@dvp.cs>	<4450BE0E.8090903@gmail.com>	<4450C311.8040603@fas.harvard.edu>	<4450CB36.7090504@gmail.com>	<44511237.5000609@ewtllc.com>	<e2r8b2$ni7$1@sea.gmane.org>	<e2rhi5$q8e$1@sea.gmane.org>	<17489.31069.526965.186604@montanaro.dyndns.org>	<4451AF74.8040702@gmx.net>	<ca471dc20604280732j4c12c5cbxf50a4c012fa1e7f1@mail.gmail.com>	<445279F7.8080306@v.loewis.de>
	<e3v5nq$mrc$1@sea.gmane.org>
Message-ID: <e4ikgd$1dc$1@sea.gmane.org>

Boris Borcic wrote:
> Martin v. L?wis wrote:
>  > Guido van Rossum wrote:
>  >> I want good Unicode support for string literals and comments.
>  >> Everything else in the language ought to be ASCII.
>  >
>  > Does that include restricting identifiers to ASCII as well?
> 
> I am late on this subthread, but FWIW and FYI with Python 2.4.2 and Idle 1.1.2 
> on WinXP I can use non-ascii identifiers transparently both in modules and at 
> the prompt, for instance
> 
>  >>> gr?zi = r?le = ni?o = ?a = True
>  >>> gr?zi
> True
> 
> I thought it was a provided feature, but scanning the subthread gave the 
> contrary impression. Should we expect disappearance of the property ?

This looks like an IDLE bug to me.

Thomas


From qrczak at knm.org.pl  Thu May 18 23:13:32 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Thu, 18 May 2006 23:13:32 +0200
Subject: [Python-3000] Unicode identifiers
In-Reply-To: <e4ikgd$1dc$1@sea.gmane.org> (Thomas Heller's message of "Thu,
	18 May 2006 22:13:01 +0200")
References: <mailman.18397.1146112002.27774.python-3000@python.org>
	<Pine.GSO.4.58.0604270656080.5502@dvp.cs> <4450BE0E.8090903@gmail.com>
	<4450C311.8040603@fas.harvard.edu> <4450CB36.7090504@gmail.com>
	<44511237.5000609@ewtllc.com> <e2r8b2$ni7$1@sea.gmane.org>
	<e2rhi5$q8e$1@sea.gmane.org>
	<17489.31069.526965.186604@montanaro.dyndns.org>
	<4451AF74.8040702@gmx.net>
	<ca471dc20604280732j4c12c5cbxf50a4c012fa1e7f1@mail.gmail.com>
	<445279F7.8080306@v.loewis.de> <e3v5nq$mrc$1@sea.gmane.org>
	<e4ikgd$1dc$1@sea.gmane.org>
Message-ID: <87y7wzm3yb.fsf@qrnik.zagroda>

Thomas Heller <theller at python.net> writes:

>>  >>> gr?zi = r?le = ni?o = ?a = True
>>  >>> gr?zi
>> True
>> 
>> I thought it was a provided feature, but scanning the subthread gave the 
>> contrary impression. Should we expect disappearance of the property ?
>
> This looks like an IDLE bug to me.

I think it's Python's fault that it assumes that LC_CTYPE locale is
set to "C". Python may be embedded in another application which sets
the locale differently.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From guido at python.org  Fri May 19 02:40:20 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 17:40:20 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
Message-ID: <ca471dc20605181740s4d509375i9c81c44b385cfdc9@mail.gmail.com>

On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> In working on notes for the type annotations PEP, I've hit some
> ambiguous/unresolved issues in the BDFL annotation syntax (drawing
> primarily from [1] and other blog posts):
>
> As a quick recap, the syntax looks something like this:
>
> """def foo(a: int, b: float, c: int = 5) -> list[int]"""
>
> In looking through all of Guido's blog posts on the subject -- and all
> the comments on them -- I haven't seen anyone consider the case of
> generators. Assuming that "->" makes assertions only about the
> function's return type, if I were to write a generator with the
> following type,
>
> """def my_range(min: Number, max: Number) -> Number"""
>
> it would blow up because the function returns a generator, not a Number.

My first response: specify the return type as Generator[Number] so the
whole thing would look like

def my_range(min: Number, max: Number) -> Generator[Number]: ...

> Of course, "->" could be DWIMmy, in the sense that it knows whether
> it's being used in a function or generator context. This doesn't solve
> the other problem with annotating generators, though: send().
>
> With the BDFL syntax, there's no way to add annotations for a
> generator's send() method. One might suggest something like
>
> """def my_range(min: Number, max: Number) <- Number -> Number"""
>
> where "<- Number" indicates that the generator's send() only accepts
> Numbers, but this feels terribly kludgy to me.

I don't like adding syntax specific to generators (especially since
most of the time send() won't be used at all).

I could extend my Generator[Number] example by also allowing
Generator[Number, Number] where the 2nd type would specify the
argument accepted by send(). (Making it 2nd makes it easy to omit.)

Or if you don't like this (I'm not crazy about letting people guess
what the second type is for either) you could write Generator(Number,
send=Number) or even Generator(returns=Number, send=Number). I think
it's fine to specify the return type of the generator by position and
the rest by keyword since the return type is always present.
Generator[Number] and Generator(Number) could mean the same thing
assuming Generator is not a real type like list but a pseudo type only
used for type annotations, like Sequence, Mapping, Iterator etc.

> My own proposal is to use keywords in the vein of "returns", "yields"
> and "is_sent" (don't quibble with the names; the actual names can be
> decided later). Under this modified syntax, the above send() example
> looks something like this:
>
> """def my_range(min: Number, max: Number) is_sent Number, yields Number"""

That's very ugly IMO.

> In the same spirit, "->" would be replaced with "returns":
>
> """def foo(a: int, b: float, c: int = 5) returns list[int]"""

I don't like that: 'returns' would have to be a reserved word (there
are no context-dependent reserved words in Python, 'import as'
notwithstanding). It seems you're making everyone suffer for a problem
that occurs only for generators.

> To combat overly long lines, users could wrap the annotation clauses
> to the next line:
>
> """
> def my_range(min: Number, max: Number) is_sent Number,
>                                        yields Number
> """

The lexer doesn't know enough about the grammer to know that the
newline after the comma should be ignored; adding this to the grammar
would be tricky too since presumably the newline would remain
optional.

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

From collinw at gmail.com  Fri May 19 03:59:01 2006
From: collinw at gmail.com (Collin Winter)
Date: Thu, 18 May 2006 21:59:01 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605181740s4d509375i9c81c44b385cfdc9@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<ca471dc20605181740s4d509375i9c81c44b385cfdc9@mail.gmail.com>
Message-ID: <43aa6ff70605181859h1c2e387eg373a98b7ca80cfd3@mail.gmail.com>

On 5/18/06, Guido van Rossum <guido at python.org> wrote:
> On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> > In looking through all of Guido's blog posts on the subject -- and all
> > the comments on them -- I haven't seen anyone consider the case of
> > generators. Assuming that "->" makes assertions only about the
> > function's return type, if I were to write a generator with the
> > following type,
> >
> > """def my_range(min: Number, max: Number) -> Number"""
> >
> > it would blow up because the function returns a generator, not a Number.
>
> My first response: specify the return type as Generator[Number] so the
> whole thing would look like
>
> def my_range(min: Number, max: Number) -> Generator[Number]: ...

[snip]

> I don't like adding syntax specific to generators (especially since
> most of the time send() won't be used at all).
>
> I could extend my Generator[Number] example by also allowing
> Generator[Number, Number] where the 2nd type would specify the
> argument accepted by send(). (Making it 2nd makes it easy to omit.)
>
> Or if you don't like this (I'm not crazy about letting people guess
> what the second type is for either) you could write Generator(Number,
> send=Number) or even Generator(returns=Number, send=Number). I think
> it's fine to specify the return type of the generator by position and
> the rest by keyword since the return type is always present.
> Generator[Number] and Generator(Number) could mean the same thing
> assuming Generator is not a real type like list but a pseudo type only
> used for type annotations, like Sequence, Mapping, Iterator etc.

I like using Generator[yields, send] in combination with "->". The
send parameter might be a good candidate for keyword-only arguments.

Collin Winter

From collinw at gmail.com  Fri May 19 04:24:03 2006
From: collinw at gmail.com (Collin Winter)
Date: Thu, 18 May 2006 22:24:03 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
Message-ID: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>

On 5/18/06, Guido van Rossum <guido at python.org> wrote:
> On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> > In looking through all of Guido's blog posts on the subject -- and all
> > the comments on them -- I haven't seen anyone consider the case of
> > generators. Assuming that "->" makes assertions only about the
> > function's return type, if I were to write a generator with the
> > following type,
> >
> > """def my_range(min: Number, max: Number) -> Number"""
> >
> > it would blow up because the function returns a generator, not a Number.
>
> My first response: specify the return type as Generator[Number] so the
> whole thing would look like
>
> def my_range(min: Number, max: Number) -> Generator[Number]: ...

[snip]

> I could extend my Generator[Number] example by also allowing
> Generator[Number, Number] where the 2nd type would specify the
> argument accepted by send(). (Making it 2nd makes it easy to omit.)

[snip]

> Or if you don't like this (I'm not crazy about letting people guess
> what the second type is for either) you could write Generator(Number,
> send=Number) or even Generator(returns=Number, send=Number).

This leads nicely into another question I was going to raise : )

BDFL syntax has generally used "Sometype[parameterizer]" to indicate
type parameterization. With this Generator example, you've gone ahead
and implicitly addressed several of the more general questions I had
about parameterization (but since explicit is better than
implicit...):

1. As above, I've occasionally seen "Sometype(parameterizer)" used to
indicate parameterization, but the bracket-based syntax predominates;
can I get a pronouncement endorsing the bracket version as "official"?

2. You've used keyword parameters in the above parens-based example; I
take it these will be legal in all parameterizations?

If yes, this would offer a solution to something I haven't seen
addressed in any blog posts: how to parameterize dict. Plenty of
examples show parameterizations of list, tuple, set, etc using
positional arguments.

Use of positional arguments to parameterize dict, e.g., dict[str,
Number], is ugly, but keyword arguments would allow the prettier
dict[key=str, value=Number] (which might also be another use case for
the proposed keyword-only arguments).


Now for some more specific questions:

3. What does list[] mean (i.e., brackets without a parameterizer)? Is
it an error? An empty list (the list *must* be empty)? Is it different
from a type annotation of list (without brackets)?

Similarly, can you do something like list[Number, String] to assert
that the list instance must have an length evenly divisible by two and
consisting of alternating Numbers and Strings? (That is, [4, 'abc',
7.0, 'foo'] is valid but [4, 'abc', 7.0] is not.)

4. In one blog post, tuple[Number] is described as creating a tuple of
arbitrary length with Number elements, with something like (Number *
Number * String) used to create a 3-tuple. Could we drop the cartesian
product notation for this latter usage and use tuple[Number, Number,
String] instead?


> Generator[Number] and Generator(Number) could mean the same thing
> assuming Generator is not a real type like list but a pseudo type only
> used for type annotations, like Sequence, Mapping, Iterator etc.

This gets into another question: will user-defined annotation classes
be able to use the same parameterization notation?

I'd like to see the typechecking machinery ignore differences like
"real type" v "pseudo type", looking only at whether, zB, a
__parameterize__ method is present. Using __parameterize__ method (or
some other name) allows maximum flexibility with respect to type
parameterization.

For example, the built-in list type might not allow the patterned
parameterization I asked about above. A user might choose to subclass
list to provide this, giving the subclass a __parameterize__ method
something like:

@classmethod
def __parameterize__(cls, *vargs):
    ....

I-need-to-teach-Gmail's-spellchecker-the-word-"parameterization"-ly yours,
Collin Winter

From guido at python.org  Fri May 19 06:13:18 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 21:13:18 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
Message-ID: <ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>

On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
[...]
> BDFL syntax has generally used "Sometype[parameterizer]" to indicate
> type parameterization. With this Generator example, you've gone ahead
> and implicitly addressed several of the more general questions I had
> about parameterization (but since explicit is better than
> implicit...):
>
> 1. As above, I've occasionally seen "Sometype(parameterizer)" used to
> indicate parameterization, but the bracket-based syntax predominates;
> can I get a pronouncement endorsing the bracket version as "official"?

I'm pragmatic. You can't use list(int) because list is a concrete type
so that would call the list constructor. So list[int] it is. This also
happens to match Eiffel, but I chose it primarily because I wanted
something that's not new syntax and yet somewhat resembled C++ or Java
SomeContainer<T>.

But since it's just an expression, I'm not against using functional
notation if for some reason square brackets don't quite work (e.g.
when a keyword argument would be desirable).

> 2. You've used keyword parameters in the above parens-based example; I
> take it these will be legal in all parameterizations?

Yes. The important thing is that THE SYNTAX FOR PARAMETER ANNOTATIONS
IS JUST AN EXPRESSION. So it can use any syntactic feature of
expressions.

> If yes, this would offer a solution to something I haven't seen
> addressed in any blog posts: how to parameterize dict. Plenty of
> examples show parameterizations of list, tuple, set, etc using
> positional arguments.
>
> Use of positional arguments to parameterize dict, e.g., dict[str,
> Number], is ugly, but keyword arguments would allow the prettier
> dict[key=str, value=Number] (which might also be another use case for
> the proposed keyword-only arguments).

Maybe you didn't find all blog posts, or maybe I really didn't mention
it, but I personally prefer dict[str, Number]. There really can't be
much confusion over what these mean for anyone who knows what a dict
is.

> Now for some more specific questions:
>
> 3. What does list[] mean (i.e., brackets without a parameterizer)? Is
> it an error? An empty list (the list *must* be empty)? Is it different
> from a type annotation of list (without brackets)?

It's a syntax error:

Python 2.5a1 (trunk, Apr  9 2006, 21:00:48)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.]
>>> list[]
  File "<stdin>", line 1
    list[]
         ^
SyntaxError: invalid syntax
>>>

To answer the implicit question: list (without brackets) would mean
the same as list[object].

> Similarly, can you do something like list[Number, String] to assert
> that the list instance must have an length evenly divisible by two and
> consisting of alternating Numbers and Strings? (That is, [4, 'abc',
> 7.0, 'foo'] is valid but [4, 'abc', 7.0] is not.)

No. I don't like using lists that way anyway. I think that's probably
an idiom from Perl or Tcl?

> 4. In one blog post, tuple[Number] is described as creating a tuple of
> arbitrary length with Number elements, with something like (Number *
> Number * String) used to create a 3-tuple. Could we drop the cartesian
> product notation for this latter usage and use tuple[Number, Number,
> String] instead?

Yes, please.

> > Generator[Number] and Generator(Number) could mean the same thing
> > assuming Generator is not a real type like list but a pseudo type only
> > used for type annotations, like Sequence, Mapping, Iterator etc.
>
> This gets into another question: will user-defined annotation classes
> be able to use the same parameterization notation?

Yes. In fact believe I once wrote a metaclass derived from type that
would let you create arbitrary user-defined parameterizable classes,
and I used this to prototype a few parts of my notation. I think it
went like this:

class List(list):
  __metaclass__ = ParameterizedType
  __parameters__ = ["T"]

class Dict(dict):
  __metaclass__ = ParameterizedType
  __parameters__ = ["T1", "T2"]

I'm not 100% sure about the __parameters__ thing, and I'm not sure how
you'd do tuple[<varargs>] but I'm sure we can find a way.

(I don't recall where I put the code; it's probably easier to recreate
it from scratch anyway, but I doubt I have time tonight -- I'm just
back from a week off-line and have some catching up to do.)

> I'd like to see the typechecking machinery ignore differences like
> "real type" v "pseudo type", looking only at whether, zB, a
> __parameterize__ method is present. Using __parameterize__ method (or
> some other name) allows maximum flexibility with respect to type
> parameterization.
>
> For example, the built-in list type might not allow the patterned
> parameterization I asked about above. A user might choose to subclass
> list to provide this, giving the subclass a __parameterize__ method
> something like:
>
> @classmethod
> def __parameterize__(cls, *vargs):
>     ....

I'm not sure what you're up to here -- maybe it's a reference to
something you did in your own system? But I agree that that kind of
subclassing (perhaps at the metaclass level) ought to be possible.

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

From guido at python.org  Fri May 19 06:17:28 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 21:17:28 -0700
Subject: [Python-3000] Unicode identifiers (Was: sets in P3K?)
In-Reply-To: <e3v5nq$mrc$1@sea.gmane.org>
References: <mailman.18397.1146112002.27774.python-3000@python.org>
	<4450CB36.7090504@gmail.com> <44511237.5000609@ewtllc.com>
	<e2r8b2$ni7$1@sea.gmane.org> <e2rhi5$q8e$1@sea.gmane.org>
	<17489.31069.526965.186604@montanaro.dyndns.org>
	<4451AF74.8040702@gmx.net>
	<ca471dc20604280732j4c12c5cbxf50a4c012fa1e7f1@mail.gmail.com>
	<445279F7.8080306@v.loewis.de> <e3v5nq$mrc$1@sea.gmane.org>
Message-ID: <ca471dc20605182117l56f65981k6d3f1761c5933c83@mail.gmail.com>

On 5/11/06, Boris Borcic <bborcic at gmail.com> wrote:
> I am late on this subthread, but FWIW and FYI with Python 2.4.2 and Idle 1.1.2
> on WinXP I can use non-ascii identifiers transparently both in modules and at
> the prompt, for instance
>
>  >>> gr?zi = r?le = ni?o = ?a = True
>  >>> gr?zi
> True
>
> I thought it was a provided feature, but scanning the subthread gave the
> contrary impression. Should we expect disappearance of the property ?

It was never my intention for this to be a feature; I always wanted it
to be ASCII letters only. Python should stop using isXXX() macros that
have locale-dependent meaning.

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

From guido at python.org  Fri May 19 06:26:31 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 21:26:31 -0700
Subject: [Python-3000] exceptions with keyword arguments
In-Reply-To: <20060518125745.686C.JCARLSON@uci.edu>
References: <bbaeab100605171143n4b028b92kf1d386081840489c@mail.gmail.com>
	<1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com>
	<20060518125745.686C.JCARLSON@uci.edu>
Message-ID: <ca471dc20605182126x2fc692ddmde1f20d37cac12ca@mail.gmail.com>

On 5/18/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> "tomer filiba" <tomerfiliba at gmail.com> wrote:
> > On 5/17/06, Brett Cannon <brett at python.org> wrote:
> > > And I brought this up with Guido once and he was not enthusiastic
> > > about it.  Basically, keep exceptions simple.  They are important
> > > and basic enough to keep it simple.  If you want fancier support,
> > > subclass Exception and add the support you want.
> >
> > well, if guido pronounced on it than i guess it's settled, but why do you
> > condsider *args to be simple and **kwargs not as simple? don't you
> > think "ex.filename" is simpler/clearer than "ex[1]"?
>
> From what I understand of Brett's post, ex[1] won't be available anymore
> either.

Correct.

> While it would be convenient for inspecting exceptions when they are
> caught via ex.attr, creating exceptions with keyword arguments seems
> like it would be a bit if a pain.

All this has little to do with exceptions per se. It's just about
classes, subclasses, constructor signatures, and instance attributes.

There's no need for the attributes to match the keywords, nor is there
a need to access values using x[i] notation when they were passed to
the constructor sequentially.

BaseException (in py3k) defines one positional argument and one
attribute named message.

Some standard exceptions will provide more attributes (e.g. errno,
filename, strerror etc.) and ways to provide values for those via the
constructor. It's up to each subclass of BaseException to define the
appropriate costructor signature.

(Is this perhaps yet another case of the misunderstanding that the
constructor signature of a subclass must be compatible with that of
the base class? Assuming single inheritance there's no need for that
restriction.)

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

From guido at python.org  Fri May 19 06:35:31 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 21:35:31 -0700
Subject: [Python-3000] Another overloaded functions usecase
In-Reply-To: <3e5572520605180512s2e54b8deq5e05a4f493a607c3@mail.gmail.com>
References: <3e5572520605180512s2e54b8deq5e05a4f493a607c3@mail.gmail.com>
Message-ID: <ca471dc20605182135u139ac58l9d977d6a704c3ee3@mail.gmail.com>

Which slide in Norvig's presentation are you referring to?

Why would you have to pass token.type to convert()? I'd think that the
simplest API would be

  convert(token, target).

What am I missing?

--Guido

On 5/18/06, Thomas Dunham <thomas.dunham at gmail.com> wrote:
> Talk on overloaded functions seems a bit sparse recently, and as I rather like
> the idea I wondered if another usecase would be helpful. I reworked
> this from an example published 10 years ago by someone who a couple of
> you guys might see at lunchtime.
>
> Say we want to read a text document in RTF and convert to one of many
> formats. The gang of four describe a builder pattern to do this, and
> their approach requires a class for each type of object to build, and
> another for the director. It's likely that you'd ditch the director if
> you were writing in Python:
>
> class TEXConverter(TextConverter):
>   def convertChar(token):
> ...
>
> builder = TEXConverter()
> ...
>
> act = dict(
>     CHAR=builder.convertChar,
>     FONT=builder.convertFont,
>     PARA=builder.convertParagraph
> )
>
> t = get_token()
> act[t.type](t)
>
>
> Maybe with overloaded functions it could look like this:
>
> target = TEXText()
> Font, Para, Char = inputTypes()
> ...
> token = get_token()
> convert(token, token.type, target)
> ...
> def convert(token, type:Font, target:TEXText):
>     ...
>
> def convert(token, type:Para, target:TEXText):
>     ...
>
> def convert(token, type:Char, target:TEXText):
>     ...
>
> In the original (written in Dylan) Font, Para, Char are instances, and
> it uses == to dispatch on individual objects. I'm suggesting creating
> more classes and dispatching on (possibly singleton) instances of
> them. (The origonal is here: http://norvig.com/design-patterns/)
>
> I don't think this is as elegant as Norvig's version, but I do like
> the way it makes the language do all the dispatching, and looking at
> the function prototypes gives a good impression of the type/operation
> grid that is somewhat hidden in the single-dispatch version.
>
> Tom
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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

From collinw at gmail.com  Fri May 19 06:46:26 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 00:46:26 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
Message-ID: <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> > I'd like to see the typechecking machinery ignore differences like
> > "real type" v "pseudo type", looking only at whether, zB, a
> > __parameterize__ method is present. Using __parameterize__ method (or
> > some other name) allows maximum flexibility with respect to type
> > parameterization.
> >
> > For example, the built-in list type might not allow the patterned
> > parameterization I asked about above. A user might choose to subclass
> > list to provide this, giving the subclass a __parameterize__ method
> > something like:
> >
> > @classmethod
> > def __parameterize__(cls, *vargs):
> >     ....
>
> I'm not sure what you're up to here -- maybe it's a reference to
> something you did in your own system? But I agree that that kind of
> subclassing (perhaps at the metaclass level) ought to be possible.

I'm just trying to flesh out how type parameterization will work under
the covers. What I'm proposing is that list[int] would desugar to
list.__parameterize__(int). In context:

def foo(a: int, b: list[int]) -> int

desugars to

def foo(a: int, b: list.__parameterize__(int)) -> int

The __parameterize__ methods take the parameter(s) as arguments and
return an object that can be used to verify that an object is a list
with int elements.

I've implemented a demo of what I'm driving at, using your
metaclass-with-__getitem__ method, taking a PatternedList class as a
quick example [1].

My goal with this is to keep user-defined annotation classes on the
same level as the built-in types, to prevent them from becoming
second-class citizens in this system.

Collin Winter

[1] - http://tinyurl.com/egabj

From guido at python.org  Fri May 19 06:48:50 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 21:48:50 -0700
Subject: [Python-3000] State of the object system
In-Reply-To: <e4ft38$qjg$1@sea.gmane.org>
References: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>
	<e4ft38$qjg$1@sea.gmane.org>
Message-ID: <ca471dc20605182148n6ac77f92y7c9004531d59314@mail.gmail.com>

On 5/17/06, Terry Reedy <tjreedy at udel.edu> wrote:
>
> "Michael Chermside" <mcherm at mcherm.com> wrote in message
> news:20060517053503.oq4mtmzuzmv4s4sw at login.werra.lunarpages.com...
> > However, this is more of a practice than a prohibition... it IS
> > possible to modify existing classes in Python.
>
> If the class is defined/written in Python.
>
> > Unfortunately, for implementation reasons you can't modify most
> > built-in (and some user-defined) classes in this fashion:
>
> Being able to add Python-coded functions as methods of compiled C-coded
> types/classes (builting or otherwise) would require some wrapping machinery
> that would slow down normal usage.

I don't think so.

There are two reasons why I currently forbid modifying built-in types:

(a) I worry about a user modifying a built-in type to fit their needs
(e.g. redefining dict.__getitem__ to return None if the value isn't
there) and thereby breaking a library module they use (perhaps
indirectly), and having a hell of a time debugging their
self-inflicted problem.

(b) CPython supports multiple interpreters (although you have to write
C code to benefit from this feature -- mod_python does this I
believe). The built-in types are currently shared between all
interpreters. Thus changes made in one interpreter, even if benign
(not of the nature described in (a)), affect all interpreters, which
would be bad.

I suppose if we decided we really didn't care about (a), we could
write some code that created pristine copies of all built-in types
when a new interpreter is created. Extension modules would also
require some kind of hack but this could all be solved if we really
wanted to. Or we could stop caring about multiple interpreters -- they
are not as successful as I expected when I added them. (However,
Brett's thesis on sandboxing may revive them -- or provide an
alternative.)

Some people believe that (a) won't be a problem in practice because
few people would *modify* the built-in types; instead, they would just
*add* stuff, and make very sure to avoid name conflicts.

Suppose built-in types were modifiable, then all sorts of type
registries could be replaced by special methods. The standard library
could use __foo__ as naming convention. Third party code could use
__foo or some other naming convention e.g.
package__subpackage__module__pick_your_name_here.

This strategy (like overloaded/generic functions, BTW) means that
subclasses by default get the same treatment as the base class that
defines the special method. This is different than the type registries
currently used e.g. by pickle.py and copy.py. (For example, pickling
has a special typecode for ints which shouldn't be used for a subclass
of int.) But I think that could be overcome by checking for an exact
type match, and otherwise doing something more generic. Some built-in
types already have such shortcuts in their __new__ methods. And it
would only affect a few very popular types that get special treatment
anyway.

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

From guido at python.org  Fri May 19 07:00:20 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 22:00:20 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
Message-ID: <ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>

On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> > On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> > > I'd like to see the typechecking machinery ignore differences like
> > > "real type" v "pseudo type", looking only at whether, zB, a
> > > __parameterize__ method is present. Using __parameterize__ method (or
> > > some other name) allows maximum flexibility with respect to type
> > > parameterization.
> > >
> > > For example, the built-in list type might not allow the patterned
> > > parameterization I asked about above. A user might choose to subclass
> > > list to provide this, giving the subclass a __parameterize__ method
> > > something like:
> > >
> > > @classmethod
> > > def __parameterize__(cls, *vargs):
> > >     ....
> >
> > I'm not sure what you're up to here -- maybe it's a reference to
> > something you did in your own system? But I agree that that kind of
> > subclassing (perhaps at the metaclass level) ought to be possible.
>
> I'm just trying to flesh out how type parameterization will work under
> the covers. What I'm proposing is that list[int] would desugar to
> list.__parameterize__(int). In context:
>
> def foo(a: int, b: list[int]) -> int
>
> desugars to
>
> def foo(a: int, b: list.__parameterize__(int)) -> int
>
> The __parameterize__ methods take the parameter(s) as arguments and
> return an object that can be used to verify that an object is a list
> with int elements.
>
> I've implemented a demo of what I'm driving at, using your
> metaclass-with-__getitem__ method, taking a PatternedList class as a
> quick example [1].
>
> My goal with this is to keep user-defined annotation classes on the
> same level as the built-in types, to prevent them from becoming
> second-class citizens in this system.
>
> Collin Winter
>
> [1] - http://tinyurl.com/egabj

That's not quite how I did it. list[int] should return another type,
not a list instance. Here's a minimal example of what I'm after (truly
minimal because it only allows a single parameter named T):

class Parameterizable1(type):
    # Simplification: only one parameter allowed
    def __getitem__(self, arg):
        newcls = self.__class__(self.__name__, (self,), {})
        newcls.T = arg
        return newcls
    def __repr__(self):
        if hasattr(self, "T"):
            return "%s[%s]" % (self.__name__, self.T)
        else:
            return self.__name__

class List(list):
    __metaclass__ = Parameterizable1

print List
print List[int]

class Int(int):
    # This isn't really meant to be parameterizable, but has a nicer repr()
    __metaclass__ = Parameterizable1

print List[Int]

# Show that
a = List[int]()
a.append(0)
a.append(42)
print a

This prints

List
List[<type 'int'>]
List[Int]
[0, 42]


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

From kay.schluehr at gmx.net  Fri May 19 07:02:19 2006
From: kay.schluehr at gmx.net (Kay Schluehr)
Date: Fri, 19 May 2006 07:02:19 +0200
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
Message-ID: <446D515B.8040802@gmx.net>

Collin Winter schrieb:

>In working on notes for the type annotations PEP, I've hit some
>ambiguous/unresolved issues in the BDFL annotation syntax (drawing
>primarily from [1] and other blog posts):
>
>As a quick recap, the syntax looks something like this:
>
>"""def foo(a: int, b: float, c: int = 5) -> list[int]"""
>  
>

I have a question to the audience. How do you represent higher order 
functions using this syntax? Another question: is there any intention to 
support ML style quards for pattern matching on algebraic /recursive types?

I'm still not sure I like this whole idea in the Python context ( I'm 
less concerned with syntax scrabbling but the semantics ) but anyway I'm 
curious how it evolves.

Kay




From guido at python.org  Fri May 19 07:07:16 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 22:07:16 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <446D515B.8040802@gmx.net>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
Message-ID: <ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>

On 5/18/06, Kay Schluehr <kay.schluehr at gmx.net> wrote:
> I have a question to the audience. How do you represent higher order
> functions using this syntax?

I think Collin and I both (independently) proposed the pragmatic
Function(<type>, <type>, ..., returns=<type>) for this.

We also discussed forward references; my proposal was that "lambda:A"
would be equivalent to "A" but usable as a forward reference.

> Another question: is there any intention to
> support ML style quards for pattern matching on algebraic /recursive types?

Can you rephrase that without references to ML or quads?

> I'm still not sure I like this whole idea in the Python context ( I'm
> less concerned with syntax scrabbling but the semantics ) but anyway I'm
> curious how it evolves.

Fair enough.

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

From guido at python.org  Fri May 19 07:17:18 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 22:17:18 -0700
Subject: [Python-3000] Function overloading (Math in Python 3.0)
In-Reply-To: <44669150.8020808@canterbury.ac.nz>
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4465FCC9.4000808@v.loewis.de>
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
	<44668160.7060709@gmail.com> <44669150.8020808@canterbury.ac.nz>
Message-ID: <ca471dc20605182217t217c318fxaf892ca7f6d687d9@mail.gmail.com>

On 5/13/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>
> > Py3k's function overloading should fix this:
>
> People are starting to talk about "Py3k's function overloading"
> as though it were a done deal. Has anything actually been
> decided about it yet.

To the contrary. My own expectation is that at best we'll have a
library module which supplies overloaded/generic functions (perhaps
along the lines of what I checked into sandbox/overload, perhaps as an
extension module for speed). This would be usable by certain parts of
the standard library (perhaps pickle.py and copy.py could use it, if
we can solve the subclassing issue for a handful of built-in types
that get special-cased for space savings). I doubt that any built-in
functions would be overloaded. I doubt that math.sqrt() would use it.
Perhaps a generic math module (gmath?) could be supplied that provided
overloaded versions of some or most math functions.

But even so we'd have to solve the delayed-loading issue: you don't
want "import gmath" to imply "import decimal, math, cmath, gnump" nor
would you (ideally) have "import decimal" imply "import gmath". But if
both are imported (in either order) the right thing should happen.
How...?

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

From kay.schluehr at gmx.net  Fri May 19 08:02:49 2006
From: kay.schluehr at gmx.net (Kay Schluehr)
Date: Fri, 19 May 2006 08:02:49 +0200
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>	
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
Message-ID: <446D5F89.2080504@gmx.net>

Guido van Rossum schrieb:

>> Another question: is there any intention to
>> support ML style quards for pattern matching on algebraic /recursive 
>> types?
>
>
> Can you rephrase that without references to ML or quads?

No, but the basic idea is easily explained using ML syntax and semantics.

ML lets users define their own datatypes which has the obvious advantage 
that they do not need to pollute their function signatures with 
definitions. Python would likely use class syntax for this purpose or 
interface syntax in future (?)

Some examples:

(* simple 'algebraic datatype' created by RED, YELLOW, BLUE . The vertical bars mark alternatives. *)

datatype PrimaryColours = RED | YELLOW | BLUE;  

(* simple recursive datatype. The '*' token is used to combine types to a cartesian product type *)

datatype IntTree = NIL | NODE of int * IntTree * IntTree;  


There is a symmetry between the usage of the vertical bars in datatype 
definitions and in "pattern matching" where the pattern mentioned here 
refers to the "algebraic datatype".

(* Function 'colourString' that keeps a PrimaryColours type. Note that ML is statically typed and each type will 
   be inferred so declarations in function signatures can be omitted.
 *)

fun colourString c =
    case c of
      RED    => "red"
    | BLUE   => "blue"
    | YELLOW => "yellow"
  ;


(* Another function defined on IntTree *)

fun preOrder t =
    case t of
      NIL => [ ]
    | NODE (i,left,right) => (preOrder left) @ (preOrder right) @ [i]
  ;


Regards,
Kay





From guido at python.org  Fri May 19 08:56:42 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 18 May 2006 23:56:42 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <446D5F89.2080504@gmx.net>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<446D5F89.2080504@gmx.net>
Message-ID: <ca471dc20605182356kfb5b446i15c268f5239580cf@mail.gmail.com>

On 5/18/06, Kay Schluehr <kay.schluehr at gmx.net> wrote:
> Guido van Rossum schrieb:
>
> >> Another question: is there any intention to
> >> support ML style quards for pattern matching on algebraic /recursive
> >> types?
> >
> > Can you rephrase that without references to ML or quads?
>
> No, but the basic idea is easily explained using ML syntax and semantics.
>
> ML lets users define their own datatypes which has the obvious advantage
> that they do not need to pollute their function signatures with
> definitions. Python would likely use class syntax for this purpose or
> interface syntax in future (?)
>
> Some examples:
>
> (* simple 'algebraic datatype' created by RED, YELLOW, BLUE . The vertical bars mark alternatives. *)
>
> datatype PrimaryColours = RED | YELLOW | BLUE;
>
> (* simple recursive datatype. The '*' token is used to combine types to a cartesian product type *)
>
> datatype IntTree = NIL | NODE of int * IntTree * IntTree;
>
>
> There is a symmetry between the usage of the vertical bars in datatype
> definitions and in "pattern matching" where the pattern mentioned here
> refers to the "algebraic datatype".
>
> (* Function 'colourString' that keeps a PrimaryColours type. Note that ML is statically typed and each type will
>    be inferred so declarations in function signatures can be omitted.
>  *)
>
> fun colourString c =
>     case c of
>       RED    => "red"
>     | BLUE   => "blue"
>     | YELLOW => "yellow"
>   ;
>
>
> (* Another function defined on IntTree *)
>
> fun preOrder t =
>     case t of
>       NIL => [ ]
>     | NODE (i,left,right) => (preOrder left) @ (preOrder right) @ [i]
>   ;

I'm frustrated by your inability to translate ML terms into Python;
you seem to assume that ML is easy, but I can guarantee you that in my
experience it's a language only spoken by people whose IQ is >= 150.

I still don't quite get which part you're interested in having in
Python's type system; if you can't explain it without mentioning ML,
the default answer to your original question (about intent) will have
to be no. :-)

I'm not sure what you meant by "quards" -- "quads" (as I originally
read it -- not knowing any ML it seemed totally plausible that it
might have something called quads) or "guards" (by which you could
perhaps mean the case statement above???). Guards are definitely not
planned.

I guess by "algebraic types" you meant enumerated types? Those aren't
planned either.

I happen to know what you mean by recursive types (even though you
don't explain the NODE thing in your example). I think we would do
that by defining the type first using some notation for forward
references (e.g. lambda:A as a forward ref to A). Then your IntTree
example could become (if I'm guessing right that @ is ML's list
concatenation operator):

class IntTree:
  op: int
  left: None | lambda:IntTree
  right: None | lambda:IntTree

def preOrder(t: IntTree):
  if t is None:
    return []
  else:
    return preOrder(t.left) + preOrder(t.right) + [t.op]
# Isn't this postOrder though?

However, note that I'm currently not proposing to have class attribute
annotations like "op: int" above, so we'd have to use some other way
to spell that. (While "op: int" seems a fine notation, it's ambiguous
about whether it refers to instance or class attributes.)

I'm not convinced that we need all this for the likely intended use,
since static type checking isn't really high on the agenda anyway.

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

From tomerfiliba at gmail.com  Fri May 19 09:21:13 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Fri, 19 May 2006 09:21:13 +0200
Subject: [Python-3000] exceptions with keyword arguments
In-Reply-To: <ca471dc20605182126x2fc692ddmde1f20d37cac12ca@mail.gmail.com>
References: <bbaeab100605171143n4b028b92kf1d386081840489c@mail.gmail.com>
	<1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com>
	<20060518125745.686C.JCARLSON@uci.edu>
	<ca471dc20605182126x2fc692ddmde1f20d37cac12ca@mail.gmail.com>
Message-ID: <1d85506f0605190021m36cdc209v95b8811c32a82142@mail.gmail.com>

Brett writes:
> as specified in the PEP.  But that does not stop someone from overriding
> BaseException in a subclass, as some built-ins do already.  So you can
> easily add your filename attribute.::
>
>  def __init__(self, filename):
>      self.filename = filename
>      BaseException.__init__(self, "%s does not exist" % filename)

Guido writes:
> Some standard exceptions will provide more attributes (e.g. errno,
> filename, strerror etc.) and ways to provide values for those via the
> constructor. It's up to each subclass of BaseException to define the
> appropriate costructor signature.

well, if this is the case, i'm happy with that. i was afraid it will end up
like today's AttributeError, where you must parse the message in order
to get the missing attribute's name. as long as exceptions will hold
information as attributes, i have no complaints.

----

still, what about ArgumentError? don't you think it's worth adding?
don't you think TypeError is misleading in that context?


-tomer

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
>
> On 5/18/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> >
> > "tomer filiba" <tomerfiliba at gmail.com> wrote:
> > > On 5/17/06, Brett Cannon <brett at python.org> wrote:
> > > > And I brought this up with Guido once and he was not enthusiastic
> > > > about it.  Basically, keep exceptions simple.  They are important
> > > > and basic enough to keep it simple.  If you want fancier support,
> > > > subclass Exception and add the support you want.
> > >
> > > well, if guido pronounced on it than i guess it's settled, but why do
> you
> > > condsider *args to be simple and **kwargs not as simple? don't you
> > > think "ex.filename" is simpler/clearer than "ex[1]"?
> >
> > From what I understand of Brett's post, ex[1] won't be available anymore
> > either.
>
> Correct.
>
> > While it would be convenient for inspecting exceptions when they are
> > caught via ex.attr, creating exceptions with keyword arguments seems
> > like it would be a bit if a pain.
>
> All this has little to do with exceptions per se. It's just about
> classes, subclasses, constructor signatures, and instance attributes.
>
> There's no need for the attributes to match the keywords, nor is there
> a need to access values using x[i] notation when they were passed to
> the constructor sequentially.
>
> BaseException (in py3k) defines one positional argument and one
> attribute named message.
>
> Some standard exceptions will provide more attributes (e.g. errno,
> filename, strerror etc.) and ways to provide values for those via the
> constructor. It's up to each subclass of BaseException to define the
> appropriate costructor signature.
>
> (Is this perhaps yet another case of the misunderstanding that the
> constructor signature of a subclass must be compatible with that of
> the base class? Assuming single inheritance there's no need for that
> restriction.)
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060519/3b334ac6/attachment.html 

From qrczak at knm.org.pl  Fri May 19 12:53:26 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Fri, 19 May 2006 12:53:26 +0200
Subject: [Python-3000] Function overloading (Math in Python 3.0)
In-Reply-To: <ca471dc20605182217t217c318fxaf892ca7f6d687d9@mail.gmail.com>
	(Guido van Rossum's message of "Thu, 18 May 2006 22:17:18 -0700")
References: <3d0cebfb0605111307y72bb8a1et99020fe96ff9e56@mail.gmail.com>
	<4465FCC9.4000808@v.loewis.de>
	<3d0cebfb0605131323t7b0cd67fs3572f12cca348aec@mail.gmail.com>
	<44668160.7060709@gmail.com> <44669150.8020808@canterbury.ac.nz>
	<ca471dc20605182217t217c318fxaf892ca7f6d687d9@mail.gmail.com>
Message-ID: <873bf6guah.fsf@qrnik.zagroda>

"Guido van Rossum" <guido at python.org> writes:

> But even so we'd have to solve the delayed-loading issue: you don't
> want "import gmath" to imply "import decimal, math, cmath, gnump" nor
> would you (ideally) have "import decimal" imply "import gmath". But if
> both are imported (in either order) the right thing should happen.
> How...?

What's wrong with "import decimal" implying "import gmath"?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From Thomas.Dunham at reuters.com  Fri May 19 15:36:23 2006
From: Thomas.Dunham at reuters.com (Thomas Dunham)
Date: Fri, 19 May 2006 14:36:23 +0100
Subject: [Python-3000] Another overloaded functions usecase
Message-ID: <9A461066B20BC240A55C1CD036D6B6010178B254@LONSMSXM06.emea.ime.reuters.com>

 
The slides are titled Multimethods, Pattern:Builder and Pattern:
Builder with Multimethods.
http://norvig.com/design-patterns/img025.htm to img027.htm.

Choosing the correct action always depends on two things: what you are
converting and what you are converting it to. If you use multiple
dispatch the language makes this choice in one go. If not the language 
makes half the choice based on the class of the builder and the
programmer 
has to maintain a dictionary of functions to make the other half. A side
benefit is using multiple dispatch makes each function's intent more
clear (IMO).

It looks dumb to pass an object and one of it's properties, but that's
needed to be able to say "call the implementation of convert that
encodes this token (that is a character) for TeX" in one call. I agree
your API is better, I'd likely end up with this:

def convert(token, target):
    convert(token, token.type, target)

I'm pretty sure that would be OK. It looked a bit odd to me at first
because it would TypeError on the arguments nowadays, but that seems
like an incorrect reflex.

Tom



-----Original Message-----
From: python-3000-bounces+thomas.dunham=reuters.com at python.org
[mailto:python-3000-bounces+thomas.dunham=reuters.com at python.org] On
Behalf Of Guido van Rossum
Sent: 19 May 2006 05:36
To: Thomas Dunham
Cc: python-3000 at python.org
Subject: Re: [Python-3000] Another overloaded functions usecase

Which slide in Norvig's presentation are you referring to?

Why would you have to pass token.type to convert()? I'd think that the
simplest API would be

  convert(token, target).

What am I missing?

--Guido

On 5/18/06, Thomas Dunham <thomas.dunham at gmail.com> wrote:
> Talk on overloaded functions seems a bit sparse recently, and as I 
> rather like the idea I wondered if another usecase would be helpful. I

> reworked this from an example published 10 years ago by someone who a 
> couple of you guys might see at lunchtime.
>
> Say we want to read a text document in RTF and convert to one of many 
> formats. The gang of four describe a builder pattern to do this, and 
> their approach requires a class for each type of object to build, and 
> another for the director. It's likely that you'd ditch the director if

> you were writing in Python:
>
> class TEXConverter(TextConverter):
>   def convertChar(token):
> ...
>
> builder = TEXConverter()
> ...
>
> act = dict(
>     CHAR=builder.convertChar,
>     FONT=builder.convertFont,
>     PARA=builder.convertParagraph
> )
>
> t = get_token()
> act[t.type](t)
>
>
> Maybe with overloaded functions it could look like this:
>
> target = TEXText()
> Font, Para, Char = inputTypes()
> ...
> token = get_token()
> convert(token, token.type, target)
> ...
> def convert(token, type:Font, target:TEXText):
>     ...
>
> def convert(token, type:Para, target:TEXText):
>     ...
>
> def convert(token, type:Char, target:TEXText):
>     ...
>
> In the original (written in Dylan) Font, Para, Char are instances, and

> it uses == to dispatch on individual objects. I'm suggesting creating 
> more classes and dispatching on (possibly singleton) instances of 
> them. (The origonal is here: http://norvig.com/design-patterns/)
>
> I don't think this is as elegant as Norvig's version, but I do like 
> the way it makes the language do all the dispatching, and looking at 
> the function prototypes gives a good impression of the type/operation 
> grid that is somewhat hidden in the single-dispatch version.
>
> Tom
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-3000 mailing list
Python-3000 at python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/thomas.dunham%40reute
rs.com


To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.


From pje at telecommunity.com  Fri May 19 16:28:14 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 19 May 2006 10:28:14 -0400
Subject: [Python-3000] Function overloading (Math in Python 3.0)
In-Reply-To: <mailman.22656.1148023276.27774.python-3000@python.org>
Message-ID: <5.1.1.6.0.20060519101521.01f54218@mail.telecommunity.com>

At 10:17 PM 5/18/2006 -0700, "Guido van Rossum" <guido at python.org> wrote:
>But even so we'd have to solve the delayed-loading issue: you don't
>want "import gmath" to imply "import decimal, math, cmath, gnump" nor
>would you (ideally) have "import decimal" imply "import gmath". But if
>both are imported (in either order) the right thing should happen.
>How...?

By putting something like this in decimal:

     @onImport('gmath')
     def register(gmath):
         defop gmath.sqrt(x: decimal):
             # etc.

PEAK already has an equivalent to 'onImport' that can do this without the 
need for import hooks.

If the module is already imported, the function just gets called 
normally.  If it's not imported, it puts an instance of a ModuleType 
subclass into sys.modules, whose __getattribute__ calls reload() to 
actually load the module, and then changes the module object's type back to 
normal and calls any functions that were registered for that module.

(This actually results in lazy loading, in that if you 'import gmath' after 
'import decimal', gmath won't really be imported until you reference one of 
its attributes, or until you 'from gmath import sqrt' or something.)


From guido at python.org  Fri May 19 17:02:48 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 08:02:48 -0700
Subject: [Python-3000] Another overloaded functions usecase
In-Reply-To: <9A461066B20BC240A55C1CD036D6B6010178B254@LONSMSXM06.emea.ime.reuters.com>
References: <9A461066B20BC240A55C1CD036D6B6010178B254@LONSMSXM06.emea.ime.reuters.com>
Message-ID: <ca471dc20605190802x2113625aid2d4b70733e8595a@mail.gmail.com>

A classic Python way of doing this would be to extract the type name
from the token and use that for dynamic dispatch on methods of the
builder. This is in a sense "better" because it isn't restricted to
types (could be used to implement HTTP GET/POST/PUT too). Example:

class TEXbuilder:
  def convert(self, token):
    method = getattr(self, "convert_%s" % token.type.__name__)
    return method(token)
  def convert_CHAR(self, token): ...
  def convert_FONT(self, token): ...
  def convert_PARA(self, token): ...

--Guido

On 5/19/06, Thomas Dunham <Thomas.Dunham at reuters.com> wrote:
>
> The slides are titled Multimethods, Pattern:Builder and Pattern:
> Builder with Multimethods.
> http://norvig.com/design-patterns/img025.htm to img027.htm.
>
> Choosing the correct action always depends on two things: what you are
> converting and what you are converting it to. If you use multiple
> dispatch the language makes this choice in one go. If not the language
> makes half the choice based on the class of the builder and the
> programmer
> has to maintain a dictionary of functions to make the other half. A side
> benefit is using multiple dispatch makes each function's intent more
> clear (IMO).
>
> It looks dumb to pass an object and one of it's properties, but that's
> needed to be able to say "call the implementation of convert that
> encodes this token (that is a character) for TeX" in one call. I agree
> your API is better, I'd likely end up with this:
>
> def convert(token, target):
>     convert(token, token.type, target)
>
> I'm pretty sure that would be OK. It looked a bit odd to me at first
> because it would TypeError on the arguments nowadays, but that seems
> like an incorrect reflex.
>
> Tom
>
>
>
> -----Original Message-----
> From: python-3000-bounces+thomas.dunham=reuters.com at python.org
> [mailto:python-3000-bounces+thomas.dunham=reuters.com at python.org] On
> Behalf Of Guido van Rossum
> Sent: 19 May 2006 05:36
> To: Thomas Dunham
> Cc: python-3000 at python.org
> Subject: Re: [Python-3000] Another overloaded functions usecase
>
> Which slide in Norvig's presentation are you referring to?
>
> Why would you have to pass token.type to convert()? I'd think that the
> simplest API would be
>
>   convert(token, target).
>
> What am I missing?
>
> --Guido
>
> On 5/18/06, Thomas Dunham <thomas.dunham at gmail.com> wrote:
> > Talk on overloaded functions seems a bit sparse recently, and as I
> > rather like the idea I wondered if another usecase would be helpful. I
>
> > reworked this from an example published 10 years ago by someone who a
> > couple of you guys might see at lunchtime.
> >
> > Say we want to read a text document in RTF and convert to one of many
> > formats. The gang of four describe a builder pattern to do this, and
> > their approach requires a class for each type of object to build, and
> > another for the director. It's likely that you'd ditch the director if
>
> > you were writing in Python:
> >
> > class TEXConverter(TextConverter):
> >   def convertChar(token):
> > ...
> >
> > builder = TEXConverter()
> > ...
> >
> > act = dict(
> >     CHAR=builder.convertChar,
> >     FONT=builder.convertFont,
> >     PARA=builder.convertParagraph
> > )
> >
> > t = get_token()
> > act[t.type](t)
> >
> >
> > Maybe with overloaded functions it could look like this:
> >
> > target = TEXText()
> > Font, Para, Char = inputTypes()
> > ...
> > token = get_token()
> > convert(token, token.type, target)
> > ...
> > def convert(token, type:Font, target:TEXText):
> >     ...
> >
> > def convert(token, type:Para, target:TEXText):
> >     ...
> >
> > def convert(token, type:Char, target:TEXText):
> >     ...
> >
> > In the original (written in Dylan) Font, Para, Char are instances, and
>
> > it uses == to dispatch on individual objects. I'm suggesting creating
> > more classes and dispatching on (possibly singleton) instances of
> > them. (The origonal is here: http://norvig.com/design-patterns/)
> >
> > I don't think this is as elegant as Norvig's version, but I do like
> > the way it makes the language do all the dispatching, and looking at
> > the function prototypes gives a good impression of the type/operation
> > grid that is somewhat hidden in the single-dispatch version.
> >
> > Tom
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-3000/guido%40python.org
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/thomas.dunham%40reute
> rs.com
>
>
> To find out more about Reuters visit www.about.reuters.com
>
> Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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

From collinw at gmail.com  Fri May 19 17:37:55 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 11:37:55 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
Message-ID: <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> That's not quite how I did it. list[int] should return another type,
> not a list instance. Here's a minimal example of what I'm after (truly
> minimal because it only allows a single parameter named T):

[snip]

I agree that the act of parameterizing dict, list, tuple, set, etc
will end up returning instances of other types, but I'd like to save
that particular discussion for later. For now, what do you think of
the underlying idea of having bracket-based parameterization be
redirected a call to some double-underscore method (as I outlined
earlier)?

I'm trying to give as much flexibility as possible to the annotation
classes. While simply assigning the parameter to an attribute of the
new annotation object (here, "newcls.T = arg") works for simple
examples, I can easily think of cases where the annotation class
(here, "List") would want to do its own processing:

1. Classes implementing boolean type expressions (Or, And, Not, Xor,
etc) might want to try and simplify the expression: Or(int, Or(int,
float)) simplifies to Or(int, float); And(Not(int), Not(float))
becomes Not(Or(int, float)); etc.

2. Similarly, annotation classes might want to do more complex
parameter validation. Or(), for instance, might want to assert that it
needs at least two distinct parameters (that is, Or(int, int, int)
simplifies to Or(int), which makes no sense and is an error).


The reason for putting parameterization into its own double-underscore
method is to make it easier to for people to incorporate their own
classes into the type system. Rather than playing metaclass tricks or
writing a separate class to handle parameterized typechecking, you can
use the same class name in type expressions as you do in "real" code:
constructing a BinaryTree instance might look like BinaryTree(5, 6) in
code, and asserting that it contains only ints would look like
BinaryTree[int]. To add parameterizability to BinaryTree, all you'd
have to do is define an appropriate __parameterize__ method.

Not being able to reuse the BinaryTree class like this leads to things
like CheckBinaryTree(int) or something equally unpleasant.

Collin Winter

From Thomas.Dunham at reuters.com  Fri May 19 17:34:40 2006
From: Thomas.Dunham at reuters.com (Thomas Dunham)
Date: Fri, 19 May 2006 16:34:40 +0100
Subject: [Python-3000] Another overloaded functions usecase
Message-ID: <9A461066B20BC240A55C1CD036D6B6010178B33B@LONSMSXM06.emea.ime.reuters.com>

You're right, that is better - I should have thought of it. 

Thanks,
Tom 


-----Original Message-----
From: python-3000-bounces+thomas.dunham=reuters.com at python.org
[mailto:python-3000-bounces+thomas.dunham=reuters.com at python.org] On
Behalf Of Guido van Rossum
Sent: 19 May 2006 16:03
To: Thomas Dunham
Cc: python-3000 at python.org
Subject: Re: [Python-3000] Another overloaded functions usecase

A classic Python way of doing this would be to extract the type name
from the token and use that for dynamic dispatch on methods of the
builder. This is in a sense "better" because it isn't restricted to
types (could be used to implement HTTP GET/POST/PUT too). Example:

class TEXbuilder:
  def convert(self, token):
    method = getattr(self, "convert_%s" % token.type.__name__)
    return method(token)
  def convert_CHAR(self, token): ...
  def convert_FONT(self, token): ...
  def convert_PARA(self, token): ...

--Guido

On 5/19/06, Thomas Dunham <Thomas.Dunham at reuters.com> wrote:
>
> The slides are titled Multimethods, Pattern:Builder and Pattern:
> Builder with Multimethods.
> http://norvig.com/design-patterns/img025.htm to img027.htm.
>
> Choosing the correct action always depends on two things: what you are

> converting and what you are converting it to. If you use multiple 
> dispatch the language makes this choice in one go. If not the language

> makes half the choice based on the class of the builder and the 
> programmer has to maintain a dictionary of functions to make the other

> half. A side benefit is using multiple dispatch makes each function's 
> intent more clear (IMO).
>
> It looks dumb to pass an object and one of it's properties, but that's

> needed to be able to say "call the implementation of convert that 
> encodes this token (that is a character) for TeX" in one call. I agree

> your API is better, I'd likely end up with this:
>
> def convert(token, target):
>     convert(token, token.type, target)
>
> I'm pretty sure that would be OK. It looked a bit odd to me at first 
> because it would TypeError on the arguments nowadays, but that seems 
> like an incorrect reflex.
>
> Tom
>
>
>
> -----Original Message-----
> From: python-3000-bounces+thomas.dunham=reuters.com at python.org
> [mailto:python-3000-bounces+thomas.dunham=reuters.com at python.org] On 
> Behalf Of Guido van Rossum
> Sent: 19 May 2006 05:36
> To: Thomas Dunham
> Cc: python-3000 at python.org
> Subject: Re: [Python-3000] Another overloaded functions usecase
>
> Which slide in Norvig's presentation are you referring to?
>
> Why would you have to pass token.type to convert()? I'd think that the

> simplest API would be
>
>   convert(token, target).
>
> What am I missing?
>
> --Guido
>
> On 5/18/06, Thomas Dunham <thomas.dunham at gmail.com> wrote:
> > Talk on overloaded functions seems a bit sparse recently, and as I 
> > rather like the idea I wondered if another usecase would be helpful.

> > I
>
> > reworked this from an example published 10 years ago by someone who 
> > a couple of you guys might see at lunchtime.
> >
> > Say we want to read a text document in RTF and convert to one of 
> > many formats. The gang of four describe a builder pattern to do 
> > this, and their approach requires a class for each type of object to

> > build, and another for the director. It's likely that you'd ditch 
> > the director if
>
> > you were writing in Python:
> >
> > class TEXConverter(TextConverter):
> >   def convertChar(token):
> > ...
> >
> > builder = TEXConverter()
> > ...
> >
> > act = dict(
> >     CHAR=builder.convertChar,
> >     FONT=builder.convertFont,
> >     PARA=builder.convertParagraph
> > )
> >
> > t = get_token()
> > act[t.type](t)
> >
> >
> > Maybe with overloaded functions it could look like this:
> >
> > target = TEXText()
> > Font, Para, Char = inputTypes()
> > ...
> > token = get_token()
> > convert(token, token.type, target)
> > ...
> > def convert(token, type:Font, target:TEXText):
> >     ...
> >
> > def convert(token, type:Para, target:TEXText):
> >     ...
> >
> > def convert(token, type:Char, target:TEXText):
> >     ...
> >
> > In the original (written in Dylan) Font, Para, Char are instances, 
> > and
>
> > it uses == to dispatch on individual objects. I'm suggesting 
> > creating more classes and dispatching on (possibly singleton) 
> > instances of them. (The origonal is here: 
> > http://norvig.com/design-patterns/)
> >
> > I don't think this is as elegant as Norvig's version, but I do like 
> > the way it makes the language do all the dispatching, and looking at

> > the function prototypes gives a good impression of the 
> > type/operation grid that is somewhat hidden in the single-dispatch
version.
> >
> > Tom
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-3000/guido%40python.or
> > g
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/) 
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/thomas.dunham%40reu
> te
> rs.com
>
>
> To find out more about Reuters visit www.about.reuters.com
>
> Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the views
of Reuters Ltd.
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-3000 mailing list
Python-3000 at python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/thomas.dunham%40reute
rs.com


To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.


From collinw at gmail.com  Fri May 19 17:51:41 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 11:51:41 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
Message-ID: <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> On 5/18/06, Kay Schluehr <kay.schluehr at gmx.net> wrote:
> > I have a question to the audience. How do you represent higher order
> > functions using this syntax?
>
> I think Collin and I both (independently) proposed the pragmatic
> Function(<type>, <type>, ..., returns=<type>) for this.

Based on a suggestion from Nick Coghlan [1], I'm now favoring
something like this:

Function(<type>, <type>, required_keyword=<type>, ...).returns(<type>)

The idea would be that you can use keyword arguments to Function to
assert that the passed-in function object supports being called with
certain keyword arguments.
That is, if you were planning to call a passed-in function like so:

func(5, 6, abc=7)

you'd want to assert that func actually has a parameter named 'abc'.
The corresponding Function would be Function(Number, Number,
abc=Number).

Using a 'returns' keyword argument to Function would effectively
prohibit you from making sure that a function has a parameter named
'returns'. Hence, the returns() method.

As I mentioned [2], you can play around with this model using the
trunk/ version of typecheck [3] (with docs for Function() [4]). This
is by no means set in stone, so comment away. The main point I'm not
entirely happy with: the use of star() and double_star() methods to
indicate types for *vargs and **kwargs, respectively.

If you like this general approach to handling Function(), I'll sketch
out a version of Generator along the same lines.

Collin Winter

[1] - http://mail.python.org/pipermail/python-3000/2006-May/002033.html
[2] - http://mail.python.org/pipermail/python-3000/2006-May/002061.html
[3] - http://oakwinter.com/code/typecheck/dist/typecheck-svn-latest.tar.gz
[4]  - http://oakwinter.com/code/typecheck/dev/utility/function.html

From paul at boddie.org.uk  Fri May 19 18:14:32 2006
From: paul at boddie.org.uk (Paul Boddie)
Date: Fri, 19 May 2006 18:14:32 +0200
Subject: [Python-3000] Type annotations: annotating generators
Message-ID: <200605191814.33021.paul@boddie.org.uk>

Guido van Rossum wrote:
>
> I'm not convinced that we need all this for the likely intended use,
> since static type checking isn't really high on the agenda anyway.

I know I'll get into trouble for quoting this out of context, and I accept 
that there's a difference between static typing and writing declarations that 
look like static type declarations but which operate at run-time. However, I 
keep wondering whether we're missing out on something by adopting a type 
description language that will either prove to be inadequately expressive or 
evolve to something on the level of a full programming language in its own 
right.

What's the general opinion on systems which attempt to infer and predict 
inappropriate type usage? (Which I'm guessing is the main motivation here, 
rather than performance, which if I recall correctly, was downplayed in the 
context of "optional" type declarations.) By "predict", I mean something that 
operates before run-time; not something which tells you 100ns before an 
exception is raised. Couldn't such systems be a better aid to program 
reliability? Would "optional" type declarations be relevant to the operation 
of such systems?

Paul

From guido at python.org  Fri May 19 18:48:39 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 09:48:39 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
Message-ID: <ca471dc20605190948g75df8e5s108319032662e9a8@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> > That's not quite how I did it. list[int] should return another type,
> > not a list instance. Here's a minimal example of what I'm after (truly
> > minimal because it only allows a single parameter named T):
>
> [snip]
>
> I agree that the act of parameterizing dict, list, tuple, set, etc
> will end up returning instances of other types, but I'd like to save
> that particular discussion for later. For now, what do you think of
> the underlying idea of having bracket-based parameterization be
> redirected a call to some double-underscore method (as I outlined
> earlier)?

It feels a little too general for my taste. Have you written a bunch
of those __parameterize__ functions yet? I somehow feel that the
metaclass might want to work a little harder so that the
parameterizable class only has to specify what's unique to it. For
example (not sure this is the right API) I could imagine that a
parameterizable class should only have to do the following:

  class List(list):
      __metaclass__ = ParameterizableClass
      __parameters__ = ["T"]

List[X] would then return a new class C for which C.T is X.

(This is vaguely analogous to __slots__ -- but only vaguely because
it's about the class and not about the instances.)

> I'm trying to give as much flexibility as possible to the annotation
> classes. While simply assigning the parameter to an attribute of the
> new annotation object (here, "newcls.T = arg") works for simple
> examples, I can easily think of cases where the annotation class
> (here, "List") would want to do its own processing:
>
> 1. Classes implementing boolean type expressions (Or, And, Not, Xor,
> etc) might want to try and simplify the expression: Or(int, Or(int,
> float)) simplifies to Or(int, float); And(Not(int), Not(float))
> becomes Not(Or(int, float)); etc.

I'm confused. Are you proposing that Or etc. are classses? How would this work?

I think this may be odd enough that subclassing the metaclass would be
more appropriate. But yo have to explain more what this would do --
I'm not grasping the specifics from your brief examples, to me they
feel like functions, not classes.

> 2. Similarly, annotation classes might want to do more complex
> parameter validation. Or(), for instance, might want to assert that it
> needs at least two distinct parameters (that is, Or(int, int, int)
> simplifies to Or(int), which makes no sense and is an error).

So that's really the same example.

> The reason for putting parameterization into its own double-underscore
> method is to make it easier to for people to incorporate their own
> classes into the type system. Rather than playing metaclass tricks or
> writing a separate class to handle parameterized typechecking, you can
> use the same class name in type expressions as you do in "real" code:
> constructing a BinaryTree instance might look like BinaryTree(5, 6) in
> code, and asserting that it contains only ints would look like
> BinaryTree[int]. To add parameterizability to BinaryTree, all you'd
> have to do is define an appropriate __parameterize__ method.
>
> Not being able to reuse the BinaryTree class like this leads to things
> like CheckBinaryTree(int) or something equally unpleasant.

Agreed. But we need code before we can continue this discussion; I
don't immediately how you get from this argument to making each class
implement its own __parameterize__() method.

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

From guido at python.org  Fri May 19 18:58:53 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 09:58:53 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <200605191814.33021.paul@boddie.org.uk>
References: <200605191814.33021.paul@boddie.org.uk>
Message-ID: <ca471dc20605190958i359f4926md28d6a7cf4d8c63@mail.gmail.com>

On 5/19/06, Paul Boddie <paul at boddie.org.uk> wrote:
> Guido van Rossum wrote:
> >
> > I'm not convinced that we need all this for the likely intended use,
> > since static type checking isn't really high on the agenda anyway.
>
> I know I'll get into trouble for quoting this out of context, and I accept
> that there's a difference between static typing and writing declarations that
> look like static type declarations but which operate at run-time. However, I
> keep wondering whether we're missing out on something by adopting a type
> description language that will either prove to be inadequately expressive or
> evolve to something on the level of a full programming language in its own
> right.

WhatI'm trying to do primarily is add just enough new syntax that
people can write their own such system. This is the optional ":
<expr>" after parameter names and "-> <expr>" after a function
heading.

The rest is just an exercise in attempting to come up with a pragmatic
set of operators and conventions that some people might be using for
talking about types. This is the idea of parameterizing types a la
dict[str, int|str] (which I should point out is valid *syntax* today
and can be made to execute correctly by modest additions to the type
metaclass) and solving various other issues pragmatically, e.g.
lambda:A for forward references and Funct(int, list[int]).returns(int)
to describe signatures.

> What's the general opinion on systems which attempt to infer and predict
> inappropriate type usage? (Which I'm guessing is the main motivation here,
> rather than performance, which if I recall correctly, was downplayed in the
> context of "optional" type declarations.) By "predict", I mean something that
> operates before run-time; not something which tells you 100ns before an
> exception is raised. Couldn't such systems be a better aid to program
> reliability? Would "optional" type declarations be relevant to the operation
> of such systems?

I expect that something like pychecker could be taught enough about a
set of conventions to be useful. I don't expect that it will make all
bugs apparent at compile time, but pragmatically, it should be able to
do very well (much better than today's pychecker).

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

From guido at python.org  Fri May 19 19:10:18 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 10:10:18 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
Message-ID: <ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> > On 5/18/06, Kay Schluehr <kay.schluehr at gmx.net> wrote:
> > > I have a question to the audience. How do you represent higher order
> > > functions using this syntax?
> >
> > I think Collin and I both (independently) proposed the pragmatic
> > Function(<type>, <type>, ..., returns=<type>) for this.
>
> Based on a suggestion from Nick Coghlan [1], I'm now favoring
> something like this:
>
> Function(<type>, <type>, required_keyword=<type>, ...).returns(<type>)

I do like the Function().returns(int) notation but would like to push
back on keywords.

> The idea would be that you can use keyword arguments to Function to
> assert that the passed-in function object supports being called with
> certain keyword arguments.
> That is, if you were planning to call a passed-in function like so:
>
> func(5, 6, abc=7)
>
> you'd want to assert that func actually has a parameter named 'abc'.
> The corresponding Function would be Function(Number, Number,
> abc=Number).
>
> Using a 'returns' keyword argument to Function would effectively
> prohibit you from making sure that a function has a parameter named
> 'returns'. Hence, the returns() method.

(Not a big loss unless you wanted to talk about the signature of
Function itself. :-)

> As I mentioned [2], you can play around with this model using the
> trunk/ version of typecheck [3] (with docs for Function() [4]). This
> is by no means set in stone, so comment away. The main point I'm not
> entirely happy with: the use of star() and double_star() methods to
> indicate types for *vargs and **kwargs, respectively.
>
> If you like this general approach to handling Function(), I'll sketch
> out a version of Generator along the same lines.

I think it's overkill and still not enough. When I write "def foo(a,
b=2): ..." all of the following call signatures are valid: foo(1),
foo(a=1), foo(1, 2), foo(1, b=2), foo(a=1, b=2), foo(b=2, a=1). Do we
really want a notation that lets us describe that?

I would like to push back and *only* support fixed-number positional
parameters and a return value for signature declarations.

Think about it: when's the last time you had a callback parameter that
was called with keyword arguments?

Keyword arguments, varargs, etc. are nice when calling specific known
functions/methods. But I'm not sure that they are all that interesting
when coding higher-order functions.

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

From collinw at gmail.com  Fri May 19 19:56:39 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 13:56:39 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <ca471dc20605190948g75df8e5s108319032662e9a8@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	<ca471dc20605190948g75df8e5s108319032662e9a8@mail.gmail.com>
Message-ID: <43aa6ff70605191056y451e6b60h1814a1e17516f3a3@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> It feels a little too general for my taste. Have you written a bunch
> of those __parameterize__ functions yet?

Some, yes:

1. There's an example of a typecheck-able binary tree in typecheck's
tests/test_examples [1] that supports parameterization.

2. Though they might not be a great idea, I've implemented patterned
lists as a proof-of-concept before. It will ship with the next version
of typecheck as an example.

> I somehow feel that the metaclass might want to work a little harder so that the
> parameterizable class only has to specify what's unique to it. For
> example (not sure this is the right API) I could imagine that a
> parameterizable class should only have to do the following:
>
>   class List(list):
>       __metaclass__ = ParameterizableClass
>       __parameters__ = ["T"]
>
> List[X] would then return a new class C for which C.T is X.

[snip]

> I think this may be odd enough that subclassing the metaclass would be
> more appropriate.

[snip]

> But we need code before we can continue this discussion; I
> don't immediately how you get from this argument to making each class
> implement its own __parameterize__() method.

I don't want each class to implement its own __parameterize__()
method. To me, the easiest thing to do would be easier to have the
built-in types inherit a __parameterize__() method that handles a
common behaviour (like what you've laid out). User-defined classes
would then override it as they saw fit.

Under your suggestion, users would have to subclass the appropriate
metaclass, override some portion of the metaclass's behaviour, then
link their annotation classes to this new metaclass. This seems like a
lot of extra work.

[pauses, thinks about this for an hour or so]

However, you've managed to somewhat derail my conviction that this
extra work would be an overly-taxing burden. The main use I see for
overriding __parameterize__() is to validate the parameters, which I'm
having trouble finding useful use cases for. Every example I come up
with -- including the two at the top of this post -- can be reduced to
your <type>.T idea.

I'm going to do a branch of typecheck to play around with this
parameterization syntax; I'll let you know how it goes.

Collin Winter

[1] - http://tinyurl.com/n2v3b

From qrczak at knm.org.pl  Fri May 19 20:18:58 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Fri, 19 May 2006 20:18:58 +0200
Subject: [Python-3000] Type parameterization
In-Reply-To: <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	(Collin Winter's message of "Fri, 19 May 2006 11:37:55 -0400")
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
Message-ID: <87odxtg9nx.fsf@qrnik.zagroda>

"Collin Winter" <collinw at gmail.com> writes:

> 2. Similarly, annotation classes might want to do more complex
> parameter validation. Or(), for instance, might want to assert that it
> needs at least two distinct parameters (that is, Or(int, int, int)
> simplifies to Or(int), which makes no sense and is an error).

It does make sense. Or(int) denotes the same set of values as int.

You could as well complain that x+0 makes no sense and a language
should refuse to compute it, asking the programmer to use x instead.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From collinw at gmail.com  Fri May 19 20:38:23 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 14:38:23 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
Message-ID: <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> I think it's overkill and still not enough. When I write "def foo(a,
> b=2): ..." all of the following call signatures are valid: foo(1),
> foo(a=1), foo(1, 2), foo(1, b=2), foo(a=1, b=2), foo(b=2, a=1). Do we
> really want a notation that lets us describe that?
>
> I would like to push back and *only* support fixed-number positional
> parameters and a return value for signature declarations.
>
> Think about it: when's the last time you had a callback parameter that
> was called with keyword arguments?
>
> Keyword arguments, varargs, etc. are nice when calling specific known
> functions/methods. But I'm not sure that they are all that interesting
> when coding higher-order functions.

I'll concede that callbacks aren't often invoked in the foo(4, 5, c=7)
style (so requiring certain parameter names is off the table), but
I'll in turn push back on varargs and varkw parameters.

I see these as being genuinely useful in higher-order functions,
especially functions that take a variable-length constructor (like
list, dict, etc). Since we're no longer using Function()'s keyword
arguments to make assertions about parameter names, we can eliminate
the ugliness of star() and double_star() by having *varargs and
**varkw parameters grab their types from keyword arguments. That is,

def foo(a: Sequence, b: Number, *varargs: Number, **varkw: Number)

would be approved by

Function(Sequence, Number, varargs=Number, varkw=Number)

The excess argument parameters would be the only ones addressable with
keyword arguments (vargs and kwargs or varargs and varkw, makes no
difference to me). These arguments would have to be passed as
keywords, thus making explicit your intention to use excess positional
and/or keyword arguments.

Collin Winter

From collinw at gmail.com  Fri May 19 20:45:46 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 14:45:46 -0400
Subject: [Python-3000] Type parameterization
In-Reply-To: <87odxtg9nx.fsf@qrnik.zagroda>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	<87odxtg9nx.fsf@qrnik.zagroda>
Message-ID: <43aa6ff70605191145s677f8affka96a792115cd8e9d@mail.gmail.com>

On 5/19/06, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> "Collin Winter" <collinw at gmail.com> writes:
> > 2. Similarly, annotation classes might want to do more complex
> > parameter validation. Or(), for instance, might want to assert that it
> > needs at least two distinct parameters (that is, Or(int, int, int)
> > simplifies to Or(int), which makes no sense and is an error).
>
> It does make sense. Or(int) denotes the same set of values as int.
>
> You could as well complain that x+0 makes no sense and a language
> should refuse to compute it, asking the programmer to use x instead.

I have yet to see a case where the type of a function wasn't specified
by the user writing it out by hand. Given this, it's highly unlikely
that the user intentionally wrote Or(int) instead of int; they've
accidentally left out a type somewhere, and it should be brought to
their attention.

Since Python 3000 will support things like "ClassA | ClassB", would
you claim that "ClassA |" isn't an error (albeit a syntax error
instead of a call error)?

Collin Winter

From jimjjewett at gmail.com  Fri May 19 21:06:38 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 19 May 2006 15:06:38 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605190958i359f4926md28d6a7cf4d8c63@mail.gmail.com>
References: <200605191814.33021.paul@boddie.org.uk>
	<ca471dc20605190958i359f4926md28d6a7cf4d8c63@mail.gmail.com>
Message-ID: <fb6fbf560605191206w3ab5122el5c95216eb3a273b5@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:

> The rest is just an exercise in attempting to come up with a pragmatic
> set of operators and conventions that some people might be using for
> talking about types. This is the idea of parameterizing types a la
> dict[str, int|str] (which I should point out is valid *syntax* today
> and can be made to execute correctly by modest additions to the type
> metaclass) and solving various other issues pragmatically, e.g.
> lambda:A for forward references and Funct(int, list[int]).returns(int)
> to describe signatures.

Today, int|str raises a TypeError.

If I didn't already know what you wanted, I would sort of expect it to
be the same as (int or str) which isn't helpful.

It sounds like what you want is that type.__or__ would magically
include the equivalent of not fully reducing the expression.  For
example, it might return a new instance of class TypeChecker with a
__call__ method that checks isinstance against each argument, unless
one argument is itself another TypeChecker instance, in which case it
would call that checker instead of doing an isinstance ...

I think trying to put compound types directly into the signature may
require a little too much magic, compared to either:

(1)  Just use a tuple, and put the smarts in your decorator if you
need to actually do something with the information.

    @decorator_which_handles_tuples
    def f(a: (int, str)):

or

(2)  Defining the complex predicate before using it

    def int_or_str(arg):
        return isinstance(arg, int) or isinstance(arg, str)

    def f(a:int_or_str)

-jJ

From collinw at gmail.com  Fri May 19 21:17:03 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 15:17:03 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <fb6fbf560605191206w3ab5122el5c95216eb3a273b5@mail.gmail.com>
References: <200605191814.33021.paul@boddie.org.uk>
	<ca471dc20605190958i359f4926md28d6a7cf4d8c63@mail.gmail.com>
	<fb6fbf560605191206w3ab5122el5c95216eb3a273b5@mail.gmail.com>
Message-ID: <43aa6ff70605191217q1b228a35gb28a52c3d576dfc3@mail.gmail.com>

On 5/19/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> > The rest is just an exercise in attempting to come up with a pragmatic
> > set of operators and conventions that some people might be using for
> > talking about types. This is the idea of parameterizing types a la
> > dict[str, int|str] (which I should point out is valid *syntax* today
> > and can be made to execute correctly by modest additions to the type
> > metaclass) and solving various other issues pragmatically, e.g.
> > lambda:A for forward references and Funct(int, list[int]).returns(int)
> > to describe signatures.
>
> Today, int|str raises a TypeError.

He said it's valid *syntax*, not that it's valid semantics.

> If I didn't already know what you wanted, I would sort of expect it to
> be the same as (int or str) which isn't helpful.
>
> It sounds like what you want is that type.__or__ would magically
> include the equivalent of not fully reducing the expression.  For
> example, it might return a new instance of class TypeChecker with a
> __call__ method that checks isinstance against each argument, unless
> one argument is itself another TypeChecker instance, in which case it
> would call that checker instead of doing an isinstance ...

That's pretty much the idea, yes.

> I think trying to put compound types directly into the signature may
> require a little too much magic, compared to either:
>
> (1)  Just use a tuple, and put the smarts in your decorator if you
> need to actually do something with the information.
>
>     @decorator_which_handles_tuples
>     def f(a: (int, str)):

How do you differentiate between this and wanting to assert that 'a'
is a 2-tuple with a first element of type int and a second element of
type str?

> (2)  Defining the complex predicate before using it
>
>     def int_or_str(arg):
>         return isinstance(arg, int) or isinstance(arg, str)
>
>     def f(a:int_or_str)

My own description of that would run toward "hideously complex predicate".

Collin Winter

From qrczak at knm.org.pl  Fri May 19 21:19:23 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Fri, 19 May 2006 21:19:23 +0200
Subject: [Python-3000] Type parameterization
In-Reply-To: <43aa6ff70605191145s677f8affka96a792115cd8e9d@mail.gmail.com>
	(Collin Winter's message of "Fri, 19 May 2006 14:45:46 -0400")
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	<87odxtg9nx.fsf@qrnik.zagroda>
	<43aa6ff70605191145s677f8affka96a792115cd8e9d@mail.gmail.com>
Message-ID: <87k68hg6v8.fsf@qrnik.zagroda>

"Collin Winter" <collinw at gmail.com> writes:

> Since Python 3000 will support things like "ClassA | ClassB", would
> you claim that "ClassA |" isn't an error (albeit a syntax error
> instead of a call error)?

It's a syntax error of course. But ClassA|ClassA is not an error.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From jimjjewett at gmail.com  Fri May 19 21:27:33 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 19 May 2006 15:27:33 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
Message-ID: <fb6fbf560605191227l1527c735p71029d6822055b50@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:

> I think it's overkill and still not enough. When I write "def foo(a,
> b=2): ..." all of the following call signatures are valid: foo(1),
> foo(a=1), foo(1, 2), foo(1, b=2), foo(a=1, b=2), foo(b=2, a=1). Do we
> really want a notation that lets us describe that?

We have one:

    def foo(a, b=2)

The signature of the function should describe it properly.

So the real question is how best to write "A callable with this
signature".  I do not think the right answer is an inline recreation.
Compare to

    from inspect import signature as sig

    def button_pushed(button,
                      pressure=1,
                      alarm=False,
                      repeated=False, ...

    # Give the signature a name, with ButtonFunc=sig(button_pushed) ?  nah...

    def foo(self, action:sig(button_pushed)): ...

And the decorator (if any) knows whether to enforce that the callback
have the right name, or to ignore even the count of arguments.

> Think about it: when's the last time you had a callback parameter that
> was called with keyword arguments?

It may be reasonable to require that the callback accept a keyword
such as 'color', rather than requiring it to take all possible GUI
parameters in a specific order.

-jJ

From tony at printra.net  Fri May 19 21:31:25 2006
From: tony at printra.net (Tony Lownds)
Date: Fri, 19 May 2006 12:31:25 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <200605191814.33021.paul@boddie.org.uk>
References: <200605191814.33021.paul@boddie.org.uk>
Message-ID: <81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net>


On May 19, 2006, at 9:14 AM, Paul Boddie wrote:

> Guido van Rossum wrote:
>>
>> I'm not convinced that we need all this for the likely intended use,
>> since static type checking isn't really high on the agenda anyway.
>
> I know I'll get into trouble for quoting this out of context, and I  
> accept
> that there's a difference between static typing and writing  
> declarations that
> look like static type declarations but which operate at run-time.  
> However, I
> keep wondering whether we're missing out on something by adopting a  
> type
> description language that will either prove to be inadequately  
> expressive or
> evolve to something on the level of a full programming language in  
> its own
> right.
>
> What's the general opinion on systems which attempt to infer and  
> predict
> inappropriate type usage? (Which I'm guessing is the main  
> motivation here,
> rather than performance, which if I recall correctly, was  
> downplayed in the
> context of "optional" type declarations.) By "predict", I mean  
> something that
> operates before run-time; not something which tells you 100ns  
> before an
> exception is raised. Couldn't such systems be a better aid to program
> reliability? Would "optional" type declarations be relevant to the  
> operation
> of such systems?

I've been hacking on such a system, called "t_types". It is in pre- 
release form right now.
It actually deduces type usage using bytecode simulation, before run- 
time.

For t_types, starting the simulation with types more specific than  
"anything" is important
for reasonable results. In general I think optional type declarations  
are relevant to such
systems, whether a special syntax is adopted or decorators are used.

The proposals I've seen here for type annotation syntax seem very  
intentionally
designed NOT to lock in any particular type system. So far nothing  
seems to preclude
static type checking, at least the way t_types works. I hope the type  
annotation syntax
for functions goes in, it's a lot more readable than decorators.

Here's an idea of the flavor of type checking t_types gives.

from t_types import t

@t.signature(t.int|t.None, returns=t.int)
def test43(foo=None):
   if None is 1:
     # should be dead code
     return ''
   if 1 is None:
     # should be dead code
     return ''
   if foo is None:
     return 1
   else:
     # foo should have type of t.int here
     return foo

@t.signature(returns=t.list[t.int])
def test26():
   x = []
   x[0] = 1
   return x


Question for Guido/Collin:

Out of curiosity, are there concrete plans for how the type  
annotation syntax for functions
translates into bytecode?

Thanks
-Tony



From jimjjewett at gmail.com  Fri May 19 21:54:44 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 19 May 2006 15:54:44 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
Message-ID: <fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> ... what do you think of ... having bracket-based parameterization be
> redirected a call to some double-underscore method

It already is -- to __getitem__.

Having it go to something else just because you're in a function
definition is asking for trouble.  What should happen in the following
case?

    b=dict(strict=check1, lenient=check2, normal=check3)

    def foo(a:b["normal"]): pass

Should it really look for some special method on b (or b's type) just
because it is in a signature context?  Today, the annotation
expression would evaluate to check2, and I'm not looking forward to
figuring out all the corner cases on when that wouldn't happen.

-jJ

From collinw at gmail.com  Fri May 19 22:04:09 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 16:04:09 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	<fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>
Message-ID: <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com>

On 5/19/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> > ... what do you think of ... having bracket-based parameterization be
> > redirected a call to some double-underscore method
>
> It already is -- to __getitem__.
>
> Having it go to something else just because you're in a function
> definition is asking for trouble.  What should happen in the following
> case?
>
>     b=dict(strict=check1, lenient=check2, normal=check3)
>
>     def foo(a:b["normal"]): pass
>
> Should it really look for some special method on b (or b's type) just
> because it is in a signature context?  Today, the annotation
> expression would evaluate to check2, and I'm not looking forward to
> figuring out all the corner cases on when that wouldn't happen.

dict(normal=check3)["normal"] is not the same as dict["normal"] --
Guido and I have been discussing the latter. When I said "redirected",
I meant that dict's metaclass would catch the __getitem__ call and
then invoke dict.__parameterize__() appropriately.

Collin Winter

From jimjjewett at gmail.com  Fri May 19 22:28:37 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 19 May 2006 16:28:37 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605191217q1b228a35gb28a52c3d576dfc3@mail.gmail.com>
References: <200605191814.33021.paul@boddie.org.uk>
	<ca471dc20605190958i359f4926md28d6a7cf4d8c63@mail.gmail.com>
	<fb6fbf560605191206w3ab5122el5c95216eb3a273b5@mail.gmail.com>
	<43aa6ff70605191217q1b228a35gb28a52c3d576dfc3@mail.gmail.com>
Message-ID: <fb6fbf560605191328i37fde1e2ic6f06f9a8c3b439@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/19/06, Jim Jewett <jimjjewett at gmail.com> wrote:

> > I think trying to put compound types directly into the signature may
> > require a little too much magic, compared to either:

> > (1)  Just use a tuple, and put the smarts in your decorator if you
> > need to actually do something with the information.

> >     @decorator_which_handles_tuples
> >     def f(a: (int, str)):

> How do you differentiate between this and wanting to assert that 'a'
> is a 2-tuple with a first element of type int and a second element of
> type str?

The decorator knows.  The human only knows by convention.  (But that's
true anyhow; a sneaky decorator could replace the entire function with
something having an unrelated signature.)

I expect that there would be other decorators using a tuple to say
"must meet all", rather than "must meet at least one".

>From my perspective, I figure ~80% of code won't even have annotations.
~80% of the rest won't need to combine them.
The "any" and "all" cases still only cover ~80% of the remainder .
(~3% of code)

That isn't enough to justify a special case.

I would expect more value (but still perhaps not enough) from
special-casing any of the following:

    annotation represents the (concrete) type
        arg:annotation <==> isinstance(arg, annotation)

    annotation represents a predicate (such as "implements this interface")
        arg:annotation <==> bool(annotation(arg)) is True

    annotation represents an adapter ("*make* it implement this interface")
        arg:annotation  ==> [wrapper replaces arg with] annotation(arg)


-jJ

From guido at python.org  Fri May 19 22:33:59 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 13:33:59 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
Message-ID: <ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> I'll concede that callbacks aren't often invoked in the foo(4, 5, c=7)
> style (so requiring certain parameter names is off the table), but
> I'll in turn push back on varargs and varkw parameters.
>
> I see these as being genuinely useful in higher-order functions,
> especially functions that take a variable-length constructor (like
> list, dict, etc).

I'm unconvinced. Can you provide an example of where this would be
useful? I'm not looking for an example showing how it works; I want to
see an example showing why we need this functionality.

> Since we're no longer using Function()'s keyword
> arguments to make assertions about parameter names, we can eliminate
> the ugliness of star() and double_star() by having *varargs and
> **varkw parameters grab their types from keyword arguments. That is,
>
> def foo(a: Sequence, b: Number, *varargs: Number, **varkw: Number)
>
> would be approved by
>
> Function(Sequence, Number, varargs=Number, varkw=Number)

Maybe. But then I think we also should use this style to add
returns=Number instead of Function().returns(Number).

> The excess argument parameters would be the only ones addressable with
> keyword arguments (vargs and kwargs or varargs and varkw, makes no
> difference to me). These arguments would have to be passed as
> keywords, thus making explicit your intention to use excess positional
> and/or keyword arguments.

Show me the motivating example.

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

From jimjjewett at gmail.com  Fri May 19 22:46:31 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 19 May 2006 16:46:31 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	<fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>
	<43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com>
Message-ID: <fb6fbf560605191346k75a0dce2wda1b674ab8c0afa8@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/19/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> > On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> > > ... what do you think of ... having bracket-based parameterization be
> > > redirected a call to some double-underscore method

> > It already is -- to __getitem__.
> >
> > Having it go to something else just because you're in a function
> > definition is asking for trouble.  What should happen in the following
> > case?

> >     b=dict(strict=check1, lenient=check2, normal=check3)

> >     def foo(a:b["normal"]): pass

> > Should it really look for some special method on b (or b's type) just
> > because it is in a signature context?  Today, the annotation
> > expression would evaluate to check2, and I'm not looking forward to
> > figuring out all the corner cases on when that wouldn't happen.

> dict(normal=check3)["normal"] is not the same as dict["normal"] --

Yes, they are.  They both call __getitem__.

__getitem__ on a dictionary instance happens to be defined.
__getitem__ on the dict class happens not to be defined.

> Guido and I have been discussing the latter. When I said "redirected",
> I meant that dict's metaclass would catch the __getitem__ call and
> then invoke dict.__parameterize__() appropriately.

I interpreted your suggestion as saying type annotations should be
treated that way.

Now it sounds like you are saying that a few specific classes (such as
dict) should be given a custom metaclass, and start to behave this way
in all situations, not just signature context.  User defined classes
would need to explicitly request the same behavior.

I still think it has too many corner cases, both mentally and from an
implementation standpoint.

    class P:
        def __parameterize__(self, T):

Is P()[x] the same as P().__parameterize__(x)?  Then why not just call
it __getitem__?

    class B:
        def __getitem__(self, k): return 42
        def __parameterize__(self, T): pass

Since __getitem__ exists and does not delegate, is there any way that
B.__parameterize__ will ever be called just by using brackets?  If so,
then when?  If not, what good is it?

-jJ

From guido at python.org  Fri May 19 22:46:52 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 13:46:52 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <fb6fbf560605191227l1527c735p71029d6822055b50@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<fb6fbf560605191227l1527c735p71029d6822055b50@mail.gmail.com>
Message-ID: <ca471dc20605191346p7a4ac975oce18f82d81c80da3@mail.gmail.com>

On 5/19/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> So the real question is how best to write "A callable with this
> signature".  I do not think the right answer is an inline recreation.
> Compare to
>
>     from inspect import signature as sig
>
>     def button_pushed(button,
>                       pressure=1,
>                       alarm=False,
>                       repeated=False, ...
>
>     # Give the signature a name, with ButtonFunc=sig(button_pushed) ?  nah...
>
>     def foo(self, action:sig(button_pushed)): ...

I like this idea. Maybe it could be called like() or Like(). (And it
still lets you inline if you really want: just put a lambda in there.
:-) Having this for the complex cases would make it possible to
simplify Function() to the bare minimum: fixed positional args and
returns=xyzzy.

> > Think about it: when's the last time you had a callback parameter that
> > was called with keyword arguments?
>
> It may be reasonable to require that the callback accept a keyword
> such as 'color', rather than requiring it to take all possible GUI
> parameters in a specific order.

May be. But somehow I don't see a big use case for a callback being
called with all possible keyword arguments. It's more likely that
you'd pass a single object containing all the UI parameterizations.

As I urged Collin before, can someone please come up with a realistic
motivating example? If there aren't any I will put my foot down and
call YAGNI on any mechanism to specify signatures with keyword
arguments, *args, or **kwds.

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

From collinw at gmail.com  Fri May 19 22:50:19 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 16:50:19 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <fb6fbf560605191328i37fde1e2ic6f06f9a8c3b439@mail.gmail.com>
References: <200605191814.33021.paul@boddie.org.uk>
	<ca471dc20605190958i359f4926md28d6a7cf4d8c63@mail.gmail.com>
	<fb6fbf560605191206w3ab5122el5c95216eb3a273b5@mail.gmail.com>
	<43aa6ff70605191217q1b228a35gb28a52c3d576dfc3@mail.gmail.com>
	<fb6fbf560605191328i37fde1e2ic6f06f9a8c3b439@mail.gmail.com>
Message-ID: <43aa6ff70605191350h36dacda7n6cfc585c344209cc@mail.gmail.com>

On 5/19/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> > On 5/19/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> > > (1)  Just use a tuple, and put the smarts in your decorator if you
> > > need to actually do something with the information.
>
> > >     @decorator_which_handles_tuples
> > >     def f(a: (int, str)):
>
> > How do you differentiate between this and wanting to assert that 'a'
> > is a 2-tuple with a first element of type int and a second element of
> > type str?
>
> The decorator knows.  The human only knows by convention.  (But that's
> true anyhow; a sneaky decorator could replace the entire function with
> something having an unrelated signature.)
>
> I expect that there would be other decorators using a tuple to say
> "must meet all", rather than "must meet at least one".

And what if I want to use several decorators at the same time, all of
which stake a claim to tuples?

Collin Winter

From collinw at gmail.com  Fri May 19 22:51:16 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 16:51:16 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net>
References: <200605191814.33021.paul@boddie.org.uk>
	<81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net>
Message-ID: <43aa6ff70605191351l45d76183heefdf5357d9eb12f@mail.gmail.com>

On 5/19/06, Tony Lownds <tony at printra.net> wrote:
> I've been hacking on such a system, called "t_types". It is in pre-
> release form right now.
> It actually deduces type usage using bytecode simulation, before run-
> time.

What do you mean by "bytecode simulation" and "before runtime"?

Also, is there somewhere to read about/download this system?

> Question for Guido/Collin:
>
> Out of curiosity, are there concrete plans for how the type
> annotation syntax for functions
> translates into bytecode?

For my part, I've never imagined that any of the type system would
translate into bytecode. I believe one of Guido's blog posts mentions
that the type information will be available from the callable's
__signature__ attribute.

Collin Winter

From guido at python.org  Fri May 19 22:52:08 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 13:52:08 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net>
References: <200605191814.33021.paul@boddie.org.uk>
	<81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net>
Message-ID: <ca471dc20605191352l6dbe67ecv1f473b9f9dfdc39b@mail.gmail.com>

On 5/19/06, Tony Lownds <tony at printra.net> wrote:
> The proposals I've seen here for type annotation syntax seem very intentionally
> designed NOT to lock in any particular type system.

Right.

> So far nothing seems to preclude
> static type checking, at least the way t_types works. I hope the type annotation syntax
> for functions goes in, it's a lot more readable than decorators.
>
> Here's an idea of the flavor of type checking t_types gives.
> [snipped]

This looks good, it would be able to make good use of the proposed
syntax, and the notation you use isn't too different from what Collin
is proposing either (e.g. int|None, list[int]).

> Question for Guido/Collin:
>
> Out of curiosity, are there concrete plans for how the type
> annotation syntax for functions
> translates into bytecode?

I suspect rather similar to the way default parameter values are
handled today: we generate bytecode that evaluates the type
annotations and somehow saves them on the signature object which is
part of the function object.

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

From collinw at gmail.com  Fri May 19 23:08:25 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 17:08:25 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <fb6fbf560605191346k75a0dce2wda1b674ab8c0afa8@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	<fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>
	<43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com>
	<fb6fbf560605191346k75a0dce2wda1b674ab8c0afa8@mail.gmail.com>
Message-ID: <43aa6ff70605191408n274b7b37u6cc9ddea67106d16@mail.gmail.com>

On 5/19/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> > dict(normal=check3)["normal"] is not the same as dict["normal"] --
>
> Yes, they are.  They both call __getitem__.
>
> __getitem__ on a dictionary instance happens to be defined.
> __getitem__ on the dict class happens not to be defined.

dict(normal=check3)["normal"] invokes dict.__getitem__().
dict["normal"] invokes type.__getitem__().

That's why they're not the same.

> > Guido and I have been discussing the latter. When I said "redirected",
> > I meant that dict's metaclass would catch the __getitem__ call and
> > then invoke dict.__parameterize__() appropriately.
>
> I interpreted your suggestion as saying type annotations should be
> treated that way.
>
> Now it sounds like you are saying that a few specific classes (such as
> dict) should be given a custom metaclass, and start to behave this way
> in all situations, not just signature context.  User defined classes
> would need to explicitly request the same behavior.

I would imagine that __getitem__ would be defined on type, meaning
that all classes, user-defined and built-in, have this behaviour
automatically.

> I still think it has too many corner cases, both mentally and from an
> implementation standpoint.
>
>     class P:
>         def __parameterize__(self, T):
>
> Is P()[x] the same as P().__parameterize__(x)?  Then why not just call
> it __getitem__?

They are not the same: P()[x] would invoke P.__getitem__(), not
type.__getitem__().

>     class B:
>         def __getitem__(self, k): return 42
>         def __parameterize__(self, T): pass
>
> Since __getitem__ exists and does not delegate, is there any way that
> B.__parameterize__ will ever be called just by using brackets?  If so,
> then when?  If not, what good is it?

B.__parameterize__ will only be called in the case of B[x] (as opposed
to B()[x]).

Collin Winter

From collinw at gmail.com  Fri May 19 23:09:42 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 17:09:42 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
Message-ID: <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> > Use of positional arguments to parameterize dict, e.g., dict[str,
> > Number], is ugly, but keyword arguments would allow the prettier
> > dict[key=str, value=Number] (which might also be another use case for
> > the proposed keyword-only arguments).
>
> Maybe you didn't find all blog posts, or maybe I really didn't mention
> it, but I personally prefer dict[str, Number]. There really can't be
> much confusion over what these mean for anyone who knows what a dict
> is.

As a quick data point, I showed around your "dict[str, str|int]"
example to some friends, all of whom have done a decent amount of
coding in Python. I gave them some background, including that this was
an example of type parameterization. To quote one fellow, a PhD
student in CS at Edinburgh: "So, uh, 'dict[str, int|str]' is supposed
to represent... uh... I give in, what the hell is that supposed to
denote?"

I know the plural of "anecdote" isn't "data"; maybe c.l.p should be
polled on some of these things?

Collin Winter

From collinw at gmail.com  Fri May 19 23:14:29 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 17:14:29 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
Message-ID: <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> I'm unconvinced. Can you provide an example of where this would be
> useful? I'm not looking for an example showing how it works; I want to
> see an example showing why we need this functionality.

Honestly, I don't have one.

Let's go back to Function(<type>, <type>, ..., returns=<type>) for
now. I'll change my own implementation of Function() to match this,
and if people start hollering at me after the next release of
typecheck, wanting vargs, kwargs and/or keyword argument support, then
we can reconsider it for Python's own version.

Collin Winter

From jimjjewett at gmail.com  Fri May 19 23:24:09 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 19 May 2006 17:24:09 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605191408n274b7b37u6cc9ddea67106d16@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	<fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>
	<43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com>
	<fb6fbf560605191346k75a0dce2wda1b674ab8c0afa8@mail.gmail.com>
	<43aa6ff70605191408n274b7b37u6cc9ddea67106d16@mail.gmail.com>
Message-ID: <fb6fbf560605191424j5f79b0f2xfa08f9ac5fd35a3a@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> B.__parameterize__ will only be called in the case of B[x] (as opposed
> to B()[x]).

new-style classes (the ones sticking around for python 3) are also instances.

    >>> isinstance(dict, type) and isinstance(dict, object)
    True

How can the interpreter know which interpretation to use?

When proposing a rule, remember to consider classes which are supposed
to have only a single instance (similar to a JSP).  Even if you
normally separate classes from instances, the line between "class" and
"the only instance of the class" can get kind of blurry.

-jJ

From tony at printra.net  Fri May 19 23:31:09 2006
From: tony at printra.net (Tony Lownds)
Date: Fri, 19 May 2006 14:31:09 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605191351l45d76183heefdf5357d9eb12f@mail.gmail.com>
References: <200605191814.33021.paul@boddie.org.uk>
	<81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net>
	<43aa6ff70605191351l45d76183heefdf5357d9eb12f@mail.gmail.com>
Message-ID: <7973AE7A-B48C-47C5-9AB6-F1CA742B3919@printra.net>


On May 19, 2006, at 1:51 PM, Collin Winter wrote:

> On 5/19/06, Tony Lownds <tony at printra.net> wrote:
>> I've been hacking on such a system, called "t_types". It is in pre-
>> release form right now.
>> It actually deduces type usage using bytecode simulation, before run-
>> time.
>
> What do you mean by "bytecode simulation" and "before runtime"?
>

Before runtime means that t_types does static type checking. Like  
Pychecker, it should be
used during development.

t_types operates on bytecode, not source or AST, and has it's own  
loop, and stack to simulate the types
that would occur when Python executes the bytecode. Hopefully that  
makes sense. The upshot is that
if type annotations don't make it to bytecode, t_types is screwed :)

> Also, is there somewhere to read about/download this system?
>

No, not yet. It has a long way to go before even moderately complex  
programs
can be checked. I'll post it before too long or contact me off-list.

-Tony



From guido at python.org  Fri May 19 23:38:02 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 14:38:02 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
Message-ID: <ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> > On 5/18/06, Collin Winter <collinw at gmail.com> wrote:
> > > Use of positional arguments to parameterize dict, e.g., dict[str,
> > > Number], is ugly, but keyword arguments would allow the prettier
> > > dict[key=str, value=Number] (which might also be another use case for
> > > the proposed keyword-only arguments).
> >
> > Maybe you didn't find all blog posts, or maybe I really didn't mention
> > it, but I personally prefer dict[str, Number]. There really can't be
> > much confusion over what these mean for anyone who knows what a dict
> > is.
>
> As a quick data point, I showed around your "dict[str, str|int]"
> example to some friends, all of whom have done a decent amount of
> coding in Python. I gave them some background, including that this was
> an example of type parameterization. To quote one fellow, a PhD
> student in CS at Edinburgh: "So, uh, 'dict[str, int|str]' is supposed
> to represent... uh... I give in, what the hell is that supposed to
> denote?"
>
> I know the plural of "anecdote" isn't "data"; maybe c.l.p should be
> polled on some of these things?

Did you first show them list[int] (to get them used to the idea of
parameterized types) and then dict[str, int] (since the int|str union
could be a distractor)?

IMO it's more important whether they are able to recall what it's
supposed to mean after you've explained it once or shown them an
example, than that they be able to guess what it means without
introduction.

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

From tony at printra.net  Fri May 19 23:42:05 2006
From: tony at printra.net (Tony Lownds)
Date: Fri, 19 May 2006 14:42:05 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605191352l6dbe67ecv1f473b9f9dfdc39b@mail.gmail.com>
References: <200605191814.33021.paul@boddie.org.uk>
	<81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net>
	<ca471dc20605191352l6dbe67ecv1f473b9f9dfdc39b@mail.gmail.com>
Message-ID: <F6AA4219-2085-4307-B5C9-01CFF653E3D0@printra.net>


On May 19, 2006, at 1:52 PM, Guido van Rossum wrote:
>> Out of curiosity, are there concrete plans for how the type
>> annotation syntax for functions
>> translates into bytecode?
>
> I suspect rather similar to the way default parameter values are
> handled today: we generate bytecode that evaluates the type
> annotations and somehow saves them on the signature object which is
> part of the function object.

Ok. I'm also wondering whether order of evaluation will be  
constrained and
whether missing annotations result in a sentinel value or are just  
missing.

I'd propose that MAKE_FUNCTION's arg has a flag bit which indicates that
type annotations are present. If the flag is set, an integer value is  
popped off
the stack which is used as a bit array to determine how the default  
arguments
and type annotations are mixed.

My apologies if this is getting too far ahead of the process.

Thanks for listening
-Tony


From guido at python.org  Fri May 19 23:52:19 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 14:52:19 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <F6AA4219-2085-4307-B5C9-01CFF653E3D0@printra.net>
References: <200605191814.33021.paul@boddie.org.uk>
	<81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net>
	<ca471dc20605191352l6dbe67ecv1f473b9f9dfdc39b@mail.gmail.com>
	<F6AA4219-2085-4307-B5C9-01CFF653E3D0@printra.net>
Message-ID: <ca471dc20605191452r12e5c775o60c4159ecc7b6358@mail.gmail.com>

On 5/19/06, Tony Lownds <tony at printra.net> wrote:
>
> On May 19, 2006, at 1:52 PM, Guido van Rossum wrote:
> >> Out of curiosity, are there concrete plans for how the type
> >> annotation syntax for functions
> >> translates into bytecode?
> >
> > I suspect rather similar to the way default parameter values are
> > handled today: we generate bytecode that evaluates the type
> > annotations and somehow saves them on the signature object which is
> > part of the function object.
>
> Ok. I'm also wondering whether order of evaluation will be
> constrained and
> whether missing annotations result in a sentinel value or are just
> missing.
>
> I'd propose that MAKE_FUNCTION's arg has a flag bit which indicates that
> type annotations are present. If the flag is set, an integer value is
> popped off
> the stack which is used as a bit array to determine how the default
> arguments
> and type annotations are mixed.
>
> My apologies if this is getting too far ahead of the process.

I think you're ahead. Perhaps you could make some suggestions of what
you'd like instead of asking (leading?) questions.

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

From qrczak at knm.org.pl  Sat May 20 00:12:57 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sat, 20 May 2006 00:12:57 +0200
Subject: [Python-3000] Type parameterization
In-Reply-To: <fb6fbf560605191346k75a0dce2wda1b674ab8c0afa8@mail.gmail.com> (Jim
	Jewett's message of "Fri, 19 May 2006 16:46:31 -0400")
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	<fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>
	<43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com>
	<fb6fbf560605191346k75a0dce2wda1b674ab8c0afa8@mail.gmail.com>
Message-ID: <87psi9zms6.fsf@qrnik.zagroda>

"Jim Jewett" <jimjjewett at gmail.com> writes:

> __getitem__ on a dictionary instance happens to be defined.
> __getitem__ on the dict class happens not to be defined.

I wouldn't be so sure.

>>> dict.__getitem__
<method '__getitem__' of 'dict' objects>
>>> dict.__getitem__({'one':1}, 'one')
1

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From jimjjewett at gmail.com  Sat May 20 01:18:13 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 19 May 2006 19:18:13 -0400
Subject: [Python-3000] Type parameterization
In-Reply-To: <87psi9zms6.fsf@qrnik.zagroda>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>
	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>
	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>
	<fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>
	<43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com>
	<fb6fbf560605191346k75a0dce2wda1b674ab8c0afa8@mail.gmail.com>
	<87psi9zms6.fsf@qrnik.zagroda>
Message-ID: <fb6fbf560605191618x46deedabrb84a143c12b0aed4@mail.gmail.com>

On 5/19/06, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> "Jim Jewett" <jimjjewett at gmail.com> writes:
>
> > __getitem__ on a dictionary instance happens to be defined.
> > __getitem__ on the dict class happens not to be defined.
>
> I wouldn't be so sure.
>
> >>> dict.__getitem__
> <method '__getitem__' of 'dict' objects>
> >>> dict.__getitem__({'one':1}, 'one')
> 1

I should have been more precise.

On a dictionary instance, __getitem__ wil be found (in the definition
of the class dict)

On a type instance, such as dict itself, __getitem__ will not be found
(in the definition of the (meta)class type)

If the implementation of [] ends up doing the moral equivalent of

    (self.__getitem__(arg) if not isintance(self, type) else
self.__parameterization__(arg))

then we're running into problems with

    If the implementation is hard to explain, it's a bad idea.

-jJ

From collinw at gmail.com  Sat May 20 03:29:40 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 21:29:40 -0400
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
Message-ID: <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> > As a quick data point, I showed around your "dict[str, str|int]"
> > example to some friends, all of whom have done a decent amount of
> > coding in Python. I gave them some background, including that this was
> > an example of type parameterization. To quote one fellow, a PhD
> > student in CS at Edinburgh: "So, uh, 'dict[str, int|str]' is supposed
> > to represent... uh... I give in, what the hell is that supposed to
> > denote?"
>
> Did you first show them list[int] (to get them used to the idea of
> parameterized types) and then dict[str, int] (since the int|str union
> could be a distractor)?

I showed examples like list[str] and tuple[int, int], but I don't
think I included dict[str, int].

On the other hand, my suggestion of dict[key=str, val=int] didn't go
over well either; they liked the readability, but objected to the
extra typing imposed by "key=" and "val=".

> IMO it's more important whether they are able to recall what it's
> supposed to mean after you've explained it once or shown them an
> example, than that they be able to guess what it means without
> introduction.

I'll try asking again after a week or so.

Collin Winter

From collinw at gmail.com  Sat May 20 03:39:01 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 19 May 2006 21:39:01 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
Message-ID: <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> Let's go back to Function(<type>, <type>, ..., returns=<type>)

I just finished converting typecheck's test suite to use this
notation, and I have the following to report: ick.

The main problem is when the function returns a complex type:

>>> Function(int, int, returns=(int, int))
or:
>>> Function(returns=(int, int))

I find the latter even worse than the former.

I played around, switching it back and forth between the above and

>>> Function(int, int).returns(int, int)
and
>>> Function().returns(int, int)

Using the methods, though, does mean you might end up with something
like this when it comes to changing the Function()'s strictness:

>>> Function(int, int, int).returns(int, int).is_strict(True)

However, you can change the strictness settings for all Function()s
using the class-level Function.default_strict attribute; I imagine
most people wanting to change strictness will do so via the class, not
the individual instances. I expect the majority of usages to look
like:

>>> Function(<type>, <type>, <type>).returns(<type>, <type>)

...with which I am pleased muchly.

Collin Winter

From guido at python.org  Sat May 20 05:25:56 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 19 May 2006 20:25:56 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
Message-ID: <ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> > Let's go back to Function(<type>, <type>, ..., returns=<type>)
>
> I just finished converting typecheck's test suite to use this
> notation, and I have the following to report: ick.
>
> The main problem is when the function returns a complex type:
>
> >>> Function(int, int, returns=(int, int))
> or:
> >>> Function(returns=(int, int))
>
> I find the latter even worse than the former.
>
> I played around, switching it back and forth between the above and
>
> >>> Function(int, int).returns(int, int)
> and
> >>> Function().returns(int, int)
>
> Using the methods, though, does mean you might end up with something
> like this when it comes to changing the Function()'s strictness:
>
> >>> Function(int, int, int).returns(int, int).is_strict(True)
>
> However, you can change the strictness settings for all Function()s
> using the class-level Function.default_strict attribute; I imagine
> most people wanting to change strictness will do so via the class, not
> the individual instances. I expect the majority of usages to look
> like:
>
> >>> Function(<type>, <type>, <type>).returns(<type>, <type>)
>
> ...with which I am pleased muchly.

OK; for the return value (only) the Function().returns(<type>)
notation does look fairly pretty.

I presume that return(int, int) is the same as return((int, int))?

Weren't we going to write a tuple of two ints as tuple[int, int]
though? Is (int, int) now just an alias for that or does it have a
different meaing?

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

From talin at acm.org  Sat May 20 06:23:20 2006
From: talin at acm.org (Talin)
Date: Fri, 19 May 2006 21:23:20 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
 annotating generators)
In-Reply-To: <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
Message-ID: <446E99B8.10500@acm.org>

Collin Winter wrote:
> On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> 
>>On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
>>
>>>As a quick data point, I showed around your "dict[str, str|int]"
>>>example to some friends, all of whom have done a decent amount of
>>>coding in Python. I gave them some background, including that this was
>>>an example of type parameterization. To quote one fellow, a PhD
>>>student in CS at Edinburgh: "So, uh, 'dict[str, int|str]' is supposed
>>>to represent... uh... I give in, what the hell is that supposed to
>>>denote?"
>>
>>Did you first show them list[int] (to get them used to the idea of
>>parameterized types) and then dict[str, int] (since the int|str union
>>could be a distractor)?
> 
> 
> I showed examples like list[str] and tuple[int, int], but I don't
> think I included dict[str, int].

OK, try this on your friends and see what happens:

    dict[ str >> int ]

and similarly:

    Function( args ) >> int

In other words, I am overloading the right shift operator to mean "maps to".

Alternative suggestion: Define -> as an operator.

    def myfunc( a:dict[ int -> int ], b:Function( int ) -> int ) -> int:
       ...

In English, this means: "A function which takes two arguments, the first 
being a dictionary which given an int produces an int, and the second 
argument, a function which takes an int and produces an int. The 
function itself returns an int."

Side note: I'm actually in favor of the idea of Python adding 
syntactical support for operators that have no "built-in" definition. 
The use case would be for classes that define new operators that don't 
correspond to the semantics of any existing operator. But that's another 
thread, maybe one not worth starting :)

-- Talin

From steven.bethard at gmail.com  Sat May 20 06:42:49 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 19 May 2006 22:42:49 -0600
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
Message-ID: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> As a quick data point, I showed around your "dict[str, str|int]"
> example to some friends, all of whom have done a decent amount of
> coding in Python. I gave them some background, including that this was
> an example of type parameterization. To quote one fellow, a PhD
> student in CS at Edinburgh: "So, uh, 'dict[str, int|str]' is supposed
> to represent... uh... I give in, what the hell is that supposed to
> denote?"
>
> I know the plural of "anecdote" isn't "data"; maybe c.l.p should be
> polled on some of these things?

I think c.l.py is definitely not the right place to go right now.
It'll just dissolve into a syntax debate without touching on any of
the real issues.

Which brings me to my comment about the current discussion.  Can't we
drop the syntax discussion for a while and have someone motivate it
with some use-cases first?  Sure, I can figure out what ``dict[str,
str|int]`` means, but I still have no idea what you'd gain by
declaring a parameter to have such a type.  Should it add checks every
time __getitem__ or __setitem__ is called?

I think that if we can figure out what people would actually use type
annotations for, I think it'll be much clearer what exactly needs
syntactic support.  At the moment, I can see a few simple uses that
would only make things painful -- e.g. parameters getting declared as
ints when any number type would work -- or that seem too
computationally inefficient -- e.g. dict[str, str] would presumably
have to add type-checks at every __getitem__ or __setitem__ call.

STeVe

P.S.  I did look at
http://svn.python.org/projects/sandbox/trunk/typecheck, but couldn't
find any use-case examples.
-- 
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From collinw at gmail.com  Sat May 20 07:10:28 2006
From: collinw at gmail.com (Collin Winter)
Date: Sat, 20 May 2006 01:10:28 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
Message-ID: <43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> OK; for the return value (only) the Function().returns(<type>)
> notation does look fairly pretty.
>
> I presume that return(int, int) is the same as return((int, int))?

It is.

> Weren't we going to write a tuple of two ints as tuple[int, int]
> though? Is (int, int) now just an alias for that or does it have a
> different meaing?

I think that returns() is smart enough to know that "returns((int,
int))" is the same as "returns(int, int)". It will know to do
something similar for "returns(tuple[int, int])".

Collin Winter

From qrczak at knm.org.pl  Sat May 20 07:24:26 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sat, 20 May 2006 07:24:26 +0200
Subject: [Python-3000] Use cases for type annotations?
In-Reply-To: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	(Steven Bethard's message of "Fri, 19 May 2006 22:42:49 -0600")
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
Message-ID: <87psi9jmk5.fsf@qrnik.zagroda>

"Steven Bethard" <steven.bethard at gmail.com> writes:

> Which brings me to my comment about the current discussion.  Can't we
> drop the syntax discussion for a while and have someone motivate it
> with some use-cases first?  Sure, I can figure out what ``dict[str,
> str|int]`` means, but I still have no idea what you'd gain by
> declaring a parameter to have such a type.  Should it add checks every
> time __getitem__ or __setitem__ is called?

Indeed. And if passes through a variable with a declared type multiple
times in a loop, would it accumulate multiple checking layers?

If "mapping" is substituted for "dict", is it wrapped while preserving
the class? How?

IMHO any type checking which would require wrapping in a checking
layer makes no sense; besides the risk of accumulating checking
layers, it doesn't detect type violation at the time of the check
anyway.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From talin at acm.org  Sat May 20 07:38:54 2006
From: talin at acm.org (Talin)
Date: Fri, 19 May 2006 22:38:54 -0700
Subject: [Python-3000] Use cases for type annotations? (WAS:
	Type	parameterization)
In-Reply-To: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
Message-ID: <446EAB6E.4020606@acm.org>

Steven Bethard wrote:
> 
> Which brings me to my comment about the current discussion.  Can't we
> drop the syntax discussion for a while and have someone motivate it
> with some use-cases first?  Sure, I can figure out what ``dict[str,
> str|int]`` means, but I still have no idea what you'd gain by
> declaring a parameter to have such a type.  Should it add checks every
> time __getitem__ or __setitem__ is called?
> 
> I think that if we can figure out what people would actually use type
> annotations for, I think it'll be much clearer what exactly needs
> syntactic support.  At the moment, I can see a few simple uses that
> would only make things painful -- e.g. parameters getting declared as
> ints when any number type would work -- or that seem too
> computationally inefficient -- e.g. dict[str, str] would presumably
> have to add type-checks at every __getitem__ or __setitem__ call.

I'm less interested in type-checking than in type-inferencing, that is, 
making logical deductions about the code based on types. Multi-dispatch 
is one example of this.

Here's a list of use cases that I can think of:

1) Type checking

2) Dispatching based on the type of arguments.

3) Documentation scanners that can extract type information.

4) Static code analysis tools.

5) Implementation of mini-languages (algebraic solvers, expert systems, 
etc.) within Python.

6) Using type information to optimize packet formats for RPC calls.

7) Method to declare functions that communicate with statically-typed 
libraries or network protocols.

8) Optimized code generation for Python native-code compilers.

-- Talin

From tomerfiliba at gmail.com  Sat May 20 10:31:04 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Sat, 20 May 2006 10:31:04 +0200
Subject: [Python-3000] Anti-use-case for type annotations
Message-ID: <1d85506f0605200131y4ef00ebdh3f46286691ae40f1@mail.gmail.com>

i've been crying about that for quite a long time, but it seems people
failed to see
my point: type checking, which is more easily enforced by type annotations,
is bad.

and because it will have this nice (and pointless*) syntax, lots of
people will start
using them everywhere, and make projects like mine (RPyC) or PYRO worthless.

this kind of projects relies on proxies -- objects that *look* like
the object they
point to. like weakref.proxy. of course these objects don't have the *type* of
the pointed object, they only have it's attributes, or rather, they deliver all
__getattr__s and __setattr__s to the remote object, and re-raise exceptions
locally.

when type annotations become so handy, everybody will start using them,
and it will greatly limit the use case of proxies. my proxies give you something
that looks like a file, i.e, you can .read from it, .write to it,
.close it, etc., but
isinstance(f, file) is False.

in fact, version 2.55 of RPyC provided a replacement for isinstance that can
test for proxies (recursively goes up the __bases__, and serialzies each type
as a filename.typename string, which is unique enough), and you can do
__builtin__.isinstance = Rpyc.isinstance, and then throughout your code
you can work with NetProxies. but it's uber *nasty*, and doesn't work with
builtin modules/classes/functions (they bind directly to the "real" isinstance)

so that's an anti-use-case for type annotations. when people start
using those, they would effectively stop using duck-typing, since the
type of the object must be well-defined, and thus render "look-alike"
objects useless.

------

* pointless -- type annotations basically subclass an existing
container type (list,
tuple, dict) and simply add type checking to append/insert/__setitem__, so
that wrongly-typed objects can't accidentally get into the container.

but it's python, not java, so you could always call the super's __setitem__
and break the whole idea.

i would expect that specialized type of be optimized for that given type, i.e.,
reserve only the required space for that type, etc. but i understand that's not
the case. so why not just do something like this instead:

>>> def ListOf(oftype):
...     class meta(type): # just for pretty repr
...         def __repr__(self):
...             return "<type %s(%s)>" % (self.__name__, oftype.__name__)
...     class ListOf(list):
...         __metaclass__ = meta
...         def __init__(self, seq = []):
...             self.extend(seq)
...         def append(self, value):
...             if not isinstance(value, oftype):
...                 raise TypeError("invalid type")
...             list.append(self, value)
...         def insert(self, index, value):
...             if not isinstance(value, oftype):
...                 raise TypeError("invalid type")
...             list.insert(self, index, value)
...         def extend(self, iterable):
...             for item in iterable:
...                 self.append(item)
...         def __setitem__(self, index, value):
...             if not isinstance(value, oftype):
...                 raise TypeError("invalid type")
...             list.__setitem__(self, index, value)
...     return ListOf
...
>>>
>>> intlist = ListOf(int)
>>> intlist
<type ListOf(int)>
>>> l = intlist([1,2,3])
>>> l.append(4)
>>> l.append("a string")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 11, in append
TypeError: invalid type
>>> print l
[1, 2, 3, 4]
>>> isinstance(l, intlist)
True
>>>

that way, with dicts, you can have keyword arguments

d = DictOf(key = str, value = int)
or
d = DictOf(key = str, value = (int, str))
(int, str) means int or string, because isinstance can accept a tuple of types.

so who needs type annotations? the only thing they are good for is
better/automatically documenting code. but is better documenting
worth imposing restrictions on the langauge, as in the proxying case?
is better documenting worth breaking duck typing?

something that looks like a file but does not inherit from file, cannot be
used by a function that expects a file, although all it needs is a "read"
attribute!

-------

but if you think type annotations are the way to go, i'd ask that the type-
checking functions, like type or isinstance, would call a special __type__
method of the object.
i.e., type(x) ==> x.__type__()
which would normally return x.__class__, but in the case of proxies, it
would return the type of the proxied object.

by the way, how about renaming type(x) as typeof(x)? it's quite ugly
that "type" is both a factory for types as well as a function that returns
their type, and it depends of the number of arguments.
type(name, bases, namespace) --> create a new type
typeof(x) --> return the type of x




-tomer

From p.f.moore at gmail.com  Sat May 20 15:25:03 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 20 May 2006 14:25:03 +0100
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <446EAB6E.4020606@acm.org>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<446EAB6E.4020606@acm.org>
Message-ID: <79990c6b0605200625u41e2bafcy6b09404f15bf8d4a@mail.gmail.com>

On 5/20/06, Talin <talin at acm.org> wrote:

> Here's a list of use cases that I can think of:
[...]

Interesting. Can you elaborate one of these into a strawman example,
with code, that we can discuss? There are a number of issues I can
see, but it's too easy to be vague without a concrete example to pick
apart.

As an example, with type checking, I'd like to see how the interface
between annotated and non-annotated code would work. Would we hit the
same problems as "const" in C++? Would people need to add "casts"
(conversions) to use annotated libraries? What happens if an
annotation is too strict (say, a function documented as taking int or
long, which gets passed a gmpy.mpz (efficient long integer) instance)?

Feel free to pick a different use case, if you prefer.

Paul.

From guido at python.org  Sat May 20 16:37:41 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 20 May 2006 07:37:41 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <446E99B8.10500@acm.org>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
Message-ID: <ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>

On 5/19/06, Talin <talin at acm.org> wrote:
> Side note: I'm actually in favor of the idea of Python adding
> syntactical support for operators that have no "built-in" definition.
> The use case would be for classes that define new operators that don't
> correspond to the semantics of any existing operator. But that's another
> thread, maybe one not worth starting :)

That could be done for a fixed number of new operators with fixed
priorities. (But you'd have to pick your set of operators somehow.)

It could not be done if you wanted to let users define their own
combination of squiggles on the fly (the parser and lexer are too
stupid).

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

From guido at python.org  Sat May 20 16:41:55 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 20 May 2006 07:41:55 -0700
Subject: [Python-3000] Use cases for type annotations?
In-Reply-To: <87psi9jmk5.fsf@qrnik.zagroda>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<87psi9jmk5.fsf@qrnik.zagroda>
Message-ID: <ca471dc20605200741g490fba22lef4b31efe3640d22@mail.gmail.com>

On 5/19/06, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> "Steven Bethard" <steven.bethard at gmail.com> writes:
>
> > Which brings me to my comment about the current discussion.  Can't we
> > drop the syntax discussion for a while and have someone motivate it
> > with some use-cases first?

Read my blogs (over a year old) on the topic. I believe Collin
references them regularly in these threads.

> > Sure, I can figure out what ``dict[str,
> > str|int]`` means, but I still have no idea what you'd gain by
> > declaring a parameter to have such a type.  Should it add checks every
> > time __getitem__ or __setitem__ is called?
>
> Indeed. And if passes through a variable with a declared type multiple
> times in a loop, would it accumulate multiple checking layers?
>
> If "mapping" is substituted for "dict", is it wrapped while preserving
> the class? How?
>
> IMHO any type checking which would require wrapping in a checking
> layer makes no sense; besides the risk of accumulating checking
> layers, it doesn't detect type violation at the time of the check
> anyway.

We're way ahead of you two. The annotations are meant as
documentation, for tools like pychecker, and (perhaps, with suitable
decorators) for things like adaptation. While some participants in
this thread have written systems that actually (dynamically) verify
that arguments passed in match the type specs, the intent is *not*
that that will be a standard feature. Nor is it intended to cause
optimized bytecode to be written.

It's all in the blogs.

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

From guido at python.org  Sat May 20 16:52:38 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 20 May 2006 07:52:38 -0700
Subject: [Python-3000] Anti-use-case for type annotations
In-Reply-To: <1d85506f0605200131y4ef00ebdh3f46286691ae40f1@mail.gmail.com>
References: <1d85506f0605200131y4ef00ebdh3f46286691ae40f1@mail.gmail.com>
Message-ID: <ca471dc20605200752q64b183cbof59aac8543d78e4a@mail.gmail.com>

On 5/20/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> i've been crying about that for quite a long time, but it seems people failed to see
> my point: type checking, which is more easily enforced by type annotations,
> is bad.

Pleast stop panicking. You don't seem to understand the proposal.

> and because it will have this nice (and pointless*) syntax, lots of people will start
> using them everywhere, and make projects like mine (RPyC) or PYRO worthless.

Depends.

> this kind of projects relies on proxies -- objects that *look* like the object they
> point to. like weakref.proxy. of course these objects don't have the *type* of
> the pointed object, they only have it's attributes, or rather, they deliver all
> __getattr__s and __setattr__s to the remote object, and re-raise exceptions
> locally.
>
> when type annotations become so handy, everybody will start using them,
> and it will greatly limit the use case of proxies. my proxies give you something
> that looks like a file, i.e, you can .read from it, .write to it, .close it, etc., but
> isinstance(f, file) is False.

Read my blogs on the topic. requiring isinstance() matching is *not*
part of the proposal. This has all been discussed before.

[...]
> * pointless -- type annotations basically subclass an existing container type (list,
> tuple, dict) and simply add type checking to append/insert/__setitem__, so
> that wrongly-typed objects can't accidentally get into the container.

I don't know where you got this idea. That's not the plan at all.

The plan is for the bytecode compiler to *ignore* the annotations
except to make the value of the evaluated annotation expressions
available via the __signature__ attribute of the function object, just
like the default values.

You can then write a decorator that does something with these. Or you
can just use them as documentation. The decorators don't have to do
type checking; they can do whatever you like; that's why there is no
semantic constraint on the type annotations.

If you want to write

def foo(a: "the first argument", b: 42) -> (1, 2, 3):

go right ahead.

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

From guido at python.org  Sat May 20 17:04:40 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 20 May 2006 08:04:40 -0700
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
Message-ID: <ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>

> On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> > I know the plural of "anecdote" isn't "data"; maybe c.l.p should be
> > polled on some of these things?

Please don't. It serves no purpose; just like in US politics, you'll
always find a pretty much 50/50 split for and against any proposal
(except the party lines aren't always the same), and endless debate
will ensue (and I mean *endless*).

I've already addressed Steve's other issues. The blogs have the use cases etc.

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

From collinw at gmail.com  Sat May 20 18:19:48 2006
From: collinw at gmail.com (Collin Winter)
Date: Sat, 20 May 2006 12:19:48 -0400
Subject: [Python-3000] Misc type annotation issues
Message-ID: <43aa6ff70605200919i296a1ac5ib7cd687489e94c1d@mail.gmail.com>

Some things I still have listed as "outstanding issues" for the annotations PEP:

1. You mentioned in one blog post [1] that you wanted to have 'any'
and 'nothing' types. Is this still something you want as built-ins, or
should it be left up to the annotation-interpreting libraries to
provide these?

2. Do you still want syntactic support for super/subtyping? In [1],
you mention using something like "T1 <= T2" to indicate that T1 is a
subtype of T2 and "T2 >= T1" to say T2 is a supertype of T1.

If you still want this syntax, what do these inequalities return? The
obvious answer is "a boolean", but you go on to use something like
"list[T <= Number]" to indicate a list of subtypes of Number. To me,
this latter example should be written "list[Number]", freeing <= and
>= on types to return booleans as expected.

However, since we're giving so much control to the
annotation-interpreting libraries, trying to define a useful and
consistent semantic for built-in super/subtyping inequalities would
run into the same problem as would a built-in typecheck() function.
Like typecheck(), it would be better to let the third-party libraries
provide their own issubtype() and issupertype() functions.

3. What will annotations on *varargs and **varkw look like? My own
suggestion is that

>>> def foo(a: <type>, *varargs: <type>, **varkw: <type>)

is fully equivalent to -- and is indeed coerced to --

>>> def foo(a: <type>, *varargs: list[<type>], **varkw: dict[str, <type>])

What did you have in mind?

Collin Winter

[1] - http://www.artima.com/weblogs/viewpost.jsp?thread=86641

From guido at python.org  Sat May 20 18:29:47 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 20 May 2006 09:29:47 -0700
Subject: [Python-3000] Misc type annotation issues
In-Reply-To: <43aa6ff70605200919i296a1ac5ib7cd687489e94c1d@mail.gmail.com>
References: <43aa6ff70605200919i296a1ac5ib7cd687489e94c1d@mail.gmail.com>
Message-ID: <ca471dc20605200929p3d4c36b8xe6a67fe8a4bedc43@mail.gmail.com>

On 5/20/06, Collin Winter <collinw at gmail.com> wrote:
> Some things I still have listed as "outstanding issues" for the annotations PEP:
>
> 1. You mentioned in one blog post [1] that you wanted to have 'any'
> and 'nothing' types. Is this still something you want as built-ins, or
> should it be left up to the annotation-interpreting libraries to
> provide these?

Since their semantics are up to the libraries they should also be defined there.

> 2. Do you still want syntactic support for super/subtyping? In [1],
> you mention using something like "T1 <= T2" to indicate that T1 is a
> subtype of T2 and "T2 >= T1" to say T2 is a supertype of T1.

Lukewarm. If we have typecheck(x, T) (in the library or whereever)
perhaps we could also have issubtype(T1, T2) there.

> If you still want this syntax, what do these inequalities return? The
> obvious answer is "a boolean", but you go on to use something like
> "list[T <= Number]" to indicate a list of subtypes of Number. To me,
> this latter example should be written "list[Number]", freeing <= and
> >= on types to return booleans as expected.

That was probably an earlier wild idea where 'T' would automatically
become a free (type) variable. Let's not go there for now.

> However, since we're giving so much control to the
> annotation-interpreting libraries, trying to define a useful and
> consistent semantic for built-in super/subtyping inequalities would
> run into the same problem as would a built-in typecheck() function.
> Like typecheck(), it would be better to let the third-party libraries
> provide their own issubtype() and issupertype() functions.

Agreed.

> 3. What will annotations on *varargs and **varkw look like? My own
> suggestion is that
>
> >>> def foo(a: <type>, *varargs: <type>, **varkw: <type>)
>
> is fully equivalent to -- and is indeed coerced to --
>
> >>> def foo(a: <type>, *varargs: list[<type>], **varkw: dict[str, <type>])
>
> What did you have in mind?

We can't allow both the shorthand and the full notation, since then
there would be ambiguity: if "*args: int" meant the same as "*args:
list[int]", then what if I want each of the remaining positional
arguments to be a list of ints? "*args: list[int]" is already taken to
mean that each of the remaining arguments is an int.

Since the full notation is unnecessarily verbose, I propose that
"*args: T" means that each of the remaining arguments should be a T,
and the type of args itself is list[T]. Similar for **kwds.

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

From tomerfiliba at gmail.com  Sat May 20 18:51:22 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Sat, 20 May 2006 18:51:22 +0200
Subject: [Python-3000] Anti-use-case for type annotations
In-Reply-To: <ca471dc20605200752q64b183cbof59aac8543d78e4a@mail.gmail.com>
References: <1d85506f0605200131y4ef00ebdh3f46286691ae40f1@mail.gmail.com>
	<ca471dc20605200752q64b183cbof59aac8543d78e4a@mail.gmail.com>
Message-ID: <1d85506f0605200951n461d6a78w2e345053c86a7282@mail.gmail.com>

Guido writes:
> You can then write a decorator that does something with these. Or you
> can just use them as documentation. The decorators don't have to do
> type checking; they can do whatever you like; that's why there is no
> semantic constraint on the type annotations.

well, if that's the case, i'm fine with that. still, i think people would
break duck-typing with that new feature, but as long as it's not enforced by
the language -- it's their problem.

-----

by the way, i released a working draft of the pythonic sockets module,
if anyone is interested:
http://iostack.wikispaces.com/download

i'd like to receive feedback on it. c.l.p didn't respond.

allow me to remind that this socket module is not directly related to stream-
based IO that was discussed here. Sock2 improves the existing socket
module, and streams would be constructed on top of it, if desired.


-tomer

On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> On 5/20/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> > i've been crying about that for quite a long time, but it seems people failed to see
> > my point: type checking, which is more easily enforced by type annotations,
> > is bad.
>
> Pleast stop panicking. You don't seem to understand the proposal.
>
> > and because it will have this nice (and pointless*) syntax, lots of people will start
> > using them everywhere, and make projects like mine (RPyC) or PYRO worthless.
>
> Depends.
>
> > this kind of projects relies on proxies -- objects that *look* like the object they
> > point to. like weakref.proxy. of course these objects don't have the *type* of
> > the pointed object, they only have it's attributes, or rather, they deliver all
> > __getattr__s and __setattr__s to the remote object, and re-raise exceptions
> > locally.
> >
> > when type annotations become so handy, everybody will start using them,
> > and it will greatly limit the use case of proxies. my proxies give you something
> > that looks like a file, i.e, you can .read from it, .write to it, .close it, etc., but
> > isinstance(f, file) is False.
>
> Read my blogs on the topic. requiring isinstance() matching is *not*
> part of the proposal. This has all been discussed before.
>
> [...]
> > * pointless -- type annotations basically subclass an existing container type (list,
> > tuple, dict) and simply add type checking to append/insert/__setitem__, so
> > that wrongly-typed objects can't accidentally get into the container.
>
> I don't know where you got this idea. That's not the plan at all.
>
> The plan is for the bytecode compiler to *ignore* the annotations
> except to make the value of the evaluated annotation expressions
> available via the __signature__ attribute of the function object, just
> like the default values.
>
> You can then write a decorator that does something with these. Or you
> can just use them as documentation. The decorators don't have to do
> type checking; they can do whatever you like; that's why there is no
> semantic constraint on the type annotations.
>
> If you want to write
>
> def foo(a: "the first argument", b: 42) -> (1, 2, 3):
>
> go right ahead.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>

From tony at printra.net  Sat May 20 17:25:23 2006
From: tony at printra.net (Tony Lownds)
Date: Sat, 20 May 2006 08:25:23 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <446E99B8.10500@acm.org>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
Message-ID: <287D2E67-D342-4BFA-8D8F-DB3A6BD04865@printra.net>


On May 19, 2006, at 9:23 PM, Talin wrote:

>
> OK, try this on your friends and see what happens:
>
>     dict[ str >> int ]
>

How about just dict[str:int]?

> Alternative suggestion: Define -> as an operator.
>

I like this idea!

-Tony



From steven.bethard at gmail.com  Sat May 20 20:36:55 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sat, 20 May 2006 12:36:55 -0600
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>
Message-ID: <d11dcfba0605201136r25d43a39y7bf2e21cb7ea1531@mail.gmail.com>

On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> I've already addressed Steve's other issues. The blogs have the use cases etc.

I'm sorry, I guess I'm just dense, but here's the blogs I've read:

http://www.artima.com/weblogs/viewpost.jsp?thread=85551
http://www.artima.com/weblogs/viewpost.jsp?thread=86641
http://www.artima.com/weblogs/viewpost.jsp?thread=87182
http://www.artima.com/weblogs/viewpost.jsp?thread=89161
http://www.artima.com/weblogs/viewpost.jsp?thread=101605
http://www.artima.com/weblogs/viewpost.jsp?thread=92662
http://www.artima.com/weblogs/viewpost.jsp?thread=155123

And the only use-cases I could extract are:

* optional type checking.  Lots of thoughts here, and it seemed like
most of the blogs were leaning towards introducing interfaces to avoid
requiring concrete types.  But the discussion here has been using
things like 'int' and 'str', so I'm confused as to whether or not this
is still the intention.

* function overloading[1].  I think Philip J. Eby had some interesting
thoughts here, but in all the prototypes, dispatching was done on
concrete types.  Is there a way to do function overloading that
doesn't rule-out duck typing and is still reasonably efficient?

I guess, in general, my concerns about the use-cases I found were that:

(1) there were very few real implementations of the ideas, and
(2) where there was an implementation, it relied on concrete types

Is it the intention that type annotations be used primarily to check
concrete types?  Or maybe interfaces are being introduced so that type
annotations can check them instead?  If so, I'd like to see one of the
prototype systems using interfaces.  Or maybe there's some other way
that type annotations are going to be used that doesn't rely on
concrete types that I've just missed?

Sorry to still not be getting it!

STeVe

[1] A related use case was adaptation, but as I understand it, the
adaptation folks have mostly moved to the function overloading camp
now.  The issues were similar anyway.
-- 
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From guido at python.org  Sat May 20 21:52:14 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 20 May 2006 12:52:14 -0700
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <d11dcfba0605201136r25d43a39y7bf2e21cb7ea1531@mail.gmail.com>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>
	<d11dcfba0605201136r25d43a39y7bf2e21cb7ea1531@mail.gmail.com>
Message-ID: <ca471dc20605201252u26c4ff5dkf98854e98bbd9dfa@mail.gmail.com>

On 5/20/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> > I've already addressed Steve's other issues. The blogs have the use cases etc.
>
> I'm sorry, I guess I'm just dense, but here's the blogs I've read:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=85551
> http://www.artima.com/weblogs/viewpost.jsp?thread=86641
> http://www.artima.com/weblogs/viewpost.jsp?thread=87182
> http://www.artima.com/weblogs/viewpost.jsp?thread=89161
> http://www.artima.com/weblogs/viewpost.jsp?thread=101605
> http://www.artima.com/weblogs/viewpost.jsp?thread=92662
> http://www.artima.com/weblogs/viewpost.jsp?thread=155123
>
> And the only use-cases I could extract are:
>
> * optional type checking.  Lots of thoughts here, and it seemed like
> most of the blogs were leaning towards introducing interfaces to avoid
> requiring concrete types.  But the discussion here has been using
> things like 'int' and 'str', so I'm confused as to whether or not this
> is still the intention.

This was mostly retracted later.

Re-read this one:
http://www.artima.com/weblogs/viewpost.jsp?thread=86641 especially the
section on Motivation.

> * function overloading[1].  I think Philip J. Eby had some interesting
> thoughts here, but in all the prototypes, dispatching was done on
> concrete types.  Is there a way to do function overloading that
> doesn't rule-out duck typing and is still reasonably efficient?

You may have read my prototypes, which dispatch on concrete types.
Phillip lets you dispatch on predicates like hasattr(x, 'append').

> I guess, in general, my concerns about the use-cases I found were that:
>
> (1) there were very few real implementations of the ideas, and

Collin Winters is pretty real, and I believe one other person (Tony
Lownds?) has another.

> (2) where there was an implementation, it relied on concrete types

Collin's doesn't. (He rewrote his tutorial to remove this.)

> Is it the intention that type annotations be used primarily to check
> concrete types?

To the contrary, that would be a big mistake.

> Or maybe interfaces are being introduced so that type
> annotations can check them instead?  If so, I'd like to see one of the
> prototype systems using interfaces.  Or maybe there's some other way
> that type annotations are going to be used that doesn't rely on
> concrete types that I've just missed?
>
> Sorry to still not be getting it!

You could build your own system using interfaces, perhaps by combining
Zope/Twisted interfaces with Collin's implementation?

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

From guido at python.org  Sat May 20 21:53:08 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 20 May 2006 12:53:08 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <287D2E67-D342-4BFA-8D8F-DB3A6BD04865@printra.net>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
	<287D2E67-D342-4BFA-8D8F-DB3A6BD04865@printra.net>
Message-ID: <ca471dc20605201253y11fbb05dg9a9c7838a06527bc@mail.gmail.com>

On 5/20/06, Tony Lownds <tony at printra.net> wrote:
> How about just dict[str:int]?

A bit too clever, although it happens to work syntactically -- it
calls dict.__getitem__(slice(str, int)).

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

From qrczak at knm.org.pl  Sat May 20 22:09:38 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sat, 20 May 2006 22:09:38 +0200
Subject: [Python-3000] Use cases for type annotations?
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>
	<d11dcfba0605201136r25d43a39y7bf2e21cb7ea1531@mail.gmail.com>
Message-ID: <87ejyoo3ul.fsf@qrnik.zagroda>

"Steven Bethard" <steven.bethard at gmail.com> writes:

> (1) there were very few real implementations of the ideas, and
> (2) where there was an implementation, it relied on concrete types

Common Lisp has:

- Classes ("concrete types"), with explicit subclassing,
  not parametrized, defined strictly, used for dispatch.

- Types, with various ad-hoc notations for builtin concepts (like
  integer ranges, arrays with specialized element types, functions
  with specific argument and result types), where asking for subtyping
  has three possible outcomes ("yes", "no", "I don't know", with
  partially implementation-dependent distribution), used mainly for
  optimization based on explicit declarations, and sometimes for
  expressing predicates to be tested against concrete objects.

Python seems to want to archieve both goals with one system.
I'm sceptic.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From steven.bethard at gmail.com  Sat May 20 22:43:00 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sat, 20 May 2006 14:43:00 -0600
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <ca471dc20605201252u26c4ff5dkf98854e98bbd9dfa@mail.gmail.com>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>
	<d11dcfba0605201136r25d43a39y7bf2e21cb7ea1531@mail.gmail.com>
	<ca471dc20605201252u26c4ff5dkf98854e98bbd9dfa@mail.gmail.com>
Message-ID: <d11dcfba0605201343m423aca56v3f03a1a5159b49bb@mail.gmail.com>

On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> On 5/20/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > And the only use-cases I could extract are:
[snip]
> > * function overloading[1].  I think Philip J. Eby had some interesting
> > thoughts here, but in all the prototypes, dispatching was done on
> > concrete types.  Is there a way to do function overloading that
> > doesn't rule-out duck typing and is still reasonably efficient?
>
> You may have read my prototypes, which dispatch on concrete types.
> Phillip lets you dispatch on predicates like hasattr(x, 'append').

I assume you mean this one:
    http://svn.python.org/projects/sandbox/trunk/Overload3K
It does allow you to dispatch on other predicates, but in the current
prototype incarnation,  implies() is defined in terms of issubclass.
Of course, the nice thing about Phillip's approach is that you can
overload implies() so that, for example, you can use hasattr() like
you suggest above, but I haven't seen any examples yet where this was
actually done.

> > I guess, in general, my concerns about the use-cases I found were that:
> >
> > (1) there were very few real implementations of the ideas, and
>
> Collin Winters is pretty real, and I believe one other person (Tony
> Lownds?) has another.

I wandered around
    http://oakwinter.com/code/typecheck/
but couldn't find any discussion about the implications of, say,
requring the type ``{str:Number}`` (which I assume is basically
equivalent to the dict[str, Number] in this discussion).  Does that
mean that every access to the dict is checked?

I do like the idea of the TypeClass object, which basically infers an
interface.  But I'd really like someone to discuss the performance
implications somewhere.  Maybe it is and I just couldn't find it?

> > Is it the intention that type annotations be used primarily to check
> > concrete types?
>
> To the contrary, that would be a big mistake.

Phew. ;-)  And thanks for all the clarifications.

I guess in the end, I'm still a little confused at why we're having a
syntax discussion now.  If type annotations are just an extra
expression in a function definition, why does Python  core care about
what syntax a system like Phillip's or Collin's chooses?  That is,
isn't the ``dict[str, int]`` or ``{str: int}`` syntax decision just a
decision for the ``typecheck`` or ``overloading`` module, and not for
Python in general?

STeVe
-- 
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From collinw at gmail.com  Sat May 20 23:07:19 2006
From: collinw at gmail.com (Collin Winter)
Date: Sat, 20 May 2006 17:07:19 -0400
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <d11dcfba0605201343m423aca56v3f03a1a5159b49bb@mail.gmail.com>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>
	<d11dcfba0605201136r25d43a39y7bf2e21cb7ea1531@mail.gmail.com>
	<ca471dc20605201252u26c4ff5dkf98854e98bbd9dfa@mail.gmail.com>
	<d11dcfba0605201343m423aca56v3f03a1a5159b49bb@mail.gmail.com>
Message-ID: <43aa6ff70605201407o2a003a54s8d888422d23d3e3f@mail.gmail.com>

On 5/20/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> > Collin Winter's is pretty real, and I believe one other person (Tony
> > Lownds?) has another.
>
> I wandered around
>     http://oakwinter.com/code/typecheck/
> but couldn't find any discussion about the implications of, say,
> requring the type ``{str:Number}`` (which I assume is basically
> equivalent to the dict[str, Number] in this discussion).  Does that
> mean that every access to the dict is checked?

{str: Number} is indeed my syntax for dict[str, Number] (I didn't have
the luxury of messing with the built-ins ; )

http://oakwinter.com/code/typecheck/tutorial/builtintypes.html in
particular discusses what it means to say that an argument should be
{str: Number}: namely, that all keys must be strs and all values
should be Numbers. It also talks about tuples, lists and sets.

The documentation also (frequently) says things like "The following
signature asserts that the function takes a list of Numbers and
returns a single Number", "This [signature] specifies that the
function accepts a 2-tuple", "In this example, the first two arguments
to the function must be Numbers, but 'c' can be anything", "In the
following signature, the 'a' parameter must be either 6 or 7", etc.

Put simply, I'm having trouble imagining where you're getting ideas
about {str: Number} creating wrapping layers around the dict, since
such a thing is never once mentioned in the docs.

> I do like the idea of the TypeClass object, which basically infers an
> interface.  But I'd really like someone to discuss the performance
> implications somewhere.  Maybe it is and I just couldn't find it?

I haven't done any real performance analysis on my system. My focus so
far has been getting things working the way I want, saving the
performance issue for later.

Collin Winter

From talin at acm.org  Sat May 20 23:38:06 2006
From: talin at acm.org (Talin)
Date: Sat, 20 May 2006 14:38:06 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
 annotating generators)
In-Reply-To: <ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>	
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>	
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>	
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>	
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>	
	<446E99B8.10500@acm.org>
	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>
Message-ID: <446F8C3E.5000009@acm.org>

Guido van Rossum wrote:
> On 5/19/06, Talin <talin at acm.org> wrote:
> 
>> Side note: I'm actually in favor of the idea of Python adding
>> syntactical support for operators that have no "built-in" definition.
>> The use case would be for classes that define new operators that don't
>> correspond to the semantics of any existing operator. But that's another
>> thread, maybe one not worth starting :)
> 
> 
> That could be done for a fixed number of new operators with fixed
> priorities. (But you'd have to pick your set of operators somehow.)
> 
> It could not be done if you wanted to let users define their own
> combination of squiggles on the fly (the parser and lexer are too
> stupid).

That's a given. What I was thinking about was a fixed number of 
"placeholder" operators that would be available for application use.

As far as how to pick the set of operators, well my notion on that was 
to come up with a list of general mathematical and logical concepts, and 
see if any would be useful as operators. In other words, the placeholder 
operators would have general meanings assigned to them, but not specific 
implementations.

My train of thought was something like this: If you are planning on 
using the token '->' to indicate the return type of a function, then 
you're going to have to add that to the lexer; And once you do that, why 
not go the extra step and make it an operator?

In this case, the meaning of the '->' operator is "derives" as in 
"derives/produces/yields/maps-to/etc." So the expression "f(a) -> b" is 
a statement that the operation of 'f(a)' yields a result of 'b'.

(BTW, correct me if I am using the word 'derives' incorrectly. I'm 
specifically thinking of the meaning from the 'dragon book', but I may 
have it reversed.)

The operator's magic method would be something like __derives__, and its 
actual implementation would depend on the context. So for a type system, 
you could say things like:

    Function( int ) -> float

Meaning 'a function that takes an int and produces a float'.

Meanwhile, in an algebraic solver, you could say:

    Var('x') + 0 -> Var('x')

The 'Var' type overloads '+' operator to return an AST-like structure 
representing the addition of a variable and a constant zero; That 
structure in turn overloads the '->' operator to add generate a rule 
that says that adding 0 to a variable produces the same variable.

(Now all I need is a friendly way to spell "Var('x')" and I'm all set.)

One strange consequence of defining the expression 'a -> b' as 'a 
produces b' is how this applies to type declarations of dictionaries and 
lists. For dicts, there are two possible options:

     dict[ str -> int ]
     dict[ str ] -> int

The first is saying that 'within the context of a dict, a str produces 
an int'. The second is saying 'the operation dict[ str ] produces an 
int." (The latter is more Haskell-ish)

Both of those are fairly reasonable, but what happpens if we apply the 
same reasoning to lists:

     list[ int -> int ]
     list[ int ] -> int

This is unecessarily verbose, because the first argument is always going 
to be an int (or some scalar number type). I suppose one way around this 
is to simply declare that for type-description purposes, lists are not 
treated as mappings.

Another question that springs to mind is, what about the converse 
operator, '<-', and what does it represent? (Besides meaning "less than 
the negative of", which is a troubling ambiguity.) One possible meaning 
that could be assigned is "substitutes", and could be useful in grammar 
files, where the non-terminal is usually on the left. (Or you could 
simply make the BNF operator ::= a Python operator, but that's getting 
ridiculous, assuming that I haven't made myself ridiculous enough already.)

-- Talin




-- Talin

From paul at boddie.org.uk  Sun May 21 01:00:18 2006
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 21 May 2006 01:00:18 +0200
Subject: [Python-3000] Type annotations: annotating generators
Message-ID: <200605210100.18808.paul@boddie.org.uk>

Tony Lownds wrote:
>
> Paul Boddie wrote:
> >
> > What's the general opinion on systems which attempt to infer and
> > predict inappropriate type usage?

[...]

> > Couldn't such systems be a better aid to program reliability?
> > Would "optional" type declarations be relevant to the operation
> > of such systems?
> 
> I've been hacking on such a system, called "t_types". It is in pre- 
> release form right now. It actually deduces type usage using bytecode
> simulation, before run-time.

I've been working on something similar, which is partly why I asked the 
question. See here:

http://www.python.org/pypi/analysis

However, it's not that similar: it traverses the AST (from the compiler 
module) for want of a representation that doesn't drop useful information 
from the program. For a more efficient approach, I can imagine a virtual 
machine which operates on types and constraints as opposed to actual data, 
and I imagine that the PyPy "flow object space" might do something like this, 
but finding some kind of concise confirmation of such suspicions in the PyPy 
documentation is often a challenge.

There are other systems which take similar approaches: Shedskin, Starkiller, 
Pylint (not the Logilab one), along with various other experiments. It makes 
me think that a common framework, possibly involving some of the Logilab 
projects (as previously suggested to me by one of their developers), may 
provide a good opportunity for consolidation here.

> For t_types, starting the simulation with types more specific than  
> "anything" is important for reasonable results. In general I think
> optional type declarations are relevant to such systems, whether a
> special syntax is adopted or decorators are used.

Is there some kind of unstated consensus on whole-program analysis? Collin 
Winter expressed some reservations in a private communication, but I'd be 
interested to hear why people seem to disregard that approach so lightly. I 
don't doubt that accurate type inference is a hard problem - Mark Dufour's 
thesis provides some level of confirmation of that - but I'm inclined to 
believe that there's a wide open space between today's Python and ubiquitous 
type declarations that could hold a more appropriate solution.

[...]

> from t_types import t
> 
> @t.signature(t.int|t.None, returns=t.int)
> def test43(foo=None):
>    if None is 1:
>      # should be dead code
>      return ''
>    if 1 is None:
>      # should be dead code
>      return ''
>    if foo is None:
>      return 1
>    else:
>      # foo should have type of t.int here
>      return foo
> 
> @t.signature(returns=t.list[t.int])
> def test26():
>    x = []
>    x[0] = 1
>    return x

Stripping the import and decorators from this and running it through the 
analysis tools doesn't identify dead code, mostly because I haven't 
implemented optimisations for the identity operators in the way envisaged 
above (although it is done for isinstance calls), but it does tell you what 
the return types are, provided there are some calls to the above functions. 
Whilst that is almost like declaring the types, it is only necessary to 
provide usage of a function at the top of a "call hierarchy" - you wouldn't 
write an explicit call to test26 if such invocations already existed in other 
places.

Accurate prediction of the contents of things like lists can be hard, though, 
but instead of declaring such things everywhere, one thing I mentioned in my 
communications with Collin Winter was the possibility of "semantic" marking 
of such types: instead of stating list[int], or to take a more illustrative 
example, instead of stating list[Element|Text], you refer to an ElementList 
(possibly by subclassing list) and then have the inferencer work out that 
only Element and Text objects are ever stored in such objects. Shedskin 
manages to find such things out all by itself, but I'm not certain that it 
can always do so. Having some level of abstract type annotation, whilst not 
as nice as having the system work everything out by itself, is certainly 
better than the maintenance nightmare of going round adjusting type 
declarations upon a minor type-related modification to a program, however.

Paul

From guido at python.org  Sun May 21 01:23:37 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 20 May 2006 16:23:37 -0700
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <d11dcfba0605201343m423aca56v3f03a1a5159b49bb@mail.gmail.com>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>
	<d11dcfba0605201136r25d43a39y7bf2e21cb7ea1531@mail.gmail.com>
	<ca471dc20605201252u26c4ff5dkf98854e98bbd9dfa@mail.gmail.com>
	<d11dcfba0605201343m423aca56v3f03a1a5159b49bb@mail.gmail.com>
Message-ID: <ca471dc20605201623i66038e73l4e0402db5eb3246e@mail.gmail.com>

On 5/20/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> > You may have read my prototypes, which dispatch on concrete types.
> > Phillip lets you dispatch on predicates like hasattr(x, 'append').
>
> I assume you mean this one:
>     http://svn.python.org/projects/sandbox/trunk/Overload3K

No, I meant his Dispatch thing. It's somewhere on the PEAK website and
has been discussed here before.

> > Collin Winters is pretty real, and I believe one other person (Tony
> > Lownds?) has another.
>
> I wandered around
>     http://oakwinter.com/code/typecheck/
> but couldn't find any discussion about the implications of, say,
> requring the type ``{str:Number}`` (which I assume is basically
> equivalent to the dict[str, Number] in this discussion).  Does that
> mean that every access to the dict is checked?

That's for Collin to answer.

> I do like the idea of the TypeClass object, which basically infers an
> interface.  But I'd really like someone to discuss the performance
> implications somewhere.  Maybe it is and I just couldn't find it?

I expect performance is going to kill the wrapper approach, which is
why I'm at best lukewarm towards it.

> I guess in the end, I'm still a little confused at why we're having a
> syntax discussion now.  If type annotations are just an extra
> expression in a function definition, why does Python  core care about
> what syntax a system like Phillip's or Collin's chooses?  That is,
> isn't the ``dict[str, int]`` or ``{str: int}`` syntax decision just a
> decision for the ``typecheck`` or ``overloading`` module, and not for
> Python in general?

It is indeed up to the framework, not up to Python.

However we might as well give some guidance, and e.g. parameterized
types a la list[int] (or ImmutableSequence[Number]) is my proposal
*if* I were asked to design a sub-language for expression type
constraints.

Also, if we want IDEs to use this (e.g. for name completion) we should
have agreement on the syntax.

But if someone wants to use the annotation slot as a mini-docstring
for parameters, or to add a validation function for a web framework,
or whatever, they should be free to do so (as long as they don't care
about the IDE support, which so far is just a dream anyway).

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

From guido at python.org  Sun May 21 01:26:13 2006
From: guido at python.org (Guido van Rossum)
Date: Sat, 20 May 2006 16:26:13 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <446F8C3E.5000009@acm.org>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>
	<446F8C3E.5000009@acm.org>
Message-ID: <ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>

On 5/20/06, Talin <talin at acm.org> wrote:
> As far as how to pick the set of operators, well my notion on that was
> to come up with a list of general mathematical and logical concepts, and
> see if any would be useful as operators. In other words, the placeholder
> operators would have general meanings assigned to them, but not specific
> implementations.
>
> My train of thought was something like this: If you are planning on
> using the token '->' to indicate the return type of a function, then
> you're going to have to add that to the lexer; And once you do that, why
> not go the extra step and make it an operator?
>
> In this case, the meaning of the '->' operator is "derives" as in
> "derives/produces/yields/maps-to/etc." So the expression "f(a) -> b" is
> a statement that the operation of 'f(a)' yields a result of 'b'.
>
> (BTW, correct me if I am using the word 'derives' incorrectly. I'm
> specifically thinking of the meaning from the 'dragon book', but I may
> have it reversed.)
>
> The operator's magic method would be something like __derives__, and its
> actual implementation would depend on the context. So for a type system,
> you could say things like:
>
>     Function( int ) -> float
>
> Meaning 'a function that takes an int and produces a float'.
>
> Meanwhile, in an algebraic solver, you could say:
>
>     Var('x') + 0 -> Var('x')
>
> The 'Var' type overloads '+' operator to return an AST-like structure
> representing the addition of a variable and a constant zero; That
> structure in turn overloads the '->' operator to add generate a rule
> that says that adding 0 to a variable produces the same variable.
>
> (Now all I need is a friendly way to spell "Var('x')" and I'm all set.)
>
> One strange consequence of defining the expression 'a -> b' as 'a
> produces b' is how this applies to type declarations of dictionaries and
> lists. For dicts, there are two possible options:
>
>      dict[ str -> int ]
>      dict[ str ] -> int
>
> The first is saying that 'within the context of a dict, a str produces
> an int'. The second is saying 'the operation dict[ str ] produces an
> int." (The latter is more Haskell-ish)
>
> Both of those are fairly reasonable, but what happpens if we apply the
> same reasoning to lists:
>
>      list[ int -> int ]
>      list[ int ] -> int
>
> This is unecessarily verbose, because the first argument is always going
> to be an int (or some scalar number type). I suppose one way around this
> is to simply declare that for type-description purposes, lists are not
> treated as mappings.
>
> Another question that springs to mind is, what about the converse
> operator, '<-', and what does it represent? (Besides meaning "less than
> the negative of", which is a troubling ambiguity.) One possible meaning
> that could be assigned is "substitutes", and could be useful in grammar
> files, where the non-terminal is usually on the left. (Or you could
> simply make the BNF operator ::= a Python operator, but that's getting
> ridiculous, assuming that I haven't made myself ridiculous enough already.)

I suggest you let this rest for now. We have plenty of existing
operators, and I'd rather wait for a more compelling reason to add
more.

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

From qrczak at knm.org.pl  Sun May 21 01:53:39 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sun, 21 May 2006 01:53:39 +0200
Subject: [Python-3000] Type parameterization
In-Reply-To: <446F8C3E.5000009@acm.org> (talin@acm.org's message of "Sat, 20
	May 2006 14:38:06 -0700")
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>
	<446F8C3E.5000009@acm.org>
Message-ID: <87wtcguubg.fsf@qrnik.zagroda>

Talin <talin at acm.org> writes:

> (Now all I need is a friendly way to spell "Var('x')" and I'm all set.)

var.x

> Another question that springs to mind is, what about the converse
> operator, '<-', and what does it represent? (Besides meaning "less
> than the negative of", which is a troubling ambiguity.)

Let's make use of the ambiguity - no need to change the current syntax:

func[int <- str, str]   # A function returning an int for two strings
dict[int <- str]        # A dictionary of ints mapped from strings

Joking.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From steven.bethard at gmail.com  Sun May 21 01:56:08 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sat, 20 May 2006 17:56:08 -0600
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <43aa6ff70605201407o2a003a54s8d888422d23d3e3f@mail.gmail.com>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>
	<d11dcfba0605201136r25d43a39y7bf2e21cb7ea1531@mail.gmail.com>
	<ca471dc20605201252u26c4ff5dkf98854e98bbd9dfa@mail.gmail.com>
	<d11dcfba0605201343m423aca56v3f03a1a5159b49bb@mail.gmail.com>
	<43aa6ff70605201407o2a003a54s8d888422d23d3e3f@mail.gmail.com>
Message-ID: <d11dcfba0605201656l1363776cqe9e87bffbcf0512@mail.gmail.com>

On 5/20/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/20/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > I wandered around
> >     http://oakwinter.com/code/typecheck/
> > but couldn't find any discussion about the implications of, say,
> > requring the type ``{str:Number}`` (which I assume is basically
> > equivalent to the dict[str, Number] in this discussion).  Does that
> > mean that every access to the dict is checked?
>
> {str: Number} is indeed my syntax for dict[str, Number] (I didn't have
> the luxury of messing with the built-ins ; )
>
> http://oakwinter.com/code/typecheck/tutorial/builtintypes.html in
> particular discusses what it means to say that an argument should be
> {str: Number}: namely, that all keys must be strs and all values
> should be Numbers. It also talks about tuples, lists and sets.

So I should read a sentence like "This will assert that all the keys
in the dictionary are strs and all values are Numbers." as being
equivalent to dropping in the following code before the function is
called:

    for key, value in dictobj.items():
        assert isinstance(key, str)
        # okay, well not isinstance, but something like it
        assert isinstance(value, Number)

Is that right?

FWIW, it wasn't clear to me if "asserts" was literally an assert
statement, and if it was, it wasn't clear whether the assert
statements were placed directly before the function call, or if they
were delayed (e.g. via wrapping __getitem__ and __setitem__) until the
point at which they were actually necessary.

> I haven't done any real performance analysis on my system. My focus so
> far has been getting things working the way I want, saving the
> performance issue for later.

Ahh, ok.  Thanks.

STeVe
-- 
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From steven.bethard at gmail.com  Sun May 21 02:00:34 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sat, 20 May 2006 18:00:34 -0600
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <ca471dc20605201623i66038e73l4e0402db5eb3246e@mail.gmail.com>
References: <d11dcfba0605192142v2d4734a0rff99c53068c48da4@mail.gmail.com>
	<ca471dc20605200804m150aabcbi997dd8f8bf776b90@mail.gmail.com>
	<d11dcfba0605201136r25d43a39y7bf2e21cb7ea1531@mail.gmail.com>
	<ca471dc20605201252u26c4ff5dkf98854e98bbd9dfa@mail.gmail.com>
	<d11dcfba0605201343m423aca56v3f03a1a5159b49bb@mail.gmail.com>
	<ca471dc20605201623i66038e73l4e0402db5eb3246e@mail.gmail.com>
Message-ID: <d11dcfba0605201700sc463abard0233c99b9de9f6b@mail.gmail.com>

On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> On 5/20/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > I guess in the end, I'm still a little confused at why we're having a
> > syntax discussion now.  If type annotations are just an extra
> > expression in a function definition, why does Python  core care about
> > what syntax a system like Phillip's or Collin's chooses?  That is,
> > isn't the ``dict[str, int]`` or ``{str: int}`` syntax decision just a
> > decision for the ``typecheck`` or ``overloading`` module, and not for
> > Python in general?
>
> It is indeed up to the framework, not up to Python.
>
> However we might as well give some guidance, and e.g. parameterized
> types a la list[int] (or ImmutableSequence[Number]) is my proposal
> *if* I were asked to design a sub-language for expression type
> constraints.
>
> Also, if we want IDEs to use this (e.g. for name completion) we should
> have agreement on the syntax.

So in the end, the goal of this discussion is something along the
lines of an informational PEP, ala the Database API or WSGI, that
would provide suggested guidelines for type annotation expressions.

Thanks for the clarification.  I think I'm going to re-read these
threads now. ;-)

STeVe
-- 
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From talin at acm.org  Sun May 21 02:10:25 2006
From: talin at acm.org (Talin)
Date: Sat, 20 May 2006 17:10:25 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
 annotating generators)
In-Reply-To: <ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>	
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>	
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>	
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>	
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>	
	<446E99B8.10500@acm.org>	
	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>	
	<446F8C3E.5000009@acm.org>
	<ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
Message-ID: <446FAFF1.3070503@acm.org>

Guido van Rossum wrote:
> On 5/20/06, Talin <talin at acm.org> wrote:
> 
>> As far as how to pick the set of operators, well my notion on that was
>> to come up with a list of general mathematical and logical concepts, and
>> see if any would be useful as operators. In other words, the placeholder
>> operators would have general meanings assigned to them, but not specific
>> implementations.
> 
> I suggest you let this rest for now. We have plenty of existing
> operators, and I'd rather wait for a more compelling reason to add
> more.

Resting is good.

-- Talin

From pje at telecommunity.com  Sun May 21 02:25:16 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 20 May 2006 20:25:16 -0400
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
 parameterization)
In-Reply-To: <mailman.22875.1148161094.27774.python-3000@python.org>
Message-ID: <5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com>

At 12:36 AM 5/20/2006 -0600, "Steven Bethard" <steven.bethard at gmail.com> wrote:

>On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> > I've already addressed Steve's other issues. The blogs have the use 
> cases etc.
>
>I'm sorry, I guess I'm just dense, but here's the blogs I've read:
>
>http://www.artima.com/weblogs/viewpost.jsp?thread=85551
>http://www.artima.com/weblogs/viewpost.jsp?thread=86641
>http://www.artima.com/weblogs/viewpost.jsp?thread=87182
>http://www.artima.com/weblogs/viewpost.jsp?thread=89161
>http://www.artima.com/weblogs/viewpost.jsp?thread=101605
>http://www.artima.com/weblogs/viewpost.jsp?thread=92662
>http://www.artima.com/weblogs/viewpost.jsp?thread=155123
>
>And the only use-cases I could extract are:
>
>* optional type checking.  Lots of thoughts here, and it seemed like
>most of the blogs were leaning towards introducing interfaces to avoid
>requiring concrete types.  But the discussion here has been using
>things like 'int' and 'str', so I'm confused as to whether or not this
>is still the intention.
>
>* function overloading[1].  I think Philip J. Eby had some interesting
>thoughts here, but in all the prototypes, dispatching was done on
>concrete types.

Not true.  See Overload3K in the sandbox, per my previous posts.


>   Is there a way to do function overloading that
>doesn't rule-out duck typing and is still reasonably efficient?

Yes; see my proof-of-concept.


>I guess, in general, my concerns about the use-cases I found were that:
>
>(1) there were very few real implementations of the ideas, and
>(2) where there was an implementation, it relied on concrete types
>
>Is it the intention that type annotations be used primarily to check
>concrete types?  Or maybe interfaces are being introduced so that type
>annotations can check them instead?  If so, I'd like to see one of the
>prototype systems using interfaces.

My overloading proof of concept can be trivially extended to use any kind 
of type checking you want - as long as the checking is of an object's 
*type*, rather than of the instance involved.  Just add overloads of the 
appropriate flavor for whatever thing you plan to check.

And you're not even limited to checks against types, as long as you're 
willing to pay the price in either decreased performance or increased 
implementation complexity.  RuleDispatch, for example, can dispatch on 
arbitrary runtime tests against literally anything you care to code.  It 
offers reasonable performance at the cost of greater implementation 
complexity.  But if you don't care about performance, you can of course do 
a much simpler implementation based on the Overload3K prototype, but that 
doesn't cache type information.

Anyway, the point is that argument annotations allow you to leverage any 
number of possible systems for dispatching or argument validation, not to 
create a blessed set of semantics for them.

Another relevant use case for type annotations, by the way, is to write 
code that interfaces with statically typed languages.  For example, Jython 
and IronPython could both benefit from being able to specify types to allow 
proper overloads from Java and C# (into Python).  Likewise, ctypes and 
Pyrex could benefit from CPython having better ways to specify types.

Indeed, any kind of interface that requires external marshalling 
potentially benefits.  For example, CORBA, COM, and other RPC or "remote 
object" systems can benefit from argument annotation.  Creating a UI 
framework like the "Naked Objects" system for Java and .NET would also benefit.

And these are just the use cases for argument annotations that I can think 
of on a moment's notice.


>   Or maybe there's some other way
>that type annotations are going to be used that doesn't rely on
>concrete types that I've just missed?
>
>Sorry to still not be getting it!

I'm confused as to why nobody seems to have noticed my proposal or 
prototype.  So far my speculation is that it's outside of most people's 
ability to perceive, because it moots all the things they're arguing 
about.  That is, it makes everything way too easy for anybody to pay 
attention to it.  :)


From ncoghlan at gmail.com  Sun May 21 03:07:10 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 21 May 2006 11:07:10 +1000
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
 annotating generators)
In-Reply-To: <fb6fbf560605191424j5f79b0f2xfa08f9ac5fd35a3a@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>	<fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>	<43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com>	<fb6fbf560605191346k75a0dce2wda1b674ab8c0afa8@mail.gmail.com>	<43aa6ff70605191408n274b7b37u6cc9ddea67106d16@mail.gmail.com>
	<fb6fbf560605191424j5f79b0f2xfa08f9ac5fd35a3a@mail.gmail.com>
Message-ID: <446FBD3E.1020006@gmail.com>

Jim Jewett wrote:
> On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
>> B.__parameterize__ will only be called in the case of B[x] (as opposed
>> to B()[x]).
> 
> new-style classes (the ones sticking around for python 3) are also instances.
> 
>     >>> isinstance(dict, type) and isinstance(dict, object)
>     True
> 
> How can the interpreter know which interpretation to use?

The same way the interpreter always resolves this question: type precedes 
object in the MRO, so the methods of type win. This already happens with 
__call__ - the idea is to extend it to __getitem__ as well.

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Sun May 21 03:09:54 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 21 May 2006 11:09:54 +1000
Subject: [Python-3000] Type parameterization
In-Reply-To: <fb6fbf560605191618x46deedabrb84a143c12b0aed4@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>	<43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com>	<ca471dc20605182200w2f8e4c57sf9bbe2d302518bd0@mail.gmail.com>	<43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com>	<fb6fbf560605191254m2b5a76a3p3fe26ddaa4a335bd@mail.gmail.com>	<43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com>	<fb6fbf560605191346k75a0dce2wda1b674ab8c0afa8@mail.gmail.com>	<87psi9zms6.fsf@qrnik.zagroda>
	<fb6fbf560605191618x46deedabrb84a143c12b0aed4@mail.gmail.com>
Message-ID: <446FBDE2.6050203@gmail.com>

Jim Jewett wrote:
> If the implementation of [] ends up doing the moral equivalent of
> 
>     (self.__getitem__(arg) if not isintance(self, type) else
> self.__parameterization__(arg))
> 
> then we're running into problems with
> 
>     If the implementation is hard to explain, it's a bad idea.

It's no more complicated than the difference between dict() and dict()(). The 
former works because it invokes type.__call__, the latter fails because it 
tries to invoke dict.__call__ (and fails to find it).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Sun May 21 03:27:37 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 21 May 2006 11:27:37 +1000
Subject: [Python-3000] Misc type annotation issues
In-Reply-To: <ca471dc20605200929p3d4c36b8xe6a67fe8a4bedc43@mail.gmail.com>
References: <43aa6ff70605200919i296a1ac5ib7cd687489e94c1d@mail.gmail.com>
	<ca471dc20605200929p3d4c36b8xe6a67fe8a4bedc43@mail.gmail.com>
Message-ID: <446FC209.8070009@gmail.com>

Guido van Rossum wrote:
> On 5/20/06, Collin Winter <collinw at gmail.com> wrote:
>> 3. What will annotations on *varargs and **varkw look like? My own
>> suggestion is that
>>
>>>>> def foo(a: <type>, *varargs: <type>, **varkw: <type>)
>> is fully equivalent to -- and is indeed coerced to --
>>
>>>>> def foo(a: <type>, *varargs: list[<type>], **varkw: dict[str, <type>])
>> What did you have in mind?
> 
> We can't allow both the shorthand and the full notation, since then
> there would be ambiguity: if "*args: int" meant the same as "*args:
> list[int]", then what if I want each of the remaining positional
> arguments to be a list of ints? "*args: list[int]" is already taken to
> mean that each of the remaining arguments is an int.
> 
> Since the full notation is unnecessarily verbose, I propose that
> "*args: T" means that each of the remaining arguments should be a T,
> and the type of args itself is list[T]. Similar for **kwds.

That last paragraph is actually the way I interpreted Collin's suggestion (due 
to the "coerced to" comment).

And I trust "*args : T" would actually map to a type annotation of tuple[T] 
for the args variable ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Sun May 21 03:59:26 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 21 May 2006 11:59:26 +1000
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>	<446D515B.8040802@gmx.net>	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
	<43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
Message-ID: <446FC97E.4030105@gmail.com>

Collin Winter wrote:
> On 5/19/06, Guido van Rossum <guido at python.org> wrote:
>> OK; for the return value (only) the Function().returns(<type>)
>> notation does look fairly pretty.
>>
>> I presume that return(int, int) is the same as return((int, int))?
> 
> It is.
> 
>> Weren't we going to write a tuple of two ints as tuple[int, int]
>> though? Is (int, int) now just an alias for that or does it have a
>> different meaing?
> 
> I think that returns() is smart enough to know that "returns((int,
> int))" is the same as "returns(int, int)". It will know to do
> something similar for "returns(tuple[int, int])".

Assume the following is true for a type annotation system:
   (T,) is equivalent to tuple[T]
   (T1, T2) is equivalent to tuple[T1, T2]
   (T1, T2, T3) is equivalent to tuple[T1, T2, T3]

This fits in with how tuples are typically intended to be used (small 
collections of heterogeneous data), but how do I use this system to spell the 
type annotation for a tuple of unknown length containing only T instances?

I'd say "that's what lists are for", except that the CPython core uses tuples 
as homogeneous containers of unknown length in several places. For example, 
the sequence used to hold the additional arguments to a function is a tuple. 
So I would expect the type annotation in "*args : T" to be implicitly 
translated to "tuple[T]". Similarly, I would expect the type description for 
both __mro__ and __bases__ to be "tuple[type]".

This contradicts the original assumption above, suggesting that a type 
description for a tuple and a tuple of type descriptions should not be 
considered equivalent.

With such a mechanism, "T1, T2" would be a type description for a 2-tuple, 
while "tuple[T1, T2]" would be a type description for an arbitrary length 
tuple of 2-tuples.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From oliphant.travis at ieee.org  Sun May 21 06:59:52 2006
From: oliphant.travis at ieee.org (Travis E. Oliphant)
Date: Sat, 20 May 2006 22:59:52 -0600
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
 annotating generators)
In-Reply-To: <ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>	<446E99B8.10500@acm.org>	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>	<446F8C3E.5000009@acm.org>
	<ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
Message-ID: <e4os4a$96v$1@sea.gmane.org>

Guido van Rossum wrote:
> On 5/20/06, Talin <talin at acm.org> wrote:
>> As far as how to pick the set of operators, well my notion on that was
> 
> I suggest you let this rest for now. We have plenty of existing
> operators, and I'd rather wait for a more compelling reason to add
> more.
> 

I'm sorry to interrupt the resting, but I just wanted to remind 
everybody that Numerical computing people would still like a way to 
distinguish between "element-by-element" multiplication and tensor 
contraction (matrix multiplication).  A new operator could definitely 
help the situation.

The existing dance between matrix objects and array objects to reuse the 
single "*" operator can get confusing.

-Travis



From greg.ewing at canterbury.ac.nz  Sun May 21 08:42:09 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 21 May 2006 18:42:09 +1200
Subject: [Python-3000] Type parameterization
In-Reply-To: <e4os4a$96v$1@sea.gmane.org>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>
	<446F8C3E.5000009@acm.org>
	<ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
	<e4os4a$96v$1@sea.gmane.org>
Message-ID: <44700BC1.9080302@canterbury.ac.nz>

Travis E. Oliphant wrote:

> I'm sorry to interrupt the resting, but I just wanted to remind 
> everybody that Numerical computing people would still like a way to 
> distinguish between "element-by-element" multiplication and tensor 
> contraction (matrix multiplication).

A while back, there was talk of adding @ as a matrix
multiplication operator. What's the thought on that
nowadays?

Note that this wouldn't come under the head of an
"undefined operator", because it would be implemented
in the core as doing matrix multiplication on sequences
of sequences.

--
Greg

From greg.ewing at canterbury.ac.nz  Sun May 21 08:42:19 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 21 May 2006 18:42:19 +1200
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <446FC97E.4030105@gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
	<43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
	<446FC97E.4030105@gmail.com>
Message-ID: <44700BCB.8000000@canterbury.ac.nz>

Nick Coghlan wrote:

> Assume the following is true for a type annotation system:
>    (T,) is equivalent to tuple[T]
>    (T1, T2) is equivalent to tuple[T1, T2]
>    (T1, T2, T3) is equivalent to tuple[T1, T2, T3]
> 
> but how do I use this system to spell the 
> type annotation for a tuple of unknown length containing only T instances?

   tuple[T, ...]

There wouldn't be any () equivalent, unless ... were made
a generally-available expression, in which case you could use

   (T, ...)

--
Greg

From greg.ewing at canterbury.ac.nz  Sun May 21 08:54:14 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 21 May 2006 18:54:14 +1200
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <ca471dc20605182356kfb5b446i15c268f5239580cf@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<446D5F89.2080504@gmx.net>
	<ca471dc20605182356kfb5b446i15c268f5239580cf@mail.gmail.com>
Message-ID: <44700E96.6050302@canterbury.ac.nz>

Guido van Rossum wrote:

> I guess by "algebraic types" you meant enumerated types?

An algebraic type is somewhat more than that -- think
of it as something like a tagged tuple.

A less degenerate example would be (using a more
Haskell-like syntax):

   Tree t = Leaf t | Node (Tree t) (Tree t)

This says that a Tree of items of type t is either a
Leaf containing something of type t, or a Node containing
two other things of type Tree of t.

Leaf and Node can then be used as functions that construct
data items, e.g.

   let x = Node (Leaf 1) (Node (Leaf 2) (Leaf 3))

An equivalent Python data structure might be something like

   x = ('Node', ('Leaf', 1), ('Node', ('Leaf', 2), ('Leaf', 3)))

Which wouldn't be all that useful unless you could to
Haskell-style pattern matching on it as well. So you're
probably right that algebraic types don't really belong
in Python.

--
Greg

From ncoghlan at gmail.com  Sun May 21 09:00:28 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 21 May 2006 17:00:28 +1000
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <44700BCB.8000000@canterbury.ac.nz>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
	<43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
	<446FC97E.4030105@gmail.com> <44700BCB.8000000@canterbury.ac.nz>
Message-ID: <4470100C.30405@gmail.com>

Greg Ewing wrote:
> Nick Coghlan wrote:
> 
>> Assume the following is true for a type annotation system:
>>    (T,) is equivalent to tuple[T]
>>    (T1, T2) is equivalent to tuple[T1, T2]
>>    (T1, T2, T3) is equivalent to tuple[T1, T2, T3]
>>
>> but how do I use this system to spell the type annotation for a tuple 
>> of unknown length containing only T instances?
> 
>   tuple[T, ...]

That looks more like "the first item is a T, the rest can be anything" to me, 
though. Slice notation might work:
     tuple[T:]

(Although Guido was cool towards a similar idea to use slice notation for 
mapping type descriptions)

> There wouldn't be any () equivalent, unless ... were made
> a generally-available expression, in which case you could use
> 
>   (T, ...)

I guess what I'm really asking is whether or not we should go to any 
significant effort to preserve two ways of saying the same thing. Since we 
plan to be able use tuples of type descriptions to describe heterogeneous 
tuples, why not use the tuple[T] notation to describe homogeneous tuples?

Then we can allow *args to be annotated normally, as sometimes it is used to 
accept a homogeneous tuple of arbitrary length, and other times is used to 
accept positional-only arguments to a function that accepts arbitrary 
keyword-only arguments (e.g. implementing methods in Python with signatures 
matching those of the dict constructor and update method).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Sun May 21 09:51:31 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 21 May 2006 17:51:31 +1000
Subject: [Python-3000] What makes infix operators special? (was Re: Type
 parameterization (was: Re: Type annotations: annotating generators))
In-Reply-To: <e4os4a$96v$1@sea.gmane.org>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>	<446E99B8.10500@acm.org>	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>	<446F8C3E.5000009@acm.org>	<ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
	<e4os4a$96v$1@sea.gmane.org>
Message-ID: <44701C03.9040407@gmail.com>

Travis E. Oliphant wrote:
> Guido van Rossum wrote:
>> On 5/20/06, Talin <talin at acm.org> wrote:
>>> As far as how to pick the set of operators, well my notion on that was
>> I suggest you let this rest for now. We have plenty of existing
>> operators, and I'd rather wait for a more compelling reason to add
>> more.
>>
> 
> I'm sorry to interrupt the resting, but I just wanted to remind 
> everybody that Numerical computing people would still like a way to 
> distinguish between "element-by-element" multiplication and tensor 
> contraction (matrix multiplication).  A new operator could definitely 
> help the situation.
> 
> The existing dance between matrix objects and array objects to reuse the 
> single "*" operator can get confusing.

<This is a rambling thinking-out-loud kind of post. You have been warned ;)>

Something I've occasionally wondered about is just what it is that makes 
operators so much more convenient than methods or builtin functions for some 
operations.

The first benefit is the obvious one: they're a concise mnemonic for 
operations that may otherwise require a long method name in order to be clear 
(compare A.symmetric_difference(B) with A ^ B for sets). A related aspect is 
the ability to avoid repeating yourself for in-place operations (A ^= B 
instead of A = A.symmetric_difference(B)).

The second benefit I see is that operators embody a standard form of 
type-based dispatch used to implement support for mixed-type operations (the 
dance with special methods that return NotImplemented).

The latter benefit is a question of semantics, while the former is a question 
of syntax. I think both are important, but that it's the syntactic one that is 
the real driver for use of operator overloading. (NumPy's ufuncs appear to 
based on the idea of providing the semantic benefit for additional operations 
without syntactic support).

In the mathematical world of scalars and matrices, we have element-by-element 
multiplication, matrix multiplication, the vector scalar product and the 
vector cross product all competing for the same standard operator ('*').

Using '@' would now be fairly counterintuitive, given that symbol's 
association with decorators.

The doubling trick used to separate true division from integer division isn't 
available, since the doubled operator '**' is already used for exponentiation.

I wonder if something could be done with the idea of using additional symbol 
pairs for operators. Then something like '*.' could added for the vector 
scalar product (aka the dot product), and '*~' could be added for matrix 
multiplication. It might even be possible to permit '/%' for divmod.

However, I also wonder if that way lies madness ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From qrczak at knm.org.pl  Sun May 21 11:15:29 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sun, 21 May 2006 11:15:29 +0200
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <446FC97E.4030105@gmail.com> (Nick Coghlan's message of "Sun,
	21 May 2006 11:59:26 +1000")
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<446D515B.8040802@gmx.net>
	<ca471dc20605182207u7bd0ce49x7677ad7a492d3bf4@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
	<43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
	<446FC97E.4030105@gmail.com>
Message-ID: <87odxrpwlq.fsf@qrnik.zagroda>

Nick Coghlan <ncoghlan at gmail.com> writes:

> Assume the following is true for a type annotation system:
>    (T,) is equivalent to tuple[T]
>    (T1, T2) is equivalent to tuple[T1, T2]
>    (T1, T2, T3) is equivalent to tuple[T1, T2, T3]

This is ambiguous: tuple[T1, T2] is the same as tuple[(T1, T2)],
i.e. it's a 1-tuple containing a 2-tuple.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From greg.ewing at canterbury.ac.nz  Sun May 21 12:29:51 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 21 May 2006 22:29:51 +1200
Subject: [Python-3000] What makes infix operators special? (was Re: Type
 parameterization
In-Reply-To: <44701C03.9040407@gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>
	<446F8C3E.5000009@acm.org>
	<ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
	<e4os4a$96v$1@sea.gmane.org> <44701C03.9040407@gmail.com>
Message-ID: <4470411F.2040606@canterbury.ac.nz>

Nick Coghlan wrote:

> Using '@' would now be fairly counterintuitive, given that symbol's 
> association with decorators.

It would be very disappointing if @ were now considered
too "polluted" by association with decorators to be used
for anything else, since it would mean we have lost both
a potential prefix operator and a potential infix operator
in one go.

Personally I don't think there would be any confusion.

> I wonder if something could be done with the idea of using additional symbol 
> pairs for operators. Then something like '*.' could added for the vector 
> scalar product (aka the dot product), and '*~' could be added for matrix 
> multiplication.

No, no, please, no!!! Things like this were debated at
length last time round, and were found to be extremely
ugly and hard to read.

> However, I also wonder if that way lies madness ;)

Indeed, it does. Even brief exposure to expressions
containing *. operators has been found to cause severe
mental derangement in laboratory rats. We don't want
to go there.

--
Greg

From p.f.moore at gmail.com  Sun May 21 15:44:13 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 21 May 2006 14:44:13 +0100
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
	parameterization)
In-Reply-To: <5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com>
References: <mailman.22875.1148161094.27774.python-3000@python.org>
	<5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com>
Message-ID: <79990c6b0605210644h585a6294r43fcca10697e07b5@mail.gmail.com>

On 5/21/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> I'm confused as to why nobody seems to have noticed my proposal or
> prototype.  So far my speculation is that it's outside of most people's
> ability to perceive, because it moots all the things they're arguing
> about.  That is, it makes everything way too easy for anybody to pay
> attention to it.  :)

Possibly because there were a number of prototypes around at the time,
with varying capabilities? It was pretty hard to keep track of which
was which, and this one obviously slipped through the cracks (that's
certainly true for me - possibly I assumed your comments referred to
RuleDispatch, rather than a new prototype).

My feeling is that the whole generic function discussion lost momentum
at the point where it became clear that:

(a) Simple implementations weren't too hard to build as library code, and
(b) Using them pervasively was a significant paradigm shift, and
people weren't sure about that.

Maybe just having a single "blessed" implementation of a function
overloading module in the stdlib (even in the 2.x series) would be the
best place to start. With a bit more real-world experience, it would
be easier to see if there was call for integrating the concept more
deeply into the core.

Paul

From thomas at python.org  Sun May 21 16:20:33 2006
From: thomas at python.org (Thomas Wouters)
Date: Sun, 21 May 2006 16:20:33 +0200
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <446FAFF1.3070503@acm.org>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>
	<446F8C3E.5000009@acm.org>
	<ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
	<446FAFF1.3070503@acm.org>
Message-ID: <9e804ac0605210720n60f896d1seece6bbeca6245bf@mail.gmail.com>

On 5/21/06, Talin <talin at acm.org> wrote:
>
> Guido van Rossum wrote:
> > We have plenty of existing operators, and I'd rather wait for a more
> compelling reason to
>
> add more.
>
> Resting is good.


http://www.python.org/peps/pep-0211.html
http://www.python.org/peps/pep-0225.html

"No no, 'e's not dead, 'e's, 'e's restin'". But they do have beautiful
plumage.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060521/278b245f/attachment.html 

From guido at python.org  Sun May 21 17:31:53 2006
From: guido at python.org (Guido van Rossum)
Date: Sun, 21 May 2006 08:31:53 -0700
Subject: [Python-3000] What makes infix operators special? (was Re: Type
	parameterization (was: Re: Type annotations: annotating generators))
In-Reply-To: <44701C03.9040407@gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>
	<446F8C3E.5000009@acm.org>
	<ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
	<e4os4a$96v$1@sea.gmane.org> <44701C03.9040407@gmail.com>
Message-ID: <ca471dc20605210831o4dfba47fl93fd3ee06434eb37@mail.gmail.com>

On 5/21/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Something I've occasionally wondered about is just what it is that makes
> operators so much more convenient than methods or builtin functions for some
> operations.

Lambert Meertens, ABC's primary author, once explained this to me in a
way that made sense to me.

Some of the oldest operators (in the history of
arithmetic/mathematics) are + and * (or whatever multiplication
operator was first). These operators are associative: (a+b)+c ==
a+(b+c). There's also  distributive law: a*(b+c) == a*b + a*c. And of
course they are symmetric: a+b == b+a. Properties like that *visually*
(at least this is Lambert's theory) help you see equivalences when
doing mathematical proofs much easier than when you limit yourself to
functional notations.

(This might also explain why unary operators are relatively scarce;
they don't have any of these properties so they don't buy you as
much.)

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

From pje at telecommunity.com  Sun May 21 18:32:38 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 21 May 2006 12:32:38 -0400
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
 parameterization)
In-Reply-To: <79990c6b0605210644h585a6294r43fcca10697e07b5@mail.gmail.co
 m>
References: <5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com>
	<mailman.22875.1148161094.27774.python-3000@python.org>
	<5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060521122116.01f631a0@mail.telecommunity.com>

At 02:44 PM 5/21/2006 +0100, Paul Moore wrote:
>Maybe just having a single "blessed" implementation of a function
>overloading module in the stdlib (even in the 2.x series) would be the
>best place to start. With a bit more real-world experience, it would
>be easier to see if there was call for integrating the concept more
>deeply into the core.

2.5 actually includes a single-dispatch overloading function already, 
although it's internal to pkgutil and not exposed for anything else to use.

The Overload3K prototype was mainly intended to promote:

1. having a "defop" keyword to allow anonymous overloading using argument 
annotations

2. having an extensible builtin overload() that's able to:
    a) overload builtins using Python's existing method dispatch machinery
    b) overload any other type you want to use as an "overloaded function"
       (so that advanced or specialized implementations are still first class)

3. having one or more extensible 'implies()' functions that can be shared 
by overloaded function implementations and thus extended to allow new kinds 
of argument criteria.

4. having a standard protocol for introspecting the methods available in 
overloaded functions, so that overloaded functions *themselves* can be used 
as simple typeclasses or interfaces.  (That way, you could define something 
like 'def join(sep:str, seq:iter)' and have the 'seq' argument accept any 
type that implements __iter__.)


From pje at telecommunity.com  Sun May 21 18:41:59 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 21 May 2006 12:41:59 -0400
Subject: [Python-3000] Use cases for type annotations? (WAS: Type
 parameterization)
In-Reply-To: <d11dcfba0605201951i54d93591uca5691f92d40c899@mail.gmail.co
 m>
References: <5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com>
	<mailman.22875.1148161094.27774.python-3000@python.org>
	<5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060521123359.01f5da30@mail.telecommunity.com>

At 08:51 PM 5/20/2006 -0600, Steven Bethard wrote:
>I'd particularly be interested in an example where overloading
>implies() to do something other than issubclass comparisons solves a
>real problem.

The prototype overloads implies() to allow a generic function to imply any 
type that can be passed to the generic function.

The flatten() example then uses this by defining a dummy 'iter()' generic 
function.

RuleDispatch is of course another example; it has its own 'implies()' 
protocol that is used in basically the same way.  Of course, it has lots of 
types that implement implies(), since it supports isinstance(), 
issubclass(), comparison operators, object identity checks, etc.  So 
anything that people use RuleDispatch for is essentially a "real problem" 
being solved by overloading of implies().

The Overload3K implementation is a restricted subset of what RuleDispatch 
does, in that Overload3K never performs tests directly on arguments, only 
on the arguments' types.  However, a RuleDispatch implementation based on 
Overload3K could still use the same implies() function that Overload3K 
does, albeit only for inter-signature priority comparisons.

Anyway, the main thrust of the prototype was to answer the then-current 
discussion about interfaces and typeclasses and the like.  I wanted to show 
that an open-ended system (based on the 4 concepts in my post immediately 
previous to this one) would allow interfaces, typeclasses, or whatever the 
heck else people want, to be implemented through a common base system that 
would also be extensible to full predicate dispatching for people who want 
that.


From collinw at gmail.com  Sun May 21 20:23:51 2006
From: collinw at gmail.com (Collin Winter)
Date: Sun, 21 May 2006 14:23:51 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <446FC97E.4030105@gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
	<43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
	<446FC97E.4030105@gmail.com>
Message-ID: <43aa6ff70605211123v4a5b55aer19f305a780947e42@mail.gmail.com>

On 5/20/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Assume the following is true for a type annotation system:
>    (T,) is equivalent to tuple[T]
>    (T1, T2) is equivalent to tuple[T1, T2]
>    (T1, T2, T3) is equivalent to tuple[T1, T2, T3]
>
> This fits in with how tuples are typically intended to be used (small
> collections of heterogeneous data), but how do I use this system to spell the
> type annotation for a tuple of unknown length containing only T instances?
>
> I'd say "that's what lists are for", except that the CPython core uses tuples
> as homogeneous containers of unknown length in several places. For example,
> the sequence used to hold the additional arguments to a function is a tuple.
> So I would expect the type annotation in "*args : T" to be implicitly
> translated to "tuple[T]". Similarly, I would expect the type description for
> both __mro__ and __bases__ to be "tuple[type]".

This is something I've been meaning to bring up: if we're serious
about the "tuples = fixed-length collections, lists = unknown-length
collections" distinction, then the CPython core should switch over to
this mindset as well. The fact that Python 2.x uses a tuple for
*varargs has caused me to jump through a number of hoops in my own
typecheck package.

If there's interest, I can put together a separate PEP on this issue
that lists all the places where tuples would need to be changed to
lists.

Collin Winter

From collinw at gmail.com  Sun May 21 20:33:34 2006
From: collinw at gmail.com (Collin Winter)
Date: Sun, 21 May 2006 14:33:34 -0400
Subject: [Python-3000] Mixing annotations and non-annotations
Message-ID: <43aa6ff70605211133p4d4804dcjabf8141679411b1b@mail.gmail.com>

On 5/21/06, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> Nick Coghlan <ncoghlan at gmail.com> writes:
>
> > Assume the following is true for a type annotation system:
> >    (T,) is equivalent to tuple[T]
> >    (T1, T2) is equivalent to tuple[T1, T2]
> >    (T1, T2, T3) is equivalent to tuple[T1, T2, T3]
>
> This is ambiguous: tuple[T1, T2] is the same as tuple[(T1, T2)],
> i.e. it's a 1-tuple containing a 2-tuple.

tuple[T1, T2] a 2-tuple with element 1 of type T1 and element 2 of
type T2. A 1-tuple containing a 2-tuple would be tuple[tuple[T1, T2]].

However, we still need to decide what happens in the case of
tuple[(T1, T2)]. Is the (T1, T2) coerced to tuple[T1, T2]?

My vote is "yes", but I don't have a full idea of how this coercion
would work. One solution would be to let the metaclass (the one that
catches the __getitem__ call on, e.g., tuple) automatically convert
non-annotations (using a to-be-decided test for annotation-ness) to
annotations. Something like this on the metaclass might do the trick
(based on Guido's metaclass sketch):

def __getitem__(self, arg):
       newcls = self.__class__(self.__name__, (self,), {})
       newcls.T = arg if is_annotation(arg) else type(arg)[arg]
       return newcls

Collin Winter

From edloper at gradient.cis.upenn.edu  Sun May 21 20:51:57 2006
From: edloper at gradient.cis.upenn.edu (Edward Loper)
Date: Sun, 21 May 2006 14:51:57 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605211123v4a5b55aer19f305a780947e42@mail.gmail.com>
References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com>
	<43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
	<43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
	<446FC97E.4030105@gmail.com>
	<43aa6ff70605211123v4a5b55aer19f305a780947e42@mail.gmail.com>
Message-ID: <04B77647-6812-47CD-B396-BC41DDEA6E6A@gradient.cis.upenn.edu>

On May 21, 2006, at 2:23 PM, Collin Winter wrote:
> This is something I've been meaning to bring up: if we're serious
> about the "tuples = fixed-length collections, lists = unknown-length
> collections" distinction, then the CPython core should switch over to
> this mindset as well.

Although lists are *often* used for unknown-length ordered homogenous  
collections, and tuples are *often* used for fixed-length  
heterogeneous collections, I think it would be a mistake to try to  
define them this way.  In particular, there is at least one other  
important difference between tuples and lists: mutability.  If you  
need to use an unknown-length sequence as a key, then it's very  
natural to use a tuple.  And if you want a fixed-length heterogeneous  
collection that's mutable, then it's natural to use a list.

-Edward


From qrczak at knm.org.pl  Sun May 21 21:05:13 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Sun, 21 May 2006 21:05:13 +0200
Subject: [Python-3000] Mixing annotations and non-annotations
In-Reply-To: <43aa6ff70605211133p4d4804dcjabf8141679411b1b@mail.gmail.com>
	(Collin Winter's message of "Sun, 21 May 2006 14:33:34 -0400")
References: <43aa6ff70605211133p4d4804dcjabf8141679411b1b@mail.gmail.com>
Message-ID: <871wunxkpi.fsf@qrnik.zagroda>

"Collin Winter" <collinw at gmail.com> writes:

>> > Assume the following is true for a type annotation system:
>> >    (T,) is equivalent to tuple[T]
>> >    (T1, T2) is equivalent to tuple[T1, T2]
>> >    (T1, T2, T3) is equivalent to tuple[T1, T2, T3]
>>
>> This is ambiguous: tuple[T1, T2] is the same as tuple[(T1, T2)],
>> i.e. it's a 1-tuple containing a 2-tuple.
>
> tuple[T1, T2] a 2-tuple with element 1 of type T1 and element 2 of
> type T2. A 1-tuple containing a 2-tuple would be tuple[tuple[T1, T2]].

If tuple[T1, T2] and (T1, T2) are equivalent when interpreted as
annotations, then a 1-tuple containing a 2-tuple can also be written
tuple[(T1, T2)].

But this is already equivalent to tuple[T1, T2] on a more fundamental
level than interpreting values as annotations. Both call __getitem__
with a 2-tuple as the argument, they evaluate to the same value no
matter how __getitem__ is implemented.

Different annotations can be interpreted as the same thing, but the
same annotation can't be interpreted differently depending on
distinctions which have been lost during parsing.

So the following assumptions are mutually contradictory when
considered together, something must be taken away:

- obj[i, j] means obj.__getitem__((i, j)), as today
- annotations are evaluated as expressions
- annotations tuple[T1, T2] and (T1, T2) are equivalent

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From aahz at pythoncraft.com  Sun May 21 21:53:11 2006
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 21 May 2006 12:53:11 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605211123v4a5b55aer19f305a780947e42@mail.gmail.com>
References: <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191010x7a1fb826g92f161701b6aa5d9@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
	<43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
	<446FC97E.4030105@gmail.com>
	<43aa6ff70605211123v4a5b55aer19f305a780947e42@mail.gmail.com>
Message-ID: <20060521195311.GB7756@panix.com>

On Sun, May 21, 2006, Collin Winter wrote:
>
> This is something I've been meaning to bring up: if we're serious
> about the "tuples = fixed-length collections, lists = unknown-length
> collections" distinction, then the CPython core should switch over to
> this mindset as well. The fact that Python 2.x uses a tuple for
> *varargs has caused me to jump through a number of hoops in my own
> typecheck package.

This is a guideline, not a rule, and the speed and size of tuples make
them more appropriate for varargs.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"I saw `cout' being shifted "Hello world" times to the left and stopped
right there."  --Steve Gonedes

From collinw at gmail.com  Sun May 21 22:23:35 2006
From: collinw at gmail.com (Collin Winter)
Date: Sun, 21 May 2006 16:23:35 -0400
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <20060521195311.GB7756@panix.com>
References: <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
	<43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
	<446FC97E.4030105@gmail.com>
	<43aa6ff70605211123v4a5b55aer19f305a780947e42@mail.gmail.com>
	<20060521195311.GB7756@panix.com>
Message-ID: <43aa6ff70605211323u13829017s7851680a5c8dd349@mail.gmail.com>

On 5/21/06, Aahz <aahz at pythoncraft.com> wrote:
> On Sun, May 21, 2006, Collin Winter wrote:
> >
> > This is something I've been meaning to bring up: if we're serious
> > about the "tuples = fixed-length collections, lists = unknown-length
> > collections" distinction, then the CPython core should switch over to
> > this mindset as well. The fact that Python 2.x uses a tuple for
> > *varargs has caused me to jump through a number of hoops in my own
> > typecheck package.
>
> This is a guideline, not a rule, and the speed and size of tuples make
> them more appropriate for varargs.

Honest question: what is so special about *varargs that demands
tuple's speed and size characteristics?

Collin Winter

From guido at python.org  Sun May 21 23:25:02 2006
From: guido at python.org (Guido van Rossum)
Date: Sun, 21 May 2006 14:25:02 -0700
Subject: [Python-3000] Type annotations: annotating generators
In-Reply-To: <43aa6ff70605211323u13829017s7851680a5c8dd349@mail.gmail.com>
References: <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com>
	<ca471dc20605191333t25d4b5eag22e86ea0033fee39@mail.gmail.com>
	<43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com>
	<43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com>
	<ca471dc20605192025p7758aa5bl49315949b40964cd@mail.gmail.com>
	<43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com>
	<446FC97E.4030105@gmail.com>
	<43aa6ff70605211123v4a5b55aer19f305a780947e42@mail.gmail.com>
	<20060521195311.GB7756@panix.com>
	<43aa6ff70605211323u13829017s7851680a5c8dd349@mail.gmail.com>
Message-ID: <ca471dc20605211425i76125accjd70ea1e00c6802ec@mail.gmail.com>

On 5/21/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/21/06, Aahz <aahz at pythoncraft.com> wrote:
> > On Sun, May 21, 2006, Collin Winter wrote:
> > >
> > > This is something I've been meaning to bring up: if we're serious
> > > about the "tuples = fixed-length collections, lists = unknown-length
> > > collections" distinction, then the CPython core should switch over to
> > > this mindset as well. The fact that Python 2.x uses a tuple for
> > > *varargs has caused me to jump through a number of hoops in my own
> > > typecheck package.
> >
> > This is a guideline, not a rule, and the speed and size of tuples make
> > them more appropriate for varargs.
>
> Honest question: what is so special about *varargs that demands
> tuple's speed and size characteristics?

I'm not sure -- it might depend on the application.

But I can shed some light on this like no-one else... :-)

It's mostly a historical accident. A very early version of Python
didn't have *varargs, but had a different feature: f(a, b, c) was
equivalent to f((a, b, c)). Also, def f(a, b, c) was equivalent to
today's def f((a, b, c)). This was all borrowed from ABC (which went
one step further -- f a was equivalent to f(a); but I didn't like that
enough to copy it). The idea was that a function really had only one
argument, and that multiple arguments were simulated by passing a
tuple -- just like what we still do for return values. A varargs
function was then declared with a single argument and called with
multiple ones. For example, this was a common idiom for a varargs
method:

  def foo(args):
      self, args = args[0], args[1:]
      ...

It was a bit trickier to write code that would also handle the case
where there were zero args -- because then the single argument wasn't
turned into a tuple!

The realization that this was a common use case made me change it all
around, to the current model. (I think keyword arguments and default
values came a bit later.)

The conclusion to draw from this history lesson is that the
interpretation of an argument list as a tuple was logical in the
original version, since syntactically it *was* a tuple (except in
f(a), where it *wasn't* -- just like (a, b) is a tuple but (a) isn't).
Tuples ended up significantly in the implementation as a result of the
early version, and the rewrite didn't remove them, since all C code
was also expecting tuples and I didn't want to have to change that --
except there was also C code that expected that a *single* argument
was *not* passed as a tuple, and for the longest times there were
hacks to work around that expectation: track the history of
PyArg_Parse and friends.

Nowadays the implementation contains a variety of hacks to *avoid*
creating tuples during a call -- since the arguments are present on
the caller's stack in the right order, it's often easier to present
the callee (at the C level) with a count and a pointer to an array of
objects. But since *args historically returned a tuple, if it is
present, a tuple is created.

Since **kwds is already a dict (i.e. a mutable container) and since we
long accept a list for *vargs on the call side, I think it is actually
more logical to use a list for receiving *args.

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

From talin at acm.org  Mon May 22 09:33:20 2006
From: talin at acm.org (Talin)
Date: Mon, 22 May 2006 00:33:20 -0700
Subject: [Python-3000] stdlib reorganization
Message-ID: <44716940.9000300@acm.org>

The 3100 PEP has an item which states "Reorganize the standard library 
to not be as shallow". I presume that there are already numerous 
proposals for a new library organization; Is there a list of links that 
someone can post so that I could check them out? Thanks.

-- Talin

From collinw at gmail.com  Mon May 22 17:56:45 2006
From: collinw at gmail.com (Collin Winter)
Date: Mon, 22 May 2006 11:56:45 -0400
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
	annotating generators)
Message-ID: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>

On 5/21/06, Guido van Rossum <guido at python.org> wrote:
> Since **kwds is already a dict (i.e. a mutable container) and since we
> long accept a list for *vargs on the call side, I think it is actually
> more logical to use a list for receiving *args.

I've started working on patches against the p3yk branch (side note:
could someone please do an 'svn mv p3yk py3k' to fix that name?) to
implement this change.

One thing I've run into several times in this process is the use of
*args as a dict key. As several others have mentioned, the "tuple ==
fixed-length, list == arbitrary-length" distinction means we now need
a way to create hashable lists. I propose a new, hashable frozenlist
built-in type to fill this niche.

This type would subclass from list, overriding __getitem__,
__delitem__, __hash__ and other methods as appropriate.

Thoughts? Does this need to go through a full PEP process?

Collin Winter

From brett at python.org  Mon May 22 18:07:02 2006
From: brett at python.org (Brett Cannon)
Date: Mon, 22 May 2006 09:07:02 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <44716940.9000300@acm.org>
References: <44716940.9000300@acm.org>
Message-ID: <bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>

On 5/22/06, Talin <talin at acm.org> wrote:
>
> The 3100 PEP has an item which states "Reorganize the standard library
> to not be as shallow". I presume that there are already numerous
> proposals for a new library organization; Is there a list of links that
> someone can post so that I could check them out? Thanks.



Actually, there aren't any real proposals.  =)

I tried bringing up the topic earlier this year shortly after Python 3000
discussion took off, and everyone said to hold off for a while on that
topic.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060522/cea7e438/attachment.htm 

From solipsis at pitrou.net  Mon May 22 18:29:28 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 22 May 2006 18:29:28 +0200
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
References: <44716940.9000300@acm.org>
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
Message-ID: <1148315368.19392.4.camel@fsol>

Le lundi 22 mai 2006 ? 09:07 -0700, Brett Cannon a ?crit :
> Actually, there aren't any real proposals.  =)
> 
> I tried bringing up the topic earlier this year shortly after Python
> 3000 discussion took off, and everyone said to hold off for a while on
> that topic. 

Perhaps a wiki page somewhere could list all the issues people have with
the current stdlib ?

For example, one common annoyance IMO is naming: why "urllib" or
"httplib"? If I import something, it's obvious it's a lib, so "import
http" would seem sufficient. There are also inconsistencies in casing
("StringIO, "cPickle", etc.), unnecessary distinctions ("thread" vs.
"threading")...

Regards

Antoine.



From guido at python.org  Mon May 22 18:36:29 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 22 May 2006 09:36:29 -0700
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
Message-ID: <ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>

On 5/22/06, Collin Winter <collinw at gmail.com> wrote:
> One thing I've run into several times in this process is the use of
> *args as a dict key. As several others have mentioned, the "tuple ==
> fixed-length, list == arbitrary-length" distinction means we now need
> a way to create hashable lists. I propose a new, hashable frozenlist
> built-in type to fill this niche.
>
> This type would subclass from list, overriding __getitem__,
> __delitem__, __hash__ and other methods as appropriate.
>
> Thoughts? Does this need to go through a full PEP process?

No, no, no!

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

From aahz at pythoncraft.com  Mon May 22 18:46:18 2006
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 22 May 2006 09:46:18 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <1148315368.19392.4.camel@fsol>
References: <44716940.9000300@acm.org>
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
	<1148315368.19392.4.camel@fsol>
Message-ID: <20060522164618.GA14460@panix.com>

On Mon, May 22, 2006, Antoine Pitrou wrote:
>
> For example, one common annoyance IMO is naming: why "urllib" or
> "httplib"? If I import something, it's obvious it's a lib, so "import
> http" would seem sufficient. There are also inconsistencies in casing
> ("StringIO, "cPickle", etc.), unnecessary distinctions ("thread" vs.
> "threading")...

So that you can use "http" as a name, of course.  Some of the others you
list are historical accidents that probably will get fixed for Py3K.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"I saw `cout' being shifted "Hello world" times to the left and stopped
right there."  --Steve Gonedes

From solipsis at pitrou.net  Mon May 22 19:21:20 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 22 May 2006 19:21:20 +0200
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <20060522164618.GA14460@panix.com>
References: <44716940.9000300@acm.org>
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
	<1148315368.19392.4.camel@fsol>  <20060522164618.GA14460@panix.com>
Message-ID: <1148318480.19392.6.camel@fsol>

Le lundi 22 mai 2006 ? 09:46 -0700, Aahz a ?crit :
> On Mon, May 22, 2006, Antoine Pitrou wrote:
> >
> > For example, one common annoyance IMO is naming: why "urllib" or
> > "httplib"? If I import something, it's obvious it's a lib, so "import
> > http" would seem sufficient. There are also inconsistencies in casing
> > ("StringIO, "cPickle", etc.), unnecessary distinctions ("thread" vs.
> > "threading")...
> 
> So that you can use "http" as a name, of course.

Yet "array" is not named "arraylib", "calendar" is not named
"calendarlib", "email" is not named "emaillib"... Shall I continue? ;)




From guido at python.org  Mon May 22 19:28:23 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 22 May 2006 10:28:23 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <1148318480.19392.6.camel@fsol>
References: <44716940.9000300@acm.org>
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
	<1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com>
	<1148318480.19392.6.camel@fsol>
Message-ID: <ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>

On 5/22/06, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Yet "array" is not named "arraylib", "calendar" is not named
> "calendarlib", "email" is not named "emaillib"... Shall I continue? ;)

Please stop this pointless debate. We all know that the stdlib uses
many different inconsistent naming conventions. And I admit full
responsibility for many of those.

If you want to do something about it, come up with a consistent naming
convention.

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

From jcarlson at uci.edu  Mon May 22 21:13:51 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Mon, 22 May 2006 12:13:51 -0700
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
Message-ID: <20060522121249.68B4.JCARLSON@uci.edu>


"Guido van Rossum" <guido at python.org> wrote:
> 
> On 5/22/06, Collin Winter <collinw at gmail.com> wrote:
> > One thing I've run into several times in this process is the use of
> > *args as a dict key. As several others have mentioned, the "tuple ==
> > fixed-length, list == arbitrary-length" distinction means we now need
> > a way to create hashable lists. I propose a new, hashable frozenlist
> > built-in type to fill this niche.
> >
> > This type would subclass from list, overriding __getitem__,
> > __delitem__, __hash__ and other methods as appropriate.
> >
> > Thoughts? Does this need to go through a full PEP process?
> 
> No, no, no!

Or to clarify Guido: use a tuple.  Tuples are also arbitrary-length, and
serve the same purposes that any 'frozen list' equivalent would.

 - Josiah


From tomerfiliba at gmail.com  Mon May 22 21:29:39 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Mon, 22 May 2006 21:29:39 +0200
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
Message-ID: <1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>

forwarded from c.l.p -- they said it is better suited for python3k as it
break things

-----

typing "help(type)" gives the following documentation:
    >>> help(type)
    Help on class type in module __builtin__:
    class type(object)
     |  type(object) -> the object's type
     |  type(name, bases, dict) -> a new type

"type" behaves both as a function, that reports the type of an object,
and as a factory type for creating types, as used mainly with
metaclasses.

calling the constructor of types, like lists, etc., is expected to
create a new instance of that type -- list() is a factory for lists,
dict() is a factory for dicts, etc.

but type() breaks this assumption. it behaves like a factory when
called with 3 params, but as a function when called with one param.
i find this overloading quite ugly and unnecessary.

more over, it can cause abominations like
>>> class mymetaclass(type):
...     pass
...
>>> mymetaclass(1)
<type 'int'>

or
>>> list.__class__(1)
<type 'int'>

i suggest splitting this overloaded meaning into two separate builtins:
* type(name, bases, dict) - a factory for types
* typeof(obj) - returns the type of the object

this way, "type" retains its meaning as the base-class for all types,
and as a factory for types, while typeof() reports the object's type.
it's also more intuitive that typeof(1) returns, well, the *type of*
the object 1.

no new keywords are needed, and code is always allowed to
override builtin functions, so there's no need for "from __future__
import blah" kind of stuff.

---

notes on compatibility: it would be easy to write an external tool
that mechanically replaces "type(obj)" with "typeof(obj)"... which
also proves the point type(obj) and type(n, b, d) are fundamentally
different and shouldn't share the same overloaded name.

comments?


-tomer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060522/646400ec/attachment.htm 

From guido at python.org  Mon May 22 22:35:01 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 22 May 2006 13:35:01 -0700
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
Message-ID: <ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>

I think this is a reasonable suggestion. Perhaps less code would break
if you renamed the metaclass instead of the inquiry function.

--Guido

On 5/22/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> forwarded from c.l.p -- they said it is better suited for python3k as it
> break things
>
> -----
>
> typing "help(type)" gives the following documentation:
>     >>> help(type)
>     Help on class type in module __builtin__:
>     class type(object)
>      |  type(object) -> the object's type
>      |  type(name, bases, dict) -> a new type
>
> "type" behaves both as a function, that reports the type of an object,
> and as a factory type for creating types, as used mainly with
> metaclasses.
>
> calling the constructor of types, like lists, etc., is expected to
> create a new instance of that type -- list() is a factory for lists,
> dict() is a factory for dicts, etc.
>
> but type() breaks this assumption. it behaves like a factory when
> called with 3 params, but as a function when called with one param.
> i find this overloading quite ugly and unnecessary.
>
> more over, it can cause abominations like
> >>> class mymetaclass(type):
> ...     pass
> ...
> >>> mymetaclass(1)
> <type 'int'>
>
> or
> >>> list.__class__(1)
> <type 'int'>
>
> i suggest splitting this overloaded meaning into two separate builtins:
> * type(name, bases, dict) - a factory for types
> * typeof(obj) - returns the type of the object
>
> this way, "type" retains its meaning as the base-class for all types,
> and as a factory for types, while typeof() reports the object's type.
> it's also more intuitive that typeof(1) returns, well, the *type of*
> the object 1.
>
> no new keywords are needed, and code is always allowed to
> override builtin functions, so there's no need for "from __future__
> import blah" kind of stuff.
>
> ---
>
> notes on compatibility: it would be easy to write an external tool
> that mechanically replaces "type(obj)" with "typeof(obj)"... which
> also proves the point type(obj) and type(n, b, d) are fundamentally
> different and shouldn't share the same overloaded name.
>
> comments?
>
>
> -tomer

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

From collinw at gmail.com  Tue May 23 01:24:00 2006
From: collinw at gmail.com (Collin Winter)
Date: Mon, 22 May 2006 19:24:00 -0400
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <20060522121249.68B4.JCARLSON@uci.edu>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
Message-ID: <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>

On 5/22/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> "Guido van Rossum" <guido at python.org> wrote:
> > On 5/22/06, Collin Winter <collinw at gmail.com> wrote:
> > > One thing I've run into several times in this process is the use of
> > > *args as a dict key. As several others have mentioned, the "tuple ==
> > > fixed-length, list == arbitrary-length" distinction means we now need
> > > a way to create hashable lists. I propose a new, hashable frozenlist
> > > built-in type to fill this niche.
> > >
> > > This type would subclass from list, overriding __getitem__,
> > > __delitem__, __hash__ and other methods as appropriate.
> > >
> > > Thoughts? Does this need to go through a full PEP process?
> >
> > No, no, no!
>
> Or to clarify Guido: use a tuple.  Tuples are also arbitrary-length, and
> serve the same purposes that any 'frozen list' equivalent would.

In Python 2, sure, but if Python 3 introduces the idea that tuples
should be used for fixed-length structures (since Guido has said that
tuple[Number, Number] should be a 2-tuple of Numbers), then something
else needs to fill the "hashable, arbitrary-length ordered container"
niche.

The main use case I'm thinking of is parameterizing mapping types. Say
I wanted a set of Number lists: in Python 2, I'd just convert the
lists to tuples before adding them to the set. However, in Python 3,
converting the lists to tuples will cause any annotations like
set[list[Number]] to reject the candidate set. I'd like to avoid
having annotations like set[tuple & EveryElementIs(Number)]. Also,
before anyone proposes it, I don't think "just remove the offending
annotations" is a viable solution.

Collin Winter

From guido at python.org  Tue May 23 02:02:47 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 22 May 2006 17:02:47 -0700
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
Message-ID: <ca471dc20605221702k1a9d413aqa14e71fc1de0a0f1@mail.gmail.com>

On 5/22/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/22/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> > "Guido van Rossum" <guido at python.org> wrote:
> > > On 5/22/06, Collin Winter <collinw at gmail.com> wrote:
> > > > One thing I've run into several times in this process is the use of
> > > > *args as a dict key. As several others have mentioned, the "tuple ==
> > > > fixed-length, list == arbitrary-length" distinction means we now need
> > > > a way to create hashable lists. I propose a new, hashable frozenlist
> > > > built-in type to fill this niche.
> > > >
> > > > This type would subclass from list, overriding __getitem__,
> > > > __delitem__, __hash__ and other methods as appropriate.
> > > >
> > > > Thoughts? Does this need to go through a full PEP process?
> > >
> > > No, no, no!
> >
> > Or to clarify Guido: use a tuple.  Tuples are also arbitrary-length, and
> > serve the same purposes that any 'frozen list' equivalent would.
>
> In Python 2, sure, but if Python 3 introduces the idea that tuples
> should be used for fixed-length structures (since Guido has said that
> tuple[Number, Number] should be a 2-tuple of Numbers), then something
> else needs to fill the "hashable, arbitrary-length ordered container"
> niche.

No. This distinction is in your mind. The tuple type can easily fulfill both.

> The main use case I'm thinking of is parameterizing mapping types. Say
> I wanted a set of Number lists: in Python 2, I'd just convert the
> lists to tuples before adding them to the set. However, in Python 3,
> converting the lists to tuples will cause any annotations like
> set[list[Number]] to reject the candidate set. I'd like to avoid
> having annotations like set[tuple & EveryElementIs(Number)]. Also,
> before anyone proposes it, I don't think "just remove the offending
> annotations" is a viable solution.

You should be able to declare it as set[ImmutableSequence[Number]] and
a set containing tuples would match that.

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

From tony at printra.net  Tue May 23 02:04:00 2006
From: tony at printra.net (Tony Lownds)
Date: Mon, 22 May 2006 17:04:00 -0700
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
Message-ID: <D28B559A-A8C9-4C69-88ED-FD954A142013@printra.net>


On May 22, 2006, at 4:24 PM, Collin Winter wrote:
> The main use case I'm thinking of is parameterizing mapping types. Say
> I wanted a set of Number lists: in Python 2, I'd just convert the
> lists to tuples before adding them to the set. However, in Python 3,
> converting the lists to tuples will cause any annotations like
> set[list[Number]] to reject the candidate set. I'd like to avoid
> having annotations like set[tuple & EveryElementIs(Number)]. Also,
> before anyone proposes it, I don't think "just remove the offending
> annotations" is a viable solution.
>

How about tuple[T] then? tuple[T,] can represent a 1-tuple.

-Tony



From greg.ewing at canterbury.ac.nz  Tue May 23 02:23:30 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 23 May 2006 12:23:30 +1200
Subject: [Python-3000] Immutable lists (was: Re: Type
	annotations:	annotating generators)
In-Reply-To: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
Message-ID: <44725602.3020806@canterbury.ac.nz>

Collin Winter wrote:
> (side note:
> could someone please do an 'svn mv p3yk py3k' to fix that name?)

Aw, that would spoil the fun.

--
Greg

From greg.ewing at canterbury.ac.nz  Tue May 23 02:33:30 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 23 May 2006 12:33:30 +1200
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
Message-ID: <4472585A.8010109@canterbury.ac.nz>

tomer filiba wrote:

> i suggest splitting this overloaded meaning into two separate builtins:
> * type(name, bases, dict) - a factory for types
> * typeof(obj) - returns the type of the object

Or just drop the function usage altogether and make
__class__ the one obvious way to find out something's
class/type.

--
Greg

From greg.ewing at canterbury.ac.nz  Tue May 23 02:42:21 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 23 May 2006 12:42:21 +1200
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
 annotating generators)
In-Reply-To: <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
Message-ID: <44725A6D.5040808@canterbury.ac.nz>

Collin Winter wrote:

> In Python 2, sure, but if Python 3 introduces the idea that tuples
> should be used for fixed-length structures (since Guido has said that
> tuple[Number, Number] should be a 2-tuple of Numbers), then something
> else needs to fill the "hashable, arbitrary-length ordered container"
> niche.

The way to resolve this is to devise a notation for
arbitrary-length tuple types, not to introduce a whole
new data type and revise everyone's ideas on how a
tuple should be used. As far as I'm aware, Guido has
never said that tuples should *only* be used for
fixed-length applications.

--
Greg

From collinw at gmail.com  Tue May 23 03:02:09 2006
From: collinw at gmail.com (Collin Winter)
Date: Mon, 22 May 2006 21:02:09 -0400
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <ca471dc20605221702k1a9d413aqa14e71fc1de0a0f1@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
	<ca471dc20605221702k1a9d413aqa14e71fc1de0a0f1@mail.gmail.com>
Message-ID: <43aa6ff70605221802w57c27942g465ee26aa633f767@mail.gmail.com>

On 5/22/06, Guido van Rossum <guido at python.org> wrote:
> On 5/22/06, Collin Winter <collinw at gmail.com> wrote:
> > The main use case I'm thinking of is parameterizing mapping types. Say
> > I wanted a set of Number lists: in Python 2, I'd just convert the
> > lists to tuples before adding them to the set. However, in Python 3,
> > converting the lists to tuples will cause any annotations like
> > set[list[Number]] to reject the candidate set. I'd like to avoid
> > having annotations like set[tuple & EveryElementIs(Number)]. Also,
> > before anyone proposes it, I don't think "just remove the offending
> > annotations" is a viable solution.
>
> You should be able to declare it as set[ImmutableSequence[Number]] and
> a set containing tuples would match that.

Is Python 3 going to ship with a set of these interface definitions? I
thought the plan was to leave things like this up to external
libraries, but if a crucial role for a built-in type (like what you've
described) is going to need an ImmutableSequence interface to be
correctly annotated, then....I think you can see where I'm going with
this.

Perhaps we should go with Tony Lownds' suggestion of tuple[T] is an
arbitrary-length tuple and tuple[T,] is a 1-tuple?

Collin Winter

From guido at python.org  Tue May 23 04:48:12 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 22 May 2006 19:48:12 -0700
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <4472585A.8010109@canterbury.ac.nz>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
	<4472585A.8010109@canterbury.ac.nz>
Message-ID: <ca471dc20605221948s2a584124wa652736aa9f5f7c8@mail.gmail.com>

On 5/22/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> tomer filiba wrote:
>
> > i suggest splitting this overloaded meaning into two separate builtins:
> > * type(name, bases, dict) - a factory for types
> > * typeof(obj) - returns the type of the object
>
> Or just drop the function usage altogether and make
> __class__ the one obvious way to find out something's
> class/type.

Well, you could overload __class__ to "lie" -- but type won't. I'd
rather not lost that functionality. I expect that with proxies
becoming more popular they may start lying about __class__. For most
purposes that's fine but I'd like to be able to tell whether I'm
dealing with a proxy, if I really need to know.

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

From guido at python.org  Tue May 23 04:50:50 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 22 May 2006 19:50:50 -0700
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605221802w57c27942g465ee26aa633f767@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
	<ca471dc20605221702k1a9d413aqa14e71fc1de0a0f1@mail.gmail.com>
	<43aa6ff70605221802w57c27942g465ee26aa633f767@mail.gmail.com>
Message-ID: <ca471dc20605221950k3fb0aa5eh246a0e24f694e3f3@mail.gmail.com>

On 5/22/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/22/06, Guido van Rossum <guido at python.org> wrote:
> > On 5/22/06, Collin Winter <collinw at gmail.com> wrote:
> > > The main use case I'm thinking of is parameterizing mapping types. Say
> > > I wanted a set of Number lists: in Python 2, I'd just convert the
> > > lists to tuples before adding them to the set. However, in Python 3,
> > > converting the lists to tuples will cause any annotations like
> > > set[list[Number]] to reject the candidate set. I'd like to avoid
> > > having annotations like set[tuple & EveryElementIs(Number)]. Also,
> > > before anyone proposes it, I don't think "just remove the offending
> > > annotations" is a viable solution.
> >
> > You should be able to declare it as set[ImmutableSequence[Number]] and
> > a set containing tuples would match that.
>
> Is Python 3 going to ship with a set of these interface definitions? I
> thought the plan was to leave things like this up to external
> libraries, but if a crucial role for a built-in type (like what you've
> described) is going to need an ImmutableSequence interface to be
> correctly annotated, then....I think you can see where I'm going with
> this.

No, I can't. Will you please stop asking questions about what will
happen? We're still in the brainstorming phase. We can't know what
will happen, nor even what we'd like to happen. We need to brainstorm
more.

> Perhaps we should go with Tony Lownds' suggestion of tuple[T] is an
> arbitrary-length tuple and tuple[T,] is a 1-tuple?

Looks pretty ugly to me. I suggest you STOP WORRYING about this for a
while and finish the rest of the PEP.

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

From talin at acm.org  Tue May 23 07:57:33 2006
From: talin at acm.org (Talin)
Date: Mon, 22 May 2006 22:57:33 -0700
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
	<ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>
Message-ID: <4472A44D.8000106@acm.org>

Guido van Rossum wrote:
> I think this is a reasonable suggestion. Perhaps less code would break
> if you renamed the metaclass instead of the inquiry function.
> 
> --Guido

I'd like to lend my support to Tomer's proposal. I have been confused 
(repeatedly, which is a bad sign) by the conflation of the type-query 
and type-construction uses of 'type'.

As far as renaming the metaclass goes, I think that 'type' is a really 
good name for the metaclass, so even if it would break less things, 
there's a strong mnemonic value in keeping it the way it is. I think 
'typeof' is a reasonably good name for the query function.

(In fact, the first time I tried to use type( x ), I accidentally typed 
'typeof( x )'. So this is one data point as to how intuitive the name is.)

-- Talin

From talin at acm.org  Tue May 23 08:00:57 2006
From: talin at acm.org (Talin)
Date: Mon, 22 May 2006 23:00:57 -0700
Subject: [Python-3000] Type annotations
In-Reply-To: <ca471dc20605221950k3fb0aa5eh246a0e24f694e3f3@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>	<20060522121249.68B4.JCARLSON@uci.edu>	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>	<ca471dc20605221702k1a9d413aqa14e71fc1de0a0f1@mail.gmail.com>	<43aa6ff70605221802w57c27942g465ee26aa633f767@mail.gmail.com>
	<ca471dc20605221950k3fb0aa5eh246a0e24f694e3f3@mail.gmail.com>
Message-ID: <4472A519.9040308@acm.org>

Guido van Rossum wrote:
>>Perhaps we should go with Tony Lownds' suggestion of tuple[T] is an
>>arbitrary-length tuple and tuple[T,] is a 1-tuple?
> 
> 
> Looks pretty ugly to me. I suggest you STOP WORRYING about this for a
> while and finish the rest of the PEP.

At this point, I have to admit that I've completely lost track of the 
discussion (and I've read all the messages) - what exactly is it that 
we're trying to accomplish here?

Would some kind person please do me a favor and summarize what the 
issues being put forward are? Thanks.

-- Talin

From talin at acm.org  Tue May 23 08:54:14 2006
From: talin at acm.org (Talin)
Date: Mon, 22 May 2006 23:54:14 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
References: <44716940.9000300@acm.org>	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>	<1148315368.19392.4.camel@fsol>
	<20060522164618.GA14460@panix.com>	<1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
Message-ID: <4472B196.7070506@acm.org>

Guido van Rossum wrote:
> On 5/22/06, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 
>>Yet "array" is not named "arraylib", "calendar" is not named
>>"calendarlib", "email" is not named "emaillib"... Shall I continue? ;)
> 
> 
> Please stop this pointless debate. We all know that the stdlib uses
> many different inconsistent naming conventions. And I admit full
> responsibility for many of those.
> 
> If you want to do something about it, come up with a consistent naming
> convention.

Well, in that case, let me ask this: What would be the general 
parameters / requirements of the re-organization? I mean, any programmer 
can come along and divide up things into categories, but I suspect that 
there are subtler requirements than that.

Here are some examples of some requirements that I can think of:

1) No mass renaming of modules unless there's something seriously wrong 
with the existing name.

2) For most cases, I suspect that you will want to add no more than one 
additional level to the hierarchy. Namespaces will still be fairly flat, 
with large numbers of items per namespace, but not quite as broad and 
flat as they are today. (In other words, avoid deep nesting - we don't 
want to have to type sys.runtime.types.containers.UserDict.UserDict.)

So that people will have something to argue about, I'd suggest the 
following as a top-level category list. Note that only a small amount of 
thought has gone into this :)

    sys - contains the existing sys, plus atexit, site, user, etc.

    rt - runtime modules - gc, fpectl, inspect, etc.

    types - existing types module, mixin types, type predicates.

    persist - marshall, pickle, shelve, etc. Possibly zip and
       maybe ConfigParser

    imp - import machinery - existing imp, zipimport, pkgutil,
       modulefinder

    string - existing string, plus repr, pprint, textwrap, stringprep.
       Possibly fnmatch.

    encoding - codecs, unicodedata
       Example: net.protocols.http

    conversions - data conversion modules - fpformat

    re - regular expressions - unchanged

    collection - existing collections, queue, heapq, array
       Example: collections.array.array

    algorithms - diff, random, whrandom

    testing - doctest, unittest, test, test_support

    math - existing math, decimal, cmath
       Example: math.decimal

    doc - documentation tools - pydoc

    itertools - unchanged

    functional - unchanged

    console - cmd, shlex, curses*, getopt, optparse, readline,
      rlcompleter

    os - existing os plus errno

    os.path - as-is

    os.file - existing os.file plus fileinput, tempfile, filecmp,
      mmap

    os.dir - existing os.dir plus dircache, stat*, glob, shutil

    os.stream - popen*

    os.process - subprocess, signal

    os.socket - existing socket, select

    os.thread - existing threading, mutex

    os.posix - posix-specific

    os.win32 - win32-specific

    os.osx - osx-specific

    locale - unchanged

    logging - unchanged

    platform - unchanged

    compression - zlib, gzip, bz2, etc. (Or perhaps an 'archive'
      module including 'tar'.)

    db - database packages - the various databases, gdbm, bsddb, etc.

    debug - pdb, bdb, etc.

    profile - profiler, hotshot, etc.

    net.protocols - http, imap, pop, ftp, etc.
       Example: net.protocols.http

    net.formats - mail, mime, binhex, etc.
       Example: net.formats.mime

    net.tools - webbrowser, SocketServer, robotparser, etc.

    xml.* - xml-related packages
       Example: xml.sax

    media.audio - audio packages

    media.image - image conversion packages

    rexec - rename to 'restrict' (Too much confusion with 'regex')

    python - python language services (compiler, parser, etc.)


-- Talin


From phd at mail2.phd.pp.ru  Tue May 23 10:21:18 2006
From: phd at mail2.phd.pp.ru (Oleg Broytmann)
Date: Tue, 23 May 2006 12:21:18 +0400
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <4472B196.7070506@acm.org>
References: <44716940.9000300@acm.org>
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
	<1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com>
	<1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
Message-ID: <20060523082118.GD24731@phd.pp.ru>

On Mon, May 22, 2006 at 11:54:14PM -0700, Talin wrote:
>     net.protocols - http, imap, pop, ftp, etc.
>        Example: net.protocols.http
> 
>     net.formats - mail, mime, binhex, etc.
>        Example: net.formats.mime
> 
>     net.tools - webbrowser, SocketServer, robotparser, etc.

   I'd like to organize by usage, not by low-level details like protocols
and formats:

   net.email - email, smtp, pop
   net.web - sgml, html, xml, http, url, webbrowser

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From ncoghlan at gmail.com  Tue May 23 11:14:25 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 23 May 2006 19:14:25 +1000
Subject: [Python-3000] Immutable lists (was: Re: Type annotations:
 annotating generators)
In-Reply-To: <44725A6D.5040808@canterbury.ac.nz>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>	<20060522121249.68B4.JCARLSON@uci.edu>	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
	<44725A6D.5040808@canterbury.ac.nz>
Message-ID: <4472D271.9010001@gmail.com>

Greg Ewing wrote:
> Collin Winter wrote:
> 
>> In Python 2, sure, but if Python 3 introduces the idea that tuples
>> should be used for fixed-length structures (since Guido has said that
>> tuple[Number, Number] should be a 2-tuple of Numbers), then something
>> else needs to fill the "hashable, arbitrary-length ordered container"
>> niche.
> 
> The way to resolve this is to devise a notation for
> arbitrary-length tuple types, not to introduce a whole
> new data type and revise everyone's ideas on how a
> tuple should be used. As far as I'm aware, Guido has
> never said that tuples should *only* be used for
> fixed-length applications.

This is exactly what I was trying to get at when I suggested using "tuple[T]" 
as the notation for an arbitrary length tuple with elements of type T, and 
"T1, T2" as the notation for a 2-tuple with the first element of type T1 and 
the second element of type T2.

If "tuple[T1, T2]" is interpreted to mean the same thing as "T1, T2" does, 
then we have two ways of spelling the 2-tuple version and no way of spelling 
the arbitrary length tuple version.

Tony's suggestion of tuple[T] (where T is not a tuple instance) to mean an 
arbitrary length sequence is potentially workable, but not particularly clean 
(it means you have to write "tuple[tuple[T1, T2]]" for an arbitrary length 
tuple of 2-tuples, as "tuple[T1, T2]" would be the description of a single 
2-tuple)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Tue May 23 11:31:02 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 23 May 2006 19:31:02 +1000
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <ca471dc20605221948s2a584124wa652736aa9f5f7c8@mail.gmail.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>	<4472585A.8010109@canterbury.ac.nz>
	<ca471dc20605221948s2a584124wa652736aa9f5f7c8@mail.gmail.com>
Message-ID: <4472D656.20707@gmail.com>

Guido van Rossum wrote:
> On 5/22/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> tomer filiba wrote:
>>
>>> i suggest splitting this overloaded meaning into two separate builtins:
>>> * type(name, bases, dict) - a factory for types
>>> * typeof(obj) - returns the type of the object
>> Or just drop the function usage altogether and make
>> __class__ the one obvious way to find out something's
>> class/type.
> 
> Well, you could overload __class__ to "lie" -- but type won't. I'd
> rather not lost that functionality. I expect that with proxies
> becoming more popular they may start lying about __class__. For most
> purposes that's fine but I'd like to be able to tell whether I'm
> dealing with a proxy, if I really need to know.

That suggests to me that Tomer's on the right track in renaming the query 
function and leaving the metaclass alone. A lot of the code that currently 
uses type() directly doesn't work properly with classic classes and other 
metaclasses (like remote proxies) that persuade "__class__" to lie (I don't 
use classic classes if I can help it, so I'm fairly sure some of my own code 
fits into this category).

You could even standardise the "use __class__ if it's present and typeof(x) 
otherwise" pattern as a separate query function:

def classof(instance):
     try:
         return instance.__class__
     except AttributeError:
         return typeof(instance)

Then:

   type = the standard metaclass
   typeof = query function that an instance's metaclass cannot affect
   classof = query function that an instance's metaclass can affect

Metaclasses that play games with __class__ (like types.ClassType) can then be 
detected by the fact that typeof(x) != classof(x).

classof and typeof could actually be added in 2.x - it's only the removal of 
type's single argument behaviour that would have to wait until Py3k (or do the 
deprecation dance in the 2.x series)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From gmccaughan at synaptics-uk.com  Tue May 23 11:34:13 2006
From: gmccaughan at synaptics-uk.com (Gareth McCaughan)
Date: Tue, 23 May 2006 10:34:13 +0100
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <ca471dc20605201253y11fbb05dg9a9c7838a06527bc@mail.gmail.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<287D2E67-D342-4BFA-8D8F-DB3A6BD04865@printra.net>
	<ca471dc20605201253y11fbb05dg9a9c7838a06527bc@mail.gmail.com>
Message-ID: <200605231034.14546.gmccaughan@synaptics-uk.com>

On Saturday 2006-05-20 20:53, Guido van Rossum wrote:

> On 5/20/06, Tony Lownds <tony at printra.net> wrote:
> > How about just dict[str:int]?
> 
> A bit too clever, although it happens to work syntactically -- it
> calls dict.__getitem__(slice(str, int)).

Hmm. Why "too clever"? The symmetry with the syntax for dict literals
is nice, and (to me) it's more instantly apparent that the LH type
is the key and the RH type the value than with dict[str, int].

Now, Function[(int, int, int): float] isn't so good. ... Then again,
Function(int, int, int): float is pretty nice. What was the compelling
reason for not allowing bare slice literals, again? :-)

-- 
g


From mchermside at ingdirect.com  Tue May 23 14:02:26 2006
From: mchermside at ingdirect.com (Chermside, Michael)
Date: Tue, 23 May 2006 08:02:26 -0400
Subject: [Python-3000] Fwd: proposal: disambiguating type
Message-ID: <C5FC90016C43944485B7EE79356461214921B8@INGDEXJ3.ingdirect.com>

Guido writes:
> Well, you could overload __class__ to "lie" -- but type won't. I'd
> rather not lost that functionality. I expect that with proxies
> becoming more popular they may start lying about __class__. For most
> purposes that's fine but I'd like to be able to tell whether I'm
> dealing with a proxy, if I really need to know.


Hmm...

There are two ways to access a piece of information. You can either use
the built-in "foo(x)" function, or you can use a special
double-underscore
"x.__foo__". One of these is spoofable by proxies, the other returns
the REAL value for those times when you really need to know.

Gee... I'd expect that "foo(x)" was the spoofable one and "x.__foo__"
the real one. Anything else sounds quite odd. Are we going to advise
users with something like this:

    Normally use the x.__foo__ property. Please try to avoid the
    simple foo(x) built-in -- it is really only for experts.

My preference would be to have "foo(x)" simply return "x.__foo__" (which
is spoofable) to encourage novices to do the right thing. Then provide
"somemodule.realfoo(x)" as the non-spoofable version for experts.

-- Michael Chermside

PS: __foo__ == __class__, foo(x) == type(x) or typeof(x), I'm not sure
  what somemodule equals.

PPS: I apologize for the silly disclaimer below.





*****************************************************************************
This email may contain confidential or privileged information. If you believe
 you have received the message in error, please notify the sender and delete 
the message without copying or disclosing it.
*****************************************************************************


From guido at python.org  Tue May 23 17:12:49 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 23 May 2006 08:12:49 -0700
Subject: [Python-3000] Type annotations
In-Reply-To: <4472A519.9040308@acm.org>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
	<ca471dc20605221702k1a9d413aqa14e71fc1de0a0f1@mail.gmail.com>
	<43aa6ff70605221802w57c27942g465ee26aa633f767@mail.gmail.com>
	<ca471dc20605221950k3fb0aa5eh246a0e24f694e3f3@mail.gmail.com>
	<4472A519.9040308@acm.org>
Message-ID: <ca471dc20605230812u600a704fg3a3f2e2bd13ad1a0@mail.gmail.com>

On 5/22/06, Talin <talin at acm.org> wrote:
> Guido van Rossum wrote:
> >>Perhaps we should go with Tony Lownds' suggestion of tuple[T] is an
> >>arbitrary-length tuple and tuple[T,] is a 1-tuple?
> >
> >
> > Looks pretty ugly to me. I suggest you STOP WORRYING about this for a
> > while and finish the rest of the PEP.
>
> At this point, I have to admit that I've completely lost track of the
> discussion (and I've read all the messages) - what exactly is it that
> we're trying to accomplish here?
>
> Would some kind person please do me a favor and summarize what the
> issues being put forward are? Thanks.

I think that Collin's agenda and mine are slightly different. Collin
wants something like his type checking decorators to be in the stdlib
(but he's okay to switching to my syntax proposal e.g. list[int] or
Sequence[Number]). I'm not sure that I want that but I also don't want
to prevent him from doing it if it can be pulled off. My own agenda is
first to get a PEP written about the parameter and return value
annotation syntax, *without* any semantics (other than making the
expression available via __signature__, which is a separate PEP).

Bill Janssen wants to go further than Collin; he wants sequence-ness,
file-ness,  etc. to be expressed by explicit subclassing. I'm at the
point where I think that some kind of explicit marker to distinguish
sequence-ness from mapping-ness is a good idea, but I'm not sure if it
should be inheritance or a marker attribute/method, and I'm not sure
that we should do this for all container types. But I'm open to
someone coming up with a coherent type hierarchy for Python and a way
to formalize it a bit mor without losing duck typing.

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

From guido at python.org  Tue May 23 17:17:03 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 23 May 2006 08:17:03 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <4472B196.7070506@acm.org>
References: <44716940.9000300@acm.org>
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
	<1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com>
	<1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
Message-ID: <ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>

I have to ignore this topic. It's too big and contentious to get easy
agreement. (The one thing I *don't* want is move the entire stdlib
hierarchy under 'py' or something like that.) Eric Raymond once made
detailed proposal, you can probably still find it somewhere. Good
luck!

--Guido

On 5/22/06, Talin <talin at acm.org> wrote:
> Guido van Rossum wrote:
> > On 5/22/06, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >
> >>Yet "array" is not named "arraylib", "calendar" is not named
> >>"calendarlib", "email" is not named "emaillib"... Shall I continue? ;)
> >
> >
> > Please stop this pointless debate. We all know that the stdlib uses
> > many different inconsistent naming conventions. And I admit full
> > responsibility for many of those.
> >
> > If you want to do something about it, come up with a consistent naming
> > convention.
>
> Well, in that case, let me ask this: What would be the general
> parameters / requirements of the re-organization? I mean, any programmer
> can come along and divide up things into categories, but I suspect that
> there are subtler requirements than that.
>
> Here are some examples of some requirements that I can think of:
>
> 1) No mass renaming of modules unless there's something seriously wrong
> with the existing name.
>
> 2) For most cases, I suspect that you will want to add no more than one
> additional level to the hierarchy. Namespaces will still be fairly flat,
> with large numbers of items per namespace, but not quite as broad and
> flat as they are today. (In other words, avoid deep nesting - we don't
> want to have to type sys.runtime.types.containers.UserDict.UserDict.)
>
> So that people will have something to argue about, I'd suggest the
> following as a top-level category list. Note that only a small amount of
> thought has gone into this :)
>
>     sys - contains the existing sys, plus atexit, site, user, etc.
>
>     rt - runtime modules - gc, fpectl, inspect, etc.
>
>     types - existing types module, mixin types, type predicates.
>
>     persist - marshall, pickle, shelve, etc. Possibly zip and
>        maybe ConfigParser
>
>     imp - import machinery - existing imp, zipimport, pkgutil,
>        modulefinder
>
>     string - existing string, plus repr, pprint, textwrap, stringprep.
>        Possibly fnmatch.
>
>     encoding - codecs, unicodedata
>        Example: net.protocols.http
>
>     conversions - data conversion modules - fpformat
>
>     re - regular expressions - unchanged
>
>     collection - existing collections, queue, heapq, array
>        Example: collections.array.array
>
>     algorithms - diff, random, whrandom
>
>     testing - doctest, unittest, test, test_support
>
>     math - existing math, decimal, cmath
>        Example: math.decimal
>
>     doc - documentation tools - pydoc
>
>     itertools - unchanged
>
>     functional - unchanged
>
>     console - cmd, shlex, curses*, getopt, optparse, readline,
>       rlcompleter
>
>     os - existing os plus errno
>
>     os.path - as-is
>
>     os.file - existing os.file plus fileinput, tempfile, filecmp,
>       mmap
>
>     os.dir - existing os.dir plus dircache, stat*, glob, shutil
>
>     os.stream - popen*
>
>     os.process - subprocess, signal
>
>     os.socket - existing socket, select
>
>     os.thread - existing threading, mutex
>
>     os.posix - posix-specific
>
>     os.win32 - win32-specific
>
>     os.osx - osx-specific
>
>     locale - unchanged
>
>     logging - unchanged
>
>     platform - unchanged
>
>     compression - zlib, gzip, bz2, etc. (Or perhaps an 'archive'
>       module including 'tar'.)
>
>     db - database packages - the various databases, gdbm, bsddb, etc.
>
>     debug - pdb, bdb, etc.
>
>     profile - profiler, hotshot, etc.
>
>     net.protocols - http, imap, pop, ftp, etc.
>        Example: net.protocols.http
>
>     net.formats - mail, mime, binhex, etc.
>        Example: net.formats.mime
>
>     net.tools - webbrowser, SocketServer, robotparser, etc.
>
>     xml.* - xml-related packages
>        Example: xml.sax
>
>     media.audio - audio packages
>
>     media.image - image conversion packages
>
>     rexec - rename to 'restrict' (Too much confusion with 'regex')
>
>     python - python language services (compiler, parser, etc.)
>
>
> -- Talin
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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

From guido at python.org  Tue May 23 17:20:54 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 23 May 2006 08:20:54 -0700
Subject: [Python-3000] Type parameterization (was: Re: Type annotations:
	annotating generators)
In-Reply-To: <200605231034.14546.gmccaughan@synaptics-uk.com>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<287D2E67-D342-4BFA-8D8F-DB3A6BD04865@printra.net>
	<ca471dc20605201253y11fbb05dg9a9c7838a06527bc@mail.gmail.com>
	<200605231034.14546.gmccaughan@synaptics-uk.com>
Message-ID: <ca471dc20605230820m68977d58j826ce5161d3fdb23@mail.gmail.com>

On 5/23/06, Gareth McCaughan <gmccaughan at synaptics-uk.com> wrote:
> On Saturday 2006-05-20 20:53, Guido van Rossum wrote:
>
> > On 5/20/06, Tony Lownds <tony at printra.net> wrote:
> > > How about just dict[str:int]?
> >
> > A bit too clever, although it happens to work syntactically -- it
> > calls dict.__getitem__(slice(str, int)).
>
> Hmm. Why "too clever"?

Because you're creatin a correspondence between two entirely unrelated
usages of ':' -- the usage in a dict display is unrelated (and totally
different in nature) than the usage in slices.

> The symmetry with the syntax for dict literals
> is nice, and (to me) it's more instantly apparent that the LH type
> is the key and the RH type the value than with dict[str, int].
>
> Now, Function[(int, int, int): float] isn't so good. ... Then again,
> Function(int, int, int): float is pretty nice. What was the compelling
> reason for not allowing bare slice literals, again? :-)

It's ambiguous, e.g. if you put it at the top level of the condition
in an if statement.

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

From guido at python.org  Tue May 23 18:51:35 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 23 May 2006 09:51:35 -0700
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <4472D656.20707@gmail.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
	<4472585A.8010109@canterbury.ac.nz>
	<ca471dc20605221948s2a584124wa652736aa9f5f7c8@mail.gmail.com>
	<4472D656.20707@gmail.com>
Message-ID: <ca471dc20605230951k7e204826g4a3b08465b071f9a@mail.gmail.com>

Let's please leave 2.x alone.

On 5/23/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Guido van Rossum wrote:
> > On 5/22/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> >> tomer filiba wrote:
> >>
> >>> i suggest splitting this overloaded meaning into two separate builtins:
> >>> * type(name, bases, dict) - a factory for types
> >>> * typeof(obj) - returns the type of the object
> >> Or just drop the function usage altogether and make
> >> __class__ the one obvious way to find out something's
> >> class/type.
> >
> > Well, you could overload __class__ to "lie" -- but type won't. I'd
> > rather not lost that functionality. I expect that with proxies
> > becoming more popular they may start lying about __class__. For most
> > purposes that's fine but I'd like to be able to tell whether I'm
> > dealing with a proxy, if I really need to know.
>
> That suggests to me that Tomer's on the right track in renaming the query
> function and leaving the metaclass alone. A lot of the code that currently
> uses type() directly doesn't work properly with classic classes and other
> metaclasses (like remote proxies) that persuade "__class__" to lie (I don't
> use classic classes if I can help it, so I'm fairly sure some of my own code
> fits into this category).
>
> You could even standardise the "use __class__ if it's present and typeof(x)
> otherwise" pattern as a separate query function:
>
> def classof(instance):
>      try:
>          return instance.__class__
>      except AttributeError:
>          return typeof(instance)
>
> Then:
>
>    type = the standard metaclass
>    typeof = query function that an instance's metaclass cannot affect
>    classof = query function that an instance's metaclass can affect
>
> Metaclasses that play games with __class__ (like types.ClassType) can then be
> detected by the fact that typeof(x) != classof(x).
>
> classof and typeof could actually be added in 2.x - it's only the removal of
> type's single argument behaviour that would have to wait until Py3k (or do the
> deprecation dance in the 2.x series)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> ---------------------------------------------------------------
>              http://www.boredomandlaziness.org
>


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

From guido at python.org  Tue May 23 18:54:57 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 23 May 2006 09:54:57 -0700
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <4472A44D.8000106@acm.org>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
	<ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>
	<4472A44D.8000106@acm.org>
Message-ID: <ca471dc20605230954w33d0dbcekfe2a20b6273471bd@mail.gmail.com>

On 5/22/06, Talin <talin at acm.org> wrote:
> Guido van Rossum wrote:
> > I think this is a reasonable suggestion. Perhaps less code would break
> > if you renamed the metaclass instead of the inquiry function.
> >
> > --Guido
>
> I'd like to lend my support to Tomer's proposal. I have been confused
> (repeatedly, which is a bad sign) by the conflation of the type-query
> and type-construction uses of 'type'.
>
> As far as renaming the metaclass goes, I think that 'type' is a really
> good name for the metaclass, so even if it would break less things,
> there's a strong mnemonic value in keeping it the way it is. I think
> 'typeof' is a reasonably good name for the query function.

Doesn't convince me. Python doesn't have any "xyzzyof" functions; I
find this quite ugly -- and xyzzy_of is no better due to the dreaded
underscore. After all, we don't write lenof(seq).

And I'm not sure why 'type' is such a great name for the metaclass --
it just doesn't express clearly what it is (if anything, it ought to
be called "class" or "Class").

Finally, type() the function is older.

> (In fact, the first time I tried to use type( x ), I accidentally typed
> 'typeof( x )'. So this is one data point as to how intuitive the name is.)

The only intuitive interface is the nipple. Everything else is
learned. (Jef Raskin, I believe.)

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

From bwinton at latte.ca  Tue May 23 18:58:37 2006
From: bwinton at latte.ca (Blake Winton)
Date: Tue, 23 May 2006 12:58:37 -0400
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <ca471dc20605230954w33d0dbcekfe2a20b6273471bd@mail.gmail.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
	<ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>
	<4472A44D.8000106@acm.org>
	<ca471dc20605230954w33d0dbcekfe2a20b6273471bd@mail.gmail.com>
Message-ID: <20060523165837.GA27084@latte.ca>

On Tue, May 23, 2006 at 09:54:57AM -0700, Guido van Rossum wrote:
> > (In fact, the first time I tried to use type( x ), I accidentally typed
> > 'typeof( x )'. So this is one data point as to how intuitive the name is.)
> The only intuitive interface is the nipple. Everything else is
> learned. (Jef Raskin, I believe.)

As the father of two young girls, let me add that the nipple isn't
particularly intuitive either.  It was a two-to-three day intensive
learning process for my wife and both babies.  (Although it was easier
the second time around, since then at least one of them knew what was
supposed to be happening.)

Later,
Blake.

From guido at python.org  Tue May 23 19:10:44 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 23 May 2006 10:10:44 -0700
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <20060523165837.GA27084@latte.ca>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
	<ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>
	<4472A44D.8000106@acm.org>
	<ca471dc20605230954w33d0dbcekfe2a20b6273471bd@mail.gmail.com>
	<20060523165837.GA27084@latte.ca>
Message-ID: <ca471dc20605231010y73871829n70b5a3f6cfe02245@mail.gmail.com>

On 5/23/06, Blake Winton <bwinton at latte.ca> wrote:
> On Tue, May 23, 2006 at 09:54:57AM -0700, Guido van Rossum wrote:
> > > (In fact, the first time I tried to use type( x ), I accidentally typed
> > > 'typeof( x )'. So this is one data point as to how intuitive the name is.)
> > The only intuitive interface is the nipple. Everything else is
> > learned. (Jef Raskin, I believe.)
>
> As the father of two young girls, let me add that the nipple isn't
> particularly intuitive either.  It was a two-to-three day intensive
> learning process for my wife and both babies.  (Although it was easier
> the second time around, since then at least one of them knew what was
> supposed to be happening.)

I know all about that. :-)

Anyway, it appears that the quote is commonly attributed to Bruce
Edigar, and it should properly be  "The only intuitive interface is
the nipple. After that, it's all learned." it is true that Jef Raskin
has often been chiding people for calling something "intuitive" when
they mean "familiar".

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

From guido at python.org  Tue May 23 19:28:40 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 23 May 2006 10:28:40 -0700
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <ca471dc20605231010y73871829n70b5a3f6cfe02245@mail.gmail.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
	<ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>
	<4472A44D.8000106@acm.org>
	<ca471dc20605230954w33d0dbcekfe2a20b6273471bd@mail.gmail.com>
	<20060523165837.GA27084@latte.ca>
	<ca471dc20605231010y73871829n70b5a3f6cfe02245@mail.gmail.com>
Message-ID: <ca471dc20605231028g3dcf1ec0j5fdcc64ae0856c33@mail.gmail.com>

On 5/23/06, Guido van Rossum <guido at python.org> wrote:
> Anyway, it appears that the quote is commonly attributed to Bruce
> Edigar, and it should properly be  "The only intuitive interface is
> the nipple. After that, it's all learned." it is true that Jef Raskin
> has often been chiding people for calling something "intuitive" when
> they mean "familiar".

Sigh. It's Bruce Ediger. What's more, Bruce denies coming up with it,
and he also says it isn't true, according to his wife's experience.

http://www.greenend.org.uk/rjk/2002/08/nipple.html (the quest for whose it is)

http://groups.google.com/group/comp.editors/msg/882fd4ef853ee770
(Bruce deniying it's his)

There is no intuitive interface, not even the nipple.  It's all learned.
        - Bruce Ediger, 2001

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

From aahz at pythoncraft.com  Tue May 23 19:33:28 2006
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 23 May 2006 10:33:28 -0700
Subject: [Python-3000] Instinctive interfaces (was proposal:
	disambiguating type)
In-Reply-To: <ca471dc20605230954w33d0dbcekfe2a20b6273471bd@mail.gmail.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
	<ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>
	<4472A44D.8000106@acm.org>
	<ca471dc20605230954w33d0dbcekfe2a20b6273471bd@mail.gmail.com>
Message-ID: <20060523173328.GA758@panix.com>

On Tue, May 23, 2006, Guido van Rossum wrote:
>
> The only intuitive interface is the nipple. Everything else is
> learned. (Jef Raskin, I believe.)

Except, of course, that even nipples aren't intuitive (which I assume you
knew given that you have kids).  Further info on this subject is
off-topic, but here's a Google search  in case anyone wants proof ;-)

"learning breastfeeding"

Your previous comments that the critical characteristics are how easy an
interface is to remember and how easy it is to make appropriate guesses
about other uses of an interface seem more on-target.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"I saw `cout' being shifted "Hello world" times to the left and stopped
right there."  --Steve Gonedes

From tomerfiliba at gmail.com  Tue May 23 21:38:24 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Tue, 23 May 2006 21:38:24 +0200
Subject: [Python-3000] Fwd: proposal: disambiguating type
In-Reply-To: <ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>
References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com>
	<1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com>
	<ca471dc20605221335h2810a2e1p4aa1a6d9e8bda09b@mail.gmail.com>
Message-ID: <1d85506f0605231238g7d36f107x5a713745a58be4a1@mail.gmail.com>

Guido writes:
> Perhaps less code would break
> if you renamed the metaclass instead of the inquiry function.

hrrm... well, the only name, other than "type", that i could think of the
metaclass is "metalcass". for example,

class MyMetaclass(metaclass):
    def __new__(cls, name, bases, dict):
        dict["blah"] = 5
        return metaclass.__new__(cls, name, bases, dict)

which seems okay. but the problem arises with type(),
which becomes a function --

>>> type(1)
<metaclass 'int'>
>>> type(list)
<metaclass 'metaclass'>
>>> type(metaclass)
<metaclass 'metaclass'>
>>> type(type)
<metaclass 'builtin_function_or_method'>

ugh?

metalcasses are a scary concept by themselves... the type of the
type... it's not quite /intuitive/ to newcommers. and it's not like
experienced programmers write metaclasses on a daily basis.
they are only used here and there.

yeah, i read the breastfeeding thread, but still, if i were a newcommer
and saw type(int) returned <metaclass>, i would ask myself
"wtf is a metaclass?", and start pulling my hair off.

metaclasses are not an everyday mechanism, and thus should be
"hidden" or kept out of everyday programming. on the other hand,
the concept of "type" more intuitive/common from other languages:
"the type of 4 is the integer type", as opposed to
"the type of 4 is the integer metaclass"

and since i read about plans for a mechanical tool that converts
legacy python code to py3k, i don't see how the amout of broken
code matters, as long as the code is converted right.

so i'd vote for type -> the metaclass, typeof -> the type of an object.
if you find "typeof" ugly, perhaps gettype looks better, as it resembles
getattr/item, etc.

>>> getattr(x, "y")
6
>>> gettype(6)
<type 'int'>

?


-tomer

On 5/22/06, Guido van Rossum <guido at python.org> wrote:
> I think this is a reasonable suggestion. Perhaps less code would break
> if you renamed the metaclass instead of the inquiry function.
>
> --Guido
>

From tdelaney at avaya.com  Tue May 23 23:27:55 2006
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Wed, 24 May 2006 07:27:55 +1000
Subject: [Python-3000] Fwd: proposal: disambiguating type
Message-ID: <2773CAC687FD5F4689F526998C7E4E5FF1E713@au3010avexu1.global.avaya.com>

Guido van Rossum wrote:

> I think this is a reasonable suggestion. Perhaps less code would break
> if you renamed the metaclass instead of the inquiry function.

It might be a positive effect if code broke because type(obj) broke -
haven't we been promoting for years that it's normally the wrong thing
to do? Might convince people to revisit any such code ;)

Tim Delaney

From greg.ewing at canterbury.ac.nz  Wed May 24 03:42:13 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 24 May 2006 13:42:13 +1200
Subject: [Python-3000] Immutable lists
In-Reply-To: <4472D271.9010001@gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
	<44725A6D.5040808@canterbury.ac.nz> <4472D271.9010001@gmail.com>
Message-ID: <4473B9F5.7070701@canterbury.ac.nz>

Nick Coghlan wrote:

> This is exactly what I was trying to get at when I suggested using 
> "tuple[T]" as the notation for an arbitrary length tuple with elements 
> of type T

If tuple[T] is an arbitrary-length tuple, then how
do you spell a 1-tuple with element type T?

 > and "T1, T2" as the notation for a 2-tuple with the first
> element of type T1 and the second element of type T2.

It's been pointed out that making (T1, T2) equivalent to
tuple[T1, T2] leads to an inconsistency. That needs to be
resolved before taking this idea any further.

--
Greg



From talin at acm.org  Wed May 24 08:57:20 2006
From: talin at acm.org (Talin)
Date: Tue, 23 May 2006 23:57:20 -0700
Subject: [Python-3000] PEP 3102 feedback
Message-ID: <447403D0.5030301@acm.org>

Well, c.l.p was strangely quiet in response to my posting PEP 3102 a few 
days ago. Only two comments, one of a general "ick" variety that seems 
mainly based on personal bias, and another which likes the idea but 
votes a -1 on the 'naked star' syntax.

So in other words, nothing has really changed - most people seem to like 
the idea of keyword-only arguments, but find the 'required keyword 
arguments' syntax confusing. (I haven't found many people who were in 
favor of it, however Guido says that's the form that he prefers.)

A few people have complained about keyword-only arguments with no 
defaults, but my feeling is that these concerns are based on a mistaken 
understanding of how keyword arguments work. (Many people seem to 
conflate keyword arguments and default argument values, because they 
both use '=' and they both are required to come after positional arguments.)

What's the next step after this? One thing that's missing is a sample 
implementation. Unfortunately, its not quite as simple as hacking lambda 
or ASTs, this one affects code generation (AFAICT) and is not something 
I feel confident to do myself.

(I'm also continuing to work on 3101, expect a new rev soon.)

-- Talin

From nnorwitz at gmail.com  Wed May 24 09:14:56 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Wed, 24 May 2006 00:14:56 -0700
Subject: [Python-3000] PEP 3102 feedback
In-Reply-To: <447403D0.5030301@acm.org>
References: <447403D0.5030301@acm.org>
Message-ID: <ee2a432c0605240014s40805faha22be214d126105f@mail.gmail.com>

On 5/23/06, Talin <talin at acm.org> wrote:
> Well, c.l.p was strangely quiet in response to my posting PEP 3102 a few
> days ago. Only two comments, one of a general "ick" variety that seems
> mainly based on personal bias, and another which likes the idea but
> votes a -1 on the 'naked star' syntax.

I don't really like the *, I prefer something like + or / (I don't
really like them much either, I just like them slightly more than *
:-).  + says it's something additional and / reminds me of and/or.
Kinda like take the previous positional arguments and/or the following
keyword arguments.  Though that doesn't work perfect since the keyword
args are required.

> What's the next step after this? One thing that's missing is a sample
> implementation. Unfortunately, its not quite as simple as hacking lambda
> or ASTs, this one affects code generation (AFAICT) and is not something
> I feel confident to do myself.

Go as far as you can, and ask questions when you get stuck.  Not sure
if that's the next step, but it's the best way to learn. :-)

n

From mcherm at mcherm.com  Wed May 24 16:13:14 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Wed, 24 May 2006 07:13:14 -0700
Subject: [Python-3000] PEP 3102 feedback
Message-ID: <20060524071314.5504li461i8gg040@login.werra.lunarpages.com>

Talin writes:
> So in other words, nothing has really changed - most people seem to  
> like the idea of keyword-only arguments, but find the 'required  
> keyword arguments' syntax confusing. (I haven't found many people  
> who were in favor of it, however Guido says that's the form that he  
> prefers.)

I'm in favor of it. I just haven't had much to say.

-- Michael Chermside

From guido at python.org  Wed May 24 16:48:36 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 24 May 2006 07:48:36 -0700
Subject: [Python-3000] PEP 3102 feedback
In-Reply-To: <447403D0.5030301@acm.org>
References: <447403D0.5030301@acm.org>
Message-ID: <ca471dc20605240748g698a00bdjea3b6923a423c2c4@mail.gmail.com>

On 5/23/06, Talin <talin at acm.org> wrote:
> Well, c.l.p was strangely quiet in response to my posting PEP 3102 a few
> days ago. Only two comments, one of a general "ick" variety that seems
> mainly based on personal bias, and another which likes the idea but
> votes a -1 on the 'naked star' syntax.

Lucky you. (If you want more negative feedback, I'd be happy to
volunteer as a co-author. :-)

> So in other words, nothing has really changed - most people seem to like
> the idea of keyword-only arguments, but find the 'required keyword
> arguments' syntax confusing. (I haven't found many people who were in
> favor of it, however Guido says that's the form that he prefers.)

Well, I'm at best +0 on it, but I haven't seen any proposal that I
like better (or even as well).

> A few people have complained about keyword-only arguments with no
> defaults, but my feeling is that these concerns are based on a mistaken
> understanding of how keyword arguments work. (Many people seem to
> conflate keyword arguments and default argument values, because they
> both use '=' and they both are required to come after positional arguments.)

Yeah, that confusion happens a lot, even here.

> What's the next step after this? One thing that's missing is a sample
> implementation. Unfortunately, its not quite as simple as hacking lambda
> or ASTs, this one affects code generation (AFAICT) and is not something
> I feel confident to do myself.

I suggest you give it a try anyway, and ask for help if you get stuck.
There are plenty of people who can help out, and you'l likely learn
something.

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

From fdrake at acm.org  Wed May 24 16:52:46 2006
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 24 May 2006 10:52:46 -0400
Subject: [Python-3000] PEP 3102 feedback
In-Reply-To: <20060524071314.5504li461i8gg040@login.werra.lunarpages.com>
References: <20060524071314.5504li461i8gg040@login.werra.lunarpages.com>
Message-ID: <200605241052.46532.fdrake@acm.org>

Talin writes:
 > So in other words, nothing has really changed - most people seem to
 > like the idea of keyword-only arguments, but find the 'required
 > keyword arguments' syntax confusing. (I haven't found many people
 > who were in favor of it, however Guido says that's the form that he
 > prefers.)

On Wednesday 24 May 2006 10:13, Michael Chermside wrote:
 > I'm in favor of it. I just haven't had much to say.

Same here.  The required keyword syntax is very interesting.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From tomerfiliba at gmail.com  Wed May 24 21:26:21 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Wed, 24 May 2006 21:26:21 +0200
Subject: [Python-3000] PEP 3102 comments
Message-ID: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>

talin asked for comments, so

def f(a, b, *, c, d)

seems wrong to me. '*' can't be a token on its own, at least
that's the way i see it. opeators shouldn't stand for themselves.
just like the {/} (empty set) was rejected.

anyway, this pep is certainly very useful (i would have used it
countless times), and since the '*' is gonna be overloaded this
way or another, i'd vote for placing it at the end of the last
argument's name, for example:

def f(a, b*, c, d)

"a" and "b" are positional arguments, no more positional
arguments can follow "b", and "c" and "d" are keyword only

we already have *b, which reads "all positional arguments
go into b", so b* could mean "no more positional arguments
after b". it's kinda symmetric imho. i like the way it looks.


-tomer

From benji at benjiyork.com  Wed May 24 21:43:35 2006
From: benji at benjiyork.com (Benji York)
Date: Wed, 24 May 2006 15:43:35 -0400
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
Message-ID: <4474B767.4000308@benjiyork.com>

tomer filiba wrote:
> i'd vote for placing it at the end of the last
> argument's name, for example:
> 
> def f(a, b*, c, d)

Another idea:

def f(a, b; c, d):

It fails the "syntax variants shouldn't look like grime on your monitor" 
test though.

Hmm, the next best thing I can come up with is:

def f(a, b, =, c, d):

The "=" vaguely references the "=" in keyword arguments.
--
Benji York

From solipsis at pitrou.net  Wed May 24 23:06:27 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 24 May 2006 23:06:27 +0200
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <4474B767.4000308@benjiyork.com>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
	<4474B767.4000308@benjiyork.com>
Message-ID: <1148504787.5736.7.camel@fsol>

Le mercredi 24 mai 2006 ? 15:43 -0400, Benji York a ?crit :
> Hmm, the next best thing I can come up with is:
> 
> def f(a, b, =, c, d):

Why not:
  def f(a, b, !c, !d):

The exclamation mark can be thought to say "you must explicitly mention
this one by its name".
I think having a sigil in front of a variable name is less ugly than
having a separate sigil between commas as a fake parameter.




From benji at benjiyork.com  Wed May 24 23:15:37 2006
From: benji at benjiyork.com (Benji York)
Date: Wed, 24 May 2006 17:15:37 -0400
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <1148504787.5736.7.camel@fsol>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>	<4474B767.4000308@benjiyork.com>
	<1148504787.5736.7.camel@fsol>
Message-ID: <4474CCF9.8080102@benjiyork.com>

Antoine Pitrou wrote:
> Why not:
>   def f(a, b, !c, !d):
> 
> The exclamation mark can be thought to say "you must explicitly mention
> this one by its name".
> I think having a sigil in front of a variable name is less ugly than
> having a separate sigil between commas as a fake parameter.

In that case, just use the current default value syntax, sans value (d, 
below):

def f(a, b, c=None, d=):
--
Benji

From solipsis at pitrou.net  Wed May 24 23:30:30 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 24 May 2006 23:30:30 +0200
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <4474CCF9.8080102@benjiyork.com>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
	<4474B767.4000308@benjiyork.com> <1148504787.5736.7.camel@fsol>
	<4474CCF9.8080102@benjiyork.com>
Message-ID: <1148506230.5736.11.camel@fsol>

Le mercredi 24 mai 2006 ? 17:15 -0400, Benji York a ?crit :
> In that case, just use the current default value syntax, sans value (d, 
> below):
> 
> def f(a, b, c=None, d=):

Then we can't decide whether "c" can be positional or is keyword-only.



From benji at benjiyork.com  Wed May 24 23:42:19 2006
From: benji at benjiyork.com (Benji York)
Date: Wed, 24 May 2006 17:42:19 -0400
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <1148506230.5736.11.camel@fsol>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>	<4474B767.4000308@benjiyork.com>
	<1148504787.5736.7.camel@fsol>	<4474CCF9.8080102@benjiyork.com>
	<1148506230.5736.11.camel@fsol>
Message-ID: <4474D33B.7030903@benjiyork.com>

Antoine Pitrou wrote:
> Le mercredi 24 mai 2006 ? 17:15 -0400, Benji York a ?crit :
> 
>>In that case, just use the current default value syntax, sans value (d, 
>>below):
>>
>>def f(a, b, c=None, d=):
> 
> Then we can't decide whether "c" can be positional or is keyword-only.

True.  As I suspect many do, I tend to conflate default arguments and 
keyword arguments.

It seems that this feature is doomed to ugly syntax.
--
Benji

From greg.ewing at canterbury.ac.nz  Thu May 25 02:58:17 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 25 May 2006 12:58:17 +1200
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
Message-ID: <44750129.50401@canterbury.ac.nz>

tomer filiba wrote:
> talin asked for comments, so
> 
> def f(a, b, *, c, d)
> 
> seems wrong to me. '*' can't be a token on its own, at least
> that's the way i see it. opeators shouldn't stand for themselves.

But * is not an operator here. It's just a token
with a special meaning in this context.

I don't really understand why this is so controversial.
To me, it's the obvious least-change way of introducing
the feature concerned. As someone said, it's just
"*args without the args".

--
Greg

From greg.ewing at canterbury.ac.nz  Thu May 25 03:00:45 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 25 May 2006 13:00:45 +1200
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <1148504787.5736.7.camel@fsol>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
	<4474B767.4000308@benjiyork.com> <1148504787.5736.7.camel@fsol>
Message-ID: <447501BD.2060900@canterbury.ac.nz>

Antoine Pitrou wrote:

> Why not:
>   def f(a, b, !c, !d):

That looks like "you're not allowed to pass these arguments". :-)

--
Greg

From talin at acm.org  Thu May 25 04:42:04 2006
From: talin at acm.org (Talin)
Date: Wed, 24 May 2006 19:42:04 -0700
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
Message-ID: <4475197C.1070804@acm.org>

tomer filiba wrote:
> talin asked for comments, so
> 
> def f(a, b, *, c, d)
> 
> seems wrong to me. '*' can't be a token on its own, at least
> that's the way i see it. opeators shouldn't stand for themselves.
> just like the {/} (empty set) was rejected.
> 

Um, before we get all tangled up in syntax arguments, I'd like to ask a 
slightly broader question - do we need this at all?

Remember, the PEP has two parts. The first part (allowing keywords 
arguments after *args) seems relatively uncontroversial - there are a 
lot of use cases, and a fairly small minority of people who have argued 
against it.

The discussion of the '*' syntax started with the following request from 
Guido:

 > Here's a related but more complicated wish: define a function in such
 > a way that certain parameters *must* be passed as keywords, *without*
 > using *args or **kwds. This may require a new syntactic crutch.

While a number of people have submitted possible use cases for this 
feature, others have challenged the validity of such cases.

At this point, I don't feel that the use cases for part 2 of the PEP are 
as well-understood as the use cases for part 1.

- Talin

From baptiste13 at altern.org  Thu May 25 11:42:23 2006
From: baptiste13 at altern.org (Baptiste Carvello)
Date: Thu, 25 May 2006 11:42:23 +0200
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <4475197C.1070804@acm.org>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
	<4475197C.1070804@acm.org>
Message-ID: <e53ujc$cu6$1@sea.gmane.org>

>  > Here's a related but more complicated wish: define a function in such
>  > a way that certain parameters *must* be passed as keywords, *without*
>  > using *args or **kwds. This may require a new syntactic crutch.
> 
> While a number of people have submitted possible use cases for this 
> feature, others have challenged the validity of such cases.
> 
> At this point, I don't feel that the use cases for part 2 of the PEP are 
> as well-understood as the use cases for part 1.
> 

maybe those use cases can work without syntactic sugar. With only part 1, you 
can already add a manual check if you need:

 >>> def myfunction(a1, a2, *forbidden, kw1, kw2):
...    assert forbidden is (), "myfunction() takes exactly 2 arguments"
...    pass
 >>>

If you want to have access to the function itself (to modify the signature), you 
can use a decorator:

 >>> @forbid('forbidden')
 >>> def myfunction(a1, a2, *forbidden, kw1, kw2):
...    pass
 >>>

(there can be a hook in the function object that @forbid will call, which would 
both fix the signature and add the runtime check)

or, some time in the future, a typecheck:

 >>> @forbid_moreargs
 >>> def myfunction(a1, a2, *forbidden : Forbidden, kw1, kw2):
...    pass
 >>>

(where Forbidden is a marker object)

As long as we have an agreed upon idiom, it is not really important if it takes 
on more line. Personnaly, I find any of those far more explicit that the lone 
start thinggy.

Baptiste


From ncoghlan at gmail.com  Thu May 25 12:00:32 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 25 May 2006 20:00:32 +1000
Subject: [Python-3000] Immutable lists
In-Reply-To: <4473B9F5.7070701@canterbury.ac.nz>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>	<20060522121249.68B4.JCARLSON@uci.edu>	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>	<44725A6D.5040808@canterbury.ac.nz>
	<4472D271.9010001@gmail.com> <4473B9F5.7070701@canterbury.ac.nz>
Message-ID: <44758040.8030505@gmail.com>

Greg Ewing wrote:
> Nick Coghlan wrote:
> 
>> This is exactly what I was trying to get at when I suggested using 
>> "tuple[T]" as the notation for an arbitrary length tuple with elements 
>> of type T
> 
> If tuple[T] is an arbitrary-length tuple, then how
> do you spell a 1-tuple with element type T?

(T,)

>  > and "T1, T2" as the notation for a 2-tuple with the first
>> element of type T1 and the second element of type T2.
> 
> It's been pointed out that making (T1, T2) equivalent to
> tuple[T1, T2] leads to an inconsistency. That needs to be
> resolved before taking this idea any further.

Yes - I'm saying tuple[T1, T2] should describe an arbitrary length tuple whose 
elements are 2-tuples, *instead* of being equivalent to (T1, T2).

Since we have 2 notations (a tuple of type descriptions, and a subscript 
operation on the tuple type) and 2 concepts to be expressed (a type 
description for a heterogeneous tuple and a type description for an arbitrary 
length tuple), it makes sense to me to use one of the notations for each 
concept rather than making the two notations mean the same thing.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Thu May 25 12:07:25 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 25 May 2006 20:07:25 +1000
Subject: [Python-3000] What makes infix operators special? (was Re: Type
 parameterization
In-Reply-To: <4470411F.2040606@canterbury.ac.nz>
References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com>
	<ca471dc20605182113w19a0b1a8vb9cfe76942a7b4dc@mail.gmail.com>
	<43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com>
	<ca471dc20605191438w352982bcy418169d534de3012@mail.gmail.com>
	<43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com>
	<446E99B8.10500@acm.org>
	<ca471dc20605200737o3cea089n123f5d43427bc31d@mail.gmail.com>
	<446F8C3E.5000009@acm.org>
	<ca471dc20605201626w1302212pb1abe69f367d759b@mail.gmail.com>
	<e4os4a$96v$1@sea.gmane.org> <44701C03.9040407@gmail.com>
	<4470411F.2040606@canterbury.ac.nz>
Message-ID: <447581DD.1020200@gmail.com>

Greg Ewing wrote:
> Nick Coghlan wrote:
> 
>> Using '@' would now be fairly counterintuitive, given that symbol's 
>> association with decorators.
> 
> It would be very disappointing if @ were now considered
> too "polluted" by association with decorators to be used
> for anything else, since it would mean we have lost both
> a potential prefix operator and a potential infix operator
> in one go.
> 
> Personally I don't think there would be any confusion.

Agreed - I've had a look at the relevant PEPs now, and find the S @ T notation 
quite understandable. I'd actually find it interesting to see an iterator that 
abused __mul__ to implement the semantics (i.e. the PEP's concept of "S @ T" 
would be written as "crossproduct(S) * T").

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From ncoghlan at gmail.com  Thu May 25 12:34:52 2006
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 25 May 2006 20:34:52 +1000
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <44750129.50401@canterbury.ac.nz>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
	<44750129.50401@canterbury.ac.nz>
Message-ID: <4475884C.3010606@gmail.com>

Greg Ewing wrote:
> tomer filiba wrote:
>> talin asked for comments, so
>>
>> def f(a, b, *, c, d)
>>
>> seems wrong to me. '*' can't be a token on its own, at least
>> that's the way i see it. opeators shouldn't stand for themselves.
> 
> But * is not an operator here. It's just a token
> with a special meaning in this context.
> 
> I don't really understand why this is so controversial.
> To me, it's the obvious least-change way of introducing
> the feature concerned. As someone said, it's just
> "*args without the args".

While the naked star syntax is fine by me, permitting tuple-expansion for 
*args would also do the trick (as well as permitting positional only arguments).

That is,

def f(a, b, *args, c, d):
     # Arbitrary number of extra positional arguments allowed

def f(a, b, *(pos1, pos2), c, d):
     # Exactly 2 extra positional arguments required

def f(a, b, *(pos1,), c, d):
     # Exactly 1 extra positional argument required

def f(a, b, *(), c, d):
     # Exactly 0 extra positional arguments required
     # (In other words, no extra positional arguments permitted)


Although even that still wouldn't allow the signature for dict.update to be 
expressed correctly. Doing that would require the ability to specify optional 
positional only arguments:

def update(*(self, other=None), **kwds):
     # self & other can still be used as keyword arguments
     # and end up in the kwds dictionary

Just something to consider.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From guido at python.org  Thu May 25 16:10:25 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 25 May 2006 07:10:25 -0700
Subject: [Python-3000] Immutable lists
In-Reply-To: <44758040.8030505@gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
	<44725A6D.5040808@canterbury.ac.nz> <4472D271.9010001@gmail.com>
	<4473B9F5.7070701@canterbury.ac.nz> <44758040.8030505@gmail.com>
Message-ID: <ca471dc20605250710p2d1437c1s19849637c83efa07@mail.gmail.com>

On 5/25/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Yes - I'm saying tuple[T1, T2] should describe an arbitrary length tuple whose
> elements are 2-tuples, *instead* of being equivalent to (T1, T2).
>
> Since we have 2 notations (a tuple of type descriptions, and a subscript
> operation on the tuple type) and 2 concepts to be expressed (a type
> description for a heterogeneous tuple and a type description for an arbitrary
> length tuple), it makes sense to me to use one of the notations for each
> concept rather than making the two notations mean the same thing.

This is growing on me.

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

From guido at python.org  Thu May 25 18:25:29 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 25 May 2006 09:25:29 -0700
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <4475884C.3010606@gmail.com>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
	<44750129.50401@canterbury.ac.nz> <4475884C.3010606@gmail.com>
Message-ID: <ca471dc20605250925h3c17be8dwf43965a1fb61d5c4@mail.gmail.com>

On 5/25/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> def f(a, b, *(pos1, pos2), c, d):
>      # Exactly 2 extra positional arguments required

-1.

This is (nearly?) just an obscure way to say "def f(a, b, pos1, pos2)".

Suggestion to everyone: please stop proposing alternatives. Let's
instead work on implementing the proposal exactly as it stands, so we
can experience it.

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

From pje at telecommunity.com  Thu May 25 18:54:08 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 25 May 2006 12:54:08 -0400
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <mailman.51.1148551229.28026.python-3000@python.org>
Message-ID: <5.1.1.6.0.20060525125040.0485aa18@mail.telecommunity.com>

At 11:42 AM 5/25/2006 +0200, Baptiste Carvello <baptiste13 at altern.org> wrote:
>maybe those use cases can work without syntactic sugar. With only part 1, you
>can already add a manual check if you need:
>
>  >>> def myfunction(a1, a2, *forbidden, kw1, kw2):
>...    assert forbidden is (), "myfunction() takes exactly 2 arguments"
>...    pass
>  >>>

How about:

     def myfunction(a1, a2, *(), kw1, kw2):

This seems to me to mean "an empty varargs parameter" on its face, and it 
has the advantage of being a valid call syntax.  That is, you can already 
invoke "myfunction(1,2,*())" and it's syntactically valid and means the 
same thing.


From greg.ewing at canterbury.ac.nz  Fri May 26 02:15:29 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 26 May 2006 12:15:29 +1200
Subject: [Python-3000] PEP 3102 comments
In-Reply-To: <4475884C.3010606@gmail.com>
References: <1d85506f0605241226s4fdddfe6re859dec2aa88454a@mail.gmail.com>
	<44750129.50401@canterbury.ac.nz> <4475884C.3010606@gmail.com>
Message-ID: <447648A1.30808@canterbury.ac.nz>

Nick Coghlan wrote:

> def f(a, b, *(pos1, pos2), c, d):
>     # Exactly 2 extra positional arguments required

Then someone is going to want

   def f(a, b, *(pos1, pos2, *args), c, d):
       # 2 or more positional-only arguments required

--
Greg


From greg.ewing at canterbury.ac.nz  Fri May 26 02:24:55 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 26 May 2006 12:24:55 +1200
Subject: [Python-3000] Immutable lists
In-Reply-To: <ca471dc20605250710p2d1437c1s19849637c83efa07@mail.gmail.com>
References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com>
	<ca471dc20605220936m58cb7a34xd17dabfb6b353b57@mail.gmail.com>
	<20060522121249.68B4.JCARLSON@uci.edu>
	<43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com>
	<44725A6D.5040808@canterbury.ac.nz> <4472D271.9010001@gmail.com>
	<4473B9F5.7070701@canterbury.ac.nz> <44758040.8030505@gmail.com>
	<ca471dc20605250710p2d1437c1s19849637c83efa07@mail.gmail.com>
Message-ID: <44764AD7.1020006@canterbury.ac.nz>

> On 5/25/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
>>Yes - I'm saying tuple[T1, T2] should describe an arbitrary length tuple whose
>>elements are 2-tuples, *instead* of being equivalent to (T1, T2).

Ah, I see. Yes, that would work, although it would
make tuple somewhat special in that some parameterisations
of it would not be expressible as typename[params].

--
Greg

From mcherm at mcherm.com  Fri May 26 12:46:49 2006
From: mcherm at mcherm.com (Michael Chermside)
Date: Fri, 26 May 2006 06:46:49 -0400
Subject: [Python-3000] State of the object system
In-Reply-To: <446C18A1.1040409@gmx.net>
References: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>
	<446C18A1.1040409@gmx.net>
Message-ID: <327376ff0605260346r1eaf96ebya25efff78ed68a1c@mail.gmail.com>

On 5/18/06, Kay Schluehr <kay.schluehr at gmx.net> wrote:
> Michael Chermside schrieb:
>
> >Unfortunately, for implementation reasons you can't modify most
> >built-in (and some user-defined) classes in this fashion:
> >
> >   >>> int.func2 = func2
> >
> >   Traceback (most recent call last):
> >     File "<pyshell#35>", line 1, in -toplevel-
> >       int.func2 = func2
> >   TypeError: can't set attributes of built-in/extension type 'int'
> >
> >Most Python programmers would probably agree that this is a
> >perfectly fine restriction. Built-in classes like int and dict
> >are widely used... allowing the code from any one module to
> >modify them has dangerously non-local effects.
> >
> And that's not true for user defined classes?

No, it's now. I suspect (this is just a wild guess) that more than half
of all Python modules use int somewhere. I'm guessing nearly
100% use str, and I'm certain 100% use dict. That's just not true
of user defined classes, not even widely used libraries.

> Adding a
> method isprime() or iseven() to a subclass of int will suddenly be lost
> in the resulting object after an operation as long as it is not
> overwritten to return the right type and not the base type. So it is
> questionable if subclassing is really a good design decision.

That's why int subclasses can override both __add__ and __radd__
to ensure that your subclass is returned when combined with normal
ints. But I agree that it's not a good decision... making "isprime()" or
"iseven()" a helper function (not method) is probably a better design.

> AFAIK Ruby doesn't support standalone functions but needs a class
> context to define them as methods. Python might be more liberal in this
> respect but it seems to me that it forces to write functions in certain
> situations.

Yes it is, and while it doesn't *force* you to write functions, if what you
want is really a function, then why work to make it a method? (See Java.)

> Sometimes a broken structure needs more justification than a sound one.
> Arbitrary restrictions complicate the language semantics for no good
> reasons. But if it is strongly encouraged not to add methods to classes
> at runtime we might get rid of the self parameter that lessens the
> barrier between functions and methods?

The barrier between functions and methods is QUITE small in Python,
and the existance of the self parameter is the major reason for this. A
method is just a funciton in which we happen to pass an object instance
as the first argument. (Bound methods are slightly different beasts.) So
I'm not sure what you're suggesting here.

- Michael Chermside

From collinw at gmail.com  Fri May 26 18:51:57 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 26 May 2006 18:51:57 +0200
Subject: [Python-3000] Keep new.instance?
Message-ID: <43aa6ff70605260951x19d769a7v48ec96e692cba60b@mail.gmail.com>

Going through and cleaning up failing tests in the p3yk branch...

Is there any interest in keeping new.instance()? It's defined as
equivalent to types.InstanceType, which is in turn defined as
(effectively)...

"""
class _C:
    pass

InstanceType = type(_C())
"""

Since _C under Python 3 will be new-style, type(_C()) is _C, not <type
'instance'> (as in 2.x).

Is there interest in keeping new.instance()'s functionality (that is,
in allowing users to create instances of a type, bypassing __init__ in
the process)?

Collin Winter

From guido at python.org  Fri May 26 19:13:34 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 26 May 2006 10:13:34 -0700
Subject: [Python-3000] Keep new.instance?
In-Reply-To: <43aa6ff70605260951x19d769a7v48ec96e692cba60b@mail.gmail.com>
References: <43aa6ff70605260951x19d769a7v48ec96e692cba60b@mail.gmail.com>
Message-ID: <ca471dc20605261013h3dbebbf4kae2d27360fb1c9b2@mail.gmail.com>

It should be discarded. You can already create instances bypassing
__init__ by calling __new__.

On 5/26/06, Collin Winter <collinw at gmail.com> wrote:
> Going through and cleaning up failing tests in the p3yk branch...
>
> Is there any interest in keeping new.instance()? It's defined as
> equivalent to types.InstanceType, which is in turn defined as
> (effectively)...
>
> """
> class _C:
>     pass
>
> InstanceType = type(_C())
> """
>
> Since _C under Python 3 will be new-style, type(_C()) is _C, not <type
> 'instance'> (as in 2.x).
>
> Is there interest in keeping new.instance()'s functionality (that is,
> in allowing users to create instances of a type, bypassing __init__ in
> the process)?
>
> Collin Winter
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


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

From jimjjewett at gmail.com  Fri May 26 19:53:22 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 26 May 2006 13:53:22 -0400
Subject: [Python-3000] State of the object system
In-Reply-To: <327376ff0605260346r1eaf96ebya25efff78ed68a1c@mail.gmail.com>
References: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com>
	<446C18A1.1040409@gmx.net>
	<327376ff0605260346r1eaf96ebya25efff78ed68a1c@mail.gmail.com>
Message-ID: <fb6fbf560605261053k54abb4c9pddf161e0430a3cdf@mail.gmail.com>

On 5/26/06, Michael Chermside <mcherm at mcherm.com> wrote:
> On 5/18/06, Kay Schluehr <kay.schluehr at gmx.net> wrote:

> > Adding a
> > method isprime() or iseven() to a subclass of int will suddenly be lost
> > in the resulting object after an operation as long as it is not
> > overwritten to return the right type and not the base type. So it is
> > questionable if subclassing is really a good design decision.

> That's why int subclasses can override both __add__ and __radd__
> to ensure that your subclass is returned when combined with normal
> ints. But I agree that it's not a good decision... making "isprime()" or
> "iseven()" a helper function (not method) is probably a better design.

With strings, you need to override __add__ and __radd__ (which objects
of the base class don't even have), and __mul__ and __rmul__.  Good
luck overriding __str__.

Do also override non-magic methods capitalize, center, join, ljust,
lower, lstrip, replace, rjust, rsplit, rstrip, split, splitlines,
strip, swapcase, title, translate, upper, zfill, perhaps encode and
decode,

I do like Josiah's suggestion that if a method returns an instance of
its own type, it should instead return the derived type for types that
don't bother to override the method.  There is a bit of a corner case
when a method takes multiple arguments (as join does), but I suppose
the resolution used for numbers works well enough.[1]

-jJ

[1]  Assume type(self), but switch to a subclass if one of the other
arguments is strictly more specific.

    class S1(str): pass
    class S2(str): pass

    str() + S1() -> S1
    S1() + S2() -> S1, because S2 is not a subclass of S1

From collinw at gmail.com  Fri May 26 20:58:56 2006
From: collinw at gmail.com (Collin Winter)
Date: Fri, 26 May 2006 20:58:56 +0200
Subject: [Python-3000] Keep new.instance?
In-Reply-To: <ca471dc20605261013h3dbebbf4kae2d27360fb1c9b2@mail.gmail.com>
References: <43aa6ff70605260951x19d769a7v48ec96e692cba60b@mail.gmail.com>
	<ca471dc20605261013h3dbebbf4kae2d27360fb1c9b2@mail.gmail.com>
Message-ID: <43aa6ff70605261158h13f8fde9w1bb02c5f438bd1c3@mail.gmail.com>

On 5/26/06, Guido van Rossum <guido at python.org> wrote:
> It should be discarded. You can already create instances bypassing
> __init__ by calling __new__.

SF patch #1495675 (http://python.org/sf/1495675) does the trick; I've
assigned it to you.

Collin Winter

From greg.ewing at canterbury.ac.nz  Sat May 27 03:09:04 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 27 May 2006 13:09:04 +1200
Subject: [Python-3000] Keep new.instance?
In-Reply-To: <43aa6ff70605260951x19d769a7v48ec96e692cba60b@mail.gmail.com>
References: <43aa6ff70605260951x19d769a7v48ec96e692cba60b@mail.gmail.com>
Message-ID: <4477A6B0.9080601@canterbury.ac.nz>

Collin Winter wrote:

> Is there interest in keeping new.instance()'s functionality (that is,
> in allowing users to create instances of a type, bypassing __init__ in
> the process)?

Doesn't C.__new__ already do this for a new-style class C?

--
Greg

From tomerfiliba at gmail.com  Sat May 27 15:15:32 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Sat, 27 May 2006 15:15:32 +0200
Subject: [Python-3000] a slight change to __[get|set|del]item__
Message-ID: <1d85506f0605270615i7d3e4befp78285b794f57a962@mail.gmail.com>

it's a minor issue, but i thought i should bring it up anyway:

today, __getitem__ et al take a single argument. inside the indexer,
however,
multiple items may be passed. if only one argument is passed, it is passed
as-is to __getitem__; however, when multiple arguments are passed, a tuple
is passed to __getitem__. for example:

>>> class x(object):
...     def __getitem__(self, index):
...         print index
...
>>> y = x()
>>> y[1]
1
>>> y[1,2]
(1, 2)

which makes it impossible to diffrenciate between
>>> y[1, 2]
(1, 2)

and
>>> y[(1, 2)]
(1, 2)

etc.

i'd suggest to change __getitem__'s signature to __getitem__(self,
*indexes),
but this causes a problem with __setitem__(self, *indexes, value)... so in
order
to make it uniform, why not always pass a tuple? even in the case of a
single
argument.

i.e.,
>>> y[1]
(1,)
>>> y[1,2]
(1, 2)
>>> y[(1,2)]
((1, 2),)

i.e., __getitem__(self, indexes), where `indexes` is like a tuple of
everything that
was passed in the brackets.

functions that expect only one index, would be defined
def __getitem__(self, (index,)):
    ....

and you even get the bonus of simplifying (and slightly optimizing) the code
of the
bytecode-engine that calls __getitem__ -- it just passes the tuple without
second
thoughts.

think it's worth it? i find it more explicit, as today it's not clear
whether you
pass [(1,2)] or [1,2]. it's a subtle corner, but i'd suggest cleaning it up
as well.


-tomer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060527/d03922af/attachment.html 

From phd at mail2.phd.pp.ru  Sat May 27 15:36:16 2006
From: phd at mail2.phd.pp.ru (Oleg Broytmann)
Date: Sat, 27 May 2006 17:36:16 +0400
Subject: [Python-3000] a slight change to __[get|set|del]item__
In-Reply-To: <1d85506f0605270615i7d3e4befp78285b794f57a962@mail.gmail.com>
References: <1d85506f0605270615i7d3e4befp78285b794f57a962@mail.gmail.com>
Message-ID: <20060527133616.GB20800@phd.pp.ru>

On Sat, May 27, 2006 at 03:15:32PM +0200, tomer filiba wrote:
> which makes it impossible to diffrenciate between
> >>>y[1, 2]
> (1, 2)
> 
> and
> >>>y[(1, 2)]
> (1, 2)

   Tuples are not created with parenthesizes. Tuples are created with a comma. Hence

1, 2

   *is* a tuple. Just as (1, 2).

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From just at letterror.com  Sat May 27 18:10:59 2006
From: just at letterror.com (Just van Rossum)
Date: Sat, 27 May 2006 18:10:59 +0200
Subject: [Python-3000] a slight change to __[get|set|del]item__
In-Reply-To: <20060527133616.GB20800@phd.pp.ru>
Message-ID: <r01050400-1039-645914A2ED9B11DA8E5C001124365170@[10.0.0.24]>

Oleg Broytmann wrote:

> On Sat, May 27, 2006 at 03:15:32PM +0200, tomer filiba wrote:
> > which makes it impossible to diffrenciate between
> > >>>y[1, 2]
> > (1, 2)
> > 
> > and
> > >>>y[(1, 2)]
> > (1, 2)
> 
>    Tuples are not created with parenthesizes. Tuples are created with
a comma. Hence
> 
> 1, 2
> 
>    *is* a tuple. Just as (1, 2).

But

    foo(1, 2)

isn't the same as

    foo((1, 2))

Just

From collinw at gmail.com  Sat May 27 22:48:13 2006
From: collinw at gmail.com (Collin Winter)
Date: Sat, 27 May 2006 22:48:13 +0200
Subject: [Python-3000] Using a list for *args (was: Type annotations:
	annotating generators)
Message-ID: <43aa6ff70605271348y352921f6he107ba1f40a0393a@mail.gmail.com>

On 5/21/06, Guido van Rossum <guido at python.org> wrote:
> Since **kwds is already a dict (i.e. a mutable container) and since we
> long accept a list for *vargs on the call side, I think it is actually
> more logical to use a list for receiving *args.

I'm working on implementing this change and have a question: a number
of places in the stdlib do some processing on *args, then return the
result (currently a tuple). Changing *args to a list means that these
functions now also return lists.

My question is this: should these functions keep returning tuples or
should they (and their tests and docs) be updated to use lists? The
former introduces extra implementation complexity, while the latter
adds backwards compatibility issues.

Collin Winter

From guido at python.org  Tue May 30 05:28:24 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 29 May 2006 20:28:24 -0700
Subject: [Python-3000] a slight change to __[get|set|del]item__
In-Reply-To: <r01050400-1039-645914A2ED9B11DA8E5C001124365170@10.0.0.24>
References: <20060527133616.GB20800@phd.pp.ru>
	<r01050400-1039-645914A2ED9B11DA8E5C001124365170@10.0.0.24>
Message-ID: <ca471dc20605292028l1eeff1bo3ba44065efdef889@mail.gmail.com>

On 5/27/06, Just van Rossum <just at letterror.com> wrote:
> Oleg Broytmann wrote:
>
> > On Sat, May 27, 2006 at 03:15:32PM +0200, tomer filiba wrote:
> > > which makes it impossible to diffrenciate between
> > > >>>y[1, 2]
> > > (1, 2)
> > >
> > > and
> > > >>>y[(1, 2)]
> > > (1, 2)
> >
> >    Tuples are not created with parenthesizes. Tuples are created with
> a comma. Hence
> >
> > 1, 2
> >
> >    *is* a tuple. Just as (1, 2).
>
> But
>
>     foo(1, 2)
>
> isn't the same as
>
>     foo((1, 2))

Because the (...) in a function call isn't a tuple.

I'm with Oleg -- a[x, y] is *intentionally* the same as a[(x, y)].
This is a feature; you can write

   t = x, y    # or t = (x, y)

and later

  a[t]

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

From guido at python.org  Tue May 30 05:30:06 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 29 May 2006 20:30:06 -0700
Subject: [Python-3000] Using a list for *args (was: Type annotations:
	annotating generators)
In-Reply-To: <43aa6ff70605271348y352921f6he107ba1f40a0393a@mail.gmail.com>
References: <43aa6ff70605271348y352921f6he107ba1f40a0393a@mail.gmail.com>
Message-ID: <ca471dc20605292030q4f13b9fv7df3397edaab537@mail.gmail.com>

Please be specific. Which places are affected? This shouldn't be
answered generically but on a case-by-case basis.

--Guido

On 5/27/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/21/06, Guido van Rossum <guido at python.org> wrote:
> > Since **kwds is already a dict (i.e. a mutable container) and since we
> > long accept a list for *vargs on the call side, I think it is actually
> > more logical to use a list for receiving *args.
>
> I'm working on implementing this change and have a question: a number
> of places in the stdlib do some processing on *args, then return the
> result (currently a tuple). Changing *args to a list means that these
> functions now also return lists.
>
> My question is this: should these functions keep returning tuples or
> should they (and their tests and docs) be updated to use lists? The
> former introduces extra implementation complexity, while the latter
> adds backwards compatibility issues.
>
> Collin Winter
>


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

From talin at acm.org  Tue May 30 05:51:02 2006
From: talin at acm.org (Talin)
Date: Mon, 29 May 2006 20:51:02 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
References: <44716940.9000300@acm.org>	
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>	
	<1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com>	
	<1148318480.19392.6.camel@fsol>	
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>	
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
Message-ID: <447BC126.8050107@acm.org>

Guido van Rossum wrote:
> I have to ignore this topic. It's too big and contentious to get easy
> agreement. (The one thing I *don't* want is move the entire stdlib
> hierarchy under 'py' or something like that.) Eric Raymond once made
> detailed proposal, you can probably still find it somewhere. Good
> luck!
> 

Well, it looks like it wasn't that contentious after all :)

Actually, I'm kind of surprised that there wasn't more comments on this. 
Part of my purpose in posting a strawman proposal was to generate 
discussion, and from that discussion see if I could derive a set of 
guidelines or principles that could be used to generate a more serious 
proposal. So in a sense my posting was a trojan horse intended to gather 
data; Perhaps everyone was smart enough to see through this strategem 
and decline to comment. :)

Looking over the general Py3K roadmap, and ignoring various wild-eyed 
proposals for new features (my own included), it seems to me that the 
two biggest areas of cruft cleanup that have not been fully addressed 
are 1) the organization of the standard library, and 2) The refactoring 
of the import/package facility. I'm not really interested in creating 
proposals for either of these, what I am more interested in is 
organizing other people's proposals and in particular resolving 
conflicts (which is effectively what I am trying to do with 3101.)

-- Talin

>> Well, in that case, let me ask this: What would be the general
>> parameters / requirements of the re-organization? I mean, any programmer
>> can come along and divide up things into categories, but I suspect that
>> there are subtler requirements than that.
>>
>> Here are some examples of some requirements that I can think of:
>>
>> 1) No mass renaming of modules unless there's something seriously wrong
>> with the existing name.
>>
>> 2) For most cases, I suspect that you will want to add no more than one
>> additional level to the hierarchy. Namespaces will still be fairly flat,
>> with large numbers of items per namespace, but not quite as broad and
>> flat as they are today. (In other words, avoid deep nesting - we don't
>> want to have to type sys.runtime.types.containers.UserDict.UserDict.)
>>
>> So that people will have something to argue about, I'd suggest the
>> following as a top-level category list. Note that only a small amount of
>> thought has gone into this :)
>>
>>     sys - contains the existing sys, plus atexit, site, user, etc.
>>
>>     rt - runtime modules - gc, fpectl, inspect, etc.
>>
>>     types - existing types module, mixin types, type predicates.
>>
>>     persist - marshall, pickle, shelve, etc. Possibly zip and
>>        maybe ConfigParser
>>
>>     imp - import machinery - existing imp, zipimport, pkgutil,
>>        modulefinder
>>
>>     string - existing string, plus repr, pprint, textwrap, stringprep.
>>        Possibly fnmatch.
>>
>>     encoding - codecs, unicodedata
>>        Example: net.protocols.http
>>
>>     conversions - data conversion modules - fpformat
>>
>>     re - regular expressions - unchanged
>>
>>     collection - existing collections, queue, heapq, array
>>        Example: collections.array.array
>>
>>     algorithms - diff, random, whrandom
>>
>>     testing - doctest, unittest, test, test_support
>>
>>     math - existing math, decimal, cmath
>>        Example: math.decimal
>>
>>     doc - documentation tools - pydoc
>>
>>     itertools - unchanged
>>
>>     functional - unchanged
>>
>>     console - cmd, shlex, curses*, getopt, optparse, readline,
>>       rlcompleter
>>
>>     os - existing os plus errno
>>
>>     os.path - as-is
>>
>>     os.file - existing os.file plus fileinput, tempfile, filecmp,
>>       mmap
>>
>>     os.dir - existing os.dir plus dircache, stat*, glob, shutil
>>
>>     os.stream - popen*
>>
>>     os.process - subprocess, signal
>>
>>     os.socket - existing socket, select
>>
>>     os.thread - existing threading, mutex
>>
>>     os.posix - posix-specific
>>
>>     os.win32 - win32-specific
>>
>>     os.osx - osx-specific
>>
>>     locale - unchanged
>>
>>     logging - unchanged
>>
>>     platform - unchanged
>>
>>     compression - zlib, gzip, bz2, etc. (Or perhaps an 'archive'
>>       module including 'tar'.)
>>
>>     db - database packages - the various databases, gdbm, bsddb, etc.
>>
>>     debug - pdb, bdb, etc.
>>
>>     profile - profiler, hotshot, etc.
>>
>>     net.protocols - http, imap, pop, ftp, etc.
>>        Example: net.protocols.http
>>
>>     net.formats - mail, mime, binhex, etc.
>>        Example: net.formats.mime
>>
>>     net.tools - webbrowser, SocketServer, robotparser, etc.
>>
>>     xml.* - xml-related packages
>>        Example: xml.sax
>>
>>     media.audio - audio packages
>>
>>     media.image - image conversion packages
>>
>>     rexec - rename to 'restrict' (Too much confusion with 'regex')
>>
>>     python - python language services (compiler, parser, etc.)
>>
>>
>> -- Talin

From guido at python.org  Tue May 30 06:00:04 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 29 May 2006 21:00:04 -0700
Subject: [Python-3000] [Python-Dev] Integer representation (Was: ssize_t
	question: longs in header files)
In-Reply-To: <447B7189.30408@v.loewis.de>
References: <ee2a432c0605282315s6cb5743bj4a37009a03ebbca2@mail.gmail.com>
	<447B66B7.90107@v.loewis.de>
	<9e804ac0605291433x54dd64e7o10acfc3076f5ffb0@mail.gmail.com>
	<447B6B1A.2020107@v.loewis.de>
	<9e804ac0605291457s784e6089ge84e6315feb2c3cd@mail.gmail.com>
	<447B7189.30408@v.loewis.de>
Message-ID: <ca471dc20605292100q16f57fe1qd645596ad1492dae@mail.gmail.com>

[Adding the py3k list; please remove python-dev in followups.]

On 5/29/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I thought Py3k will have a single integer type whose representation
> varies depending on the value being represented.

That's one proposal. Another is to have an abstract 'int' type with
two concrete subtypes, e.g. 'short' and 'long', corresponding to
today's int and long. At the C level the API should be unified so C
programmers are isolated from the difference (they aren't today).

> I haven't seen an actual proposal for such a type,

I'm not sure that my proposal above has ever been said out loud. I'm
also not partial; I think we may have to do an experiment to decide.

> so let me make one:
>
> struct PyInt{
>   struct PyObject ob;
>   Py_ssize_t value_or_size;
>   char is_long;
>   digit ob_digit[1];
> };
>
> If is_long is false, then value_or_size is the value (represented
> as Py_ssize_t), else the value is in ob_digit, and value_or_size
> is the size.

Nice. I guess if we store the long value in big-endian order we could
drop is_long, since the first digit of the long would always be
nonzero. This would save a byte (on average) for the longs, but it
would do nothing for the wasted space for short ints.

> PyLong_* will be synonyms for PyInt_*.

Why do we need to keep the PyLong_* APIs at all? Even at the Python
level we're not planning any backward compatibility features; at the C
level I like even more freedom to break things.

> PyInt_FromLong/AsLong will
> continue to exist; PyInt_AsLong will indicate an overflow with -1.
> Likewise, PyArg_ParseTuple "i" will continue to produce int, and
> raise an exception (OverflowError?) when the value is out of range.
>
> C code can then decide whether to parse a Python integer as
> C int, long, long long, or ssize_t.

Nice. I like the unified API and I like using Py_ssize_t instead of
long for the value; this ensures that an int can hold a pointer (if we
allow for signed pointers) and matches the native word size better on
Windows (I guess it makes no difference for any other platform, where
ssize_t and long already have the same size).

I worry about all the wasted space for alignment caused by the extra
flag byte though. That would be 4 byte per integer on 32-bit machines
(where they are currently 12 bytes) and 8 bytes on 64-bit machines
(where they are currently 24 bytes).

That's why I'd like my alternative proposal (int as ABC and two
subclasses that may remain anonymous to the Python user); it'll save
the alignment waste for short ints and will let us use a smaller int
type for the size for long ints (if we care about the latter).

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

From martin at v.loewis.de  Tue May 30 07:26:10 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 30 May 2006 07:26:10 +0200
Subject: [Python-3000] [Python-Dev] Integer representation (Was: ssize_t
 question: longs in header files)
In-Reply-To: <ca471dc20605292100q16f57fe1qd645596ad1492dae@mail.gmail.com>
References: <ee2a432c0605282315s6cb5743bj4a37009a03ebbca2@mail.gmail.com>	
	<447B66B7.90107@v.loewis.de>	
	<9e804ac0605291433x54dd64e7o10acfc3076f5ffb0@mail.gmail.com>	
	<447B6B1A.2020107@v.loewis.de>	
	<9e804ac0605291457s784e6089ge84e6315feb2c3cd@mail.gmail.com>	
	<447B7189.30408@v.loewis.de>
	<ca471dc20605292100q16f57fe1qd645596ad1492dae@mail.gmail.com>
Message-ID: <447BD772.3090303@v.loewis.de>

Guido van Rossum wrote:
>> struct PyInt{
>>   struct PyObject ob;
>>   Py_ssize_t value_or_size;
>>   char is_long;
>>   digit ob_digit[1];
>> };
>>
> 
> Nice. I guess if we store the long value in big-endian order we could
> drop is_long, since the first digit of the long would always be
> nonzero. This would save a byte (on average) for the longs, but it
> would do nothing for the wasted space for short ints.

Right; alternatively, the top-most bit of ob_digit[0] could also be
used, as longs have currently 15-bit digits.

> Why do we need to keep the PyLong_* APIs at all? Even at the Python
> level we're not planning any backward compatibility features; at the C
> level I like even more freedom to break things.

Indeed, they should get dropped.

> I worry about all the wasted space for alignment caused by the extra
> flag byte though. That would be 4 byte per integer on 32-bit machines
> (where they are currently 12 bytes) and 8 bytes on 64-bit machines
> (where they are currently 24 bytes).

I think ints should get managed by PyMalloc in Py3k. With my proposal,
an int has 16 bytes on a 32-bit machine, so there wouldn't be any
wastage for PyMalloc (which allocates 16 bytes for 12-byte objects,
anyway). On a 64-bit machine, it would indeed waste 8 bytes per
int.

> That's why I'd like my alternative proposal (int as ABC and two
> subclasses that may remain anonymous to the Python user); it'll save
> the alignment waste for short ints and will let us use a smaller int
> type for the size for long ints (if we care about the latter).

I doubt they can remain anonymous. People often dispatch by type
(e.g. pickle, xmlrpclib, ...), and need to put the type into a
dictionary. If the type is anonymous, they will do

   dispatch[type(0)] = marshal_int
   dispatch[type(sys.maxint+1)] = marshal_int

Plus, their current code as

   dispatch[int] = marshal_int

which will silently break (although it won't be silent if they also
have dispatch[long] = marshal_long).

Regards,
Martin


From just at letterror.com  Tue May 30 09:27:49 2006
From: just at letterror.com (Just van Rossum)
Date: Tue, 30 May 2006 09:27:49 +0200
Subject: [Python-3000] a slight change to __[get|set|del]item__
In-Reply-To: <ca471dc20605292028l1eeff1bo3ba44065efdef889@mail.gmail.com>
Message-ID: <r01050400-1039-CF337978EFAD11DA8E5C001124365170@[10.0.0.24]>

Guido van Rossum wrote:

> On 5/27/06, Just van Rossum <just at letterror.com> wrote:
> > Oleg Broytmann wrote:
> >
> > > On Sat, May 27, 2006 at 03:15:32PM +0200, tomer filiba wrote:
> > > > which makes it impossible to diffrenciate between
> > > > >>>y[1, 2]
> > > > (1, 2)
> > > >
> > > > and
> > > > >>>y[(1, 2)]
> > > > (1, 2)
> > >
> > > Tuples are not created with parenthesizes. Tuples are created with
> > > a comma. Hence
> > >
> > > 1, 2
> > >
> > >    *is* a tuple. Just as (1, 2).
> >
> > But
> >
> >     foo(1, 2)
> >
> > isn't the same as
> >
> >     foo((1, 2))
> 
> Because the (...) in a function call isn't a tuple.
> 
> I'm with Oleg -- a[x, y] is *intentionally* the same as a[(x, y)].
[ ... ]

FWIW: I wasn't agreeing with Tomer, just pointing out what I think was
his intention, and that Oleg's argument against it doesn't hold, given
how call syntax works.

Just

From greg.ewing at canterbury.ac.nz  Tue May 30 10:56:25 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 30 May 2006 20:56:25 +1200
Subject: [Python-3000] [Python-Dev] Integer representation (Was: ssize_t
 question: longs in header files)
In-Reply-To: <447BD772.3090303@v.loewis.de>
References: <ee2a432c0605282315s6cb5743bj4a37009a03ebbca2@mail.gmail.com>
	<447B66B7.90107@v.loewis.de>
	<9e804ac0605291433x54dd64e7o10acfc3076f5ffb0@mail.gmail.com>
	<447B6B1A.2020107@v.loewis.de>
	<9e804ac0605291457s784e6089ge84e6315feb2c3cd@mail.gmail.com>
	<447B7189.30408@v.loewis.de>
	<ca471dc20605292100q16f57fe1qd645596ad1492dae@mail.gmail.com>
	<447BD772.3090303@v.loewis.de>
Message-ID: <447C08B9.3050004@canterbury.ac.nz>

Martin v. L?wis wrote:

>    dispatch[type(sys.maxint+1)] = marshal_int

And presumably sys.maxint would be renamed sys.maxshort?

--
Greg

From talin at acm.org  Tue May 30 12:13:07 2006
From: talin at acm.org (Talin)
Date: Tue, 30 May 2006 03:13:07 -0700
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
Message-ID: <447C1AB3.5000602@acm.org>

I want to take a stab at unifying a number of ideas that have been 
proposed recently:

    -- defaultdict - the desire to allow for a 'default' value that
       doesn't get evaluated unless its needed.

    -- the 'shortcut' operators 'and' and 'or', which aren't overloadable
       because the current overloading mechanism won't handle the
       current shortcut behavior.

    -- various proposals with generators, list comprehensions, lambda,
       etc.

Lets take the first case, defaultdict. The original motivation was to be 
able to do something like:

    a.setdefault( key, [] )

...but avoid the evaluation of the list creation unless it was actually 
needed. The (eventual) proposed solution was to create a special 
subclass of dict that would have a factory attribute for creating values 
as needed.

However, I can think of a number of use cases which defaultdict doesn't 
address. For example - suppose I have two dictionaries that I wish to 
search, such that if I don't find a value in the first, I want to look 
in the second; And if I don't find a value in the second, I want to 
default to zero. (This pattern happens to me rather a lot - because I 
tend to do a lot of stuff with parsing and nested symbol tables.)

One simple but inefficient way to code this would be:

    value = a.getitem( key, b.getitem( key, 0 ) )

The problem here, of course, is that the second lookup gets performed 
regardless of whether it is needed. Instead, you have to code something 
like this:

    if hasattr( a, key ):
       value = a.getitem( key )
    else:
       value = b.getitem( key, 0 )

or even:

    try:
       value = a[ key ]
    except KeyError:
       value = b.getitem( key, 0 )

Now, suppose that getitem() expected the second argument to be a factory 
function instead of an actual value, in which case you'd write it like this:

    value = a.getitem( key, lambda: b.getitem( key, 0 ) )

The problem with this, of course, is that you now have to have a special 
version of "getitem" which expects a callable instead of a value.

What if, instead, there was a way to mark a calculation as "lazy", 
meaning that instead of actually doing the calculation, it would instead 
insert a generator-like object which would produce the value the first 
time it is accessed. Lets assume for a moment that they keyword 'lazy' 
is used to indicate this situation (more likely it would be an operator, 
but for simplicity I'll use a keyword):

    value = a.getitem( key, lazy b.getitem( key, 0 ) )

So 'lazy' is kind of like an implicit lambda - that is, it acts like a 
parameterless lambda that auto-evaluates itself at the right time.

Similarly, the 'setdefault' case becomes:

    a.setdefault( key, lazy [] ).append( item )

In other words, the creation of the list isn't actually evaluated unless 
it is needed.

Now, from an implementation standpoint, the implementation of a 
generator-like construction isn't terribly hard; The difficult problem 
is invoking the generator upon first use. There's no explicit protocol 
that signals a value that it is being "used" as a function argument. You 
generally can't write a class that somehow 'detects' whether or not a 
function is retrieved from the function's argument list.

One way around that would be to have the 'lazy' attribute associated 
with the formal parameter of the called function instead:

    def getitem( self, key, lazy default_val ):
       ...

Unfortunately, this breaks the "no programmable syntax" rule - because 
there's no way for a given program to know whether or not the function 
being called has a lazy argument or not. I don't know of a way around 
this, to be honest, so this idea won't work unless someone out there has 
some clever idea that I haven't thought of.

However, it is still interesting to consider what the ramifications of 
such a feature might be. For one thing, it makes the implementation of 
__and__ and __or__ shortcut operators trivial:

    def __and__( self, lazy second ):
       ...

    def __or__( self, lazy second ):
       ...

And in fact, you could even do LISP-ish like statements such as 'cond':

    def cond( self, test, lazy result1, lazy result2 ):
       ...

...or any other non-looping control construct (switch, etc.). (I say 
non-looping because I assume that lazy values aren't re-evaluable like 
callables, i.e. the lazy generator is replaced with its output on first 
use.) This gets into the realm of 'evil' hidden control-flow-modifiers 
and such.

Anyway, I realize that this is not doable (not without drastically 
changing the nature of Python), but it's still interesting to think about.

-- Talin

From brett at python.org  Tue May 30 18:25:49 2006
From: brett at python.org (Brett Cannon)
Date: Tue, 30 May 2006 09:25:49 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <447BC126.8050107@acm.org>
References: <44716940.9000300@acm.org>
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
	<1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com>
	<1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
Message-ID: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>

On 5/29/06, Talin <talin at acm.org> wrote:
>
> Guido van Rossum wrote:
> > I have to ignore this topic. It's too big and contentious to get easy
> > agreement. (The one thing I *don't* want is move the entire stdlib
> > hierarchy under 'py' or something like that.) Eric Raymond once made
> > detailed proposal, you can probably still find it somewhere. Good
> > luck!
> >
>
> Well, it looks like it wasn't that contentious after all :)
>
> Actually, I'm kind of surprised that there wasn't more comments on this.
> Part of my purpose in posting a strawman proposal was to generate
> discussion, and from that discussion see if I could derive a set of
> guidelines or principles that could be used to generate a more serious
> proposal. So in a sense my posting was a trojan horse intended to gather
> data; Perhaps everyone was smart enough to see through this strategem
> and decline to comment. :)



I didn't say anything since I am a little burned out on the topic from the
last time I tried to bring this up.  But I do want to get this going since I
think it will take a while to get any form of consensus.

So, first step in my mind is settling if we want to add one more depth to
the stdlib, and if so, how we want to group (not specific groupings, just
general guidelines).

-Brett


Looking over the general Py3K roadmap, and ignoring various wild-eyed
> proposals for new features (my own included), it seems to me that the
> two biggest areas of cruft cleanup that have not been fully addressed
> are 1) the organization of the standard library, and 2) The refactoring
> of the import/package facility. I'm not really interested in creating
> proposals for either of these, what I am more interested in is
> organizing other people's proposals and in particular resolving
> conflicts (which is effectively what I am trying to do with 3101.)



I think what needs to happen is decide if we want to group modules into
packages (but no deeper than a single depth), and then how to handle general
naming (e.g., net.http, net.httplib, http, or httplib?).


-- Talin
>
> >> Well, in that case, let me ask this: What would be the general
> >> parameters / requirements of the re-organization? I mean, any
> programmer
> >> can come along and divide up things into categories, but I suspect that
> >> there are subtler requirements than that.
> >>
> >> Here are some examples of some requirements that I can think of:
> >>
> >> 1) No mass renaming of modules unless there's something seriously wrong
> >> with the existing name.
> >>
> >> 2) For most cases, I suspect that you will want to add no more than one
> >> additional level to the hierarchy. Namespaces will still be fairly
> flat,
> >> with large numbers of items per namespace, but not quite as broad and
> >> flat as they are today. (In other words, avoid deep nesting - we don't
> >> want to have to type sys.runtime.types.containers.UserDict.UserDict.)
> >>
> >> So that people will have something to argue about, I'd suggest the
> >> following as a top-level category list. Note that only a small amount
> of
> >> thought has gone into this :)
> >>
> >>     sys - contains the existing sys, plus atexit, site, user, etc.
> >>
> >>     rt - runtime modules - gc, fpectl, inspect, etc.
> >>
> >>     types - existing types module, mixin types, type predicates.
> >>
> >>     persist - marshall, pickle, shelve, etc. Possibly zip and
> >>        maybe ConfigParser
> >>
> >>     imp - import machinery - existing imp, zipimport, pkgutil,
> >>        modulefinder
> >>
> >>     string - existing string, plus repr, pprint, textwrap, stringprep.
> >>        Possibly fnmatch.
> >>
> >>     encoding - codecs, unicodedata
> >>        Example: net.protocols.http
> >>
> >>     conversions - data conversion modules - fpformat
> >>
> >>     re - regular expressions - unchanged
> >>
> >>     collection - existing collections, queue, heapq, array
> >>        Example: collections.array.array
> >>
> >>     algorithms - diff, random, whrandom
> >>
> >>     testing - doctest, unittest, test, test_support
> >>
> >>     math - existing math, decimal, cmath
> >>        Example: math.decimal
> >>
> >>     doc - documentation tools - pydoc
> >>
> >>     itertools - unchanged
> >>
> >>     functional - unchanged
> >>
> >>     console - cmd, shlex, curses*, getopt, optparse, readline,
> >>       rlcompleter
> >>
> >>     os - existing os plus errno
> >>
> >>     os.path - as-is
> >>
> >>     os.file - existing os.file plus fileinput, tempfile, filecmp,
> >>       mmap
> >>
> >>     os.dir - existing os.dir plus dircache, stat*, glob, shutil
> >>
> >>     os.stream - popen*
> >>
> >>     os.process - subprocess, signal
> >>
> >>     os.socket - existing socket, select
> >>
> >>     os.thread - existing threading, mutex
> >>
> >>     os.posix - posix-specific
> >>
> >>     os.win32 - win32-specific
> >>
> >>     os.osx - osx-specific
> >>
> >>     locale - unchanged
> >>
> >>     logging - unchanged
> >>
> >>     platform - unchanged
> >>
> >>     compression - zlib, gzip, bz2, etc. (Or perhaps an 'archive'
> >>       module including 'tar'.)
> >>
> >>     db - database packages - the various databases, gdbm, bsddb, etc.
> >>
> >>     debug - pdb, bdb, etc.
> >>
> >>     profile - profiler, hotshot, etc.
> >>
> >>     net.protocols - http, imap, pop, ftp, etc.
> >>        Example: net.protocols.http
> >>
> >>     net.formats - mail, mime, binhex, etc.
> >>        Example: net.formats.mime
> >>
> >>     net.tools - webbrowser, SocketServer, robotparser, etc.
> >>
> >>     xml.* - xml-related packages
> >>        Example: xml.sax
> >>
> >>     media.audio - audio packages
> >>
> >>     media.image - image conversion packages
> >>
> >>     rexec - rename to 'restrict' (Too much confusion with 'regex')
> >>
> >>     python - python language services (compiler, parser, etc.)
> >>
> >>
> >> -- Talin
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060530/ce0a0616/attachment.htm 

From steven.bethard at gmail.com  Tue May 30 19:32:16 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Tue, 30 May 2006 11:32:16 -0600
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
References: <44716940.9000300@acm.org>
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
	<1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com>
	<1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
Message-ID: <d11dcfba0605301032m647094d2tcfe814ba190bfa21@mail.gmail.com>

On 5/30/06, Brett Cannon <brett at python.org> wrote:
> So, first step in my mind is settling if we want to add one more depth to
> the stdlib, and if so, how we want to group (not specific groupings, just
> general guidelines).

I think that having a package level that exactly matches the divisions
in the Library Reference (http://docs.python.org/lib/lib.html) would
be great.  Currently, that would mean packages for:

3. Python Runtime Services
4. String Services
5. Miscellaneous Services
6. Generic Operating System Services
7. Optional Operating System Services
8. Unix Specific Services
9. The Python Debugger
10. The Python Profiler
11. Internet Protocols and Support
12. Internet Data Handling
13. Structured Markup Processing Tools
14. Multimedia Services
15. Cryptographic Services
16. Graphical User Interfaces with Tk
17. Restricted Execution
18. Python Language Services
19. Python compiler package
20. SGI IRIX Specific Services
21. SunOS Specific Services
22. MS Windows Specific Services

So we should first determine what's wrong (if anything) with the list
above, and fix it.  From there we can decide what else needs to be
done.

STeVe
-- 
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From jcarlson at uci.edu  Tue May 30 19:49:13 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 30 May 2006 10:49:13 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <d11dcfba0605301032m647094d2tcfe814ba190bfa21@mail.gmail.com>
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<d11dcfba0605301032m647094d2tcfe814ba190bfa21@mail.gmail.com>
Message-ID: <20060530104546.695F.JCARLSON@uci.edu>


"Steven Bethard" <steven.bethard at gmail.com> wrote:
> 
> On 5/30/06, Brett Cannon <brett at python.org> wrote:
> > So, first step in my mind is settling if we want to add one more depth to
> > the stdlib, and if so, how we want to group (not specific groupings, just
> > general guidelines).
> 
> I think that having a package level that exactly matches the divisions
> in the Library Reference (http://docs.python.org/lib/lib.html) would
> be great.  Currently, that would mean packages for:

Agreed.

Though I'm probably a bit strange in that I almost want a top level "py"
package, and a separating of site-packages from the sys.path and into a
top level package named "site".

The former would make clear that you expect the module to be in the
standard library, and the latter would make clear that you want a
site-packages-specific module/package.

 - Josiah


From jcarlson at uci.edu  Tue May 30 20:09:59 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 30 May 2006 11:09:59 -0700
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <447C1AB3.5000602@acm.org>
References: <447C1AB3.5000602@acm.org>
Message-ID: <20060530102903.6959.JCARLSON@uci.edu>


Talin <talin at acm.org> wrote:
> 
> I want to take a stab at unifying a number of ideas that have been 
> proposed recently:

1. It's either a strange way of spelling lambda, and doesn't gain
anything except a reduction in typing by 1 character.
2. Or it's a strange way of deferring evaluation of a line in the
current stackframe.

Either way, -1.

 - Josiah


From guido at python.org  Tue May 30 20:16:44 2006
From: guido at python.org (Guido van Rossum)
Date: Tue, 30 May 2006 11:16:44 -0700
Subject: [Python-3000] [Python-Dev] Integer representation (Was: ssize_t
	question: longs in header files)
In-Reply-To: <447BD772.3090303@v.loewis.de>
References: <ee2a432c0605282315s6cb5743bj4a37009a03ebbca2@mail.gmail.com>
	<447B66B7.90107@v.loewis.de>
	<9e804ac0605291433x54dd64e7o10acfc3076f5ffb0@mail.gmail.com>
	<447B6B1A.2020107@v.loewis.de>
	<9e804ac0605291457s784e6089ge84e6315feb2c3cd@mail.gmail.com>
	<447B7189.30408@v.loewis.de>
	<ca471dc20605292100q16f57fe1qd645596ad1492dae@mail.gmail.com>
	<447BD772.3090303@v.loewis.de>
Message-ID: <ca471dc20605301116k15601d76v3f16a1588e60ce68@mail.gmail.com>

[Removing python-dev from the CC list]

On 5/29/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > That's why I'd like my alternative proposal (int as ABC and two
> > subclasses that may remain anonymous to the Python user); it'll save
> > the alignment waste for short ints and will let us use a smaller int
> > type for the size for long ints (if we care about the latter).
>
> I doubt they can remain anonymous. People often dispatch by type
> (e.g. pickle, xmlrpclib, ...), and need to put the type into a
> dictionary. If the type is anonymous, they will do
>
>    dispatch[type(0)] = marshal_int
>    dispatch[type(sys.maxint+1)] = marshal_int
>
> Plus, their current code as
>
>    dispatch[int] = marshal_int
>
> which will silently break (although it won't be silent if they also
> have dispatch[long] = marshal_long).

Fair enough.

I'm not sure what the downside of exposing "short" and "long" would
be, as long as it remains limited to places where people dispatch on
type(x) -- isinstance(x, int) should always work. And, as /F notes,
hopefully some overloading/dispatching/generic functions machinery
would help.

If we really want all ints to have the same type, a hackish proposal
would be to tweak type() and the __class__ attribute to lie, returning
the 'int' type object when the type or class of a short or long is
requested. This should probably go with a prohibition on subclassing
int to avoid confusion. At the C level, the concrete types would be
exposed.

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

From jimjjewett at gmail.com  Tue May 30 23:11:01 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 30 May 2006 17:11:01 -0400
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <20060530104546.695F.JCARLSON@uci.edu>
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<d11dcfba0605301032m647094d2tcfe814ba190bfa21@mail.gmail.com>
	<20060530104546.695F.JCARLSON@uci.edu>
Message-ID: <fb6fbf560605301411h6f0ddab7k2b4bfec58b9fb55f@mail.gmail.com>

On 5/30/06, Josiah Carlson <jcarlson at uci.edu> wrote:

> "Steven Bethard" <steven.bethard at gmail.com> wrote:

> > I think that having a package level that exactly matches the divisions
> > in the Library Reference (http://docs.python.org/lib/lib.html) would
> > be great.

Are there any *dis*agreements with this?


> Though I'm probably a bit strange in that I almost want a top level "py"
> package, and a separating of site-packages from the sys.path and into a
> top level package named "site".

> The former would make clear that you expect the module to be in the
> standard library, and the latter would make clear that you want a
> site-packages-specific module/package.

I agree with this too, despite Guido's stance.

-jJ

From tjreedy at udel.edu  Tue May 30 23:30:43 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 30 May 2006 17:30:43 -0400
Subject: [Python-3000] stdlib reorganization
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com><d11dcfba0605301032m647094d2tcfe814ba190bfa21@mail.gmail.com><20060530104546.695F.JCARLSON@uci.edu>
	<fb6fbf560605301411h6f0ddab7k2b4bfec58b9fb55f@mail.gmail.com>
Message-ID: <e5idi4$bkb$1@sea.gmane.org>


"Jim Jewett" <jimjjewett at gmail.com> wrote in message 
news:fb6fbf560605301411h6f0ddab7k2b4bfec58b9fb55f at mail.gmail.com...
>> "Steven Bethard" <steven.bethard at gmail.com> wrote:
>> > I think that having a package level that exactly matches the divisions
>> > in the Library Reference (http://docs.python.org/lib/lib.html) would
>> > be great.
>
> Are there any *dis*agreements with this?

It is certainly a good starting point.  However, it is possible that that 
the docs might be a adjusted to put the two in sync.

tjr




From steven.bethard at gmail.com  Tue May 30 23:39:47 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Tue, 30 May 2006 15:39:47 -0600
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <e5idi4$bkb$1@sea.gmane.org>
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<d11dcfba0605301032m647094d2tcfe814ba190bfa21@mail.gmail.com>
	<20060530104546.695F.JCARLSON@uci.edu>
	<fb6fbf560605301411h6f0ddab7k2b4bfec58b9fb55f@mail.gmail.com>
	<e5idi4$bkb$1@sea.gmane.org>
Message-ID: <d11dcfba0605301439h2d148b0fl263ff9cc2e4d626c@mail.gmail.com>

[Steven Bethard]
> I think that having a package level that exactly matches the divisions
> in the Library Reference (http://docs.python.org/lib/lib.html) would
> be great.

[Jim Jewett]
> Are there any *dis*agreements with this?

[Terry Reedy]
> It is certainly a good starting point.  However, it is possible that that
> the docs might be a adjusted to put the two in sync.

Yep, that's what I was aiming at.  In particular, I think the docs
reorg could all be done in the Python 2.X series.  Then when Python
3000 rolls around, even if people don't know the package names, they
should be able to figure them out pretty quick since they'll match the
library documentation everyone's already used to.

(It appears I accidentally sent the last email to Python Dev, so
clearly I've already borrowed the time machine to propose this for
Python 2.X)  ;-)

STeVe
-- 
Grammar am for people who can't think for myself.
        --- Bucky Katt, Get Fuzzy

From alexander.belopolsky at gmail.com  Wed May 31 00:36:07 2006
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 30 May 2006 22:36:07 +0000 (UTC)
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
References: <447C1AB3.5000602@acm.org> <20060530102903.6959.JCARLSON@uci.edu>
Message-ID: <loom.20060530T235316-399@post.gmane.org>

Josiah Carlson <jcarlson <at> uci.edu> writes:

> 
> 
> Talin <talin <at> acm.org> wrote:
> > 
> > I want to take a stab at unifying a number of ideas that have been 
> > proposed recently:
> 
> 1. It's either a strange way of spelling lambda, and doesn't gain
> anything except a reduction in typing by 1 character.
> 2. Or it's a strange way of deferring evaluation of a line in the
> current stackframe.

My understanding of Talin's proposal is that it is # 2 above. I don't see
anything strange about this idea.  In fact the S family of languages (S,
S-plus, R) defers evaluation of function arguments by default.  This
feature has some interesting concequences, for example R's plot function
can put "y" on the label when invoked as plot(y).

I don't think python needs any syntactic sugar to support this feature.
One can emulate R's lazy evaluation by implementing a "promise" class that
contains slots for a callable and a result that is filled on demand.

Something along the following lines:


class promise(object):
   def __init__(self, callable):
      self._callable = callable
      self._result = None
      
   def __getattribute__(self, name):
      attr = object.__getattribute__
      if attr(self, '_result') is None:
          self._result = attr(self, '_callable')()
      return attr(attr(self, '_result'), name)

def f(x):
    print x.values()

f(promise(lambda: {1:2,3:4}))
-> [2, 4]

Similarly, one can write "promise_number", "promise_sequence" etc. classes
that will dispatch the appropriate special methods to a lazily evaluated
object.  Once type annotations are in-place, it may even become possible
to spell such classes "promise[interface]" and automate their creation.
I think this is a valuable use case for the future type annotation
discussions.




 


From jcarlson at uci.edu  Wed May 31 02:52:59 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 30 May 2006 17:52:59 -0700
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <loom.20060530T235316-399@post.gmane.org>
References: <20060530102903.6959.JCARLSON@uci.edu>
	<loom.20060530T235316-399@post.gmane.org>
Message-ID: <20060530174643.696E.JCARLSON@uci.edu>


Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> 
> Josiah Carlson <jcarlson <at> uci.edu> writes:
> 
> > 
> > 
> > Talin <talin <at> acm.org> wrote:
> > > 
> > > I want to take a stab at unifying a number of ideas that have been 
> > > proposed recently:
> > 
> > 1. It's either a strange way of spelling lambda, and doesn't gain
> > anything except a reduction in typing by 1 character.
> > 2. Or it's a strange way of deferring evaluation of a line in the
> > current stackframe.
> 
> My understanding of Talin's proposal is that it is # 2 above. I don't see
> anything strange about this idea.  In fact the S family of languages (S,
> S-plus, R) defers evaluation of function arguments by default.  This
> feature has some interesting concequences, for example R's plot function
> can put "y" on the label when invoked as plot(y).
> 
> I don't think python needs any syntactic sugar to support this feature.
> One can emulate R's lazy evaluation by implementing a "promise" class that
> contains slots for a callable and a result that is filled on demand.
> 
> Something along the following lines:
[snip]
> Similarly, one can write "promise_number", "promise_sequence" etc. classes
> that will dispatch the appropriate special methods to a lazily evaluated
> object.  Once type annotations are in-place, it may even become possible
> to spell such classes "promise[interface]" and automate their creation.
> I think this is a valuable use case for the future type annotation
> discussions.

Really, this boils down to another way of spelling lambda.

    a.default = lambda: b.get(key, 0)
    value = a[key]

Changing the __dict__ on an instance gives you equivalent behavior for
attribute access.  Before I posted my last response, I hacked together a
generator wrapper, but then I noted that in the 6 or so lines it took me
to properly specify a lazy dict getter, it was all essentially a change
in the default of a default dictionary.  I'm still not convinced that
'lazy <expression>' or your equivalent promise class are necessary or
desireable for the evolution of Python; especially given the simplicity
of the lambda solution.


 - Josiah


From tdickenson at geminidataloggers.com  Tue May 30 13:43:57 2006
From: tdickenson at geminidataloggers.com (Toby Dickenson)
Date: Tue, 30 May 2006 12:43:57 +0100
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <447C1AB3.5000602@acm.org>
References: <447C1AB3.5000602@acm.org>
Message-ID: <200605301243.57103.tdickenson@geminidataloggers.com>

On Tuesday 30 May 2006 11:13, Talin wrote:

> For example - suppose I have two dictionaries that I wish to 
> search, such that if I don't find a value in the first, I want to look 
> in the second; And if I don't find a value in the second, I want to 
> default to zero. (This pattern happens to me rather a lot - because I 
> tend to do a lot of stuff with parsing and nested symbol tables.)
> 
> One simple but inefficient way to code this would be:
> 
>     value = a.getitem( key, b.getitem( key, 0 ) )

This reminds me of one feature of the last scripting language I designed prior 
to Python taking over my world - an exception handler operator which could be 
used in expressions.

The ?? operator first evaluated its left operand. If that succeeds its value 
is returned. If that raised an exception it evaluates and returns its right 
operand. That allowed your example to be written:

	value = a[key] ?? b[key] ?? 0

That was handy for the scripts which this language was designed to support: It 
was a common requirement that values had to be found by scavenging through 
increasingly more desperate sources of information. All of the sources were 
fallible, and some default value needed to be substituted in case all other 
methods failed.

-- 
Toby Dickenson

____________________

Important Notice:

This email and any attachments are confidential and may contain trade secrets or be legally privileged. If you have received this email in error you must not use, rely upon, disclose, copy or distribute the contents. Please reply to the sender so that proper delivery can be arranged and delete the email from your computer.
Gemini Data Loggers monitor incoming and outgoing email to ensure satisfactory customer service, maintain company security and prevent abuse of their email system. However, any views expressed in this email are not necessarily those of Gemini and Gemini cannot be held responsible for the content.
Gemini makes best efforts to ensure emails are virus free; however you are advised to carry out your own checks. Gemini does not accept responsibility for any damage resulting from email viruses.
____________________


From alexander.belopolsky at gmail.com  Wed May 31 04:27:18 2006
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 30 May 2006 22:27:18 -0400
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <20060530174643.696E.JCARLSON@uci.edu>
References: <20060530102903.6959.JCARLSON@uci.edu>
	<loom.20060530T235316-399@post.gmane.org>
	<20060530174643.696E.JCARLSON@uci.edu>
Message-ID: <F497957D-6247-49EF-9F7E-F404953E9E44@local>


On May 30, 2006, at 8:52 PM, Josiah Carlson wrote:
>
> Really, this boils down to another way of spelling lambda.
>

I almost agree.  The difference between a promise and a lambda is  
that the former can be passed to functions that don't know how to  
deal with callables.  I think an appropriate analogy is the  
difference between a pointer and reference in C++.  In C++ references  
are logically equivalent to (const) pointers, but are not  
interchangeable within the type system. There may be the same reason  
to add promises to python as Stroustrup had for adding references to C 
++: operator overloading <http://www.research.att.com/~bs/ 
bs_faq2.html#pointers-and-references>. A function def foo(x,y):  
return x+y will work fine with x or y or both passed as instances of  
promise[Number], but will not work if either is a lambda.

Another  useful analogy is the difference between ref and proxy from  
the weakref module:

 >>> class X(object):
...   def __add__(self, other):
...             return 42
 >>> x = X()
 >>> p = proxy(x)
 >>> r = ref(x)
 >>> p + p
42
 >>> r + r
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'weakref' and 'weakref'
 >>> r() + r()
42

I think we both agree that adding a keyword would just allow "promise 
(lambda: ...)" be contracted to "lazy: ...".

Returning to the setdefault  proposals, a promise has an advantage  
over lambda because proper action can be taken based on the type of  
the argument without an ambiguity in detecting a callable.

  

From jcarlson at uci.edu  Wed May 31 06:09:54 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 30 May 2006 21:09:54 -0700
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <F497957D-6247-49EF-9F7E-F404953E9E44@local>
References: <20060530174643.696E.JCARLSON@uci.edu>
	<F497957D-6247-49EF-9F7E-F404953E9E44@local>
Message-ID: <20060530210257.6971.JCARLSON@uci.edu>


Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> 
> On May 30, 2006, at 8:52 PM, Josiah Carlson wrote:
> >
> > Really, this boils down to another way of spelling lambda.
> >
> 
> I almost agree.  The difference between a promise and a lambda is  
> that the former can be passed to functions that don't know how to  
> deal with callables.  I think an appropriate analogy is the  
> difference between a pointer and reference in C++.  In C++ references  
> are logically equivalent to (const) pointers, but are not  
> interchangeable within the type system. There may be the same reason  
> to add promises to python as Stroustrup had for adding references to C 
> ++: operator overloading <http://www.research.att.com/~bs/ 
> bs_faq2.html#pointers-and-references>. A function def foo(x,y):  
> return x+y will work fine with x or y or both passed as instances of  
> promise[Number], but will not work if either is a lambda.
[snip]

It's all a matter of semantics.  If I tell you "I'm going to implement
deferred/promise/etc., as a callable", and as long as I tell you the
semantics of that call, it will be clear what I mean.  Let's actually go
through the trouble of defining it:

If I call something a "future", a "promise", or a "deferred", what I
mean is that the actual evaluation of an arbitrary sequence of
statements and/or expressions will be "deferred" to the "future" and
that I "promise" to evaluate them if given the proper opportunity.  How
I will define such a thing is to say that any callable that takes zero
arguments is a "future", a "promise", or a "deferred", and that calling
this callable without any arguments will evaluate the specified
statements and/or expressions.

Now that I have sufficiently specified, please explain to me how a new
syntax would improve the current situation?

 - Josiah


From talin at acm.org  Wed May 31 06:35:13 2006
From: talin at acm.org (Talin)
Date: Tue, 30 May 2006 21:35:13 -0700
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <20060530210257.6971.JCARLSON@uci.edu>
References: <20060530174643.696E.JCARLSON@uci.edu>	<F497957D-6247-49EF-9F7E-F404953E9E44@local>
	<20060530210257.6971.JCARLSON@uci.edu>
Message-ID: <447D1D01.3060000@acm.org>

Josiah Carlson wrote:
> It's all a matter of semantics.  If I tell you "I'm going to implement
> deferred/promise/etc., as a callable", and as long as I tell you the
> semantics of that call, it will be clear what I mean.  Let's actually go
> through the trouble of defining it:
> 
> If I call something a "future", a "promise", or a "deferred", what I
> mean is that the actual evaluation of an arbitrary sequence of
> statements and/or expressions will be "deferred" to the "future" and
> that I "promise" to evaluate them if given the proper opportunity.  How
> I will define such a thing is to say that any callable that takes zero
> arguments is a "future", a "promise", or a "deferred", and that calling
> this callable without any arguments will evaluate the specified
> statements and/or expressions.
> 
> Now that I have sufficiently specified, please explain to me how a new
> syntax would improve the current situation?

You're missing a crucial point: The whole idea of 'promise', as I 
understand it, is that it works with functions that aren't expecting a 
callable.

For example, you cannot pass a lambda as the second argument of 
dict.setdefault, because setdefault expects the second argument to be 
already evaluated. So if I say:

    a.setdefault( key, lambda a: [] )

...what you will end up with is the value being a reference to the 
lambda function, not the *output* of the lambda function.

A 'promise' on the other hand, doesn't need to be explicitly called to 
evaluate it. Instead, it automatically evaluates itself whenever it is 
'used'. The problem, of course, is that we haven't defined 'used' very 
well. (I.e. if you pass the unevaluated argument to another function, 
does it get evaluated or not?)

Now, I don't have a problem with the -1, except to say that nothing 
concrete has actually been proposed yet, so there's nothing to vote on. 
(Unless you are voting to kill the discussion.)

I'm actually more interested in exploring the general concept of 
deferred evaluation. The ability to control *when* a particular piece of 
code runs is extremely powerful, and in fact can emulate virtually every 
other programming construct, all the way from a simple if statement to 
concurrency and object inheritance. There are dozens of flavors of 
deferred evaluation already in the language, and none of them (IMHO) are 
redundant.

I'm also interested in anything that blurs the line between code and data :)

-- Talin

From ronaldoussoren at mac.com  Wed May 31 07:49:34 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 31 May 2006 07:49:34 +0200
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <20060530104546.695F.JCARLSON@uci.edu>
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<d11dcfba0605301032m647094d2tcfe814ba190bfa21@mail.gmail.com>
	<20060530104546.695F.JCARLSON@uci.edu>
Message-ID: <7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>


On 30-mei-2006, at 19:49, Josiah Carlson wrote:

>
> "Steven Bethard" <steven.bethard at gmail.com> wrote:
>>
>> On 5/30/06, Brett Cannon <brett at python.org> wrote:
>>> So, first step in my mind is settling if we want to add one more  
>>> depth to
>>> the stdlib, and if so, how we want to group (not specific  
>>> groupings, just
>>> general guidelines).
>>
>> I think that having a package level that exactly matches the  
>> divisions
>> in the Library Reference (http://docs.python.org/lib/lib.html) would
>> be great.  Currently, that would mean packages for:
>
> Agreed.
>
> Though I'm probably a bit strange in that I almost want a top level  
> "py"
> package, and a separating of site-packages from the sys.path and  
> into a
> top level package named "site".
>
> The former would make clear that you expect the module to be in the
> standard library, and the latter would make clear that you want a
> site-packages-specific module/package.

I can understand the wish for a toplevel package that contains the  
stdlib, although I don't think I agree with that. Stuffing site- 
packages in another toplevel package seems wrong to me. If I  
understand you correctly I'd have to do 'import site.wx' to import  
wxPython and that doesn't feel right.

Ronald


From fdrake at acm.org  Wed May 31 07:57:03 2006
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed, 31 May 2006 01:57:03 -0400
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<20060530104546.695F.JCARLSON@uci.edu>
	<7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>
Message-ID: <200605310157.04260.fdrake@acm.org>

On Wednesday 31 May 2006 01:49, Ronald Oussoren wrote:
 > I can understand the wish for a toplevel package that contains the
 > stdlib, although I don't think I agree with that.

I understand it, and mostly wish for it at this point, though I think the name 
really has to be something short to work.

 > Stuffing site- 
 > packages in another toplevel package seems wrong to me. If I
 > understand you correctly I'd have to do 'import site.wx' to import
 > wxPython and that doesn't feel right.

Agreed.  That would be nothing but pain.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>

From jcarlson at uci.edu  Wed May 31 08:52:06 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 30 May 2006 23:52:06 -0700
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <447D1D01.3060000@acm.org>
References: <20060530210257.6971.JCARLSON@uci.edu> <447D1D01.3060000@acm.org>
Message-ID: <20060530234751.6974.JCARLSON@uci.edu>


Talin <talin at acm.org> wrote:
> Josiah Carlson wrote:
> > It's all a matter of semantics.  If I tell you "I'm going to implement
> > deferred/promise/etc., as a callable", and as long as I tell you the
> > semantics of that call, it will be clear what I mean.  Let's actually go
> > through the trouble of defining it:
> > 
> > If I call something a "future", a "promise", or a "deferred", what I
> > mean is that the actual evaluation of an arbitrary sequence of
> > statements and/or expressions will be "deferred" to the "future" and
> > that I "promise" to evaluate them if given the proper opportunity.  How
> > I will define such a thing is to say that any callable that takes zero
> > arguments is a "future", a "promise", or a "deferred", and that calling
> > this callable without any arguments will evaluate the specified
> > statements and/or expressions.
> > 
> > Now that I have sufficiently specified, please explain to me how a new
> > syntax would improve the current situation?
> 
> You're missing a crucial point: The whole idea of 'promise', as I 
> understand it, is that it works with functions that aren't expecting a 
> callable.

So you use the 9-line promise that Alex posted.

[snip]
> Now, I don't have a problem with the -1, except to say that nothing 
> concrete has actually been proposed yet, so there's nothing to vote on. 
> (Unless you are voting to kill the discussion.)

I'm voting a -1 on the proposed feature addition of a 'deferred
execution' mechanism because such is already available with minimal
effort in current Python, either explicitly via semantic definition (I
know my deferred is a callable) or by using a __getattribute__ hook like
Alex specified, which uses the "I know my deferred is a callable"
internally.

 - Josiah


From alexander.belopolsky at gmail.com  Wed May 31 08:49:19 2006
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 31 May 2006 02:49:19 -0400
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <20060530210257.6971.JCARLSON@uci.edu>
References: <20060530174643.696E.JCARLSON@uci.edu>
	<F497957D-6247-49EF-9F7E-F404953E9E44@local>
	<20060530210257.6971.JCARLSON@uci.edu>
Message-ID: <d38f5330605302349h7cb6fdb4q31b32f5418ca379a@mail.gmail.com>

On 5/31/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> Now that I have sufficiently specified, please explain to me how a new
> syntax would improve the current situation?

If you have read past the first paragraph in my previous post you
would see the answer to your question:

"""
I think we both agree that adding a keyword would just allow "promise
(lambda: ...)" be contracted to "lazy: ...".
"""

I am not advocating for the new syntax.  I was simply explaining the
difference between a promise and a lambda expression.

From jcarlson at uci.edu  Wed May 31 09:00:03 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 31 May 2006 00:00:03 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>
References: <20060530104546.695F.JCARLSON@uci.edu>
	<7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>
Message-ID: <20060530235244.6977.JCARLSON@uci.edu>


Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> 
> 
> On 30-mei-2006, at 19:49, Josiah Carlson wrote:
> > Though I'm probably a bit strange in that I almost want a top level  
> > "py"
> > package, and a separating of site-packages from the sys.path and  
> > into a
> > top level package named "site".
> >
> > The former would make clear that you expect the module to be in the
> > standard library, and the latter would make clear that you want a
> > site-packages-specific module/package.
> 
> I can understand the wish for a toplevel package that contains the  
> stdlib, although I don't think I agree with that. Stuffing site- 
> packages in another toplevel package seems wrong to me. If I  
> understand you correctly I'd have to do 'import site.wx' to import  
> wxPython and that doesn't feel right.

I believe people would tend to use 'from site import wx', because using
'wx.Frame' is much preferrable to 'site.wx.Frame'.

Do you disagree with the desire to make Python all in 'py' in addition
to site-packages as 'site'?

Note that by having top level 'py' and 'site' packages, the sys.modules
naming of subpackages and modules necessarily get a 'py.' or 'site.'
prefix, which I believe would reduce the amount of name intersections
with user code.

There was also a proposal that I was supposed to work on getting
formalized somewhat over a year ago about getting __main__ relative
imports to have __main__.XXX names, which would further reduce (if not
remove entirely) name collisions in sys.modules, but I got caught up in
my attempt at a relative import hook.

 - Josiah


From gary at zope.com  Wed May 31 09:08:34 2006
From: gary at zope.com (Gary Poster)
Date: Wed, 31 May 2006 10:08:34 +0300
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <20060530234751.6974.JCARLSON@uci.edu>
References: <20060530210257.6971.JCARLSON@uci.edu> <447D1D01.3060000@acm.org>
	<20060530234751.6974.JCARLSON@uci.edu>
Message-ID: <F5D79C95-7941-45B2-B31A-006C24D0766E@zope.com>


On May 31, 2006, at 9:52 AM, Josiah Carlson wrote:

>
> Talin <talin at acm.org> wrote:
...
>> You're missing a crucial point: The whole idea of 'promise', as I
>> understand it, is that it works with functions that aren't  
>> expecting a
>> callable.
>
> So you use the 9-line promise that Alex posted.

I think a promise is an excellent use case.

Proxies, such as used by the solution Alex proposed, are very  
powerful, but can be very surprising.  Zope has years of experience  
with a variety of them.  A language solution that let the end result  
of a promise not be proxied would be much better than a proxy-based  
solution, at least if our experience with Python 2.x is any guide.

Gary

From greg.ewing at canterbury.ac.nz  Wed May 31 10:38:17 2006
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 31 May 2006 20:38:17 +1200
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <200605310157.04260.fdrake@acm.org>
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<20060530104546.695F.JCARLSON@uci.edu>
	<7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>
	<200605310157.04260.fdrake@acm.org>
Message-ID: <447D55F9.3000300@canterbury.ac.nz>

Fred L. Drake, Jr. wrote:
>  > Stuffing site- 
>  > packages in another toplevel package seems wrong to me. If I
>  > understand you correctly I'd have to do 'import site.wx' to import
>  > wxPython and that doesn't feel right.
> 
> Agreed.  That would be nothing but pain.

Also it would seem to mean that there would only ever
be two top-level packages, stdlib and site. That seems
like a poor use of a naming level.

--
Greg

From talin at acm.org  Wed May 31 10:48:24 2006
From: talin at acm.org (Talin)
Date: Wed, 31 May 2006 01:48:24 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <447D55F9.3000300@canterbury.ac.nz>
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>	<20060530104546.695F.JCARLSON@uci.edu>	<7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>	<200605310157.04260.fdrake@acm.org>
	<447D55F9.3000300@canterbury.ac.nz>
Message-ID: <447D5858.5070802@acm.org>

Greg Ewing wrote:
> Fred L. Drake, Jr. wrote:
> 
>> > Stuffing site- 
>> > packages in another toplevel package seems wrong to me. If I
>> > understand you correctly I'd have to do 'import site.wx' to import
>> > wxPython and that doesn't feel right.
>>
>>Agreed.  That would be nothing but pain.
> 
> 
> Also it would seem to mean that there would only ever
> be two top-level packages, stdlib and site. That seems
> like a poor use of a naming level.

Absolutely. What I would like to see is a namespace that has a fan-out 
factor of around, say, 20-50 names per namespace on average, a small 
enough number that collisions aren't a problem, but large enough that 
the tree doesn't have to be very deep.

-- Talin

From qrczak at knm.org.pl  Wed May 31 14:47:21 2006
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Wed, 31 May 2006 14:47:21 +0200
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <447D1D01.3060000@acm.org> (talin@acm.org's message of "Tue, 30
	May 2006 21:35:13 -0700")
References: <20060530174643.696E.JCARLSON@uci.edu>
	<F497957D-6247-49EF-9F7E-F404953E9E44@local>
	<20060530210257.6971.JCARLSON@uci.edu> <447D1D01.3060000@acm.org>
Message-ID: <873beqz7hi.fsf@qrnik.zagroda>

Talin <talin at acm.org> writes:

> A 'promise' on the other hand, doesn't need to be explicitly called to 
> evaluate it. Instead, it automatically evaluates itself whenever it is 
> 'used'. The problem, of course, is that we haven't defined 'used' very 
> well. (I.e. if you pass the unevaluated argument to another function, 
> does it get evaluated or not?)

I'm afraid that this can't be defined well. I haven't yet seen
a consistently behaving transparent proxy in any language.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

From solipsis at pitrou.net  Wed May 31 15:08:41 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 31 May 2006 15:08:41 +0200
Subject: [Python-3000] packages in the stdlib
In-Reply-To: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
References: <44716940.9000300@acm.org>
	<bbaeab100605220907r63304e19kbc6f27221643a6fd@mail.gmail.com>
	<1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com>
	<1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
Message-ID: <1149080922.5718.20.camel@fsol>

Le mardi 30 mai 2006 ? 09:25 -0700, Brett Cannon a ?crit :
> 
> I think what needs to happen is decide if we want to group modules
> into packages (but no deeper than a single depth), and then how to
> handle general naming (e.g., net.http, net.httplib, http, or
> httplib?). 

I don't see the point of grouping modules into packages.
It is obvious what "http" is (a network protocol), so why have to write
"net.http" instead of simply "http" ? It's more things to type and more
things to remember, without any clear advantage.

The current flat namespace for the standard library is one *very*
pleasant feature of Python. You only have to remember the module name
itself, not its position in the hierarchy. Compare this with Java
or .Net...

Moreover, as someone wrote in another post, if you introduce packages,
people will write "from gui import wx", so why not just let it be
"import wx"? We are adults.


The problem with the current naming IMO is the fact it is inconsistent
and sometimes confusing. I don't think introducing a level of nesting is
an answer to this problem. Actually, flattening the current nested
modules would be a good think.

(for example, I don't like the way "os.path" is magically imported when
importing "os". Some functions are in "os", others in "os.path", without
any clear logical reason. They should all belong in "os" - or any other
name for that matter).

Regards

Antoine.



From fperez.net at gmail.com  Wed May 31 15:52:04 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 31 May 2006 07:52:04 -0600
Subject: [Python-3000] stdlib reorganization
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<20060530104546.695F.JCARLSON@uci.edu>
	<7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>
	<200605310157.04260.fdrake@acm.org>
Message-ID: <e5k71p$ai8$1@sea.gmane.org>

Fred L. Drake, Jr. wrote:

> On Wednesday 31 May 2006 01:49, Ronald Oussoren wrote:
>  > I can understand the wish for a toplevel package that contains the
>  > stdlib, although I don't think I agree with that.
> 
> I understand it, and mostly wish for it at this point, though I think the
> name really has to be something short to work.

I've thought about this for a while, and wondered if it wouldn't be more
palatable in conjunction with a small syntactic addition to the import
statement: 'from :'.  An example should make the idea clear, assuming 'py'
or 'std' as the canonical name for the stdlib:

from std:
  import email
  import sys
  import os

from scipy:
  import linalg
  import fft


This obviously raises the problem of offering two ways of doing the same:

from foo import bar
from foo: import bar

if the ':' is allowed but left as optional.  

Rather than having a nested stdlib, what I'd like to have is to protection
from accidental name clashes with other things.  An 'std' namespace would
future-proof the stdlib in this regard, with a minimal burden on code
writers.  I already write the above anyway in most of my code since I think
it helps clarify what comes from where, it's just that I use a comment:

# stdlib imports
import os
import sys

# third-party imports
...


If this particular approach has already been debated and rejected, please
forgive me: I did read as much as I could find on the archives first.

Cheers,

f


From tim.hochberg at ieee.org  Wed May 31 16:46:24 2006
From: tim.hochberg at ieee.org (Tim Hochberg)
Date: Wed, 31 May 2006 07:46:24 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <e5k71p$ai8$1@sea.gmane.org>
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>	<20060530104546.695F.JCARLSON@uci.edu>	<7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>	<200605310157.04260.fdrake@acm.org>
	<e5k71p$ai8$1@sea.gmane.org>
Message-ID: <e5ka4f$nf6$1@sea.gmane.org>


The more examples I see of the 'py' and 'site' top level namespaces, the 
less I like them. Let's dispose of 'site' first; it's been common to 
show examples like:

     from gui import wx

However, wx currently, and presumably for the forseeable future, lives 
in site packages, so we'd actually have something like:

     from site.gui import wx
     from site.gui import pygui
     from py.gui import tkinter

That seems confusing and suboptimal. So, presumably what we want is for 
packages that get installed under site-packages to logically live under 
the main headings so that, for example, all of the above imports would 
be "from gui ...".

That eliminates most of the uses for 'site' and if 'site' is gone I fail 
to see much use for the 'py' package either. Let's just ditch them both 
and save ourselves a layer of cruft.

On a slightly different topic, the library reorganization only seems 
useful if it's accompanied by some increased smarts in either the import 
machinery or the installation code such that one could do:

     >>> import gui
     >>> dir(gui)
     ['wx', 'tkinter', 'pygui']
     >>> help(gui)
     wx - GUI toolkit based on wxWidgets
     tkinter - GUI toolkit based on TK
     pygui - Another GUI toolkit

You don't want to import the full packages most of the time, so perhaps 
at least part of the smarts needs to be in the installer. I any event, 
reorganizing the standard lib seems at best a minor upgrade if it 
doesn't also support introspection.

I would be nice to also be able to inquire about what top level packages 
were available, but I'm not sure how to spell that since I just banished 
'py' ;-|  Perhaps:

    >>> import sys
    >>> dir(sys.packages)
    ['gui', 'web', 'database', ....]

Regards,

-tim


From shponglespore at gmail.com  Wed May 31 17:31:33 2006
From: shponglespore at gmail.com (John Williams)
Date: Wed, 31 May 2006 10:31:33 -0500
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <20060530174643.696E.JCARLSON@uci.edu>
References: <20060530102903.6959.JCARLSON@uci.edu>
	<loom.20060530T235316-399@post.gmane.org>
	<20060530174643.696E.JCARLSON@uci.edu>
Message-ID: <e6c6cc500605310831p1321dbb4t7464e55097516a59@mail.gmail.com>

On 5/30/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> I'm still not convinced that
> 'lazy <expression>' or your equivalent promise class are necessary or
> desireable for the evolution of Python; especially given the simplicity
> of the lambda solution.

I may be just seeing that I want to see, but by my reading of Talin's
original posting, it looks like 'lazy <expression>' was not part of
what he was actually proposing. The actual proposal was to declare
parameters 'lazy' in the function definition, with the effect of
creating an implicit lambda at each call site.

I don't think this feature is a good fit for Python, but it a has a
lot of history so I don't want to see it go down without getting its
due.

I believe the first language to have a similar feature was Algol,
where all arguments were passed "by name". The general consensus seems
to have been that this was a very bad idea, since the only modern
languages that work this way are pure functional languages (Haskell,
Clean, etc.)

The ability to introduce more fine-grained laziness, as proposed here,
seems to be more common in non-pure functional languages (that is,
functional languages that allow side-effects)--I've seen two proposals
from highly-regarded functional language researchers to add similar
constructs to ML.

Laziness is probably most common in functional languages because in
many ways it's an alternative to side-effects. On one hand,
eliminating or discouraging side-effects in a language make laziness
much more attractive because it's possible to re-order the evaluation
of purely functional code without changing its meaning. On the other
hand, laziness has much more value in a functional setting because
many purely-functional algorithms have worse asymptotic complexity
than their procedural counterparts unless laziness is allowed.

That said, I have seen lazy arguments in one OO language, namely
Scala. It's a fairly new language with a lot of novel features, so
it's a bit early to single out a feature and say it's (?:good|bad)
because Scala is a (?:spectacular success|miserable failure), but it
doesn't seem to have caused an inordinate amount of confusion, and
there's an awful lot of cool stuff you can do with deferred arguments,
such as implementing boolean operators, looping constructs,
"with"-like constructs, etc.

The fact that you can get the same effect with explicit lambdas
doesn't detract from the value of lazy arguments IMHO because a lot of
the time the extra syntactic weight is just too much to
tolerate--imagine if the 'and' and 'or' operators required a callable
as their second argument!

The thing that really makes this feature unattractive in Python is
that it would become impossible to tell when or if a function will
evaluate its arguments without seeing the function's definition. Even
this might be OK if not for inheritance, but the possibility of
overriding a normal method with a lazy method just makes my skin
crawl!

--jw

From jcarlson at uci.edu  Wed May 31 18:10:04 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 31 May 2006 09:10:04 -0700
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
In-Reply-To: <d38f5330605302349h7cb6fdb4q31b32f5418ca379a@mail.gmail.com>
References: <20060530210257.6971.JCARLSON@uci.edu>
	<d38f5330605302349h7cb6fdb4q31b32f5418ca379a@mail.gmail.com>
Message-ID: <20060531090045.6980.JCARLSON@uci.edu>


"Alexander Belopolsky" <alexander.belopolsky at gmail.com> wrote:
> 
> On 5/31/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> > Now that I have sufficiently specified, please explain to me how a new
> > syntax would improve the current situation?
> 
> If you have read past the first paragraph in my previous post you
> would see the answer to your question:

My question wasn't fully directed at you, it was more directed at others
who desired the lazy syntax.

> """
> I think we both agree that adding a keyword would just allow "promise
> (lambda: ...)" be contracted to "lazy: ...".
> """
> 
> I am not advocating for the new syntax.  I was simply explaining the
> difference between a promise and a lambda expression.

And I was also trying to describe how you can get similar behavior
strictly with lambdas if you are willing to say "I know I'm passing
around promises".  From what I understand, we do agree on these points,
so I'll let this particular fork of the thread end.

 - Josiah


From brett at python.org  Wed May 31 18:57:12 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 31 May 2006 09:57:12 -0700
Subject: [Python-3000] packages in the stdlib
In-Reply-To: <1149080922.5718.20.camel@fsol>
References: <44716940.9000300@acm.org> <1148315368.19392.4.camel@fsol>
	<20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<1149080922.5718.20.camel@fsol>
Message-ID: <bbaeab100605310957u4f49bcbbwb2512dd195ba4b49@mail.gmail.com>

On 5/31/06, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Le mardi 30 mai 2006 ? 09:25 -0700, Brett Cannon a ?crit :
> >
> > I think what needs to happen is decide if we want to group modules
> > into packages (but no deeper than a single depth), and then how to
> > handle general naming (e.g., net.http, net.httplib, http, or
> > httplib?).
>
> I don't see the point of grouping modules into packages.
> It is obvious what "http" is (a network protocol), so why have to write
> "net.http" instead of simply "http" ? It's more things to type and more
> things to remember, without any clear advantage.


That might be true of http, but what about modules with a more ambiguous
name?

The current flat namespace for the standard library is one *very*
> pleasant feature of Python. You only have to remember the module name
> itself, not its position in the hierarchy. Compare this with Java
> or .Net...


But with Java (don't have much .NET experience) the issue is they put data
structures in java.util which doesn't explain anything.  But if it had been
named datastruct or something more meaningful would it be so bad?

Moreover, as someone wrote in another post, if you introduce packages,
> people will write "from gui import wx", so why not just let it be
> "import wx"? We are adults.


We are adults, but doesn't that mean we can also be organized?  We are past
the point of keeping our toys in one big basket and instead have organized
shelves where we separate our Transformers from our Tonka trucks.

The problem with the current naming IMO is the fact it is inconsistent
> and sometimes confusing. I don't think introducing a level of nesting is
> an answer to this problem. Actually, flattening the current nested
> modules would be a good think.


We will be fixing the names on top of categorizing, so that will be
addressed.

(for example, I don't like the way "os.path" is magically imported when
> importing "os". Some functions are in "os", others in "os.path", without
> any clear logical reason. They should all belong in "os" - or any other
> name for that matter).


The magic importation is an implementation artifact from os being around
before packages existed.  If it was done today that wouldn't work that way.

And I would never want to flatten os completely.  Knowing that path
manipulating code is in os.path is handy when you are looking for a function
in the documentation, and especially at the interpreter prompt.  We all know
searching a tree over a list is better!  =)

-Brett

Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060531/4a22ea36/attachment-0001.html 

From alexander.belopolsky at gmail.com  Wed May 31 19:05:52 2006
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 31 May 2006 17:05:52 +0000 (UTC)
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
References: <20060530174643.696E.JCARLSON@uci.edu>
	<F497957D-6247-49EF-9F7E-F404953E9E44@local>
	<20060530210257.6971.JCARLSON@uci.edu>
	<447D1D01.3060000@acm.org> <873beqz7hi.fsf@qrnik.zagroda>
Message-ID: <loom.20060531T185616-905@post.gmane.org>

Marcin 'Qrczak' Kowalczyk <qrczak <at> knm.org.pl> writes:

> 
> Talin <talin <at> acm.org> writes:
> 
> > A 'promise' on the other hand, doesn't need to be explicitly called to 
> > evaluate it. Instead, it automatically evaluates itself whenever it is 
> > 'used'. The problem, of course, is that we haven't defined 'used' very 
> > well. (I.e. if you pass the unevaluated argument to another function, 
> > does it get evaluated or not?)
> 
> I'm afraid that this can't be defined well. I haven't yet seen
> a consistently behaving transparent proxy in any language.
> 

Does that include R?  I've started looking under the hood of R only recently,
and the fact that I was able to use S+ and R for years without even knowing
about promises tells me that these are pretty transparent.

It maybe helpful for the current discussion if someone with more experience than
I would criticize R's approach.

Here is the relevant section from "R Language Definition":

"""
2.1.8 Promise objects

Promise objects are part of R's lazy evaluation mechanism. They contain three
slots: a value, an expression, and an environment. When a function is called the
arguments are matched and then each of the formal arguments is bound to a
promise. The expression that was given for that formal argument and a pointer to
the environment the function was called from are stored in the promise.

Until that argument is accessed there is no value associated with the promise.
When the argument is accessed, the stored expression is evaluated in the stored
environment, and the result is returned. The result is also saved by the
promise. The substitute function will extract the content of the expression
slot. This allows the programmer to access either the value or the expression
associated with the promise.

Within the R language, promise objects are almost only seen implicitly. (In an
upcoming release they will never be visible to R code, as they will always be
evaluated when accessed.) Actual function arguments are of this type. There is
also a delayedAssign function that will make a promise out of an expression.
There is generally no way in R code to check whether an object is a promise or
not, nor is there a way to use R code to determine the environment of a promise. 
"""
<http://cran.r-project.org/doc/manuals/R-lang.html#Promise-objects>



From solipsis at pitrou.net  Wed May 31 19:19:37 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 31 May 2006 19:19:37 +0200
Subject: [Python-3000] packages in the stdlib
In-Reply-To: <bbaeab100605310957u4f49bcbbwb2512dd195ba4b49@mail.gmail.com>
References: <44716940.9000300@acm.org> <1148315368.19392.4.camel@fsol>
	<20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<1149080922.5718.20.camel@fsol>
	<bbaeab100605310957u4f49bcbbwb2512dd195ba4b49@mail.gmail.com>
Message-ID: <1149095977.5718.51.camel@fsol>

Le mercredi 31 mai 2006 ? 09:57 -0700, Brett Cannon a ?crit :
> 
> That might be true of http, but what about modules with a more
> ambiguous name? 

Then perhaps the name can be made less ambiguous ;)
For example "ElementTree" could be named "xmltree", or whatever.

> But with Java (don't have much .NET experience) the issue is they put
> data structures in java.util which doesn't explain anything.  But if
> it had been named datastruct or something more meaningful would it be
> so bad? 

No, but it still would be additional baggage to remember.
It is clear a "deque" is a collection and a "heapq" is a specific kind
of data structure, so why try to categorize them whereas the
categorization does not bring any additional information or
functionality to the programmer?

> We are adults, but doesn't that mean we can also be organized?  We are
> past the point of keeping our toys in one big basket and instead have
> organized shelves where we separate our Transformers from our Tonka
> trucks. 

But it is very difficult to come with a hierarchy that will be
reasonably intuitive.
Do we put "http" in "net", "protocols", "net.protocols"?
Does "email" warrant its own package? If so, do we put "imap" or "pop3"
in "email" or in "protocols"?
Is "web" separate from "net"? What about "url"?
etc.

The documentation can be topically structured, which is indeed handy
when discovering Python and its stdlib, but why force the categorization
on the programmer while it does not bring any benefits?

Regards,

Antoine.



From ronaldoussoren at mac.com  Wed May 31 20:04:06 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 31 May 2006 20:04:06 +0200
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <20060530235244.6977.JCARLSON@uci.edu>
References: <20060530104546.695F.JCARLSON@uci.edu>
	<7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>
	<20060530235244.6977.JCARLSON@uci.edu>
Message-ID: <2375C3EE-7263-4CCF-BE7B-5F4C9A46F205@mac.com>


On 31-mei-2006, at 9:00, Josiah Carlson wrote:

>
> Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>>
>>
>> On 30-mei-2006, at 19:49, Josiah Carlson wrote:
>>> Though I'm probably a bit strange in that I almost want a top level
>>> "py"
>>> package, and a separating of site-packages from the sys.path and
>>> into a
>>> top level package named "site".
>>>
>>> The former would make clear that you expect the module to be in the
>>> standard library, and the latter would make clear that you want a
>>> site-packages-specific module/package.
>>
>> I can understand the wish for a toplevel package that contains the
>> stdlib, although I don't think I agree with that. Stuffing site-
>> packages in another toplevel package seems wrong to me. If I
>> understand you correctly I'd have to do 'import site.wx' to import
>> wxPython and that doesn't feel right.
>
> I believe people would tend to use 'from site import wx', because  
> using
> 'wx.Frame' is much preferrable to 'site.wx.Frame'.
>
> Do you disagree with the desire to make Python all in 'py' in addition
> to site-packages as 'site'?
>
> Note that by having top level 'py' and 'site' packages, the  
> sys.modules
> naming of subpackages and modules necessarily get a 'py.' or 'site.'
> prefix, which I believe would reduce the amount of name intersections
> with user code.

I'm definitely opposed to having a toplevel package "site" that  
contains what's currently in site-packages. My first reaction to this  
was that 3th-party packages get stuffed into a ghetto. A method to  
selectively add packages to sys.path, such as the multi-version- 
install feature of setuptools, would be a much better solution than  
that. This would allow scripts to control which 3th-party code it  
wants to use.

I'm not sure about the toplevel package "py". I usually pick toplevel  
package name for applications to keep them nicely selfcontained. That  
combined with requiring full package names in import statements seems  
to take away the need for a toplevel package for the standard library.

>
> There was also a proposal that I was supposed to work on getting
> formalized somewhat over a year ago about getting __main__ relative
> imports to have __main__.XXX names, which would further reduce (if not
> remove entirely) name collisions in sys.modules, but I got caught  
> up in
> my attempt at a relative import hook.

That would really suck.

Ronald

>
>  - Josiah
>


From tomerfiliba at gmail.com  Wed May 31 20:02:19 2006
From: tomerfiliba at gmail.com (tomer filiba)
Date: Wed, 31 May 2006 11:02:19 -0700
Subject: [Python-3000] weakrefs and cyclic references
Message-ID: <1d85506f0605311102la44fb40j65954db9bad9a29c@mail.gmail.com>

the current gc already detects cyclic referencing between objects,
and by what i understood, it can free the memory the objects take,
but __del__ is never call because there's not telling where to
start the __del__ chain.

by cyclic referencing i mean something like
>>> class x(object):
...     def __init__(self):
...         self.next = self
...     def __del__(self):
...         print "deleted"
...
>>> y=x()
>>> del y
>>> import gc
>>> gc.collect()
2

while __del__ was never called. you can solve the problem using
weakref.proxy, in a fashion like

>>> class x(object):
...     def __init__(self):
...         self.next = weakref.proxy(self)
...     def __del__(self):
...         print "deleted", repr(self.next)
...
>>> y=x()
>>> y
<__main__.x object at 0x00B9E190>
>>> y.next
<weakproxy at 00ADFF60 to x at 00B9E190>
>>> y.next.next
<weakproxy at 00ADFF60 to x at 00B9E190>
>>> del y
deleted <weakproxy at 00ADFF60 to NoneType at 1E1A1E00>

so why not do this automatically?

this idea is to simplify the GC and completely avoid cyclic references
between objects. it's quite simple: every time an assignment is made, i.e.,

self.next = self

the interpreter would automatically detect the assignment would create
a cyclic reference, and would instead create a weakproxy instead, i.e.

self.next = self ==> self.next = weakref.proxy(self)

this approach has several benefits:
* the object stays alive only when *external* references to it exist
* makes the GC a lot simpler (only refcounts are needed)
* __del__ is always called
* the only problem is when __del__ is called, some attributes might
refer to None, but that can be easily anticipated by the code of the
destructor

i guess it has a performance penalty... but maybe there can be a
trick around it. i can imagine the code of the INCREF() detecting
the assignment yields an increment of two instead of one, and
would therefore create a weakref. of coure this optimization is
too lax, but something in that direction.



-tomer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060531/cec30cc5/attachment.htm 

From ronaldoussoren at mac.com  Wed May 31 20:11:09 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 31 May 2006 20:11:09 +0200
Subject: [Python-3000] packages in the stdlib
In-Reply-To: <1149095977.5718.51.camel@fsol>
References: <44716940.9000300@acm.org> <1148315368.19392.4.camel@fsol>
	<20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<1149080922.5718.20.camel@fsol>
	<bbaeab100605310957u4f49bcbbwb2512dd195ba4b49@mail.gmail.com>
	<1149095977.5718.51.camel@fsol>
Message-ID: <430FBE78-D78A-4346-BD18-27D1D038AFE7@mac.com>


On 31-mei-2006, at 19:19, Antoine Pitrou wrote:

> Le mercredi 31 mai 2006 ? 09:57 -0700, Brett Cannon a ?crit :
>>
>> That might be true of http, but what about modules with a more
>> ambiguous name?
>
> Then perhaps the name can be made less ambiguous ;)
> For example "ElementTree" could be named "xmltree", or whatever.
>
>> But with Java (don't have much .NET experience) the issue is they put
>> data structures in java.util which doesn't explain anything.  But if
>> it had been named datastruct or something more meaningful would it be
>> so bad?
>
> No, but it still would be additional baggage to remember.
> It is clear a "deque" is a collection and a "heapq" is a specific kind
> of data structure, so why try to categorize them whereas the
> categorization does not bring any additional information or
> functionality to the programmer?

And what would a more hierarchical namespace mean for 3th-party code?  
If there were to be a toplevel package "gui" that contains gui code  
such as tkinter it would be very natural to assume that wxWidgets or  
gtk are also in the gui namespace, even if they aren't part of the  
standard library. I haven't thought enough about this to know which  
option I'd hate more, requiring 3th-party libraries to pick unobvious  
names or not knowing if net.jabber is a standard library package I  
didn't use yet or something that is was installed sepereately.

Ronald


From brett at python.org  Wed May 31 20:31:52 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 31 May 2006 11:31:52 -0700
Subject: [Python-3000] packages in the stdlib
In-Reply-To: <1149095977.5718.51.camel@fsol>
References: <44716940.9000300@acm.org> <1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<1149080922.5718.20.camel@fsol>
	<bbaeab100605310957u4f49bcbbwb2512dd195ba4b49@mail.gmail.com>
	<1149095977.5718.51.camel@fsol>
Message-ID: <bbaeab100605311131h37f7f231k1c30ebb20cf873f0@mail.gmail.com>

On 5/31/06, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Le mercredi 31 mai 2006 ? 09:57 -0700, Brett Cannon a ?crit :
> >
> > That might be true of http, but what about modules with a more
> > ambiguous name?
>
> Then perhaps the name can be made less ambiguous ;)
> For example "ElementTree" could be named "xmltree", or whatever.


Yes, less ambiguous names, regardless of the outcome of this hierarchy
discussion, is desired by everyone.

> But with Java (don't have much .NET experience) the issue is they put
> > data structures in java.util which doesn't explain anything.  But if
> > it had been named datastruct or something more meaningful would it be
> > so bad?
>
> No, but it still would be additional baggage to remember.
> It is clear a "deque" is a collection and a "heapq" is a specific kind
> of data structure, so why try to categorize them whereas the
> categorization does not bring any additional information or
> functionality to the programmer?


I think this debate is boiling down to how people remember modules whose
name they do not have remembered.  I might remember heapq, but what happens
if I remember there is a module of implementing heaps but I don't remember
the name?  If the docs are organized in a hierarchical fashion, I can look
in one or two obvious categories.  This is made even more helpful if you are
at the interpreter prompt and you happen to have the handful of package
names memorized.  Running ``help(datastruct)`` and getting a list of
contained modules and a one-liner of what they do would be really handy.

> We are adults, but doesn't that mean we can also be organized?  We are
> > past the point of keeping our toys in one big basket and instead have
> > organized shelves where we separate our Transformers from our Tonka
> > trucks.
>
> But it is very difficult to come with a hierarchy that will be
> reasonably intuitive.


I don't know about that.  And even so, we won't have a bazillion categories,
so most of us will end up memorizing the handful that there are and what
they generally contain and use the docs and help() to figure out the rest as
needed.

Do we put "http" in "net", "protocols", "net.protocols"?
> Does "email" warrant its own package? If so, do we put "imap" or "pop3"
> in "email" or in "protocols"?
> Is "web" separate from "net"? What about "url"?
> etc.


Right, but that problem exists in a flat hierarchy as well.  Why isn't
smtplib in the email package?  What if I think that is the way it should
be?  I would then have to search again.  So this is the same as having to
peruse the docs again for smtplib.

The documentation can be topically structured, which is indeed handy
> when discovering Python and its stdlib, but why force the categorization
> on the programmer while it does not bring any benefits?



So here is how I tend to do my module searching.  When I am developing I
have an interpreter open.  I try to import a module by name to see if I got
the name right, maybe run help() on it.  If that doesn't work I pull up the
module index and look at the names for the module I want since I pretty much
know what each one does, I just don't necessarily remember the exact name.
If that fails I go to the hierarchical list or Google.

If there were categories, though, I would most likely have the handful of
package names memorized.  So I would run help() on the packages to see what
modules they had and the summary.  Basically what I should probably be doing
with the online docs' hierarchy, but entirely at the interpreter.  I
*really* prefer using the interpreter for quick doc lookup and only hit the
online docs for detailed documentation or I have no clue where something
is.  If I can cut down on the instances of not having a clue where something
is by some basic categorization at the interpreter I consider that a win.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060531/0364aa13/attachment-0001.html 

From alexander.belopolsky at gmail.com  Wed May 31 20:51:14 2006
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 31 May 2006 18:51:14 +0000 (UTC)
Subject: [Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
References: <447C1AB3.5000602@acm.org>
Message-ID: <loom.20060531T194658-844@post.gmane.org>

Talin <talin <at> acm.org> writes:

[snip]
> One way around that would be to have the 'lazy' attribute associated 
> with the formal parameter of the called function instead:
> 
>     def getitem( self, key, lazy default_val ):
>        ...
> 
> Unfortunately, this breaks the "no programmable syntax" rule - because 
> there's no way for a given program to know whether or not the function 
> being called has a lazy argument or not. I don't know of a way around 
> this, to be honest, so this idea won't work unless someone out there has 
> some clever idea that I haven't thought of.
[snip]

On the first reading I did not realize that Talin proposed that laziness be
specified at the definition rather than at the call site.

This is a much more interesting and more difficult to implement idea than the
simple "promise" proxy that I described.  This idea does appear to be crossing
the "programmable syntax" line unless f(...) is made to always push unevaluated
arguments to the stack and the evaluation of arguments is handled by the
CALL_FUNCTION op-code. In the later case, the evaluation can be guided by the
information associated with the function object.  I believe type annotations
would provide a natural place to specify this extra information.  If 
CALL_FUNCTION finds an undecorated function object on the stack, it would
just evaluate all the arguments and proceed as in 2.x, but if type decoration
is available, arguments specified as promise[interface] will be wrapped in
proxies supporting the given interface.  Mixing "pass by" information with
the type annotations has an additional advantage of solving the problem of
when a promise should be fulfilled: at the time when an interface method is
called.

This is still far from a proposal, I've just tried to describe something that
I think is implementable.





From jcarlson at uci.edu  Wed May 31 21:01:45 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 31 May 2006 12:01:45 -0700
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <2375C3EE-7263-4CCF-BE7B-5F4C9A46F205@mac.com>
References: <20060530235244.6977.JCARLSON@uci.edu>
	<2375C3EE-7263-4CCF-BE7B-5F4C9A46F205@mac.com>
Message-ID: <20060531114550.6983.JCARLSON@uci.edu>


Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> > There was also a proposal that I was supposed to work on getting
> > formalized somewhat over a year ago about getting __main__ relative
> > imports to have __main__.XXX names, which would further reduce (if not
> > remove entirely) name collisions in sys.modules, but I got caught  
> > up in
> > my attempt at a relative import hook.
> 
> That would really suck.

Here's a better description of what I was trying to get across, which
likely sucks quite a bit less than what I think you were thinking I
meant.

Every import in the module known as __main__ functions exactly the same
as it did before.  That is...

    import my_library
    from my_package import other_library

All continue to work.  However, the proposal I was working on (which was
suggested by Guido) was that the __name__ given to those modules and
packages would be relative to __main__, that is, you would get
'__main__.my_library', '__main__.my_package', and
'__main__.my_package.other_library' as __name__ attributes of those
modules and packages, and those same names would be used in sys.modules.

The purpose of this was that so sys.modules could do the right thing,
vis-a-vis module import caching and accidental system import shadowing.
Like, say for example, I have an 'email' module that I have written, but
I discover later that I want to access the standard library 'email'
package, I can't right now because even if my 'email' isn't in the
current module's path search, it will give me my 'email' because it is
in the sys.modules cache.

However, if all modules which are imported relative to __main__ got a
__main__ prefix in their name, my email module would presumably get a
name of '__main__.email', and I could still import the stdlib email
package, becayse sys.modules would have a '__main__.email' and not a
'MYTHICAL_STDLIB_PREFIX.email'


One of the reasons for relegating the standard library to a 'py', or
site packages to a 'site' is that one would ultimately reduce name
collisions, and one could be explicit about where they expect their
modules and packages to come from: the standard library, user-installed
site-packages, etc.


Whether or not to include the just-mentioned MYTHICAL_STDLIB_PREFIX in
all system/package imports is somewhat different, but also related to,
whether or not to create a higher-level py or site package.  I can
understand the _undesireability_ of having those higher-level packages,
but perhaps you can understand the _desireability_ of having names
include a prefix which defines where the modules/packages came from,
specifically to reduce and/or remove __name__ collisions with user code.


 - Josiah


From solipsis at pitrou.net  Wed May 31 21:04:26 2006
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 31 May 2006 21:04:26 +0200
Subject: [Python-3000] packages in the stdlib
In-Reply-To: <bbaeab100605311131h37f7f231k1c30ebb20cf873f0@mail.gmail.com>
References: <44716940.9000300@acm.org> <1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<1149080922.5718.20.camel@fsol>
	<bbaeab100605310957u4f49bcbbwb2512dd195ba4b49@mail.gmail.com>
	<1149095977.5718.51.camel@fsol>
	<bbaeab100605311131h37f7f231k1c30ebb20cf873f0@mail.gmail.com>
Message-ID: <1149102266.5718.62.camel@fsol>

Le mercredi 31 mai 2006 ? 11:31 -0700, Brett Cannon a ?crit :
> If there were categories, though, I would most likely have the handful
> of package names memorized.  So I would run help() on the packages to
> see what modules they had and the summary.  Basically what I should
> probably be doing with the online docs' hierarchy, but entirely at the
> interpreter.  I *really* prefer using the interpreter for quick doc
> lookup and only hit the online docs for detailed documentation or I
> have no clue where something is.  If I can cut down on the instances
> of not having a clue where something is by some basic categorization
> at the interpreter I consider that a win. 

Ok, so we are looking for a way to easily find library modules while in
the command line, or automatically generate topical documentation.
But it doesn't mean we must mandate "from net import jabber" instead of
the more obvious "import jabber", for the common case where you already
know the module name and just want to use it.

So perhaps there is a way to create some kind of "virtual packages" or
"categories" in which existing modules could register themselves. This
could allow third-party modules (e.g. "gtk") to register themselves in
stdlib-supplied virtual packages (e.g. "gui"), for documentation and
findability purposes. "import gui; help(gui)" would give you the list of
available modules.

Regards

Antoine.



From brett at python.org  Wed May 31 21:09:20 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 31 May 2006 12:09:20 -0700
Subject: [Python-3000] packages in the stdlib
In-Reply-To: <430FBE78-D78A-4346-BD18-27D1D038AFE7@mac.com>
References: <44716940.9000300@acm.org>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<1149080922.5718.20.camel@fsol>
	<bbaeab100605310957u4f49bcbbwb2512dd195ba4b49@mail.gmail.com>
	<1149095977.5718.51.camel@fsol>
	<430FBE78-D78A-4346-BD18-27D1D038AFE7@mac.com>
Message-ID: <bbaeab100605311209n28ce4f07qcbe97d928610edcb@mail.gmail.com>

On 5/31/06, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>
> On 31-mei-2006, at 19:19, Antoine Pitrou wrote:
>
> > Le mercredi 31 mai 2006 ? 09:57 -0700, Brett Cannon a ?crit :
> >>
> >> That might be true of http, but what about modules with a more
> >> ambiguous name?
> >
> > Then perhaps the name can be made less ambiguous ;)
> > For example "ElementTree" could be named "xmltree", or whatever.
> >
> >> But with Java (don't have much .NET experience) the issue is they put
> >> data structures in java.util which doesn't explain anything.  But if
> >> it had been named datastruct or something more meaningful would it be
> >> so bad?
> >
> > No, but it still would be additional baggage to remember.
> > It is clear a "deque" is a collection and a "heapq" is a specific kind
> > of data structure, so why try to categorize them whereas the
> > categorization does not bring any additional information or
> > functionality to the programmer?
>
> And what would a more hierarchical namespace mean for 3th-party code?
> If there were to be a toplevel package "gui" that contains gui code
> such as tkinter it would be very natural to assume that wxWidgets or
> gtk are also in the gui namespace, even if they aren't part of the
> standard library. I haven't thought enough about this to know which
> option I'd hate more, requiring 3th-party libraries to pick unobvious
> names or not knowing if net.jabber is a standard library package I
> didn't use yet or something that is was installed sepereately.


Why would a 3rd-party module be installed into the stdlib namespace?
net.jabber wouldn't exist unless it was in the stdlib or the module's author
decided to be snarky and inject their module into the stdlib namespace.

And this ambiguity issue exists now.  If a module author choose some generic
name, how are you supposed to know where it is in the stdlib or not?

And I really don't think the gui example is an issue anyway.  wxWidgets
names itself wx to prevent these problems to begin with.  I really don't
think users are going to be confused by not finding third-party code in
stdlib packages.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060531/e7a295fd/attachment.htm 

From jcarlson at uci.edu  Wed May 31 21:10:07 2006
From: jcarlson at uci.edu (Josiah Carlson)
Date: Wed, 31 May 2006 12:10:07 -0700
Subject: [Python-3000] weakrefs and cyclic references
In-Reply-To: <1d85506f0605311102la44fb40j65954db9bad9a29c@mail.gmail.com>
References: <1d85506f0605311102la44fb40j65954db9bad9a29c@mail.gmail.com>
Message-ID: <20060531120231.6986.JCARLSON@uci.edu>


"tomer filiba" <tomerfiliba at gmail.com> wrote:
> the current gc already detects cyclic referencing between objects,
> and by what i understood, it can free the memory the objects take,
> but __del__ is never call because there's not telling where to
> start the __del__ chain.

Not all cyclic references are easily discovered during assignment, and
could induce huge overhead during assignments in general.

According to my experience, there are two great ways of dealing with
object cycles:
1. never write __del__ methods
2. use weakrefs

The former avoids the __del__ never being called mess assuming that you
don't need any manual cleanup, and the latter allows for arbitrary
cleanup methods.


 - Josiah


From brett at python.org  Wed May 31 21:12:49 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 31 May 2006 12:12:49 -0700
Subject: [Python-3000] packages in the stdlib
In-Reply-To: <1149102266.5718.62.camel@fsol>
References: <44716940.9000300@acm.org> <4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<1149080922.5718.20.camel@fsol>
	<bbaeab100605310957u4f49bcbbwb2512dd195ba4b49@mail.gmail.com>
	<1149095977.5718.51.camel@fsol>
	<bbaeab100605311131h37f7f231k1c30ebb20cf873f0@mail.gmail.com>
	<1149102266.5718.62.camel@fsol>
Message-ID: <bbaeab100605311212s40b1372bt4e91d929ca1d8186@mail.gmail.com>

On 5/31/06, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Le mercredi 31 mai 2006 ? 11:31 -0700, Brett Cannon a ?crit :
> > If there were categories, though, I would most likely have the handful
> > of package names memorized.  So I would run help() on the packages to
> > see what modules they had and the summary.  Basically what I should
> > probably be doing with the online docs' hierarchy, but entirely at the
> > interpreter.  I *really* prefer using the interpreter for quick doc
> > lookup and only hit the online docs for detailed documentation or I
> > have no clue where something is.  If I can cut down on the instances
> > of not having a clue where something is by some basic categorization
> > at the interpreter I consider that a win.
>
> Ok, so we are looking for a way to easily find library modules while in
> the command line, or automatically generate topical documentation.
> But it doesn't mean we must mandate "from net import jabber" instead of
> the more obvious "import jabber", for the common case where you already
> know the module name and just want to use it.
>
> So perhaps there is a way to create some kind of "virtual packages" or
> "categories" in which existing modules could register themselves. This
> could allow third-party modules (e.g. "gtk") to register themselves in
> stdlib-supplied virtual packages (e.g. "gui"), for documentation and
> findability purposes. "import gui; help(gui)" would give you the list of
> available modules.


I see possible problems with this because then we run into your issue with
packaging; where do things go?  At least with the stdlib we have sufficient
control to make sure things follow a standard in terms of where thing should
end up.

I would rather do an all-or-nothing solution to the whole package hierarchy
for the stdlib.  Does anyone else have an opinion on any of this since this
ending up just being fundamental differences in how two people like to
organize modules?

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060531/15b15f69/attachment-0001.html 

From collinw at gmail.com  Wed May 31 21:33:13 2006
From: collinw at gmail.com (Collin Winter)
Date: Wed, 31 May 2006 21:33:13 +0200
Subject: [Python-3000] Using a list for *args (was: Type annotations:
	annotating generators)
In-Reply-To: <ca471dc20605292030q4f13b9fv7df3397edaab537@mail.gmail.com>
References: <43aa6ff70605271348y352921f6he107ba1f40a0393a@mail.gmail.com>
	<ca471dc20605292030q4f13b9fv7df3397edaab537@mail.gmail.com>
Message-ID: <43aa6ff70605311233i6f8195fdye2ed52fc559830ea@mail.gmail.com>

On 5/30/06, Guido van Rossum <guido at python.org> wrote:
> Please be specific. Which places are affected? This shouldn't be
> answered generically but on a case-by-case basis.

My final report:

All in all, the tuple->list change was minimally invasive. The two
most prevalent issues were

1) converting *args to a tuple for hashing purposes,
2) appending/prepending items to *args, then trying to
hash/do-something-else with it.

In both cases, the code changes were minor.

The most striking cases were logging.LogRecord.__init__() and
cgi.dolog() (broadly, "msg % args"), both of which are fed by numerous
other functions like

def warning(self, msg, *args):
    self._log(msg, args, ....)

There are also other places that feed the logging.* and cgi.*
functions with dicts, meaning that a simple call to tuple() breaks
things sometimes. This means that extra logic has to be added to check
for the presence of a dict, slightly complicating this uncommon
usecase.


Overall, I've chosen to keep the external interfaces of the changed
modules/packages the same; if there's a desire to change them later,
this SVN commit can be used to figure out where adjustments should be
made. Most of the changes involve the test suite, primarily where
higher-order functions are concerned.

I've submitted a patch to implement this change as SF #1498441
(http://python.orf/sf/1498441); it's assigned to Guido.

Collin Winter

From jimjjewett at gmail.com  Wed May 31 22:04:43 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 31 May 2006 16:04:43 -0400
Subject: [Python-3000] stdlib reorganization
In-Reply-To: <e5ka4f$nf6$1@sea.gmane.org>
References: <bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<20060530104546.695F.JCARLSON@uci.edu>
	<7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com>
	<200605310157.04260.fdrake@acm.org> <e5k71p$ai8$1@sea.gmane.org>
	<e5ka4f$nf6$1@sea.gmane.org>
Message-ID: <fb6fbf560605311304y5f6b3f29yd0f2400326357b77@mail.gmail.com>

On 5/31/06, Tim Hochberg <tim.hochberg at ieee.org> wrote:

> However, wx currently, and presumably for the forseeable future, lives
> in site packages, so we'd actually have something like:
>
>      from site.gui import wx
>      from site.gui import pygui
>      from py.gui import tkinter

> That seems confusing and suboptimal.

Requiring the "site" or "py" or "__main__" prefix is indeed suboptimal.

Puttting it in the module's cached name so that you can tell where it
came from is useful.

Note that one common use case is evaluating (or using) a package that
is distributed both in the stdlib and separately.

    import logging             # I don't care where you get it.
    import py.logging          # Get the stdlib version; it is
sufficient and I tested with it
    import site.logging        # Get the version used by this sysadmin
(with her config tweaks)
    import .utils.logging      # Get a version distributed with this program


>      >>> import gui
>      >>> dir(gui)
>      ['wx', 'tkinter', 'pygui']

Note that wx, tkinter, and pygui are probably not in the same
directory.  I *think* this is the primary use case behind namespace
packages.

-jJ

From jimjjewett at gmail.com  Wed May 31 22:22:34 2006
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 31 May 2006 16:22:34 -0400
Subject: [Python-3000] packages in the stdlib
In-Reply-To: <1149095977.5718.51.camel@fsol>
References: <44716940.9000300@acm.org> <1148318480.19392.6.camel@fsol>
	<ca471dc20605221028y91d50e0n4dcc2ed7b186fc70@mail.gmail.com>
	<4472B196.7070506@acm.org>
	<ca471dc20605230817x331241e6r45e63c4c1c0eb8ed@mail.gmail.com>
	<447BC126.8050107@acm.org>
	<bbaeab100605300925k151a1437gea18eeaafe5c8068@mail.gmail.com>
	<1149080922.5718.20.camel@fsol>
	<bbaeab100605310957u4f49bcbbwb2512dd195ba4b49@mail.gmail.com>
	<1149095977.5718.51.camel@fsol>
Message-ID: <fb6fbf560605311322w64d9e6c2v45ae24f66d715107@mail.gmail.com>

On 5/31/06, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le mercredi 31 mai 2006 ? 09:57 -0700, Brett Cannon a ?crit :

> > That might be true of http, but what about modules with a more
> > ambiguous name?

> Then perhaps the name can be made less ambiguous ;)
> For example "ElementTree" could be named "xmltree", or whatever.

(1)  It isn't really limited to xml elements.
(2)  The fact that there is disagreement means that any specific name
will be hard to find when browsing for relevant modules -- as when
learning the language.  But if there are only 5-30 toplevel packages,
people have a better chance of knowing which collection to look in.
(If borderline modules could exist or be referenced in multiple
namespaces, it might get even easier, so long as it was clear that
these were references rather than alternates.)

> No, but it still would be additional baggage to remember.
> It is clear a "deque" is a collection and a "heapq" is a specific kind
> of data structure,

Not to me.

I had no idea what a "deque" was until I read the module, as I would
never have used that particular abbreviation.

My first assumption about heapq was that it implemented a Queue
interface using a heap, and was therefore threading related.

> The documentation can be topically structured, which is indeed handy
> when discovering Python and its stdlib, but why force the categorization
> on the programmer while it does not bring any benefits?

Are you assuming that people will learn about python by printing out
hundreds of pages and reading them, instead of just starting in?

I actually did that, but I know it is only because I'm strange.  (And
I did much of the reading on a computerless vacation.)   After the
initial reading, I have used help at the interactive prompt; if I have
to squint at the separate documentation, I get unhappy.

-jJ

From tdelaney at avaya.com  Wed May 31 23:11:57 2006
From: tdelaney at avaya.com (Delaney, Timothy (Tim))
Date: Thu, 1 Jun 2006 07:11:57 +1000
Subject: [Python-3000] packages in the stdlib
Message-ID: <2773CAC687FD5F4689F526998C7E4E5FF1E73E@au3010avexu1.global.avaya.com>

Antoine Pitrou wrote:

> Le mardi 30 mai 2006 ? 09:25 -0700, Brett Cannon a ?crit :
>> 
> The current flat namespace for the standard library is one *very*
> pleasant feature of Python. You only have to remember the module name
> itself, not its position in the hierarchy. Compare this with Java
> or .Net...

Yes - it is a very pleasant feature. However, it it also conducive to causing module/package name clashes.

I have no problems remembering the fully-qualified classnames I use most in Java, and have no problems looking up in the reference for ones I don't use as often. The same would apply to Python.

Tim Delaney