Python Evangelism

T

Tim Churches

Benny said:
To emphasize the point as a newbie: I know what CPAN is. I would go to
the Vaults of Parnassus for Python stuff. But Cheese Shop?

I like the irony of the name Cheese Shop, but I do think that there is a
problem with "Shop", as it typically means a place where you buy things
for money. However, the vast majority of the cheesy comestibles at the
Cheese Shop are available for free. In fact, of 1287 packages currently
listed there, only 7 have non-free or proprietary licenses. Actually, it
was the "National Cheese Emporium" in the original sketch, although Mr
Wensleydale does describe it as a cheese shop - but both "shop" and
"emporium" are used to describe places of commerce. On re-acquaintance,
the sketch itself is still very funny after all these years, except
perhaps for the ending, in which Mousebender shoots dead Mr Wensleydale
for deliberately wasting his time. In the early 1970s in Britain, when
shooters were possessed by a very small minority of blaggards, that
might have been funny, but in the early 21st century, I find it grates a
little (no pun intended) - I can imagine the same fate befalling a
latter-day Wensleydale in a different country who happens to be fresh
out of meira. But I am sure ESR would defend Mousebender's right to blow
poor Wensleydale away - see http://www.catb.org/~esr/guns/gun-ethics.html .

So is there an alternative Monty Python sketch which has a theme of
purveyance as opposed to commerce? None spring to mind.

Tim C
 
T

Terry Reedy

Tim Parkin said:
Definitely

I have to say I prefer pypi myself.

Strongly prefer. Cheeseshop made no sense to me until explained.
I think it's a great idea
subtitling it 'cheeseshop' but referring to it directly as "cheeseshop"
is confusing at best.

I think PieShop would be much funnier as a double pun on Py/Pi and as a
subtle Python riff on the Cheeseshop sketch for those familiar with the
latter. I also remember something about a Python/Parrot pie fight.
I've already had a few requests to change the text
of the link on the home page to 'packages' or 'package index'.

Please at least make it a synonym.

Terry Jan Reedy
 
M

Michael Tobis

The name isn't changing, so it's a "make lemonade" situation.

What's the best use we can make of the name; how do we make it stick in
people's minds positively? How do we make a positive image out of it?

