From: Jonathan Hartley on
On Jan 13, 9:06 am, ta...(a)mongo.net (tanix) wrote:
> 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
From: ikuta liu on
On 1月13日, 上午7時55分, a...(a)pythoncraft.com (Aahz) wrote:
> In article <1b42700d-139a-4653-8669-d4ee2fc48...(a)r5g2000yqb.googlegroups.com>,
> ikuta liu  <ikut...(a)gmail.com> wrote:
>
>
>
> >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.  ;-)
> --
> Aahz (a...(a)pythoncraft.com)           <*>        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.


From: tanix on
In article <mailman.901.1263452854.28905.python-list(a)python.org>, Dennis Lee Bieber <wlfraed(a)ix.netcom.com> wrote:
>On Wed, 13 Jan 2010 00:53:19 -0800 (PST), "johan.sanden(a)gmail.com"
><johan.sanden(a)gmail.com> declaimed the following in
>gmane.comp.python.general:

>> GoPython i think would be neat.
>
> 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.

From: John Nagle on
Terry Reedy wrote:
> 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
From: Nobody on
On Fri, 15 Jan 2010 12:34:17 -0800, John Nagle wrote:

> 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.