Dr. Dobb's Python-URL! - weekly Python news and links (Jul 29)
QOTW: Guido has marked the trail; don't ignore the signs unless you really know where you're going. - Raymond Hettinger 'Proverbs 28:14 JPS Happy is the man that feareth alway; but he that hardeneth his heart shall fall into evil. Obviously an exhortation to not ignore raised exceptions with except: pass.' - Robert Kern Jason Orendorff's path module is a popular alternative to the build in os.path and shutil modules. Michael Hoffman and Reinhold Birkenfeld are working on a PEP suggesting that it be included in the standard library: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/1f5bcb67c4c73f15 http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/df1b647a0f103640 Java has nearly as many web frameworks as Python, but you can run any of them on any of the Java web application servers because they are all built on the Java Servlet specification. PEP 333, the Python Web Server Gateway Interface, aims to bring something similar to the world of Python: http://www.python.org/peps/pep-0333.html A short but sweet day-of-the-month suffix generator from John Machin: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/904fa627890c85dd Thanos Tsouanas wants access to an object's namespace dictionary: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/d5cc509d138e1701 David Isaac wants to avoid map(), but he wants a zip() function that runs to the length of the longest sequence. It's suggested that zip() should be able to do this, but Raymond Hettinger channels Guido and thinks that this would be a bad idea: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/265675b50fee8ec1 Tiny.be release four open source enterprise applications: http://lwn.net/Articles/145209/ Who needs Ten Essential Development Practices? We've got The Zen of Python: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/c52d3c17f1ea9ec5 Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. For far, FAR more Python reading than any one mind should absorb, much of it quite interesting, several pages index much of the universe of Pybloggers. http://lowlife.jp/cgi-bin/moin.cgi/PythonProgrammersWeblog http://www.planetpython.org/ http://mechanicalcat.net/pyblagg.html comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djqas_ugroup=comp.lang.python.announce Steve Bethard, Tim Lesher, and Tony Meyer continue the marvelous tradition early borne by Andrew Kuchling, Michael Hudson and Brett Cannon of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of Python resources. http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Kurt B. Kaiser publishes a weekly report on faults and patches. http://www.google.com/groups?as_usubject=weekly%20python%20patch Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to
Re: Python-cgi or Perl-cgi script doubt
Prabahar wrote: I want to know difference between Python-cgi and Perl-cgi and also I want to which one is efficient from the performance. The difference between a cgi program written in Perl and a cgi program written in Python is the choice of programming language. Both work quite well. You probably want to use whichever programming language you like best, and that can only be discovered from writing programs in both. In terms of efficient (efficiency) , are you talking about how much memory the program uses, how fast the program executes, or how much time it takes to write and debug the program? There are differences between the two in these regards, but I do not have any reliable information that quantifies those differences, and the differences are likely to vary greatly depending on the nature and length of the program, and how efficiently written the code is. I think, generally, if you really like programming in Perl, there is probably no reason not to use it (at least for typical/short cgi programs) - it has been the default choice for years; conversely, if you really like programming in Python, you will probably be happy to tackle any challenges associated with using it for cgi. Notes: Perl cgi execution is generally offered by all hosts that offer cgi; Python cgi execution is offered by fewer hosts (but some of those hosts are really great). With either language, if execution performance is a concern, you may want to use something along the lines of mod_python or mod_perl which embed a persistent interpreter in your web server. This lets you avoid the overhead of starting an external interpreter and avoids the penalty of Perl/Python start-up time, giving faster time to execution. Was this at all the information you were looking for? Why do I think you may have intended a very technical question? If so, you may have to be a little more specific about the sort of differences you are interested in understanding. Eric -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
James Richards [EMAIL PROTECTED] writes: Personally, I can't recall any decent programmer I know who objects to actually writing out a variable name. In fact, I don't know a single real programmer (this is one who writes programs he intends to look at again in, say, 3 weeks) who doesn't insist on writing real variable names. The issue is whether you want to name every intermediate result in every expression. sum = a + b + c + d + e is a lot nicer than x1 = a + b x2 = c + d x3 = x1 + e sum = x2 + x3 the language has nicely kept all those intermediate results anonymous. Python has first-class functions, which, like recursion, is a powerful idea that takes some getting used to. They let you say things like def derivative(f, t, h=.1): # evaluate f'(t) numerically return (f(t+h) - f(t)) / h dy_dt = derivative(cos, 0.3) # approx. -sin(0.3) With anonymous functions, you can also say: dy_dt = derivative(lambda x: sin(x)+cos(x), 0.3) # approx. cos(.3)-sin(.3) Most Python users have experience with recursion before they start using Python, so they don't see a need for extra keywords to express it. Those not used to first-class functions (and maybe some others) seem to prefer extra baggage. For many of those used to writing in the above style, though, there's nothing confusing about using a lambda there instead of spewing extra verbiage to store that (lambda x: sin(x)+cos(x)) function in a named variable before passing it to another function. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Calvin Spealman [EMAIL PROTECTED] writes: The choice is GUI toolkits is largely seperate from Python. Consider that they are just bindings to libraries that are developed completely seperate of the language. GUI is should be seperate from the language, and thus not bound to same expectations and desires as elements of the language itself. I disagree. A modern language must provide a convenient and well-embedded way to write GUI applications. This is not a sign of decadence, but a very good promotional argument. Delphi and first and foremost VB are extremely popular, and it's sad to see that Python could get a lot more of the cake if the efforts for IDEs and toolkits were somewhat streamlined. Besides, all other already good aspects of Python wouldn't suffer at all. Tkinter fits into Python very well and it is very easily (if not trivially) accessible for users of our applications. People complain about non-native look-and-feel on Windows, but sorry, I simply find it unacceptably ugly on all platforms. Don't misunderstand me: I don't like neat GUI effects just for the sake of it but Tkinter makes an outdated impression on the end-user. I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Probably I'll use it nevertheless. PyGTK and PyQt may have their own advantages and disadvantages. However, in my opinion we don't need yet another binding so thin that C or C++ is shining through, but a modern replacement for Tkinter with its Pythonic way of thinking. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
Tim Roberts schrieb: Scott David Daniels [EMAIL PROTECTED] wrote: What kind of shenanigans must a parser go through to translate: x**2 with(x)x**3 with(x) this is the comparison of two functions, but it looks like a left- shift on a function until the second with is encountered. Then you need to backtrack to the shift and convert it to a pair of less-thans before you can successfully translate it. C++ solves this exact problem quite reasonably by having a greedy tokenizer. Thus, that would always be a left shift operator. To make it less than and a function, insert a space: x**2 with(x) x**3 with(x) -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. Python does have such a greedy/longest match tokenizer too: 2 .__add__(3) # insert whitespace before dot 5 2.__add__(3)# 2. is a float - Exception Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
why (x**2 with(x))(x**3 with(x)) is not taken in consideration? If 'with' must be there (and substitue 'lambda:') then at least the syntax is clear.IMO Ruby syntax is also clear. ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it -- http://mail.python.org/mailman/listinfo/python-list
Re: Hiding
but also, wat if i needed to hide the loading of a file or the even hide the whole python window to run in background?? is there no module or function i can use -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
Mike Meyer wrote: Rewriting a canonical abuse of lambda in this idiom gives: myfunc = def @(*args): return sum(x + 1 for x in args) Nice proposal. Technically you don't need the @ there, it is superfluous. But then again so is the colon, so whatever floats your boat. class Spam(object): myprop = property(fget = def @(self): return self._properties['myprop'] , fset = def @(self, value): self._properties['myprop'] = value , fdel = def @(self) del self._properties['myprop'] , doc = Just an example) I think the anonymous lambdas need to be outside the parentheses to be parsable. Maybe like this: class Spam(object): myprop = property(fget, fset, fdel, doc=just an example): where fget = def (self): . where fset = def (self): . where fdel = def (self): ... As you can see, it doesn't save much over the traditional way since you have to name the anonymous lambdas anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
D H [EMAIL PROTECTED] writes: where fdel = def (self): ... As you can see, it doesn't save much over the traditional way since you have to name the anonymous lambdas anyway. It saves polluting the surrounding namespace with superfluous variables that aren't going to be used again. -- http://mail.python.org/mailman/listinfo/python-list
keylogger in Python
ok, i thought for 2 seconds i might have created a Keylogger in python but i still have one major think stopping me... PYTHON. when i run the program i have python create a file named keylog2.log and it then logs all keys pressed/typed in the python IDE into that file. All i want to know now is how do i hide or background python so that it will log all the keys pressed outside of Python. feel free to play around with my program... but please post ur findings on my post... # class keylogger: pass keylogging = keylogger() keylog = open(keylog2.log, w) text = raw_input() keylog.write(text) keylog.close keylog = open(keylog2.log, r) keylog.read -- http://mail.python.org/mailman/listinfo/python-list
Re: Block-structured resource handling via decorators
I will shamelessly point out my decorator module: http://www.phyast.pitt.edu/~micheles/python/decorator.zip The documentation is here: http://www.phyast.pitt.edu/~micheles/python/documentation.htm There is an example of redirecting stdout which is relevant to this thread. HTH, Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: keylogger in Python
Jay [EMAIL PROTECTED] writes: ok, i thought for 2 seconds i might have created a Keylogger in python but i still have one major think stopping me... PYTHON. when i run the program i have python create a file named keylog2.log and it then logs all keys pressed/typed in the python IDE into that file. All i want to know now is how do i hide or background python so that it will log all the keys pressed outside of Python. You are completely confused and keyloggers don't work anything like that. Why do you want to log keystrokes anyway? -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
Christopher Subich [EMAIL PROTECTED] writes: Basically, I'd rewrite the Python grammar such that: lambda_form ::= expression with parameter_list I do prefer my parameter list to come before the expression. It would remain consistant with simple function definitions. - Cheers, Paddy. -- http://mail.python.org/mailman/listinfo/python-list
Re: To thread or not to thread
On 28 Jul 2005 12:10:12 -0700, Sidd [EMAIL PROTECTED] wrote: Hello, I was recently reading an article on threading in python and I came across Global Interpreter Lock,now as a novince in python I was cusrious about 1.Is writing a threaded code in python going to perform well than a normal python code.If so on what basis can it performance be measured. 2.Is writing a threaded code in python better than a code written in C/C++ using PTHREADS. If someone can comment on these questions, it would be great. If you want performance with an application that does a lot of concurrent activity, you might take a look at http://www.twistedmatrix.com which is an event driven framework for python. Much better performance than threads with a lot less memory and cpu usage. Although it does have a bit of a learning curve. In my own experience it would be faster then a comparable application written in C using pthreads. We have an application written in twisted that processes financial applications via bank networks, and at a steady 100tps I get about 1% cpu usage. We tested it up to around 1000tps before our database server started to get a bit overloaded. Twisted never used more than 20% of the cpu though. Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
on 30.07.2005 10:20 Paolino said the following: why (x**2 with(x))(x**3 with(x)) is not taken in consideration? If 'with' must be there (and substitue 'lambda:') then at least the syntax is clear.IMO Ruby syntax is also clear. I am sorry if this has already been proposed (I am sure it has). Why not substitue python-lambdas with degenerated generator expressions:: (lambda x: func(x)) == (func(x) for x) i.e. a one time callable generator expression (missing the `in` part). The arguments get passed into the generator, I am sure that can be combined with the PEP about passing args and Exceptions into a generator. -- http://mail.python.org/mailman/listinfo/python-list
rfc822 module bug?
Hi all, I found that the function parsedate_tz of the rfc822 module has a bug (or at least I think so). I found a usenet article (message-id: [EMAIL PROTECTED]) that has this Date field: Date: Tue,26 Jul 2005 13:14:27 GMT +0200 It seems to be correct¹, but parsedate_tz is not able to decode it, it is confused by the absence of a space after the ,. I studied the parsedate_tz code and the problem is on its third line: ... if not data: return None data = data.split() ... After the split I have: ['Tue,26', 'Jul', '2005', '13:14:27', 'GMT', '+0200'] but Tue, and 26 should be separated. Of course parsedate_tz correctly decode the field if you add a space after the ,. Do you think that's a bug? Which is the most correct place where to file this bug? ¹ and looking at rfc822 par3.3 it should be correct: date-time = [ day-of-week , ] date FWS time [CFWS] day-of-week = ([FWS] day-name) / obs-day-of-week day-name= Mon / Tue / Wed / Thu / Fri / Sat / Sun date= day month year -- A pat on the back is only a few centimeters from a kick in the butt. |\ | |HomePage : http://nem01.altervista.org | \|emesis |XPN (my nr): http://xpn.altervista.org -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
Stefan Rank [EMAIL PROTECTED] writes: I am sorry if this has already been proposed (I am sure it has). Why not substitue python-lambdas with degenerated generator expressions:: (lambda x: func(x)) == (func(x) for x) I don't think I've seen that one before, and FWIW it's kind of cute. But what's wrong with leaving lambdas the way they are? Anyone who can understand generator expressions can understand lambda. I don't see any point in trying to improve on lambda, without actually fixing its main problem, which is the inability to create multi-statement closures. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python-cgi web or Perl-cgi script doubt
praba kar wrote: I want to know difference between Python-cgi and Perl-cgi and also I want to which one is efficient from the performance. Possibly the most important difference between the two is when you're using JUST cgi - ie no mod_perl, no mod_python, etc. With python, if your cgi is structured to use more than one file, then your programs can be compiled and stored on disk (compiled to something called bytecode). This can just be loaded and executed immediately on subsequent runs. With perl, the program needs to be loaded and recompiled with each run. For small CGI systems this difference is negligible, but for large CGI based systems (eg when using a large framework), these differences can become very important - if you do not have the option to use mod_perl/mod_python or similar. However, many people running large web systems do tend to use mod_perl and friends when using perl which discounts this argument pretty much completely. That said, I'd suggest looking to see *what* you want to do, look at what *tools* are available and *then* decide which *language* to use. Personally I find python nicer for this sort of things these days - larger because it naturally encourages better strutcure. (And this is after having using perl day-in, day-out for 5 years, and still liking perl :-) Hope that's of some use, Michael. -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
Mike Meyer schrieb: I know, lambda bashing (and defending) in the group is one of the most popular ways to avoid writing code. However, while staring at some Oz code, I noticed a feature that would seem to make both groups happy - if we can figure out how to avoid the ugly syntax. This proposal does away with the well-known/obscure lambda keyword. It gives those who want a more functional lambda what they want. It doesn't add any new keywords. It doesn't add any new magic characters, though it does add meaning to an existing one. That could be replaced by a new magic token, or adding magic meaning to a non-magic token. It breaks no old code either way. Mike, in modern functional language design one starts with certain lambda expressions and add syntax sugar ( operational / statement syntax ) for constructs based on them. In Python statement- and expression syntax were introduced seperately. Pythons lambda is simply the symptom of this separation. Now you suggest ( not the first time on this list or at python-dev ) to put statements into expressions leading to a strange syntax and conflicting with Pythons indentation rules. Another way to deal with the restrictions of lambda is going the other way round and simply propose expression syntax for conds and assignments. Using guards '||' and the keyword 'then' for conditional expressions: ( || x=0 then f(x) || True then f(-x) ) Or shorter dropping 'then' in the second condition: ( || x=0 then f(x) || f(-x) ) Both translates to: if x=0: f(x) else: f(-x) Using a reverse arrow for assignments: x - y For loops can be replaced by functional constructs ( use map() or a list/generator comprehension ). Finally the lambda keyword can be replaced by expressional syntax e.g. ( EXPR from ARGS ): Examples: f = ( || x=0 then f(x) || True then f(-x) from (x,) ) g = ( || x 0 then self._a -x || self._a - 0 from (x,)) Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: multiple inheritance super()
If I understand correcly you have a situation like this: Base | Parent1 Mixin | | | | Children1 Base | Parent2 Mixin | | | | Children2 Base | Parent3 | | Children3 The Base class is pretty general, Parent1, Parent2 and Parent3 are more specific, Children1 and Children2 requires the Mixin class, but Children3 does not require it. Let me note that this looks like a sensible design and that I agree that in simple situations multiple inheritance could be the simplest solution. Nevertheless 1) I am scared of the case where you have hundreds of methods coming from everywhere (ex. Zope) and 2) even in simple situations a solution without multiple inheritance is not that much worse. Various solutions (using pseudocode): 1. use single inheritance and attach the mixin methods by hand: class Children2(Parent2): pass for methodname, method in methods_of(Mixin): setattr(Children2, methodname, method) if you think this is ugly, use a metaclass to attach the methods for you. This is probably still ugly, since it is akin to reimplementing multiple inheritance by hand. Still, it can be done, if you really want. 2. use single inheritance and delegation. If mixin is a proxy to the methods in the mixin (for instance implemented as an attribute descriptor) you could do class Children2(Parent2): mixin = Proxy(Mixin) c2 = Children2() and then c2.mixin.method(args) would actually call Mixin.method(c2, args). I like this solution since it is clear where methods come from and it scales better to complex situations (still if you have only 2 or 3 methods multiple inheritance could be pretty fine). 3. think differently and use multimethods There are implementations of multimethods in Python (for instance in PEAK). This example looks like a good candidate for a multiple dispatch solution. You would use single inheritance and promote the mixin methods to multimethods. BTW, I think multimethods are pretty nifty and I would welcome them in standard Python. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
Kay Schluehr [EMAIL PROTECTED] writes: Examples: f = ( || x=0 then f(x) || True then f(-x) from (x,) ) g = ( || x 0 then self._a -x || self._a - 0 from (x,)) Is this an actual language? It looks sort of like CSP. Python with native parallelism, m. -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
Paul Rubin wrote: Kay Schluehr [EMAIL PROTECTED] writes: Examples: f = ( || x=0 then f(x) || True then f(-x) from (x,) ) g = ( || x 0 then self._a -x || self._a - 0 from (x,)) Is this an actual language? It looks sort of like CSP. Python with native parallelism, m. The syntax was inspired by OCamls pattern matching syntax: match object with pattern1- result1 | pattern2- result2 | pattern3- result3 ... But for Python we have to look for an expression not a statement syntax. In order to prevent ambiguities I used a double bar '||' instead of a single one. Kay -- http://mail.python.org/mailman/listinfo/python-list
How can I run a program?
Hello, I am running Python on XP and have a problem with a program if its name consists '-' for example: my-program.py When I try to run a program with such name I get the error : Traceback (most recent call last): File interactive input, line 1, in ? NameError: name 'my' is not defined Python thinks that the name of program is my.py only but the name is my-program.py What is a solution? Thank you Lad. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ten Essential Development Practices
Dark Cowherd wrote: GUI, Web development, Application Framework - it is shambles. Yeah, I agree. When I finally make that GUI application I still don't know whether I am going to use wx or PyGTK. I was part of the anygui development team, back when it was still active (I think I technically am still part of the team, we just haven't checked in any new code since I left BeOS!). It was a plan to allow GUI access to be as simple and 'once' as anydb does for accessing the database systems it does. We failed. Although we did actually have some code that was working really well, across several platforms and GUI systems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Graphics files Python
In article [EMAIL PROTECTED], Terry Reedy wrote: Besides the other responses, you might also check out the pygame site where there once were some tutorial examples of manipulating bitmaps with Numerical Python to get various effects. I'll keep this in mind too. Thanks to both for helpful replies. -- Pekka Karjalainen - Oulu, Finland -- http://mail.python.org/mailman/listinfo/python-list
Re: functions without parentheses
On Fri, 29 Jul 2005 06:37:52 GMT, Bengt Richter [EMAIL PROTECTED] wrote: I suggested in a previous thread that one could support such a syntax by supporting an invisible binary operator between two expressions, That's a truely appalling idea. so that examine string translates to examine.__invisbinop__(string) if examine as an expression evaluates to an object that has a __invisbinop__ method. Then you wouldn't define examine as a function, you would define it as an instance of a class like class Examine(object): define __invisbinop__(self, other): #...whatever examine = Examine() and then examine string Pass the sick bucket. -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: How can I run a program?
* Lad (2005-07-30 11:33 +0100) I am running Python on XP and have a problem with a program if its name consists '-' for example: my-program.py When I try to run a program with such name /How/ do you run the program for Guido's sake?! I get the error : Traceback (most recent call last): File interactive input, line 1, in ? NameError: name 'my' is not defined Python thinks that the name of program is my.py only but the name is my-program.py What is a solution? The solution to get answers is to give details. But to play the clairvoyant: /If/ you tried to run the program from a command prompt or from by klicking on the file there should be no problems. /If/ you tried to run the program by importing it from the Python shell, then this is normal. A hyphen is not allowed in module names at it is the same character as in subtractation. -- http://mail.python.org/mailman/listinfo/python-list
PyPy sprint announcement: Heidelberg 22nd - 29th August 2005
PyPy Sprint in Heidelberg 22nd - 29th August 2005 == The next PyPy sprint will take place at the Heidelberg University in Germany from 22nd August to 29th August (both days included). Its main focus is translation of the whole PyPy interpreter to a low level language and reaching 2.4.1 Python compliancy. To learn more about the new PyPy Python implementation look here: http://codespeak.net/pypy Goals and topics of the sprint -- One of the main goals of the sprint is going to be a 0.7 release of PyPy. The 0.7 is meant to be the first self-contained PyPy version but still alpha with some C-extension modules missing and not meant for production use. Therefore the topics of the sprint will be: - translation efforts: it's not completely clear now what related task will be left at that time - work on 2.4.1 compliancy: there are some failing compliancy tests on which we plan to work - rewriting c-extension modules/integrating existing rewrites - all kinds of small release issues - possibly some more LLVM efforts Location Accomodation The sprint will be held in a conference room of the Institute of Physics, University of Heidelberg. We have WLAN connection there and small kitchen to make tea and coffee. `See here`_ how to get there from the Heidelberg main station. There is a huge number of hotels_ in Heidelberg, all of which are unfortunately rather expensive. It should be no problem to reach the sprint venue from anywhere in Heidelberg. As an alternative you could also take a `hotel in Mannheim`_ which you can reach in 15 min from Heidelberg with the train. .. _`See here`: http://www.physi.uni-heidelberg.de/physi/front/anfahrt.en.php .. _hotels: http://www.cvb-heidelberg.de/index_eng.html .. _`hotel in Mannheim`: http://www.hotels.de/en/mannheim.htm Exact times --- The Pypy sprint is held Monday 22nd August - Monday 29th August 2005. Hours will be from 09:00 until people have had enough. It's a good idea to arrive a day before the sprint starts. Network, Food - The Heidelberg Altstadt can be reached in approximately 10 min from the sprint venue. There you will find all kinds of restaurants and fast food places. You will probably need a wireless network card to access the network although we could set up a WLAN to cable bridge if necessary. Registration etc.pp. Please subscribe to the `PyPy sprint mailing list`_, introduce yourself and post a note that you want to come. Feel free to ask any questions there! There also is a separate `Heidelberg people`_ page tracking who is already thought to come. If you have commit rights on codespeak then you can modify yourself a checkout of http://codespeak.net/svn/pypy/extradoc/sprintinfo/heidelberg-people.txt .. _`Heidelberg people`: http://codespeak.net/pypy/index.cgi?extradoc/sprintinfo/heidelberg-people.html .. _`PyPy sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint -- Carl Friedrich Bolz the PyPy-Team -- http://mail.python.org/mailman/listinfo/python-list
Re: Hiding
* Jay (2005-07-30 08:51 +0100) but also, wat if i needed to hide the loading of a file As others have pointed out: your question is pointless as opening a file doesn't load it or open it in your preferred application. You are confusing Operating System semantics with Python semantics. You're probably only asking this question because you've never actually tried it. The solution for your problem is to read a beginner's tutorial about Python. or the even hide the whole python window to run in background?? is there no module or function i can use On windows: use pythonw.exe instead of python.exe. -- http://mail.python.org/mailman/listinfo/python-list
Re: Block-structured resource handling via decorators
The only cases I see the first school of thought is when the resource
in question is scarce in some way.
By resource I meant anything with some sort of acquire/release
semantics. There may be plenty of threading.Locks available, but it's
still important that a given Lock is released when not needed.
For example, most OS's place a
class withFile(blockScopedResource):
init, cleanup = open, 'close'
Well, I'd say that using a string for cleanup and a function for init
is unpythonic.
I could have specified cleanup as lambda f:f.close(), but as I thought
it might be quite common to call a method on the resourse for cleanup,
if a string is specified a method of that name is used instead.
The question is whether having to turn your scope into a
function to do this is more trouble than it's worth.
Needing one slightly contrived-looking line (the def) vs a try-finally
block with explicit cleanup code? I know which I'd prefer, but for all I
know I could in a minority of 1 here.
I'd certainly be interested in seeing the implementation.
And so you shall...
I start with the base class. It does all the work, everything else is
just tweaks for convenience. Normally, then, you wouldn't need to bother
with all the __init__ params.
class blockScopedResource(object):
def __init__(self, init, cleanup,
initArgs, initKwargs, cleanupArgs, cleanupKwargs,
passResource, resourceIsFirstArg):
self.init = init # function to get resource
self.cleanup = cleanup # function to release resource
self.initArgs, self.initKwargs = initArgs, initKwargs
self.cleanupArgs, self.cleanupKwargs = cleanupArgs,
cleanupKwargs
self.passResource = passResource # whether resource is passed
into block
self.resourceIsFirstArg = resourceIsFirstArg # whether resource
is arg to init,
# rather than returned from it
def __call__(self, block):
resource = self.init(*self.initArgs, **self.initKwargs)
if self.resourceIsFirstArg:
resource = self.initArgs[0]
try:
if self.passResource:
block(resource)
else:
block()
finally:
self.cleanup(resource, *self.cleanupArgs,
**self.cleanupKwargs)
But this still won't do conveniently for files and locks, which are my
motivating examples.
The simpleResource class constructor gets its setup from attributes on
the type of the object being created, with sensible defaults being set
on simpleResource itself. As stated above, if a string is supplied as
init or cleanup, it is treated as a method name and that method is used
instead.
def stringToMethod(f):
# Getting the attribute from the class may have wrapped it into
# an unbound method; in this case, unwrap it
if isinstance(f, types.MethodType) and f.im_self is None:
f = f.im_func
if not isinstance(f, basestring): return f
def helper(resource, *args, **kwargs):
return getattr(resource, str(f))(*args, **kwargs)
return helper
class simpleResource(blockScopedResource):
def __init__(self, *initArgs, **initKwargs):
# get attributes off type
t = type(self)
blockScopedResource.__init__(self,
stringToMethod(t.init), stringToMethod(t.cleanup),
initArgs, initKwargs, t.cleanupArgs, t.cleanupKwargs,
t.passResource, t.resourceIsFirstArg)
# defaults supplied here
cleanupArgs, cleanupKwargs = (), {}
passResource = True
resourceIsFirstArg = False
Then useful implementations can be written by:
class withFile(simpleResource):
init, cleanup = open, 'close'
class withLock(simpleResource):
init, cleanup = 'acquire', 'release'
passResource = False
resourceIsFirstArg = True
And new ones can be created with a similar amount of effort.
Of course, one-liners can be done without using the decorator syntax:
withLock(aLock)(lambda:doSomething(withAnArg))
Gotcha: If you stack multiple resource-decorator it won't do what you
want:
# !!! DOESN'T WORK !!!
@withLock(aLock)
@withLock(anotherLock)
def do():
# ...
Either nest them explicitly (causing your code you drift ever further to
the right):
@withLock(aLock)
def do():
@withLock(anotherLock)
def do():
# ...
Or come up with a multiple-resource handler, which shouldn't be too
hard:
@withResources(withLock(aLock), withLock(anotherLock),
withFile('/dev/null'))
But I'll get round to that another day.
--
http://mail.python.org/mailman/listinfo/python-list
Comparison of functions
Playing around with comparisons of functions (don't ask), I discovered an interesting bit of unintuitive behaviour: (lambda y: y) (lambda y: y) False Do the comparison again and things become even more bizarre: (lambda y: y) (lambda y: y) True (lambda y: y) (lambda y: y) False This behaviour should be easy for experienced Pythonisters to answer, but will probably confuse beginners greatly. For the benefit of beginners, imagine we expand the first line into two, and commit what some people call an abuse of lambdas: we bind them to names. a = lambda y: y b = lambda y: y a function lambda at 0xf70598ec b function lambda at 0xf7059844 a and b are now bound to two objects, each of which is an anonymous function that just happens to do the same thing. But each time you create a lambda function, you get a different object at some unpredictable location in memory. This is where my level of Python knowledge fails me. I don't understand how Python is comparing the two objects since neither a nor b have any rich comparison methods or even the old-style __cmp__ method. a b False So I'm puzzled about how Python compares the two. If we compare a and b again, we will always get the same answer. But if we create a new pair of anonymous functions with lambda, and compare them, it is the luck of the draw each time whether the first compares bigger or smaller than the second. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Path inherits from basestring again
NickC wrote: [Re: alternatives to overloading '/'] Is there a reason the Path constructor is limited to a single argument? If it allowed multiple arguments, the following would seem very straightforward: p = Path(somePath, user.getFolder(), 'archive', oldPath + .bak) That's a quite good idea. Thanks! I'm usually not much of a purist, but C++ has convinced me that overloading an operator to mean something entirely unrelated to its mathematical meaning can be very unwise. It's much the same as with @ decorators. Those who have used them much don't object to the syntax any more. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Ivan Van Laningham wrote: Hi All-- Tony Meyer wrote: So far, there have been various statements that look like +0 for __div__, but no-one with a +1. (And I've said this a couple of times now, which really is just trolling for a +1 from someone). It's not a question of saving characters, but readability which, as you've said, is a matter of opinion. I like / as a shortcut to joinwith(). I like it a lot. I like it so much I'll give you a +2. Add a +1 from me. (Those who are offended by sweeping generalisations should ignore this next bit) I think it's also worth considering that Windows users are more clueless than users of posix systems. The readability of __div__ comes from familiarity with posix filesystems; for a Windows user, \ would be the natural character. So we're making things more readable for users that are already more likely figure things out, and less readable for users that have trouble figuring things out. This is not only bullshit, it's elitist bullshit. Windows users are more clueless than users of posix systems. Pfui. Prove it or withdraw it. Above all, nobody can tell me that there's any programmer who doesn't instantly recognize '/' as a directory separator. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano wrote: Playing around with comparisons of functions (don't ask), I discovered an interesting bit of unintuitive behaviour: (lambda y: y) (lambda y: y) False Do the comparison again and things become even more bizarre: (lambda y: y) (lambda y: y) True (lambda y: y) (lambda y: y) False This behaviour should be easy for experienced Pythonisters to answer, but will probably confuse beginners greatly. Beginners should not be comparing lambdas. Neither should you. ;-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano wrote: Playing around with comparisons of functions (don't ask), I discovered an interesting bit of unintuitive behaviour: a = lambda y: y b = lambda y: y a function lambda at 0xf70598ec b function lambda at 0xf7059844 a b False So I'm puzzled about how Python compares the two. Seems to me the object addresses are compared in this case. But I'm too lazy to check it in the source. ;) However, the doc [1] warns you about such comparisons: Most other types compare unequal unless they are the same object; the choice whether one object is considered smaller or larger than another one is made arbitrarily but consistently within one execution of a program. [1] http://docs.python.org/ref/comparisons.html -- http://mail.python.org/mailman/listinfo/python-list
Problems installing Python
I have been trying to install python on an older pc. At first I tryed to install from the Suse 9.1 Pro Cd's. However it reported an error with the core php 4 file. I tried again with the same result. So I checked with Suse and there was an updated version. I downloaded it and it also reported an error installing the core php 4 file. I need Python installed as a program I want to run requires it. Does anyone have any idea's I can try? TIA Bob -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP on path module for standard library
Mike Orr wrote:
The main changes I'd like to see in Path (some of these have been made
in Python CVS at nondist/sandbox/path/path.py) are:
Thanks for the comments! They are greatly appreciated.
- When methods create path objects, use self.__class__() instead of
Path().
This makes it possible to subclass Path. Otherwise you
have to rewrite the whole thing due to the hardcoded name.
- Path.cwd() should be a class method instead of a static method, for
the same
reason.
Changed by now.
- The constructor behavior in CVS is good. Path(''), Path.cwd(),
Path() = Path.cwd().
Note that Path() results in os.curdir, while Path.cwd() results in the
absolute current directory.
- Need .chdir() method, otherwise you have to import os for it.
Added by now.
- Some way to pretty-print paths embedded in lists/dicts as strings. I
have a
.repr_as_str class attribute that toggles this.
I think str() does its job nicely there.
- .ancestor(3) is the same as .parent.parent.parent, but more concise.
Good proposal, will consider this.
- I saw in a thread that .name and .parent were removed. I use them
very
frequently, along with .ext and .namebase. I don't want to call
methods for
these.
They are now named .basename and .directory.
- '/' vs .joinpath(), no big deal. I've been using '/' because it's
there.
.joinpath must take multiple *args, to prevent .joinpath().joinpath()
.
That's already in.
- .joinancestor(N, *components) is a combination of .ancestor and
.joinpath.
If curdir is /home/joe/Webware/www, Path.cwd().joinancestor(1, 'lib')
is
/home/joe/Webware/lib.
I think Path.cwd().parent.joinwith('lib') is readable enough.
- Keep .lisdir() as in CVS; it acts like os.listdir(). This is useful
even
with paths, when you're just going to use the string basename anyway.
Right. In addition, it's confusing if os.listdir is behaving differently
from Path.listdir().
- Who needs .open()? open(myPath) is fine. But it can stay for
backward
compatibility.
Right. I think it's nice for people who like a more OO approach.
Less important but non-controversial:
- Path.tempfile(), Path.tempdir():
Create a temporary file using tempfile.mkstemp, tempfile.mkdtemp
- Path.tempfileobject():
Create a temporary file object using tempfile.TemporaryFile.
(Static method.)
Don't know whether these belong here. They are all not acting upon the
path, but create the file/dir at another location.
Controversial:
- Delete methods and mkdir should succeed silently if the operation is
already done. Otherwise you always have to put them in an if:
'if foo.exists(): foo.remove()'.
That's a good thing. The delete methods shouldn't act any different from
the corresponding os functions.
- .delete_dammit() recursively deletes it, whatever it is, without you
having to do the if file/if directory dance. I suppose it would need
a
politically correct name.
which you really have to do every time you delete.
*grin* Any naming suggestions?
- All .dirs*, .files*, .walk* methods have a symlinks flag, default
True.
If false, don't yield symlinks. Add .symlinks and .walksymlinks
methods.
This eliminates an 'if' for programs that want to treat symlinks
specially.
Sounds good. Will see.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: Path inherits from basestring again
NickC wrote: [Re: how to get at the base class] Do you really want to have a only works for Path way to get at the base class, rather than using the canonical Path.__bases__[0]? How about a new property in the os.path module instead? Something like os.path.path_type. Then os.path.path_type is unicode if and only if os.path.supports_unicode_filenames is True. Otherwise, os.path.path_type is str. Then converting a Path to str or unicode is possible using: as_str_or_unicode = os.path.path_type(some_path) The other thing is that you can simply make Path inherit from os.path.path_type. That's what I suggested with Path.Base. It has the advantage that you don't have to import os.path to get at it (Path is meant so that you can avoid os.path). Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
Stefan Rank wrote: on 30.07.2005 10:20 Paolino said the following: why (x**2 with(x))(x**3 with(x)) is not taken in consideration? If 'with' must be there (and substitue 'lambda:') then at least the syntax is clear.IMO Ruby syntax is also clear. I am sorry if this has already been proposed (I am sure it has). Why not substitue python-lambdas with degenerated generator expressions:: (lambda x: func(x)) == (func(x) for x) i.e. a one time callable generator expression (missing the `in` part). The arguments get passed into the generator, I am sure that can be combined with the PEP about passing args and Exceptions into a generator. It's hard to spot, and it's too different to a genexp to have such a similar syntax. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
On Sat, 30 Jul 2005 08:13:26 -0400, Peter Hansen wrote: Beginners should not be comparing lambdas. Neither should you. ;-) Actually, yes I should, because I'm trying to make sense of the mess that is Python's handling of comparisons. At least two difference senses of comparisons is jammed into one, leading to such such warts as these: L = [] L.sort() # we can sort lists L.append(1+1j) L.sort() # even if they include a complex number L.append(1) L.sort() # but not any more Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = Um, I didn't ask to compare complex numbers using comparison operators. I asked to sort a list. And please don't tell me that that sorting is implemented with comparison operators. That just means that the implementation is confusing numeric ordering with sort order. Then there is this: 1 0 True 1+0j == 1 True 1+0j == 1 0 True 1+0j 0 Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = I applaud that Python has got rich comparisons for those who need them. But by confusing the question which comes first in a sorted list? with which is larger?, you get all sorts of warts like being unable to sort lists with some objects, while being able to make meaningless comparisons like ''.join = [].append. I'm not sure what the solution to this ugly state of affairs is. I'm not even sure if there is a solution. But I'm willing to make a good effort to *look*, and even though you were joking, I don't appreciate being told not to. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
On Sat, 30 Jul 2005 14:20:50 +0200, tiissa wrote: Steven D'Aprano wrote: Playing around with comparisons of functions (don't ask), I discovered an interesting bit of unintuitive behaviour: a = lambda y: y b = lambda y: y a function lambda at 0xf70598ec b function lambda at 0xf7059844 a b False So I'm puzzled about how Python compares the two. Seems to me the object addresses are compared in this case. But I'm too lazy to check it in the source. ;) Strangely enough, I'm lazy enough to not check the source too :-) Actually, more to the point, I don't read C, so even if I did check the source, I wouldn't know what it was trying to tell me. However, the doc [1] warns you about such comparisons: Most other types compare unequal unless they are the same object; the choice whether one object is considered smaller or larger than another one is made arbitrarily but consistently within one execution of a program. I am aware of that. That's a wart. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano ha scritto: On Sat, 30 Jul 2005 08:13:26 -0400, Peter Hansen wrote: Beginners should not be comparing lambdas. Neither should you. ;-) Actually, yes I should, because I'm trying to make sense of the mess that is Python's handling of comparisons. At least two difference senses of comparisons is jammed into one, leading to such such warts as these: L = [] L.sort() # we can sort lists L.append(1+1j) L.sort() # even if they include a complex number L.append(1) L.sort() # but not any more Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = Um, I didn't ask to compare complex numbers using comparison operators. I asked to sort a list. And please don't tell me that that sorting is implemented with comparison operators. That just means that the implementation is confusing numeric ordering with sort order. Then there is this: 1 0 True 1+0j == 1 True 1+0j == 1 0 True 1+0j 0 Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = I applaud that Python has got rich comparisons for those who need them. But by confusing the question which comes first in a sorted list? with which is larger?, you get all sorts of warts like being unable to sort lists with some objects, while being able to make meaningless comparisons like ''.join = [].append. I'm not sure what the solution to this ugly state of affairs is. I'm not even sure if there is a solution. But I'm willing to make a good effort to *look*, and even though you were joking, I don't appreciate being told not to. As far as I recall from Math Analysis, which I studied two months ago, you can't sort complex numbers. It makes no sense. The reason being (reading from my book), it's not possible to define an order that preserves the properties of arithmetical operations on complex numbers. So you can't order them, and you can't compare them. -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Adriano Varoli Piazza ha scritto: As far as I recall from Math Analysis, which I studied two months ago, you can't sort complex numbers. It makes no sense. The reason being (reading from my book), it's not possible to define an order that preserves the properties of arithmetical operations on complex numbers. So you can't order them, and you can't compare them. Sorry, that should have been you can't sort them, and you can't compare them with greater than, lesser than, etc. Of course, using == will work. But tell me, how do you think sort works if not with , , ==, = and = ? I'm really interested. -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano wrote: On Sat, 30 Jul 2005 08:13:26 -0400, Peter Hansen wrote: Beginners should not be comparing lambdas. Neither should you. ;-) Actually, yes I should, because I'm trying to make sense of the mess that is Python's handling of comparisons. At least two difference senses of comparisons is jammed into one, leading to such such warts as these: L = [] L.sort() # we can sort lists L.append(1+1j) L.sort() # even if they include a complex number L.append(1) L.sort() # but not any more Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = Um, I didn't ask to compare complex numbers using comparison operators. I asked to sort a list. And please don't tell me that that sorting is implemented with comparison operators. That just means that the implementation is confusing numeric ordering with sort order. Sorting is implemented with comparison operators. How should it be otherwise? Would you prefer a __sort__ method to specify sort order? And how would you sort a list of complex numbers? Then there is this: 1 0 True Okay. 1+0j == 1 True Okay. 1+0j == 1 0 True (1+0j == 1) yields True, which is comparable to 0. 1+0j 0 Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = But complex numbers are not greater or littler than others. You can't order them, not on a one-dimensional scale. I applaud that Python has got rich comparisons for those who need them. But by confusing the question which comes first in a sorted list? with which is larger?, you get all sorts of warts like being unable to sort lists with some objects, while being able to make meaningless comparisons like ''.join = [].append. That's a wart indeed, and intended to be removed for 3.0, if I'm informed correctly. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Selection, picking with PyOpenGL?
Erik Max Francis wrote: I was interesting in adding selection and hit testing to ZOE, and was looking at the PyOpenGL wrappers' handling of selection and picking. I see glSelectBuffer to specify the size of the buffer, and glRenderMode properly returns the number of hits when put back into GL_RENDER mode, but I don't see any way within PyOpenGL itself to access the select buffer to actually process the hits. Is there any way to do this without using OpenGLContext? (If not, does this make sense, given that OpenGLContext is supposed to be an additional helper library for a gentle introduction to OpenGL?) I think you're missing what's returned from the glRenderMode code (which is non-standard OpenGL, to avoid the need for Python code using and decoding structured pointers), from OpenGLContext: nameStack = list(glRenderMode(GL_RENDER)) that is, you get a stack of name records (i.e. your glSelectBuffer with (near,far,names) records) back from the glRenderMode call, *not* just a count of the records produced. In general, you shouldn't *need* OpenGLContext to do anything, as all of its OpenGL code is written directly in Python to PyOpenGL's API (that was its original purpose in life, to test those APIs). It is, however, intended to provide a source for sample code showing how to accomplish effects when using PyOpenGL, so from renderpass.py: event.setObjectPaths([ nodepath.NodePath(filter(None,[ self.selectable.get(name) for name in names ])) for (near,far,names) in nameStack ]) shows you how to deal with the glSelectBuffer result, namely that it's a near value, a far value, and a set of integer names (the name stack) for each record in the set. OpenGLContext is here creating a node-path of all selectable objects from the scenegraph root to the final selected object using the nameStack and a registered set of name:node values (self.selectable). It will use those to populate the event objects that show up in the OpenGLContext mouse-event-handling APIs. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com -- http://mail.python.org/mailman/listinfo/python-list
Dr. Dobb's Python-URL! - weekly Python news and links (Jul 29)
QOTW: Guido has marked the trail; don't ignore the signs unless you really know where you're going. - Raymond Hettinger 'Proverbs 28:14 JPS Happy is the man that feareth alway; but he that hardeneth his heart shall fall into evil. Obviously an exhortation to not ignore raised exceptions with except: pass.' - Robert Kern Jason Orendorff's path module is a popular alternative to the build in os.path and shutil modules. Michael Hoffman and Reinhold Birkenfeld are working on a PEP suggesting that it be included in the standard library: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/1f5bcb67c4c73f15 http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/df1b647a0f103640 Java has nearly as many web frameworks as Python, but you can run any of them on any of the Java web application servers because they are all built on the Java Servlet specification. PEP 333, the Python Web Server Gateway Interface, aims to bring something similar to the world of Python: http://www.python.org/peps/pep-0333.html A short but sweet day-of-the-month suffix generator from John Machin: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/904fa627890c85dd Thanos Tsouanas wants access to an object's namespace dictionary: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/d5cc509d138e1701 David Isaac wants to avoid map(), but he wants a zip() function that runs to the length of the longest sequence. It's suggested that zip() should be able to do this, but Raymond Hettinger channels Guido and thinks that this would be a bad idea: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/265675b50fee8ec1 Tiny.be release four open source enterprise applications: http://lwn.net/Articles/145209/ Who needs Ten Essential Development Practices? We've got The Zen of Python: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/c52d3c17f1ea9ec5 Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. For far, FAR more Python reading than any one mind should absorb, much of it quite interesting, several pages index much of the universe of Pybloggers. http://lowlife.jp/cgi-bin/moin.cgi/PythonProgrammersWeblog http://www.planetpython.org/ http://mechanicalcat.net/pyblagg.html comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djqas_ugroup=comp.lang.python.announce Steve Bethard, Tim Lesher, and Tony Meyer continue the marvelous tradition early borne by Andrew Kuchling, Michael Hudson and Brett Cannon of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of Python resources. http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Kurt B. Kaiser publishes a weekly report on faults and patches. http://www.google.com/groups?as_usubject=weekly%20python%20patch Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to
Re: Wheel-reinvention with Python
On 7/30/05, Torsten Bronger [EMAIL PROTECTED] wrote: I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Probably I'll use it nevertheless. PyGTK and PyQt may have their own advantages and disadvantages. However, in my opinion we don't need yet another binding so thin that C or C++ is shining through, but a modern replacement for Tkinter with its Pythonic way of thinking. I had the exact same impression when I started working with wxPython: it looked and ran great, but I held my nose when coding in it - it just was too un-Pythonic for my tastes. I then discovered Dabo (http://dabodev.com), which is a full application framework, but whose UI layer is a very Pythonic wrapper around wxPython. I've created several apps now using Dabo, even though I haven't even looked at the data connectivity aspects of it; the UI code works fine without it. The authors have done such a great job I'm surprised that it hasn't been more widely adopted. Its development is very active, and they have great support for their users. # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Hi All-- Tony Meyer wrote: (Those who are offended by sweeping generalisations should ignore this next bit) [...generalisation bit snipped...] This is not only bullshit, it's elitist bullshit. Windows users are more clueless than users of posix systems. Pfui. Prove it or withdraw it. Sigh. I guess you didn't read or understand the first sentence? Yes, I read and understood it. Saying Don't read this if you don't want to be offended doesn't make an offensive statement inoffensive. This (readability without knowing the language/standard libraries) is a huge benefit of using Python. It's overrated. It must be macho to say I learned Python without reading books. No it is not. Have you used Python as pseudocode when teaching people how to program? Many people have. That's just one example. I grant that Python is much easier to learn than other programming languages; students can pick up the basics rapidly. Once the basics are mastered and mentoring is over, reliance on guess and intuition is not a substitute for documentation, or for reading the code if documentation is not available. People can subclass Path and add it if they really want it. They can use Jason's original module. My position is that the PEP without this use of __div__ is (a) better as a standard module, and (b) improves the chance of the PEP being accepted. I disagree. Using __div__ to mean path concatenation is no worse than using __add__ to mean string concatenation, and it is both easy to remember (once the manual is read) and easy to type. Requiring users who want / to mean what it has always meant in the path module is neither easy nor intuitive. On the face of it, Jason would seem to agree, since he created / as a synonym for joinpath(). However, if the intention here is to create something different from Jason's original module, create something different and call it by another name than path; don't attempt to guess what Jason really meant. It is not Pythonic to guess. Metta, Ivan -- Ivan Van Laningham God N Locomotive Works http://www.andi-holmes.com/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: How can I run a program?
On 30 Jul 2005 03:33:14 -0700, Lad [EMAIL PROTECTED] wrote: Hello, I am running Python on XP and have a problem with a program if its name consists '-' for example: my-program.py When I try to run a program with such name I get the error : Traceback (most recent call last): File interactive input, line 1, in ? NameError: name 'my' is not defined Python thinks that the name of program is my.py only but the name is my-program.py What is a solution? Have you tried renaming it so it doesn't have a - in it? -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Sat, 30 Jul 2005 08:54:59 +0200, Torsten Bronger [EMAIL PROTECTED] wrote: Hallöchen! Calvin Spealman [EMAIL PROTECTED] writes: The choice is GUI toolkits is largely seperate from Python. Consider that they are just bindings to libraries that are developed completely seperate of the language. GUI is should be seperate from the language, and thus not bound to same expectations and desires as elements of the language itself. I disagree. A modern language must provide a convenient and well-embedded way to write GUI applications. This is not a sign of decadence, but a very good promotional argument. Delphi and first and foremost VB are extremely popular, and it's sad to see that Python could get a lot more of the cake if the efforts for IDEs and toolkits were somewhat streamlined. Besides, all other already good aspects of Python wouldn't suffer at all. Tkinter fits into Python very well and it is very easily (if not trivially) accessible for users of our applications. People complain about non-native look-and-feel on Windows, but sorry, I simply find it unacceptably ugly on all platforms. Don't misunderstand me: I don't like neat GUI effects just for the sake of it but Tkinter makes an outdated impression on the end-user. I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Tkinter is hardly brilliantly documented, IMO. Probably I'll use it nevertheless. PyGTK and PyQt may have their own advantages and disadvantages. However, in my opinion we don't need yet another binding so thin that C or C++ is shining through, but a modern replacement for Tkinter with its Pythonic way of thinking. How about sometihing with the same API as Tkinter (so no need to relearn), but which looks prettier? Would that fix your gripes? -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Fri, 29 Jul 2005 14:38:23 +1200, Tony Meyer [EMAIL PROTECTED] wrote: def functions_which_modifies_some_file_in_place(path): output = open(path+'.tmp', 'w') . I dont want a seperator inserted between path and the new extension. Fair enough. Forget using '+' for join, then (which I was never that keen on - TIOWTDI), but I'm still -1 on using '/' for join. I agree. It's yuck. What's wrong with simply having each path-element as an argument to a function, e.g. join(foo, bar, baz) -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Fri, 29 Jul 2005 14:48:55 +1200, Tony Meyer [EMAIL PROTECTED] wrote: Would you really choose this: p = Path() / build / a / very / very / long / path Over this: p = Path(os.path.join(build, a, very, very, long, path)) Or have the constructor accept multiple arguments. ? A saving of six characters, and the second one is a lot clearer. If there was a os.path.joinPath (or whatever name) function that returned a Path object rather than a string, then you'd get: p = joinPath(build, a, very, very, long, path) Indeed. I have a little function I've written called normalizePath(). It expands users (~ and ~someuser), does os.path.join(), then gets the absolute path (os.path.abspath()) of the result. The code is trivial: def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [string] = a path to a file or directory @param pathParts [list of string] = optional path parts @return [string] = the same path, normalized p1 = os.path.abspath(os.path.expanduser(p)) if len(pathParts)0: allPathParts = [ p1 ] allPathParts.extend(pathParts) p1 = os.path.join(*allPathParts) p2 = os.path.abspath(p1) return p2 normalisePath=normalizePath # alternate spelling join=normalizePath # it works like os.path.join, but better To be honest I don't see the point of having a Path class. That's the way Java does it, and I find path handling in Java to be a lot more of a hassle than in Python. (Actually, most things are more of a hassle in Java, but that's another story). -- Email: zen19725 at zen dot co dot uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
* Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: 1+0j == 1 0 True (1+0j == 1) yields True, which is comparable to 0. a == b c is equivalent to a == b and b c: 1 == 1+0j 0 Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = -- http://mail.python.org/mailman/listinfo/python-list
How to do this?
the codes as follow: class Base: def fun(self): print base_fun def fun2(self): print base_fun2 class Foo: def __init__(self, base): self.__base = base def fun3(self): print foo_fun3 b = Base() foo = Foo(b) my aim is:when foo.fun3() be called,it run as usually, but when foo.fun() or foo.fun2() be called, as Foo hasn't attribute fun() and fun2(), foo will call self.__base.fun() or self.__base.fun2(). when a attr can't be find in foo, it's will try to search 'self.__base. I think this maybe need to use __getattr__ and __setattr__ ,but I cant do it successfully. can someone help me? -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Peter Decker [EMAIL PROTECTED] writes: On 7/30/05, Torsten Bronger [EMAIL PROTECTED] wrote: I've been having a closer look at wxPython which is not Pythonic at all and bad documented. Probably I'll use it nevertheless. PyGTK and PyQt may have their own advantages and disadvantages. However, in my opinion we don't need yet another binding so thin that C or C++ is shining through, but a modern replacement for Tkinter with its Pythonic way of thinking. I had the exact same impression when I started working with wxPython: [...] I then discovered Dabo (http://dabodev.com), which is a full application framework, but whose UI layer is a very Pythonic wrapper around wxPython. I've created several apps now using Dabo, even though I haven't even looked at the data connectivity aspects of it; the UI code works fine without it. I'm aware of it (and there is Wax and maybe a third one). Actually it illustrates my point quite well: These projects are small and instable (Dabo has a developer basis of very few people, Wax has only one); they are even worse documented; they add another layer which slows down and requires the end-user to install another package; they force you to test even more GUI approaches. == They contribute heavily to Dark Cowherd's observation that it is shambles. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! [EMAIL PROTECTED] (phil hunt) writes: [...] How about sometihing with the same API as Tkinter (so no need to relearn), but which looks prettier? Would that fix your gripes? I haven't learned Tkinter. Well, I programed toy applications with different toolkits (including Tkinter) and tried to make a rather competent decision, that's all. So for me, it needn't be like Tkinter. The three most important attributes for me are Pythonic, modern (both nice-looking and comprehensive), and non-niche. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
showing help(M) when running module M standalone
hello, I have a small module which only contains some utility functions. when running this standalone I would like to show the module docs and each function docs, as if doing import M help(M) I came up with the following but I reckon there is a much simpler way? if __name__ == '__main__': print __doc__ print \nFUNCTIONS:\n for x in __all__: print x exec print + x + .__doc__ Works but does not seem right using exec for such a task. any hint would be great! thanks chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On 7/30/05, Torsten Bronger [EMAIL PROTECTED] wrote: I'm aware of it (and there is Wax and maybe a third one). Actually it illustrates my point quite well: These projects are small and instable (Dabo has a developer basis of very few people, Wax has only one); they are even worse documented; they add another layer which slows down and requires the end-user to install another package; they force you to test even more GUI approaches. Well, wxPython itself is largely the work of a single person, but I doubt that many consider that a reason to avoid it. As far as your comment about 'slowing down' the app, I've found that Dabo and pure-wxPython apps run indistinguishably. Perhaps there are some microseconds of extra processing, but I sure haven't noticed it. And I don't think that the comment about installing another package is fair; *anything* outside of the standard distribution requires that, and Dabo is no more difficult than copying to site-packages. I do agree about the documentation aspect of Dabo, though. The authors have put together some basic stuff to get you started, but have chosen to focus their time on continued development for the time being. But having said that, I found that Dabo uses a very consistent syntax, and was no more difficult to pick up than Python itself. With wxPython, I constantly had to refer to the docs, as every class did things slightly differently. For example, many controls have some text associated with them. Depending on the control, you need to call SetText(), SetLabel(), SetBitmapLabel(), SetTitle(), etc. Dabo wrapped all of these controls so that the identifying text for each is controlled by a single property: Caption. In any Dabo control, executing ctl.Caption=Something will change its associated text. This sort of consistency removes the need to constantly refer to documentation in order to write your code. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
string methods
I am an abject newbie, so mock away (actually no-one ever does that in this group..) Anyway, I want to replace one character in a string, based in that character's position in the string. For example if I wanted to replace the 4th character in 'foobar' (the b)with the contents of another string, newchar, what would be the easiest way? I know this touches on immutability etc, but I can't find string methods to return the first 3 characters, and then the last 2 characters, which I could concatenate with newchar to make a new string. I know the string methods are there, but can't find it in any docs, and just want to check the syntax, unless there is an easier way. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
On Sat, 30 Jul 2005 14:10:52 +0200, Reinhold Birkenfeld wrote: Above all, nobody can tell me that there's any programmer who doesn't instantly recognize '/' as a directory separator. Is classic Macintosh OS still supported on Python? Because Mac programmers who haven't made the jump to OS X will probably instantly recognise ':' as the directory separator, not '/'. Acorn RISC OS developers may also instantly recognise '.' as the directory separator. And presumably mathematicians and numeric programmers who do very little file input/output will probably instantly recognise '/' as the division operator. And I have no idea what directory separators are in use under file systems that don't use ASCII or any extension to ASCII, eg the OS which has been described as the most common operating system in the world, the Japanese Real-time Operating System Nucleus, TRON. (Chances are you have at least half a dozen devices in your home with embedded TRON.) Still, your (modified) point that most Western programmers will quickly recognise '/' as a directory separator is surely true. Even given that, I'm not convinced that it is a good idea to turn '/' into a join-path operator. I don't have any good reasons for objecting either, just a funny little feeling in the back of my head that says that no good can ever come from allowing Path(C:\Windows)/cmd.com. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to do this?
On Fri, 29 Jul 2005 22:34:23 +0800, flyaflya [EMAIL PROTECTED] wrote: the codes as follow: class Base: def fun(self): print base_fun def fun2(self): print base_fun2 class Foo: def __init__(self, base): self.__base = base def fun3(self): print foo_fun3 b = Base() foo = Foo(b) my aim is:when foo.fun3() be called,it run as usually, but when foo.fun() or foo.fun2() be called, as Foo hasn't attribute fun() and fun2(), foo will call self.__base.fun() or self.__base.fun2(). when a attr can't be find in foo, it's will try to search 'self.__base. I think this maybe need to use __getattr__ and __setattr__ ,but I cant do it successfully. can someone help me? class Foo(Base): def fun3(self): print fun_foo3 HTH, Dan -- Dan Sommers http://www.tombstonezero.net/dan/ -- http://mail.python.org/mailman/listinfo/python-list
Re: showing help(M) when running module M standalone
On Sat, 30 Jul 2005 17:04:50 +0200, Chris [EMAIL PROTECTED] wrote: hello, I have a small module which only contains some utility functions. when running this standalone I would like to show the module docs and each function docs, as if doing import M help(M) I came up with the following but I reckon there is a much simpler way? if __name__ == '__main__': print __doc__ print \nFUNCTIONS:\n for x in __all__: print x exec print + x + .__doc__ Works but does not seem right using exec for such a task. So don't use exec. any hint would be great! for x in __all__: print x.__doc__ HTH, Dan -- Dan Sommers http://www.tombstonezero.net/dan/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Peter Decker [EMAIL PROTECTED] writes: On 7/30/05, Torsten Bronger [EMAIL PROTECTED] wrote: I'm aware of it (and there is Wax and maybe a third one). Actually it illustrates my point quite well: These projects are small and instable (Dabo has a developer basis of very few people, Wax has only one); they are even worse documented; they add another layer which slows down and requires the end-user to install another package; they force you to test even more GUI approaches. Well, wxPython itself is largely the work of a single person, but I doubt that many consider that a reason to avoid it. But the developer and contributor base is much larger, so the project has reached the critical mass. As far as your comment about 'slowing down' the app, I've found that Dabo and pure-wxPython apps run indistinguishably. Perhaps there are some microseconds of extra processing, but I sure haven't noticed it. And I don't think that the comment about installing another package is fair; *anything* outside of the standard distribution requires that, and Dabo is no more difficult than copying to site-packages. I didn't want to say that Dabo is bad. I just wanted to point out that its presence (and the presence of comparable projects) doesn't ease the IMO unfortunate situation with GUI toolkits for Python. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP on path module for standard library
On Sat, 30 Jul 2005 14:43:27 +0200, Reinhold Birkenfeld wrote: Less important but non-controversial: - Path.tempfile(), Path.tempdir(): Create a temporary file using tempfile.mkstemp, tempfile.mkdtemp - Path.tempfileobject(): Create a temporary file object using tempfile.TemporaryFile. (Static method.) Don't know whether these belong here. They are all not acting upon the path, but create the file/dir at another location. Agreed that they do not belong. - .delete_dammit() recursively deletes it, whatever it is, without you having to do the if file/if directory dance. I suppose it would need a politically correct name. which you really have to do every time you delete. *grin* Any naming suggestions? force_delete() -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: showing help(M) when running module M standalone
Chris wrote: hello, I have a small module which only contains some utility functions. when running this standalone I would like to show the module docs and each function docs, as if doing import M help(M) I came up with the following but I reckon there is a much simpler way? if __name__ == '__main__': print __doc__ print \nFUNCTIONS:\n for x in __all__: print x exec print + x + .__doc__ Works but does not seem right using exec for such a task. One way would be to use the locals() [1] to get rid of the exec: if __name__ == '__main__': print __doc__ print \nFUNCTIONS:\n for x in __all__: print x print locals()[x].__doc__ However, if you just want to call help, calling it on '__main__' seems to work: if __name__ == '__main__': help(__name__) [1] http://docs.python.org/lib/built-in-funcs.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Ten Essential Development Practices
Dark Cowherd wrote: -Quote - Phillip J. Eby from dirtsimple.org Python as a community is plagued by massive amounts of wheel-reinvention. The infamous web framework proliferation problem is just the most egregious example. Why is Python blessed with so much reinvention? Because it's often cheaper to rewrite than to reuse. Python code is easy to write, but hard to depend on. You pretty much have to: 1. limit yourself to platforms with a suitable packaging system, 2. bundle all your dependencies into your distribution, or 3. make your users do all the work themselves Ouch. No wonder rewriting looks easier. The only way to stop this trend is to make it easier to reuse than to rewrite, which has been my mission with setuptools and EasyInstall -UnQuote I think that Phillip misrepresents the problem a little bit, because it is not true that there are too few reusable components that need just another hero programmer like himself or anyone of us to implement. What is missing is just a simple distinction that does not exist in an open source community guided by hackers at least not on a certain level ( the PEP process would be a counter-example ) but is well known in contemporary industry practice: some people are just writing specs. SUN with Java for example employs people that model systems and write API specs that are finally licenced and implemented by 3rd-party vendors. J2EE or the JavaCard API are prominent examples. This is very different from the just-for-fun or heroic-hacker attitude due to spare-time programmers who create a bit of code they are interested in and leaving the rest aside. It's not all just marketing blabla that makes Javas success. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
On Sat, 30 Jul 2005 13:22:47 +, Adriano Varoli Piazza wrote: As far as I recall from Math Analysis, which I studied two months ago, you can't sort complex numbers. It makes no sense. The reason being (reading from my book), it's not possible to define an order that preserves the properties of arithmetical operations on complex numbers. So you can't order them, and you can't compare them. You are confusing mathematical ordering with sorting a list. Here, I will sort some mixed complex and real numbers for you. If you look at them closely, you will even be able to work out the algorithm I used to sort them. 1 1+0j 1+7j 2 2+3j 3+3j 3-3j 3+4j 4 4+2j It was easy. I never once asked myself whether some complex number was greater or less than another, I just asked which one comes first in a lexicographic sort? The two questions are NOT the same, and it is an ugliness in an otherwise beautiful language that Python treats them as the same. Mathematically, 1 == 1.0 == 1+0j but in the dictionary 1 should sort before 1.0 which sorts before 1.0+0.0j. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
On Sat, 30 Jul 2005 13:30:20 +, Adriano Varoli Piazza wrote: But tell me, how do you think sort works if not with , , ==, = and = ? I'm really interested. How do you sort words in a dictionary? Why does five come before four when the number five is larger than the number four? Why does hundred come before ten? What does it mean to say that elephant is less than mouse? When you can answer those questions, you will be enlightened. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano ha scritto: It was easy. I never once asked myself whether some complex number was greater or less than another, I just asked which one comes first in a lexicographic sort? The two questions are NOT the same, and it is an ugliness in an otherwise beautiful language that Python treats them as the same. Mathematically, 1 == 1.0 == 1+0j but in the dictionary 1 should sort before 1.0 which sorts before 1.0+0.0j. Because, of course, when I sort numbers the first thing I think of is looking at the ascii table... Here I was, thinking maths was useful. Sorting numbers lexicographically might make sense to you, but it's totally unintuitive to me. For example, why or how would I guess that 3-3j is bigger (or smaller) than 3+3j? You'll still want to sort complex numbers lexicographically. It'll still have no meaning whatsoever, so you might as well leave the list unsorted. You might think you sorted something. 100? 200? years of maths say you didn't. -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano ha scritto: On Sat, 30 Jul 2005 13:30:20 +, Adriano Varoli Piazza wrote: But tell me, how do you think sort works if not with , , ==, = and = ? I'm really interested. How do you sort words in a dictionary? Why does five come before four when the number five is larger than the number four? Why does hundred come before ten? What does it mean to say that elephant is less than mouse? When you can answer those questions, you will be enlightened. 'a' 'A' True 'a' '-' True 'a' 'h' False Whii. I just discovered the Ascii table! wooot! (Your EBCDIC mileage might vary) What does it have to do with complex numbers, pray tell? and how do you think any string sort works if not by comparing the numerical value of each character? Once more: 'five' 'four' True 'five' 'Four' False 'Five' 'Four' True Ooohhh! magic of ascii! -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On 7/30/05, Torsten Bronger [EMAIL PROTECTED] wrote: Well, wxPython itself is largely the work of a single person, but I doubt that many consider that a reason to avoid it. But the developer and contributor base is much larger, so the project has reached the critical mass. So until it reached that critical mass, you would have argued against supporting it or using it? That seems to be what you're doing here. Dabo is about a year and a half along; IMO, its progress in such a short time frame is a very positive thing, not at all a negative. As far as your comment about 'slowing down' the app, I've found that Dabo and pure-wxPython apps run indistinguishably. Perhaps there are some microseconds of extra processing, but I sure haven't noticed it. And I don't think that the comment about installing another package is fair; *anything* outside of the standard distribution requires that, and Dabo is no more difficult than copying to site-packages. I didn't want to say that Dabo is bad. I just wanted to point out that its presence (and the presence of comparable projects) doesn't ease the IMO unfortunate situation with GUI toolkits for Python. Perhaps, but I see it differently, since Dabo doesn't attempt to add a new toolkit. I greatly preferred the look of wxPython over TkInter and PyGtk, since I do a lot of cross-platform work. But while I liked the results, I didn't like coding in wxPython. Dabo is giving me the best of both worlds: a Pythonic language, and great-looking GUI apps. So I feel that it is improving the situation with GUI toolkits for Python in that it is allowing me to use the best toolkit without having to write un-Pythonic code. It would be great if the wxPython folks would adopt Dabo, and eventually integrate it so that there is but a single, Pythonic way of working with wxPython, but it seems that they have their hands full just wrapping the C++ code of wxWidgets. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
On Sat, 30 Jul 2005 15:32:45 +0200, Reinhold Birkenfeld wrote: Um, I didn't ask to compare complex numbers using comparison operators. I asked to sort a list. And please don't tell me that that sorting is implemented with comparison operators. That just means that the implementation is confusing numeric ordering with sort order. Sorting is implemented with comparison operators. How should it be otherwise? That's a good question, and that's why I'm exploring different comparisons in Python, trying to understand what Python already does, and the pros and cons thereof, before I suggest anything new. Would you prefer a __sort__ method to specify sort order? Well, there are an infinite number of sort orders. Most of them are pretty much useless, but even if we limit ourselves to common, useful sort orders, there are still a good half dozen or more. So at this time, I'd rather not be pinned down to some half-baked solution before I have even understood the problem. And how would you sort a list of complex numbers? Answered in another post. Then there is this: 1 0 True Okay. 1+0j == 1 True Okay. 1+0j == 1 0 True (1+0j == 1) yields True, which is comparable to 0. No, 1+0j == 1 0 is calculated as 1+0j == 1 and 1 0. 1+0j 0 Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = But complex numbers are not greater or littler than others. You can't order them, not on a one-dimensional scale. Of course you can order them. You are confusing order with magnitude. The two are not identical, although they are similar enough in some contexts as to cause confusion. I admit that I haven't fully grasped all the subtleties of the general ordering problem. Fortunately, my needs are much less lofty. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: string methods
anthonyberet wrote: I know this touches on immutability etc, but I can't find string methods to return the first 3 characters, and then the last 2 characters, which I could concatenate with newchar to make a new string. As tiissa said, you want slicing: py s = foobar py s[:3] 'foo' py s[:3] + B + s[4:] 'fooBar' py -- Brian Beck Adventurer of the First Order -- http://mail.python.org/mailman/listinfo/python-list
2-player game, client and server at localhost
hi, everyone. I'm writing a 2-players game that should support network mode. I'm now testing it on 1 PC since I don't have 2. I directly use sockets, and both client and server do computations, the only data transfered is user mouse/kbd input. It works synchronously, but somehow, when I play in client window, both client and server have 17 fps, while when playing in server window, server has 44 fps while client has 5, and due to forced synchronization, they both run very slowly (I wonder how come server says it has 44fps?). Does anybody have an idea how can this be? Not that users will test 2 game intances communicating via localhost, but I need to make it work properly. -- Best Regards, Michael Rybak mailto:[EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Python language ver 2.4 , development platform 0.4
The Python language is at ver 2.4 and a thing of beauty. As a development environment IMHO it is probably 0.4 I really like what I read when I say import this in Python. But as a development environment - TOOWTDI and batteries included are just not true. I would like to place my position in context. I work in a bread and butter development shop. There are one or two competent long term programmers. The others are freshers or average programmers who join and leave after a year or two etc. But we develop business products and projects for small companies. The natural development environment for companies like us are products like VB or Delphi. We wanted to move towards Linux instead of being purely Windows - centric. So I evaluated Python. This is the impressions I got. It is a hyper-productive environment for the following scenarios. Utilities - fetchmail being a prime example Really futuristic programming paradigms - an example being http://kamaelia.sourceforge.net/Home Large in house programming projects - Just a feeling I have, but I felt that most of the frameworks were scratchin the itch in such scenarios and they got released as open source projects. For a bread and butter programming shop Python looks like Shambles. Until TOOWTDI for GUI, 3 tier applications, Web applications are in place I would hesitate to jump in for day to day use. Calvin had pointed out WSGI and the anygui package. But long way to go. I have looked at DABO, it is impressive. So there are signs that things are going in the right direction but still I feel it is somewhere around 0.4 Small projects, utilities which I am going to code myself I will continue to use Python because I love it. I hope to learn Python well enough to be able to contribute to some projects to achieve this. But I still see that as six to nine months away. -- DarkCowherd -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
On Saturday 30 July 2005 12:28, Peter Decker wrote: It would be great if the wxPython folks would adopt Dabo, and eventually integrate it so that there is but a single, Pythonic way of working with wxPython, but it seems that they have their hands full just wrapping the C++ code of wxWidgets. Thanks for the vote of encouragement! Our goal isn't to muddy the waters; it is simply to create a consistent API for coding. There is already a great GUI toolkit for Python; we're just trying to make it easier to code. -- Ed Leafe -- http://leafe.com -- http://dabodev.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano ha scritto: On Sat, 30 Jul 2005 13:22:47 +, Adriano Varoli Piazza wrote: As far as I recall from Math Analysis, which I studied two months ago, you can't sort complex numbers. It makes no sense. The reason being (reading from my book), it's not possible to define an order that preserves the properties of arithmetical operations on complex numbers. So you can't order them, and you can't compare them. You are confusing mathematical ordering with sorting a list. Here, I will sort some mixed complex and real numbers for you. If you look at them closely, you will even be able to work out the algorithm I used to sort them. 1 1+0j 1+7j 2 2+3j 3+3j 3-3j 3+4j 4 4+2j It was easy. I never once asked myself whether some complex number was greater or less than another, I just asked which one comes first in a lexicographic sort? The two questions are NOT the same, and it is an ugliness in an otherwise beautiful language that Python treats them as the same. Mathematically, 1 == 1.0 == 1+0j but in the dictionary 1 should sort before 1.0 which sorts before 1.0+0.0j. If you want to treat numbers as strings, why not convert them before sorting them? Python is just saying He's trying to sort complex numbers. No can do. You're trying to make it guess that you want them sorted as strings, not as numbers. I don't see how Python treats things the same way. I see that real numbers and strings can be compared and sorted (asciibetically? don't remember). It has nothing to do with complex numbers. The abstraction or overloading or what it is fails, because they don't have an order as numbers, and Py is not intelligent enough to know that you want them asciibetized -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
Re: showing help(M) when running module M standalone
Chris [EMAIL PROTECTED] writes: hello, I have a small module which only contains some utility functions. when running this standalone I would like to show the module docs and each function docs, as if doing import M help(M) I came up with the following but I reckon there is a much simpler way? if __name__ == '__main__': print __doc__ print \nFUNCTIONS:\n for x in __all__: print x exec print + x + .__doc__ Works but does not seem right using exec for such a task. any hint would be great! if __name__ == __main__: help(__main__) The only downside is that the module name is printed as '__main__'. Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Some indications: for i in range(5): ... x = lambda x:x ... y = lambda y:y ... print x,y,xy,id(x)id(y) ... function lambda at 0x00EE83F0 function lambda at 0x00EE8FB0 True True function lambda at 0x00EE8AB0 function lambda at 0x00EE83F0 False False function lambda at 0x00EE8FB0 function lambda at 0x00EE8AB0 False False function lambda at 0x00EE83F0 function lambda at 0x00EE8FB0 True True function lambda at 0x00EE8AB0 function lambda at 0x00EE83F0 False False Regards, Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano wrote: It was easy. I never once asked myself whether some complex number was greater or less than another, I just asked which one comes first in a lexicographic sort? The two questions are NOT the same, and it is an ugliness in an otherwise beautiful language that Python treats them as the same. The point is Python does not. The order you proposed above can be implemented using a comparison function you can pass to the sort function of lists [1] or the sorted builtin [2]. If the elements can be compared, Python offers you not to pass the cmp function to sort if you want to use this default order. Python allows you to use the default ordering to sort a list but does not treat both questions in the same manner. However, the fact is ordering a list using the default '' happens pretty often. In the case of complex numbers, no mathematically sound comparison function exists and Python does not impose some default function that would be called a wart. [1] http://docs.python.org/lib/typesseq-mutable.html [2] http://docs.python.org/lib/built-in-funcs.html -- http://mail.python.org/mailman/listinfo/python-list
Re: How can I run a program?
did you try to put the filename in quotes? On 30 Jul 2005 03:33:14 -0700, Lad [EMAIL PROTECTED] wrote: Hello, I am running Python on XP and have a problem with a program if its name consists '-' for example: my-program.py When I try to run a program with such name I get the error : Traceback (most recent call last): File interactive input, line 1, in ? NameError: name 'my' is not defined Python thinks that the name of program is my.py only but the name is my-program.py What is a solution? Thank you Lad. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Ivan Van Laningham wrote: I like / as a shortcut to joinwith(). I like it a lot. I like it so much I'll give you a +2. +1 here. Extremely practical. -- Brian Beck Adventurer of the First Order -- http://mail.python.org/mailman/listinfo/python-list
Re: Path inherits from basestring again
Reinhold Birkenfeld wrote: It's much the same as with @ decorators. Those who have used them much don't object to the syntax any more. I do and I still think they are ugly. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
phil hunt wrote: On Fri, 29 Jul 2005 14:38:23 +1200, Tony Meyer [EMAIL PROTECTED] wrote: def functions_which_modifies_some_file_in_place(path): output = open(path+'.tmp', 'w') . I dont want a seperator inserted between path and the new extension. Fair enough. Forget using '+' for join, then (which I was never that keen on - TIOWTDI), but I'm still -1 on using '/' for join. I agree. It's yuck. So don't use it. What's wrong with simply having each path-element as an argument to a function, e.g. join(foo, bar, baz) Nothing's wrong, and you can do it this way too. Path(foo, bar, baz) or Path(foo).joinwith(bar, baz) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
phil hunt wrote: def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [string] = a path to a file or directory @param pathParts [list of string] = optional path parts @return [string] = the same path, normalized p1 = os.path.abspath(os.path.expanduser(p)) if len(pathParts)0: allPathParts = [ p1 ] allPathParts.extend(pathParts) p1 = os.path.join(*allPathParts) p2 = os.path.abspath(p1) return p2 normalisePath=normalizePath # alternate spelling join=normalizePath # it works like os.path.join, but better To be honest I don't see the point of having a Path class. That's the way Java does it, and I find path handling in Java to be a lot more of a hassle than in Python. (Actually, most things are more of a hassle in Java, but that's another story). You see, with the Path class the above function could be written as def normalizePath(p, *pathParts): Normalize a file path, by expanding the user name and getting the absolute path.. @param p [Path] = a path to a file or directory @param pathParts [list of string/Path] = optional path parts @return [Path] = the same path, normalized tp = p.expanduser().abspath() return tp.joinwith(*pathParts).abspath() That's clearly an improvement, isn't it? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Steven D'Aprano wrote: On Sat, 30 Jul 2005 14:10:52 +0200, Reinhold Birkenfeld wrote: Above all, nobody can tell me that there's any programmer who doesn't instantly recognize '/' as a directory separator. Is classic Macintosh OS still supported on Python? Because Mac programmers who haven't made the jump to OS X will probably instantly recognise ':' as the directory separator, not '/'. Acorn RISC OS developers may also instantly recognise '.' as the directory separator. I didn't say that '/' is the native directory separator on every platform. But other than ':' or '.', '/' is used as widely as URLs are, so it _will_ be recognizable as a directory separator. And presumably mathematicians and numeric programmers who do very little file input/output will probably instantly recognise '/' as the division operator. Yes, they will. But they presumably will read the documentation of the path module when using it (and, given that most operands will be strings, they won't suspect division going on). And I have no idea what directory separators are in use under file systems that don't use ASCII or any extension to ASCII, eg the OS which has been described as the most common operating system in the world, the Japanese Real-time Operating System Nucleus, TRON. (Chances are you have at least half a dozen devices in your home with embedded TRON.) Well, as long as Python doesn't run under TRON, that's not much of a point here. Still, your (modified) point that most Western programmers will quickly recognise '/' as a directory separator is surely true. Even given that, I'm not convinced that it is a good idea to turn '/' into a join-path operator. I don't have any good reasons for objecting either, just a funny little feeling in the back of my head that says that no good can ever come from allowing Path(C:\Windows)/cmd.com. Well, if you want to do such things, you surely don't need a path join anyway. Just write C:\\Windows\\ + something in this case. The path join is there for platform independence, and you will most certainly not write a Windows path directly into the source if you want to be XP compatible. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Georg Neis wrote: * Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: 1+0j == 1 0 True (1+0j == 1) yields True, which is comparable to 0. a == b c is equivalent to a == b and b c: Right. Stupid me :) Doesn't do much to the point, though. 1 == 1+0j 0 Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano wrote: On Sat, 30 Jul 2005 15:32:45 +0200, Reinhold Birkenfeld wrote: Um, I didn't ask to compare complex numbers using comparison operators. I asked to sort a list. And please don't tell me that that sorting is implemented with comparison operators. That just means that the implementation is confusing numeric ordering with sort order. Sorting is implemented with comparison operators. How should it be otherwise? That's a good question, and that's why I'm exploring different comparisons in Python, trying to understand what Python already does, and the pros and cons thereof, before I suggest anything new. Would you prefer a __sort__ method to specify sort order? Well, there are an infinite number of sort orders. Most of them are pretty much useless, but even if we limit ourselves to common, useful sort orders, there are still a good half dozen or more. That's why the sort method does have certain keyword arguments with which you can customize sorting to your liking. But unless the standard sort without arguments should be disallowed, it has to resort to comparison. So at this time, I'd rather not be pinned down to some half-baked solution before I have even understood the problem. That's wise. But complex numbers are not greater or littler than others. You can't order them, not on a one-dimensional scale. Of course you can order them. You are confusing order with magnitude. The two are not identical, although they are similar enough in some contexts as to cause confusion. Well, you can order everything according to some specs, but you can't find a default sort order for everything. That's where custom comparison functions can help. Correct me if I'm wrong, but is there a default order for complex number? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Path inherits from basestring again
Michael Hoffman wrote: Reinhold Birkenfeld wrote: It's much the same as with @ decorators. Those who have used them much don't object to the syntax any more. I do and I still think they are ugly. Shouldn't have generalized that. Add most of where you like. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Python language ver 2.4 , development platform 0.4
Dark Cowherd wrote: The Python language is at ver 2.4 and a thing of beauty. As a development environment IMHO it is probably 0.4 Have you considered looking at any of the commercial IDEs? Personally I *like* command line based systems, but I do know many people who swear by GUI based IDEs. If you have, what did want to see but didn't see ? (System usability from my perspective starts with developers, since whilst beauty is skin deep, ugly goes to the bone) Most of these IDEs tend to integrate with one of the more common GUI toolkits as well, which /may/ be more TOOWTDI from your perspective. As for batteries included, I suspect it depends on what you expect as batteries :-) Small projects, utilities which I am going to code myself I will continue to use Python because I love it. Nice to hear. I hope to learn Python well enough to be able to contribute to some projects to achieve this. But I still see that as six to nine months away. I'm sure such contributions would be welcome - especially if you're scratching an itch to help resolve the things you currently suggest as deficiencies :-) Regards, Michael. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP on path module for standard library
Reinhold Birkenfeld wrote: Mike Orr wrote: - I saw in a thread that .name and .parent were removed. I use them very frequently, along with .ext and .namebase. I don't want to call methods for these. They are now named .basename and .directory. Reinhold, is .parent now .directory? Does that still make sense when the Path contains a directory and not a file name? It seems to me more general to have .parent in there where it makes sense for both cases. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Hallöchen! Peter Decker [EMAIL PROTECTED] writes: On 7/30/05, Torsten Bronger [EMAIL PROTECTED] wrote: [...] I didn't want to say that Dabo is bad. I just wanted to point out that its presence (and the presence of comparable projects) doesn't ease the IMO unfortunate situation with GUI toolkits for Python. Perhaps, but I see it differently, since Dabo doesn't attempt to add a new toolkit. Well, effectively, it does so because from the human point of view, the programming interface is what you have to deal with. [...] Dabo is giving me the best of both worlds: a Pythonic language, and great-looking GUI apps. So I feel that it is improving the situation with GUI toolkits for Python in that it is allowing me to use the best toolkit without having to write un-Pythonic code. You found a solution for you, which is a good thing. I don't want to rule out to use Dabo myself. But in my institute I'd like to present Python as a viable alternative to Delphi. In order to convince people who are used to a homogeneous rock-solid system, you must present something equivalent. Of course an open-source project can never be as homogeneous, but I can't make the whole team switch to a niche project, ignoring all other GUI alternatives about which you can even buy books in German! They'll think strange, that Python (or maybe strange that Torsten ;). It would be great if the wxPython folks would adopt Dabo, and eventually integrate it so that there is but a single, Pythonic way of working with wxPython, Yes indeed. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP on path module for standard library
Reinhold Birkenfeld wrote: Mike Orr wrote: - Who needs .open()? open(myPath) is fine. But it can stay for backward compatibility. Right. I think it's nice for people who like a more OO approach. There's one very good reason to use .open() on a Path object, and in fact it's a (for me) strong justification for the existence of Path in the standard library (and, even more, for porting everything else in the standard library to use Path). A scattered assortment of module-level global function names, and builtins such as open(), make it extraordinarily difficult to do effective and efficient automated testing with mock objects. Although one can fairly easily shadow the definition of open in any given module under test, if the code under test instead calls another standard library routine which internally uses open(), it becomes necessary to replace the builtin definition of open() and affect all code throughout the program. Object-oriented solutions like Path make it near trivial to substitute a mock or other specialized object which (duck typing) acts like a Path except perhaps for actually writing the file to disk, or whatever other difference you like. I haven't gotten around to doing a mock Path object yet, though given the work that's gone into my existing mock FileSystem object which lets you replace open() and test code in a fully controlled and safe environment, it shouldn't be hard to do. So, for the PEP, another justification for Path is that its use can encourage better use of automated testing techniques and thereby improve the quality of Python software, including in the standard library. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP on path module for standard library
Peter Hansen wrote: Reinhold Birkenfeld wrote: Mike Orr wrote: - I saw in a thread that .name and .parent were removed. I use them very frequently, along with .ext and .namebase. I don't want to call methods for these. They are now named .basename and .directory. Reinhold, is .parent now .directory? Does that still make sense when the Path contains a directory and not a file name? It seems to me more general to have .parent in there where it makes sense for both cases. Hm. It was suggested on python-dev and among my first modifications. I didn't see objections till now, but as you're saying, parent is probably better. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
On Sat, 30 Jul 2005 16:13:22 +, Adriano Varoli Piazza wrote: Steven D'Aprano ha scritto: It was easy. I never once asked myself whether some complex number was greater or less than another, I just asked which one comes first in a lexicographic sort? The two questions are NOT the same, and it is an ugliness in an otherwise beautiful language that Python treats them as the same. Mathematically, 1 == 1.0 == 1+0j but in the dictionary 1 should sort before 1.0 which sorts before 1.0+0.0j. Because, of course, when I sort numbers the first thing I think of is looking at the ascii table... Here I was, thinking maths was useful. Sorting numbers lexicographically might make sense to you, but it's totally unintuitive to me. For example, why or how would I guess that 3-3j is bigger (or smaller) than 3+3j? 3-3j is NOT bigger than 3+3j, nor is it smaller. You said so yourself: it's not possible to define an order that preserves the properties of arithmetical operations on complex numbers. Fortunately, when we sort a list, we don't care about preserving the properties of arithmetical operations, we just need to place each item in a known, non-arbitrary (or at least not too arbitrary) position. You'll still want to sort complex numbers lexicographically. It'll still have no meaning whatsoever, so you might as well leave the list unsorted. Your mathematical purity does you great credit. Unfortunately, it is also quite impractical. I'll give you a real-world actual case where sorting complex numbers is important: The Penguin Dictionary Of Curious and Interesting Numbers by David Wells. Some few hundreds of numbers are listed, including i. Should Wells have listed those numbers in random unsorted order just to satisfy some purists who insist that placing i in the list makes sorting the other 399 entries meaningless? You might think you sorted something. 100? 200? years of maths say you didn't. Sorting is not just numeric ordering. There are many different collation systems, not just ordering numbers by their magnitude. Think about sorting guests around a dinner table: married couples next to each other, single people across from another single person of the opposite sex, children at the end of the table, babies next to their mother, Uncle Enno as far away from Aunt May as possible. It is a complicated algorithm, but it is still sorting (people, in this case, not numbers). I appreciate your strong feelings about not doing comparisons on complex numbers, but if you actually studied the mathematics of orderings sets, you would realise how silly it was to say that a century of mathematics says that I didn't sort a list. Mathematicians are fully aware that numeric sorting is just one way of many of sorting. Do you understand the difference between partial and total ordering, or weakly and strongly ordered? When you do understand them, come back and tell me again whether you still think lexicographic sorting has no meaning whatsoever. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
The state of OO wrappers on top of wxPython (was Re: Wheel-reinvention with Python)
Ed Leafe wrote: On Saturday 30 July 2005 12:28, Peter Decker wrote: It would be great if the wxPython folks would adopt Dabo, Thanks for the vote of encouragement! Our goal isn't to muddy the waters; it is simply to create a consistent API for coding. There is already a great GUI toolkit for Python; we're just trying to make it easier to code. The last time I checked (as I recall), at least Wax and possibly Dabo both either lagged well behind recent wxPython developments of provide relatively limited support, leaving out a sizable and (to me) important number of features from what they wrapped. Is this a remotely accurate and current picture of things? Or is it more fair to say that by adopting Dabo (or Wax?) one really loses nothing in terms of flexibility, and gains only improved write- and readability? -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: string methods
Brian Beck wrote: anthonyberet wrote: I know this touches on immutability etc, but I can't find string methods to return the first 3 characters, and then the last 2 characters, which I could concatenate with newchar to make a new string. As tiissa said, you want slicing: py s = foobar py s[:3] 'foo' py s[:3] + B + s[4:] 'fooBar' And if that's too ugly for you and you think you need to do this operation a lot, just define a function to do it for you based on the index value and string that you pass in to it. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP on path module for standard library
Sorry for the formatting of my first message; I haven't posted via Google Groups before. Reinhold Birkenfeld wrote: - Some way to pretty-print paths embedded in lists/dicts as strings. I have a .repr_as_str class attribute that toggles this. I think str() does its job nicely there. But when you str() a list or other collection, it repr()'s the elements. This makes programs difficult to debug because you can't just insert a print my_list; you then have to weed through all the path( prefixes in the output.So you have to write a custom for loop, which you may only use for five minutes, to convert the paths or print them separately. With a list you can use a list comprehension, but not with a more complex structure. I don't know if there's a good solution to this other than a path_debug function that takes an object and converts all the embedded paths to strings, because people would object to repr() returning a plain string, but I want to at least acknowledge it's a problem. Less important but non-controversial: - Path.tempfile(), Path.tempdir(): Create a temporary file using tempfile.mkstemp, tempfile.mkdtemp - Path.tempfileobject(): Create a temporary file object using tempfile.TemporaryFile. (Static method.) Don't know whether these belong here. They are all not acting upon the path, but create the file/dir at another location. More controversial than I thought. OK, they can stay in a subclass. My reasoning is that, if you're using paths, you'll need a Path for the file/dir anyway, so why not do it in one step? It also organizes the operations, the way Path organizes os.path and shutil. tempfileobject is less closely related to path, but it would allow the deprecation of the tempfile module, rather than just two functions in it. Controversial: - Delete methods and mkdir should succeed silently if the operation is already done. Otherwise you always have to put them in an if: 'if foo.exists(): foo.remove()'. That's a good thing. The delete methods shouldn't act any different from the corresponding os functions. Jason said the same thing. I disagree. But it shows why a literal superclass in the stdlib and higher-level subclasses would be useful. I don't see why a little change to avoid an unnecessary IOError is a bad thing. The only programs it would hurt are those that really want to know whether the thing already existed, and those programs can explicitly test for it *and already do*. But most programs just want to make sure the way is clear for their files, and would like a one-line call to do it. -- Mike Orr [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: 2-player game, client and server at localhost
Michael Rybak wrote: I'm writing a 2-players game that should support network mode. I'm now testing it on 1 PC since I don't have 2. I directly use sockets, and both client and server do computations, the only data transfered is user mouse/kbd input. It works synchronously, but somehow, when I play in client window, both client and server have 17 fps, while when playing in server window, server has 44 fps while client has 5, and due to forced synchronization, they both run very slowly (I wonder how come server says it has 44fps?). Does anybody have an idea how can this be? I'd suggest not spending time profiling, debugging, optimizing a home-brewed implementation using sockets but switch to Twisted or Pyro or something like that and save yourself a lot of headaches. Chances are this will magically speed things up to acceptable levels, too. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison of functions
Steven D'Aprano ha scritto: Do you understand the difference between partial and total ordering, or weakly and strongly ordered? When you do understand them, come back and tell me again whether you still think lexicographic sorting has no meaning whatsoever. I think I answered this in another post... If you want to order text strings (as complex numbers in an index in a book, or in a lexicographic sort are) do so. I understand the importance it has to you, but it's hardly reasonable to argue that Python should do the most unintuitive thing with complex numbers by default just because it suits you. -- Adriano Varoli Piazza The Inside Out: http://moranar.com.ar MSN: [EMAIL PROTECTED] ICQ: 4410132 -- http://mail.python.org/mailman/listinfo/python-list
