Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Why I love python.

Reply
Thread Tools

Why I love python.

 
 
Michael Scarlett
Guest
Posts: n/a
 
      08-13-2004
There is an amazing article by paul graham about python, and an even
better discussion about it on slashdot. The reason I point this out,
is the more I read both articles, the more I realised how we would be
mutilating the language with that god forsaken @ decorator.
I don't know about the rest of you, but I learned python and fell in
love with its syntax and simplicity. Python - just works. So please
GVR. Don't complicate it. Leave it as is. Work on making it faster,
not uglier. Work on - in some cases - better algorithms for certain
modules, not for it to even closely resemble C or perl or god knows
whateverotherlanguagethereisoutthere. Am i the only one with a
visceral reaction to this thing???

paul Graham article: http://www.paulgraham.com/pypar.html

Slashdot discussion:
http://developers.slashdot.org/devel...id=156&tid=218
 
Reply With Quote
 
 
 
 
Robert
Guest
Posts: n/a
 
      08-13-2004
"Michael Scarlett" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> There is an amazing article by paul graham about python, and an even
> better discussion about it on slashdot. The reason I point this out,
> is the more I read both articles, the more I realised how we would be
> mutilating the language with that god forsaken @ decorator.
> I don't know about the rest of you, but I learned python and fell in
> love with its syntax and simplicity. Python - just works. So please
> GVR. Don't complicate it. Leave it as is. Work on making it faster,
> not uglier. Work on - in some cases - better algorithms for certain
> modules, not for it to even closely resemble C or perl or god knows
> whateverotherlanguagethereisoutthere. Am i the only one with a
> visceral reaction to this thing???
>


Nope I have the same reaction.


 
Reply With Quote
 
 
 
 
Mark Bottjer
Guest
Posts: n/a
 
      08-13-2004
Michael Scarlett wrote:
> I don't know about the rest of you, but I learned python and fell in
> love with its syntax and simplicity.


That's the funny thing about Python. It really isn't simple, but it sure
seems like it is. There's tons of little niggling rules about scoping,
inheritance, and what have you--but you can be blissfully ignorant of
most of them and still get work done. That's pretty unique.

I think that's why people are so concerned about @pie: it has the
*potential* to be an obstacle early in the learning process, instead of
after someone is already hooked.

> Am i the only one with a visceral reaction to this thing???


Goodness, no! Why do you think we've all been ****ing and moaning so much?

-- Mark
 
Reply With Quote
 
Nick Patavalis
Guest
Posts: n/a
 
      08-13-2004
On 2004-08-13, Michael Scarlett <(E-Mail Removed)> wrote:
> There is an amazing article by paul graham about python, and an even
> better discussion about it on slashdot.


Yes, the article is very good

> Don't complicate it. Leave it as is. Work on making it faster, not
> uglier.


Python needs drastic performance improvement if it is to scrap-off the
"scripting language" stigma. The only way to get these improvements is
making it possible for a python implementation to produce *efficient*
*compiled* code. At the same time the dynamic-typing nature of the
language is one of its most valuable characteristics. And this is one
of the hardest problems when trying to write a decent python
compiler. If you define a function like:

def sum (a, b):
return a + b

How can the compiler know what code to produce? It could trace all the
applications of sum(), and decide what types of arguments sum() is
actually applied on. But this is not easy, and sometimes it is
straight-out impossible.

A different approach would be for the programmer to *suggest* what
kind of types the function will *most probably* be applied on. The
programmer might suggest to the compiler that "a" and "b" will *most
probably* be integers or floats, so the compiler will have to produce
code for a function that handles these cases (or code for two
"functions", one for each case). One might say that the function could
be "decorated" by the programmer regarding the type of its
arguments. Notice that in such a case the decoration does not alter
the behavior of the function in any way! The function can still be
called with string arguments, in which case execution will be
dispatched to an "interpreted" version thereof.

So I believe is that "making it faster" requires some fundamental
work, and not simply devising "better algorithms for some
modules". Better algorithms for some modules will give you something
like point-something improvement in performance. Being able to produce
efficient compiled code will give you improvement between a factor of
10 and an order of magnitude (depending on the type of the
program). The same it true for "making it more secure" (e.g by
providing the programmer a way to specify what types of arguments are
*allowed* to be passed to a function).

