Is python not good enough?

[ikuta liu]

I'm a little confused.
Is python not good enough?
for google, enhance python performance is the good way better then
choose build Go language?

Go language try to merge low level, hight level and browser language.

Those I'd like to see it on python..

 

[Stefan Behnel]

ikuta liu, 12.01.2010 16:09:

I'm a little confused.
Is python not good enough?
for google, enhance python performance is the good way better then
choose build Go language?

Go language try to merge low level, hight level and browser language.

Those I'd like to see it on python..

I think everyone's free to put resources into the creation of new
programming languages. Google has enough money to put it into all sorts of
things without the need to have them pay off.

Stefan

 

[Krister Svanlund]

Every language has it uses and Google obviously thought that it would
take more resources to get Python to the level they need it than to
start using Go.

Python is great for alot of things but it's not perfect for anything.

 

[Ethan Furman]

[please don't top-post]

> Every language has it uses and Google obviously thought that it would
> take more resources to get Python to the level they need it than to
> start using Go.
>
> Python is great for alot of things but it's not perfect for anything.
>

s/anything/everything/

~Ethan~

 

[Terry Reedy]

Every language has it uses and Google obviously thought that it would
take more resources to get Python to the level they need it than to
start using Go.

'Google' does not think.

Go builds on previous works by the main developers. I doubt that they
even considered trying to upgrade Python and in particular, its
generators, to accomplish the parallel processing goals. Their goal of
making Go very fast to compile by machines somewhat conflicts with
Python's goal of being fast to read by humans.

Terry Jan Reedy

 

[Aahz]

Is python not good enough? for google, enhance python performance is
the good way better then choose build Go language?

It is not at all clear that -- despite some comments to the contrary --
the Go developers are intending to compete with Python. Go seems much
more intended to compete with C++/Java. If they're successful, we may
eventually see GoPython. ;-)

 

[johan.sanden]

It is not at all clear that -- despite some comments to the contrary --
the Go developers are intending to compete with Python.  Go seems much
more intended to compete with C++/Java.  If they're successful, we may
eventually see GoPython.  ;-)
--
Aahz ([email protected])           <*>        http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair

GoPython i think would be neat.

 

[tanix]

GoPython i think would be neat.

Well, as soon as they restore the braces to identify the code
blocks and provide the functionality of advanced statically
type languages, such as threads, async processing, all synchronization
primitives, garbage collection, events and GUI, i'd be willing
to switch to Python. Some of it is already there. But not all.

Except, before doing it, I'd like to know what Python buys me
compared to say Java.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP,
organized by major topics of language, tools, methods, techniques.

 

[Chris Rebert]

Well, as soon as they restore the braces to identify the code
blocks and provide the functionality of advanced statically
type languages, such as threads, async processing, all synchronization
primitives, garbage collection, events and GUI, i'd be willing
to switch to Python. Some of it is already there. But not all.

Except, before doing it, I'd like to know what Python buys me
compared to say Java.

The lack of knowledge shown here gives me even less confidence in your
"Goldmine" collections than before.

Cheers,
Chris

 

[Stefan Behnel]

tanix, 13.01.2010 10:06:

Well, as soon as they restore the braces to identify the code
blocks and provide the functionality of advanced statically
type languages, such as threads, async processing, all synchronization
primitives, garbage collection, events and GUI, i'd be willing
to switch to Python. Some of it is already there. But not all.

Why don't you write up a proposal for the python-ideas list?

Stefan

 

[Jonathan Hartley]

Well, as soon as they restore the braces to identify the code
blocks and provide the functionality of advanced statically
type languages, such as threads, async processing, all synchronization
primitives, garbage collection, events and GUI, i'd be willing
to switch to Python. Some of it is already there. But not all.

Except, before doing it, I'd like to know what Python buys me
compared to say Java.

Hey tanis.

