The Artima Developer Community
Sponsored Link

Weblogs Forum
Python 3K or Python 2.9?

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

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 62 replies on 5 pages [ « | 1 2 3 4 5 | » ]
Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 2:03 PM
Reply to this message Reply
Advertisement
I'll blog more in response to this post later, but I have just blogged about the GIL in response to another blog pleading for its removal. Here it is: http://www.artima.com/weblogs/viewpost.jsp?thread=214235

Bruce Eckel

Posts: 868
Nickname: beckel
Registered: Jun, 2003

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 3:05 PM
Reply to this message Reply
I am not asking for the removal of the GIL (which may actually be impossible to get rid of), but we do need some kind of solution to the concurrency problem.

Brandon Corfman

Posts: 14
Nickname: bcorfman
Registered: Aug, 2003

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 3:15 PM
Reply to this message Reply
> But this scoping is explicit in Ruby as well; you merely
> say @foo instead of self.foo
>
> I understand preferring @foo (even though I personally
> prefer self.foo), but it doesn't seem terribly different
> to me.

The problem is that the 'self' plague doesn't stop there ... don't forget that self is required as the first parameter of every class method. For example, the following code that forgets to use self as the first parameter of printInfo:


class MyClass(object):
def printInfo(s):
print s

def main():
m = MyClass()
m.printInfo('Hello')

When running main, you get the following traceback from Python:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "hello.py", line 7, in main
m.printString('Hello')
TypeError: printString() takes exactly 1 argument (2 given)

Except I am giving one argument! What second one is it talking about? Oh yes, the interpreter is expecting 'self'. Totally confusing and brain-dead requirement. Why does this need to be the first parameter of every class method?

Brandon Corfman

Posts: 14
Nickname: bcorfman
Registered: Aug, 2003

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 3:22 PM
Reply to this message Reply
On Bruce's original post ... I must admit -- I am rather lost by the motivations of Python 3000 too.
There are some warts on the Python 2.x series, but this doesn't seem like a total overhaul for consistency, beginner friendliness, or making things more object-oriented (e.g. len as part of an object, eliminating self as the first argument of class methods as described above, getting rid of the 'if __name__ == "__main__": main()' clumsiness for executing a script). Instead we've gotten highly controversial changes like making print a function, which was roundly booed during the Py3K keynote at EuroPython.

Bottom line, Py3K is much less ambitious than I would've thought, and therefore seems nice but pretty pointless (except for all Unicode strings, which is a terrific idea). Of anything going on, I would've thought that throwing support entirely behind PyPy would be a better route (and its associated support for speed and concurrency) than this current idea.

What I find upsetting at the same time is Guido's citation (http://www.python.org/dev/peps/pep-3000/) of a Joel Spolsky article (see at the bottom of the PEP) as the motivation for not rewriting Python from scratch. The lessons of Joel's story aren't quite the same ... wouldn't it make much more sense to switch to a new codebase like PyPy's in the long run? Make one major rewrite of your C-based extensions into Python syntax, have them all translated into RPython, and be done? Plus get JIT/multicore/multithreading/Stackless support for free? (Christian Tismer et. al. have written superior Python versions twice now, and they still get no respect.)

Without proper support for multiprocessing or multithreading in the language, I think this Py3K "rewrite" effort could be the beginning of the twilight for Python. There is the opportunity to change the entire language to correctly deal with future hardware requirements, and the choice is being made for it to remain a limited, single-processor, C-based scripting language. This is a huge, huge mistake.

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 4:24 PM
Reply to this message Reply
> On Bruce's original post ... I must admit -- I am rather
> lost by the motivations of Python 3000 too.

This comment is so full of FUD that I simply have to respond.

