Re: [Python-3000] Use Py_CLEAR only

Greg Ewing wrote: > Edward C. Jones wrote: > >> Can Py_CLEAR completely replace Py_DECREF and Py_XDECREF? > > It would be less efficient in the cases where you don't > need to check for NULL and/or clear the reference > afterwards. Both should be optimized away by the compiler. But what we gai

Re: [Python-3000] Futures in Python 3000 (was Re: mechanism for handling asynchronous concurrency)

Andy Sy wrote: > I don't know about you, but with the addition of send() to deal with > the problem outlined in PEP 342, generators are starting to look more > and more like a Rube Goldberg contraption. Could anything be more > Pythonic than Io's: > > f := url @fetch // f is a future that will

[Python-3000] A super() idea - no _getframe() involved

Here's how you solve the "how does super() get the current class" problem, using existing compiler and VM constructs, and without relying on class names, or on functions not being decorated, or anything like that. And it's so simple you'll slap your forehead for not thinking of it first. :) C

Re: [Python-3000] auto-super()

Aahz wrote: > But multiple inheritance with new-style classes is inherently diamond > inheritance -- how do you propose to deal with that? Yes, that's a bit of a problem. Or rather, it's not really a problem, because object doesn't provide any methods of its own, so having it at the top of every

Re: [Python-3000] A wish: build C, C++, FORTRAN library wrapping into Python.

Edward C. Jones wrote: > How much of the wrapping process can > be built into Python? What would Beasley, Abrahams, Ewing, > et al want to see done? Well, my idea of what a Pythonic Python-wrapping system should be is Pyrex, and I don't think I'd want too much of that incorporated into Python i

Re: [Python-3000] Use Py_CLEAR only

Edward C. Jones wrote: > Can Py_CLEAR completely replace Py_DECREF and Py_XDECREF? It would be less efficient in the cases where you don't need to check for NULL and/or clear the reference afterwards. -- Greg ___ Python-3000 mailing list Python-3000@py

Re: [Python-3000] Special object to return from functions that return only None

Edward C. Jones wrote: > I suggest a singleton object "UseForbidden" ("Py_UseForbidden" in C). It should be called "Mu". :-) Although such an object could cause a lot of pain to debuggers and other such introspective code. -- Greg ___ Python-3000 mai

Re: [Python-3000] Is reference counting still needed?

Edward C. Jones wrote: > Maybe some day a sufficiently portable automatic garbage collector will > be available for C. Until then, we'll have to live with reference counts. Even if it did become available, we might not want to use it. In recent times I've come round to the view that, on modern a

[Python-3000] Futures in Python 3000 (was Re: mechanism for handling asynchronous concurrency)

Josiah Carlson wrote: > Andy Sy <[EMAIL PROTECTED]> wrote: >> The Io language has what (on paper) seems to be a very >> neat, Pythonic mechanism for doing asynchronous concurrency. >> >> >> The mechanism is called futures and is described at: >> >> http://iolanguage.com/darcs/Io/_docs/guide.html#TO

Re: [Python-3000] Python 3000 and the Google Summer of Code

Guido, are you willing to send this? Would you rather me, Terry, or someone else send it? My changes are inline. They aren't extensive. On 4/18/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > between May 1, 17:00 PST through May 8, 17:00 PST. Might as well be explicit. :-) > The Python Software

Re: [Python-3000] After 2.6 should be 3.0

"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Personally, I see Py3k as a vetting mechanism for all those hair-brained > ideas that really shouldn't make it into any Python version (3k or > otherwise), with the possible inclusion of things that *should* make > lif

Re: [Python-3000] Python 3000 and the Google Summer of Code

[This discussion could just as well go to py-dev, but it is here, this is here;-] Draft of announcement to send to various Python related lists. Google 2006 Summer of Code and Python Software Foundation This spring and summer, Google corporation will again provide several hundred stip

Re: [Python-3000] Python 3000 and the Google Summer of Code

"Neal Norwitz" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Here's a write up about last year's projects: > http://wiki.python.org/moin/SummerOfCode/2005 > > Payment was all or nothing. I thought we had something like 18 > projects, there are 14 up on the page above. I now coun