The absence of braces from Python is a thoughtful, deliberate choice.
There are good reasons for it, and many people (especially people
round these parts) think Python is better without braces. If you don't
like it then fair enough, your preferences are your own to choose.

Other than that, Python does have every single one of the things you
enumerate.

Regarding static versus dynamic typing - many people (especially
people round these parts) believe dynamic typing to be superior to
static typing in many situations. Again, personal taste seems to weigh
heavily in this topic, but there are strong reasons to prefer dynamic
typing - it allows you to write some programs that simply couldn't be
written statically, and this greater flexibility sometimes allows you
to choose algorithms and code organisation that is a better match for
your problem than a statically typed language would, making your
programs easier to write, shorter, and simpler to read.

As for a direct comparison with Java, then perhaps the most prominent
differences are that Python generally produces shorter, simpler-
looking programs, which are easier to write and read. Dynamic typing
is an advantage of Python in most situations. On the other hand,
Python often has poorer performance than Java. My personal hypothesis
is that this performance mismatch is most pronounced in small,
benchmark-like data churning inner-loops, and becomes less significant
for most real-world programs that have high complexity, since Python's
power-through-simplicity allows developers to visualise better
algorithms and refactor more easily than would otherwise be the case.

Best regards,

Jonathan

 

[ikuta liu]

It is not at all clear that -- despite some comments to the contrary --
the Go developers are intending to compete with Python.  Go seems much
more intended to compete with C++/Java.  If they're successful, we may
eventually see GoPython.  ;-)
--
Aahz ([email protected])           <*>        http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair

Thanks for the reply.
I don't think GoPython would be happen... because...
http://code.google.com/p/googleappengine/issues/detail?id=2382

Go is going to take the position from python and browser language
(Native Client),
Don't surprise Go got the interpreter in the future.

 

[Dennis Lee Bieber]

GoPython i think would be neat.

As long as it doesn't get called "GoPy" (too easy to pronounce as
"goopy")

 

[tanix]

On Wed, 13 Jan 2010 00:53:19 -0800 (PST), "(e-mail address removed)"
<[email protected]> declaimed the following in
gmane.comp.python.general:

As long as it doesn't get called "GoPy" (too easy to pronounce as
"goopy")

:--}

You guys are funny, I tellya.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP,
organized by major topics of language, tools, methods, techniques.

 

[John Nagle]

On 1/12/2010 10:17 AM, Krister Svanlund wrote:
Their goal of
making Go very fast to compile by machines somewhat conflicts with
Python's goal of being fast to read by humans.

Actually, no. It's quite possible to make a Python implementation that
runs fast. It's just that CPython, a naive interpreter, is too primitive
to do it. I was really hoping that Google would put somebody good at
compilers in charge of Python and bring it up to production speed.

Look at Shed Skin, a hard-code compiler for Python with automatic
type inference. One guy did that.

The language is fine, but the CPython implementation is obsolete.

John Nagle

 

[Nobody]

Actually, no. It's quite possible to make a Python implementation that
runs fast. It's just that CPython, a naive interpreter, is too primitive
to do it. I was really hoping that Google would put somebody good at
compilers in charge of Python and bring it up to production speed.

Look at Shed Skin, a hard-code compiler for Python

A hard-code compiler for the subset of Python which can easily be compiled.

Shed Skin has so many restrictions that it isn't really accurate to
describe the language which it supports as "Python".

Hardly any real-world Python code can be compiled with Shed Skin. Some of
it could be changed without too much effort, although most of that is the
kind of code which wouldn't look any different if it was implemented in
C++ or Java.

The monomorphism restriction is likely to be particularly onerous: the
type of a variable must be known at compile time; instances of subclasses
are allowed, but you can only call methods which are defined in the
compile-time class.

If you're writing code which makes extensive use of Python's dynamicity,
making it work with Shed Skin would require as much effort as re-writing
it in e.g. Java, and would largely defeat the point of using Python in the
first place.

http://shedskin.googlecode.com/files/shedskin-tutorial-0.3.html