> There are some warts on the Python 2.x series, but this
> doesn't seem like a total overhaul for consistency,
> beginner friendliness, or making things more
> object-oriented (e.g. len as part of an object,
> eliminating self as the first argument of class methods as
> described above,

Talk to any regular Python user, and they would explain that they *want* those things to remain. (Bruce apparently has lost his touch too, perhaps due to over-exposure to Java.)

> getting rid of the 'if __name__ ==
> "__main__": main()' clumsiness for executing a script).

Various proposals have been put forward to improve this, but they all make things worse in other areas. FWIW, you don't have to use this idiom -- it's only customary in scripts that do double duty as importable modules.

> Instead we've gotten highly controversial changes like
> making print a function, which was roundly booed during
> the Py3K keynote at EuroPython.

Eh? In Vilnius this year it was applauded. Maybe you're thinking of last year's EuroPython at CERN?

> Bottom line, Py3K is much less ambitious than I would've
> thought,

Armchair language designers have it easy. We had to balance carefully between too much and not enough innovation, in order to get existing users to support the new version. I challenge you to come up with a fork of the language that will be more popular.

> and therefore seems nice but pretty pointless
> (except for all Unicode strings, which is a terrific
> idea).

And indeed it is one of the driving forces for Py3k -- a lot of the rest is minor cleanup in comparison.

> Of anything going on, I would've thought that
> throwing support entirely behind PyPy would be a better
> route (and its associated support for speed and
> concurrency) than this current idea.

That's up to the users. There are multiple implementations of Python; users can choose which one to use. But in terms of readiness for deployment and availability of extensions, PyPy has a long way to go before it's more than a research project. I am hoping that the PyPy folks will find a way to succeed, so I can retire, but in the mean time, I simply don't think it's ready yet.

> What I find upsetting at the same time is Guido's citation
> (http://www.python.org/dev/peps/pep-3000/) of a Joel
> Spolsky article (see at the bottom of the PEP) as the
> motivation for not rewriting Python from scratch. The
> lessons of Joel's story aren't quite the same ...

Eh? What do *you* see as the lesson from that story, if not a strongly-worded warning against total rewrites?

> wouldn't
> it make much more sense to switch to a new codebase like
> PyPy's in the long run?

In the very long run, probably. Not in time for next August though. You can consider CPython as a prototype implementation for Py3k if you like.

> Make one major rewrite of your
> C-based extensions into Python syntax, have them all
> translated into RPython, and be done? Plus get
> JIT/multicore/multithreading/Stackless support for free?
> (Christian Tismer et. al. have written superior Python
> versions twice now, and they still get no respect.)

I don't think Tismer sees it that way; he is well aware of Stackless's limitations (and its repeated reinventions suggest that it wasn't quite superior from the start).

FWIW Stackless does *not* remove the GIL -- it just removes the C stack (in most but not all places).

> Without proper support for multiprocessing or
> multithreading in the language, I think this Py3K
> "rewrite" effort could be the beginning of the twilight
> for Python.

I've heard that prediction before. I'm still standing.

> There is the opportunity to change the entire
> language to correctly deal with future hardware
> requirements, and the choice is being made for it to
> remain a limited, single-processor, C-based scripting
> language. This is a huge, huge mistake.

Eh? The language doesn't restrict you in that way at all, only the CPython VM does. All implementations *except* CPython support multi-processor architectures just fine. I'm still waiting for any of them to conquer the world.

Bruce Eckel

Posts: 868
Nickname: beckel
Registered: Jun, 2003

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 5:01 PM
Reply to this message Reply
> (Bruce apparently has lost his touch too, perhaps due to
> over-exposure to Java.)

Trust me, over-exposure to Java has done nothing but drive me further into the comfortable arms of Python. Or should I say "comfortable coils." I certainly still love Python, I just want it to be better. And concurrency is the biggest opportunity, IMO. See my comment on Guido's GIL post regarding what I'm willing to do about it.

Brandon Corfman

Posts: 14
Nickname: bcorfman
Registered: Aug, 2003

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 5:20 PM
Reply to this message Reply
> Talk to any regular Python user, and they would explain
> that they *want* those things to remain. (Bruce
> apparently has lost his touch too, perhaps due to
> over-exposure to Java.)

Well, adding to Bruce and myself, Artima's recent article on "Python pain points" had four folks commenting on how they hated 'self'. Titus Brown's article on "5 things I hate about Python" had a fair number of complaints about 'self' as well, so much so that he actually comments "I'm impressed by how many people seem to hate 'self'." (since he personally likes it). A couple more Python users (including Bill de hOra) on jacobian.org's "Five Things I Hate about Python" commented that they hate 'self'.

I'm not saying it's not needed ... obviously you need to designate scope inside your class methods. But I've actually seen people do 'item = self.item' inside their methods and then use the local variable instead just so they don't have to keep using 'self.' everywhere. That's a problem. Either it needs to be shorter, like Ruby's '@' symbol, or you need some other more convenient method to designate scope.

> > getting rid of the 'if __name__ ==
> > "__main__": main()' clumsiness for executing a script).
>
> Various proposals have been put forward to improve this,
> but they all make things worse in other areas. FWIW, you
> don't have to use this idiom -- it's only customary in
> scripts that do double duty as importable modules.

Obviously you disagree with me on this, but I think virtually any of the PEP 0299 (http://www.python.org/dev/peps/pep-0299) or 3122 (http://www.python.org/dev/peps/pep-3122) proposals were an improvement over the current method.

> > Instead we've gotten highly controversial changes like
> > making print a function, which was roundly booed during
> > the Py3K keynote at EuroPython.
>
> Eh? In Vilnius this year it was applauded. Maybe you're
> thinking of last year's EuroPython at CERN?

I read this information online and apparently got the year incorrect. Sorry for the confusion.

> > Bottom line, Py3K is much less ambitious than I
> would've
> > thought,
>
> Armchair language designers have it easy. We had to
> balance carefully between too much and not enough
> innovation, in order to get existing users to support the
> new version. I challenge you to come up with a fork of
> the language that will be more popular.
>
Yes, I'm one of the Python users who doesn't have the luxury of hanging out on python-dev or contributing to the rewrite. I have a job where I try to use the language itself and contribute by introducing it into the organizations where I've had jobs over the past several years. I would think this qualifies me to make at least some basic comments on its direction.

> That's up to the users. There are multiple
> implementations of Python; users can choose which one to
> use. But in terms of readiness for deployment and
> availability of extensions, PyPy has a long way to go
> before it's more than a research project. I am hoping
> that the PyPy folks will find a way to succeed, so I can
> retire, but in the mean time, I simply don't think it's
> ready yet.
>
I know it's not ready yet, but it's going to take some support from python-dev to get there. There needs to be some recognition that it is a improved direction for Python in a multicore world, and it is also freedom from the treadmill of upgrading C-based extensions with every new Python version. Not to mention the eventual speed gains from JIT compilation. This is going to require support to make that happen. Who wants another fork, for goodness sake? You set the standard for the language -- who wants to be trying to play catch-up with the current language implementation. That is the curse of Jython and IronPython.

> Eh? What do *you* see as the lesson from that story, if
> not a strongly-worded warning against total rewrites?
>
I see a lesson against rewrites if there is no longer-term vision that requires the rewrite. In other words, you can't get to a multicore/multi-threaded Python implementation the way Python is currently coded with its C-based libraries. The GIL is almost a necessity because of the current design. That's why changing the architecture is necessary. I wouldn't advocate a total rewrite if the PyPy guys hadn't already done the proof-of-concept. They released 1.0. It's time to support them.

> > wouldn't
> > it make much more sense to switch to a new codebase
> like
> > PyPy's in the long run?
>
> In the very long run, probably. Not in time for next
> August though. You can consider CPython as a prototype
> implementation for Py3k if you like.
>
> > Make one major rewrite of your
> > C-based extensions into Python syntax, have them all
> > translated into RPython, and be done? Plus get
> > JIT/multicore/multithreading/Stackless support for
> free?
> > (Christian Tismer et. al. have written superior Python
> > versions twice now, and they still get no respect.)
>
> I don't think Tismer sees it that way; he is well aware of
> Stackless's limitations (and its repeated reinventions
> suggest that it wasn't quite superior from the start).
>
> FWIW Stackless does *not* remove the GIL -- it just
> removes the C stack (in most but not all places).
>
I'm just saying that PyPy is a foundation for the multicore/multithreading hardware changes in the future, whereas CPython can't escape the GIL due to its design.

> > Without proper support for multiprocessing or
> > multithreading in the language, I think this Py3K
> > "rewrite" effort could be the beginning of the twilight
> > for Python.
>
> I've heard that prediction before. I'm still standing.
>
Of course, this is the beginning of the dual-core and quad-core era. Check back in 5-10 years. By then, it will be too late to change direction.

> > There is the opportunity to change the entire
> > language to correctly deal with future hardware
> > requirements, and the choice is being made for it to
> > remain a limited, single-processor, C-based scripting
> > language. This is a huge, huge mistake.
>
> Eh? The language doesn't restrict you in that way at all,
> only the CPython VM does. All implementations *except*
> CPython support multi-processor architectures just fine.
> I'm still waiting for any of them to conquer the world.

Again, CPython is the standard. Who wants to throw their support behind a fork. There's no need to fragment the Python world, unless you really want it to happen.

Paul Boddie

Posts: 26
Nickname: pboddie
Registered: Jan, 2006

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 5:44 PM
Reply to this message Reply
David Vydra wrote: "I am beginning to think that JRuby will propel Ruby to new heights because it will give it all of the benefits of running in a JVM (libraries/app servers) and access to its threading facilities. Scala also runs in both JVM and .NET. Why not take the same approach to Python 3K?"

Well, Jython (formerly JPython) has been around for ten years or so. Here's the JPython 1.0 press release:

http://press.oreilly.com/pub/pr/699

Perhaps the JVM is a re-emerging platform now that Java the language has less favour with those talking up the trends. As for "new heights" and "app servers" on the JVM, the peaks in question are usually associated with CPU and memory usage, whilst improving virtualisation technology seems a real threat to whatever differentiating edge the Java platform may once have had.

Paul Boddie

Posts: 26
Nickname: pboddie
Registered: Jan, 2006

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 5:57 PM
Reply to this message Reply
Brandon Corfman wrote...


> Eh? In Vilnius this year it was applauded. Maybe you're
> thinking of last year's EuroPython at CERN?

I read this information online and apparently got the year incorrect. Sorry for the confusion.


I don't remember the print function being booed at either CERN or in Vilnius and I was there on both occasions. I don't think it's a compelling change to the language given what has already been said about not using the print statement in serious programs anyway, but even if the booing was my inner voice which you somehow managed to record (which it wasn't, since I maintained perfect inner calm!), it wouldn't qualify as anything having been "roundly booed" in any case. ;-)


Yes, I'm one of the Python users who doesn't have the luxury of hanging out on python-dev or contributing to the rewrite. I have a job where I try to use the language itself and contribute by introducing it into the organizations where I've had jobs over the past several years. I would think this qualifies me to make at least some basic comments on its direction.


I agree with you here, at least. That said, you'd look a lot better in a duel with the BDFL with some code to show.


Again, CPython is the standard. Who wants to throw their support behind a fork. There's no need to fragment the Python world, unless you really want it to happen.


This sounds like the usual faint praise of any Python implementation which isn't CPython. If you want a "team victory" the last thing you do is pull the best-placed team members out of the race and shout louder at the one bringing up the rear.

Perhaps, as one of the CERN guys said, we need a conservative Python standard which encourages platform development, not language development, but I'm quite happy to see people keep up what they've been doing with the different implementations.

Berco Beute

Posts: 72
Nickname: berco
Registered: Jan, 2002

Re: Python 3K or Python 2.9? Posted: Sep 10, 2007 6:02 PM
Reply to this message Reply
Although I agree with most of your post (as far as I can judge anything to do with GIL), I disagree with the issues you have with your self. I learned the necessity of self and got to love my self!

Kidding aside, my experience is that the use of self makes it explicit what type of scope we're dealing with. This outweighs the burden of the extra keystrokes.

Vladimir Roudnev

Posts: 1
Nickname: roudnev
Registered: Sep, 2007

Re: Python 3K or Python 2.9? Posted: Sep 11, 2007 1:01 AM
Reply to this message Reply
> Either it needs to be shorter, like Ruby's '@'
> symbol, or you need some other more convenient method to
> designate scope.

I agree that distinguishing class variables from the locals is a good idea. It is especially useful for the languages that do not have an explicit variable declaration.
Why don't we use just a leading dot?
As .foo instead of self.foo?

But I still can not appreciate the necessity to refer to the self argument in every method: does it make sense to declare an argument which should actually be omitted when the method is called? I have convinced myself that it might be a dirty hack used to implement classes for the first time, but this is nothing I would miss in the language I actualy use...

Nick Evgeniev

Posts: 16
Nickname: nevgeniev
Registered: Aug, 2007

Re: Python 3K or Python 2.9? Posted: Sep 11, 2007 2:15 AM
Reply to this message Reply
Would someone explain me what is the relation of GIL and language concurrency support?

I don't see any. GIL is implementation detail nothing more.

What is the real problem is that python has no concurrency support in language itself neither in java way (locks, concurrent data structures), nor erlang way (message passing, surprise but erlang runtime has *one* scheduler runnning by default), nor haskel way (via atomic keyword).

This is the *real* problem. I can move to jython or ironpython but I still have no support from language. that's it. if you're in demand of writing concurrent program python is not your friend.

Hence, personally, I don't care about GIL - getting rid of it solves nothing.

Morel Xavier

Posts: 73
Nickname: masklinn
Registered: Sep, 2005

Re: Python 3K or Python 2.9? Posted: Sep 11, 2007 3:30 AM
Reply to this message Reply
> 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.
>

The problem here is that it would block quite fast: the Agent model of computation
means that everything works through messages, so you use a lot of processes
and send a lot of messages.

I think an evolved Stackless/Erlang (pre R11B) approach would be a better
idea: provide lightweight *processes* that don't share memory (agents)
and then dynamically map them onto multiple OS processes.

The OS process is an implementation detail (that would be used to
bypass the GIL in CPython), making the actual concurrency semantics
of Python independant from the hardware, OS or implementation means
that e.g. Jython could implement Python processes as mapping over
hardware threads instead of processes and could maybe optimize things
accordingly.

> That's just one suggestion, but the problem needs to be
> solved or some other dynamic language will solve it, and
> we'll be forced to go to that language in order to use all
> the cores that are becoming available (Scala agents have
> already produced what seems to be the best solution
> around, especially because Scala has tried to solve the
> syntax-horror problems that plague traditional functional
> languages -- and yes, before you write, I've looked at
> Erlang, which is great at solving some problems but it
> isn't the future that Scala promises).
>

I don't understand, Agents are exactly what Erlang uses, even though
it doesn't call them that, and the agents-manipulating syntax of Erlang
is *much* better than Scala's, if only because the language was built around
agents and concurrency concepts.

(and what syntax-horror problems do you see in e.g. erlang?)

> Eggs and Easyinstall Standardized
>
> I'm hoping that this is just an issue of "waiting
> for maturity," but we need to make support for Python
> Eggs and Easyinstall part of the python distribution. Easy
> installation and update of library components should not
> require effort or be a distraction.
>

Yes. And I think EasyInstall is completely flawed in that regard.

It plain and simply doesn't work.

This is one field where we should take everything we can from Ruby,
because Ruby's gems work *much* better than Python's eggs, they're simpler
to use, simpler to create, simpler to manage (install, update or remove) and
the command-line utility is easier to remember and type (use "gem" to install
"gems" versus use "easy_install" to install "eggs"... makes sense to you?
Because it sure doesn't to me.)

Easy install is crap, it should be scrapped and completely redone in a much
more gem/apt-get/port manner.


> Support for DSL Creation
>
> Although Domain-Specific Languages (DSLs) have
> gotten a lot of press lately, creating little languages to
> solve specific problems has always been one of the more
> powerful weapons in a programmer's toolbox (the
> Interpreter design pattern is an example of
> this). This is another area where Ruby has a leg up,
> although in the grand scheme of things Ruby's DSL support
> is fairly limited.
>

I strongly disagree here. Creating DSLs is a pattern that doesn't exist
in Python and has no reason to. Most Python users doesn't work that way
and don't have a reason to, other languages (Ruby maybe, but Haskell even
more so) are great at building DSLs, but that doesn't mean DSLs are the
end-of-it-all and should be everywhere. Some languages solve their problems
through the use of Domain Specific Languagess, others solve their problems
through the use of Domain Specific Libraries.

Python is undoubtedly the latter.

I don't have a problem with that, I have more of a problem with all those
little things that make semi-meta programming in Ruby much easier, such
as classes existing within their definition (Ruby class objects exist from
the moment where you hit "class Foo", Python's seem to only start existing
at the end of class definitions), which would make metaprogramming cleaner
and easier.

> But Ruby -- and they argue that it's even more dynamic
> than Python -- doesn't have self. Nor do any of the other
> dynamic languages that I know of.
>

Sure do, they don't have an explicit self argument to methods, on the
other hand.

And this can be confusing, as Ruby's `self` can refer to both instances
and classes, too, depending on the scope you're in (in the classdef
scope `self` points to the Class object, in methods it points to instance
objects).

> How exactly would Python (or any dynamic language) work
> without "self" (or equiv). Note, I haven't used Ruby
> beyond "hello world".
>

Ruby has `self`, and it has an `@` prefix for instance variables
(@foo is the `foo` instance variable), what it doesn't have is explicit
`self` argument

> I would have thought "self" is a fairly important aspect
> of being able to create instances of objects without
> having to declare them upfront.
>

Yeah but most people's problem is with having to declare an explicit `self`
argument to Python methods. `self` and `cls` could very well become keyword and
become implicit in-scope accessors of instancemethods and classmethods.

> Also, the lack of a Rake-like tool hurts badly. I'm
> currently writing my own custom commands using setuptools
> in setup.py, and it works, but it's much more involved and
> verbose than writing Rake tasks. How can I easily build
> my docs, or run my tests? It's too much work.
>

There's SCons, seems not that bad, but I'm not sure it supports tasks
(such as running tests or starting servers or whatever), it seems very
file-construction oriented (I haven't looked at it that much though,
may very well have missed it).

Other than that, it seems fairly clean and quite pythonic.

> You can't do "rake
> install rails" on a clean system and then start developing
> (or maybe you can now?)
>

`rake` is a build tool, to install rails you use `gem`, the Ruby packaging
tool.

And sure you can do that, you've been able to do that for a *very* long time.

You just need to have both Ruby and Gem (come together in the Windows install,
on my mac I just had to `port install ruby && port install rb-rubygems`, then
`gem install rails -y` to install rails and all its dependancies, done)

> , but you can do "easy_install
> plone" or "easy_install grokproject" and get a complete
> system.

No you can't, last time I checked easy_install was not part of the Python
distribution.

Not to mention, of course, the problem of not being able to update all my
eggs via a simple command (in ruby, it's as simple as `gem update`).

> But this scoping is explicit in Ruby as well; you merely
> say @foo instead of self.foo
>
> I understand preferring @foo (even though I personally
> prefer self.foo), but it doesn't seem terribly different
> to me.
>

The problem is not with `self` as a scoping determinator,
name resolution indicator or namespace, it's with having to define `self`
as an explicit method argument.

> len as part of an object
>

That doesn't make the language "more object oriented".

> eliminating self as the first argument of class methods as
> described above

Neither does that one, it merely changes the syntax

> getting rid of the 'if __name__ ==
> "__main__": main()' clumsiness for executing a script)

That's only needed if your script can be imported as the toplevel code
is run then and you have to differentiate between import and regular run.

If the script is never run or never imported, you don't need it and are
merely a case of Cargo Cult Programming.

> I agree that distinguishing class variables from the
> locals is a good idea. It is especially useful for the
> languages that do not have an explicit variable
> declaration.
> Why don't we use just a leading dot?
> As .foo instead of self.foo?
>
Because it's horrible and unreadable?

> What is the real problem is that python has no concurrency
> support in language itself neither in java way (locks,
> concurrent data structures), nor erlang way (message
> passing, surprise but erlang runtime has *one* scheduler
> runnning by default), nor haskel way (via atomic
> keyword).
>

Concurrent data structures aren't language-level support (they're library
level support, just as Python's Queue.Queue), and the dismal Java concurrency
language support, in the form of the `synchronized` keyword (which I guess
is what you were talking about), causes as many problem as it solves.

I strongly doubt it's a good example. In fact, you'll notice that Java's
concurrency support was quite recently improved *purely via library constructs*
in the form of the java.util.concurrent package
(and the java.util.concurrent.atomic and java.util.concurrent.locks subpackages)
while standard/basic containers all moved to non-threadsafe by default a long
time ago (e.g. ArrayList vs Vector).

In other words, if you want to consider the Java examples what Python lacks is a
thought-of concurrent datastructures library (including scalar types, that is).

Also, Haskell *doesn't* have an `atomic` keyword. In fact, Haskell has no
concurrenty-oriented keyword that I know of (you can see haskell's keyword
list at "http://haskell.org/haskellwiki/Keywords").

Haskell has `atomically`, but it's a *function* and part of the nonstandard
GHC.Conc module as an implementation of the STM monad.

So the only language that has actual, useful, working concurrency keywords
here is Erlang, and it was built around concurrency in the first place.

The others' concurrency support is pretty much exclusively through library
(not that I think it's quite good enough).

Jason Tuller

Posts: 1
Nickname: jt4
Registered: Sep, 2007

Re: Python 3K or Python 2.9? Posted: Sep 11, 2007 4:45 AM
Reply to this message Reply
As Guido suggested above, what Bruce really wants is Java (or C#): a Python with implicit self, a standard GUI library, easy deployment (esp. for C#), efficient utilization of multicores.

I think Guido is trying to avoid the exact same thing: in one of his blogposts here I remember reading that adding static typing to Python would morph it into Java.

Bruce Eckel

Posts: 868
Nickname: beckel
Registered: Jun, 2003

Re: Python 3K or Python 2.9? Posted: Sep 11, 2007 7:48 AM
Reply to this message Reply
> I strongly doubt it's a good example. In fact, you'll
> notice that Java's
> concurrency support was quite recently improved *purely
> via library constructs*
> in the form of the java.util.concurrent package
> (and the java.util.concurrent.atomic and
> java.util.concurrent.locks subpackages)
> while standard/basic containers all moved to
> non-threadsafe by default a long
> time ago (e.g. ArrayList vs Vector).

Actually it was not purely via library constructs; there was a very important low-level change made to ensure cache coherency based on a seminal paper that came out in recent years and changed everyone's thinking about the issue (I don't have the reference, but Scott Meyers wrote about it, and I'm pretty sure Brian Goetz has as well). Java threading (as well as other threading implementations) had a fundamental flaw until version 5 because of this issue, and it's one reason there was such pressure to upgrade. And yet another reason why threading is not the right solution to parallel processing -- it's too hard to get right.

Python threads with the GIL might actually be the best solution for threads from a programming standpoint, because the lack of true parallelism seems like it would mean that you can't actually access shared memory simultaneously as you could with multicores. You can certainly still write bad multithreaded programs, but maybe the collisions are reduced. Have to think about that one some more.

Flat View: This topic has 62 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: Python 3K or Python 2.9? Previous Topic   Next Topic Topic: Physical Dependencies


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us