Morel Xavier
Posts: 73
Nickname: masklinn
Registered: Sep, 2005
|
|
Re: Python 3K or Python 2.9?
|
Posted: Sep 11, 2007 12:30 AM
|
|
> 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).
|
|
Previous Topic