Re: [Python-3000] auto-super()

On Wed, Apr 19, 2006, Greg Ewing wrote: > > What causes trouble isn't multiple inheritance, it's diamond > inheritance. Without diamond inheritance, explicit calls to inherited > methods usually work fine, and continue to work fine when your classes > get inherited, multiply or otherwise, by other

Re: [Python-3000] mechanism for handling asynchronous concurrency

Andy Sy <[EMAIL PROTECTED]> wrote: > > The Io language has what (on paper) seems to be a very > neat, Pythonic mechanism for doing asynchronous concurrency. > > > The mechanism is called futures and is described at: > > http://iolanguage.com/darcs/Io/_docs/guide.html#TOC17133 > > > Perhaps P

Re: [Python-3000] Python 3000 and the Google Summer of Code

"Jan Claeys" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Well, I know the Django (web framework) people are maybe interested in > someone doing a SoC project for them: > So interested that they have signed up as

Re: [Python-3000] After 2.6 should be 3.0

"Edward C. Jones" <[EMAIL PROTECTED]> wrote: > Wild idea. > > I would like to see Python 3.0 before the turn of the next millennium. I > suggest that Python 2.6 be devoted to implementing some of the backward > compatible changes for Python 3.0. In particular, do the long-overdue > reorganizat

Re: [Python-3000] auto-super()

Thomas Wouters wrote: > The arguments against super() are > understandable -- if you only think about your own class, or completely > disregard MI. I think that's irresponsible: super() always calls the > right baseclass method, On the contrary, it's precisely when you *don't* know what classe

[Python-3000] mechanism for handling asynchronous concurrency

The Io language has what (on paper) seems to be a very neat, Pythonic mechanism for doing asynchronous concurrency. The mechanism is called futures and is described at: http://iolanguage.com/darcs/Io/_docs/guide.html#TOC17133 Perhaps Python 3000 can incorporate some similar ideas in its syntax

[Python-3000] A wish: build C, C++, FORTRAN library wrapping into Python.

Wild wish. Many C, C++ and FORTRAN libraries have been wrapped in Python. These wrapped libraries are used a lot. A number of programs have been written that automate this process, the standard example being SWIG. These programs have become fairly mature. How much of the wrapping process can b

[Python-3000] After 2.6 should be 3.0

Wild idea. I would like to see Python 3.0 before the turn of the next millennium. I suggest that Python 2.6 be devoted to implementing some of the backward compatible changes for Python 3.0. In particular, do the long-overdue reorganization of the libraries. After 2.6 should be 3.0. ___

[Python-3000] Special object to return from functions that return only None

Wild idea. When I was a newbie, I repeatedly make the mistake of writing alist = alist.sort() I suggest a singleton object "UseForbidden" ("Py_UseForbidden" in C). "UseForbidden" can be used only to return from a function. Any other attempt to use "UseForbidden" raises an exception. The incorr

Re: [Python-3000] Is reference counting still needed?

"Edward C. Jones" <[EMAIL PROTECTED]> wrote: > > Wild Idea: > > From Section 1.10 of "Extending and Embedding": > > Maybe some day a sufficiently portable automatic garbage collector will > be available for C. Until then, we'll have to live with reference counts. > > Any hope such a GC will

Re: [Python-3000] Function call speed (Was: Cleaning up argument list parsing)

Guido van Rossum wrote: > On 4/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote: >>Would automated inlining be a legitimate use for ast-hacking? > > Perhaps, if you can do it in a way that it also works for IronPython > and Jython... Would automatically falling back on non-inlining be acceptable if s

[Python-3000] Use Py_CLEAR only

Wild idea: Can Py_CLEAR completely replace Py_DECREF and Py_XDECREF? ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-a

[Python-3000] Is reference counting still needed?

Wild Idea: From Section 1.10 of "Extending and Embedding": Maybe some day a sufficiently portable automatic garbage collector will be available for C. Until then, we'll have to live with reference counts. Any hope such a GC will be available before Python 3.0? _

Re: [Python-3000] Function call speed (Was: Cleaning up argument listparsing)

