Weblogs Forum - Python 3K or Python 2.9?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Python 3K or Python 2.9?

62 replies on 5 pages. Most recent reply: May 8, 2008 9:17 AM by David Johnson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 62 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Python 3K or Python 2.9?

Posted: Sep 14, 2007 1:01 PM

Dale,

We are not complaining about the prefix aspect, which -- as you point out -- is a necessary evil in most OO languages, but about the fact that we need to specify self as the first parameter of all the member methods.

There are usually two reasons why this constraint is disliked:

- It introduces a lot of useless noise.
- It creates the appearance that the method should be invoked with n parameters while it should only be n-1.

--
Cedric

Yair C.

Posts: 1
Nickname: yairchu
Registered: Sep, 2007

concurrency and rpyc

Posted: Sep 14, 2007 7:11 PM

if you want concurrency for performance / parallelization,
you should take a look at rypc - the "transparent" python library for distributed computing.
rpyc.wikispaces.com

Luciano Ramalho

Posts: 3
Nickname: ramalho
Registered: Jun, 2007

About self

Posted: Sep 15, 2007 9:07 AM

I used to bash Python's use of explicit self, and after learning Ruby I wrote a similar rant about how that language handled this issue better. But recently I learned an idiom that shows the value of Guido's position in this regard:

cc_number = ''.join(filter(str.isdigit, cc_number))

If self was not explicit in the definition of the isdigit method, the call above could only work through majyk.

Unlike Ruby, Python does not want to be a "pure" OO language (whatever that means). Python is a multi-paradigm or paradigm-agnostic language, and that is something that many of us like about it. The explicit use of self makes the OO and the functional styles work well together.

Steve Simmons

Posts: 5
Nickname: scs
Registered: Sep, 2007

UI shouldn't be part of the language

Posted: Sep 16, 2007 1:35 PM

IM-not-so-HO, UI should not be part of the language. At the moment there seem to be three popular ways of doing it - via library, via VM, and via UI embedded languages. To my knowledge, no open-source cross-platform UI language has ever attained enough users to hit critical mass, certainly none have enough open-source support to even be a contender. I'll therefore ignore UI embedded languages for the rest of this response.

I don't think significant UI components should be placed into a general-purpose language. It complicates the language, and leads to endless demarcation problems. Putting the UI support in an external entity, be it library or VM, avoids the whole problem.

I had a bunch of verbiage here about the long and difficult problems that led to the various language-specific forks of tk, but ultimately it's irrelevant to my main point: there are far more successes for languages using external UI packages than for ones that bake the UI support into the language.

Brandon Corfman

Posts: 14
Nickname: bcorfman
Registered: Aug, 2003

Re: Python 3K or Python 2.9?

Posted: Sep 17, 2007 7:33 AM

Yes, you could use 'm', 's' or any other abbreviation instead of self. But this is ridiculous: the accepted convention is 'self', and if I decide to use some personal shortcut to abbreviate it, then I've made my code unreadable to others besides myself. Whatever abbreviation there is needs to be part of the accepted language convention, or it's worthless.

An abbreviation also doesn't address the goofy need for 'self' to be the first parameter in every class method (and the cryptic error when I don't include it).

Jim Kleckner

Posts: 1
Nickname: jkleckner
Registered: Sep, 2007

Re: Python 3K or Python 2.9?

Posted: Sep 17, 2007 9:46 AM

> Unfortunately the chances for getting rid of the GIL
> seem to be the same as the chances of Stackless getting
> merged.

What are the biggest issues facing getting stackless merged?

(probably deserves it's own thread).

Larry H.

Posts: 3
Nickname: larzluv
Registered: Sep, 2007

Re: Python 3K or Python 2.9?

Posted: Sep 19, 2007 12:09 AM

Morel Xavier posted:

> > Why don't we use just a leading dot?
> > As .foo instead of self.foo?
> >
> Because it's horrible and unreadable?
>

As I've often thought this would be a suitable solution - still explicit, yet less typing - I wonder if you could elaborate on your though(s) as to why this would be "horrible and unreadable"?

Thank you for your time.
-Larry

ian o

Posts: 8
Nickname: iano
Registered: Aug, 2007

Re: Python 3K or Python 2.9?

Posted: Sep 19, 2007 6:53 AM

A problem with the idea of a . is that it doesn't stand out enough. Some editors even display spacing or tabbing using dots that could be mistaken.

There are two arguments here 1) something shorter to type, and 2) explicit self in function definitions (which are typed far less often than the self.foo )

1) the something shorter to type (like ruby) has some merit, and if an alternate convention or even new syntax was agreed it could good but personally i would hate to see the object.property pattern broken as it would be inconsistent. That only leaves three characters to save if a one character symbol could be found as an alternative to self. The ~ would be my suggestion... allow a ~ to be used as a single character identifier and sanction it as a convention. It sort of fits with the home paradigm as an abbreviation :)
Certainly better than an '@' and with the . still required ideally.... this is only making ~ a legal identifier after all!

There would actually be no clash with existing ~ operator to allow this so it could be considered for any release as an addition not requiring a break to backward compatibilty.

Whilst the syntax rules to avoid confusion with the ~ operator Nothing about this idea that requires being in python 3.0 as it is adding something, not breaking old code and self still valid.

now for 2 - the explicit 1st parameter.
Well...it IS a real parameter, and can be explictly in the call: just use class.method in place of instance.method and you can put the self in the parameter list. There is a lot of sense to the current rule. But it still is easy to forget when typing...if there was a way to warn for the error when a routine is called and try and allow the program to run in the cases when the runtime could really see what the problem is ...would that help? Program would still need to be as they are now to run warning free.... or perhaps issue a warning each for each non static method that doesnt have 'self' ( or '~' ) as the first parameter??

