Python 3K or Python 2.9?

[TheFlyingDutchman]

Re: Python 3K or Python 2.9?

Well I'm with Bruce Eckel - there shouldn't be any argument for the
object in the class method parameter list. But since Python 3 was
"code-named" 3000 (implying but not delivering big changes... I don't
think it required big changes) and since it still has an explicit
object parameter it's a given that it's not gonna happen in any
revisions.

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods. But Perl does it as well.
I think the label "mainstream OO language" is as valid being applied
to Perl as it is to Python.

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.

[Wildemar Wildenburger]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an wrote:

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.
>

Isn't one of the main ideas behind python that it doesn't force you to
do (well, declare) anything? And by "ideas" I mean "design decisions".
Thats exactly what makes python great for prototyping; you just do it
and see if it works. As soon as you need to declare things you have to
change stuff in at least 2 places for every change of heart you have.

(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
currently avoiding to do, by wasting my time on usenet.))

/W

[TheFlyingDutchman]

Re: Python 3K or Python 2.9?

>
Isn't one of the main ideas behind python that it doesn't force you to
do (well, declare) anything? And by "ideas" I mean "design decisions".
Thats exactly what makes python great for prototyping; you just do it
and see if it works. As soon as you need to declare things you have to
change stuff in at least 2 places for every change of heart you have.
>
(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
currently avoiding to do, by wasting my time on usenet.))
>

But if you are looking at code you didn't write, it's nice to be able
to see all the member variables that a class has listed separate from
method code.

I think static typing helps in trying to deduce what code is doing,
particularly when you are looking at function definitions. You don't
have to work to find out what type of variables it takes.

[Stefan Bellon]

Re: Python 3K or Python 2.9?

On Thu, 13 Sep, TheFlyingDutchm an wrote:

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods.

Ada 95 does. And Ada 95 was the first standardized OO language. Now
with Ada 2005 you can either pass the the object explicitly as first
parameter (like in Ada 95) or you can call the method on the object
(like in Java, C++, Python, ...) and the object is passed implicitly.

--
Stefan Bellon

[Marc 'BlackJack' Rintsch]

Re: Python 3K or Python 2.9?

On Thu, 13 Sep 2007 10:10:57 -0700, TheFlyingDutchm an wrote:

>Isn't one of the main ideas behind python that it doesn't force you to
>do (well, declare) anything? And by "ideas" I mean "design decisions".
>Thats exactly what makes python great for prototyping; you just do it
>and see if it works. As soon as you need to declare things you have to
>change stuff in at least 2 places for every change of heart you have.
>>
>(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
>currently avoiding to do, by wasting my time on usenet.))
>>

But if you are looking at code you didn't write, it's nice to be able
to see all the member variables that a class has listed separate from
method code.

That information is usually in the `__init__()` method and the class
docstring.

I think static typing helps in trying to deduce what code is doing,
particularly when you are looking at function definitions. You don't
have to work to find out what type of variables it takes.

This should either be obvious or in the docstring.

Ciao,
Marc 'BlackJack' Rintsch

[Bruno Desthuilliers]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an a écrit :

Well I'm with Bruce Eckel - there shouldn't be any argument for the
object in the class method parameter list.

def fun(obj, *args, **kw):
# generic code here that do something with obj

import some_module
some_module.Som eClass.fun = fun

This is why uniformity is important.

But anyway, I think it's quite clear that Python won't drop the explicit
self, so it looks like you have to live with it or choose another language.

Bruce said that no other mainstream OO language is explicitly passing
the object as a parameter to class methods.

to methods. class methods gets the class as first parameter.

Anyway, there are a lot of things that Python doesn't do like "other
mainstream OO languages", and that's a GoodThing.

What I would like to have seen added to class definitions was the
forced declaration of all object variables in the class outside of
methods. I don't like the fact that they have to be, and can be
created in any method on the fly.

I definitively think you'd be happier with some other language.

[TheFlyingDutchman]

Re: Python 3K or Python 2.9?

>
(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
currently avoiding to do, by wasting my time on usenet.))
>

Maybe you can sneak Jython into the mix. Just describe it as "this
Java scripting language".

[Bjoern Schliessmann]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an wrote:

Here's a FAQ item where they refer to it as I think Python should
have done it - a special predefined variable:

Maybe. Personally, I like it the way it is in Python.

Why don't you make a preprocessor which accepts method declarations
without "self" and fixes them?

Regards,


Björn

--
BOFH excuse #135:

You put the disk in upside down.

[Wildemar Wildenburger]

Re: Python 3K or Python 2.9?

TheFlyingDutchm an wrote:

>(Can you tell I'm currently forced to developing in Java? ;) (Which I'm
>currently avoiding to do, by wasting my time on usenet.))
>>

>
Maybe you can sneak Jython into the mix. Just describe it as "this
Java scripting language".
>
>

Hehe, devious idea. I might just try that. :)

/W

[Bruno Desthuilliers]

Re: Python 3K or Python 2.9?

Bjoern Schliessmann a écrit :

TheFlyingDutchm an wrote:
>

>>Here's a FAQ item where they refer to it as I think Python should
>>have done it - a special predefined variable:

>
>
Maybe. Personally, I like it the way it is in Python.
>
Why don't you make a preprocessor which accepts method declarations
without "self" and fixes them?