In general, python must break free from its perl-ish adolescence
(language for small things, which doesn't have to be very fast or very
safe), but without loosing its agility. Decorators might be a step in
the right direction, or at least they might allow some experimentation
with such matters.

Because of this they are welcome.

Just my 2c
/npat

 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      08-13-2004

"Nick Patavalis" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 2004-08-13, Michael Scarlett <(E-Mail Removed)> wrote:
>
> Python needs drastic performance improvement if it is to scrap-off the
> "scripting language" stigma.


More performance would be helpful. There are a number
of projects that are working toward that end, of which
the most visible is the PyPy project. Jim Hughnin claims
that he's getting substantial improvements with his port
to the .Net framework, but see Fredrick Lundh's August
4 post on the subject.

As far as I'm aware, the biggest current performance
sink is function and method call overhead. Lookup for
module and built-in level variables is also a significant
time sink - and both module level and builtin identifiers
are used quite frequently.

Another thing to notice is the garbage collection
algorithm. Python uses reference counting as the
basic algorithm, which wasn't that bad a choice
a decade ago. Today real garbage collection
technology has outstripped it so that maintaining
the reference counts is another time sink.

The descriptor technology in new style classes
is a stunning techincal achievement, but in the
worst case it requires a full scan of the class
hierarchy before the mechanism can decide if
it's appropriate to insert an attribute into an
instance or invoke a property.

> The only way to get these improvements is
> making it possible for a python implementation
> to produce *efficient* *compiled* code.


I think there are lots of people that would dispute
you on that. Current Java environments run close
to C++ performance due to the JIT compilers
that are built into the runtimes. Current JIT
technology doesn't require pre-declaration of
variable types; it's perfectly happy to insert checks
at appropriate points so that it can reuse code when
the object types don't change (which they don't
most of the time.)

John Roth


> Just my 2c
> /npat
>



 
Reply With Quote
 
Jack Diederich
Guest
Posts: n/a
 
      08-13-2004
On Thu, Aug 12, 2004 at 08:22:01PM -0400, Mark Bottjer wrote:
> Michael Scarlett wrote:
> >I don't know about the rest of you, but I learned python and fell in
> >love with its syntax and simplicity.

>
> That's the funny thing about Python. It really isn't simple, but it sure
> seems like it is. There's tons of little niggling rules about scoping,
> inheritance, and what have you--but you can be blissfully ignorant of
> most of them and still get work done. That's pretty unique.
>
> I think that's why people are so concerned about @pie: it has the
> *potential* to be an obstacle early in the learning process, instead of
> after someone is already hooked.
>

Agreed, python isn't simple and those hidden things are actually useful for
getting real work done. I've been using python industrially for three years
and I'm a big fan of decorators; decorators would help me get things done.
I liked the look of [decorators] before colon option more, but the current
situation of

def foo(a,b,c):
#
# 60 lines of code here
#
foo = mutate(foo) # oh, and by the way the 'def foo'
# signature might be misleading

'foo = mutate(foo)' It is boilerplate, python is nice because it eschews
boilerplate.

While the decorator syntax might not be obvious to newbies they won't see
it in simple code. When then do see it having @mutate right next to the
func def has to be more of a clue than 'foo=mutate(foo)' lines or screens away.

-Jack
 
Reply With Quote
 
Nick Patavalis
Guest
Posts: n/a
 
      08-13-2004
On 2004-08-13, John Roth <(E-Mail Removed)> wrote:
>
> "Nick Patavalis" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On 2004-08-13, Michael Scarlett <(E-Mail Removed)> wrote:
>>
>> Python needs drastic performance improvement if it is to scrap-off the
>> "scripting language" stigma.

>
> More performance would be helpful. There are a number
> of projects that are working toward that end, of which
> the most visible is the PyPy project.


Yes, I know about PyPy, and I think what they are trying to do is
write Python itself in a Python-subset that can be efficiently
compiled, or something along these lines. This is interesting (to say
the least).

>
> As far as I'm aware, the biggest current performance
> sink is function and method call overhead [...]
>
> Another thing to notice is the garbage collection
> algorithm [...]


Both very true!

>
>> The only way to get these improvements is
>> making it possible for a python implementation
>> to produce *efficient* *compiled* code.

