🌐 Mailman 3 October 2004 - Python-list - python.org

Re: Encouraging Python adoption in your organization
by Daniel Dittmar Oct. 4, 2004

Oct. 4, 2004

John Hunter wrote: > Read "Hackers and Painters" by Paul Graham, and then give copies to > your developers. He writes compellingly about the benefits of using > python (or lisp) is a competitive environment. On the other hand, Paul Graham paints Java programmers as dimwits. So quoting him is likely to start a flamewar. This is perhaps not the best choice from a diplomatic point of view. Daniel

3 4

Re: Python and C#
by Thorsten Kampe Oct. 4, 2004

Oct. 4, 2004

* Gerhard Haering (2004-10-04 16:47 +0200) > On Mon, Oct 04, 2004 at 03:59:33PM +0200, Thorsten Kampe wrote: >> py2exe is easier to setup but McMillan offers more functionality. > > The old site www.mcmillan-inc.com is dead since months. Has Gordon disppeared > completely Out of job I heard :-(. > or is his stuff available somewhere else now? * Distributing Python Apps http://paulbaranowski.org/modules.php?name=Downloads&d_op=viewdownloadsimpl…'s%20Installer http://paulbaranowski.org/modules.php?name=Downloads&d_op=getit&lid=8 ...and a few other mirrors mentioned in thread recently. Google for it if you care about the mirrors. Thorsten

1 0

should these be fixed for python 2.4?
by Alexander Schmolck Oct. 4, 2004

Oct. 4, 2004

Two smallish things that have been bugging me; I'm not sure whether they're actually broken or not, but anyway here it goes: 1. ``os.system`` (and co): Shouldn't ``os.system``'s signature really be ``os.system(cmd, arg1, arg2,...)`` rather than ``os.system(some_string)``? Otherwise ``some_string`` almost certainly will be constructed by something along the lines of ``os.system('convert %s %s' % (infile, outfile))`` which of course is broken (e.g. ``infile = "with space"``). I don't think it's even possible to do the right thing platform-independently. I currently use the following hack (any improvement suggestions welcome): def _fixupCmdStr(cmd, args): escape = lambda s: '"%s"' % re.sub(r'\"$!', r'\\\1',s) #FIXME return " ".join([cmd] + map(escape, args)) def system(cmd,*args): return os.system(_fixupCmdStr(cmd, args)) So why not just allow ``os.system('convert',infile, outfile)`` as a backward compatible extension that "does the right thing"? BTW, if I'm not mistaken it's something that perl got right a long time ago. > perl -e "system('touch', 'a b c', 'd')" > ll total 0 -rw-r--r-- 1 aschmolc phd 0 Oct 1 17:48 a b c -rw-r--r-- 1 aschmolc phd 0 Oct 1 17:48 d 2. pydoc's handling of overriden methods without docstrings: I really think it should show the documentation of the method in the baseclass; the current behavior really sucks when working with things like backends. Even fixing up subclass docstrings by hand is not trivial:: In [25]: class Bar(object): ....: def meth(x): ....: pass ....: In [26]: Bar.meth.__doc__ In [27]: Bar.meth.__doc__ = "abc" --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) /auto/home/black4/aschmolc/PhD/Bayes/<console> AttributeError: 'instancemethod' object attribute '__doc__' is read-only Going via dict will work (but that of course fails for the general case):: In [28]: Bar.__dict__['meth'].__doc__ = "abc" cheers, 'as P.S. speaking of running external processes -- I'm also unaware of a good, platform-independent (or even just unix) way to run a process that possibly accepts input, but will just continue on EOF from stdin and getting back stdout and stderr (if supported) as strings and the exit status. I currently use this to run e.g. latex, but it doesn't seem to work absolutely reliably and is unix only. I'm pretty sure there must be a better way. def readProcess(cmd, *args): r"""Like `os.popen3`, but returns 2 strings (stdin, stdout) and the exit code (unlike popen2, exit is 0 if no problems occured (for some bizzarre reason popen2 returns None... <sigh>). FIXME: only works for UNIX!""" cmdStr = _fixupCmdStr(cmd, args) popen = popen2.Popen3(cmdStr, capturestderr=True) popen.tochild.close() # XXX make sure we're not waiting forever exit = popen.wait() out, err = map(slurpIn, [popen.fromchild, popen.childerr]) return out or "", err or "", exit def slurpIn(file, binary=False): if isString(file): file = open(file, ("r", "rb")[bool(binary)]) try: result = file.read() return result finally: file.close()

11 23

Re: Processing a MySQL Dump file with Python
by Jeffrey Froman Oct. 4, 2004

Oct. 4, 2004

Nico Grubert wrote: > can I somehow call the MySQL interpreter in background to pass the dump > file to it so the SQL Dump is imported in order > to write the tables and data into the MySQL database? Sure, that's what dump files are good for. Simply pipe the contents of the file into a mysql command. On a Unix-type system (maybe Windows too, I wouldn't know) you'd run something like: mysql -h myhost.com -p -u myusername < dumpfile MySQL does all this by itself, no Python required. Hope that helps, Jeffrey

