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: References: <4450C80D.50002@iinet.net.au> 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: On 4/30/06, 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... 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" 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 "", line 1, in File "", 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: <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: <44506457.1040607@gmx.net> <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: References: <4450C80D.50002@iinet.net.au> Message-ID: <9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com> On 4/27/06, 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. I disagree, and I believe that would be a big mistake to change it. -- Thomas Wouters 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 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 "", 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: (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> <9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com> Message-ID: 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 ;-) 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: > 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: References: <4450C80D.50002@iinet.net.au> <9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com> Message-ID: <9e804ac0605010341u68e77864u6d2f8b48848f725c@mail.gmail.com> On 5/1/06, Fredrik Lundh 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 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> <9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com> <9e804ac0605010341u68e77864u6d2f8b48848f725c@mail.gmail.com> Message-ID: 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. 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> <9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com> <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> <9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com> <9e804ac0605010341u68e77864u6d2f8b48848f725c@mail.gmail.com> <4455ECA8.3000408@gmail.com> Message-ID: 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) 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> <9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com> <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: References: <4450C80D.50002@iinet.net.au> <9e804ac0605010058w58b4fb64mab4438edfd646bb4@mail.gmail.com> 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: References: <200604250009.04347.birchb@tpg.com.au> 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: On 5/1/06, Greg Ewing 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: <445279F7.8080306@v.loewis.de> <4452916F.1030304@v.loewis.de> <4452D871.9020901@v.loewis.de> <4453FBFE.7060001@v.loewis.de> <44550467.20304@v.loewis.de> Message-ID: On 4/30/06, "Martin v. L?wis" 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: On 4/29/06, Rudy Rudolph 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 (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" 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: 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: References: 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: 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.) 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: References: <17489.31069.526965.186604@montanaro.dyndns.org> <4451AF74.8040702@gmx.net> <445279F7.8080306@v.loewis.de> <4452916F.1030304@v.loewis.de> Message-ID: 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: <44563E8F.8050001@ewtllc.com> Message-ID: On 5/1/06, Raymond Hettinger 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: Nick Coghlan 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: > > 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: On 5/1/06, Josiah Carlson wrote: > > If you want to get my general opinion; -1 on all of your recommendations. > In each part, I describe why. > > Alexander Belopolsky 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 "", 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 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: References: <20060501011031.674D.JCARLSON@uci.edu> Message-ID: <20060501122448.675F.JCARLSON@uci.edu> "Alexander Belopolsky" wrote: > On 5/1/06, Josiah Carlson wrote: > > > > If you want to get my general opinion; -1 on all of your recommendations. > > In each part, I describe why. > > > > Alexander Belopolsky 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 "", 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: 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...) 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> <20060501122448.675F.JCARLSON@uci.edu> Message-ID: 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: 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: References: 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." 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: <4456790B.7080409@ewtllc.com> Message-ID: 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 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" 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) >>> 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: References: <20060501105538.6759.JCARLSON@uci.edu> Message-ID: <20060501145901.676E.JCARLSON@uci.edu> "Fredrik Lundh" 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 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: References: Message-ID: On 4/29/06, Steven Bethard wrote: > On 4/27/06, Guido van Rossum 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 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: 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: 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> <1f7befae0604271154w6ba78d3p3b6851e85d4dc68d@mail.gmail.com> <1f7befae0604282307x10335f80x55d75509ff55eedb@mail.gmail.com> Message-ID: On 4/30/06, Fredrik Lundh 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 "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><1f7befae0604271154w6ba78d3p3b6851e85d4dc68d@mail.gmail.com><1f7befae0604282307x10335f80x55d75509ff55eedb@mail.gmail.com> Message-ID: 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__) 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: References: Message-ID: <20060502010154.6778.JCARLSON@uci.edu> Talin 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 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: References: Message-ID: <9e804ac0605020138o7a1c8348j1e6c33caf5c595a5@mail.gmail.com> On 5/1/06, Guido van Rossum 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 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 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: References: <44563E8F.8050001@ewtllc.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: <9e804ac0605020138o7a1c8348j1e6c33caf5c595a5@mail.gmail.com> Message-ID: <445726EE.7040603@gmail.com> Thomas Wouters wrote: > > On 5/1/06, *Guido van Rossum* > 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 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 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 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. 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: References: <20060501090813.8y05zi9jhpq88kw4@login.werra.lunarpages.com> <06May1.095920pdt.58641@synergy1.parc.xerox.com> 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: References: <200605012050.08254.birchb@tpg.com.au> <4455E9B5.3040006@canterbury.ac.nz> 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<> 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: References: Message-ID: On 5/1/06, Talin 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: On 5/2/06, Michael Chermside 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> <200605022255.00725.birchb@tpg.com.au> Message-ID: On 5/2/06, Bill Birch 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> <200605022255.00725.birchb@tpg.com.au> Message-ID: 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: References: Message-ID: <20060502091647.677E.JCARLSON@uci.edu> "Guido van Rossum" 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: <20060502091647.677E.JCARLSON@uci.edu> Message-ID: On 5/2/06, Josiah Carlson wrote: > > "Guido van Rossum" 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: References: <1145807918.069455.241510@i40g2000cwc.googlegroups.com> <4450928c$0$21107$626a54ce@news.free.fr> 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: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> Message-ID: "Nick Coghlan" 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: References: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> Message-ID: On 5/2/06, Terry Reedy wrote: > > "Nick Coghlan" 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> <1f7befae0605021030r458a371fm54f263cfaf9c90cf@mail.gmail.com> Message-ID: 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 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 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: 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 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: On 5/2/06, 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. 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 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: 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: References: Message-ID: > 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: References: <44563E8F.8050001@ewtllc.com> <44572190.30007@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: 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: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> <4457AD62.4060003@ewtllc.com> Message-ID: 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: <44563E8F.8050001@ewtllc.com> <44572190.30007@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: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> <4457AD62.4060003@ewtllc.com> <1146599816.2268.107.camel@resist.wooz.org> Message-ID: 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 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: References: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> <4457AD62.4060003@ewtllc.com> <1146599816.2268.107.camel@resist.wooz.org> Message-ID: <3d2ce8cb0605021316q43a712a4yb050d965df2430c6@mail.gmail.com> On 5/2/06, Guido van Rossum 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: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> <4457AD62.4060003@ewtllc.com> <1146599816.2268.107.camel@resist.wooz.org> <3d2ce8cb0605021316q43a712a4yb050d965df2430c6@mail.gmail.com> Message-ID: On 5/2/06, Mike Klaas wrote: > On 5/2/06, Guido van Rossum 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: Message-ID: "Talin" 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: Message-ID: Guido van Rossum python.org> writes: > On 5/1/06, Talin 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: References: Message-ID: On 5/2/06, Talin 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() 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() 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: On 5/2/06, Josiah Carlson 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: Message-ID: Guido van Rossum python.org> writes: > On 5/2/06, Talin 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() 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() 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: References: Message-ID: On 5/1/06, Guido van Rossum 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: References: <20060501184213.6775.JCARLSON@uci.edu> <44574C3C.5030000@canterbury.ac.nz> <20060502093334.6781.JCARLSON@uci.edu> 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: References: Message-ID: On 5/2/06, Talin 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: References: Message-ID: On 5/2/06, Jim Jewett wrote: > On 5/1/06, Guido van Rossum 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: References: <20060502091647.677E.JCARLSON@uci.edu> Message-ID: <20060502215314.6787.JCARLSON@uci.edu> "Guido van Rossum" wrote: > On 5/2/06, Josiah Carlson 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: References: Message-ID: <20060502220500.678A.JCARLSON@uci.edu> "Guido van Rossum" 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() 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: <20060502220500.678A.JCARLSON@uci.edu> Message-ID: On 5/2/06, Josiah Carlson 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: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> <4457AD62.4060003@ewtllc.com> Message-ID: On 5/2/06, 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. 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> <1146610278.5848.9.camel@fsol> Message-ID: 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 ) 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: Message-ID: 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). 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: 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: References: 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: References: <20060501184213.6775.JCARLSON@uci.edu> <44574C3C.5030000@canterbury.ac.nz><20060502093334.6781.JCARLSON@uci.edu> <1146610278.5848.9.camel@fsol> 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: 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) 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> <20060502215314.6787.JCARLSON@uci.edu> Message-ID: 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. 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: References: Message-ID: > From: Raymond Hettinger > 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: References: 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: References: Message-ID: On 5/3/06, Greg Wilson 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: <44588A24.9020101@gmail.com> Message-ID: 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: References: 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: References: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> <4457AD62.4060003@ewtllc.com> Message-ID: On 5/2/06, 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. 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: References: <20060502091647.677E.JCARLSON@uci.edu> 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: References: Message-ID: On 5/2/06, Fredrik Lundh 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: References: <20060502220500.678A.JCARLSON@uci.edu> Message-ID: <20060503010744.6790.JCARLSON@uci.edu> "Guido van Rossum" wrote: > On 5/2/06, Josiah Carlson 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: On 5/3/06, Michael Chermside 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: References: Message-ID: <20060503094338.6793.JCARLSON@uci.edu> "Jim Jewett" wrote: > > On 5/2/06, 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. > > 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: References: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> <4457AD62.4060003@ewtllc.com> Message-ID: On 5/2/06, Neal Norwitz wrote: > On 5/2/06, 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. > > 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: References: Message-ID: On 5/3/06, Greg Wilson 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: References: <44563E8F.8050001@ewtllc.com> <44572190.30007@gmail.com> <4457AD62.4060003@ewtllc.com> Message-ID: On 5/3/06, Jim Jewett 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> <20060503010744.6790.JCARLSON@uci.edu> Message-ID: On 5/3/06, Josiah Carlson wrote: > "Guido van Rossum" 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: On 5/3/06, Edward C. Jones 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 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: 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) wrote: > Jim Jewett wrote: > > > On 5/2/06, 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. > > > > 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: On 5/3/06, Delaney, Timothy (Tim) 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) 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: References: <20060503010744.6790.JCARLSON@uci.edu> Message-ID: <20060503182349.6796.JCARLSON@uci.edu> "Guido van Rossum" 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: References: 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: References: <2773CAC687FD5F4689F526998C7E4E5F074372@au3010avexu1.global.avaya.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 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: 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: >>>>> "Michael" == Michael Chermside 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: 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" 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: References: 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: References: Message-ID: <20060504140730.GC27395@mithrandi.za.net> * Talin [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: References: Message-ID: On 5/3/06, Talin 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: References: <1145807918.069455.241510@i40g2000cwc.googlegroups.com> <4450928c$0$21107$626a54ce@news.free.fr> <1f7befae0605021030r458a371fm54f263cfaf9c90cf@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: <20060503182349.6796.JCARLSON@uci.edu> Message-ID: <20060504114107.67A2.JCARLSON@uci.edu> Josiah Carlson 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: On 5/3/06, Tim Peters 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: <20060503182349.6796.JCARLSON@uci.edu> <20060504114107.67A2.JCARLSON@uci.edu> Message-ID: 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; } ... 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:>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 &param) {param += 5;} void bar(int &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(&param): param += 5 def bar(&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(&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: <20060503182349.6796.JCARLSON@uci.edu> <20060504114107.67A2.JCARLSON@uci.edu> Message-ID: Can you please post the benchmarking code? On 5/4/06, Josiah Carlson wrote: > > Josiah Carlson 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: On 5/4/06, Rudy Rudolph 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> <1f7befae0605021030r458a371fm54f263cfaf9c90cf@mail.gmail.com> <1f7befae0605041207k64aff52cgf7fdbf5d7fe387be@mail.gmail.com> Message-ID: <873bfph3gb.fsf@qrnik.zagroda> "Tim Peters" 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: References: <20060504114107.67A2.JCARLSON@uci.edu> Message-ID: <20060504152340.67AB.JCARLSON@uci.edu> "Guido van Rossum" 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: References: 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. 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 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: <44596963.8070200@canterbury.ac.nz> Message-ID: "Greg Ewing" 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: On 5/5/06, Collin Winter wrote: > On 5/1/06, Nick Coghlan 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." 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: <8324284203556580454@unknownmsgid> Message-ID: On 5/5/06, Bill Janssen 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> <20060504152340.67AB.JCARLSON@uci.edu> Message-ID: On 5/4/06, Josiah Carlson wrote: > > "Guido van Rossum" 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 > -----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." Message-ID: <06May5.210705pdt."58641"@synergy1.parc.xerox.com> GvR writes: > On 5/5/06, Bill Janssen 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 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: >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: References: <20060504152340.67AB.JCARLSON@uci.edu> Message-ID: <20060506023436.67D1.JCARLSON@uci.edu> "Guido van Rossum" wrote: > > On 5/4/06, Josiah Carlson wrote: > > > > "Guido van Rossum" 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: References: 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 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 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: References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com> <4455C828.1060209@gmail.com> <43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com> Message-ID: <43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com> On 5/5/06, Guido van Rossum wrote: > On 5/5/06, Collin Winter wrote: > > On 5/1/06, Nick Coghlan 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. > Nope, that is not what I meant. Eventually adding *more* reliability to py programs. Cheers 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> <43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com> Message-ID: On 5/6/06, Collin Winter wrote: > On 5/5/06, Guido van Rossum 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: On 5/6/06, Krishna Sankar 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 > -----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 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: <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. 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: <445C8994.3020206@canterbury.ac.nz> <200605061428.08491.fdrake@acm.org> Message-ID: On 5/6/06, Fred L. Drake, Jr. 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: Bill Janssen 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> <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: 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: References: 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: <445D89E5.8040609@canterbury.ac.nz> Message-ID: Greg Ewing 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: References: <445D89E5.8040609@canterbury.ac.nz> Message-ID: <9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com> On 5/7/06, Talin wrote: > > Greg Ewing 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 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: <445D89E5.8040609@canterbury.ac.nz> <9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com> Message-ID: Thomas Wouters 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: References: <445D89E5.8040609@canterbury.ac.nz> <9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com> Message-ID: <79990c6b0605070435o522e342fre926d9f1fc7ec88d@mail.gmail.com> On 5/7/06, Talin 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: References: <445D89E5.8040609@canterbury.ac.nz> 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: References: <445D89E5.8040609@canterbury.ac.nz> <9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com> 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: <445D89E5.8040609@canterbury.ac.nz> <9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com> <445DDE50.6060108@canterbury.ac.nz> Message-ID: 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: <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: References: Message-ID: On 5/6/06, Talin 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 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: References: Message-ID: > From: Greg Ewing > 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: References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com> <4455C828.1060209@gmail.com> <43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com> <43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com> Message-ID: <43aa6ff70605071147g5820c0aet61db0290bfca46e7@mail.gmail.com> On 5/6/06, Guido van Rossum wrote: > On 5/6/06, Collin Winter wrote: > > On 5/5/06, Guido van Rossum 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: References: Message-ID: <79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com> On 5/7/06, Greg Wilson wrote: > > From: Greg Ewing > > 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: Message-ID: Guido van Rossum 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: (talin@acm.org's message of "Sun, 7 May 2006 20:43:58 +0000 (UTC)") References: Message-ID: <87veshpn08.fsf@qrnik.zagroda> Talin 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: On 5/7/06, Oleg Broytmann 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: References: Message-ID: <9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com> On 5/7/06, Talin 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 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: <9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com> Message-ID: Thomas Wouters python.org> writes: > On 5/7/06, Talin 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: <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: References: 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: References: <445D4F70.2080208@canterbury.ac.nz> <20060507215156.GA15329@phd.pp.ru> 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 "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: <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: References: Message-ID: On 5/1/06, Guido van Rossum wrote: > On 4/29/06, Steven Bethard 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> <43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com> <43aa6ff70605071147g5820c0aet61db0290bfca46e7@mail.gmail.com> Message-ID: On 5/7/06, Collin Winter 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: 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: References: Message-ID: 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 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: <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: <79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com> <445E970F.6020303@canterbury.ac.nz> Message-ID: <79990c6b0605080042l8ce3b30p94d921126e781113@mail.gmail.com> On 5/8/06, 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. 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: References: <9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com> Message-ID: <79990c6b0605080046j7f3cacfmce62a202eed14908@mail.gmail.com> On 5/8/06, Talin 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: <9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com> <79990c6b0605080046j7f3cacfmce62a202eed14908@mail.gmail.com> Message-ID: <059901c67274$fe392ad0$53b02997@bagio> Paul Moore 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: <79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com> <445E970F.6020303@canterbury.ac.nz> Message-ID: 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: <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: References: <9e804ac0605071608u63db66fetc01d2f93376c378@mail.gmail.com> Message-ID: <9e804ac0605080252i782b6ec5ubdc51575f8e9c4ca@mail.gmail.com> On 5/8/06, Talin wrote: > > Thomas Wouters 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 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: <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: <445D89E5.8040609@canterbury.ac.nz> <9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com> Message-ID: 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...) 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: <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: <445D89E5.8040609@canterbury.ac.nz><9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com> <79990c6b0605070435o522e342fre926d9f1fc7ec88d@mail.gmail.com> Message-ID: 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. 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: References: <445D89E5.8040609@canterbury.ac.nz> <9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com> Message-ID: <9e804ac0605080629tdbaf9d5gb76ea497bd80feb4@mail.gmail.com> On 5/8/06, Fredrik Lundh 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 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: <445D89E5.8040609@canterbury.ac.nz> <9e804ac0605070041w231411d8v5673539ce8051283@mail.gmail.com> Message-ID: 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. 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: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> Message-ID: 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) 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: References: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> Message-ID: <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> On 5/8/06, Fredrik Lundh 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 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: <445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.org> Message-ID: On 5/8/06, Talin 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: On 5/8/06, Paul Boddie 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: References: <79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com> <445E970F.6020303@canterbury.ac.nz> Message-ID: 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: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <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. 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: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> Message-ID: On 5/8/06, Barry Warsaw 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 "", line 1, in ? TypeError: 'str' object is not callable >>> s() Traceback (most recent call last): File "", line 1, in ? File "", 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: References: <200605081458.06846.paul@boddie.org.uk> Message-ID: <200605081749.05322.paul@boddie.org.uk> On Monday 08 May 2006 16:20, Jim Jewett wrote: > On 5/8/06, Paul Boddie 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. 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: References: Message-ID: On 5/6/06, Talin 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: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> Message-ID: <87vesg1hz3.fsf@qrnik.zagroda> Barry Warsaw 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: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <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 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: References: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> 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 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 "", line 1, in ? > TypeError: 'str' object is not callable > >>> s() > Traceback (most recent call last): > File "", line 1, in ? > File "", 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: On 5/8/06, Giovanni Bajo 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: References: <43aa6ff70604302022n112b53scc366540fcbcb8dc@mail.gmail.com> <4455C828.1060209@gmail.com> <43aa6ff70605051230u7a66c5e5pd981db2296eebe88@mail.gmail.com> <43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com> <43aa6ff70605071147g5820c0aet61db0290bfca46e7@mail.gmail.com> Message-ID: <43aa6ff70605081422j468b8a04o1bfe7f6b1ce4aec1@mail.gmail.com> On 5/7/06, Guido van Rossum wrote: > On 5/7/06, Collin Winter 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> <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: References: <200605081341.07969.paul@boddie.org.uk> <20060508141336.GA21306@panix.com> <02f201c672cf$99fc18b0$bf03030a@trilan> Message-ID: <445FD8C4.9030503@canterbury.ac.nz> Alex Martelli wrote: > On 5/8/06, Giovanni Bajo 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> <445FD8C4.9030503@canterbury.ac.nz> Message-ID: On 5/8/06, Greg Ewing wrote: > Alex Martelli wrote: > > On 5/8/06, Giovanni Bajo 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> <43aa6ff70605060709m35fb6ba0v8da56be5b27756c@mail.gmail.com> <43aa6ff70605071147g5820c0aet61db0290bfca46e7@mail.gmail.com> <43aa6ff70605081422j468b8a04o1bfe7f6b1ce4aec1@mail.gmail.com> Message-ID: Can we just agree to disagree? Read the piece on python.org/dev about knowing when to stop. On 5/8/06, Collin Winter wrote: > On 5/7/06, Guido van Rossum wrote: > > On 5/7/06, Collin Winter 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: References: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> Message-ID: On 5/8/06, Steven Bethard 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 "", line 1, in ? > TypeError: 'str' object is not callable > >>> s() > Traceback (most recent call last): > File "", line 1, in ? > File "", 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: References: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> Message-ID: On 5/8/06, Guido van Rossum wrote: > On 5/8/06, Steven Bethard 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 "", line 1, in ? > > TypeError: 'str' object is not callable > > >>> s() > > Traceback (most recent call last): > > File "", line 1, in ? > > File "", 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 "", line 1, in ? TypeError: iteration over non-sequence >>> 'abc'['1'] Traceback (most recent call last): File "", line 1, in ? TypeError: string indices must be integers >>> str(1, 16) Traceback (most recent call last): File "", line 1, in ? TypeError: str() takes at most 1 argument (2 given) >>> 42 + '56' Traceback (most recent call last): File "", 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: References: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> Message-ID: 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 wrote: > On 5/8/06, Guido van Rossum wrote: > > On 5/8/06, Steven Bethard 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 "", line 1, in ? > > > TypeError: 'str' object is not callable > > > >>> s() > > > Traceback (most recent call last): > > > File "", line 1, in ? > > > File "", 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 "", line 1, in ? > TypeError: iteration over non-sequence > >>> 'abc'['1'] > Traceback (most recent call last): > File "", line 1, in ? > TypeError: string indices must be integers > >>> str(1, 16) > Traceback (most recent call last): > File "", line 1, in ? > TypeError: str() takes at most 1 argument (2 given) > >>> 42 + '56' > Traceback (most recent call last): > File "", 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: References: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> 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: <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> <1147147707.12713.123.camel@resist.wooz.org> Message-ID: 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 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: References: <445D89E5.8040609@canterbury.ac.nz> <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> Message-ID: 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 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: <445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.org> Message-ID: Jim Jewett gmail.com> writes: > On 5/8/06, Talin 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: References: <445DDC87.5040403@canterbury.ac.nz> <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> <1147147707.12713.123.camel@resist.wooz.org> 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: References: <445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.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: Josiah Carlson uci.edu> writes: > Greg Ewing 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: Message-ID: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com> At 06:19 AM, 9 May 2006 +0000, Talin 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." 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: 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: <5.1.1.6.0.20060509095435.01e94908@mail.telecommunity.com> Message-ID: On 5/9/06, Phillip J. Eby wrote: > At 06:19 AM, 9 May 2006 +0000, Talin 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 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: <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: <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. 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: 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.20060509133112.01e6c660@mail.telecommunity.com> At 09:56 AM 5/9/2006 -0700, Mike Krell wrote: >On 5/9/06, Phillip J. Eby wrote: >>At 06:19 AM, 9 May 2006 +0000, Talin 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 | 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: Phillip J. Eby 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: Phillip J. Eby 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: On 5/9/06, Ivan Krstic 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 wrote: >> On 5/7/06, Guido van Rossum wrote: >> > On 5/7/06, Collin Winter 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: References: <4460D516.6090305@fas.harvard.edu> 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 | 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 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 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: 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 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 wrote: > >> On 5/7/06, Guido van Rossum wrote: > >> > On 5/7/06, Collin Winter 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: References: <44596963.8070200@canterbury.ac.nz> Message-ID: Terry Reedy wrote: > "Greg Ewing" 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: On 5/9/06, Ivan Krstic 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: Michael Chermside 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: Oleg Broytmann 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." 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: 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: Message-ID: <0a4801c673c1$bbb7dff0$53b02997@bagio> Jim Jewett 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: <0a4801c673c1$bbb7dff0$53b02997@bagio> Message-ID: On 5/9/06, Giovanni Bajo wrote: > Jim Jewett 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: References: <0a4801c673c1$bbb7dff0$53b02997@bagio> 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: <0a4801c673c1$bbb7dff0$53b02997@bagio> Message-ID: Giovanni Bajo 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: <0a4801c673c1$bbb7dff0$53b02997@bagio> Message-ID: <0aa201c673d0$4bf188b0$53b02997@bagio> Jim Jewett 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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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: References: <44596963.8070200@canterbury.ac.nz> 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: <0a4801c673c1$bbb7dff0$53b02997@bagio> Message-ID: <0ab601c673d2$4a25de80$53b02997@bagio> Talin 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: <0a4801c673c1$bbb7dff0$53b02997@bagio><0aa201c673d0$4bf188b0$53b02997@bagio> <1147224657.5646.18.camel@fsol> Message-ID: <0b4a01c673d5$4401e140$53b02997@bagio> Antoine Pitrou 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: 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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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 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: <0a4801c673c1$bbb7dff0$53b02997@bagio><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: 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. > _______________________________________________ > 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: <0a4801c673c1$bbb7dff0$53b02997@bagio><1147222942.5646.11.camel@fsol> <44617DE5.5070104@canterbury.ac.nz> Message-ID: <0d0001c6741b$e7b6e560$53b02997@bagio> Greg Ewing 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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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 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: References: <1d85506f0605091331u770ff33dj66ce3da18b4cd496@mail.gmail.com> <20060509205748.GA19619@phd.pp.ru> 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: References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com> Message-ID: <200605102334.31944.birchb@tpg.com.au> On Wed, 10 May 2006 08:46 am, Talin wrote: > Michael Chermside 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> <200605102334.31944.birchb@tpg.com.au> Message-ID: <79990c6b0605100738m4d8fc456g43e5644419b4c5cf@mail.gmail.com> On 5/10/06, Bill Birch 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: (talin@acm.org's message of "Tue, 9 May 2006 06:19:59 +0000 (UTC)") References: <445E9A1A.8010905@canterbury.ac.nz> <445EEC1F.8060303@acm.org> Message-ID: <87bqu6c4dg.fsf@qrnik.zagroda> Talin 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: Message-ID: <5.1.1.6.0.20060510115856.036c13f0@mail.telecommunity.com> At 04:59 PM 5/10/2006 +0200, Marcin 'Qrczak' Kowalczyk 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: 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: 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: On 5/10/06, Bill Janssen 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" 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: 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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <0aa201c673d0$4bf188b0$53b02997@bagio> Message-ID: On 5/9/06, Giovanni Bajo 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: <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> <1147147707.12713.123.camel@resist.wooz.org> <44603687.6020905@canterbury.ac.nz> Message-ID: On 5/8/06, Greg Ewing 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" 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: <44596963.8070200@canterbury.ac.nz> <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: 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: On 5/10/06, Phillip J. Eby 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: <44596963.8070200@canterbury.ac.nz> <4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org> Message-ID: 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: <0ab601c673d2$4a25de80$53b02997@bagio> Message-ID: <20060510150405.6800.JCARLSON@uci.edu> "Giovanni Bajo" 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: <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." 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: <5553726489438271847@unknownmsgid> Message-ID: On 5/10/06, Bill Janssen 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: <79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com> Message-ID: Paul Moore gmail.com> writes: > On 5/7/06, Greg Wilson cs.utoronto.ca> wrote: > > > From: Greg Ewing 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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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: <0a4801c673c1$bbb7dff0$53b02997@bagio> <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: References: <9e804ac0605080655l1ec2b2f5sbcf572a4852e5fca@mail.gmail.com> <1147099922.10381.20.camel@resist.wooz.org> <1147147707.12713.123.camel@resist.wooz.org> <44603687.6020905@canterbury.ac.nz> 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: References: <79990c6b0605071230t717c98a8wbb2270624733ae9@mail.gmail.com> 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: <44596963.8070200@canterbury.ac.nz> <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: <44629EF1.4000307@gradient.cis.upenn.edu> Message-ID: <20060510205645.6803.JCARLSON@uci.edu> Edward Loper 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: <44596963.8070200@canterbury.ac.nz> <4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org> Message-ID: "Travis E. Oliphant" 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: References: 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: On 5/10/06, tomer filiba 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: References: Message-ID: 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 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: References: Message-ID: <4462C6F8.6030203@comcast.net> Talin 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: References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com> Message-ID: [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> Message-ID: "Guido van Rossum" 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: <44596963.8070200@canterbury.ac.nz> <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: On 5/10/06, Collin Winter 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 "". ) > 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: <4462C6F8.6030203@comcast.net> Message-ID: On 5/10/06, Edward C. Jones wrote: > Talin 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: References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com> Message-ID: On 5/10/06, Guido van Rossum 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: References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.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: References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@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" 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: 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 | 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" 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: References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.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> <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: (Neal Norwitz's message of "Wed, 10 May 2006 23:22:13 -0700") References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com> Message-ID: <878xp8k4ji.fsf@qrnik.zagroda> "Neal Norwitz" 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> <4462D9F7.6040605@acm.org> Message-ID: <874pzwk454.fsf@qrnik.zagroda> Talin 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: 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: "Phillip J. Eby" 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 wrote: > On Thu, 11 May 2006 12:38 am, you wrote: > > On 5/10/06, Bill Birch 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: <44596963.8070200@canterbury.ac.nz> <4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org> <4462B2FD.3070406@canterbury.ac.nz> Message-ID: 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> <878xp8k4ji.fsf@qrnik.zagroda> Message-ID: <44636110.4010503@gradient.cis.upenn.edu> Marcin 'Qrczak' Kowalczyk wrote: > "Neal Norwitz" 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." 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: 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: References: <44596963.8070200@canterbury.ac.nz> <4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org> <4462B2FD.3070406@canterbury.ac.nz> 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" 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__ # print type(p) # 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> <4462D9F7.6040605@acm.org> Message-ID: On 5/11/06, Talin 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> <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 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: References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com> <4462D9F7.6040605@acm.org> 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 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: [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> <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: On 5/11/06, tomer filiba 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> <4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda> <446375E5.2090500@acm.org> Message-ID: On 5/11/06, Talin 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: References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com> <4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda> <446375E5.2090500@acm.org> Message-ID: <44638200.40106@acm.org> Guido van Rossum wrote: > On 5/11/06, Talin 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> <4462DAA5.9040104@acm.org> <4463332E.8000107@gmail.com> <44637CCC.7000709@acm.org> Message-ID: On 5/11/06, Talin 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: References: 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. 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: References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com> <4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda> <446375E5.2090500@acm.org> Message-ID: On 5/11/06, Mike Krell wrote: > On 5/11/06, Guido van Rossum 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: References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com> <4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda> <446375E5.2090500@acm.org> Message-ID: On 5/11/06, Guido van Rossum 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: On 5/11/06, Fredrik Johansson 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> <4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda> <446375E5.2090500@acm.org> Message-ID: Guido van Rossum 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: References: <43aa6ff70605102217r76720ec0l5158837dcba612e4@mail.gmail.com> Message-ID: <43aa6ff70605111547j4096995ai1544ea1f80aed5c8@mail.gmail.com> On 5/11/06, Guido van Rossum 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: (talin@acm.org's message of "Thu, 11 May 2006 21:17:05 +0000 (UTC)") References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com> <4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda> <446375E5.2090500@acm.org> Message-ID: <87psik3ycu.fsf@qrnik.zagroda> Talin 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: On 5/11/06, Phillip J. Eby 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> <4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda> <446375E5.2090500@acm.org> <87psik3ycu.fsf@qrnik.zagroda> Message-ID: <446419B2.9090908@acm.org> Marcin 'Qrczak' Kowalczyk wrote: > Talin 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: References: <20060509140318.g2bhc7k950o48cg0@login.werra.lunarpages.com> <4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda> <446375E5.2090500@acm.org> Message-ID: <44641BF2.6090301@acm.org> Mike Krell wrote: > On 5/11/06, Guido van Rossum 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> <4462D9F7.6040605@acm.org> <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: "Phillip J. Eby" 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: References: 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 wrote: > On 5/11/06, tomer filiba 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> <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> <4462D9F7.6040605@acm.org> <874pzwk454.fsf@qrnik.zagroda> <446375E5.2090500@acm.org> <87psik3ycu.fsf@qrnik.zagroda> <446419B2.9090908@acm.org> Message-ID: <87slnfserf.fsf@qrnik.zagroda> Talin 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> <4462D9F7.6040605@acm.org> <446377D6.70807@acm.org> <4464411B.9080001@gmail.com> Message-ID: <87ody3semm.fsf@qrnik.zagroda> Nick Coghlan 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: 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 "" % (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 wrote: > IMO, the free mixing decimal and binary floats is not a good idea. On 5/12/06, Greg Ewing 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 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: Message-ID: <5.1.1.6.0.20060512120303.01e5c3f8@mail.telecommunity.com> At 10:14 PM 5/11/2006 -0700, Talin wrote: >Marcin 'Qrczak' Kowalczyk wrote: > > Talin 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 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: 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 wrote: >Talin 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: References: <44596963.8070200@canterbury.ac.nz> <4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org> <4462B2FD.3070406@canterbury.ac.nz> 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: <44596963.8070200@canterbury.ac.nz> <4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org> <4462B2FD.3070406@canterbury.ac.nz> <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: <44596963.8070200@canterbury.ac.nz> <4461428C.60803@canterbury.ac.nz> <446256F9.50507@ieee.org> <4462B2FD.3070406@canterbury.ac.nz> <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: <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" 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: <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 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: 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 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 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 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 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: 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 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 ). 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 "", 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: 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 "", line 1, in ? *TypeError*: f() takes exactly 1 argument (2 given) >>> type(f) # 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: On 5/17/06, tomer filiba 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 "", line 1, in ? > *TypeError*: f() takes exactly 1 argument (2 given) > >>> type(f) > # 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: "Michael Chermside" 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: [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 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 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. 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: References: <4463CF45.3030309@canterbury.ac.nz> Message-ID: <20060517153529.6852.JCARLSON@uci.edu> "Robin Bryce" 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 "", 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: References: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com> 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: <446C1B66.3060205@gmx.net> Message-ID: <20060518003138.685B.JCARLSON@uci.edu> Kay Schluehr 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: <4450BE0E.8090903@gmail.com> <4450C311.8040603@fas.harvard.edu> <4450CB36.7090504@gmail.com> <44511237.5000609@ewtllc.com> <17489.31069.526965.186604@montanaro.dyndns.org> <4451AF74.8040702@gmx.net> <445279F7.8080306@v.loewis.de> Message-ID: 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" 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 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 wrote: > On 5/18/06, Collin Winter 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 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) >>> """ 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: References: <1d85506f0605171029m678ebab7q99903a1486890611@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 wrote: > > > > On 5/17/06, tomer filiba 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 "", line 1, in ? > *TypeError*: f() takes exactly 1 argument (2 given) > >>> type(f) > # 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> <1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com> Message-ID: On 5/18/06, tomer filiba 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 wrote: > > > > > > > > On 5/17/06, tomer filiba 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 "", line 1, in ? > > *TypeError*: f() takes exactly 1 argument (2 given) > > >>> type(f) > > # 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: <1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com> Message-ID: <20060518125745.686C.JCARLSON@uci.edu> "tomer filiba" wrote: > On 5/17/06, Brett Cannon 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: References: <4450BE0E.8090903@gmail.com> <4450C311.8040603@fas.harvard.edu> <4450CB36.7090504@gmail.com> <44511237.5000609@ewtllc.com> <17489.31069.526965.186604@montanaro.dyndns.org> <4451AF74.8040702@gmx.net> <445279F7.8080306@v.loewis.de> Message-ID: 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: (Thomas Heller's message of "Thu, 18 May 2006 22:13:01 +0200") References: <4450BE0E.8090903@gmail.com> <4450C311.8040603@fas.harvard.edu> <4450CB36.7090504@gmail.com> <44511237.5000609@ewtllc.com> <17489.31069.526965.186604@montanaro.dyndns.org> <4451AF74.8040702@gmx.net> <445279F7.8080306@v.loewis.de> Message-ID: <87y7wzm3yb.fsf@qrnik.zagroda> Thomas Heller 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: On 5/18/06, Collin Winter 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: References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com> Message-ID: <43aa6ff70605181859h1c2e387eg373a98b7ca80cfd3@mail.gmail.com> On 5/18/06, Guido van Rossum wrote: > On 5/18/06, Collin Winter 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 wrote: > On 5/18/06, Collin Winter 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: On 5/18/06, Collin Winter 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. 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 "", 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[] 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: References: <4450CB36.7090504@gmail.com> <44511237.5000609@ewtllc.com> <17489.31069.526965.186604@montanaro.dyndns.org> <4451AF74.8040702@gmx.net> <445279F7.8080306@v.loewis.de> Message-ID: On 5/11/06, Boris Borcic 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: <1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com> <20060518125745.686C.JCARLSON@uci.edu> Message-ID: On 5/18/06, Josiah Carlson wrote: > > "tomer filiba" wrote: > > On 5/17/06, Brett Cannon 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: 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 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> Message-ID: <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> On 5/19/06, Guido van Rossum wrote: > On 5/18/06, Collin Winter 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: References: <20060517053503.oq4mtmzuzmv4s4sw@login.werra.lunarpages.com> Message-ID: On 5/17/06, Terry Reedy wrote: > > "Michael Chermside" 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> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> Message-ID: On 5/18/06, Collin Winter wrote: > On 5/19/06, Guido van Rossum wrote: > > On 5/18/06, Collin Winter 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[] 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: On 5/18/06, Kay Schluehr 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(, , ..., returns=) 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: On 5/13/06, Greg Ewing 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: References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com> <446D515B.8040802@gmx.net> 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> <446D5F89.2080504@gmx.net> Message-ID: On 5/18/06, Kay Schluehr 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: References: <1d85506f0605181228m166fe470xce42fa918f814aec@mail.gmail.com> <20060518125745.686C.JCARLSON@uci.edu> 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 wrote: > > On 5/18/06, Josiah Carlson wrote: > > > > "tomer filiba" wrote: > > > On 5/17/06, Brett Cannon 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: (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> Message-ID: <873bf6guah.fsf@qrnik.zagroda> "Guido van Rossum" 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 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: Message-ID: <5.1.1.6.0.20060519101521.01f54218@mail.telecommunity.com> At 10:17 PM 5/18/2006 -0700, "Guido van Rossum" 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: 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 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 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> Message-ID: <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> On 5/19/06, Guido van Rossum 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 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 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: References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com> <446D515B.8040802@gmx.net> Message-ID: <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> On 5/19/06, Guido van Rossum wrote: > On 5/18/06, Kay Schluehr 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(, , ..., returns=) for this. Based on a suggestion from Nick Coghlan [1], I'm now favoring something like this: Function(, , required_keyword=, ...).returns() 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> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> Message-ID: On 5/19/06, Collin Winter wrote: > On 5/19/06, Guido van Rossum 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: On 5/19/06, 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. WhatI'm trying to do primarily is add just enough new syntax that people can write their own such system. This is the optional ": " after parameter names and "-> " 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> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> Message-ID: On 5/19/06, Collin Winter wrote: > On 5/19/06, Guido van Rossum wrote: > > On 5/18/06, Kay Schluehr 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(, , ..., returns=) for this. > > Based on a suggestion from Nick Coghlan [1], I'm now favoring > something like this: > > Function(, , required_keyword=, ...).returns() 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> Message-ID: <43aa6ff70605191056y451e6b60h1814a1e17516f3a3@mail.gmail.com> On 5/19/06, Guido van Rossum 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 .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> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> Message-ID: <87odxtg9nx.fsf@qrnik.zagroda> "Collin Winter" 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: References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com> <446D515B.8040802@gmx.net> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> Message-ID: <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> On 5/19/06, Guido van Rossum 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> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> <87odxtg9nx.fsf@qrnik.zagroda> Message-ID: <43aa6ff70605191145s677f8affka96a792115cd8e9d@mail.gmail.com> On 5/19/06, Marcin 'Qrczak' Kowalczyk wrote: > "Collin Winter" 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: References: <200605191814.33021.paul@boddie.org.uk> Message-ID: On 5/19/06, Guido van Rossum 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: References: <200605191814.33021.paul@boddie.org.uk> Message-ID: <43aa6ff70605191217q1b228a35gb28a52c3d576dfc3@mail.gmail.com> On 5/19/06, Jim Jewett wrote: > On 5/19/06, Guido van Rossum 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> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> <87odxtg9nx.fsf@qrnik.zagroda> <43aa6ff70605191145s677f8affka96a792115cd8e9d@mail.gmail.com> Message-ID: <87k68hg6v8.fsf@qrnik.zagroda> "Collin Winter" 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: References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com> <446D515B.8040802@gmx.net> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> Message-ID: On 5/19/06, Guido van Rossum 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> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> Message-ID: On 5/19/06, Collin Winter 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> Message-ID: <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com> On 5/19/06, Jim Jewett wrote: > On 5/19/06, Collin Winter 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> <43aa6ff70605191217q1b228a35gb28a52c3d576dfc3@mail.gmail.com> Message-ID: On 5/19/06, Collin Winter wrote: > On 5/19/06, Jim Jewett 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> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> Message-ID: On 5/19/06, Collin Winter 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> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com> Message-ID: On 5/19/06, Collin Winter wrote: > On 5/19/06, Jim Jewett wrote: > > On 5/19/06, Collin Winter 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: References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com> <446D515B.8040802@gmx.net> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> Message-ID: On 5/19/06, Jim Jewett 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: References: <200605191814.33021.paul@boddie.org.uk> <43aa6ff70605191217q1b228a35gb28a52c3d576dfc3@mail.gmail.com> Message-ID: <43aa6ff70605191350h36dacda7n6cfc585c344209cc@mail.gmail.com> On 5/19/06, Jim Jewett wrote: > On 5/19/06, Collin Winter wrote: > > On 5/19/06, Jim Jewett 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 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: On 5/19/06, Tony Lownds 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com> Message-ID: <43aa6ff70605191408n274b7b37u6cc9ddea67106d16@mail.gmail.com> On 5/19/06, Jim Jewett wrote: > On 5/19/06, Collin Winter 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> Message-ID: <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> On 5/19/06, Guido van Rossum wrote: > On 5/18/06, Collin Winter 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: References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com> <446D515B.8040802@gmx.net> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> Message-ID: <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> On 5/19/06, Guido van Rossum 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(, , ..., returns=) 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> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com> <43aa6ff70605191408n274b7b37u6cc9ddea67106d16@mail.gmail.com> Message-ID: On 5/19/06, Collin Winter 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 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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> Message-ID: On 5/19/06, Collin Winter wrote: > On 5/19/06, Guido van Rossum wrote: > > On 5/18/06, Collin Winter 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: References: <200605191814.33021.paul@boddie.org.uk> <81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net> Message-ID: 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: References: <200605191814.33021.paul@boddie.org.uk> <81E91D1E-0FEB-4D17-B095-0D60FA4B0901@printra.net> Message-ID: On 5/19/06, Tony Lownds 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: (Jim Jewett's message of "Fri, 19 May 2006 16:46:31 -0400") References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com> Message-ID: <87psi9zms6.fsf@qrnik.zagroda> "Jim Jewett" 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__ >>> 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> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com> <87psi9zms6.fsf@qrnik.zagroda> Message-ID: On 5/19/06, Marcin 'Qrczak' Kowalczyk wrote: > "Jim Jewett" 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__ > > >>> 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> Message-ID: <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> On 5/19/06, Guido van Rossum wrote: > On 5/19/06, Collin Winter 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> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> Message-ID: <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com> On 5/19/06, Collin Winter wrote: > Let's go back to Function(, , ..., returns=) 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(, , ).returns(, ) ...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> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com> Message-ID: On 5/19/06, Collin Winter wrote: > On 5/19/06, Collin Winter wrote: > > Let's go back to Function(, , ..., returns=) > > 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(, , ).returns(, ) > > ...with which I am pleased muchly. OK; for the return value (only) the Function().returns() 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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> Message-ID: <446E99B8.10500@acm.org> Collin Winter wrote: > On 5/19/06, Guido van Rossum wrote: > >>On 5/19/06, Collin Winter 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: On 5/19/06, Collin Winter 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: References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com> <446D515B.8040802@gmx.net> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com> Message-ID: <43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com> On 5/19/06, Guido van Rossum wrote: > OK; for the return value (only) the Function().returns() > 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: (Steven Bethard's message of "Fri, 19 May 2006 22:42:49 -0600") References: Message-ID: <87psi9jmk5.fsf@qrnik.zagroda> "Steven Bethard" 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: References: 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 "" % (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 >>> l = intlist([1,2,3]) >>> l.append(4) >>> l.append("a string") Traceback (most recent call last): File "", line 1, in ? File "", 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: <446EAB6E.4020606@acm.org> Message-ID: <79990c6b0605200625u41e2bafcy6b09404f15bf8d4a@mail.gmail.com> On 5/20/06, Talin 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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> Message-ID: On 5/19/06, Talin 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: <87psi9jmk5.fsf@qrnik.zagroda> Message-ID: On 5/19/06, Marcin 'Qrczak' Kowalczyk wrote: > "Steven Bethard" 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: On 5/20/06, tomer filiba 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: References: Message-ID: > On 5/19/06, Collin Winter 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: , *varargs: , **varkw: ) is fully equivalent to -- and is indeed coerced to -- >>> def foo(a: , *varargs: list[], **varkw: dict[str, ]) 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: On 5/20/06, Collin Winter 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: , *varargs: , **varkw: ) > > is fully equivalent to -- and is indeed coerced to -- > > >>> def foo(a: , *varargs: list[], **varkw: dict[str, ]) > > 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: References: <1d85506f0605200131y4ef00ebdh3f46286691ae40f1@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 wrote: > On 5/20/06, tomer filiba 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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@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: References: Message-ID: On 5/20/06, Guido van Rossum 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: References: Message-ID: On 5/20/06, Steven Bethard wrote: > On 5/20/06, Guido van Rossum 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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <287D2E67-D342-4BFA-8D8F-DB3A6BD04865@printra.net> Message-ID: On 5/20/06, Tony Lownds 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: Message-ID: <87ejyoo3ul.fsf@qrnik.zagroda> "Steven Bethard" 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: References: Message-ID: On 5/20/06, Guido van Rossum wrote: > On 5/20/06, Steven Bethard 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: References: Message-ID: <43aa6ff70605201407o2a003a54s8d888422d23d3e3f@mail.gmail.com> On 5/20/06, Steven Bethard wrote: > On 5/20/06, Guido van Rossum 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> Message-ID: <446F8C3E.5000009@acm.org> Guido van Rossum wrote: > On 5/19/06, Talin 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: References: Message-ID: On 5/20/06, Steven Bethard wrote: > On 5/20/06, Guido van Rossum 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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.org> Message-ID: On 5/20/06, Talin 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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.org> Message-ID: <87wtcguubg.fsf@qrnik.zagroda> Talin 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: <43aa6ff70605201407o2a003a54s8d888422d23d3e3f@mail.gmail.com> Message-ID: On 5/20/06, Collin Winter wrote: > On 5/20/06, Steven Bethard 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: References: Message-ID: On 5/20/06, Guido van Rossum wrote: > On 5/20/06, Steven Bethard 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.org> Message-ID: <446FAFF1.3070503@acm.org> Guido van Rossum wrote: > On 5/20/06, Talin 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: Message-ID: <5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com> At 12:36 AM 5/20/2006 -0600, "Steven Bethard" wrote: >On 5/20/06, Guido van Rossum 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com> <43aa6ff70605191408n274b7b37u6cc9ddea67106d16@mail.gmail.com> Message-ID: <446FBD3E.1020006@gmail.com> Jim Jewett wrote: > On 5/19/06, Collin Winter 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605182146r660bcbdav48378da86098e759@mail.gmail.com> <43aa6ff70605190837p276a315ah86f71f6a1fbadb3e@mail.gmail.com> <43aa6ff70605191304i7e7bc1b5gb2891e25d18fef7b@mail.gmail.com> <87psi9zms6.fsf@qrnik.zagroda> 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: References: <43aa6ff70605200919i296a1ac5ib7cd687489e94c1d@mail.gmail.com> Message-ID: <446FC209.8070009@gmail.com> Guido van Rossum wrote: > On 5/20/06, Collin Winter wrote: >> 3. What will annotations on *varargs and **varkw look like? My own >> suggestion is that >> >>>>> def foo(a: , *varargs: , **varkw: ) >> is fully equivalent to -- and is indeed coerced to -- >> >>>>> def foo(a: , *varargs: list[], **varkw: dict[str, ]) >> 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> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com> <43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com> Message-ID: <446FC97E.4030105@gmail.com> Collin Winter wrote: > On 5/19/06, Guido van Rossum wrote: >> OK; for the return value (only) the Function().returns() >> 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.org> Message-ID: Guido van Rossum wrote: > On 5/20/06, Talin 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.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> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@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: References: <43aa6ff70605180831o612a2e3et94eb9d4f18440ea8@mail.gmail.com> <446D515B.8040802@gmx.net> <446D5F89.2080504@gmx.net> 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> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.org> Message-ID: <44701C03.9040407@gmail.com> Travis E. Oliphant wrote: > Guido van Rossum wrote: >> On 5/20/06, Talin 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. 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> <43aa6ff70605190851u7b3d2355gc90881168c5c6b51@mail.gmail.com> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com> <43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com> <446FC97E.4030105@gmail.com> Message-ID: <87odxrpwlq.fsf@qrnik.zagroda> Nick Coghlan 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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.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: <5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com> Message-ID: <79990c6b0605210644h585a6294r43fcca10697e07b5@mail.gmail.com> On 5/21/06, Phillip J. Eby 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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.org> <446FAFF1.3070503@acm.org> Message-ID: <9e804ac0605210720n60f896d1seece6bbeca6245bf@mail.gmail.com> On 5/21/06, Talin 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 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> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.org> <44701C03.9040407@gmail.com> Message-ID: On 5/21/06, Nick Coghlan 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> <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: References: <5.1.1.6.0.20060520200945.01f236b8@mail.telecommunity.com> <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> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@mail.gmail.com> <43aa6ff70605192210p200fadd5mf57e750174a7f4f4@mail.gmail.com> <446FC97E.4030105@gmail.com> Message-ID: <43aa6ff70605211123v4a5b55aer19f305a780947e42@mail.gmail.com> On 5/20/06, 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] > > 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 wrote: > Nick Coghlan 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> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@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" 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> <43aa6ff70605191138r592ef776ncf684d92cf20c806@mail.gmail.com> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@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> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@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 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> <43aa6ff70605191414i218c0f81u2ba546decf1ba894@mail.gmail.com> <43aa6ff70605191839r6c84ca14t53a1df273c6d4a83@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: On 5/21/06, Collin Winter wrote: > On 5/21/06, Aahz 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 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: On 5/22/06, Talin 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: References: <44716940.9000300@acm.org> 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: On 5/22/06, Collin Winter 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> <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> <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> <1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol> Message-ID: On 5/22/06, Antoine Pitrou 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: References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com> Message-ID: <20060522121249.68B4.JCARLSON@uci.edu> "Guido van Rossum" wrote: > > On 5/22/06, Collin Winter 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) or >>> list.__class__(1) 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: 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 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) > > > or > >>> list.__class__(1) > > > 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> <20060522121249.68B4.JCARLSON@uci.edu> Message-ID: <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com> On 5/22/06, Josiah Carlson wrote: > "Guido van Rossum" wrote: > > On 5/22/06, Collin Winter 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> <20060522121249.68B4.JCARLSON@uci.edu> <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com> Message-ID: On 5/22/06, Collin Winter wrote: > On 5/22/06, Josiah Carlson wrote: > > "Guido van Rossum" wrote: > > > On 5/22/06, Collin Winter 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> <20060522121249.68B4.JCARLSON@uci.edu> <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com> Message-ID: 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> <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: References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com> <20060522121249.68B4.JCARLSON@uci.edu> <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com> Message-ID: <43aa6ff70605221802w57c27942g465ee26aa633f767@mail.gmail.com> On 5/22/06, Guido van Rossum wrote: > On 5/22/06, 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. > > 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: On 5/22/06, Greg Ewing 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> <20060522121249.68B4.JCARLSON@uci.edu> <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com> <43aa6ff70605221802w57c27942g465ee26aa633f767@mail.gmail.com> Message-ID: On 5/22/06, Collin Winter wrote: > On 5/22/06, Guido van Rossum wrote: > > On 5/22/06, 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. > > > > 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: References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com> <1d85506f0605221229s64a3942fp867157c800b682f3@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: References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@mail.gmail.com> <20060522121249.68B4.JCARLSON@uci.edu> <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com> <43aa6ff70605221802w57c27942g465ee26aa633f767@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: References: <44716940.9000300@acm.org> <1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol> Message-ID: <4472B196.7070506@acm.org> Guido van Rossum wrote: > On 5/22/06, Antoine Pitrou 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> <1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol> <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> <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: References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com> <1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com> <4472585A.8010109@canterbury.ac.nz> Message-ID: <4472D656.20707@gmail.com> Guido van Rossum wrote: > On 5/22/06, Greg Ewing 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: References: <43aa6ff70605181924k5556dab9sb14a38f1bafbd16b@mail.gmail.com> <287D2E67-D342-4BFA-8D8F-DB3A6BD04865@printra.net> 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 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: 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> <20060522121249.68B4.JCARLSON@uci.edu> <43aa6ff70605221624m44963f21k3b335b279f3148fa@mail.gmail.com> <43aa6ff70605221802w57c27942g465ee26aa633f767@mail.gmail.com> <4472A519.9040308@acm.org> Message-ID: On 5/22/06, Talin 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> <1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol> <4472B196.7070506@acm.org> Message-ID: 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 wrote: > Guido van Rossum wrote: > > On 5/22/06, Antoine Pitrou 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> <200605231034.14546.gmccaughan@synaptics-uk.com> Message-ID: On 5/23/06, Gareth McCaughan wrote: > On Saturday 2006-05-20 20:53, Guido van Rossum wrote: > > > On 5/20/06, Tony Lownds 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> <4472D656.20707@gmail.com> Message-ID: Let's please leave 2.x alone. On 5/23/06, Nick Coghlan wrote: > Guido van Rossum wrote: > > On 5/22/06, Greg Ewing 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> <4472A44D.8000106@acm.org> Message-ID: On 5/22/06, Talin 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: References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com> <1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com> <4472A44D.8000106@acm.org> 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> <4472A44D.8000106@acm.org> <20060523165837.GA27084@latte.ca> Message-ID: On 5/23/06, Blake Winton 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: References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com> <1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com> <4472A44D.8000106@acm.org> <20060523165837.GA27084@latte.ca> Message-ID: On 5/23/06, Guido van Rossum 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: References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com> <1d85506f0605221229s64a3942fp867157c800b682f3@mail.gmail.com> <4472A44D.8000106@acm.org> 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: References: <1148238801.796827.56560@j33g2000cwa.googlegroups.com> <1d85506f0605221229s64a3942fp867157c800b682f3@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) >>> type(list) >>> type(metaclass) >>> type(type) 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 , 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) ? -tomer On 5/22/06, 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 > 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> <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: On 5/23/06, Talin 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: On 5/23/06, Talin 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. 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: > > 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> <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> <43aa6ff70605191409u90e4cfan1a8eb1472c978ca3@mail.gmail.com> <43aa6ff70605191829m18084e57r18730188e5d0abf3@mail.gmail.com> <446E99B8.10500@acm.org> <446F8C3E.5000009@acm.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> <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: On 5/25/06, Nick Coghlan 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: On 5/25/06, Nick Coghlan 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: Message-ID: <5.1.1.6.0.20060525125040.0485aa18@mail.telecommunity.com> At 11:42 AM 5/25/2006 +0200, Baptiste Carvello 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: References: <43aa6ff70605220856x6dcb9f2dr326bd34c9f237678@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: <44764AD7.1020006@canterbury.ac.nz> > On 5/25/06, Nick Coghlan 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 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 "", 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 (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: It should be discarded. You can already create instances bypassing __init__ by calling __new__. On 5/26/06, Collin Winter 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 '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: On 5/26/06, Michael Chermside wrote: > On 5/18/06, Kay Schluehr 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: References: <43aa6ff70605260951x19d769a7v48ec96e692cba60b@mail.gmail.com> Message-ID: <43aa6ff70605261158h13f8fde9w1bb02c5f438bd1c3@mail.gmail.com> On 5/26/06, Guido van Rossum 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: 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 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: References: <20060527133616.GB20800@phd.pp.ru> Message-ID: On 5/27/06, Just van Rossum 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: 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 wrote: > On 5/21/06, Guido van Rossum 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: References: <44716940.9000300@acm.org> <1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol> <4472B196.7070506@acm.org> 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: <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: [Adding the py3k list; please remove python-dev in followups.] On 5/29/06, "Martin v. L?wis" 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: References: <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: <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: Message-ID: Guido van Rossum wrote: > On 5/27/06, Just van Rossum 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: <447B66B7.90107@v.loewis.de> <9e804ac0605291433x54dd64e7o10acfc3076f5ffb0@mail.gmail.com> <447B6B1A.2020107@v.loewis.de> <9e804ac0605291457s784e6089ge84e6315feb2c3cd@mail.gmail.com> <447B7189.30408@v.loewis.de> <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> <1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> Message-ID: On 5/29/06, Talin 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: References: <44716940.9000300@acm.org> <1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> Message-ID: On 5/30/06, Brett Cannon 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: References: Message-ID: <20060530104546.695F.JCARLSON@uci.edu> "Steven Bethard" wrote: > > On 5/30/06, Brett Cannon 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 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: <447B66B7.90107@v.loewis.de> <9e804ac0605291433x54dd64e7o10acfc3076f5ffb0@mail.gmail.com> <447B6B1A.2020107@v.loewis.de> <9e804ac0605291457s784e6089ge84e6315feb2c3cd@mail.gmail.com> <447B7189.30408@v.loewis.de> <447BD772.3090303@v.loewis.de> Message-ID: [Removing python-dev from the CC list] On 5/29/06, "Martin v. L?wis" 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: <20060530104546.695F.JCARLSON@uci.edu> Message-ID: On 5/30/06, Josiah Carlson wrote: > "Steven Bethard" 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: <20060530104546.695F.JCARLSON@uci.edu> Message-ID: "Jim Jewett" wrote in message news:fb6fbf560605301411h6f0ddab7k2b4bfec58b9fb55f at mail.gmail.com... >> "Steven Bethard" 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: References: <20060530104546.695F.JCARLSON@uci.edu> Message-ID: [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: Josiah Carlson uci.edu> writes: > > > Talin 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: References: <20060530102903.6959.JCARLSON@uci.edu> Message-ID: <20060530174643.696E.JCARLSON@uci.edu> Alexander Belopolsky wrote: > > Josiah Carlson uci.edu> writes: > > > > > > > Talin 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 ' 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> <20060530174643.696E.JCARLSON@uci.edu> Message-ID: 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 . 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 "", 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: References: <20060530174643.696E.JCARLSON@uci.edu> Message-ID: <20060530210257.6971.JCARLSON@uci.edu> Alexander Belopolsky 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 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> <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: <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" wrote: >> >> On 5/30/06, Brett Cannon 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: <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. 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 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> <20060530210257.6971.JCARLSON@uci.edu> Message-ID: On 5/31/06, Josiah Carlson 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 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: On May 31, 2006, at 9:52 AM, Josiah Carlson wrote: > > Talin 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: <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: <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> <20060530210257.6971.JCARLSON@uci.edu> <447D1D01.3060000@acm.org> Message-ID: <873beqz7hi.fsf@qrnik.zagroda> Talin 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: References: <44716940.9000300@acm.org> <1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> 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: <20060530104546.695F.JCARLSON@uci.edu> <7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com> <200605310157.04260.fdrake@acm.org> Message-ID: 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: References: <20060530104546.695F.JCARLSON@uci.edu> <7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com> <200605310157.04260.fdrake@acm.org> Message-ID: 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> <20060530174643.696E.JCARLSON@uci.edu> Message-ID: On 5/30/06, Josiah Carlson wrote: > I'm still not convinced that > 'lazy ' 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 ' 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: References: <20060530210257.6971.JCARLSON@uci.edu> Message-ID: <20060531090045.6980.JCARLSON@uci.edu> "Alexander Belopolsky" wrote: > > On 5/31/06, Josiah Carlson 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> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> <1149080922.5718.20.camel@fsol> Message-ID: On 5/31/06, Antoine Pitrou 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> <20060530210257.6971.JCARLSON@uci.edu> <447D1D01.3060000@acm.org> <873beqz7hi.fsf@qrnik.zagroda> Message-ID: Marcin 'Qrczak' Kowalczyk knm.org.pl> writes: > > Talin 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. """ 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: References: <44716940.9000300@acm.org> <1148315368.19392.4.camel@fsol> <20060522164618.GA14460@panix.com> <1148318480.19392.6.camel@fsol> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> <1149080922.5718.20.camel@fsol> 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 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 >>> y.next.next >>> del y deleted 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> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> <1149080922.5718.20.camel@fsol> <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> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> <1149080922.5718.20.camel@fsol> <1149095977.5718.51.camel@fsol> Message-ID: On 5/31/06, 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. 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: Talin 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 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: References: <44716940.9000300@acm.org> <1148318480.19392.6.camel@fsol> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> <1149080922.5718.20.camel@fsol> <1149095977.5718.51.camel@fsol> 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> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> <1149080922.5718.20.camel@fsol> <1149095977.5718.51.camel@fsol> <430FBE78-D78A-4346-BD18-27D1D038AFE7@mac.com> Message-ID: On 5/31/06, Ronald Oussoren 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" 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> <447BC126.8050107@acm.org> <1149080922.5718.20.camel@fsol> <1149095977.5718.51.camel@fsol> <1149102266.5718.62.camel@fsol> Message-ID: On 5/31/06, Antoine Pitrou 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: References: <43aa6ff70605271348y352921f6he107ba1f40a0393a@mail.gmail.com> Message-ID: <43aa6ff70605311233i6f8195fdye2ed52fc559830ea@mail.gmail.com> On 5/30/06, Guido van Rossum 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: References: <20060530104546.695F.JCARLSON@uci.edu> <7033D42E-3EF0-4A69-B9E4-D2882CB7BC95@mac.com> <200605310157.04260.fdrake@acm.org> Message-ID: On 5/31/06, Tim Hochberg 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> <4472B196.7070506@acm.org> <447BC126.8050107@acm.org> <1149080922.5718.20.camel@fsol> <1149095977.5718.51.camel@fsol> Message-ID: On 5/31/06, 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. (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