Shy tadpoles, by the way, ( http://python.org/images/python-logo.gif )
isn't it.

mt
 
T

Tim Churches

Would it be possible to rename "Cheese Shop" as "Bright Side of Life"?

That's a cheery, upbeat name, there are overtones of commerce or filthy
lucre, it is a clear reference to one of the Monty Python crew's
greatest works, it can be easily abbreviated to BSOL (to avoid confusion
with BSL for blood sugar level, and to have some resonance with another
well-known Python acronym, BDFL), it is associated with a memorable
theme tune which, appropriately, reminds one to always look on the BSOL
(see http://www.geocities.com/fang_club/Bright_side_of_life.html for the
lyrics), one can install an (ALOT)BSOL ringtone on your mobile (cell)
phone if one wishes like - see (or hear) for example
http://www.niksula.cs.hut.fi/~ajvaanan/p_80861/ , and it possesses a
certain irony just like the original Cheese Shop allusion.

So, BSOL instead of Cheese Shop? I am quite prepared to be crucified
(cheerfully) for this suggestion.

Tim C
 
T

Tim Churches

Tim said:
Would it be possible to rename "Cheese Shop" as "Bright Side of Life"?

That's a cheery, upbeat name, there are overtones of commerce or filthy
lucre,

I meant "no overtones", mea culpa.

Tim C
 
P

Paul Boddie

Tim said:
Would it be possible to rename "Cheese Shop" as "Bright Side of Life"?

Well, you could replay the conversation I gave as an example elsewhere
to see if it sounds ridiculous or not, but what we've encountered here
is the problem of whether something should be given a distinctive
identity or a derivative identity. A long time ago, and possibly
continuing to this day, people complained about how nearly every Python
package, module or program had names starting or ending with "Py" -
announcing a module in a Python newsgroup and giving it a name starting
with "Py" seemed somewhat redundant, and there was always the issue of
not being able to scan long lists of packages comfortably, just like
with all the KDE application names that start with the letter K.

But even without "the curse of Py", many people don't just choose
arbitrary names for their packages: it often makes sense to include
related technologies in the name (eg. XML, XSLT, ado, dav), or to use a
descriptive component, possibly in shortened form (eg. auth, bayes,
bio, Cal). Yes, a search will often bring forth the right resource
regardless of what it's called, but many people underestimate their own
searching skills and overestimate what other people can find via things
like Google.

Of course, programs may downplay Python as the implementation
technology because the underlying technical details are mostly
irrelevant to end-users (eg. BitTorrent, b3, Eric, Glarf), but if we
look at distinctively named packages, we can see that they often
attempt to define their own identity distinct from Python (eg.
BeautifulSoup, Dabo, DejaVu, Django, Twisted, Zope), frequently because
they seek to be the primary point of reference for developers -
developing in Twisted or Zope is more specialised than just developing
things in Python. Some of the distinctively named package names employ
metaphors and/or cultural references that possibly make them more
memorable, but they don't necessarily make the names easy to guess.

So should a service for finding Python packages have a distinct
identity? It is possible that a package index could be someone's
principal view of the Python world ("I go to Camelot to get... what is
it I get there?"), but the things that emerge from such a service
aren't just downloads that have little in common with each other.
Consequently, I don't think a descriptive name, derived from the name
of the technology, is sensibly avoided in this case.

Paul
 
K

Kay Schluehr

Paul said:
Well, you could replay the conversation I gave as an example elsewhere
to see if it sounds ridiculous or not, but what we've encountered here
is the problem of whether something should be given a distinctive
identity or a derivative identity. A long time ago, and possibly
continuing to this day, people complained about how nearly every Python
package, module or program had names starting or ending with "Py" -
announcing a module in a Python newsgroup and giving it a name starting
with "Py" seemed somewhat redundant, and there was always the issue of
not being able to scan long lists of packages comfortably, just like
with all the KDE application names that start with the letter K.

But even without "the curse of Py", many people don't just choose
arbitrary names for their packages: it often makes sense to include
related technologies in the name (eg. XML, XSLT, ado, dav), or to use a
descriptive component, possibly in shortened form (eg. auth, bayes,
bio, Cal). Yes, a search will often bring forth the right resource
regardless of what it's called, but many people underestimate their own
searching skills and overestimate what other people can find via things
like Google.

Of course, programs may downplay Python as the implementation
technology because the underlying technical details are mostly
irrelevant to end-users (eg. BitTorrent, b3, Eric, Glarf), but if we
look at distinctively named packages, we can see that they often
attempt to define their own identity distinct from Python (eg.
BeautifulSoup, Dabo, DejaVu, Django, Twisted, Zope), frequently because
they seek to be the primary point of reference for developers -
developing in Twisted or Zope is more specialised than just developing
things in Python. Some of the distinctively named package names employ
metaphors and/or cultural references that possibly make them more
memorable, but they don't necessarily make the names easy to guess.

So should a service for finding Python packages have a distinct
identity? It is possible that a package index could be someone's
principal view of the Python world ("I go to Camelot to get... what is
it I get there?"), but the things that emerge from such a service
aren't just downloads that have little in common with each other.
Consequently, I don't think a descriptive name, derived from the name
of the technology, is sensibly avoided in this case.

Paul

The problem I have with the cheese-shop is less a naming but a
usability issue. In some commercial projects that involve Python I
already integrated SQLite as a local database for storing and
retrieving all kind of configuration data as well as session data,
failure statistics etc. I also extended a Python console in order to
send SQL commands directly using this syntax "$ select * from reports
where...". I should mention that this kind of integration was one of
the most acknowledged features by those who where Python sceptics. I
wonder if creating a database client, integreting it with a Python
console and shipping it with a Python setup would not leave behind all
other solutions in the field? BTW I'm not only intererested in the
functionality of a package but how well it performs how well it is
tested etc. The packages checked into the cheese-shop obtain already a
rough classification. If classification schemes become more usable it
is likely that they could be extended.

Kay
 
M

Michael Tobis

I like cheeseshop just fine, but have been a Monty Python fan since
they appeared on the CBC in, I think, 1969. I'm one of those people who
is always surprised when a MP bon mot is greeted with confusion and the
suspicion that I have finally lost my mind altogether. So...

If we are moving to the snake motif (which probably would be better
marketing):

"Pythons lay eggs which they arrange in a pile. They coil around the
pile until all eggs have hatched. Since pythons cannot regulate their
internal body temperature, they cannot incubate their eggs per se;
instead, they raise the temperature of their eggs by small movements of
their body-essentially, they "shiver". This is one of only a few
documented cases of parental behaviour in snakes."
--Wikipedia article "python"

Pythons build no nests. Their eggs are found in coils. coil.python.org
?

Tadpoles ( http://python.org/images/python-logo.gif ) are immature
frogs. If we keep the logo, we can change the name of the language to
"frog". Then the eggs would be found in lilypad.frog.org . I personally
do not like this choice but it would have the virtue of consistency.
(Did I mention that I don't like the logo?)

mt
 
T

Torsten Bronger

Hallöchen!

Michael Tobis said:
[...]

Pythons build no nests. Their eggs are found in coils. coil.python.org
?

Better eggs.python.org. Would support the spread of the new file
format, too.

Tschö,
Torsten.
 
C

Christos Georgiou

Tim Churches wrote:

[Paul]
So should a service for finding Python packages have a distinct
identity? It is possible that a package index could be someone's
principal view of the Python world ("I go to Camelot to get... what is
it I get there?"), but the things that emerge from such a service
aren't just downloads that have little in common with each other.
Consequently, I don't think a descriptive name, derived from the name
of the technology, is sensibly avoided in this case.

I like the BSOL idea, but in that case what will the package extension be
instead of .egg? camelot.python.org has the advantage of suggesting an
obvious extension: .graal

So you go to the Camelot to get the graal (or one of them :). In case this
catches on, I'd like to upload ASAP one of my packages [1] called "wholy".

PS "Grail" was a web browser written in Python (or an attempt at one).


[1] It's mostly useless but I trust wholy.graal will be downloaded by
millions.
 
D

Douglas Alan

Andrew Gwozdziewycz said:
Douglas Alan wrote:
I'll admit "Ruby on Rails" is a clever name. The fact that you
mention it "didn't catch on" is only partially true.

I'm sorry if I wasn't clear. By "didn't catch on", I only meant that
it had little mainstream success. At least in the US. I'm certainly
aware that it has had a significant community of devotees for some
time now.
Rails did however jump start it's new career as the definitive
web2.0 language, but who cares? Not me!

Well, I'm not sure that the threat to Python is being fully
appreciated here. I have friends who are fully convinced that Python
is doomed because Ruby has all the buzz now. I think that their
predictions of doom and gloom for Python are overstated. For one
thing, I point out to them that Rails is what really has all the buzz,
not Ruby per se. But such subtle distinctions seem to often get lost
in the type of buzz that causes technologies to succeed or fail. This
is an example of how names are indeed very important.

There *is* a serious worry here. For instance, look how PHP
completely decimated Perl in its biggest market niche at the time (CGI
programming) in just a couple of years. PHP couldn't use that
advantage to threaten the more general scripting niches, but unlike
PHP, Ruby might certainly be able to leverage that advantage, as it is
also a perfectly good general-purpose programming language. Ruby's
domain is not limited to just server-side web scripting.

For those who don't believe that Ruby on Rails does have an incredible
amount of buzz going for it right now, I do have a number of personal
data points that seem to indicate that it is indeed undergoing
exponential growth at the moment: (1) I'm sitting in on a class at MIT
on developing web applications. For their projects and assignments,
the students are allowed to chose whatever programming languages,
databases (as long as they are ACID-compliant), and development
environments that they prefer. From what I can tell, more than half
of the class is using Ruby on Rails. One group is using C# and .NET.
Another is using JSP. No one is using PHP. No one is using Django.
One group was doing straight Python CGI, but I think they switched to
Rails. (2) I've started to see advertisements for web hosting
services where the ads say, "PHP! MySQL! Rails!". (3) I have
friends who work in companies that are big Python shops, but they seem
to be moving to Rails for web development.
Hell I like django quite a bit, but anyone writing something for
django knows it's written in python.

Yes, and for Rails, everyone who has never even seen a single line of
Ruby code knows that it is Ruby-based. The same cannot be said for
Django.
If some non-programmer decided to create a new web app, and his
friend said, 'I hear django is quick and oh, it use's this really
cool easy to learn language python,' What's the difference?

There's a huge difference. Ruby on Rails gives Ruby great brand
recognition, while Django does nothing at all for Python's brand
recognition. Just pay attention to TV commercials: a large fraction
of them have nothing to say whatsoever about the merits of their
product -- the ads just want to get the brand name into your head.
For better or worse, this is how human psychology works.

In any case, it's almost certainly too late for Django to achieve the
kind of popularity that Rails is achieving; if you Google
"web-development rails", you get 3 million hits, while if you Google
"web-development django", you get 82,000 hits. So, unfortunately, how
to best use Django to help popularize Python is almost certainly moot
at this point.

|>oug
 
J

John Pote

If I get time I'll expand my thoughts and experiences but for now,
Don't know what Ruby on Rails is but it's catchy and current high volume of
interest makes me think - I should look into it. Django, skip reading this
thread before and I had not even picked up it was a Python product (still
don't know what it is too little time to look!)

Python seems to concentrate on language development rather than environment
development. Programmer productivity depends much more on the associated
environment - docs, code editor, libraries, wysiwyg GUI designer - than the
language. So far my experience is that the further away from the core
language the worst things get. My principle moan about the standard library
is lack of formal stating of ALL exceptions that can be thrown by a module.
Sometimes the detail is burried in the general text about the module which
makes it difficult to eye ball quickly. httplib does not mention any of the
socket module exceptions that can be thrown. This makes it difficult to
write stable bullet proof code.

Finding myself slowed down too much by hand coding tkinter (and modifying it
weeks later) I've switched to wxPython and Glade. Certainly better but
wxPython docs are not ideal. (only reason for switching is lack of wysiwyg
GUI designer for it)

I get a myApp.pyw working on one machine. Copy to another and maybe forget
something (usually updating my own python library so a header import fails)
and what happens? nothing if tkinter has not yet fired up the gui. and even
if it has and there's an uncaught exception the app just closes. Any error
message and traceback are dumped because there's no dos box.

On the positive side Twisted (I have the docs and book) looks exactly what I
need in all respects.

I think the language has already made Python, the rest is down to its
'environment'.

Best wishes to everyone,

John Pote
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,599
Members
45,175
Latest member
Vinay Kumar_ Nevatia
Top