1 0

Re: Encouraging Python adoption in your organization
by Ian J Cottee Oct. 4, 2004

Oct. 4, 2004

Neil Benn wrote: > Ian J Cottee wrote: > >> Daniel Dittmar wrote: >> >>> On the other hand, Paul Graham paints Java programmers as dimwits. So >>> quoting him is likely to start a flamewar. This is perhaps not the >>> best choice from a diplomatic point of view. >> >> >> >> That is not what he said or meant. As he himself clarifies: >> >> """In a recent talk I said something that upset a lot of people: that >> you could get smarter programmers to work on a Python project than you >> could to work on a Java project. >> >> I didn't mean by this that Java programmers are dumb. I meant that >> Python programmers are smart. It's a lot of work to learn a new >> programming language. And people don't learn Python because it will >> get them a job; they learn it because they genuinely like to program >> and aren't satisfied with the languages they already know. >> >> Which makes them exactly the kind of programmers companies should want >> to hire. Hence what, for lack of a better name, I'll call the Python >> paradox ... """ >> >> http://www.paulgraham.com/pypar.html >> >> Ian > > > Hello, > > You can quote it in different ways : > > --- > But when you choose a language, you're also choosing a community. The > programmers you'll be able to hire to work on a Java project won't be as > smart <http://www.paulgraham.com/pypar.html> as the ones you could get > to work on a project written in Python > --- (disclaimer - it's late, very tired and should go to bed soon, blah blah, yada yada) Anyway - he explains the reasoning. The reasoning is that if you took 100 programmers who call themselves Java Programmers and 100 programmers who call themselves Python Programmers you are most likely going to find different characteristics within the two groups. Python programmers are unlikely to be as focussed on financial reward as Java programmers. Python programmers are however more likely to be endowed with a love of the art of programming. Now I'm not sure if I agree with the statement and frankly, having two kids and an expensive wife I'm not sure if I'd call myself intelligent for NOT jumping onto the Java bandwagon ;). But I do understand the point. > This is from his _own_website - he then follows it up with : > > --- > Though, frankly, the fact that good hackers prefer Python to Java should > tell you something about the relative merits of those languages. > --- Elsewhere he states who he believes to be great hackers. He knows all of them and therefore I guess he knows what they prefer. I think he also says that he doesn't feel he can pass judgment on people he does not know (or has worked with). So it might just be that he doesn't get on with Java programmers of course ;) > > Next we have : > > --- > And of all the great programmers I can think of who don't work for Sun, > on Java, I know of zero. As above > --- > > On the retract posted above : > > --- > It's a lot of work to learn a new programming language. > -- > > The response on this would be - 'but you just told me that python is > 'easy to learn''. I agree with him and you. Python is easy to learn but it's still a lot of work to drop your current language, your knowledge of it and risk moving elsewhere. Especially if you are taking your employers (or employees) with you. > Although that was probably retracted afterwards - the fact that that > quote exists will be picked up people. I'm not insulting the quality of > writing as it is a very well written article - it just isn't gonna help > anyone trying to advocate python in a sensible business, that kind of > retort sounds like an American election campaign!! Ooooh ... that hurt! But I agree with that. I don't think he's planning at talking at any Java conventions soon. I just don't agree he's calling Java programmers stupid. peace, beer, cool things Ian

