(slightly OT): Python and linux - very cool
TuxTrax
provides. While it is true that these tools are often available on
other platforms, they just *seem* to work more smoothly in linux, and
are alot easier to learn. I don't know. maybe it's just me. But Python
is a good example: I first learned of python in my windows days. Back
then, if it didn't have a GUI frontend, I wasn't interested. Geeze, I
should have known better; it wasn't like I was still wet behind the
ears. But I really didn't like IDLE, and soon lost interest in Python.
I don't know exactly why, but I don't take much to Idle, pythons
gui. It seems to get in the way. It's alot easier to fire up emacs
(since emacs has a python mode and makes python programming a snap)
from an xterm and away I go. Now it could be argued that I am still
relying on my GUI. Actually, I just like the way emacs looks from x. I
am doing everything else from the command line in the term, mainly
because of how simple it makes life. I mean I wouldn't have believed
it before, but you know, a GUI can really slow you down.
Anyway, when I left microsoft behind for good, I discovered that
mandrake had set up python as part of the default install (along with
alot of other really top-drawer development tools). I remembered the
show "call for help" that I used to watch on ZDTV (now techtv), a
program for windows users hosted (and this is a hoot) by a couple of
IT guys that just happen to both be mainly linux and mac users!
Anyway, they had suggested python as a good first language, and I had
been looking for a good language to get my feet wet after a long
abscense from programming. So when I saw that it was in my default
Linux install, I got curious again. I am a rank newbie. I mean, a real
baby in my python education. I have a good understanding of basic
programming concepts, which makes things easier, but I am learning to
potty train when it comes to learning python.
Having said that, I asked for a reference in this group for some
information about NNTP protocols for experimenting in python.
Jim steered me to pythons standard NNTPLIB and suggested I not
reinvent the wheel. Boy was he right. With Python, it was so easy to
access news servers "raw" that I had to pick up my jaw off the
floor. Jeeze! In 45 minutes, I whipped up a program that I *could*
*not* have done in the $100.00 visual basic 6.0 learning edition that I
had, because VB learning edition intentionally lacks the sockets
libraries (or it did when I bought it). That's so you will buy the VB
developers pack for what, $400.00? $500.00?
What do I have to say about VB? "It's dead Jim".
This is the code I whipped up. It opens a connection to the server,
and gets the ident and stats. It then prints the last 10 available
messages before closing the connection. No big deal. But for this
newbie, a very big deal.
#####################################
# load needed libraries and modules #
#####################################
# load module required for interfacing to usenet servers
# via NNTP. Documentation for this library is at:
# http://www.python.org/doc/current/lib/module-nntplib.html
from nntplib import *
# Load sys module for system calls like argv[]
from sys import *
################################
# Declare persistent variables #
# (yes I know I don't have to) #
################################
# news server - replace with your own server
nntpserver = "news.yourserver.com"
# newsgroup we are interested in
newsgroup = "comp.os.linux.advocacy"
#################
# Begin program #
#################
# Open connection to server
s = NNTP(nntpserver)
# Ask the sever for it's welcome message (usually just a system ID)
# if one is available. Print the message. Min. response is a three digit code
welcome = s.getwelcome()
print "\n\nOpening connection to", nntpserver
print "querying server for login message ....."
if len (welcome) < 3:
print "\nServer has no response to query. Don't worry, it happens."
else:
print "\nServer says: ", welcome
# Retrieve and print information on the newsgroup we are interested in
print "\n\n"
resp, count, first, last, name = s.group(newsgroup)
print "Group", name, "has", count, "articles, range", first, "to", last
print
# Retrieve and print subject information
resp, subs = s.xhdr("subject", first+"-"+last)
for id, sub in subs[-10:]: print id, sub
# close the connection
s.quit()
###############
# End program #
###############
Some of this is borrowed from the NNTPLIB example page.
Elegant, isn't it? Python is like that. So simple, yet so
powerful. And alot of the work has been done for you already. Like the
NNTPLIB module. or the SMTPLIB module. They make accessing servers
with these protocols painless.
Python is what BASIC should have been. Easy for beginners, powerful
for advanced applications, able to seamlessly integrate with C, object
oriented. I *love* this language.
I said that it seems to just work better in Linux. I should have said,
there are snags in windows that have to do with the way windows
handles things. For instance, the line:
from nntplib import *
should make all of nntplib's methods available to the calling
program. However, a known problem (for which there is a workaround -
as is the way with windows) is that due to windows file system quirks,
the libraries are not always in the same place, or with the same
names. for instance, according to the docs, windows often will
capitalize an 8.3 filename all on it's own, or not treat spaces
correctly. The trolls will jump on this, but I trust the python docs
more than I trust the word of trolls. And it is in line with my
experiences.
Stuff just works better in Linux. What else can you say.
Oh, I know what else ..... PYTHON ROCKS!
Cheers,
Mathew
XPosted: comp.os.linux.advocacy, comp.lang.python
--
TuxTrax (n.) An invincible, all terrain, Linux driven armored assault
vehicle that can take as much fire as it gives ;-)
Yes, I am a Penguin cult high priest. Flipper readings upon request.
ROT13 this email address to mail me: uvtuqr...@lnubb.pbz
rapskat
- dump details are as follows...
> Python is what BASIC should have been. Easy for beginners, powerful for
> advanced applications, able to seamlessly integrate with C, object
> oriented. I *love* this language.
I don't know what else I could possibly add to this besides a lame "me too!"
Awesome post! :-)
--
rapskat - 6:05am up 1 day, 6:37, 0 users, load average: 0.76, 0.74, 0.66
116 processes: 113 sleeping, 2 running, 1 zombie, 0 stopped
CPU states: 14.0% user, 4.5% system, 0.0% nice, 3.4% idle
drop the hot to mail me
By working faithfully eight hours a day, you may eventually get to be
boss and work twelve.
-- Robert Frost
RPM1
"TuxTrax" <Tux...@fortress.tuxnet.net> wrote in message
news:slrnakhuhq....@fortress.tuxnet...
> This is the code I whipped up. It opens a connection to the server,
> and gets the ident and stats. It then prints the last 10 available
> messages before closing the connection. No big deal. But for this
> newbie, a very big deal.
>
Interesting, I just did the same thing, (on Windows). I have some extra
functionality,
'!' - Prompt for group and get last 10 posts from the group.
'+' - Get next 10 posts.
'-' - Get previous 10 posts
'*' - Reprint the current list of posts
0..9 - Show post #x of the current list
'quit' - To quit
Here's the code I whipped up, (in about 90 minutes). It's kind of ugly but
it works:
######## Start ############
from nntplib import *
def displayPosts(s,start,last):
resp, subs = s.xhdr('subject', start + '-' + last)
subs.reverse()
count = 0
for id, sub in subs:
header = s.head(id)
dateWhen = ''
fromWho = ''
subjectWhat = ''
for x in header[3]:
if x.find('From:') != -1:
fromWho = x
if x.find('Subject:') != -1:
subjectWhat = x
if x.find('Date:') != -1:
dateWhen = x
dateStart = dateWhen.find(':')
if dateStart < 0:
print count, sub
else:
print count, sub, dateWhen[dateStart:]
count += 1
return subs
s = NNTP('news.readfreenews.net')
stepSize = 9
finished = 0
g = 'None'
newsPrompt = 'news> '
while not(finished):
response = raw_input(newsPrompt)
if response.find('quit') != -1:
break
if response.find("+") != -1:
if (int(last) + stepSize) > int(groupLast):
start = str(int(groupLast) - stepSize)
last = groupLast
print 'End of articles'
else:
start = str(int(start) + stepSize)
last = str(int(last) + stepSize)
subs = displayPosts(s,start,last)
if response.find("-") != -1:
if (int(start) - stepSize) < int(groupFirst):
print 'Beginning of articles'
start = str(int(groupFirst))
last = str(int(start) + stepSize)
else:
start = str(int(start) - stepSize)
last = str(int(last) - stepSize)
subs = displayPosts(s,start,last)
if response.find('!') != -1:
g = raw_input('Group? : ')
print
print g
print
try:
resp, count, groupFirst, groupLast, name = s.group(g)
except:
continue
print 'Group', name, 'has', count, 'articles, range', groupFirst,
'to', groupLast
newsPrompt = name + '> '
start = str(int(groupLast) - stepSize)
last = groupLast
subs = displayPosts(s,start,last)
if response.isdigit():
if g != 'None':
articleNumber = int(response)
if articleNumber > 9 or articleNumber < 0:
continue
id, sub = subs[articleNumber]
bodyInfo = s.body(id)
header = s.head(id)
print
print 'Header =============================='
print
for x in header[3]:
if x.find('From:') != -1:
print x
if x.find('Subject:') != -1:
print x
if x.find('Date:') != -1:
print x
print '====================================='
print
for l in bodyInfo[3]:
print l
else:
print 'No newsgroup loaded'
if response.find('*') != -1:
subs = displayPosts(s,start,last)
s.quit()
######## End ############
Patrick
Fabian Suceveanu
<SNIP>(its a bit long)
Whoah. I started Vpython and Python when I was in my Wind0z3 days, too! I
then gave it up for Pascal (dumb move) and then I gave up Pascal for
learning C/C++! Maybe now I will start learning Python again! Nice post!
--
===========================
Fabian the Skinny Fat Kid
mega_fat_guy(AT)sympatico(DOT)ca
===========================
Roy Culley
Tux...@fortress.tuxnet.net (TuxTrax) writes:
>
> <snip>
Really nice post. This is what cola should be about.
> This is the code I whipped up. It opens a connection to the server,
> and gets the ident and stats. It then prints the last 10 available
> messages before closing the connection. No big deal. But for this
> newbie, a very big deal.
Newbie or not I think it is a big deal. I've been playing with python
and only wish it had been around when I learnt perl. Python is an
excellent programming language. I have the feeling it is slower than
perl but perhaps that's because I'm a python newbie as well.
> #####################################
> # load needed libraries and modules #
> #####################################
>
> # load module required for interfacing to usenet servers
> # via NNTP. Documentation for this library is at:
> # http://www.python.org/doc/current/lib/module-nntplib.html
> from nntplib import *
>
> <snip rest of script>
Sorry, this just won't do. Too many comments. :-)
> <snip>
>
> Stuff just works better in Linux. What else can you say.
That's it in a nutshell. All I can add is that it is fun too. To me
that's one of the huge differences between *nix and MS OS's. No
wonder the wintrolls are grumpy all the time. So would I be if I was
forced to use that crap day in day out. That's another freedom that
OSS provides.
Peter Hansen
>
> I said that it seems to just work better in Linux. I should have said,
> there are snags in windows that have to do with the way windows
> handles things. For instance, the line:
>
> from nntplib import *
>
> should make all of nntplib's methods available to the calling
> program. However, a known problem (for which there is a workaround -
> as is the way with windows) is that due to windows file system quirks,
> the libraries are not always in the same place, or with the same
> names. for instance, according to the docs, windows often will
> capitalize an 8.3 filename all on it's own, or not treat spaces
> correctly. The trolls will jump on this, but I trust the python docs
> more than I trust the word of trolls. And it is in line with my
> experiences.
>
> Stuff just works better in Linux. What else can you say.
Nice post, and welcome to Python, but in this I think you leapt
to conclusions a little. None of the above are actually common
issues in Windows with Python. "from x import *" certainly works
properly, even though it's almost never a good idea (hint to newbies:
don't do that!). Windows does sometimes capitalize filenames,
but it's actually Explorer (the GUI shell) which does that, not
the filesystem, so Python does not really suffer from it. A
standard installation would run your code about as well as Linux.
(Yes, there are some issues, like the Windows TCP/IP stack is
worse under Win98 than under Linux. I just mean that the items
you point out above are not issues.)
I'm actually almost OS-agnostic as a result of using Python for
so much. No small feat, that.
-Peter
Roy Culley
Peter Hansen <pe...@engcorp.com> writes:
>
> Nice post, and welcome to Python, but in this I think you leapt
> to conclusions a little. None of the above are actually common
> issues in Windows with Python. "from x import *" certainly works
> properly, even though it's almost never a good idea (hint to newbies:
> don't do that!).
I'm a python newbie. How's about expanding on the hint. I just do (as
an example):
import os, re, sys, string
Is that bad also? Maybe we can turn cola into a python tutorial
newsgroup. :-)
Matthew Gardiner
>In article <slrnakhuhq....@fortress.tuxnet>,
> Tux...@fortress.tuxnet.net (TuxTrax) writes:
>>
>> <snip>
>
>Really nice post. This is what cola should be about.
>
>> This is the code I whipped up. It opens a connection to the server,
>> and gets the ident and stats. It then prints the last 10 available
>> messages before closing the connection. No big deal. But for this
>> newbie, a very big deal.
>
>Newbie or not I think it is a big deal. I've been playing with python
>and only wish it had been around when I learnt perl. Python is an
>excellent programming language. I have the feeling it is slower than
>perl but perhaps that's because I'm a python newbie as well.
I'd be excited to. Good on ya. Now, off to see when Kobol is ready ;)
>> #####################################
>> # load needed libraries and modules #
>> #####################################
>>
>> # load module required for interfacing to usenet servers
>> # via NNTP. Documentation for this library is at:
>> # http://www.python.org/doc/current/lib/module-nntplib.html
>> from nntplib import *
>>
>> <snip rest of script>
>
>Sorry, this just won't do. Too many comments. :-)
>
>> <snip>
>>
>> Stuff just works better in Linux. What else can you say.
>
>That's it in a nutshell. All I can add is that it is fun too. To me
>that's one of the huge differences between *nix and MS OS's. No
>wonder the wintrolls are grumpy all the time. So would I be if I was
>forced to use that crap day in day out. That's another freedom that
>OSS provides.
Knowledge is freedom, freedom is power. Power to leave the Microsoft flock and
develop your own concepts and ideas. Something Microsoft supporters fear. The
know that ignorance is what keep many people from not trying alternatives, and
unfortunately, those who challenge this invisible cage are "knocked", where as
the UNIX community will praise you as you become more knowledgable.
Matthew Gardiner
D. C. Sessions
It's not Python-specific. If you import everything from
a library, you fill up your namespace with methods that
you may not mean to use. This makes it pretty easy to
use a method that you didn't mean to because it's in the
wrong library.
--
| An engineer is someone who will spend three hours |
| figuring out how to do a two-hour job in one hour. |
Roy Culley
If I was a religious person I would say amen. :-)
Mike
news:slrnakhuhq....@fortress.tuxnet...
FWIW, with the exception of a modification nntpserver definition,
> nntpserver = "news.yourserver.com"
this code runs as-is on my W2k machine. I know you're probably not
interested, but there's a very nice Python distribution for Windows from
ActiveState.
One wonders how your code would look in some other languages. In Perl, of
course, it would be an unreadable mess, but what about something like Rebol?
Here's the intro page:
http://www.rebol.com/rebol-intro.html
I've never done any rebol programming, but this sounds like something rebol
was made to do.
-- Mike --
GreyCloud
> > Knowledge is freedom, freedom is power. Power to leave the Microsoft
> > flock and develop your own concepts and ideas. Something Microsoft
> > supporters fear. The know that ignorance is what keep many people
> > from not trying alternatives, and unfortunately, those who challenge
> > this invisible cage are "knocked", where as the UNIX community will
> > praise you as you become more knowledgable.
>
> If I was a religious person I would say amen. :-)
Just say "Right on, Man!"
Graham Ashton
> In article <3D492CAC...@engcorp.com>,
> Peter Hansen <pe...@engcorp.com> writes:
>>
>> "from x import *" certainly works
>> properly, even though it's almost never a good idea (hint to newbies:
>> don't do that!).
>
> I'm a python newbie. How's about expanding on the hint. I just do (as an
> example):
>
> import os, re, sys, string
Nope, that's absolutely fine. You are only adding the four modules that
you are importing to your current name space.
When you do "from somemodule import *" you will be importing absolutely
everything that the module or package exposes to you. This means that you
can very easily get difficult to find clashes between the names in
somemodule and the names that exist in your current namespace.
Consequently it's generally not a good idea.
For example, if you do "from os import *" you'll find that the builtin
open() function seems to start behaving strangely (because it's been
hidden by os.open(), which is a different function with a different
interface).
I say "generally not a good idea" above because some modules are actually
designed to be used this way (e.g. gtk).
There is also another more subtle side effect of "import *". If you find
yourself importing multiple modules into a file it can quickly become
difficult to keep track of which functions or classes are defined in which
module.
This makes locating the docs or code for a function an order of magnitude
more difficult, especially for other people. In other words, you're
impacting your maintainability. What I'm getting at here is that saying
somemodule.do_foo() is more "self documenting" than saying do_foo().
--
Graham
Roy Culley
Thank you. Very nice explanation. I do like python and hope that I can
tear myself away from perl one day.
James J. Besemer
Graham Ashton wrote:
> I say "generally not a good idea" above because some modules are actually
> designed to be used this way (e.g. gtk).
Like most things, there are exceptions to every rule.
E.g., the __all__ facility was designed to facilitate
importing * without extraneous clutter.
Some modules (with or without __all__ ) are
designed to only export a couple names and thus
import * is comparatively benign.
Seems if you're only referencing a few imported
names a few times in your module, there's no excuse
to not fully qualify the names. If you're using many
of the imported names in a lot of places in your code,
then the module qualifier can sometimes hurt the clarity
of the code and you may be excused from using it.
IMHO.
E.g., I have encountered circumstances where I was
doing a LOT of string manipulation and I felt "from
string import *" was appropriate.
Nevertheless, generally I agree that you want to refer
to imported objects by their fully qualified names.
Regards
--jb
--
James J. Besemer 503-280-0838 voice
http://cascade-sys.com 503-280-0375 fax
mailto:j...@cascade-sys.com
Peter Hansen
(I've read the other fine responses and am adding a few more comments
of my own. The others said most of what needs saying already.)
The above is not bad, except that you might find it more maintainable
(as well as a closer fit to the recommended Python style: see
http://www.python.org/peps/pep-0008.html in the Imports section) if you
split them onto individual lines:
import os
import re
import sys
import string
Definitely a bit more typing but depending on the module and your
coding style, you could benefit by keeping with this convention.
As for why "from ... import *" is bad, in addition to the other
points raised, you can get into trouble if you are importing more
than just method names. We recently had a bug caused by overuse of
this idiom where a module initially had a "global" which was
initialized to None. An initialize() function in the module was
supposed to be called to rebind the global name to an object,
but as it turned out another module managed to do a "from
import *" before this initialization took place. As a result,
the other module had a local name bound to "None" which was not
affected by the subsequent call to the initialization() function.
Had we done a simple, clean "import ..." instead, the other module
would have been referring to the name as modulename.globalname
and after initialize() was called it would be bound to the new
object instead of to None.
That might not be clear to a newbie, and I can see I've explained
it poorly so it's probably unclear to anyone. :( Point is, there
are definitely cases where you can get in trouble with the "from"
technique so you'd best avoid it until you know enough Python to
understand exactly how you might get tripped up.
-Peter
James J. Besemer
Peter Hansen wrote:
> [describes import bug]
>
> Had we done a simple, clean "import ..." instead, the other module
> would have been referring to the name as modulename.globalname
> and after initialize() was called it would be bound to the new
> object instead of to None.
I submit that in cases like this, where modules rely on
privacy for the integrity of their operation, then ideally
they should be designed from the start to be immune
from "import *" problems such as you describe.
I realize that many existing modules predate the availability
of the __all__ keyword. However, prefixing private vars
with "_" to prevent them from being imported has been
available for a long time. A problem like the one described
that can be avoided by use of one of the above hiding
mechanisms may fairly be regarded to be a failing of the
module designer, rather than the newbie user.
> Point is, there
> are definitely cases where you can get in trouble with the "from"
> technique so you'd best avoid it until you know enough Python to
> understand exactly how you might get tripped up.
True. Don't "import *" unless you KNOW it's safe.
Just don't do it is an even easier rule of thumb.
TuxTrax
Steve Ballmers hair grease:
Thanks Graham. that makes it alot clearer. It's a simple thing that
can be done, that can make life for the programmer and everyone else
that comes along, much easier. I can tell you that there have been
times that I have looked at old code that I wrote and couldn't make
heads or tails of what I was doing. In the olden days, I didn't have a
clue about the importance of comments and making things clear via the
programming style. As you demonstrate, somemodule.do_foo() is alot
clearer although it's not the only way of doing it.
Cheers,
Mathew
TuxTrax
Steve Ballmers hair grease:
> TuxTrax wrote:
> <SNIP>(its a bit long)
> Whoah. I started Vpython and Python when I was in my Wind0z3 days, too! I
> then gave it up for Pascal (dumb move) and then I gave up Pascal for
> learning C/C++! Maybe now I will start learning Python again! Nice post!
>
Thanks. I apologise for the post being long, and for the amount of
comments in the code section. A biz zealous about Python, is me!
Cheers,
Mathew
TuxTrax
Steve Ballmers hair grease:
> TuxTrax wrote:
I hope both my Comp.os linux.advocacy friends, and those in CLP will
forgive the crosspost. I am just so jazzed about python, and it's
incredible power and ease of use, that I wanted to spread the word.
I am also a big supporter of Linux, having been weaned off of
windows. I certainly didn't want to start a windows vs. linux flame
war in either group.
At any rate, I am a self professed newbie in python, and was passing
on information I had read in the python docs. It is certainly possible
that my interpretation of what I read was incorrect.
as for the NNTP module: I just couldn't get over how easy it was to
access NNTP with python. When I was learning visual basic, this would
have been a nightmare, and only for the advanced necromancer. As I
said; it couldn't have been done at all with the $100.00 version of VB
6.0 (learning edition) I had (yes I paid for it), because microsoft
didn't include the neccessary libraries for socket
implementations. They wanted you to upgrade to the ($400.00?)
developer version for that.
I'm giddy with delight. Python is free. FREE! And it beats VB
senseless! (IMHO)
There is justice in life.
Thank you Guido!
Cheers,
Mathew
GeneralPF
> as for the NNTP module: I just couldn't get over how easy it was to
> access NNTP with python. When I was learning visual basic, this would
> have been a nightmare, and only for the advanced necromancer. As I
> said; it couldn't have been done at all with the $100.00 version of VB
> 6.0 (learning edition) I had (yes I paid for it), because microsoft
> didn't include the neccessary libraries for socket
> implementations. They wanted you to upgrade to the ($400.00?)
> developer version for that.
Now, I don't like VB, but there are lots of 3rd-party components you can
buy to do easy NNTP stuff in VB. Same as SMTP, POP, IMAP, HTTP, FTP, etc.
Also, buying a "better" version of Visual Basic won't get you NNTP.
BTW, you can access the Windows Sockets API from Visual Basic. I
wouldn't advise it, though. *That* is for the necromancers. :)
Just curious: did you do any Perl before you started with Python?
TuxTrax
Steve Ballmers hair grease:
> "TuxTrax" <Tux...@fortress.tuxnet.net> wrote in message
> news:slrnakhuhq....@fortress.tuxnet...
>
> FWIW, with the exception of a modification nntpserver definition,
>
>> nntpserver = "news.yourserver.com"
>
> this code runs as-is on my W2k machine. I know you're probably not
> interested
Actually, I am. Very interested. I think it is outstanding the way
python is such an (easily) cross platform language. Write
it on linux, run it on windows! Why, I think that is very cool!
I am a linux man. That dosen't make me a snob, just for the record. I
know people still use windows, and for some very good reasons. And I
know that if I write software that anyone else will be using, (even if
it is just for fun) I want it to run on as many platforms as possible
with a minimum of fuss. Ain't python grand!
> , but there's a very nice Python distribution for Windows from
> ActiveState.
Actually, I just downloaded the python distro for windows from the
python site. It was very simple to install, and includes all the
standard stuff. works great on the NT system at work. I play with it
on my lunch break.
Don't know about the activestate stuff.
> One wonders how your code would look in some other languages. In Perl, of
> course, it would be an unreadable mess
I understand Perl was one of the reasons that Guido decided to write
his own language. True?
Perl does tend to lack a certain............ asthetic quality, dosen't it?
> , but what about something like Rebol?
>
> www.rebol.org
>
> Here's the intro page:
>
> http://www.rebol.com/rebol-intro.html
>
> I've never done any rebol programming, but this sounds like something rebol
> was made to do.
>
> -- Mike --
>
Thanks for the reference. I will check it out.
Cheers,
Mathew
Peter Hansen
>
> Peter Hansen wrote:
>
> > [describes import bug]
> >
> > Had we done a simple, clean "import ..." instead, the other module
> > would have been referring to the name as modulename.globalname
> > and after initialize() was called it would be bound to the new
> > object instead of to None.
>
> I submit that in cases like this, where modules rely on
> privacy for the integrity of their operation, then ideally
> they should be designed from the start to be immune
> from "import *" problems such as you describe.
>
> I realize that many existing modules predate the availability
> of the __all__ keyword. However, prefixing private vars
> with "_" to prevent them from being imported has been
> available for a long time. A problem like the one described
> that can be avoided by use of one of the above hiding
> mechanisms may fairly be regarded to be a failing of the
> module designer, rather than the newbie user.
That would not have solved the problem (at least not directly)
in this case, because it was not a _private_ variable that
was involved. The intention was that it was explicitly a
publicly available variable. A better solution would have been
to make it available via a function, e.g. getThatGlobal(),
but simply using _ was not suitable in this case.
(It would indirectly have solved the problem, of course, because
the programmer would have been forced to figure out another
way to get access to it, but if she knew to use _ in the first
place, she would also have known about the problems "import *"
can cause.)
And the old "never use global variables" comes to mind again too...
-Peter
Delaney, Timothy
>
> I submit that in cases like this, where modules rely on
> privacy for the integrity of their operation, then ideally
> they should be designed from the start to be immune
> from "import *" problems such as you describe.
How can they be? Any time they export *anything* it may clobber the
namespace of the importing module.
In particular if someone does something like
from a import *
from b import *
where
a exports c, d, e
b exports f, g, h
and then a new version of b is installed
b exports d, f, g, h
then you've got a problem whether or not the authors of a and b tried to be
"immune" to imort * problems.
IMO it is up to the user to ensure that they only import what they need ...
from ... import * is IMO one of the biggest warts of Python as it can cause
very obscure bugs.
Tim Delaney
James J. Besemer
"Delaney, Timothy" wrote:
> How can they be? Any time they export *anything* it may clobber the
> namespace of the importing module.
If you're saying it's impossible in general to protect
against any and all clashes, I would have to agree.
My point was that in many cases module designers
can do a better job protecting their code and their
customers against problems such as the specific one
described. Seems the careful designer would instinctively
take care to see that internal functions and state are so
protected. If there was no "import *" then the module
designer would have no reason to care but since the
hazard exists, the responsible designer will guard
against it. This is a natural part of programming
(at least for programming professionals). And in
any case it seems irresponsible to foist problems
off on the user if you don't have to.
You don't agree?
Or are you saying it simply isn't worth the extra effort?
In looking through the library, I see some module designers
are quite scrupulous about hiding internal names. Others,
particularly older modules, are careless by comparison.
For still other modules, e.g., UserDict it's a moot point as
there's nothing to hide. Increased hiding seems to be
a trend in newer modules, a healthy trend IMO, one
which I think we all should encourage.
> IMO it is up to the user to ensure that they only import what they need ...
No argument that the user has to take responsibility
for what he's doing. And I agree that general advice to
the newbie should be "don't 'import *'".
Nevertheless, module designers can and should take steps
where possible to make the user's life easier. Eliminating
possible name clashes IMO is a characteristic of a quality
implementation and more responsible than blithely
foisting the problem onto the newbie user.
> from ... import * is IMO one of the biggest warts of Python as it can cause
> very obscure bugs.
In my view the actual wart is in blithely exporting everything
by default. Most languages and designers rely on modules
to hide information. It's a necessary feature of large scale
programming and module boundaries are the most common
place where information hiding is required. Most languages'
module implementations require an express 'export' or 'global'
declaration to explicitly indicate those portions which are to be
made public. Rather than have the ignorant user decide what is
public and what is private, the module designer should do this.
The recent addition of the "__all__" hack would appear to
acknowledge this requirement.
A proper export syntax and semantics would address
many of the aforementioned problems and would be
IMHO a superior solution. Requiring an explicit
export name1, name2, ...
with all other names remaining private, would have been
a vastly superior solution, certainly it would be cleaner
than the recently added
__all__ = "name1 name2 ..."
hack and the earlier (original?) under bar prefix hack.
(Though, in all fairness, this may have been intended to
be a stop-gap measure, with the expectation that it
eventually would be replaced by a first class feature.)
I would STILL retain the existing import semantics that
would allow you to winnow the list of symbols down even
further (which just seems handy) and provide for
disambiguation of unavoidable name clashes (absolutely
necessary, though alternative mechanisms could be devised).
If course, this doesn't solve all the problems. There's no
way to ensure that essential names from two arbitrary
modules don't clash and some way to keep them separate
will always be needed.
But I submit that better module design could eliminate
most if not all of the "subtle" bugs referred to that are
so hard to track down.
James J. Besemer
> A better solution would have been
> to make it available via a function, e.g. getThatGlobal(),
> but simply using _ was not suitable in this case.
>
> (It would indirectly have solved the problem, of course, because
> the programmer would have been forced to figure out another
> way to get access to it, but if she knew to use _ in the first
> place, she would also have known about the problems "import *"
> can cause.)
Obviously, ignorance on the part of the module designer is as
bad as or worse than ignornace on the part of the newbie.
> And the old "never use global variables" comes to mind again too...
"Designed from the start to be immune from import
problems" was intended to include other design
considerations, not simply hiding names, though the
latter admittedly was the focus of my overall post.
Sounds like we're not really disagreeing on that broader point.
Mike
> On Thu, 01 Aug 2002 15:21:04 GMT, Mike Wrote in
> Steve Ballmers hair grease:
> > One wonders how your code would look in some other languages. In Perl,
of
> > course, it would be an unreadable mess
>
> I understand Perl was one of the reasons that Guido decided to write
> his own language. True?
There's a brief history of Python written by Guido on the python.org site:
http://www.python.org/doc/essays/foreword.html
The genesis of Python was ABC, and the first version was developed on a Mac.
-- Mike --
Ville Vainio
> I'm giddy with delight. Python is free. FREE! And it beats VB
> senseless! (IMHO)
Good for you. Expect your cheerful mood to continue - Python beats
most other languages senseless, too (I'm not sure about various
functional programming languages - they can be very elegant, but seem
to be quite impractical for many problems, and hard to grok). After a
while of doing things the Python way, doing the same things in other
languages feels like a real drag. There's very little "grunt work"
that makes people opt for software architect/whatever role instead of
a "normal" programmer. There's a very short time between
understand-how-it-should-work and a working implementation, which
makes it ideal for impatient people (which probably applies for 90% of
programmers :)
-- Ville
Steve Holden
Just out of interest, you may wish to compare your code with
http://pydish.holdenweb.com/pwp/chp5notes.htm
which uses the XOVER command to retrieve news posting details rather faster.
I'm pleased you are so enthusiastic about Python, it's a good language which
deserves support.
regards
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------
TuxTrax
Steve Ballmers hair grease:
Thanks Steve. I love to browse stuff. Checking it out right now.
Matthew Gardiner
>In article <aibggq$135al0$2...@id-150829.news.dfncis.de>,
>
>>>That's it in a nutshell. All I can add is that it is fun too. To me
>>>that's one of the huge differences between *nix and MS OS's. No
>>>wonder the wintrolls are grumpy all the time. So would I be if I was
>>>forced to use that crap day in day out. That's another freedom that
>>>OSS provides.
>>
>> Knowledge is freedom, freedom is power. Power to leave the Microsoft
>> flock and develop your own concepts and ideas. Something Microsoft
>> supporters fear. The know that ignorance is what keep many people
>> from not trying alternatives, and unfortunately, those who challenge
>> this invisible cage are "knocked", where as the UNIX community will
>> praise you as you become more knowledgable.
>
>If I was a religious person I would say amen. :-)
Amen is hebrew, IIRC, for "I confirm".
Matthew Gardiner
D. C. Sessions
>>>> Roy Culley<r...@swissonline.ch> 2/08/2002 12:32:33 a.m. >>>
>>If I was a religious person I would say amen. :-)
>
> Amen is hebrew, IIRC, for "I confirm".
Think of it as an ancient form of
<AOL>Mee Too!</AOL>
Donovan Rebbechi
> Tux...@fortress.tuxnet.net (TuxTrax) wrote in message news:<slrnakjms5....@fortress.tuxnet>...
>
>> I'm giddy with delight. Python is free. FREE! And it beats VB
>> senseless! (IMHO)
>
> Good for you. Expect your cheerful mood to continue - Python beats
> most other languages senseless, too
I don't think that's really accurate. There are a lot of languages, that make
different design choices, and have fundamentally different strengths/weaknesses
to python. Python is a sort of best-of-breed though, IMO.
> (I'm not sure about various
> functional programming languages - they can be very elegant, but seem
> to be quite impractical for many problems, and hard to grok). After a
One thing I like about Python is that it supports useful functional programming
constructs: lambda functions, map, reduce, etc.
> while of doing things the Python way, doing the same things in other
> languages feels like a real drag. There's very little "grunt work"
> that makes people opt for software architect/whatever role instead of
> a "normal" programmer. There's a very short time between
> understand-how-it-should-work and a working implementation, which
> makes it ideal for impatient people (which probably applies for 90% of
> programmers :)
This is very useful for some things -- for example, the new programmer really
shouldn't have to fight with a compiler. Likewise, people who use programming
languages as tools, rather than tools to develop tools will probably want
something like this.
On the other hand, serious infrastructure development tends to require
scalable statically typed programming tools, such as C,C++, Eiffel, and Java.
--
Donovan
Roy Culley
"D. C. Sessions" <d...@lumbercartel.com> writes:
> Matthew Gardiner wrote:
>>>>> Roy Culley<r...@swissonline.ch> 2/08/2002 12:32:33 a.m. >>>
>
>>>If I was a religious person I would say amen. :-)
>>
>> Amen is hebrew, IIRC, for "I confirm".
>
> Think of it as an ancient form of
>
> <AOL>Mee Too!</AOL>
;-)
holger krekel
Mart van de Wege wrote:
> On Thu, 08 Aug 2002 11:25:16 +0200, Michael Hudson wrote:
>
> > Mart van de Wege <mvdwege...@drebbelstraat20.dyndns.org> writes:
> <lots of misunderstandings about the Python VM>
> >
> > And this has been the case in Python for, more-or-less, ever. If
> > you're knowledge is out of date, then you must have known Python circa
> > version 0.9 (and I don't know if that interpreted a parse tree -- I
> > just know it was different).
> >
> Euhm, I meant to say that Python's VM was similarly high-level like
> Perl's. The parse-tree comment was meant to apply to the Perl VM. Sorry if
> I was a little unclear there.
at least perl 5.6 doesn't have a 'virtual machine'. It uses the parse
tree for substitution/execution. Of course you could call anything
that is interpreted (as a perl-script is) call 'virtual'. But commonly
only python and java are considered having VMs. With perl6 in the
distant future this might change.
> I am not up to compiler theory and VM design. I know three types of
> languages: Assembly (6502), C, and highlevel (Perl and Python mostly), so
> it's obvious I can be a little unclear in these cases.
>
> Thanks for clarifying things to me. Obviously, despite the design
> difference, Perl and Python have a higher-level VM than Java, right?
ASAIK perl has parsetree-based execution/substitution. Note that perl
probably has no way of accessing the 'parse-tree'. A bad (de-) sign.
I-am-no-perl-expert-but-know-some :-)'ly yours, holger
Bo M. Maryniuck
> Again, there are
> things I really like to do in Perl (basically anything regexp related),
Why not with 're' module? You think that using lots of <censored> symbols is
better that use Python syntax for text-works? :/
--
Sincerely yours, Bogdan M. Maryniuck
I develop for Linux for a living, I used to develop for DOS.
Going from DOS to Linux is like trading a glider for an F117.
(By ent...@world.std.com, Lawrence Foard)
Mart van de Wege
> hello mart,
>
> Mart van de Wege wrote:
> >
> > > Mart van de Wege <mvdwege...@drebbelstraat20.dyndns.org> writes:
> > <lots of misunderstandings about the Python VM>
> > >
> > > And this has been the case in Python for, more-or-less, ever. If
> > > you're knowledge is out of date, then you must have known Python circa
> > > version 0.9 (and I don't know if that interpreted a parse tree -- I
> > > just know it was different).
> > >
> > Euhm, I meant to say that Python's VM was similarly high-level like
> > Perl's. The parse-tree comment was meant to apply to the Perl VM. Sorry if
> > I was a little unclear there.
>
> at least perl 5.6 doesn't have a 'virtual machine'. It uses the parse
> tree for substitution/execution. Of course you could call anything
> that is interpreted (as a perl-script is) call 'virtual'. But commonly
> only python and java are considered having VMs. With perl6 in the
> distant future this might change.
>
since Perl source is compiled to bytecode before it is executed, that's
an easy mistake to make. See the older bit below ;-)
> > I am not up to compiler theory and VM design. I know three types of
> > languages: Assembly (6502), C, and highlevel (Perl and Python mostly), so
> > it's obvious I can be a little unclear in these cases.
> >
> > Thanks for clarifying things to me. Obviously, despite the design
> > difference, Perl and Python have a higher-level VM than Java, right?
>
> ASAIK perl has parsetree-based execution/substitution. Note that perl
> probably has no way of accessing the 'parse-tree'. A bad (de-) sign.
>
Why'd you think I am waiting for Parrot? Again, I'd love to see the port
of Python to the Parrot VM go through, as Parrot will be the VM of Perl6
(If I understood Larry and Damian's writing correctly). Again, there are
things I really like to do in Perl (basically anything regexp related),
but for the most part I do prefer Python. Having them both compile to
the same VM would allow me to have my cake and eat it too.
What is the status of porting Python to Parrot anyway? I heard the idea
bandied about a few months ago, but I haven't heard anything since.
Anybody know?
Mart
--
"Time expands and then contracts
When you're spinning in the grip of someone
Who is not an ordinary girl"
Counting Crows - Hard Candy
holger krekel
> Maybe you'd like to read the thread Eric Raymond started on python-dev:
>
> http://mail.python.org/pipermail/python-dev/2001-July/016406.html
sorry! just noticed this is quite out of date. I remember
that the parrot-issue came up recently and the status was that
it's nowhere close to realization. Can't find the postings, though :-(
holger
holger krekel
> > ASAIK perl has parsetree-based execution/substitution. Note that perl
> > probably has no way of accessing the 'parse-tree'. A bad (de-) sign.
> >
> Why'd you think I am waiting for Parrot? Again, I'd love to see the port
> of Python to the Parrot VM go through, as Parrot will be the VM of Perl6
> (If I understood Larry and Damian's writing correctly). Again, there are
> things I really like to do in Perl (basically anything regexp related),
> but for the most part I do prefer Python. Having them both compile to
> the same VM would allow me to have my cake and eat it too.
sure it would be great. But it is not easy.
> What is the status of porting Python to Parrot anyway? I heard the idea
> bandied about a few months ago, but I haven't heard anything since.
> Anybody know?
Maybe you'd like to read the thread Eric Raymond started on python-dev:
http://mail.python.org/pipermail/python-dev/2001-July/016406.html
regards,
holger
Albert van der Horst
Just <ju...@xs4all.nl> wrote:
>In article <o58uia...@drebbelstraat20.dyndns.org>,
> Mart van de Wege <mvdwege...@drebbelstraat20.dyndns.org> wrote:
>
>> For example, this is what I recently did to extract all IPs from my
>> access.log:
>>
>> ----- BEGIN SCRIPT -----
>> #!/usr/bin/perl
>>
>> use warnings; # Make Perl picky about syntax.
>> use strict; # Make Perl *really* picky.
>>
>> my @iplist; # Declare an array to hold all IP addresses.
>>
>> open (FILE, '/var/log/apache/access.log');
>>
>> while (<FILE>) {
>> /^(\d+\.\d+\,\d+\.\d+)?/;
>> next unless $1; # Skip if the first field is somehow empty.
>> next if $1 eq '127.0.0.1'; # Skip localhost.
>> push @iplist, $1;
>> }
>> # @iplist now holds all IPs in the first field of access.log.
Full of idiosyncracies :
< > around FILE
/ / round a reg exp
reg exp working on $_ (uck)
next construction
unless is a superfluous language embellishment
>>
>> ----- END SCRIPT -----
>>
>> Python can do this too of course, but somehow this is the sort of task
>> that comes naturally to me in Perl. Note the use of the regexp:
>>
>> 1. I don't have to explicitly declare and compile it.
>> 2. It operates on the default input variable ($_), so I don't have to
>> specify its target, I just use a bare regexp.
>
>
>import re
>
>iplist = []
>
>for line in open("/var/log/httpd/access_log"):
> m = re.match(r"^(\d+\.\d+\.\d+\.\d+)", line)
> if m:
> ip = m.group(1)
> if ip != "127.0.0.1":
> iplist.append(ip)
>
>
>I don't thinkthat's significantly worse (or better...) than the Perl
>version?
I think it is clearly superior!
- There is just the amount of code to keep track of what is going on
- It properly reflects the logic of the program
- Constructions are consistent and evocative, even without
studying the ``re'' module.
This is the way I want scripting done in Forth.
It would work out approximately this way:
---------------
REQUIRE RE-MATCH
REQUIRE COMPARE
REQUIRE SET
1000 SET Iplist Iplist SET!
: 2SET+! >R SWAP R@ SET+! R> SET+! ;
"/var/log/httpd/access_log" GET-FILE $DO
$LINE "^(\d+\.\d+\.\d+\.\d+)" RE-MATCH IF
\1 "127.0.0.1" COMPARE 0= IF \1 Iplist 2SET+! THEN
THEN
$LOOP
---------------
This is admittedly inferior to Python, but not by too much
given the fact that Forth is such a light weight language.
Note that this doesn't work without slurping the file.
The pointers stored in Iplist would be worthless if pointing
to a fixed buffer reused all the time by READ-LINE.
Extension to be built in Forth in this behalf:
1. SET (can be borrowed from ciforth, a one-screener)
2. interpretive loops (idem)
3. GET-FILE (also known as SLURP, rather common)
4. $DO $LINE $LOOP ( To be done)
5. RE-MATCH ( To be done)
Convention of usage of reg expr in Forth however have not yet
converged (in 20+ years. How long did it take in Python?)
The work of (at least) Marcel Hendrix and Putka has almost
the regular expression matching such as wanted there.
This article will appear once in linux.advocacy. Those
who are interested in languages issues can follow the thread
in one of the other groups.
Forthers are kindly requested to trim python / perl from the
Newsgroups: as soon as the article is no longer on topic in that
other group.
Groetjes Albert
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst