Python article in Free Software Magazine

[Kirk Strauser]

I wrote this article which was published in Free Software Magazine:

http://www.freesoftwaremagazine.com/free_issues/issue_09/intro_zope_1/

It's intended as a high-level overview of the language, and therefore
glosses over some of the details. For example, I describe its function
calling mechanism as pass-by-reference, because that's close enough for
newcomers to get the gist of it.

Anyway, the article's available under an open license. If you like it, feel
free to pass it around. Enjoy!

 

[Gerard Flanagan]

I wrote this article which was published in Free Software Magazine:

http://www.freesoftwaremagazine.com/free_issues/issue_09/intro_zope_1/

It's intended as a high-level overview of the language, and therefore
glosses over some of the details. For example, I describe its function
calling mechanism as pass-by-reference, because that's close enough for
newcomers to get the gist of it.

Anyway, the article's available under an open license. If you like it, feel
free to pass it around. Enjoy!

It's a good article and well written. I've heard Zope mentioned quite
often but don't know a thing about it, so I'll be looking forward to
the next installment!


Gerard

 

[Steven D'Aprano]

I wrote this article which was published in Free Software Magazine:

http://www.freesoftwaremagazine.com/free_issues/issue_09/intro_zope_1/

It's intended as a high-level overview of the language, and therefore
glosses over some of the details. For example, I describe its function
calling mechanism as pass-by-reference, because that's close enough for
newcomers to get the gist of it.

Then what you are describing is not Python, it is some mythical language
that is almost like Python, but just enough like C to confuse programmers
who think they have discovered a bug when the following doesn't work:

def increment(n, inc=1):
n += inc

n = 1
increment(n)
assert n == 2


Firstly, do no harm: if you aren't prepared to bite the bullet and say
"call by object" or "call by object reference", then just don't do
it. It is better to not say what Python is than to describe it as
something it is not. Please don't invoke all the C baggage in developers'
minds by calling it call by reference.

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.

(Amazing how the Java virtual machine is one of the great buzz-word
selling features of the language, and yet Python people take it utterly
for granted.)

We both know that rational people shouldn't care about the difference
between compilers and interpreters: it is performance that counts, not
how you get it. We know that Python doesn't literally analyse the source
code over and over again, and no major interpreted language has done this
for probably two decades or more. We can argue about the differences
between interpretation, tokenization, compilation and execution, and
pedants like me will mention that machine code is interpreted by the CPU.

But sadly, many decision makers don't understand these subtleties. To
them, compiled languages like C++ and Java are Good, interpreted languages
are Bad and doomed to be slow and weak. As soon as you describe
Zope/Python as "interpreted", you turn off maybe 25% or 50% of the Pointy
Haired Bosses who are making the decision of what technologies are used.

Buzz-words like "interpreted" and "compiled" trigger frames in the
reader's mind. They have connotations. You, as the author, aren't
responsible for the wrong-headed frames that many readers will bring
to the article, but you should be aware of them and work around them if
you can.

 

[bonono]

Then what you are describing is not Python, it is some mythical language
that is almost like Python, but just enough like C to confuse programmers
who think they have discovered a bug when the following doesn't work:

def increment(n, inc=1):
n += inc

n = 1
increment(n)
assert n == 2

I assume you mean C++, not C. As in C

int n=1;
void increment(int *n)
{
n+=1
}
assert(n==2); /* this one would fail */

Behave exactly like your sample.

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.

(Amazing how the Java virtual machine is one of the great buzz-word
selling features of the language, and yet Python people take it utterly
for granted.)

We both know that rational people shouldn't care about the difference
between compilers and interpreters: it is performance that counts, not
how you get it. We know that Python doesn't literally analyse the source
code over and over again, and no major interpreted language has done this
for probably two decades or more. We can argue about the differences
between interpretation, tokenization, compilation and execution, and
pedants like me will mention that machine code is interpreted by the CPU.

But sadly, many decision makers don't understand these subtleties. To
them, compiled languages like C++ and Java are Good, interpreted languages
are Bad and doomed to be slow and weak. As soon as you describe
Zope/Python as "interpreted", you turn off maybe 25% or 50% of the Pointy
Haired Bosses who are making the decision of what technologies are used.

I don't see that as a problem. In fact, it alarms them the right way.
For those who don't care(I met many who don't, so long the technology
delivers the end result, they don't want to know the difference or the
buzz words), it doesn't matter. For those who knows a little bit(even
not the detail) and care, this "interpreted" term gives them the right
reason to ask :