1 0

ANN: Logging Package v0.4.9.4 released
by vinay_sajip＠yahoo.co.uk Oct. 4, 2004

Oct. 4, 2004

A new version of the Python logging package has been released. If you are using version 2.3 of later of Python, this release will not mean much to you - it is the same as recent checkins into Python CVS. However, this release fixes numerous bugs reported since the last independent release (0.4.9.2), and may be of interest to people using earlier versions of Python. What Does It Do? ================ The logging package offers the ability for any Python program to log events which occur during program execution. It's typically used to provide application diagnostics, warnings and error messages. In addition to capturing "what happened", "where it happened", "when it happened", "how important it is" and event specific data, you can configure, without changing the application source code, both the verbosity of logging and the routing of events to different destinations such as console, disk files, sockets, email addresses, Web servers, SOAP servers etc. etc. You can even change the configuration of a running program without stopping and restarting it! You can use the logging package in exception handlers, and it will include traceback information in the log. It's thread-safe, and very easy to use - just "import logging" and log away! Classes provided include: Logger - used to log messages for a particular area of an application. You can instantiate these wherever you want, there's no need to pass references to them around your application. You can log events based on importance levels of DEBUG (least important), INFO, WARN, ERROR, and CRITICAL (most important). You can define your own levels if the default levels don't meet your requirements. Handler - used to route events to particular destinations. Handlers included are: StreamHandler (for generalized streams, including console) FileHandler (for disk files - including log file rotation with size limits for log files) SocketHandler (for sending events to a TCP socket) DatagramHandler (for sending events to a UDP socket - faster, but less reliable than TCP) SMTPHandler (send events to arbitrary email addresses) HTTPHandler (send events to Web servers) SysLogHandler (send events to Unix syslog) MemoryHandler (batch up events and process them several at a time) NTEventLogHandler (send events to Windows NT event logs) There are also examples of XMLHandler and SOAPHandler in the distribution. Formatter - used to format events as text strings. Flexible "msg % arg_tuple" formatting is the basis for formatting, with flexible date/time formatting including ISO8601 and any strftime-based formats. Filter - used when filtering based on importance (DEBUG/INFO/WARNING/ERROR/CRITICAL) is not sufficient. The distribution includes examples of filters based on class matching, regular expression matching, value matching, and logger matching. In the unlikely event that you're daunted by all the apparent complexity, fear not. The package offers a simple function-based interface to allow very simple, almost casual use of the underlying features. In addition to the core logging functionality, you get the ability to configure logging using a ConfigParser-based text file format, a Tkinter-based GUI configurator which creates configuration files for you, and a simple network-based event receiver which receives events on TCP, UDP, HTTP and SOAP ports. This is suitable for testing and might perhaps serve as a model for your own event receivers. Also included are over 20 test scripts which serve both as test harnesses and examples of how to use the logging package. You can get more information from http://www.red-dove.com/python_logging.html There are "download" and "recent changes" links at the top of that page. API documentation is available at http://www.red-dove.com/logging/index.html As always, your feedback is most welcome (especially bug reports, patches and suggestions for improvement). Enjoy! Cheers Vinay Sajip Red Dove Consultants Ltd. Changes since the last independent release: =========================================== Added getLoggerClass() (thanks to Dave Wilson). Added exception handling in shutdown(). Sort globbed files in doRollover() in TimedRotatingFileHandler. Date formatting for SMTPHandler now uses email package where available. fileConfig() exception handling added for handler instantiation. Changed basicConfig() to add keyword arguments. Changes are backward-compatible. Refactored RotatingFileHandler to create a base class for rotating handlers. Added TimedRotatingFileHandler (thanks to Mark Davidson - minor changes have been made to the patch he supplied). Added error checking to log() to check that level is an integer, and raise a TypeError if not (as long as raiseExceptions is set). Fixed a bug in DatagramHandler.send() (thanks to Mario Aleppo and Enrico Sirola for pointing it out). Minor documentation corrections.

