Re: Python too slow?

[Ed Jensen]

[EMAIL PROTECTED] wrote:
> A lecturer gave me the perfect answer to the question of speed.
> 
> "You have two choices when it comes to programming. Fast code, or fast
> coders."

"You're either with us, or against us."

George W. Bush




My understanding is that while CPython performance won't be winning
any awards anytime soon, Jython and IronPython are pretty impressive
performers.

Disclaimer: I haven't personally used Jython or IronPython.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python too slow?

[Ed Jensen]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> I don't think you're going to make you some friends here insulting 
> Fredrik. I don't know who Ed Jensen is, but we are quite a lot here to 
> know and respect Mr Lundh for his contributions to Python as both a 
> language and a community.

I'll keep in mind that some people around these parts are untouchable
and have a free pass to be insulting and childish.

Thanks for the tip.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python too slow?

[Ed Jensen]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> fact 1: CPython compiles source code to byte-code.
> fact 2: CPython executes this byte-code.
> fact 3: Sun's JDK compiles source code to byte-code.
> fact 4: Sun's JDK executes this byte-code.
> 
> Care to prove me wrong on any of these points ? Don't bother: you can't. 
> So my first assertion that "CPython is compiled to byte-code, which is 
> then executed by a VM" is true, and since the same assertion also stands 
> for Java (ie: sun's JDK), then the "just like" qualifier is true too. 
> Period.

#2 and #4 are wrong (or, at best, misleading).  Here, I'll fix them
for you:

Fact 2: CPython interprets the bytecode.

Fact 4: Sun's JVM does some interpretation of the bytecode, but also
compiles some of the bytecode to native code and executes the
resulting native code.

These distinctions can be important and it's intellectually dishonest
to gloss over them.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python too slow?

[Ed Jensen]

Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> oh, please.  it was perfectly clear for anyone with the slightest clue 
> what Bruno was talking about (especially if they'd read the post he was 
> replying to), so the only question that remains is why you didn't 
> understand it.

If you have something substantive to add to the discussion, by all
means, do so.  But please, keep your childish and insulting comments
to yourself.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python too slow?

[Ed Jensen]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> I fail to see how the existence of JIT compilers in some Java VM changes 
> anything to the fact that both Java (by language specification) and 
> CPython use the byte-code/VM scheme.

While your answer was technically correct, by omitting pertinent
information, your answer lead readers to the wrong conclusion.

The only question that remains is if you were being accidentally
misleading or purposefully misleading.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python too slow?

[Ed Jensen]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> And the reference implementation of Python (CPython) is not 
> interpreted, it's compiled to byte-code, which is then executed by a VM 
> (just like Java).

Wow, this is pretty misleading.

Java is, indeed, compiled to bytecode; however, modern JVMs typically
compile the bytecode to native code and then execute the native code.

CPython strictly interprets bytecode; it does not compile the
bytecode to native code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The best platform and editor for Python

[Ed Jensen]

Alex Martelli <[EMAIL PROTECTED]> wrote:
> Calling all vi/vim users (and we'll heartily appreciate the support of
> TextMate fans, BBEdit ones, etc, etc) -- we're at risk being defined out
> of existence, since we're neither happy with Emacs nor wanting anything
> like Visual Studio, and yet Kay claims that people in either category
> make up the whole (one half plus the other half) and so that WE DON'T
> EXIST!!!  A ridiculous claim to be sure, but we'd better let Herr
> Schluehr know that in no uncertain terms...

vi/vim/gvim user here...  :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: try/except/else/finally problem

[Ed Jensen]

Peter Otten <[EMAIL PROTECTED]> wrote:

>> try:
>> f = file('test.txt', 'r')
>> except IOError:
>> print 'except'
>> else:
>> print 'else'
>> finally:
>> print 'finally'

> You need Python 2.5 for that to work. In older Python versions you have to
> nest try...except...else and try...finally.

Thanks Peter.

Given the code above, can you show me what that would look like?  The
nested version, that is.
-- 
http://mail.python.org/mailman/listinfo/python-list

try/except/else/finally problem

[Ed Jensen]

I'm using:

Python 2.3.2 (#1, Oct 17 2003, 19:06:15) [C] on sunos5


And I'm trying to execute:

#! /usr/bin/env python

try:
f = file('test.txt', 'r')
except IOError:
print 'except'
else:
print 'else'
finally:
print 'finally'


And the results are:

  File "./test.py", line 9
finally:
  ^
SyntaxError: invalid syntax


What am I doing wrong?

Thanks in advance for any help.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and Java

[Ed Jensen]

Steve Holden <[EMAIL PROTECTED]> wrote:
> Ed Jensen wrote:
>> Steve Holden <[EMAIL PROTECTED]> wrote:
>>> Jython is an implementation of Python that compiles to Java bytecode, 
>>> but at the moment there's some version lag so it won't handle the mos 
>>> recent language enhancements. Probably worth a look, though.
>>>
>>>http://www.jython.org/
>> 
>> Does Jython compile to Java bytecode, or is Jython a Java
>> implementation of a Python interpreter?
> 
> Please read what I wrote again.

I read it and understood it just fine.  My question was meant more
along the lines of, "Are you SURE it compiles to Java bytecode, and
isn't a Python interpreter written in Java?"  I guess I didn't make
that clear.

Anyway, I checked the Jython home page, and sure enough, Jython
compiles Python code to Java bytecode, as stated in the FAQ which can
be found at the following URL (in case anyone else reading this
message is following along and is interested):

http://www.jython.com/Project/userfaq.html#what-is-jython

In particular:

1.1   What is Jython?

Jython implements the Python programming language on the Java(tm)
Platform. It consists of a compiler to compile Python source code down
to Java bytecodes which can run directly on a JVM, a set of support
libraries which are used by the compiled Java bytecodes, and extra
support to make it trivial to use Java packages from within Jython.

Sorry if I bothered/annoyed you, Steve.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and Java

[Ed Jensen]

Steve Holden <[EMAIL PROTECTED]> wrote:
> Jython is an implementation of Python that compiles to Java bytecode, 
> but at the moment there's some version lag so it won't handle the mos 
> recent language enhancements. Probably worth a look, though.
> 
>http://www.jython.org/

Does Jython compile to Java bytecode, or is Jython a Java
implementation of a Python interpreter?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Problem with global variables

[Ed Jensen]

Ed Jensen <[EMAIL PROTECTED]> wrote:
> I'm having a vexing problem with global variables in Python.



Thanks to everyone who replied.  The peculiar way Python handles
global variables in functions now makes sense to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Problem with global variables

[Ed Jensen]

I'm having a vexing problem with global variables in Python.  Please
consider the following Python code:

#! /usr/bin/env python

def tiny():
bar = []
for tmp in foo:
bar.append(tmp)
foo = bar

if __name__ == "__main__":
foo = ['hello', 'world']
tiny()

When I try to run this, I get:

Traceback (most recent call last):
  File "./xtalk.py", line 11, in ?
tiny()
  File "./xtalk.py", line 5, in tiny
for tmp in foo:
UnboundLocalError: local variable 'foo' referenced before assignment

For some reason, Python can't see the global variable "foo" in the
function tiny().  Why is that?

If I change the code to this:

#! /usr/bin/env python

def tiny():
for tmp in foo:
print tmp

if __name__ == "__main__":
foo = ['hello', 'world']
tiny()

I get this:

hello
world

All of a sudden, tiny() can see the global variable "foo".  Very
confusing!  Why is it that tiny() sometimes can, and sometimes can't,
see the global variable "foo"?

If anyone can enlighten me about what's going on with Python and
global variables, I would appreciate it!
-- 
http://mail.python.org/mailman/listinfo/python-list

How to determine what exceptions a method might raise?

[Ed Jensen]

I'm really enjoying using the Python interactive interpreter to learn
more about the language.  It's fantastic you can get method help right
in there as well.  It saves a lot of time.

With that in mind, is there an easy way in the interactive interpreter
to determine which exceptions a method might raise?  For example, it
would be handy if there was something I could do in the interactive
interpreter to make it tell me what exceptions the file method might
raise (such as IOError).

Thanks in advance.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: jython's future

[Ed Jensen]

??ukasz Langa <[EMAIL PROTECTED]> wrote:
> Java was at 1.2 (and compiling Hello World took over 5 minutes)

Bullshit.  Complete and utter bullshit.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python component model

[Ed Jensen]

Paul Boddie <[EMAIL PROTECTED]> wrote:
> People who bring up stuff about self and indentation are just showing
> their ignorance

Ouch.  That stings.

Python's "indentation determines scope" makes it hard for me to discuss
Python via mediums like IRC and instant messengers.

It also makes it hard to quickly jump to the top and/or bottom of
code blocks in most editors I use on a day to day basis.

I guess I'm just ignorant.  :(
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: do people really complain about significant whitespace?

[Ed Jensen]

infidel <[EMAIL PROTECTED]> wrote:
> Where are they-who-hate-us-for-our-whitespace?  Are "they" really that
> stupid/petty?  Are "they" really out there at all?  "They" almost sound
> like a mythical caste of tasteless heathens that "we" have invented.
> It just sounds like so much trivial nitpickery that it's hard to
> believe it's as common as we've come to believe.

I like Python, but I do wish it used braces instead, if only because
every editor I'm likely to use supports brace matching, which makes it
easy to (for example) jump to the bottom or top of a block.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Accessors in Python (getters and setters)

[Ed Jensen]

Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> Which puts us to the next question: the sealing itself doesn't do 
> anything to restrict the code, the SecurityManager does. Which AFAIK is 
> something hooked into the VM. Now, I'm not on sure grounds here on how 
> to altere its behaviour, but I'd say if we're talking me working on a 
> secure application that introduces its own SecurityManager, I'm still 
> the one in control. I could use your lib, turn off privacy, and fiddle 
> around.
> 
> If things were the other way round, and I'd have to work in a restricted 
> context, it actually might be that someone restricted private access 
> (because he owns the VM!). But then - he'd also be able to forbid 
> threading or file access or all kinds of things that I'd otherwise be 
> used to work with which will suddenly make my code burst in flames.
> 
> And if we are honest: the most problematic cases of abused code aren't 
> the ones of strangers exploiting your code, but instead your fellow 
> coders at the other department. Which most probably means that they 
> aren't restrained by security management anyway.
> 
> To summarize: it might be possible to jump through a few hoops to 
> increase the security. But in 99.9% of cases this doesn't happen, as it 
> would increase complexity by orders of magnitude - for a comparatively 
> small gain (talking about private declarations. The sandbox-restrictions 
> of Java for running applets certainly are worth it).

Interesting stuff!  And thanks for the link from your earlier post.

Where I work, this little discovery will actually help us stop jumping
through some hoops we've been jumping through to unit test private
methods.

It also gives us more to think about since we had been assuming
private could not be circumvented.

Thanks Diez.  :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Accessors in Python (getters and setters)

[Ed Jensen]

Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>> Java is not an acronym.  That is: it's "Java", not "JAVA".
> 
> Now THAT was an important information RIGHT on topic.

It was not meant offensively.

>> Java does not allow access to private members via reflection.
> 
> For somebody nitpicking on natural language usage to a non-native 
> speaker, you show an impressive lack of knowledge in the actual subject 
> discussed.

Again: It was not meant offensively.

Maybe you can try turning the flames down a bit.

> http://www.onjava.com/pub/a/onjava/2003/11/12/reflection.html

Does that approach work on sealed jars as well?  I would imagine any
jars that need any kind of "real" security would be sealed...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Accessors in Python (getters and setters)

[Ed Jensen]

Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> Ah, you mean like in JAVA

Java is not an acronym.  That is: it's "Java", not "JAVA".

> where the compiler prevents you from accessing
> private variables, but the runtime allows access to these very variables
> via reflection? 

Java does not allow access to private members via reflection.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Ed Jensen]

Roy Smith <[EMAIL PROTECTED]> wrote:
> BTW, if like Python and haven't looked at Ruby, it's worth a glance.  If 
> Python can be called similar to Lisp, then Ruby is even more so.  I'm not 
> fond of Ruby's perlesqe syntax, but I like many of the fundamental ideas.

I can't get over Ruby's ugly syntax.  :(

Long live Python!  :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Ed Jensen]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> It's not a "scripting" language, and it's not interpreted.

http://www.python.org/doc/faq/general.html#what-is-python

"Python is an interpreted, interactive, object-oriented programming
language."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python article in Free Software Magazine

[Ed Jensen]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> I don't want to nit-pick all my way through the article, which
> is very decent and is worth reading, but I will say one more thing: you
> describe Python as "an expressive, interpreted language". Python is no
> more interpreted than Java. Like Java, it is compiled into byte-code which
> is then executed by a virtual machine. It has a separate compilation and
> execution step.

The most-used desktop/server JVM, the Sun JVM, takes things one step
further and compiles often-executed bytecode into native code.  It can
then execute native code.  AFAIK, the most-used desktop/server Python
VM doesn't do that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python article in Free Software Magazine

[Ed Jensen]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> I don't want to nit-pick all my way through the article, which
> is very decent and is worth reading, but I will say one more thing: you
> describe Python as "an expressive, interpreted language". Python is no
> more interpreted than Java. Like Java, it is compiled into byte-code which
> is then executed by a virtual machine. It has a separate compilation and
> execution step.

http://www.python.org/doc/faq/general.html

"Python is an *interpreted*, interactive, object-oriented programming
language."

Emphasis mine.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: wxPython Licence vs GPL

[Ed Jensen]

Paul Rubin  wrote:
> Python and *BSD are getting far less volunteer development love than,
> say, GCC or Linux, and the licensing is at least part of the reason.

I disagree.  I believe *BSD gets less volunteer development because of
some legal wrangling in the early 90s that didn't affect Linux.

I believe GCC gets more volunteer development than Python because C
and C++ were (and are) much more widely used.

> Also, numerous GCC ports done by hardware companies (for their CPU's)
> have been released under the GPL that would definitely have been
> proprietary if it had been permitted.  That is not speculation, it is
> known from discussions with those hardware companies at the time.

Even if this is true, GCC would have continued to exist.  Just because
an entity takes some open source code and places it in a closed source
product, the original open source code continues to exist.

Frankly, I suspect those hardware companies would have relented their
decision once they realized it was harder to keep re-integrating their
code into newer GCC releases, than it was to just release the code.

> G++
> (the original C++ front end for GCC) also would have been proprietary.

I'm not saying you're wrong, but since you're providing no evidence,
I'll remain skeptical about this claim.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: wxPython Licence vs GPL

[Ed Jensen]

Christophe <[EMAIL PROTECTED]> wrote:
> If you don't like the GPL, then by all means, *do not use GPL code !*
> 
> Please, I mean, when you use without authorisation some code in your 
> project, you are in trouble, no matter what licence the code was using.

I'm not sure why you felt compelled to state the obvious...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: wxPython Licence vs GPL

[Ed Jensen]

Paul Boddie <[EMAIL PROTECTED]> wrote:
> We'll have to wait and see what happens. There's a risk that versions
> of Python with different semantics or characteristics to the original
> could cause the development of parallel communities, instead of
> everyone working on/with the same project. The "harm done" is
> adequately described by paraphrasing your comment on licences: think
> how much farther along free software could be if all this energy and
> concern weren't expended on separate and sometimes proprietary code
> bases.

I think free software/open source has existed long enough and with
enough varied licenses (GPL, LGPL, modified LGPL (see wxWidgets), BSD,
X11, MIT, Apache, etc.) that we'd basically know without question if
less restritive licenses (like BSD) were causing projects to fail vs.
projects that use very heavy handed licenses (like GPL).  Apache and
Python are two of my favorite examples, followed by the *BSD operating
systems.

> Well, despite your protestations, I think the GPL and LGPL are fairly
> easy and safe choices for a lot of developers who know enough about
> Free Software (ie. haven't just seen the name and thought "that's the
> thing for me"), know what the characteristics of those licences are,
> and who don't have the time or legal experience to "performance due
> diligence".

To be honest, I don't dislike the LGPL that much.  The static vs.
dynamic linking issues bother me somewhat (which is why I like the
modified LGPL used by wxWidgets), but all in all, I can live (albeit
uncomfortably) with LGPL.  It seems much more sane.  Whereas including
one line of GPL code into your 10,000,000,000 line project can have
disasterous consequences (which I find ridiculous), at least with LGPL
you're only asked to share the changes you've made to that particular
library.

> Meanwhile, all this "hippie" and "chilling effect" talk is, I imagine,
> like having a discussion on software licensing with some cold war
> propagandist.

Sorry for my initial post on this subject being flamey.  I must've
been cranky that day, and I'm glad we were able to continue the
discussion.  :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: wxPython Licence vs GPL

[Ed Jensen]

Paul Boddie <[EMAIL PROTECTED]> wrote:
>> I'm aware of this concern.  I don't think it's justified.  Unless
>> you'd like to point out all those closed, proprietary Python
>> implementations that are destroying civilization as we know it.

> Well, there was some concern voiced at EuroPython that a certain large
> software-patent-lobbying organisation wouldn't release the shiny port
> of Python that they'd done for their mobile telephone products. Now,
> one can either emulate that well-practised foot-stamping routine of
> yours...

Has this seriously harmed the Python community?  Or CPython?  Has it
caused evolution of Python/CPython to stall?  Did it have the
unfortunate consequence of causing any CPython code to become closed
source or proprietary?

Show me the harm done.

> In another recent licensing spat, some people are apparently unhappy
> with one Python-related project's use of the GPL, since the code they
> originally contributed to an older, related project ends up being
> redistributed under the GPL in the former project whereas the latter
> project cannot redistribute the former project's original code without
> putting a GPL licence on the distributed work. Now, if the latter
> project, with its advantage of having come into existence first had
> chosen a GPL-incompatible licence, it's quite possible that they would
> have avoided the situation that some seem to bemoan, but then one has
> to consider the likelihood that people actually do want GPL
> compatibility in their favourite open source projects.

I agree that mixing and matching licenses can be a problem, which is
yet another reason I lament the proliferation of source code licenses.

It's like a whole generation of software developers have become
armchair lawyers, which I find unfortunate.  Think how much farther
along free software could be if all this energy and concern weren't
expended on source code licenses.

> My point about the freeloading was that business understandably likes
> to do it. I don't feel any sympathy for participants in various Apache
> projects that are hugely popular in business, for example, if those
> participants dislike the lack of contributions from those companies
> using their software to make money, because those who founded those
> projects made a conscious licensing decision and that decision defines
> the kind of sharing (or otherwise) around such projects.

I don't feel sorry for them either, and I don't think they feel sorry
for themselves.  And the success of projects like Apache are even more
proof, in my opinion, that heavy handed licenses like the GPL aren't
necessary for the success of free software projects.

> So if you're not personally affected, as you claim, why does it bother
> you?

Because I think a lot of well meaning software developers writing free
software don't performance due diligence to determine the true
motivation behind, and the chilling effect of, the GPL.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: wxPython Licence vs GPL

[Ed Jensen]

Grow up, Steven.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: wxPython Licence vs GPL

[Ed Jensen]

Paul Boddie <[EMAIL PROTECTED]> wrote:
> It's interesting that you bring this tired thought experiment up in the
> context of the original remark: "Its license is far more "free" than
> GPL is." If we were focusing on the "vox pop" interpretation of the
> word "free", that remark wouldn't make any sense at all: after all,
> what's more gratis than gratis (to use a less ambiguous word)?

My only intention was to point out that "Free Software" is a rather
misleading term.

I still think of the term "Free Software" as false advertising.

> Python is moderately successful, yes, but the GPL is a useful tool to
> ensure that certain freedoms are preserved. I've been made aware of a
> certain level of dissatisfaction about whether organisations porting
> Python to other platforms would choose to share their modifications and
> improvements with anyone, or whether binary downloads with restrictive
> usage conditions would be the best even the customers of such
> organisations would be able to enjoy. Ensuring some of those freedoms
> can be an effective way of making open source software projects
> successful.

I'm aware of this concern.  I don't think it's justified.  Unless
you'd like to point out all those closed, proprietary Python
implementations that are destroying civilization as we know it.

> At least when it comes to software licensing, what probably upsets the
> anti-GPL "pragmatic licensing" crowd the most is that Stallman is quite
> often right; the BitKeeper debacle possibly being one of the more
> high-profile cases of some group's "pragmatism" (or more accurately,
> apathy) serving up a big shock long after they'd presumably dismissed
> "the hippie nonsense".

Stallman thinks selling closed, proprietary software is evil.
Stallman thinks buying closed, proprietary software is evil.

I find these opinions and "morals" fundamentally and obviously wrong.

> Well, from what I've seen of open source software usage in business, a
> key motivation is to freeload, clearly driven by people who neither see
> nor understand any other dimension of software freedom than your "vox
> pop" definition. Such users of open source software could make their
> work a lot easier if they contributed back to the projects from which
> they obtained the software, but I've seen little understanding of such
> matters. Of course, businesses prefer to use euphemisms like "cost
> reduction" or "price efficiency" rather than the more accurate
> "freeloading" term, and they fail to see any long-term benefits in
> anything other than zero cost, zero sharing acquisition and
> redistribution of code. But then in some sectors, the game is all about
> selling the same solution over and over again to the same customers, so
> it's almost understandable that old habits remain.

Wah, wah, I gave this software away for free, and people are actually
using it without giving anything back!  Wah, wah!

>> but then that gives me the right to refer to GPL'd software as "free as in 
>> pushing my
>> personal social agenda".

> Pushing on whom, though? No-one makes you use GPL'd software by, for
> example, installing it on almost every computer you can buy from major
> vendors. If, on the other hand, you mean that some social agenda is
> being imposed on you because, in choosing to redistribute someone's
> work, you are obliged to pass on those freedoms granted to you by the
> creator (or distributor) of that work, then complaining about it seems
> little more than a foot-stamping exercise than anything else.

Now you're just trying to put words into my mouth.

I never said anything was being "pushed on" me.  I never said anything
was being "imposed on" me.  I said an agenda was being pushed.
Stallman and company have an agenda, and the GPL is their instrument
of choice for pushing that agenda.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: wxPython Licence vs GPL

[Ed Jensen]

Paul Boddie <[EMAIL PROTECTED]> wrote:
> That would be "free as in freeloading", right? (And no, I'm not
> intending to start a licensing flame war with that remark, but I think
> it's inappropriate to ignore central licensing concepts such as
> end-user freedoms, and then to make sweeping statements about how
> "free" the GPL is or isn't. If people want to use the GPL as a
> convenient punchbag, I think they have to work a bit harder justifying
> their gym subscription.)

Blame the GPL and FSF for the confusion.

Try this little experiment: Walk up, at random, to 100 people on the
street.  Show them a software CD-ROM -- a game, a word processor,
whatever.  Tell them it's free.  Then ask them what they think that
means.

99 times out of 100, they'll think it means it's free-as-in-beer.
They *won't* think it means they'll get the source code, and the right
to tweak that source code.  They *won't* think it means they have the
right to infinitely redistribute it.

At best, the GPL/FSF engaged in what I consider false advertising.
Free Software (note the capital 'F' and 'S') *isn't*, by the most
widely understood and assumed definition of "free".  They should have
called it "liberated software" or "share and share alike software" or
"free as in herpes" software.  Free Software is certainly not free
software, since it comes heavily encumbered by licensing issues.

The success of things like Python -- which is not GPL licensed, afaik
-- pretty much proves the GPL is unnecessary for the success of free
projects.  The GPL is just some bizarre social agenda being pushed by
some crazies, and a lot of programmers (who are not lawyers) fell for
the hippie nonsense.

So, you may like to bandy around the mildly offensive "free as in
freeloading", but then that gives me the right to refer to GPL'd
software as "free as in pushing my personal social agenda".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python obfuscation

[Ed Jensen]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> I'm not sure if that is meant to be a rhetorical 
> question or not, but something of the order of 95% of 
> all software written is never distributed to others, 
> and so copyright or the lack of copyright is not an issue.

Can you cite your source(s) for this information?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs Ruby

[Ed Jensen]

Bryan <[EMAIL PROTECTED]> wrote:
> i would not say sion's ratio of 5:1 is dubious.  for what it's worth, i've 
> written i pretty complex program in jython over the last year.  jython 
> compiles 
> to java source code and the number of generated java lines to the jython 
> lines 
> is 4:1.

Most code generators are known to produce non-optimal code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs Ruby

[Ed Jensen]

Sion Arrowsmith <[EMAIL PROTECTED]> wrote:
> I have here a library (it's the client side of a client-server
> interface including a pile of class definitions) which has
> implementations in pure C++, Java and Python, taking about 3000,
> 3500 and 1500 loc respectively. And there's an associated module
> (with no C++ implementation) that I remember being particular
> "impressed" while writing it to find being 3 times as long in Java
> as Python despite (a) extensive (and pretty much common) Javadoc/
> docstrings and (b) implementing in the Python version a feature
> present in the standard Java library (scheduling a thread to run
> at specified intervals and time out). Strip the Javadoc/docstrings
> out and it's about at that 5:1 ratio.

This claim seems pretty dubious to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UI toolkits for Python

[Ed Jensen]

Kenneth McDonald <[EMAIL PROTECTED]> wrote:
> I'd have to agree with this. Unfortunately, the only way to use Swing  
> (in a
> reasonable manner) from Python is to use Jython, and Jython has other
> shortcomings that make me not want to use it.

What shortcomings?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UI toolkits for Python

[Ed Jensen]

Claudio Grondi <[EMAIL PROTECTED]> wrote:
> I haven't seen any really platform-independent software yet and I don't
> expect to see any in the future.
> It is simply not possible to have one, even if much progress was done lately
> in many areas in order to try to approach it as close as possible.

Java + Swing is probably as good as it gets when the goal is to write
platform independent software.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: extreme newbie

[Ed Jensen]

Renato Ramonda <[EMAIL PROTECTED]> wrote:
> The only system (apart from solaris, I guess) that has a JVM by default 
> is OSX, and it's _NOT_ sun's one, but the internally developed one.

Apple licenses Sun's JVM and makes the modifications necessary to run
it on OSX.  I know I'm being a pedant, but I don't want people to
think Apple writes their own JVM from scratch.  Also, Java is
installed on lots of systems by companies like Dell and HP; however,
you usually can't predict which version of the JVM is installed or how
the Java auto update features are configured.

That being said, I think Sun is being foolish by not ensuring Java is
free enough to be included with every Linux distribution.  Talk about
letting a golden opportunity slip through their fingers...

As others have pointed out, Python's non-restrictive licensing allows
it to be installed far and wide, and it's easy to bundle a Python
interpreter with your application, which is great.  These are big
advantages for Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: extreme newbie

[Ed Jensen]

Grant Edwards <[EMAIL PROTECTED]> wrote:
>> I've guessed that python is purely an interpreted language unless its
>> compiled into another language (ie. it needs python installed in order
>> to run programs). Is this correct?
> 
> It's just like Java.  It's compiled into bytecode and then the
> bytecode is executed on a virtual machine.

Keep in mind that all modern JVMs "just-in-time" compile Java bytecode
to native code.  It looks something like this:

Java source -> Java bytecode -> Java virtual machine -> Native code

So, in the end, users are typically running natively compiled code.

(Warning: This is a simplification, but this description seems
adequate for the OP.)

Java typically outperforms Python by a very wide margin.
-- 
http://mail.python.org/mailman/listinfo/python-list