I wanted to follow up a bit on the issue of speeding up function calls with some more specifics. Currently, the function call mechanism has to do a lot of conversion operations on the function arguments. Specifically, it takes the various positional arguments, keyword arguments, varargs argumen

Re: [Python-3000] Type Expressions

Birch, Bill wrote: > [int, etc] # a list of ints > # (etc = zero or more of the previous element) The obvious way to express that would be [int, ...] or at least it would be if ... weren't restricted to slices! Py3k suggestion: make ... a generally legal expres

Re: [Python-3000] Removing 'self' from method definitions

Guido van Rossum wrote: > - How would the function be given the attribute? > At the time the > function is being defined the class doesn't exist yet; Good point. I'll have to think about that some more. BTW, I'm not particularly advocating the idea -- I was really just pointing out that there ar

Re: [Python-3000] auto-super()

[snip] Sorry about the double-pasting in the last post. - Josiah ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-ar

Re: [Python-3000] auto-super()

"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > Let's leave this topic behind for a while. Hacks that can be > implemented only using sys._getframe() are not generally suitable for > including in the standard library or making part of the language spec. Assuming name uniqueness among all classes

Re: [Python-3000] auto-super()

On 4/19/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > Perhaps when a code object is constructed it could include a reference > to the class where it was constructed (if any). No, code objects shouldn't contain references to run-time artifacts (other than other code objects). Code objects

Re: [Python-3000] auto-super()

Guido van Rossum wrote: > Let's leave this topic behind for a while. Hacks that can be > implemented only using sys._getframe() are not generally suitable for > including in the standard library or making part of the language spec. Yep - there's no way I'd consider such a hack for the python dist

Re: [Python-3000] auto-super()

Let's leave this topic behind for a while. Hacks that can be implemented only using sys._getframe() are not generally suitable for including in the standard library or making part of the language spec. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___

Re: [Python-3000] symbols?

On 4/18/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > I was still thinking of symbols, and reading ".name" as syntactic > sugar for "self.name", with the caveat that the translation was made > at runtime rather that compile-time. > > Therefore > > property(._get_x, ._set_x) > > would be syntactic

Re: [Python-3000] auto-super()

Ian Bicking wrote: > But how can we do that without the function being bound to a class? > self.whoami() in A.dostuff needs to access the 'real' self. > self.super in B.dostuff should be super(B, self), even when > self.__class__ is C. > > Because Python *isn't* reading the functions statically

Re: [Python-3000] symbols?