6 11

Re: ANNOUNCE: GnomePython 2.6.0
by darren＠coolpink.net Oct. 4, 2004

Oct. 4, 2004

Sorry, but I am out of the office on Monday 27th September until Monday 11th October 2004. I will respond to your e-mail when I return If you need technical support please contact simonh(a)coolpink.net or mazen(a)coolpink.net For any other enquiries please call the office on (0113) 272 3191 Thanks for your e-mail.

1 0

Re: metaclass and customization with parameters
by Anna Martelli Ravenscroft Oct. 4, 2004

Oct. 4, 2004

Carlos Ribeiro wrote: > On 4 Oct 2004 03:23:32 -0700, Michele Simionato > <michele.simionato(a)gmail.com> wrote: > >>Notice that there already valuable resources on this stuff. >>Unfortunately, after several minutes of searching on www.python.org >>I didn't find them (which may denote that something is wrong with me >>or with python.org). Search for new style classes, >>Shalab <last name which spelling I cannot remember> and may be >>even Dave Kuhlman <where the spelling is probably wrong>. > > > I've read all the tutorials and resources pointed there from the Wiki > as a starting point. All do a good job (some better than others) at > explaining a lot of the technical issues. In fact, I've read both > articles you and David Mertz have written, and found them great. The > standard documentation is unfortunately up to this standard -- I've > tried to find comprehensive references for it inside Python's > reference manuals to no avail. This is something that really needs to > be done there. > > But the problem, in my particular case, was not with metaclasses per > se, but with understanding the 'big picture'. With all respect for > you, David Mertz, Alex Martelli, and all the others who helped to > guide me through this (steep) learning curve -- you've done a great > job, and I have to thank you all -- but most of the documentation > seems to start 'from the inside'; in other words, from the perspective > of someone that thoroughly understands how Python works, specially > regarding the handling of declarations (classes, modules and > functions), and that also knows what metaclasses are good for. For > people that come from a different background (such as me), some of the > explanations fail to 'ring a bell', which usually only happens after a > lot of practical attempts and failures. <snip> > > It may be the case that, as I work more with metaclasses, I will tend > towards a more natural vision of the process, and some of the nuances > that are now relevant to me may become a thing of the past. But I > think that I'm not alone on this, and that is the real problem faced > by many newcomers to Python. It's even harder for a person coming to Python as a first programming language. Most technical documentation (not just with Python but with, for example, Linux) assumes that you already understand the topic at hand, just need a clarification of how-to. More explanation about "why-to" and "what does it mean" and underlying "how do I usefully think about this" is really helpful (in carefully measured doses... :-) It's unfortunately common that people who understand the topic thoroughly (in any field, not just computers) don't think about the details consciously anymore, so it isn't that they *choose* not to mention it - it simply never occurs to them to mention it, because they "just know". This is a common issue in Training - the subject matter experts often are too "deep" in their subject to be able to explain it well to newbies. I give a lot of credit to many of the folks in Python - at least they care whether they're getting across to newcomers. Some do better than others at explaining, but all of them seem to care. They *want* to know when something isn't clear and *why* so they can *fix* it! (Unlike my initial experience with some computer areas many years ago, where anyone who couldn't figure it out on their own was accused of being too stoopid to waste time on...) Anna

1 0

C API eqivalent of object.__new__
by Jacek Generowicz Oct. 4, 2004

Oct. 4, 2004

How would one write object._new__(SomeType) in the C API ? ... and what lies behind the following behaviour: >>> object.__new__(T) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: object.__new__(T) is not safe, use T.__new__() where T refers to almost any fundamental Python type ?

2 8

weak references an C extension types
by vng1＠mac.com Oct. 4, 2004

Oct. 4, 2004

Hi all, I'm trying to build a C extension that supports weak references with Pyrex but I'm pretty confused as to what I need to do. The docs at : http://docs.python.org/lib/weakref-extension.html make reference to PyObject_ClearWeakRefs and to a tp_flags settings which I'm not sure how to access from Pyrex. Has anyone had success with weak references and Pyrex? vic

1 0