Re: Proposal for adding symbols within Python
Rocco Moretti wrote: Pierre Barbier de Reuille wrote: Please, note that I am entirely open for every points on this proposal (which I do not dare yet to call PEP). I still don't see why you can't just use strings. As does Guido. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Iterator addition
[EMAIL PROTECTED] wrote: Tom Anderson: And we're halfway to looking like perl already! Perhaps a more pythonic thing would be to define a then operator: all_lines = file1 then file2 then file3 Or a chain one: all_lines = file1 chain file2 chain file3 That's certainly not better than the chain() function. Introducing new operators for just one application is not pythonic. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [Info] PEP 308 accepted - new conditional expressions
Ron Adam wrote: It will be A if B else (C if D else F) So this evaluates as if there are parentheses around each section.. Hmm? (A) if (B) else ( (C) if (D) else (F) ) The first 'if' divided the expr, then each succeeding 'if' divides the sub expressions, etc... ? So ... A if B else C + X * Y Would evaluate as... ? A if B else (C + X * Y) and... value = X * Y + A if B else C would be ? value = (X * Y + A) if B else C or ? value = X * Y + (A if B else C) I think I'm going to make it a habit to put parentheses around these things just as if they were required. Yes, that's the best way to make it readable and understandable. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [Info] PEP 308 accepted - new conditional expressions
Erik Max Francis wrote: Dave Benjamin wrote: Hooray! After years of arguing over which syntax to use, and finally giving up since nobody could agree, the Benevolent Dictator did what only a dictator can do, and just made a damn decision already. Thank you, Guido! =) Yes, hear hear. So what made him change his mind? When the debates raged over PEP 308, he seemed pretty dead set against it (at least by proxy) ... Raymond Hettinger proposed to change the behavior of and/or to return one of their arguments because he had been bitten by the common trap of C and X or Y when X is False. People were positive about it, but said that then a conditional would have to be introduced. So Guido considered it again. He says himself that the greatest problem last time was that no consensus over syntax was reached, and he solved the problem this time by deciding himself. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [Info] PEP 308 accepted - new conditional expressions
Sam wrote: Jaime Wyant writes: On 9/30/05, Sam [EMAIL PROTECTED] wrote: Reinhold Birkenfeld writes: Hi, after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] What's wrong with C ? X:Y? Aside from : being overloaded? First thing that comes to my mind is that it is more C-ish (read cryptic) than pythonic (read elegant and understandable). And foo if bar is Perl-ish; yet, even Perl has the ? : operators. Perl's foo if bar is very different to this one, you should know about this. For a conditional, syntax must be found, and the tradition of Python design is not to use punctuation for something that can be solved with keywords. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
[Info] PEP 308 accepted - new conditional expressions
Hi, after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] or C and X or Y (only if X is True) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [Info] PEP 308 accepted - new conditional expressions
Fredrik Lundh wrote: Reinhold Birkenfeld wrote: after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] hopefully, only one of Y or X is actually evaluated ? (cough) Yes, sorry, it's not the same. The same would be (C and lambda:X or lambda:Y)() if I'm not much mistaken. C and X or Y (only if X is True) hopefully, only if X is True isn't in fact a limitation of X if C else Y ? /... snip comment that the natural order is C, X, Y and that programmers that care about readable code will probably want to be extremely careful with this new feature .../ Yes, that was my comment too, but I'll not demonize it before I have used it. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.4.2 compilation
pnm wrote: I have a standard Debian x86 system with Python 2.4.1 (compiled from source). Attempts to compile 2.4.2 fail with references to Unicode -- is there a basic system library that's missing? ++ output from make: libpython2.4.a(funcobject.o)(.text+0x96): In function `PyFunction_New': Objects/funcobject.c:31: undefined reference to `PyUnicode_Type' libpython2.4.a(funcobject.o)(.text+0x9d):Objects/funcobject.c:31: undefined reference to `PyUnicode_Type' collect2: ld returned 1 exit status make: *** [python] Error 1 Can you post a bug report to SourceForge and include the full output from make there? Also, have there been any unusual configure warnings? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [Info] PEP 308 accepted - new conditional expressions
Rocco Moretti wrote: Reinhold Birkenfeld wrote: Hi, after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y Any word on chaining? That is, what would happen with the following constructs: A if B else C if D else F A if B if C else D else F The first one is the tricky bit - it could be either (A if B else C) if D else F or A if B else (C if D else F) I'd expect the former from left- right semantics, but reading the unparenthesized form, I'd see A if B else ... note that B is true, and conclude the expression evaluated to A (which would be wrong if D is false). It will be A if B else (C if D else F). Quote: The priorities will be such that you can write x = A if C else B x = lambda: A if C else B x = A if C else B if D else E But you'd have to write if (A if C else B): [x for x in seq if (A if C else B)] A if (X if C else Y) else B (A if C else B) if D else E Note that all these are intentionally ugly. :) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: User-defined augmented assignment
Pierre Barbier de Reuille wrote: So, what I would suggest is to drop the user-defined augmented assignment and to ensure this equivalence : a X= b = a = a X b with 'X' begin one of the operators. It can be done, but it's unnecessary for mutable objects like sets or lists. A new object must be created in these cases where one would suffice. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: What tools are used to write and generate Python Library documentation.
Kenneth McDonald wrote: I have a module I'd like to document using the same style... The Python Library documentation is written in LaTeX and converted to HTML with latex2html. The relevant style and source files are in the Python CVS tree. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: cannot write to file after close()
Rainer Hubovsky wrote: Thank you Reinhold, that was the solution. But just because I am curious: what is this statement without the parentheses? After all it is a valid statement... Rainer In article [EMAIL PROTECTED], Reinhold Birkenfeld wrote: Is the above exactly your code? If yes, it should be f.close() The parentheses are necessary to make the statement a function call. In addition to what Fredrik said, this can be useful for shortcutting a name, such as c = f.close c() Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Determine type of a socket
Peter Hansen wrote: Tor Erik Sønvisen wrote: How can I determine the type of a socket (TCP or UDP) object? In what context? Do you have some code that gets passed a socket object but it could have been created with either SOCK_STREAM or SOCK_DGRAM? And you want a way of determining by looking just at the object passed in which type it is? (I could make other guesses, but let's start with that... ;-) ) How about this: import socket t = socket.socket(socket.AF_INET, socket.SOCK_STREAM) u = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) dir(t) ['__class__', '_sock', 'accept', 'bind', 'close' , 'connect', 'connect_ex', 'dup', 'fileno', 'getpeername', ...'setblocking', 'setsockopt', 'settimeout', 'shutdown'] Let's see... what looks good here? u._sock socket object, fd=1916, family=2, type=2, protocol=0 t._sock socket object, fd=1912, family=2, type=1, protocol=0 Maybe that type field? Heh. The type field isn't publicly accessible (yet). There is a patch on SF for this, in the meanwhile you'll have to parse the __repr__ output. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: cElementTree clear semantics
D H wrote: Igor V. Rafienko wrote: This gave me the desired behaviour, but: * It looks *very* ugly * It's twice as slow as version which sees 'end'-events only. Now, there *has* to be a better way. What am I missing? Try emailing the author for support. I don't think that's needed. He is one of the most active members of c.l.py, and you should know that yourself. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: cElementTree clear semantics
D H wrote: Reinhold Birkenfeld wrote: D H wrote: Igor V. Rafienko wrote: This gave me the desired behaviour, but: * It looks *very* ugly * It's twice as slow as version which sees 'end'-events only. Now, there *has* to be a better way. What am I missing? Try emailing the author for support. I don't think that's needed. He is one of the most active members of c.l.py, and you should know that yourself. I would recommend emailing the author of a library when you have a question about that library. You should know that yourself as well. Well, if I had e.g. a question about Boo, I would of course first ask here because I know the expert writes here. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: cElementTree clear semantics
D H wrote: Reinhold Birkenfeld wrote: Well, if I had e.g. a question about Boo, I would of course first ask here because I know the expert writes here. Reinhold Reinhold Birkenfeld also wrote: If I had wanted to say you have opinions? fuck off!, I would have said you have opinions? fuck off!. Take your own advice asshole. QED. Irony tags for sale. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: cElementTree clear semantics
D H wrote: D H wrote: Reinhold Birkenfeld wrote: Well, if I had e.g. a question about Boo, I would of course first ask here because I know the expert writes here. Reinhold Reinhold Birkenfeld also wrote: If I had wanted to say you have opinions? fuck off!, I would have said you have opinions? fuck off!. Take your own advice asshole. And what's that about? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Struggling with basics
Jason wrote:
A week ago I posted a simple little hi-score routine that I was using to
learn Python.
I've only just managed to examine the code, and the responses that
people gave, and I'm now seriously struggling to understand why things
aren't working correctly.
At present my code is as follows...
import random
import bisect
class HiScores:
def __init__(self,hiScores):
self.hiScores=[entry for entry in hiScores]
def showScores(self):
for score,name in self.hiScores:
score=str(score).zfill(5)
print %s - %s % name,score
def addScore(self,score,name):
score.zfill(5)
bisect.insort(self.hiScores,(score,name))
if len(self.hiScores)==6:
self.hiScores.pop()
def lastScore(self):
return self.hiScores[-1][0]
def main():
hiScores=[('1','Alpha'),('07500','Beta'),('05000','Gamma'),('02500','Delta'),('0','Epsilon')]
a=HiScores(hiScores)
print Original Scores\n---
a.showScores()
while 1:
newScore=str(random.randint(0,1))
if newScore a.lastScore():
print Congratulations, you scored %s % newScore
name=raw_input(Please enter your name :)
a.addScore(newScore,name)
a.showScores()
if __name__==__main__:
main()
My first problem (lack of understanding of course) is that if I run the
above, I get an error saying:
print %s - %s % name,score
TypeError: not enough arguments for format string
Now I understand what it's saying, but I don't understand why.
The '%' operator expects a tuple or a single value on its right. So you
have to set parentheses around name, score.
That needs getting used to, but otherwise it can't be discerned from
print (%s - %s % name), (score).
If I change the code to read:
print %s - %n % name, score (thinking of course that ah-ha, score is
numeric) then I get the same error.
For integers you can use %s or %i (or %d), see
http://docs.python.org/lib/typesseq-strings.html.
Apologies for going over old ground and if I'm not understanding, I'm
getting there honest ;)
No problem. c.l.py is newbie-friendly.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re: cElementTree clear semantics
D H wrote: Reinhold Birkenfeld wrote: D H wrote: D H wrote: Reinhold Birkenfeld wrote: Well, if I had e.g. a question about Boo, I would of course first ask here because I know the expert writes here. Reinhold Reinhold Birkenfeld also wrote: If I had wanted to say you have opinions? fuck off!, I would have said you have opinions? fuck off!. Take your own advice asshole. And what's that about? I think it means you should fuck off, asshole. I think you've made that clear. *plonk* Reinhold PS: I really wonder why you get upset when someone except you mentions boo. -- http://mail.python.org/mailman/listinfo/python-list
Re: cElementTree clear semantics
Paul Boddie wrote: Reinhold Birkenfeld wrote: D H wrote: I would recommend emailing the author of a library when you have a question about that library. You should know that yourself as well. Well, if I had e.g. a question about Boo, I would of course first ask here because I know the expert writes here. Regardless of anyone's alleged connection with Boo or newsgroup participation level Which was sort of an ironic wink from my side. I did not expect D H to go overboard on this. the advice to contact the package author/maintainer is sound. Correct. But if the post is already in the newsgroup and the author is known to write there extensively, it sounds ridiculous to say contact the author. It happens every now and again that people post questions to comp.lang.python about fairly specific issues or packages that would be best sent to mailing lists or other resources devoted to such topics. It's far better to get a high quality opinion from a small group of people than a lower quality opinion from a larger group or a delayed response from the maintainer because he/she doesn't happen to be spending time sifting through flame wars amidst large volumes of relatively uninteresting/irrelevant messages. Hey, the flame war stopped before it got interesting ;) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: cannot write to file after close()
Rainer Hubovsky wrote: Hello Python-Gurus, == f = open(LOGFILE,'w') f.write(time + '\n') f.close command = 'ping -n 20' + target + '' + LOGFILE system(command) == produces an error saying that a file cannot be accessed because it is used by another process. I asume it is f which is used but don't understand why. Any ideas? Is the above exactly your code? If yes, it should be f.close() The parentheses are necessary to make the statement a function call. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Struggling with basics
Jason wrote: Rather than reply to those individuals, just a big thanks to those that have helped. It's definitely making sense, the fact that I need to show the two-element tuple to show correctly was one of those head-slapping moments. And Dennis Lee Bieber hit the nail on the head when he mentioned that I'd declared the initial scores as strings, yet I was comparing them against integers. I simply removed the single-quotes from the scores and everything slotted into place. Again, I now have the list working, apart from the list is reversed (as per Dennis Lee Bieber mentioned). I'm afraid I don't understand what you mean about the DIFF report but I'll investigate further and learn a bit more. Please bear in mind: If you just remove the quotes from '00050', you will get a value of 40. This is because integer literals with leading zeroes are inter- preted as octal. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Erik Wilsher wrote: Python developement is discussed, decided and usually developed within the members of python-dev. Have you seen any discussions about xml-literals in python-dev lately? No. I don't need them, so I don't start a discussion. If you need them, or you want them, feel free to do so. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Fredrik Lundh wrote: Reinhold Birkenfeld wrote: And I think the discussion that followed proved your point perfectly Fredrik. Big discussion over fairly minor things, but no big picture. Where are the initiatives on the big stuff (common documentation format, improved build system, improved web modules, reworking the standard library to mention a few) Hey, even Ruby is passing us here. This is Open Source. If you want an initiative, start one. you know, this you have opinions? fuck off! attitude isn't really helping. If I had wanted to say you have opinions? fuck off!, I would have said you have opinions? fuck off!. All I wanted to say is that if you want a common documentation format, and you want it badly, you should show up on python-dev and offer help. Unfortunately, there are not as many Python core developers as Perl core developers, and things move at a slower pace. That's mostly not their fault, and not anyone's fault. It's a consequence of the amount of time that is spent on Python-the-core itself. And why? Well, because it's more fun to program in Python than to program Python. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Object default value
ago wrote: Is it possible to have a default value associated python objects? I.e. to flag an attribute in such a way that the assignment operator for the object returns the default attribute instead of the object itself, but calls to other object attributes are properly resolved? (I don't think so, but I am not sure) Python is not Visual Basic. In Visual Basic, objects could have a default property which was set when the object variable was assigned to, but that was only possible because object variables had to be set with Set, not Let. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Erik Wilsher wrote: And I think the discussion that followed proved your point perfectly Fredrik. Big discussion over fairly minor things, but no big picture. Where are the initiatives on the big stuff (common documentation format, improved build system, improved web modules, reworking the standard library to mention a few) Hey, even Ruby is passing us here. This is Open Source. If you want an initiative, start one. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Monitoring a directory for changes
Florian Lindner wrote: Hello, is there a python lib (preferably in the std lib) to monitor a directory for changes (adding / deleting files) for Linux 2.6? There isn't, but if you don't want to use dnotify/inotify, it is trivial to implement: use a timer and check the listdir() return value. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: slicing functionality for strings / Python suitability for bioinformatics
[EMAIL PROTECTED] wrote:
rs='AUGCUAGACGUGGAGUAG'
rs[12:15]='GAG'
Traceback (most recent call last):
File pyshell#119, line 1, in ?
rs[12:15]='GAG'
TypeError: object doesn't support slice assignment
You can't assign to a section of a sliced string in
Python 2.3 and there doesn't seem to be mention of this
as a Python 2.4 feature (don't have time to actually try
2.4 yet).
Strings are immutable in Python, which is why assignment to
slices won't work.
But why not use lists?
rs = list('AUGC...')
rs[12:15] = list('GAG')
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: 2.3 - 2.4: long int too large to convert to int
Grant Edwards wrote: I give up, how do I make this not fail under 2.4? fcntl.ioctl(self.dev.fileno(),0xc0047a80,struct.pack(HBB,0x1c,0x00,0x00)) I get an OverflowError: long int too large to convert to int ioctl() is expecting a 32-bit integer value, and 0xc0047a80 has the high-order bit set. I'm assuming Python thinks it's a signed value. How do I tell Python that 0xc0047a80 is an unsigned 32-bit value? This is fixed in the 2.5 CVS branch, where the ioctl() Python C wrapper expects an unsigned integer instead of a signed one. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: python optimization
David Wilson wrote: For the most part, CPython performs few optimisations by itself. You may be interested in psyco, which performs several heavy optimisations on running Python code. http://psyco.sf.net/ Defining a function inside a loop in CPython will cause a new function object to be created each and every time the loop runs. No such automatic optimisation is performed there. For the most part, this lack of opimisation not only simplifies the CPython implementation, but also causes code to act much more closely to how it was defined, which is good for new and advanced users alike. More importantly, since Python supports lexical scopes, a function defined in a loop could be different each time it is defined, e.g. def getadders(to): for i in range(to): def adder(amount): return i + amount yield adder Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows Python 2.4: Unbuffered flag causes SyntaxError on interactive sessions?
Irmen de Jong wrote: Michael Hoffman wrote: Lonnie Princehouse wrote: C:\python -u Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. print 'hello' File stdin, line 1 print 'hello' ^ SyntaxError: invalid syntax Worksforme: C:\Python24python.exe -u Python 2.4.1 (#65, May 24 2005, 13:43:04) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. print 'hello' hello Strange that your python build is from 30 March and mine is from 24 May. Problem also occurs on my machine using Win XP Home, Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 even just typing print at the interactive prompt causes a syntax error... It __may__ be that this is caused by an error in the codecs machinery which is already fixed in 2.4 CVS. Could you try this out? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: List of integers L.I.S. (SPOILER)
n00m wrote: Tim Peters wrote: The chance that Raymond Hettinger is going to recode _your_ functions in C is approximately 0 ;-) Who is Raymond Hettinger? See python-dev and, wrt this thread, http://docs.python.org/whatsnew/node12.html. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: List of integers L.I.S. (SPOILER)
n00m wrote: Got it! He is a kind of pythonic monsters. Btw, why it's impossible to reply to old threads? Namely, there're no more Reply link in them. Only Reply to author etc. Perhaps because you are not using a real Usenet client? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: round() wrong in Python 2.4?
Robert Kern wrote: Grant Edwards wrote: On 2005-09-14, Robert Kern [EMAIL PROTECTED] wrote: Antoon Pardon wrote: 0.0225 isn't representable and it happens that the actual number you get differ. Now which number python should choose when it is fed 0.0225, I don't know. But expressing the different behaviour as a change in round, suggest that the O.P. would be wise to learn about floating point problems Uhh, Python didn't change anything between 2.3 and 2.4 wrt round(). That's what Antoon Pardon just said. The above paragraph says that round() didn't change, and the fact that the OP thinks it did indicates that the OP needs to learn more about FP. Antoon: Python 2.3 isn't rounding 0.0225 up while pyton 2.4 rounds it down. Written in Pseudocode: not (Py2.3 rounding up and Py2.4 rounding down) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Simplifying imports?
Terry Hancock wrote: On Monday 12 September 2005 10:09 pm, [EMAIL PROTECTED] wrote: I like to keep my classes each in a separate file with the same name of the class. The problem with that is that I end up with multiple imports in the beginning of each file, like this: from foo.Bar import Bar from foo.Blah import Blah from foo.Zzz import Zzz What I'd like to do would be to replace it all by a single line: from foo.* import * Of course, that doesn't work, but is there a way to do something like that? Apparently foo is already a package defined using __init__.py, so you know about that part already. Just change its contents to read: from Bar import Bar from Blah import Blah from Zzz import Zzz Then whenever you need to use these classes, you only need: from foo import Bar, Blah, Zzz or from foo import * Or, if the Bar, Blah and Zzz classes are small enough, there's no need to put each of them in separate modules. Just put them in foo.py. Concise structuring of classes and modules is not easy. Structure too much, and you will not see the wood for the trees. Structure too little, and you won't find things anymore. IMO, the Twisted project is an example of excellent Python structuring. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: documentation error
tiissa wrote: bill wrote: From 3.2 in the Reference Manual The Standard Type Hierarchy: Integers These represent elements from the mathematical set of whole numbers. The generally recognized definition of a 'whole number' is zero and the positive integers. This term is ambiguous as it seems to be used for both natural numbers and signed numbers [1]. I cleared this up; now it reads ... set of whole numbers (positive and negative ones). Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: PyBool_FromLong
Michael Hoffman wrote: Andrew MacKeith wrote: In the C API Docs, the signature of PyBool from long seems to be incorrect. int PyBool_FromLong(long v) Returns Py_True or Py_False depending on the truth value of v. New in version 2.3. The description would suggest: PyObject* PyBool_FromLong(long v) That's in the source too (dist/src/Objects/boolobject.c, dist/src/Include/boolobject.h). Want to submit a documentation bug? Not necessary. I just fixed it. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: pickling the objects returned by array.array()
Raymond Hettinger wrote: John Machin wrote: Looks like arrays are NOW (2.4.1) pickleable but not unpickleable Please file a bug report and assign to me. Done. http://python.org/sf/1281383 Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Yielding a chain of values
Matt Hammond wrote: Well, maybe it's right both ways ;-) I.e., even though yield is now an expression, it is valid to use it as an expression-statement which evaluates the expression and discards the value. So I think you could still use the currently illegal yield in token sequence to mean that what follows is to be taken as an iterable whose full sequence is to be yielded sequentially as if yield in iterable were sugar for for _ in iterable: yield _ yield in could make sense when thought of as an expression too. x = yield in iterable Would behave like a list comprehension. x would be assigned a list containing the results of the successive yields. Equivalent to: x = [ yield r for r in iterable ] Which is quite different from x = (yield) in iterable which is currently (PEP 342) equivalent to _ = (yield) x = _ in iterable So, no further tinkering with yield, I'm afraid. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: What are new-style classes?
Terry Hancock wrote: On Tuesday 30 August 2005 04:09 pm, Reinhold Birkenfeld wrote: The customary way is to use class new_class(object):. There's no advantage in using __metaclass__ except that you can set it globally for all classes in that module (which can be confusing on its own). My comment mostly referred to new-style classes must be declared as a subclass of a new-style class, which is not true. Nonsense. Given the rest of your post, I assume that this isn't meant as it sounds. Remember, I'm German, so please bear with my sense of humour. ;) __metaclass__ is simply an implementation detail. We know that because it begins with __. Therefore it is invisible, and any delusion you may have that you can see it is a complete non-issue. In Python we call that encapsulation. ;-D Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Yielding a chain of values
Kay Schluehr wrote: Reinhold Birkenfeld wrote: x = [ yield r for r in iterable ] Which is quite different from x = (yield) in iterable which is currently (PEP 342) equivalent to _ = (yield) x = _ in iterable So, no further tinkering with yield, I'm afraid. Reinhold Is the statement yield from iterable also in danger to be ambigous? The resolution of (yield) from iterable into _ = (yield) x = _ from iterable would not result in valid Python syntax. Right. Problem is, how would you define the from syntax: Is its use as an expression allowed? What value does it have, then? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: What are new-style classes?
Steve Holden wrote: Reinhold Birkenfeld wrote: Terry Hancock wrote: On Tuesday 30 August 2005 04:09 pm, Reinhold Birkenfeld wrote: The customary way is to use class new_class(object):. There's no advantage in using __metaclass__ except that you can set it globally for all classes in that module (which can be confusing on its own). My comment mostly referred to new-style classes must be declared as a subclass of a new-style class, which is not true. Nonsense. Given the rest of your post, I assume that this isn't meant as it sounds. Remember, I'm German, so please bear with my sense of humour. ;) German? Humour? Surely some mistake :-) Hm, should have added if any above... not-talking-about-the-war-ly y'rs - steve No surprise it was the Brits who discovered the world's deadliest joke. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: What are new-style classes?
Colin J. Williams wrote: I recently heard about 'new-style classes'. I am very sorry if this sounds like a newbie question, but what are they? I checked the Python Manual but did not find anything conclusive. Could someone please enlighten me? Thanks! New style classes are becoming the standard in Python, and must always be declared as a subclass of a new style class, including built-in classes. [Warning, advanced stuff ahead!] That's not entirely true. New-style classes need not be derived from a new- style class, they need to use the metaclass type or a derived. So you can also declare a new-style class as class new_class: __metaclass__ = type Or, if you want to switch a whole module with many classes to new-style, just set a __metaclass__ = type globally. What are the pros and cons of the alternate approach? The customary way is to use class new_class(object):. There's no advantage in using __metaclass__ except that you can set it globally for all classes in that module (which can be confusing on its own). My comment mostly referred to new-style classes must be declared as a subclass of a new-style class, which is not true. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Yielding a chain of values
Bengt Richter wrote: On Tue, 30 Aug 2005 12:18:59 GMT, Michael Hudson [EMAIL PROTECTED] wrote: Talin [EMAIL PROTECTED] writes: I'm finding that a lot of places within my code, I want to return the output of a generator from another generator. Currently the only method I know of to do this is to explicitly loop over the results from the inner generator, and yield each one: for x in inner(): yield x I was wondering if there was a more efficient and concise way to do this. And if there isn't, Greenlets, perhaps? (for which, see google). Maybe yield in inner() could be sugar for the above and become something optimized? The problem here is that yield isn't a statement any more. It's now an expression, so it is not easy to find new syntax around it. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: What are new-style classes?
Terry Hancock wrote: On Sunday 28 August 2005 04:47 am, Vaibhav wrote: I recently heard about 'new-style classes'. I am very sorry if this sounds like a newbie question, but what are they? I checked the Python Manual but did not find anything conclusive. Could someone please enlighten me? Thanks! New style classes are becoming the standard in Python, and must always be declared as a subclass of a new style class, including built-in classes. [Warning, advanced stuff ahead!] That's not entirely true. New-style classes need not be derived from a new- style class, they need to use the metaclass type or a derived. So you can also declare a new-style class as class new_class: __metaclass__ = type Or, if you want to switch a whole module with many classes to new-style, just set a __metaclass__ = type globally. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Setting the encoding in pysqlite2
Michele Simionato wrote: An easy question, but I don't find the answer in the docs :-( I have a sqlite3 database containing accented characters (latin-1). How do I set the right encoding? For instance if I do this: I think you should ask on the pysqlite-devel list. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
reportlab and custom fonts
Hi, I'm trying to get reportlab working together with the Tahoma font (by Microsoft ;) So far it's up and running (converted the ttf with ttf2pt1), but the Euro sign (which is in position 0x80 in the WinAnsiEncoding) fails to show up in the final PDF. I investigated a bit and saw that in the afm (and pfb) the code point 128 is called uni20AC. That's okay in principle, since that Unicode character is the Euro sign, but it seems that reportlab likes the character to be named Euro. Okay, renamed it in both files, still no luck. Has anyone experience with this problem? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: reportlab and custom fonts
Reinhold Birkenfeld wrote: Hi, I'm trying to get reportlab working together with the Tahoma font (by Microsoft ;) So far it's up and running (converted the ttf with ttf2pt1), but the Euro sign (which is in position 0x80 in the WinAnsiEncoding) fails to show up in the final PDF. I investigated a bit and saw that in the afm (and pfb) the code point 128 is called uni20AC. That's okay in principle, since that Unicode character is the Euro sign, but it seems that reportlab likes the character to be named Euro. Okay, renamed it in both files, still no luck. Has anyone experience with this problem? Never mind, I overlooked one occurence of uni20AC in my .t1a file. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in string.find; was: Re: Proposed PEP: New style indexing, was Re: Bug in slice type
Bryan Olson wrote: Steve Holden wrote: Bryan Olson wrote: Antoon Pardon wrote: It probably is too late now, but I always felt, find should have returned None when the substring isn't found. None is certainly a reasonable candidate. [...] The really broken part is that unsuccessful searches return a legal index. We might agree, before further discussion, that this isn't the most elegant part of Python's design, and it's down to history that this tiny little wart remains. I don't think my proposal breaks historic Python code, and I don't think it has the same kind of unfortunate subtle consequences as the current indexing scheme. You may think the wart is tiny, but the duct-tape* is available so let's cure it. [*] http://www.google.com/search?as_q=warts+%22duct+tape%22 Well, nobody stops you from posting this on python-dev and be screamed at by Guido... just-kidding-ly Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: overload builtin operator
Shaun wrote: Hi, I'm trying to overload the divide operator in python for basic arithmetic. eg. 10/2 ... no classes involved. I am attempting to redefine operator.__div__ as follows: # my divide function def safediv(a,b): return ... # reassign buildin __div__ import operator operator.__div__ = safediv The operator.__dict__ seems to be updated OK but the '/' operator still calls buildin __div__ It won't work that way. You cannot globally modify the behaviour of an operator, but you can customize how an operator works for your type. Consider: class safeint(int): def __div__(self, other): return safediv(self, other) safeint(10)/2 Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: RE Despair - help required
Yoav wrote: Don't think it will do much good. I need to get them from a file and extract the last folder in the path. For example: if I get c:\dos\util I want to extract the string \util Then os.path.basename should be for you. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: variable hell
rafi wrote:
Adriaan Renting wrote:
You might be able to do something along the lines of
for count in range(0,maxcount):
value = values[count]
exec(eval('a%s=%s' % (count, value)))
why using the eval?
exec ('a%s=%s' % (count, value))
should be fine
And this demonstrates why exec as a statement was a mistake ;)
It actually is
exec 'a%s=%s' % (count, value)
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: while c = f.read(1)
John Machin wrote: ... AND it's about time that list is updated to include False explicitly -- save nitpicking arguments about whether False is covered by numeric zero of all types :-) Done. If I try: f = open(blah.txt, r) while (c = f.read(1)) != '': # ... work on c I get a syntax error also. :( Is this related to Python's expression vs. statement syntactic separation? How can I be write this code more nicely? Thanks How about for c in f.read(): ? Note that this reads the whole file into memory (changing \r\n to \n on Windows) ... performance-wise for large files you've spent some memory but clawed back the rather large CPU time spent doing f.read(1) once per character. The more nicely factor improves outasight, IMHO. Mild curiosity: what are you doing processing one character at a time that can't be done with a built-in function, a standard module, or a 3rd-party module? Don't forget for line in f: for c in line: # do stuff Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: String functions deprication
Dan wrote:
http://www.python.org/doc/2.4.1/lib/node110.html
These methods are being deprecated. What are they being replaced
with?
They're being made methods of the string class itself.
For example:
s = 'any old string'
string.split(s, ' ') # Old way
['any', 'old', 'string']
s.split()# New way
s.split(' '), if we want to be equivalent.
['any', 'old', 'string']
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: Printing literal text of an argument
Rex Eastbourne wrote:
Thanks. I adapted it a bit:
def debug(foo):
print foo, 'is:'
exec('pprint.pprint(' + foo + ')')
But I'm getting NameError: name 'foo' is not defined, since foo is
not defined in this scope. (The function works beautifully when I'm
dealing with global variables, which is very rarely).
Any way around this?
Eh, yes, but it's getting uglier...
def debug(foo):
print foo, 'is:'
frame = sys._getframe(-1)
exec 'pprint.pprint(%s)' % foo, frame.f_globals, frame.f_locals
Untested.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Python?!
Evil Bastard wrote: bruno modulix wrote: You can tell buy the most common use. bash is a scripting language, javascript is a scripting language, perl is a scripting language, php is a scripting language, Python is *not* a scripting language !-) Perhaps a better definition - the term 'scripting language' is increasingly being used by CTOs as a justification for saving money by putting large chunks of their workforces on lower pay scales - an attitude of 'scripters aren't as skilled as real programmers, so don't deserve the same pay'. To me, the term is archic. What 'scripting language' means to me is: 1. insufficient facilities for general purpose or 'serious' programming 2. ability to get simple useful programs up and working quickly 3. absence of a hack/compile/link/test cycle. My view too. What makes 1 and 3 redundant is that linkage mechanisms have diversified over the years. For instance, java and python's 'import' statements, java's CLASSPATH and python's 'sys.path'. I guess a language could be called a 'scripting language' if: - the source code can be executed directly, and/or - source need not be converted to a separate file in a non-human-readable format before it can be executed, and/or - a change to the source file automatically causes a change in runtime behaviour By these, Python is most definitely a scripting language, and joins Perl and PHP. Whereas changes to java source files don't change runtime behaviour. Though they prefer to be called agile languages nowadays. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
could ildg wrote: I want to check if a folder named foldername is empty. I use os.listdir(foldername)==[] to do this, but it will be very slow if the folder has a lot of sub-files. Is there any efficient ways to do this? try: os.rmdir(path) empty = True except OSError: empty = False should be efficient. A directory (please stop calling them folders) can only be removed if it's empty. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 0.9 Released
Al Christians wrote: EP wrote: yes, my apologies to all things Iron and or Python. language and version can be confusing if one stays up late without coffee, or perhaps if one has not been debugging their English code properly. Still, it's a bit of a PITB to me that it says XP and not Win2000. Forcing you to upgrade, isn't it? Usual MS strategy. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Euclid's Algorithm in Python?
Erik the Red wrote: So, I did the following: --- a=input(Give me an integer) b=input(Give me another integer) def gcd(a,b): if a b: a, b = b, a while b != 0: a, b = b, a % b return a --- But, in the xterm, it terminates after Give me another integer. Is Euclid's Algorithm supposed to be implemented in such a way as to be used as a tool to find the GCD of two integers, or have I misinterpreted the intent of the algorithm? You do not do anything after both input() calls. You define the function, but never call it. Add print gcd(a, b) to the end and it will print your result. Note that the variable names a and b in the function don't have anything to do with your two input variables. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Decline and fall of scripting languages ?
Kay Schluehr wrote: No good news for scripting-language fans: http://www.phpmag.net/itr/news/psecom,id,23284,nodeid,113.html The study was conducted by Evans Data Corporation. Look here: http://www.evansdata.com/n2/about_us_clients.shtml Do you see the PSF or Larry Wall on the list? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: why no arg, abs methods for comlex type?
Erik Max Francis wrote: Daniel Schüle wrote: maybe I confuse, in german one would say 45 Grad I took a freedom to translate it directly :) well, my calculator shows a D which most likely stands for Degree, I cannot tell for sure Probably. In English, you have degrees and gradians, which aren't the same thing; gradians are defined so that there are 400 gradians in a circle (so 100 gradians in a right angle). In German, they're Altgrad (degrees) and Neugrad or Gon (gradians). Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Do I need to have site.py available or not ?
Terry Reedy wrote: [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, on startup my embedded python comes up with import site failed use -v. Later python crashes on Pyrun_file(). This is the first time I have used python and I would like to know does it require site.py to be read in, and has anyone got an idea how to pass in the -v without using the python -v command, ie the embedded way. Thanks very much. If by embedded you mean embedded in a C/C++ program, I would look to the doc for the C API function that you use to start it up to see whether there is a way to pass in argv flags or to have the same effect. Also note that '-v' doesn't do what you want here, it merely activates verbose mode so that you can find the cause for above error. You want '-S'. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Setting a drive's volume label
Bob Greschke wrote: Looks like the label system command will do it in Windows. That's good enough for this exercise. So, in Linux...??? mlabel in the mtools package will do what you need. mkfs.vfat can also be given a volume label, but it will not allow you to set the label without creating a new filesystem :) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this Pythonic?
Delaney, Timothy (Tim) wrote:
Peter Hansen wrote:
Change those to raise NotImplementedError('blah') instead and you'll
be taking the more idiomatic approach.
One thing I've noticed, which I may raise on python-dev ...
NotImplementedError does *not* play well with super() ...
class A (object):
def test (self):
raise NotImplementedError
class B (object):
def test (self):
print 'B'
super(B, self).test()
class C (B, A):
def test (self):
print 'C'
super(C, self).test()
It's actually worse than AttributeError, because the method actually
exists. In both cases though you need to know when you create the base
class how it's going to be used to work out whether a super() call is
needed.
One option is to do a try: except (AttributeError, NotImplementedError).
Yuk - talk about hiding errors :(
Hm... one could return NotImplemented from the abstract method. It won't raise
an error immediately, but will certainly be discovered at some point.
Not optimal though.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
phil hunt wrote: On Sun, 31 Jul 2005 09:48:45 +0200, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: An improvement to what? To how the class is implemented, or to how it is used? No, the second function is cleaner and more readable than the first, IMHO. True, but the first function, at all of seven lines, is hardly complicated. I mean, if anyone couldn't understand it, they'd never make a programmer. If you mean the former, yes is it, due to the os.path module not providing a function that does this. If you mean the latter, I disagree, because I would then have to call it with something like: pn = normalizePath(Path(p), q) That's easily helped by s/tp = p/tp = Path(p)/. I have no idea what that comment means. That's short for replace 'tp = p' by 'tp = Path(p). sed-lingo ;) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
phil hunt wrote: On Sun, 31 Jul 2005 12:09:48 -0700, Cliff Wells [EMAIL PROTECTED] wrote: On Sun, 2005-07-31 at 10:07 -0700, Kay Schluehr wrote: Some other people already abandoned Python not for the worst reasons: http://www.kevin-walzer.com/pivot/entry.php?id=69 Being a developer requires not only a bit of brains, but quite a bit of tenacity as well. Apparently Kevin lacks the second. My objection with wrappers around wrappers around wrappers is that I have no hope ever watching the ground. If some error occurs, which layer has to be addressed? Which developing group is reponsible? My own or that of team A, team B, team C ... ? The baroque concept is repulsive to me and only acceptable in case of legacy code that gets wrapped around old one and is dedicated to substitute it continously. Of course, Tkinter is still a wrapper around a third party library (Tk) borrowed from a different language (Tcl) and written again in a third language (C), much the same as wxPython. In practise any Python GUI is going to contain code from otyher languages since if it was coded all the way down in python it would be too slow. Oh, I could imagine that a MFC-like wrapper around win32gui, or another one around Xlib wouldn't be slower that wxWidgets is today. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting not derived members of a class
Franz Steinhaeusler wrote: The background: I want to create a code completition for an editor component. It should distinguish between inherited and non inherited members. Reason is, that on wxPython, most classes are derived from wxWindow. For example if I want Code completition for wx.Frame, I always get the 200 or so suggestions, whereby most times, I'm only interested in the possible completions of wx.Frame and maybe wx.TopLevelWindow. You can, of course, always search the base classes and subtract the two sets (all members)-(members of baseclasses). For example: cls = wx.Frame set(dir(cls)) - reduce(set.union, [set(dir(base)) for base in cls.__bases__]) Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Wheel-reinvention with Python
Kay Schluehr wrote: Reinhold Birkenfeld wrote: In practise any Python GUI is going to contain code from otyher languages since if it was coded all the way down in python it would be too slow. Oh, I could imagine that a MFC-like wrapper around win32gui, or another one around Xlib wouldn't be slower that wxWidgets is today. Reinhold Hi Reinhold, did You have a look at 'venster'? http://venster.sourceforge.net/htdocs/index.html They even dropped win32gui and worked with ctypes and the Win32API reducing the C-footprint. For frameworks like Dabo, AnyGUI, PyGUI etc. this would be the right level to create an abstraction layer IMO. By the way the demo applications of venster run stable and fast on WinXP. Ah! No, I didn't know this. I don't need it, either ;) but good to know it exists. Of course, doing such a thing for Xlib is more complicated because it doesn't know native widgets (okay, you can use Athena et al., but who wants them today...). Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
phil hunt wrote: On Sat, 30 Jul 2005 19:01:49 +0200, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: 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? An improvement to what? To how the class is implemented, or to how it is used? No, the second function is cleaner and more readable than the first, IMHO. If you mean the former, yes is it, due to the os.path module not providing a function that does this. If you mean the latter, I disagree, because I would then have to call it with something like: pn = normalizePath(Path(p), q) That's easily helped by s/tp = p/tp = Path(p)/. and then I would have the problem that (pn) isn't a string so calling a function to write some data into the file at that filename would no longer work, i.e. this: writeFile(pn, someData) would become this: writeFile(pn.getString(), someData) Why? A Path is a string. Reinhold -- 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: 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
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: [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: 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: multiple inheritance super()
Michele Simionato wrote: http://fuhm.org/super-harmful/ That is a pretty good page; I must say that my position is more radical (i.e. it is not super which is harmful, it is multiple inheritance itself that it is harmful: was I going to design a new language I would implement it *without* multiple inheritance). Multiple inheritance can be very useful if not used in an unresponsible way. For example, think of mixins. Or compatibility layers. Lately I had to adapt a wx 2.6 application to wx 2.4 I could either search and substitute $BIGNUM self.Bind() calls (which isn't done via simple Emacs magic, cause the replacement varies), or I could write a compatibility mixin and derive every GUI class from it, too. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: finding out the calling function
flupke wrote: Hi, i have a property in a class that gets changed and i would want to know who changes it. Is there a way i can find out the calling function of a property? You're looking for sys._getframe. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug Report / Patch (1159139 cgi.py invalid REQUEST_METHOD set)
Joe wrote:
Back in March I submitted a patch for cgi.py to sourceforge to fix a problem
with the handling of an invalid REQUEST_METHOD.
I thought I followed all the steps to properly submit the bug and patch but
the patch is still sitting there in limbo.
This is the first patch I have submitted for Python, did I miss a step in
the patch process?
What else needs to be done?
Can you provide an example script demonstrating the problem you describe?
I tried something like this (Py2.4.1):
--- test_cgi.py
#!/bin/env python
import cgi
fs = cgi.FieldStorage()
print fs
$ python test_cgi.py a=1b=2
FieldStorage(None, None, [MiniFieldStorage('a', '1'), MiniFieldStorage('b',
'2')])
$
There's no REQUEST_METHOD or QUERY_STRING env var set.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Tony Meyer wrote: [...] Open issues: [...] What about path * 4? If you keep the current join meaning of __div__, then assigning any sort of multiplication meaning to __mul__ would not be a good idea, IMO. It's natural to expect that __div__ and __mul__ are opposites. I suppose this means that you could make __mul__ mean split (and f(*tuple) does do splitting of a sort), but I don't know what splitting by 4 would mean, necessarily. Yes. I think I'll not attach any meaning to it. If used, it will have the same meaning as string * 4. Do people really like using __div__ to mean join? On the python-dev discussion, Just van Rossum spoke out against it, but there weren't (IIRC) any other comments, either pro or con. I'm not too happy with it, too, but do we have alternatives? As paths are strings, we can hardly override the '+' operator, so there's not much operators left. Of course, one can use joinwith() if he doesn't like '/'. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Andrew Dalke wrote: Reinhold Birkenfeld wrote: Okay. While a path has its clear use cases and those don't need above methods, it may be that some brain-dead functions needs them. brain-dead? Consider this code, which I think is not atypical. Okay, convinced. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: Hi, the arguments in the previous thread were convincing enough, so I made the Path class inherit from str/unicode again. Current change: * Add base() method for converting to str/unicode. * Allow compare against normal strings. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Stefan Rank wrote: on 25.07.2005 10:44 Michael Hoffman said the following: Reinhold Birkenfeld wrote: Tony Meyer wrote: Do people really like using __div__ to mean join? Of course, one can use joinwith() if he doesn't like '/'. Personally, I'm -0 on __div__, but I suppose if anyone here claimed to have used in the past, rather than it just being some novelty that might be a good idea, that would be good enough for keeping it. I, herewith, claim to have used it in the past. But I am indifferent as to if its needed, it just looks natural to me. What I use quite often is:: path(__file__).dirname() / somesiblingfileiknowisthere you do not have to think about trailing slashes or absolute vs. relative. and its much better than:: from os.path import * join(dirname(__file__), somesiblingfileiknowisthere) __div__ is actually very convenient to build / a / very / very / long / path (of course assuming the parts are strings not known initially...) Even knowing the parts that can be helpful if you want to be cross-platform. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Path PEP: What should Path(None) do?
Michael Hoffman wrote:
Currently it returns Path('None'). This means I have to do a check on
input before pathifying it to make sure it is not None.
Perhaps it should throw ValueError?
The problem is that Path() currently acts like str() and will therefore
accept almost anything that has a string representation.
We can do two things: 1) restrict Path.__new__ arguments to be strings
or unicode only, or 2) special-case None and what else comes in mind.
I think 1) is the proper solution. Path() is not a general stringifier
as str(), and shouldn't act like one.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote: Reinhold Birkenfeld wrote: Peter Hansen wrote: Would basestring() be a better name? tobase? tostring? tobasestring? Of these choices, the latter would be preferable. Alternative is to set a class attribute Base of the Path class. Or export PathBase as a name from the module (but that's not quite useful, because I expect Path to be imported via from os.path import Path). I don't understand how that would work. An attribute on the *class*? What would it be, a callable? So mypath.Base(mypath) or something? Please elaborate... [_base is str or unicode] class Path: Base = _base [...] So you could do Path.Base(mypath) or mypath.Base(mypath). What about just .basestring, as a read-only attribute on the Path object? Reasonable, though the term as such is preoccupied too. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Path PEP: What should Path(None) do?
Peter Hansen wrote:
Michael Hoffman wrote:
Currently it returns Path('None'). This means I have to do a check on
input before pathifying it to make sure it is not None.
Perhaps it should throw ValueError?
Without checking, I suspect it is merely doing str(x) or unicode(x) on
whatever is passed to it:
path(None)
path(u'None')
path(object())
path(u'object object at 0x00AAB438')
path(3.14159)
path(u'3.14159')
Therefore I think the question should be broadened beyond just None.
Should Path(x) simply call str(x) on the object or should it raise
ValueError or TypeError or something if it's not a basestring?
Given that pretty much *everything* in Python can have str() called on
it, I think we should ask for a modicum of type-safety here and reject
non-strings as input.
Settled.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
[EMAIL PROTECTED] wrote: Reinhold Right, that was a concern of mine, too. Reinhold tobase? Reinhold tostring? Reinhold tobasestring? If we're on a filesystem that understands unicode, would somepath.tostring() return a unicode object or a string object encoded with some to-be-determined encoding? Whatever the base of the Path object is. It selects its base class based on os.path.supports_unicode_filenames. Why not just add __str__ and __unicode__ methods to the class and let the user use str(somepath) or unicode(somepath) as needed? Or am I missing something fundamental about what the base() method is supposed to do? It should provide an alternative way of spelling Path.__bases__[0](path). Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Bengt Richter wrote: BTW, more OT, wouldn't '|' be more platform-neutral as the joining operator? I, on the other hand, would certainly prefer U+01C1. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote:
Reinhold Birkenfeld wrote:
[on comparing Paths and stings]
Do you have a use case for the comparison? Paths should be compared only
with other paths.
I can think of lots, though I don't know that I've used any in my
existing (somewhat limited) code that uses Path, but they all involve
cases where I would expect, if comparisons were disallowed, to just wrap
the string in a Path first, even though to me that seems like it should
be an unnecessary step:
if mypath.splitpath()[0] == 'c:/temp':
if 'tests' in mypath.dirs():
and lots of other uses which start by treating a Path as a string
first, such as by doing .endswith('_unit.py')
endswith is okay, since it is an inherited method from str.
Any of these could be resolved by ensuring both are Paths, but then I'm
not sure there's much justification left for using a baseclass of
basestring in the first place:
if mypath.splitpath()[0] == Path('c:/temp'):
But you must admit that that't the cleaner solution.
if Path('tests') in mypath.dirs():
Question: would this latter one actually work? Would this check items
in the list using comparison or identity? Identity would simply be
wrong here.
Yes, it works. I didn't do anything to make it work, but Path seems to inherit
the immutableness from str.
[on removing properties in favour of methods for volatile data]
My line of thought is that a path may, but does not need to refer to an
existing, metadata-readable file. For this, I think a property is not
proper.
Fair enough, though in either case an attempt to access that information
leads to the same exception. I can't make a strong argument in favour
of properties (nor against them, really).
Okay.
What about iteration and indexing? Should it support
for element in path or for char in path or nothing?
As John Roth suggests, the former seems a much more useful thing to do.
The latter is probably as rarely needed as it is with regular strings
(which I believe is roughly never in Python).
[on .read_file_bytes() etc]
I think it is not exactly bad that these names are somehow outstanding,
as that demonstrates that something complex and special happens.
Point taken. What about ditching the file part, since it is redundant
and obvious that a file is in fact what is being accessed. Thus:
.read_bytes(), .read_text(), .write_lines() etc.
Hm. Is it so clear that a it's about a file? A path can point to anything,
so I think it's better to clearly state that this is only for a file at the
path, if it exists.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Reinhold Birkenfeld wrote: Hi, the arguments in the previous thread were convincing enough, so I made the Path class inherit from str/unicode again. Further changes by now: * subdirs() is now dirs(). * fixed compare behaviour for unicode base (unicode has no rich compare) * __iter__() iterates over the parts(). * the following methods raise NotImplemented: capitalize, expandtabs, join, splitlines, title, zfill Open issues: What about the is* string methods? What about __contains__ and __getitem__? What about path * 4? Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Michael Hoffman wrote: Reinhold Birkenfeld wrote: * __iter__() iterates over the parts(). * the following methods raise NotImplemented: capitalize, expandtabs, join, splitlines, title, zfill Why? They *are* implemented. I do not understand this desire to wantonly break basestring compatiblity for the sake of breaking compatibility. Once you break compatibility with basestring you can no longer use a path anywhere that you could have used a str or unicode before. With compatibility broken, the only possible supported way of passing paths to third-party functions will be to cast the path with path.__bases__[0](mypath) before passing it anywhere else. You can't even use str() because you don't know what the base class of the path is. What a pain. From the original path.py documentation: os.path.join doesn't map to path.join(), because there's a string method with that name. Instead it's path.joinpath(). This is a nuisance, but changing the semantics of base class methods is worse. (I know, I tried it.) The same goes for split(). It ain't broke. Please stop breaking it. Okay. While a path has its clear use cases and those don't need above methods, it may be that some brain-dead functions needs them. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
Peter Hansen wrote:
Reinhold Birkenfeld wrote:
Peter Hansen wrote:
if mypath.splitpath()[0] == 'c:/temp':
vs.
if mypath.splitpath()[0] == Path('c:/temp'):
But you must admit that that't the cleaner solution.
Cleaner? Not at all. I'd say it's the more expressive solution,
perhaps, but I definitely wouldn't choose the word cleaner for
something which, to me, adds fairly unnecessary text.
But it's clearly a subjective matter, and as the one of us not involved
in doing the real work here, I'll bow to your judgement on the matter. ;-)
I'm in no way the last instance on this.
For example, everyone with CVS access is free to change the files ;)
Honestly, I'm in constant fear that allowing too much and loading too much
features won't increase the acceptance of python-dev wink
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
Re: tuple to string?
John Machin wrote:
Reinhold Birkenfeld wrote:
Berthold Höllmann wrote:
Francois De Serres [EMAIL PROTECTED] writes:
hiho,
what's the clean way to translate the tuple (0x73, 0x70, 0x61, 0x6D)
to the string 'spam'?
. t = (0x73, 0x70, 0x61, 0x6D)
. ''.join('%c' % c for c in t)
'spam'
Or:
t = (0x73, 0x70, 0x61, 0x6D)
('%c' * len(t)) % t
You don't need the sissy parentheses; '%c' * len(t) % t works just fine :-)
Ah, ok. Didn't want to lookup the precedence rules...
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
[path-PEP] Path inherits from basestring again
Hi,
the arguments in the previous thread were convincing enough, so I made the
Path class inherit from str/unicode again.
It still can be found in CVS:
/python/nondist/sandbox/path/{path.py,test_path.py}
One thing is still different, though: a Path instance won't compare to a regular
string.
Other minor differences, as requested on python-dev, are:
* size property - getsize() method.
* atime/mtime/ctime properties - atime()/mtime()/ctime() methods
* dirname() method - directory property
* no parent property
* basename() method - basename property
* no name property
* listdir() method - children() method
* there is still a listdir() method, but with the semantics of os.listdir
* dirs() method - subdirs() method
* joinpath() method - added alias joinwith()
* splitall() method - parts() method
* Default constructor: Path() == Path(os.curdir)
* staticmethod Path.getcwd() - Path.cwd()
* bytes() / lines() / text() - read_file_{bytes,lines,text} methods
* write_{bytes,lines,text} - write_file_{bytes,lines,text} methods
These may be removed though.
Reinhold
--
http://mail.python.org/mailman/listinfo/python-list