Self really IS the first parameter so there is logic for leaving it there...if we could perhaps either pick up earlier when it was forgotten would that be a worthy compromise?

Mike Cheponis

Posts: 2
Nickname: nickname99
Registered: Jun, 2007

Re: Python 3K or Python 2.9?

Posted: Sep 21, 2007 4:53 PM

I believe that concurrency is indeed the major issue of our time, and it must be addressed.

But another important area is: which bundled GUI?

At the moment, the answer is Tk, but it seems to me that wxWidgets or maybe Qt needs to be the "default".

There should be a rich, robust, powerful, and _consistent_ GUI built-it for the Mac, PC, and Unix.

After all, "batteries included" right?

-Mike

Adam Olsen

Posts: 11
Nickname: rhamph
Registered: Jun, 2007

Re: Python 3K or Python 2.9?

Posted: Sep 21, 2007 6:35 PM

> I believe that concurrency is indeed the major issue of
> our time, and it must be addressed.

Concurrency may be the major issue of our time, but I expect the best solutions will be those with the least impact on existing practices. This implies all the panic and grand schemes will be completely off mark.

After all, we can use multicore today. We only want to make it easier because we expect to be doing it more often.

Greg Hazel

Posts: 1
Nickname: ghazel
Registered: Sep, 2007

Re: Python 3K or Python 2.9?

Posted: Sep 23, 2007 9:35 PM

> <p>One solution I can imagine that might work is to take
> the BeOS operating system's approach, which is to make
> creating OS processes very easy. If there's no way to get
> rid of the GIL even in Python 3K (but there might be a
> way, given enough language changes), then perhaps it would
> be possible just to create a new Python image in another
> process, and make it easy to communicate with that
> process. Thus, creating an agent would create an OS
> process, and communicating with the agent would actually
> send messages through OS pipes.</p>

Have you seen the "processing" module?

http://cheeseshop.python.org/pypi/processing/0.34

Juergen Brendel

Posts: 8
Nickname: jbrendel
Registered: Sep, 2007

Re: Python 3K or Python 2.9?

Posted: Sep 23, 2007 11:01 PM

> Have you seen the "processing" module?
>
> http://cheeseshop.python.org/pypi/processing/0.34

Yes, I have had a chance to take a quick look at it. I might do some more testing at another time. The API is very nice and easy. Using queues to communicate between processes works well, but only if you have a shared-nothing architecture.

Using the example from the project's home page, I created a couple of more processes on a Debian Linux machine. The Queue used there blocks if 10 elements are in the queue, which is very different behaviour than in the threading queue. So, unless you pick up often, the sender will block trying to add to the queue.

This can be avoided using PosixQueues (more explicitly). But if you write a lot of items to that queue, the file system is exercised like crazy, leading to bad performance, eventually paging and even system crashes. Again, you need to pick up often to avoid that.

The communication overhead is significant using IPC the way processing does. So, sending anything between processes will be much slower than using a queue between threads.

Again, the first impression of 'processing' is very good. I think the author is really on to something. But considering that I was able to hang my system to the point of having to power-cycle it, I can't say that it is currently very user friendly or robust, yet.

I'm sure it can be improved, though. I will try to do some more testing at a later time, so that we can quantify this a bit better.

Larry H.

Posts: 3
Nickname: larzluv
Registered: Sep, 2007

Re: Python 3K or Python 2.9?

Posted: Sep 26, 2007 4:28 AM

Thanks for the reply, Ian.

I'd suspected the "doesn't stand out enough" was a major reason. I'd thought about it myself. *Syntactically*, I find ".attribute" good, but *visually*... :/ :>

I like the "~.attribute" concept. I'd noted someone earlier mentioned they often use an underscore ("_.attribute"/"( _, param...)"); I'd neglected to notice this was even valid. (Finding this concept dubious, I even tried it out - worked fine! ;)

Either way, the "so much typing" is less of a gripe.

I still have an issue with the explicit self; to me, though obviously (*REPEATEDLY*! ;) not to the BDFL, it seems un-pythonic in my book.

That it's in the signature makes sense. (And allows one the freedom/flexibility to use any identifier one wishes, though "self" is de facto.) The parent object is being passed to our method.

Okay, fine.

But this is via "magic", and is one of those points that has to be "learnt" in Python. Every py-book, regardless of level, has taken time to make this point, and to try to "sell" the concept. Obviously, if it's non-obvious, perhaps it is "broke"?

Further, I'd find a "magical" special name, like "__self__". (Though I think "__inst__"/"__instance__" would be more correct, as "__self__" should, to my mind, be an object handle for the item in question, like the method/function; haven't though of a creative class variable to refer to the owner class, and "__class__" refers to the item in question.)

At any rate, thanks again, and, as always, just my $0.05. (Inflation, don'tcha-know!? ;)

-Larry

Harry Smith

Posts: 2
Nickname: shantoruk
Registered: Oct, 2007

Re: Python 3K or Python 2.9?

Posted: Oct 28, 2007 2:56 AM

The GUI issue and context-sensitive editing are quite nicely solved by Boa Constructor (which uses wxPython).

Bill Manaris

Posts: 4
Nickname: manaris
Registered: Nov, 2007

Re: Get rid of self

Posted: Nov 27, 2007 4:00 AM

Getting rid of self should be straightforward:

Have the Python reader automatically insert a self reference to any function defined within a class block.

In other words, have the <FUNCTION-WITHIN-CLASS> grammar rule, within its action, insert a <SELF> token where it's needed in the internal representation used by the evaluator.

Flat View: This topic has 62 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Previous Topic

Next Topic