Is python not good enough?
in [Python]
|
From: Jonathan Hartley on 13 Jan 2010 04:33 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 13 Jan 2010 10:28 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 14 Jan 2010 02:20 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 15 Jan 2010 15:34 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 15 Jan 2010 21:31
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. |