Re: What's the best way to learn perl for a python programmer?
The online docs are very good. Just run "perldoc perl", and then go through the various tutorial pages (starting with "perldoc perlintro"). You can also read them online here: http://perldoc.perl.org/perl.html . Then go to http://www.perlmonks.org . They have many tutorial-style articles there, as well as a very helpful and knowledgeable community. If you absolutely need to write object-oriented Perl, you probably want to keep things as simple as possible and just use regular old hash-based objects. Writing OO Perl code is a whole nuther ball of wax than just writing procedural Perl code. -- http://mail.python.org/mailman/listinfo/python-list
Re: doctest, unittest, or if __name__='__main__'
> so you think that a "why all this creativity when you could just > standardize on something ported from java, and throw away every- > thing else" post is friendly ? really ? Sorry for the sloppy writing. Thanks for clarifying. I wrote: > If unittest is the standard way to write test code, why do we still > have doctest? (I notice there's no mention in PEP 3000 of deprecating > the doctest module). when that should've been > If one is the standard way to write test code, why do we still > have the other one? (I notice there's no mention in PEP 3000 of > deprecating either module). Also, as an aside, I don't think there's anything inherently wrong with porting something from Java (or Smalltalk, or any other language). Such ported software may or may not be a good fit for Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: doctest, unittest, or if __name__='__main__'
> and you can kill two birds with one stone. By that, do you mean you can write your tests and your docstrings in one shot with doctest? > I would like to see yet another alternatise such as py.test > in the standard lib, Ah: http://codespeak.net/py/current/doc/home.html -- http://mail.python.org/mailman/listinfo/python-list
Re: doctest, unittest, or if __name__='__main__'
> because it's a vastly superior way to write tests ? Well, since this is a mailing list where this sort of thing is discussed, and since I was was asking about which way is preferred, could you tell us why you (presumably) think doctest is vastly superior to unittest? > why is it that comp.lang.python is suddenly full of folks who > want to deprecate anything they don't understand ? I didn't say I wanted to deprecate it. I wrote that I noticed there was no mention in PEP 3k about deprecating it. > don't you have better things to do with your time ? That wasn't very friendly. Anyhow, I'm not attacking doctest, but rather, just trying to understand why there seems to be two very similar ways of testing your code built into the system (considering that one motto around here is "There should be one -- and preferably only one -- obvious way to do it."). -- http://mail.python.org/mailman/listinfo/python-list
doctest, unittest, or if __name__='__main__'
For writing testcode, it looks like there's three ways that it's typically done: (1). using the doctest module, (2). using the unittest module (i.e. "pyunit"), or else (3). just putting an "if __name__ = '__main__':" at the bottom of your module containing code to manually run your class through its paces. So, which way is preferred? Seems to me that unittest is the way to go, at least because it has you separate your test code from the code being tested. If unittest is the standard way to write test code, why do we still have doctest? (I notice there's no mention in PEP 3000 of deprecating the doctest module). -- http://mail.python.org/mailman/listinfo/python-list
Re: Loop Backwards
Tim Roberts wrote: > "Dave" <[EMAIL PROTECTED]> wrote: > > > >Please be mindful of making statements such as: > >"it's silly to believe both will behave equally" > > > >One of the greatest weaknesses of Python is the less than friendly > >attitude Pythonistas display towards one another. > > I don't know how much Usenet experience you've had, but comp.lang.python is > one of the friendliest places in the comp.lang universe. Newbie questions > get answered without derision, and disagreements are handled with spirited > discussion, instead of flames and insults. Compare, for example, to > comp.lang.c and comp.lang.c++. It's possible that english may not be Felipe's native language, and Dave may not've thought of that. To a native english speaker, Felipe's comment (which was very helpful!) could've also been construed as being slightly rude. Perhaps Felipe meant to write "mistaken" instead of "silly". Also, as an aside, smileys are always helpful on usenet. :) > [snip] I've looked at Ruby, but syntactically it > will never sway me from Python. Same here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tried Ruby (or, "what Python *really* needs" or "perldoc!")
Jason Earl wrote:
> "msoulier" <[EMAIL PROTECTED]> writes:
>
> >> I have found the Python sidebar VERY helpful:
> >
> > Personally, I can't use local docs on my desktop as they may not be
> > the same version of the docs for the Python distro running on the
> > server that I'm deploying on. I usually go to python.org and use the
> > wayback machine to look at the old docs for the release that I'm on.
>
> Why don't you instead install the info version of the Python
> documentation on your server. Then you can do "info Python2.3-lib"
> and have at it. If you are hacking in emacs then this is about as
> slick a documentation system as you could ask for, but even if you use
> some other editor info is a much better documentation tool than man.
You know, I'm pretty used to reading man pages. There's only a
few simple keystrokes I need to remember, and the only time I
ever touch "info" is when a very short man page tells me that the
real docs are in info and I need to look there. At that point, I have
to relearn how to use that info command. Info is complicated. It's
got some concept of nodes being hierarcical, but also they seem
to have some order to them (a la next and previous) as well. No
idea what the connection between those is. Also it's got "cross-
references" as well as menus -- dunno if they're different or not.
Bah. Why not just use html and browse it with lynx/links/links2/elinks?
I can't understand why we need two separate and distinct doc
formats: man and info. My take: write your docs in some markup
that can produce both man output and html. Done and done.
Seems like two good candidates for that are epytext and
reStructuredText ("reST").
> > But, if Python would match Perl for docs available on the
> > command-line, then I'd have it all at my fingertips. I simply don't
> > understand why this is not being done. When I'm coding in C, I use
> > the manpages on the remote host so that I know the docs are correct
> > for my target. Why can't I do that in Python? It's yet another thing
> > that my Perl-using coworkers point out as a Python weakness.
>
> Python does match (and exceed) Perl for docs available on the command
> line. Once you get used to using the excellent info-based Python
> documentation using man is downright primitive.
>
> Jason
I think that may be wishful thinking. When I use the pydoc command,
I mostly get *very* short API docs with *no* example code or tutorial
notes at all.
Contrast that with perldoc which is categorized and complete docs
for the entire language plus tutorials, faqs, ports info, ... I mean,
have a look over at http://perldoc.perl.org/perl.html -- everything
there is at your fingertips from the terminal! And it's written by
folks
like Larry, Dominus, Randal Schwartz, Tom Christiansen, et al. I've
never come across a FLOSS software project with docs as good as
Perl's.
Now, the one big thing we have going for us is that since Python
is a simpler language, so it needs few docs overall anyway. :)
---John
http://www.simisen.com/jmg/cpd/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tried Ruby (or, "what Python *really* needs" or "perldoc!")
msoulier wrote: > > [snip] > But, if Python would match Perl for docs available on the command-line, > then I'd have it all at my fingertips. I simply don't understand why > this is not being done. [snip] > > Mike Ok, well, here's my attempt to begin to make that happen: http://www.simisen.com/jmg/cpd/ This "release" is as alpha as alpha gets. It's so alpha it actually loops back around to zeta -- but it's a start, and I think it's exactly what the Python community needs. The command to read the docs works like pydoc but is called dennis (extra points for getting the obscure Monty Python reference before reading the web page). :) The dennis command is only a few lines of Python held together by bailing wire, so it will need lots of work, but it lets us read the docs so it's ok for now. You're invited to fix it up and send me an improved version. :) Please have a look and let me know what you think. If people start writing modules (that is, documentation) and sending them to me, I'll probably be forced to start a mailing list and actually put this stuff in CVS/SVN/bzr. Have at it! :) ---John -- http://mail.python.org/mailman/listinfo/python-list
Re: Tried Ruby (or, "what Python *really* needs" or "perldoc!")
> And the patch procedure you described requires > a higher degree of motivation (and free time) than > most potential contributors might have on offer, imo. Another option is to simply email the author/maintainer for a given module your modifications to their module. cd ~/dev/python/modified_modules cp /path/to/module_needs_docs.py . vim ./module_needs_docs.py # add docs -- http://mail.python.org/mailman/listinfo/python-list
Re: Tried Ruby (or, "what Python *really* needs" or "perldoc!")
Well, we've already got a wiki, of course: http://wiki.python.org/moin/ Regarding the docs for the module you're asking about, the way it's supposed to work is (I think), you're supposed to checkout the Python source, add your docs to the docstrings of that module, then either commit your changes back in (if you have access privileges) or else send a patch to the right list (python-dev?) so your patch can be integrated. It seems to me that it's best to write your docstring as epytext. That way, for now, it just looks like regular plain text (though neatly formatted) when viewed with the pydoc tool... -- http://mail.python.org/mailman/listinfo/python-list
Re: Tried Ruby (or, "what Python *really* needs" or "perldoc!")
Ok. I'm going to try and make something happen. Give me a day or so. :) ---John -- http://mail.python.org/mailman/listinfo/python-list
Re: Tried Ruby (or, "what Python *really* needs" or "perldoc!")
> So far epytext suited my needs. I like it too. Ok, now I'm starting to get excited. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tried Ruby (or, "what Python *really* needs" or "perldoc!")
Thanks Diez! Epydoc looks great. Can we use epytext to generate output suitable for a manpage? Do you prefer epytext or reST? -- http://mail.python.org/mailman/listinfo/python-list
Tried Ruby (or, "what Python *really* needs" or "perldoc!")
Just tried Ruby over the past two days. I won't bore you with the reasons I didn't like it, however one thing really struck me about it that I think we (the Python community) can learn from. Ruby has ... an issue with docs. That is to say, there are almost none. Well, actually, there are some. For example, the "PickAxe" book (google it), and "Why's" Poignant Guide. But there's a disturbing lack of *built-in* docs for Ruby. Now, the situation is getting better. In fact, it's getting better very quickly. Let me explain. IMO, Perl has docs nailed. I learned Perl before coming to Python, and I can tell you that their docs kick butt. I believe the reason why is (besides Larry's excellent and entertaining writing) because of perldoc. Here's how it works: they write special doc directives into their .pl files that the interpreter ignores, but that the perldoc command processes into a manpage for you. This is a *bit* like what pydoc does, only pydoc just regurgitates docstrings, while perldoc formats special directives into headings, code listings, bulleted lists, etc. Now, the *real* magic of perldoc is that it makes writing small self-contained little manpage style docs easy as pie. What this means is that really good doc writers can sit down and quickly produce something that can be readily incorporated into the perl-doc distribution. *That's* the magic. That's why I think they've organically grown such an amazing crop of great docs. Anyone can quickly and easily write docs that the community can then filter to find the best ones. Back to Ruby's docs. Their situation is getting better. This is because they're picking up on Perl's doc success and doing the same sort of thing. Only, I think their solution may be clunkier because it requires a separate program (rdoc) to process the doc directives, and then you actually read the docs with a program called ri (not sure). Regardless of the minute details, it looks like their docs are starting to get better, rapidly. Here's what I think is currently happening with Python (please correct me if I'm wrong): There's the docutils project http://docutils.sourceforge.net/ which, AFAICT, is working on a number of complicated things, one of which is to have a way to allow you to put reStructuredText markup (aka "reST") ( http://docutils.sourceforge.net/rst.html ) into your docstrings (and presumably have the pydoc command understand it). There's more info in PEP 287 http://www.python.org/doc/peps/pep-0287/ . I certainly don't understand all that Docutils is trying to do. All I'm convinced of is, the real magic is in being able to quickly write a .py file containing marked up docstrings and have the pydoc command be able to render it as something that looks like a man page in my terminal window. If it can later also produce html, that's great too. But *that's* the essense, IMO, of what will foster community involvement in making the docs great, as well as allowing folks to more easily document their own modules and contribute integrated docs to all the great modules already available. It looks like we have the tools do this *right now*. We've got the markup (reST), we've got the tools to churn that into a manpage or html (part of docutils?), and we've got the pydoc command. I think the current hangup is that the docutils guys (being smart and ambitious folks) want to get some sort of inter-doc linking thing working so you can refer from one doc page to another (?). I don't think perldoc has (or needs) that feature... maybe we could put that on the "would be nice to have down the road" list, and get a quick common-sense docstring-reST pydoc setup working for us much sooner? I don't know for sure, but my guess is "yes". Eventually, maybe the tutorial, language reference, library ref, etc., could even all make it into this format, with the html versions generated from the .py/docstring/reST sources. That might make it easier for the community to contribute to them (if their respective maintainers are interested in that). Please note, I certainly don't want to step on the doc-sig folks' toes here -- but rather to generate more interest in what they're doing, and to help make Python be even better in an area that I see it struggling. What do you folks think? Yes, I'm trying to make time to look at the docutils code and the pydoc command to see what's involved. Unfortunately, my spare time is vanishingly close to zero right now. Related link: Doc-SIG http://www.python.org/community/sigs/current/doc-sig/ Thanks, ---John -- http://mail.python.org/mailman/listinfo/python-list
fairly large webapp: from Java to Python. experiences?
I've got a fairly substantial webapp written in Java (plus Tomcat, Hibernate, Struts, JSP, MySQL) that is a bit of a bear to work with. I didn't write it. Much of it is only very sparsely documented (if at all). No design docs anywhere. It's a large webapp with many classes and fairly deep inheritance hierarchies. There seems to be JUnit test cases in place. The possibility of re-writing it has come up, and I must say that, although it would likely be a ton of work, it could also be a real pythonic adventure. ;) Reasons for a rewrite are to get better flexibility, easier maintenance (easier to make changes), and the possibility of really slimming down the size of the thing. And of course, it would be nice to work with Python -- possibly significantly more productive. Does anyone here have any experience with large(ish) webapps in Python? I was sniffing around the following A-team of toolkits: CherryPy, Cheetah, SQLObject, all behind Apache2. Has anyone seen performance issues with Python webapps? Could one reasonably expect to have an easier time with maintainence and future modifications with using Python over Java? Any tips, stories, recommendations, and/or experiences are most welcome. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