>
> I think there are lots of people that would dispute
> you on that. Current Java environments run close
> to C++ performance due to the JIT compilers
> that are built into the runtimes.


You 're right, I was maybe a bit too dogmatic on my point. But you
must accept that JIT-compilers are, nevertheless, compilers! They may
be more intelligent and more flexible than traditional "ahead of time"
compilers, but still they are fundamentally compilers. Furthermore,
for most cases, it might be possible for an AOT compiler to produce a
"binary" that doesn't contain the compiler itself.

> Current JIT technology doesn't require pre-declaration of variable
> types; it's perfectly happy to insert checks at appropriate points
> so that it can reuse code when the object types don't change (which
> they don't most of the time.)


What you mean I guess, is that the first time a function is applied,
it is compiled to native-code, and a signature for the application is
generated. The next time, the application is checked against the
signature and if they match, the existing code is used, otherwise the
function is re-compiled (preserving the previously compiled one too,
is some sort of "cache"). Or am I getting it wrong? Even in such a
case though per-declarations would help.

Do you happen to know of any efforts to build such "AOT"/"JIT"
compilation/execution environments for Python?

Regards
/npat

 
Reply With Quote
 
Anthony Baxter
Guest
Posts: n/a
 
      08-13-2004
On Fri, 13 Aug 2004 01:11:54 +0000 (UTC), Nick Patavalis
<(E-Mail Removed)> wrote:
> > Don't complicate it. Leave it as is. Work on making it faster, not
> > uglier.

>
> Python needs drastic performance improvement if it is to scrap-off the
> "scripting language" stigma.


I'm biased, having done a paper on this at the most recent PyCon, but
I firmly believe that much of the "Python is too slow" arguments can be
answered with "too slow for what?" See the pycon proceedings, but I've
been doing VoIP in Python, complete with audio mixing, and it's been
more than fast enough.

Another large app is a database ETL tool - Python is more than
adequate for flinging around a very large number of rows of data.
Indeed, it could be 4-5 times as slow, and Oracle would still be the
bottleneck.

Sure, you're not going to get great performance for your numerical
computation in Python, but luckily, we have numarray for this.

Yes, additional performance would be a nice-to-have, but I've not
really found the existing interpreter's performance to be that much
of a problem. I suspect that one of the many new implementations
will provide us with some wins here.
 
Reply With Quote
 
Anthony Baxter
Guest
Posts: n/a
 
      08-13-2004
On 12 Aug 2004 17:05:34 -0700, Michael Scarlett <(E-Mail Removed)> wrote:
> [ pie decorators ]
> Am i the only one with a
> visceral reaction to this thing???


So did you have a similar reaction on first hitting the indentation for
blocks? I know I dimly recall thinking that this was very strange and
horrible (dimly, because it was 1992 or 1993).
 
Reply With Quote
 
Sam Holden
Guest
Posts: n/a
 
      08-13-2004
On Fri, 13 Aug 2004 16:35:58 +1000,
Anthony Baxter <(E-Mail Removed)> wrote:
> On Fri, 13 Aug 2004 01:11:54 +0000 (UTC), Nick Patavalis
><(E-Mail Removed)> wrote:
>> > Don't complicate it. Leave it as is. Work on making it faster, not
>> > uglier.

>>
>> Python needs drastic performance improvement if it is to scrap-off the
>> "scripting language" stigma.

>
> I'm biased, having done a paper on this at the most recent PyCon, but
> I firmly believe that much of the "Python is too slow" arguments can be
> answered with "too slow for what?" See the pycon proceedings, but I've
> been doing VoIP in Python, complete with audio mixing, and it's been
> more than fast enough.


I've also been doing rtp voice in python - on an iPAQ H3800... I'm using
your rtp.py code (I'm not doing sip), so I can't take credit for it
though

I dont know if it's "more than fast enough", but it's "fast enough".

--
Sam Holden
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Love love love imuaplease@gmail.com C++ 0 06-03-2009 02:53 AM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
I love my Xeon, I hate my Xeon, I love my Xeon... wewa Windows 64bit 9 11-10-2005 06:39 PM
Win a love actually Love Pack MaG DVD Video 0 05-05-2004 04:48 PM



Advertisments