1. would that be slow ?
2. does it mean the source cannot be reasonably seperated from the end
product ?

 

[Dan Sommers]

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

So does <http://www.python.org/doc/Summary.html>.

Regards,
Dan

 

[Steven D'Aprano]

So does <http://www.python.org/doc/Summary.html>.

Then it is time it stopped.

In fairness, from a technical perspective, describing Python as
interpreted is not wrong -- as I've pointed out, machine code is
interpreted too -- but neither does it give the correct impression.
Many people have argued that the terms interpreted and compiled are no
longer meaningful in this day and age. I wouldn't go that far, but given
the negative connotations of "interpreted" I think it is both better and
more accurate to emphasis the fact that Python code is byte-code compiled
and only use the I-word when discussing Python's interactive environment
and eval/exec. If I could think of another word for interpreter, I would
use it even then.

People who are smart and care about correctness -- the "reality-based
community" -- often don't realise just how many decisions are made on the
basis of unfacts like "everybody knows interpreted languages are slow and
inefficient, that's what my professor told me when I did a semester of C
in 1982, we better stick to Java or .Net".

 

[Steven D'Aprano]

I don't see that as a problem. In fact, it alarms them the right way.
For those who don't care(I met many who don't, so long the technology
delivers the end result, they don't want to know the difference or the
buzz words), it doesn't matter. For those who knows a little bit(even
not the detail) and care, this "interpreted" term gives them the right
reason to ask :

1. would that be slow ?
2. does it mean the source cannot be reasonably seperated from the end
product ?

Dude, if they had the sense to ask the question "Will this be slow?" they
won't be a PHB now will they?

They should be asking these questions about *any* technology. If you care
about keeping your algorithms secret, you should be asking about source
code, and debugging information, and how easily can attackers disassemble
your code, not just assuming "oh it is compiled, it will be fine". If you
care about speed, and let's face it, we all care about speed, you should
ask how fast the code will run regardless of what language it is written
in. I can write C code that will run slower than Python code, and take
longer to do it too.

I'm not worried about people having the sense to judge Python on its
merits. If Python is not suited for a particular job, then we would not
be doing anyone any favours to push Python for that job. I'm worried
about people who pre-judging (as in prejudice) Python negatively on the
basis of buzzwords they barely understand.

 

[bonono]

I'm worried
about people who pre-judging (as in prejudice) Python negatively on the
basis of buzzwords they barely understand.

For those with prejudice, it doesn't matter anyway.

 

[Ernst Noch]

Then it is time it stopped.

In fairness, from a technical perspective, describing Python as
interpreted is not wrong -- as I've pointed out, machine code is
interpreted too -- but neither does it give the correct impression.
Many people have argued that the terms interpreted and compiled are no
longer meaningful in this day and age. I wouldn't go that far, but given
the negative connotations of "interpreted" I think it is both better and
more accurate to emphasis the fact that Python code is byte-code compiled
and only use the I-word when discussing Python's interactive environment
and eval/exec. If I could think of another word for interpreter, I would
use it even then.

People who are smart and care about correctness -- the "reality-based
community" -- often don't realise just how many decisions are made on the
basis of unfacts like "everybody knows interpreted languages are slow and
inefficient, that's what my professor told me when I did a semester of C
in 1982, we better stick to Java or .Net".