If you want a language to have comparable performance to C++ or Java, you
have to allow some things to be fixed at compile-time. There's a reason
why C++ and Java support both virtual and non-virtual ("final") methods.

 

[hackingKK]

A hard-code compiler for the subset of Python which can easily be compiled.

Shed Skin has so many restrictions that it isn't really accurate to
describe the language which it supports as "Python".
+1


Hardly any real-world Python code can be compiled with Shed Skin. Some of
it could be changed without too much effort, although most of that is the
kind of code which wouldn't look any different if it was implemented in
C++ or Java.

Happy hacking.
Krishnakant.

 

[John Nagle]

A hard-code compiler for the subset of Python which can easily be compiled.

Shed Skin has so many restrictions that it isn't really accurate to
describe the language which it supports as "Python".

Hardly any real-world Python code can be compiled with Shed Skin. Some of
it could be changed without too much effort, although most of that is the
kind of code which wouldn't look any different if it was implemented in
C++ or Java.

The monomorphism restriction is likely to be particularly onerous: the
type of a variable must be known at compile time; instances of subclasses
are allowed, but you can only call methods which are defined in the
compile-time class.

If you're writing code which makes extensive use of Python's dynamicity,
making it work with Shed Skin would require as much effort as re-writing
it in e.g. Java, and would largely defeat the point of using Python in the
first place.

http://shedskin.googlecode.com/files/shedskin-tutorial-0.3.html

If you want a language to have comparable performance to C++ or Java, you
have to allow some things to be fixed at compile-time. There's a reason
why C++ and Java support both virtual and non-virtual ("final") methods.

My point is that Python is a good language held back by a bad
implementation. Python has gotten further with a declaration-free syntax
than any other language. BASIC and JavaScript started out declaration-free,
and declarations had to be retrofitted. Python has survived without them.
(Yes, there are hokey extensions like Psyco declarations and "decorators",
but both are marginal concepts.)

The key to hard-compiling Python is that you have to compile the
whole program, not individual modules. You can't tell how an individual
module will be used until you've seen its callers. If the compiler
looks at the whole program at once, type inference has a good chance of
disambiguating most type issues.

If you can see the whole program at once, most dynamism can be detected.
What's really needed is to detect the most common case, where objects don't
have unexpected dynamism and can be implemented as hard structures.

John Nagle

 

[Steve Holden]

My point is that Python is a good language held back by a bad
implementation. Python has gotten further with a declaration-free syntax
than any other language. BASIC and JavaScript started out
declaration-free,
and declarations had to be retrofitted. Python has survived without them.
(Yes, there are hokey extensions like Psyco declarations and "decorators",
but both are marginal concepts.)

The key to hard-compiling Python is that you have to compile the
whole program, not individual modules. You can't tell how an individual
module will be used until you've seen its callers. If the compiler
looks at the whole program at once, type inference has a good chance of
disambiguating most type issues.

If you can see the whole program at once, most dynamism can be
detected.
What's really needed is to detect the most common case, where objects don't
have unexpected dynamism and can be implemented as hard structures.

John Nagle

Of course, Guido has left the path to declarations open through the use
of function argument annotation. If you wanted to write programs that
reasoned about Python programs to optimize them, annotations could come
in very useful.

regards
Steve

 

[David Cournapeau]

   My point is that Python is a good language held back by a bad
implementation.  Python has gotten further with a declaration-free syntax
than any other language.  BASIC and JavaScript started out declaration-free,
and declarations had to be retrofitted.  Python has survived without them.
(Yes, there are hokey extensions like Psyco declarations and "decorators",
but both are marginal concepts.)

There are efficient implementations of dynamic programming languages
which do not rely on declaration (if by declaration you mean typing
declaration), even when available:

http://strongtalk.googlecode.com/svn/web site/history.html

See also:

http://www.avibryant.com/2008/05/those-who-misre.html

David