Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Guido van Rossum wrote: On 1/6/06, Kay Schluehr [EMAIL PROTECTED] wrote: Then simply reject the PEP and the discussion can be stopped on comp.lang.python too. Only in the most severe cases does it make sense to create a PEP specifically to be rejected. Or why do you think it should be discussed there again and again or elsewhere on the web ( e.g. in Bruce Eckels blog on Artima )? Perhaps because people don't understand it? They don't accept it even more than they don't understand it. This leads to repeated guesses that the object model might perhaps change in Py3K with respect to explicit self [1]. It's not all just an educational issue. If this is not a severe case where an autoritarian decision should be made and also be made visible at a central and recoverable place I don't know what? Regards Kay [1] See e.g. Bruce Eckels postings on this page: http://www.artima.com/forums/flat.jsp?forum=106thread=141312start=75msRange=15 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Ian Bicking wrote: would have to be translated to this this: inst = Foo() f = Foo.bar meth = bind(f, inst) print meth(1, 2) +1 for an explicit bind unbound method operation, although I would spell it as inst = Foo() f = Foo.bar meth = f.bind(inst) print meth(1, 2) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
On Sat, Jan 07, 2006 at 05:12:06PM -0800, Guido van Rossum wrote: On 1/6/06, Kay Schluehr [EMAIL PROTECTED] wrote: Then simply reject the PEP and the discussion can be stopped on comp.lang.python too. Only in the most severe cases does it make sense to create a PEP specifically to be rejected. Yet if it isn't recorded, people will keep bringing it up. How about a 'rejected ideas' PEP for ideas that are right out no matter how people argue? A single PEP, with oneliners to describe ideas, one or two lines to explain 'why not', references to the python-list or python-dev discussions, if any, and a sign in big friendly letters saying if you really must discuss these subjects, do it on python-list, not python-dev. Some of the stuff that could be in there: - implicit rather than explicit self: invalidates too many tricks - omitting () on functioncalls: like implicit self - changing all statements into expressions (e.g. logix): python isn't (going to be) a functional language - methods for tuples: tuples are records, not collections; use lists instead - sigils to indicate 'self.' (e.g. @foo): loses readability, wins too little - '?' and other non-alphanumerical characters in identifiers: like sigils - strict private/public accessing: 'fake' protection; use closures instead etc. No need to come up with them all, I'm sure all the prize ideas will pop back up eventually ;) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Thomas Wouters wrote: Yet if it isn't recorded, people will keep bringing it up. How about a 'rejected ideas' PEP for ideas that are right out no matter how people argue? Recorded it is, in the mailing list archive. However, a central place might be better, preferably with referrals to pronouncements or other discussion. A Wiki comes to mind... Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- Alexander Kozlovsky [EMAIL PROTECTED] wrote: What do you think about this? I (who writes Python code for a living) love it! See also: http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html ***Please*** make Python more selfish. Note that this is also an obvious avenue for significant performance increases. If self is implicit you don't have to do the dictionary lookup for self all the time as is the case now. Good luck with your battle! Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Thomas Wouters wrote: Only in the most severe cases does it make sense to create a PEP specifically to be rejected. Yet if it isn't recorded, people will keep bringing it up. How about a 'rejected ideas' PEP for ideas that are right out no matter how people argue? A single PEP, with oneliners to describe ideas, one or two lines to explain 'why not', references to the python-list or python-dev discussions, if any, and a sign in big friendly letters saying if you really must discuss these subjects, do it on python-list, not python-dev. Some of the stuff that could be in there: - implicit rather than explicit self: invalidates too many tricks - omitting () on functioncalls: like implicit self - changing all statements into expressions (e.g. logix): python isn't (going to be) a functional language - methods for tuples: tuples are records, not collections; use lists instead - sigils to indicate 'self.' (e.g. @foo): loses readability, wins too little - '?' and other non-alphanumerical characters in identifiers: like sigils - strict private/public accessing: 'fake' protection; use closures instead etc. No need to come up with them all, I'm sure all the prize ideas will pop back up eventually ;) the FAQ touches many of these. maybe a couple of clarifications to the relevant FAQ texts (explaining things in terms of design tradeoffs, rather than absolute truths) would be good enough ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Ralf W. Grosse-Kunstleve wrote: ***Please*** make Python more selfish. Note that this is also an obvious avenue for significant performance increases. If self is implicit you don't have to do the dictionary lookup for self all the time as is the case now. what dictionary lookup ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- Fredrik Lundh [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve wrote: ***Please*** make Python more selfish. Note that this is also an obvious avenue for significant performance increases. If self is implicit you don't have to do the dictionary lookup for self all the time as is the case now. what dictionary lookup ? IIUC, self is first looked up in the local dictionary. Please try the code below to see the performance impact. As an alternative to a copy/paste exercise try this: wget http://cci.lbl.gov/~rwgk/python/self_lookup.py python self_lookup.py The output with Python 2.4.1/Fedora3/Opteron is: loop_function: 13.10 loop_class: 17.11 Cheers, Ralf import time def loop_function(x, n): result = 0 for i in xrange(n): result += x return result class loop_class: def __init__(self, x, n): self.x = x self.n = n def __call__(self): result = 0 for i in xrange(self.n): result += self.x return result def run(x=3.1415, n=10**8): t0 = time.time() loop_function(x=x, n=n) print loop_function: %.2f % (time.time() - t0) t0 = time.time() loop_class(x=x, n=n)() printloop_class: %.2f % (time.time() - t0) if (__name__ == __main__): run() __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Ralf W. Grosse-Kunstleve wrote: what dictionary lookup ? IIUC, self is first looked up in the local dictionary. no, self is a local variable. self.x means that x is looked up in the in- stance dictionary, though. Please try the code below to see the performance impact. oh, please. do you seriously think that if you don't have to type self yourself, Python will suddenly be able to turn all instance variables into local function variables without any performance overhead ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- Guido van Rossum [EMAIL PROTECTED] wrote: On 1/6/06, Armin Rigo [EMAIL PROTECTED] wrote: On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote: There are three different peculiarity in Python 2.x in respect of 'self' method argument: Yuk! This has been discussed again and again already. *Please* move this discussion to comp.lang.python. Yes please. This is a death penalty, even without your explicit rejection. No professional person has the time to sift through that volume of noise. This won't change. The outside world is trying to tell you something; and they are not all dumb as you suggest in your other posting. I suggest creating [EMAIL PROTECTED] Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
On Sun, Jan 08, 2006 at 07:35:53AM -0800, Ralf W. Grosse-Kunstleve wrote: IIUC, self is first looked up in the local dictionary. No. Local variables are stored in a tuple (more or less,) and indexed by, er, index. Loading a local variable onto the stack is a fairly fast operation. Please try the code below to see the performance impact. As an alternative to a copy/paste exercise try this: wget http://cci.lbl.gov/~rwgk/python/self_lookup.py python self_lookup.py The output with Python 2.4.1/Fedora3/Opteron is: loop_function: 13.10 loop_class: 17.11 The main difference isn't the lookup of 'self', it's the attribute retrieval of 'x' from 'self'. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Ralf W. Grosse-Kunstleve wrote: --- Fredrik Lundh [EMAIL PROTECTED] wrote: Please try the code below to see the performance impact. oh, please. do you seriously think that if you don't have to type self yourself, Python will suddenly be able to turn all instance variables into local function variables without any performance overhead ? Yes, exactly, since you can make the local namespace vs. instance attribute distinction in C. Cheers, Ralf that indeed proves why this discussion for whatever value it has, belongs to comp.lang.python. This is not a place to clarify people how Python currently works, or to have discussions made of guesses and half-formed speculations. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- Thomas Wouters [EMAIL PROTECTED] wrote: The main difference isn't the lookup of 'self', it's the attribute retrieval of 'x' from 'self'. I see. Thanks! If you put 'self' into a special category (with corresponding C code), couldn't you use the same indexing tricks as for local variables and make 'self.x' just as fast as 'x'? Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
--- Fredrik Lundh [EMAIL PROTECTED] wrote: Please try the code below to see the performance impact. oh, please. do you seriously think that if you don't have to type self yourself, Python will suddenly be able to turn all instance variables into local function variables without any performance overhead ? Yes, exactly, since you can make the local namespace vs. instance attribute distinction in C. Cheers, Ralf __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
On Sun, Jan 08, 2006 at 08:09:22AM -0800, Ralf W. Grosse-Kunstleve wrote: --- Thomas Wouters [EMAIL PROTECTED] wrote: The main difference isn't the lookup of 'self', it's the attribute retrieval of 'x' from 'self'. I see. Thanks! If you put 'self' into a special category (with corresponding C code), couldn't you use the same indexing tricks as for local variables and make 'self.x' just as fast as 'x'? No need to make 'self' magical for that. You do, however, need to make the *object* magical for that. It works for local namespaces because the Python compiler knows exactly which names are local and which aren't. There are two cases where the compiler can't know for sure (using 'exec' without 'in' and using 'from module import *') and in those cases, Python doesn't optimize local variable access all the way. This all won't work for objects and their attributes because too much is possible at runtime for the current compiler to handle. The compiler could, of course, check everything in the whole program, keeping track of what could possibly adjust which attributes of what object where. That would be 'type inferencing' and has been (and is being, I guess) attempted by various people in various projets. However, if your compiler is so smart, it won't have _any_ problems taking an exlicit self into account :) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
At 08:09 AM 1/8/2006 -0800, Ralf W. Grosse-Kunstleve wrote: --- Thomas Wouters [EMAIL PROTECTED] wrote: The main difference isn't the lookup of 'self', it's the attribute retrieval of 'x' from 'self'. I see. Thanks! If you put 'self' into a special category (with corresponding C code), couldn't you use the same indexing tricks as for local variables and make 'self.x' just as fast as 'x'? It's not nearly that simple. See e.g.: http://mail.python.org/pipermail/python-dev/2002-February/019854.html Note, however, that such a speedup is entirely independent of the syntax. Trying to link the syntax with the performance is completely bogus. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
[Thomas Wouters] My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ, the minds of many, many people, not just Python developers) but that it isn't easily findable and it isn't easily accessible in a single location. I thought PEP's where supposed to be that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Luckily, in his benevolent infinite wisdom, I expect Guido reserved PEP number 13 for exactly this purpose: for a meta-PEP to record the unlucky PEP ideas that are so unlikely to get accepted that it's not worth anyone's time to write an actual PEP for them. I like the title: Don't Bother: PEPs Rejected Before Being Written No, I'm not kidding. At least I don't think I am. ... And I would like to point out how hard it is to google or grep for ideas like this. For instance, the 'x, y, *rest = someseq' syntax. I wouldn't know what to call it (or what others would call it, and you can't google for the syntax (since the variables can be named anything). If PEP 13 grows large enough, won't be easy to find there either. But it will be easy to remember _where_ to look. ... And a PEP titled 'Rejected Ideas' would certainly be the first place to look ;) Too bland ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Thomas Wouters wrote: My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ, the minds of many, many people, not just Python developers) but that it isn't easily findable and it isn't easily accessible in a single location. Why would a single Wiki page not be accessible in a single location? Why is the FAQ not accessible in a single location? I thought PEP's where supposed to be that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Right. However, I doubt you would look in the rejected ideas PEP. I guess a Wiki'd work, but then I wonder, why aren't all PEPs in a Wiki instead? There might be several reasons - one is that a PEP is supposed to get posted to mailing lists and newsgroups, something that is not readily possible with Wiki pages. And I would like to point out how hard it is to google or grep for ideas like this. For instance, the 'x, y, *rest = someseq' syntax. I agree that collecting them in a single place is a good idea. Whether this is a PEP, a Wiki page, or the FAQ is nearly irrelevant, except: - it is strange to call it a Python Enhancement Proposal - in either the FAQ or the PEP, it will stay in its initial form forever, since nobody but the original author will edit it (that could be true of a Wiki page as well, but on a Wiki page, people *know* they are meant to edit it if they want to say something) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Martin v. Löwis wrote: But they might suffer from misunderstandings, such as your misunderstanding in how local variables work and whether 'self' is looked up in a dictionary. So it's being dumb - just being uninformed. Sorry: *not* being dumb is what I wanted to say. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
On Sun, Jan 08, 2006 at 06:31:35PM +0100, Martin v. Löwis wrote: Thomas Wouters wrote: My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ, the minds of many, many people, not just Python developers) but that it isn't easily findable and it isn't easily accessible in a single location. Why would a single Wiki page not be accessible in a single location? Why is the FAQ not accessible in a single location? Unless either of those would replace PEPs (or include all information from all PEPs), they would be a second location. I thought PEP's where supposed to be that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Right. However, I doubt you would look in the rejected ideas PEP. You may have the luxury of that doubt, but I don't :) I'm sorry if my comments sounded hypothetical; they weren't. I did wonder about (among other things) 'x, y, *rest = l', and because I didn't know the name, I did browse the PEP list. A 'Rejected Ideas' PEP would've caught my eye even if I didn't have a hunch Guido would reject 'x, y, *r = l'. I agree that collecting them in a single place is a good idea. Whether this is a PEP, a Wiki page, or the FAQ is nearly irrelevant, except: - it is strange to call it a Python Enhancement Proposal They are proposals to enhance Python, though. That's exactly why I argue they should be in a PEP, not in some other location: it's all neatly bundled together. It's just not a PEP per single proposal. - in either the FAQ or the PEP, it will stay in its initial form forever, since nobody but the original author will edit it (that could be true of a Wiki page as well, but on a Wiki page, people *know* they are meant to edit it if they want to say something) I don't think the rejected-ideas collection should be publically editable either. It's not a discussion forum, it's not meant to get people to persuade Guido to change his mind, it's a list of these things just aren't going to happen, deal with it. A Meta-PEP like Tim suggested seems most appropriate to me, even if it isn't purely Meta; practicality beats purity and all that. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Tim Peters wrote: [Thomas Wouters] My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ, the minds of many, many people, not just Python developers) but that it isn't easily findable and it isn't easily accessible in a single location. I thought PEP's where supposed to be that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Luckily, in his benevolent infinite wisdom, I expect Guido reserved PEP number 13 for exactly this purpose: for a meta-PEP to record the unlucky PEP ideas that are so unlikely to get accepted that it's not worth anyone's time to write an actual PEP for them. I like the title: Don't Bother: PEPs Rejected Before Being Written No, I'm not kidding. At least I don't think I am. +1. I think it's rather patronizing to send things back to python-list when you know people are wasting their time discussing them because they will never be accepted. People on python-list have useful things to do too, they don't just read to waste their time. I would prefer PEP form over a wiki page, as I'd rather this be truly authoritative, and only Guido can really completely reject an idea. Justifying the rejections can be done by anyone though; maybe each idea could link to a wiki page on the topic. I think it's also important to be clear on what's being rejected. Often these rejected ideas address a real issue, and if you think about the issue from another angle you might be able to solve that without falling into the trap that the oft-rejected proposal fell into. But it's easy to confuse that the issue or use case is being explicitly ignored, rather than the particulars. For instance, Thomas said changing all statements into expressions (e.g. logix): python isn't (going to be) a functional language -- and that's what shouldn't be in the PEP. All statements aren't going to be expressions; the editorialization that Python isn't going to be a functional language is both rather inaccurate, misses the real reason for statements, and needlessly alienates people who like functional programming (and they have been *needlessly* alienated by discussions about lambda and filter). So... maybe Guido or python-dev should write/vet the justifications too. When you are putting up walls and specifically discouraging community participation on certain issues, it should be done in a sensitive way. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Ian Bicking wrote: Tim Peters wrote: [Thomas Wouters] My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ, the minds of many, many people, not just Python developers) but that it isn't easily findable and it isn't easily accessible in a single location. I thought PEP's where supposed to be that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Luckily, in his benevolent infinite wisdom, I expect Guido reserved PEP number 13 for exactly this purpose: for a meta-PEP to record the unlucky PEP ideas that are so unlikely to get accepted that it's not worth anyone's time to write an actual PEP for them. I like the title: Don't Bother: PEPs Rejected Before Being Written No, I'm not kidding. At least I don't think I am. +1. I think it's rather patronizing to send things back to python-list when you know people are wasting their time discussing them because they will never be accepted. Well, the problem is that most of these proposers think that their proposal deserve attention, is valuable no matter what, but python-dev is not the place to defuse/clarify that in a gentle way for the proposer. Of course some people do exactly that here out of kindness etc., I personally don't think it's a good approach. python-list is a better place to get clarifications about the way Python is, will stay. Half-baked, not well thought out ideas, as huge threads in the past going nowhere have proven, are not healthy to python-dev s/n ratio. Even with such a valuable PEP in place, I expect some people to need clarification discussions and python-list will still be the right place to have them. People on python-list have useful things to do too, they don't just read to waste their time. I would prefer PEP form over a wiki page, as I'd rather this be truly authoritative, and only Guido can really completely reject an idea. Justifying the rejections can be done by anyone though; maybe each idea could link to a wiki page on the topic. I think it's also important to be clear on what's being rejected. Often these rejected ideas address a real issue, and if you think about the issue from another angle you might be able to solve that without falling into the trap that the oft-rejected proposal fell into. But it's easy to confuse that the issue or use case is being explicitly ignored, rather than the particulars. For instance, Thomas said changing all statements into expressions (e.g. logix): python isn't (going to be) a functional language -- and that's what shouldn't be in the PEP. All statements aren't going to be expressions; the editorialization that Python isn't going to be a functional language is both rather inaccurate, misses the real reason for statements, and needlessly alienates people who like functional programming (and they have been *needlessly* alienated by discussions about lambda and filter). So... maybe Guido or python-dev should write/vet the justifications too. When you are putting up walls and specifically discouraging community participation on certain issues, it should be done in a sensitive way. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
On Sun, Jan 08, 2006 at 02:43:17PM -0600, Ian Bicking wrote: [T]he editorialization that Python isn't going to be a functional language is both rather inaccurate, misses the real reason for statements, and needlessly alienates people who like functional programming So... maybe Guido or python-dev should write/vet the justifications too. Oh, none of my examples were anything but that. Particularly the justification. These were just quick ramblings from my side; all actual pronouncements should be made channeling or being Guido, and the editorial review to ease sensitive minds is a group effort. (On the topic you quoted, though, I do feel that if people are using Python while they are waiting for Python to turn into a functional language, they're waiting for the wrong thing. Or at least, I hope so, or *I'm* waiting for the wrong thing. So I'm not sure what's wrong about the editorialization, but perhaps I'm just too insensitive towards functional programming disciples. And I'm usually quite in tune with sensitive minds. But we can discuss that off-list ;) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Thomas Wouters wrote: [T]he editorialization that Python isn't going to be a functional language is both rather inaccurate, misses the real reason for statements, and needlessly alienates people who like functional programming So... maybe Guido or python-dev should write/vet the justifications too. Oh, none of my examples were anything but that. Particularly the justification. These were just quick ramblings from my side; all actual pronouncements should be made channeling or being Guido, and the editorial review to ease sensitive minds is a group effort. I was also just using your example as an example ;) As another similar example, around the discussions of the deprecation of map and filter I see a lot of misunderstandings. People confused the deprecation of two Lisp functions with Guido wanting to discourage functional program in general. The whole thing is based on several misconceptions, but the misunderstanding has become very widespread. A big part of what happened (I think) is that people who defended the decision added editorialization that became confused with the original intentions. And that consisted of things like functional programming is hard/confusing, so it's not appropriate in Python. I think putting these kinds of decisions on a wiki would generally lead to these kinds of confusions. When rejecting an idea altogether I think it should be clear exactly what is being rejected, and not imply that anything extra is being rejected. People read a lot I think there is a valid perception that the Python community is not very open to many ideas about changing the language. I think that's okay -- it's this way *because* of the participation and discussion that has occurred in the past, because these are old ideas that have been rejected and we are trying to move on. But it leaves people in an awkward situation, because how can you really know what is open for discussion? I don't think people on python-list really know this either, so asking there won't clarify that. I doubt there's general consensus on python-dev about what is open for change. I just don't want people to feel discouraged when they try to contribute to the Python community and a PEP 13 could help direct people towards areas where their contributions are more likely to be useful. Also I think it is unfair to use python-list to clarify things that python-dev is not willing to clarify itself. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Ian Bicking wrote: I just don't want people to feel discouraged when they try to contribute to the Python community and a PEP 13 could help direct people towards areas where their contributions are more likely to be useful. Also I think it is unfair to use python-list to clarify things that python-dev is not willing to clarify itself. But now: who is going to write it? Guido should write it clearly won't work. And no, I'm explicitly not volunteering either. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Ian Bicking wrote: I just don't want people to feel discouraged when they try to contribute to the Python community and a PEP 13 could help direct people towards areas where their contributions are more likely to be useful. but people have a lot of options, probably more effective, ranging from writing great applications in Python, great libraries ... plus implementation work before they are left with the hard option that is language design to contribute to the community. Also I think it is unfair to use python-list to clarify things that python-dev is not willing to clarify itself. notice that the intersection is not empty yet. Also PEP 1 contains PEP authors are responsible for collecting community feedback on a PEP before submitting it for review. A PEP that has not been discussed on python-list@python.org and/or python-dev@python.org will not be accepted. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the PEP author accept private comments in the early design phases, setting up a wiki page, etc. PEP authors should use their discretion here. in the past it often happened that water testing, honing for a PEP happend on python-list before any long discussion went on on python-dev. Basically I think that throwing half-cooked ideas at python-dev, especially for people with no track-record of language design contributions to Python, is just a recipe for frustration. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
[Martin] But now: who is going to write it? Guido should write it clearly won't work. And no, I'm explicitly not volunteering either. [Thomas] Well, the PEP will be mostly boilerplate anyway (unless there's a sudden influx of old ideas) so I'm sure I can whip something up before next weekend. I'll probably keep the actual list of rejected items to implicit self (which started the whole discussion), upgrading the Python parser beyond a simple LL(1), and maybe implicit ()'s for functioncalls, if I feel inspired. The exact wording, and additional rejects, can be discussed at length by those interested. I'll help with this. That means I want to and intend to, and will discover that I can't actually make any time for it. With two of us putting it off indefinitely, it should get done in half the time ;-). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
On 1/6/06, Kay Schluehr [EMAIL PROTECTED] wrote: Then simply reject the PEP and the discussion can be stopped on comp.lang.python too. Only in the most severe cases does it make sense to create a PEP specifically to be rejected. Or why do you think it should be discussed there again and again or elsewhere on the web ( e.g. in Bruce Eckels blog on Artima )? Perhaps because people don't understand it? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Example 1 (Python 2.x): --- class Foo: def __init__(self, x): # 1: Explicit 'self' argument self.x = x # 2: 'self' must be used explicitly def bar(self, a, b): # 3: There are three arguments... print self.x + a + b Foo(10).bar(20, 30) # ...but only two explicit parameters #is presented This document proposes to change this, as the next example shows: Example 2 (Python 3.0): --- class Foo: def __init__(x): # 1: Implicit self .x = x # 2: Brief form of: self.x = x def bar(a, b): # 3: Two arguments... print .x + a + b Foo(10).bar(20, 30) # ...and exactly two parameters In my case, I think that the problem of _self_ is mainly in the method definition. It's a little hard to understand why you have to use myFunction(self, otherArgs) when you create a class method. But the use of self in the code of the method is a good thing because it allow you to clearly say that you are working on a class property. In my case, I would like to have the following syntax in Python 3.0 : class Foo: def __init__(x): self.x = x def bar(a, b): print self.x + a + b My 0.2€ ;) -- Fabien SCHWOB ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Hi Alexander, On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote: There are three different peculiarity in Python 2.x in respect of 'self' method argument: Yuk! This has been discussed again and again already. *Please* move this discussion to comp.lang.python. A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Hello! Ian Bicking wrote: (As an aside directed at the original PEP, I think discussion of leaving self out of expressions, e.g., .x for self.x, should be separate from the rest of this PEP). Yes, I'm fully agree. Nick Coghlan wrote: The main concern I have is with the answer to the question How many positional arguments does the function have if I retrieve it from the class, rather than from an instance? (this is the common concern for almost all proposals to remove the explicit self and class_ slots). In this case, the function always (!!!) has fixed number of positional arguments equal to number of positional parameters inside the function definition: def func(a, b): ... print class, self, a, b ... class Foo: ... bar = func ... instance = Foo() func(1, 2) # there are 2 arguments None None 1 2 # - class and self both equal to None Foo.bar(1, 2) # 2 arguments again!! class Foo None 1 2# - self is equal to None instance.bar(1, 2) # 2 arguments always!!! class Foo Foo object at 0x016434F0 1 2 Nick Coghlan wrote: To sum the proposal up in my own words: Eliminate the need for explicit class and self slots in class and instance methods by implicitly providing those slots on all functions. Yes, I think, it is what I mean. With my proposal, 'self' is no longer the first explicit or implicit positional argument (!), instead, it is 'pseudo-argument', the value of which is equal to function's 'im_self' attribute. Any function contains two special read-only attributes: 'im_class' and 'im_self', and values of this attributes are accessible inside function body as values of 'class' and 'self' pseudo-arguments. Any function has this attributes, for ordinary function their values are set to 'None'. Example: # Python 3.0 def f(): return class, self f() (None, None) There is new built-in function: bind(old_function, self_, class_=None) - new_function The result is the new function with the same code object which the old function had, but with different im_class and im_self attributes values. - If both self_ and class_ arguments are None, then 'im_class' and 'im_self' attributes of new function is set to equal to None. - If self_ is not None, then class_ must be None or self_.__class__. 'im_self' attribute of new function is set to self_, and im_class attribute is set to self_.__class__ - If self_ is None but class_ is not None, then 'im_self' attribute is set to None, and 'im_class' attribute is set to class_ Consider this expression (extraction of a method from a class): x = Foo.bar This expression is equivalent of: x = bind(Foo.__dict__[bar], None, Foo) After this, x.im_class is Foo and x.im_self is None The type.__getattribute__ contains implementation of this Consider next expression (extraction of a method from an instance): y = instance.bar This expression is equivalent of: y = bind(instance.__class__.__dict__[bar], instance) After this, y.im_class is instance.__class__ and y.im_self is instance. The object.__getattribute__ is responsible for this Ian Bicking wrote: Well... it becomes more complex for decorators, I guess: def printargs(func): def replacement(*args, **kw): print args, kw return func(*args, **kw) return replacement class Foo: @printargs def null(a): pass What is printargs going to print? Will it even work? I'd guess you'd have to do: def printargs(func): def replacement(*args, **kw): print args, kw return bind(func, self)(*args, **kw) return replacement I think, it should be: def printargs(func): def replacement(*args, **kw): print args, kw return bind(func, self, class)(*args, **kw) return replacement Yep, the code in decorators will be more complicated than it is today. I did not get it before... I guess it depends on what bind(func, self) does outside of a method invocation. I think self should be undefined in that case. 'self' will be None in that case. Any function has 'self' pseudo-argument, but in a plain function (not a method) 'self' and 'class' both equal to None. -- Best regards, Alexandermailto:[EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
On 1/6/06, Armin Rigo [EMAIL PROTECTED] wrote: On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote: There are three different peculiarity in Python 2.x in respect of 'self' method argument: Yuk! This has been discussed again and again already. *Please* move this discussion to comp.lang.python. Yes please. This won't change. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Guido van Rossum wrote: Yuk! This has been discussed again and again already. *Please* move this discussion to comp.lang.python. Yes please. This won't change. Then simply reject the PEP and the discussion can be stopped on comp.lang.python too. Or why do you think it should be discussed there again and again or elsewhere on the web ( e.g. in Bruce Eckels blog on Artima )? Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
I wrote: 5. Each function have two constant attributes, __class__ and __self__, both of them have value 'None' Of course, this attributes have names 'im_class' and 'im_self', as before, but can be used with any function. I have not sleep enough last night :) Best regards, Alexandermailto:[EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
Alexander Kozlovsky wrote: Hello! I have some proposal for Python 3.0 (interesting one, from my point of view). I'm sorry for my English, it is not very good. Your English seems fine. About the only thing I noticed is that you have the meaning of 'function arguments' vs 'function parameters' switched from a Python point of view - the parameters are defined as part of the function definition, while the arguments are provided at call time. This is really a minor semantic quibble though - I expect most people wouldn't have any real trouble figuring out what you meant. Even though I still disagree with it, this is one of the better reasoned no explicit self proposals I've encountered - even if Guido ends up not liking it, I believe it should still be recorded as a PEP on python.org. To sum the proposal up in my own words: Eliminate the need for explicit class and self slots in class and instance methods by implicitly providing those slots on all functions. The main concern I have is with the answer to the question How many positional arguments does the function have if I retrieve it from the class, rather than from an instance? (this is the common concern for almost all proposals to remove the explicit self and class_ slots). That is, the rationale for requiring the explicit self is an outgrowth of the fact that methods can be retrieved directly from the class: class Foo: def __init__(self, x): # 1: Explicit 'self' argument self.x = x # 2: 'self' must be used explicitly def bar(self, a, b): # 3: There are three parameters... print self.x + a + b f = Foo.bar # We retrieve the unbound method f(Foo(10), 20, 30) # And there are three arguments at call time f = Foo().bar# Using an instance binds the first argument f(20, 30)# Which means there are two arguments left You can also bypass the type machinery entirely, and retrieve the raw function object from the class dictionary: f = Foo.__dict__[bar] # This gives a function. . . f(Foo(10), 20, 30) # which takes three arguments as written Under the proposal being discussed, things become far less clear: class Foo: def __init__(x): # 1: Implicit self .x = x # 2: Brief form of: self.x = x def bar(a, b): # 3: Two arguments... print .x + a + b f = Foo(10).bar # We agree this accepts 2 arguments f = Foo.bar # How many arguments does f accept? f = Foo.__dict__[bar] # How many arguments does it accept now? The answer to the first question *has* to be 3, or we lose too much functionality - but that's seriously surprising (the method appears to require two arguments when its defined, but actually requires 3 due to its being retrieved from a class). And it still requires that a distinction be made between instance, class and static methods in order to control the signature of the retrieved method. However, that answer creates its own problems - what if we have a 3-argument function that does exactly what we want our method to do? We'd need some way of signalling to the class that the function should be left alone when being retrieved from the class, but have the first argument bound automatically when being retrieved from an instance. This is where the Explicit is better than implicit and Practicality beats purity *both* kick in in favour of explicit self and class_ parameters - the signature of the retrieved function is exactly what the source code says it is, because there aren't any implicit parameters getting slipped into the parameter list when you aren't looking. As I see it, the real issue is that people are often coming from a Java or C++ background where you can't manipulate functions and classes as first-class objects - the idea that the instance method signature could be written to describe the signature of the unbound method returned by Foo.bar rather than the bound method returned by Foo().bar is an entirely foreign concept. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