Right on. Here's a tongue-in-cheek proposal for the python.org homepage
to describe a combination of python, twisted and zope or something similar.
It yields a 10 on the buzzword meter, but is unfortunately blatantly stolen:

"""
Today, more and more developers want to write distributed transactional
applications for the enterprise and leverage the speed, security, and
reliability of server-side technology. If you are already working in
this area, you know that in today's fast-moving and demanding world of
e-commerce and information technology, enterprise applications have to
be designed, built, and produced for less money, faster, and with fewer
resources than ever before.

To reduce costs and fast-track enterprise application design and
development, the Python Platform Enterprise Edition technology provides
a component-based approach to the design, development, assembly, and
deployment of enterprise applications. The Python Enterprise platform
gives you a multitiered distributed application model, the ability to
reuse components, a unified security model, and flexible transaction
control. Not only can you deliver innovative customer solutions to
market faster than ever, but your platform-independent Python
component-based solutions are not tied to the products and APIs of any
one vendor.

"""

 

[Kirk Strauser]

I don't want to nit-pick all my way through the article,

There's nothing wrong with that, and if I hadn't been prepared for it, I
wouldn't have posted the link in here.

You have fair points. Unfortunately, though, the word length of the article
just didn't provide enough space to go into the level of detail those
subjects would have required. I tried to compromise by giving the answer
that most closely fit the situation without being exactly correct.

By the way, the author style guides say to write for an audience with
technical background. That article was meant for you, not your boss.

 

[Ed Jensen]

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.

 

[Ed Jensen]

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.

 

[Terry Hancock]

You have fair points. Unfortunately, though, the word
length of the article just didn't provide enough space to
go into the level of detail those subjects would have
required. I tried to compromise by giving the answer that
most closely fit the situation without being exactly
correct.

I find that it's not difficult to explain Python object
handling if you simply insist on the concept of "name
binding" instead of "variable assignment":

a = 1

in C puts the value "1" in the variable "a" as if it were a
box that can hold values, while in Python it tacks a virtual
sticky note "a" on the object "1". I don't know anything
about Lisp, but I have gathered that Python's name-binding
behavior is conceptually similar to it.

Once you have this concept, most of the rest of Python's
behavior follows naturally. Makes for a nice figure, too,
which Free Software Magazine needs more of.

 

[Kirk Strauser]

I find that it's not difficult to explain Python object handling if you
simply insist on the concept of "name binding" instead of "variable
assignment":

That was a pretty good explanation. I'll probably use that next time.

Makes for a nice figure, too, which Free Software Magazine needs more of.

?

 

[Michele Simionato]

Kirk Strauser:

I wrote this article which was published in Free Software Magazine:
http://www.freesoftwaremagazine.com/free_issues/issue_09/intro_zope_1/

If find funny your headline

"""
Zope's biggest distinguishing characteristic is how closely it models
the language it is written in:
Python
"""

when I think Zope is the less Pythonic application I have ever seen

 

[Kirk Strauser]

when I think Zope is the less Pythonic application I have ever seen

You do? Why so? I'm not arguing, but that's different than my experience
with it and I'm curious about how you reached that conclusion.

 

[Claudio Grondi]

Michele Simionato wrote:




You do? Why so? I'm not arguing, but that's different than my experience
with it and I'm curious about how you reached that conclusion.

I can remeber, that I had took a look at Zope and was not able even to
find out what it is about. From that time on I haven't touched it again
and probably never will unless someone shows me, what is it good for and
how can it help me. In case this above happens to me with software
packages or source code I describe it usually as non-Pythonic way of
programming applications or writing source code.

Claudio

 

[Michele Simionato]

Some of the reasons are explained here:

http://www.amk.ca/python/writing/why-not-zope.html

I am using the last Zope (2.8.4) at work, and the situation is slightly
better now than in the past,
but only slightly. Zope 3 looks better, but I am not sure how much
better.

Michele Simionato