On 4/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/18/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > On 4/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > Then, on 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > > [...] > > > class C: > > > x = property(._get_x, ._set_x, .

Re: [Python-3000] Cleaning up argument list parsing (was Re: More wishful thinking)

On 4/17/06, Talin <[EMAIL PROTECTED]> wrote: >def func( first, second=default, third ): > ... what's the point of supplying a default for the second > parameter, but not the third? You may be wrapping an external library. (Or at least a well-known API.) I'll grant that the second argument

Re: [Python-3000] symbols?

On 4/18/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 4/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Then, on 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > [...] > > class C: > > x = property(._get_x, ._set_x, ._del_x, > >"This is the x property") > > [...] > > >

Re: [Python-3000] symbols?

On 4/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Then, on 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > [...] > class C: > x = property(._get_x, ._set_x, ._del_x, >"This is the x property") > [...] > This is slightly more Pythonic, and unambiguous, but I'd rather >

Re: [Python-3000] auto-super()

On 4/18/06, Michael Urman <[EMAIL PROTECTED]> wrote: > On 4/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Hardly the same mechanism; __private is done by low-level name > > mangling in the early stages of the compiler. super() would need a > > class object to be reliable; the class *name*

Re: [Python-3000] Function call speed (Was: Cleaning up argument list parsing)

On 4/18/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Perhaps, if you can do it in a way that it also works for IronPython > > and Jython... > > Is it expected that IronPython and Jython will have similar performance > characteristics to CPython? That seems hard to achie

Re: [Python-3000] Specializing the dicts in __dict__

On 4/18/06, Steven Bethard <[EMAIL PROTECTED]> wrote: > On 4/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > PS: if this change to the class statement were to happen, the crowd > > discussing the 'make' PEP (which I don't like but don't have the power > > to stop being discussed) should take

Re: [Python-3000] genexp syntax for reduce (already in 2.5a1)

I wouldn't recommend this approach to anyone. On 4/18/06, Boris Borcic <[EMAIL PROTECTED]> wrote: > Hello, > > Since the notion of a "generator comprehension" reduce syntax for py3k was > discussed on this list - it may have escaped attention that py2.5a1 already > allows the following, admittedly

Re: [Python-3000] Test and Assign [was: More wishful thinking]

On Apr 18, 2006, at 12:24 PM, Bill Janssen wrote: >>> Presumably a reference to a Python symbol would be not just the >>> symbol >>> name string, but also an indicator of the namespace of the symbol. >> >> That would be something very new -- nothing like that was >> implied by the original sugg

Re: [Python-3000] auto-super()

Aahz wrote: >>But how can we do that without the function being bound to a class? >>self.whoami() in A.dostuff needs to access the 'real' self. self.super >>in B.dostuff should be super(B, self), even when self.__class__ is C. > > > Hrm. I think I'm forgetting that Python doesn't have any dyn

Re: [Python-3000] Function call speed (Was: Cleaning up argument list parsing)

"Jim Jewett" <[EMAIL PROTECTED]> wrote: > > On 4/17/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > > Guido van Rossum wrote: > > > > Inlining code obviously addresses this, but that's often > > > killing code structure. > > > Would automated inlining be a legitimate use for > > ast-hacking? > > T

Re: [Python-3000] Function call speed (Was: Cleaning up argument list parsing)

On 4/17/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Inlining code obviously addresses this, but that's often > > killing code structure. > Would automated inlining be a legitimate use for > ast-hacking? To keep the same semantics, you need some notification that the (

Re: [Python-3000] auto-super()

On Tue, Apr 18, 2006, Ian Bicking wrote: > Aahz wrote: >>On Tue, Apr 18, 2006, Thomas Wouters wrote: >> >>>- Compiler hackery involving a magical variable name, say '__class__' >>>or '__CLASS__'. The compiler would treat this specially, probably >>>stored in the class dict, and type() (which is, af

Re: [Python-3000] Specializing the dicts in __dict__

Steven Bethard wrote: > Could someone put out some use-cases where it would be really helpful > to be able to specify a different dict type for the class dict? In SQLObject and FormEncode, you can do something like: class Registration(formencode.Schema): fname = String(not_empty=True)

Re: [Python-3000] Function call speed (Was: Cleaning up argument list parsing)

Guido van Rossum wrote: >>>Inlining >>>code obviously addresses this, but that's often killing code >>>structure. >> >>Would automated inlining be a legitimate use for ast-hacking? > > > Perhaps, if you can do it in a way that it also works for IronPython > and Jython... Is it expected that Iron

Re: [Python-3000] Specializing the dicts in __dict__

Guido van Rossum wrote: >>The suggested order would be by key creation so that reassigning >>a key after manipulation would maintain the original order as in >>the Thing.b case above. > > > Unfortunately I don't think you can implement this without > significantly slowing things down. This belief

Re: [Python-3000] auto-super()

Aahz wrote: > On Tue, Apr 18, 2006, Thomas Wouters wrote: > >> - Compiler hackery involving a magical variable name, say '__class__' >>or '__CLASS__'. The compiler would treat this specially, probably >>stored in the class dict, and type() (which is, after all, called to >>actually create the clas

Re: [Python-3000] Specializing the dicts in __dict__

On 4/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > PS: if this change to the class statement were to happen, the crowd > discussing the 'make' PEP (which I don't like but don't have the power > to stop being discussed) should take notice. If you pronounce it dead, I can make sure the discus

Re: [Python-3000] Test and Assign [was: More wishful thinking]

> > Presumably a reference to a Python symbol would be not just the symbol > > name string, but also an indicator of the namespace of the symbol. > > That would be something very new -- nothing like that was > implied by the original suggestion, and no other language > I know of that has symbols g

Re: [Python-3000] auto-super()

On Tue, Apr 18, 2006, Thomas Wouters wrote: > > - Compiler hackery involving a magical variable name, say '__class__' > or '__CLASS__'. The compiler would treat this specially, probably > stored in the class dict, and type() (which is, after all, called to > actually create the class) would stuff

Re: [Python-3000] auto-super()

On 4/17/06, Aahz <[EMAIL PROTECTED]> wrote: On Sun, Apr 16, 2006, Michael P. Soulier wrote:> On 17/04/06 Greg Ewing said: The other possible reason for using super() is so you don't have>> to write the name of the base class into all your inherited method >> calls. But that's a separate issue t

Re: [Python-3000] auto-super()

On 4/18/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Hardly the same mechanism; __private is done by low-level name > mangling in the early stages of the compiler. super() would need a > class object to be reliable; the class *name* (which is all that's > available at compile time) might resol

Re: [Python-3000] Python 3000 and the Google Summer of Code

Op ma, 17-04-2006 te 22:44 -0400, schreef Terry Reedy: > Your next post answered my question as to mentor eligibility: known of > by you or two references therefrom. But back to project eligibility: > how far beyond direct implementation-related projects? [...] Or > webframeworks? Well, I know

[Python-3000] genexp syntax for reduce (already in 2.5a1)

Hello, Since the notion of a "generator comprehension" reduce syntax for py3k was discussed on this list - it may have escaped attention that py2.5a1 already allows the following, admittedly not very efficient (nor too robust in this proof-of-concept implementation). hth, Boris Borcic def iredu

Re: [Python-3000] Function call speed (Was: Cleaning up argument list parsing)

On 4/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > Inlining > > code obviously addresses this, but that's often killing code > > structure. > > Would automated inlining be a legitimate use for ast-hacking? Perhaps, if you can do it in a way that it also works for Iro

Re: [Python-3000] Type Expressions

You seem to have missed some of my blog entries on Artima early last year. I proposed a syntax that should address most of your issues, e.g. (int, str, float) as a tuple of thos three types, T1|T2 for unions, list[int] for a list of ints. --Guido On 4/18/06, Birch, Bill <[EMAIL PROTECTED]> wrote

[Python-3000] Type Expressions

Hi, There is a massive amount of discussion about adding type checking to Python going back a long way, however most discussions gloss over exactly what type expressions are exactly. I'm working on this question with the goal of putting up a proposal of some kind to this list. So far I have s

[Python-3000] A minor cleanup: instances from bound methods

I noticed this the other day. Perhaps it is suitable for a python 3000 cleanup? It certainly seems illogical, but probably too intrusive to change in python 2.x. I needed to find the instance from a bound method, with obj.im_self. Eg >>> class C(object): ... def fn(self): print "hello"

Re: [Python-3000] Removing 'self' from method definitions

On 18-apr-2006, at 10:49, Guido van Rossum wrote: > On 4/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote: >> The problem is that there's no way for Python to know >> which class the method is "in", in the sense required >> here. >> >> That could be fixed by giving functions defined inside >> a class

Re: [Python-3000] auto-super()

On 4/18/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > Whatever resolves __private variables could be used to the same effect > to bind super, couldn't it? Still a language-level change, but not one > without precedence. Hardly the same mechanism; __private is done by low-level name mangling in the

Re: [Python-3000] Removing 'self' from method definitions

On 4/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > The problem is that there's no way for Python to know > which class the method is "in", in the sense required > here. > > That could be fixed by giving functions defined inside > a class statement an attribute referring back to the > class. It wou

Re: [Python-3000] Specializing the dicts in __dict__

On 4/18/06, Jack Diederich <[EMAIL PROTECTED]> wrote: > I mentioned then and would like to resurrect now the idea of making > a dict-alike that has two extra properties: > > 1: the keys can only be str or unicode (py3k: just unicode) This seems useful -- although the current dict type is already

Re: [Python-3000] iter_flatten was: Making strings non-iterable

Raymond Hettinger a écrit : > [Brian Harring] > >>The issue I'm seeing is that the wart you're pointing at is a >> general issue not limited to strings- everyone sooner or later >> has flattening code that hits the "recursively iterate over >> this container, except for instances of these classes