The problem being that there's no such thing as a "method declaration"
in Python - only functions being attributes of a class...

(ok, I know, you meant "functions declared within a class statement").

[Terry Reedy]

Re: Python 3K or Python 2.9?


"TheFlyingDutch man" <zzbbaadd@aol.c omwrote in message
news:1189701793 .466307.93210@g 4g2000hsf.googl egroups.com...
| Here's a FAQ item where they refer to it as I think Python should have
| done it - a special predefined variable:
|
| http://www.faqs.org/docs/javap/c5/s5.html
|
| "Java provides a special, predefined variable named "this" that you
| can use for such purposes. The variable, this, is used in the source
| code of an instance method to refer to the object that contains the
| method. This intent of the name, this, is to refer to "this object,"
| the one right here that this very method is in. If x is an instance
| variable in the same object, then this.x can be used as a full name
| for that variable. If otherMethod() is an instance method in the same
| object, then this.otherMetho d() could be used to call that method.
| Whenever the computer executes an instance method, it automatically
| sets the variable, this, to refer to the object that contains the
| method."

In Python, methods are (functions) contained in (are attributes of)
classes. Hence, by the above, 'this' or 'self' would be set to the class
and not the instance. So the above would require some rewording for
Python.

[Bjoern Schliessmann]

Re: Python 3K or Python 2.9?

Bruno Desthuilliers wrote:

Bjoern Schliessmann a écrit :

>Why don't you make a preprocessor which accepts method
>declarations without "self" and fixes them?

>
The problem being that there's no such thing as a "method
declaration" in Python

Yep, there are only definitions. I'm sorry.

- only functions being attributes of a class...

What, IYHO, is the difference between a method and a function?

(ok, I know, you meant "functions declared within a class
statement").

I think that those functions _are_ special ones since the compiler
is able to make "method(instanc e, a, b)" out of
"instance.metho d(a, b)". So IMHO, "method definition" makes sense.

Regards,


Björn

--
BOFH excuse #144:

Too few computrons available.

[Steven D'Aprano]

Re: Python 3K or Python 2.9?

On Thu, 13 Sep 2007 20:59:06 +0200, Bjoern Schliessmann wrote:

TheFlyingDutchm an wrote:

>Here's a FAQ item where they refer to it as I think Python should have
>done it - a special predefined variable:

>
Maybe. Personally, I like it the way it is in Python.
>
Why don't you make a preprocessor which accepts method declarations
without "self" and fixes them?

If you look at the thread "parameter list notation" from ten days or so
ago, TheFlyingDutchm an has forked Python and is working on a very special
new language, PIEthun 3.01B. I for one am looking forward to seeing all
the very special features of PIEthun.



--
Steven.

[Aahz]

Re: Python 3K or Python 2.9?

In article <874phz5i9n.fsf @benfinney.id.a u>,
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

>
>Specifically an easier way of doing it provided by the language syntax
>(hence "syntactic sugar"). As in, "the form 'foo += 1' is syntactic
>sugar for 'foo = foo + 1'".

Except, of course, that it isn't, quite. ;-)
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer

http://www.lysator.liu.se/c/ten-commandments.html

[Aahz]

Re: Python 3K or Python 2.9?

In article <1i4bm7a.1s51u5 91kreqe4N%aleax @mac.com>,
Alex Martelli <aleax@mac.comw rote:

>Chris Mellon <arkanes@gmail. comwrote:

>>
>and I'll punch a kitten before I accept having to read
>Python code guessing if something is a global, a local, or part of
>self like I do in C++.

>
>Exactly: the technical objections that are being raised are bogus, and
>the REAL objections from the Python community boil down to: we like it
>better the way it is now. Bringing technical objections that are easily
>debunked doesn't _strengthen_ our real case: in fact, it _weakens_ it.
>So, I'd rather see discussants focus on how things SHOULD be, rather
>than argue they must stay that way because of technical difficulties
>that do not really apply.
>
>The real advantage of making 'self' explicit is that it IS explicit, and
>we like it that way, just as much as its critics detest it. Just like,
>say, significant indentation, it's a deep part of Python's culture,
>tradition, preferences, and mindset, and neither is going to go away (I
>suspect, in fact, that, even if Guido somehow suddenly changed his mind,
>these are issues on which even he couldn't impose a change at this point
>without causing a fork in the community). Making up weak technical
>objections (ones that ignore the possibilities of __get__ or focus on
>something so "absolutely central" to everyday programming practice as
>inspect.getarg spec [!!!], for example;-) is just not the right way to
>communicate this state of affairs.

While you have a point, I do think that there is no solution that allows
the following code to work with no marker distinguishing the local bar
from the instance's bar; the only question is how you want to mark up
your code:

class C:
def foo(self, bar):
print bar, self.bar

x = C()
x.bar = 'abc'
x.foo()

From that standpoint, there is a technical objection involved. Of
course, the solution can be any of a number of different marker systems
(or even choosing to have no marker and not permit a method to access
both object attributes and locals of the same name), and Python has
chosen to force the use of a marker for all object attributes, while also
choosing to have disjoint namespaces WRT globals and locals for any one
name.
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer

http://www.lysator.liu.se/c/ten-commandments.html