Chris Mellon wrote: > On Nov 20, 2007 2:43 PM, John J. Lee <[EMAIL PROTECTED]> wrote: >> "Chris Mellon" <[EMAIL PROTECTED]> writes: >> [...] >>> These modules exist, but aren't that common. Certainly anything you're >>> likely to be using in an introductory compsci course is well packaged. >>> And even if it's not, it's really not that hard to create packages or >>> installers - a days work of course prep would take care of the >>> potential problem. >> "A day's worth of course prep" for beginners would let them debug all >> the crap that building MySQLdb on Windows might throw at them, for >> example? I think not! (MySQLdb, last time I looked, was one of the >> not-so-obscure modules that don't have a Windows installer available >> and kept up to date. Maybe it does now, but that's not really the >> point.) >> > A days worth of course prep would allow the professor (or his TA, more > likely) to produce a set of installers that's suitable for use with > the course. This is a comp sci course, not a "how to sysadmin a Python > installation" course. > > For the record, it took me less than 3 minutes to install MySqldb, the > first time I've ever needed to do it - I don't like or approve of > MySql. Steps required: Google for "mysql python" and click through 3 > or 4 links to the SF download page. Download the binary installer, > from March 2007. Not exactly rocket science. > > On a similar note, I have or create executable installers for all the > third party modules I use, because I need to provide them to the > people who do our deployments. This has never been much of a burden. > >> I certainly don't recognise what some people have been saying, though. >> It's a rare thing that I have any real pain installing a Python module >> on Linux. That's not to say you don't need some background knowledge >> about distributions and Python if doing it "by hand", of course >> (rather than with a packaging tool like apt-get). Occasionally you'll >> want the newest version of something, which will in turn occasionally >> get you into some grim automake issue or similar. But all of this can >> be entirely avoided in an introductory course -- simply restrict >> yourself to what can be installed with apt-get (if the instructor >> feels they *must* make some new library available, they can always >> package it themselves). >> > The obstacles as presented in the OP seem pretty bogus to me. Of > course, it's third hand anecdotal evidence, so there's not much of a > reason to believe that the original statement really preserves the > essence of the problem. > > I'd be pretty interested if the OP could ask his associate to chime in > with some of the actual issues he encountered
/ Chime Mode <ON> I have, in fact, sent this thread to my friend. His limiting factors are - money-control people favor MS platforms - C# and VS have minimal cost impact for academia - sys admins have everything locked down (probably essential for high school and community college) - both Python 2.4.2, then 2.5.1, on XP and Win2k crashed approx 10% of lab cptrs, so lab techs refused to allow further install of any 'third-party' s/w. (side note - I have installed Python and all the supporting stuff for PyVISA on 14 work-site (11 XP, 3 Debian) cptrs with no problem, so I do not understand). - no such thing as TAs in JC or HS. - CS instructors, for the effected schools, are not allowed to config machines or admin the network. - money-control people want students to learn skills that are on the IT buzz-word list. - my friend is no longer allowed to use me as an 'unofficial' assistant in these classes (not considered qualified because I only have a B.S. degree), so he only uses stuff that existing staff are (supposedly) familiar with... / Chime Mode <OFF> I told my friend, the wannabe Python instructor, to walk away from any more volunteer work, and stick to the paid stuff. American education, what a mess... luck, Brian -- http://mail.python.org/mailman/listinfo/python-list
