🌐 Mailman 3 July 2008 - Python-list - python.org

Re: How to figure out if the platform is 32bit or 64bit?
by norseman Aug. 2, 2008

Aug. 2, 2008

> > I need to know if I'm running on 32bit or 64bit ... so far I haven't > > come up with how to get this info via python. sys.platform returns > > what python was built on ... but not what the current system is. > > > > I thought platform.uname() or just platform.processor() would have > > done it, but python returns an empty string on windows. Any ideas? > > > > Thanks, Ken =========================================== From what I'm reading I think the answer lies in being able to see Microsoft's OS 'About' statement. One of the Python guru's should be able to supply the code. On Linux you should be able to uname -m and get a pretty good idea. See man uname. something like: #contents of t.py #----------- import os zstatflg= os.system("uname -m") #----------- EOF --- then: python t.py i686 (I'm running a stock Python 2.5.2) If the Python itself was compiled 32 bit and installed on a 64 bit machine that runs 32 bit code (like most all do during transition times) then all attempts with Python to check itself will return 32 bit responses. Using math and/or 'kibitz' (cheater text) will be useless. Hope this helps; Steve norseman(a)hughes.net

5 5

Python parsing iTunes XML/COM
by william tanksley Aug. 2, 2008

Aug. 2, 2008

I'm trying to convert the URLs contained in iTunes' XML file into a form comparable with the filenames returned by iTunes' COM interface. I'm writing a podcast sorter in Python; I'm using iTunes under Windows right now. iTunes' COM provides most of my data input and all of my mp3/aac editing capabilities; the one thing I can't access through COM is the Release Date, which is my primary sorting field. So I read everything in through COM, then read all the release dates from the iTunes XML file, then try to join the two together... But so far I have zero success. Is there _any_ way to match up tracks between iTunes COM and iTunes XML? I've spent far too much effort on this. I'm not stuck on using filenames, if that's a bad idea... But I haven't found anything else that works, and filenames seem like an obvious solution. -Wm

4 12

Newbie having issues with threads
by James Calivar Aug. 1, 2008

Aug. 1, 2008

I'm a newbie trying to write a script that uses threads. I'm right now a little bit stuck in understanding why the code snippet I wrote doesn't seem to be entering the function defined in the start_new_thread() call. If I run it as is (the threaded version), the output is: UA_1 configuring... UA_1 halting.. But if I comment out the line w/ the thread and just call the function directly, everything seems to work OK: UA_1 configuring... UA_1 executing... UA_1 halting... Can anyone tell me why the thread doesn't seem to invoke the function "execute()"? I'm running Python 2.4.3. Here is my code: =========== import thread class Test(object): def __init__(self, instanceID): self.instanceID = instanceID def configure(self): print self.instanceID + " configuring..." def execute(self): print self.instanceID + " executing..." def halt(self): print self.instanceID + " halting..." if __name__ == "__main__": """usage: sipp_auto [options]""" ua1 = Test("UA_1") ua1.configure() #ua1.execute() thread.start_new_thread(ua1.execute, ()) ua1.halt() =========== Thanks, James

2 1

Attack a sacred Python Cow
by Jordan Aug. 1, 2008

Aug. 1, 2008

Hi everyone, I'm a big Python fan who used to be involved semi regularly in comp.lang.python (lots of lurking, occasional posting) but kind of trailed off a bit. I just wrote a frustration inspired rant on my blog, and I thought it was relevant enough as a wider issue to the Python community to post here for your discussion and consideration. This is not flamebait. I love Python, and I'm not out to antagonise the community. I also realise that one of the issues I raise is way too ingrained to be changed now. I'd just like to share my thinking on a misstep in Python's guiding principles that has done more harm than good IMO. So anyway, here's the post. I've become utterly convinced that at least one criticism leveled at my favourite overall programming language, Python, is utterly true and fair. After quite a while away from writing Python code, I started last night on a whim to knock up some code for a prototype of an idea I once had. It's going swimmingly; the Python Image Library, which I'd never used before, seems quick, intuitive, and with the all the features I need for this project. As for Python itself, well, my heart still belongs to whitespace delimitation. All the basics of Python coding are there in my mind like I never stopped using them, or like I've been programming in this language for 10 years. Except when it comes to Classes. I added some classes to code that had previously just been functions, and you know what I did - or rather, forgot to do? Put in the 'self'. In front of some of the variable accesses, but more noticably, at the start of *every single method argument list.* This cannot be any longer blamed as a hangover from Java - I've written a ton more code, more recently in Python than in Java or any other OO language. What's more, every time I go back to Python after a break of more than about a week or so, I start making this 'mistake' again. The perennial justification for this 'feature' of the language? That old Python favourite, "Explicit is better than implicit." I'm sorry, but EXPLICIT IS NOT NECESSARILY BETTER THAN IMPLICIT. Assembler is explicit FFS. Intuitive, clever, dependable, expected, well-designed *implicit* behaviour is one of the chief reasons why I use a high level language. Implicitly garbage collect old objects for me? Yes, please! I was once bitten by a Python wart I felt was bad enough to raise and spend some effort advocating change for on comp.lang.python (never got around to doing a PEP; partly laziness, partly young and inexperienced enough to be intimidated at the thought. Still am, perhaps.) The following doesn't work as any sane, reasonable person would expect: # Blog code, not tested class A(): def __eq__(self, obj): return True a = A() b = [] assert a == b assert not (a != b) The second assertion fails. Why? Because coding __eq__, the most obvious way to make a class have equality based comparisons, buys you nothing from the != operator. != isn't (by default) a synonym for the negation of == (unlike in, say, every other language ever); not only will Python let you make them mean different things, without documenting this fact - it actively encourages you to do so. There were a disturbingly high number of people defending this (including one quite renowned Pythonista, think it might have been Effbot). Some had the temerity to fall back on "Explicit is better than implict: if you want != to work, you should damn well code __ne__!" Why, for heaven's sake, should I have to, when in 99.99% of use cases (and of those 0.01% instances quoted in the argument at the time only one struck me as remotely compelling) every programmer is going to want __ne__ to be the logical negation of __eq__? Why, dear Python, are you making me write evil Java-style language power reducing boilerplate to do the thing you should be doing yourself anyway? What's more, every programmer is going to unconciously expect it to work this way, and be as utterly as mystified as me when it fails to do so. Don't tell me to RTFM and don't tell me to be explicit. I'll repeat myself - if I wanted to be explicit, I'd be using C and managing my own memory thank you very much. Better yet, I'd explicitly and graphically swear - swear in frustration at this entrenched design philosophy madness that afflicts my favourite language. I think the real problem with the explicit is better than implicit, though, is that while you can see the underlying truth its trying to get at (which is perhaps better expressed by Ruby's more equivocal, less dependable, but more useful Principle of Least Surprise), in its stated form its actually kind of meanginless and is used mainly in defence of warts - no, we'll call them for what they are, a language design *bugs*. You see, the problem is, there's no such thing of explict in programming. Its not a question of not doing things implicitly; its a question of doing the most sensible thing implicitly. For example this python code: some_obj.some_meth(some_arg1, some_arg2) is implicitly equivalent to SomeClass.some_meth(some_obj, some_arg1, some_arg2) which in turn gives us self as a reference to some_obj, and Python's OO model merrily pretends its the same as Java's when in fact is a smarter version that just superficially looks the same. The problem is that the explicit requirement to have self at the start of every method is something that should be shipped off to the implicit category. You should have to be explicit, yes - explicit when you want the *other* behaviour, of self *not* being an argument, because thats the more unusual, less likely case. Likewise, a != b is implicitly equivalent to something like calling this function (may not be correct, its a while since I was heavily involved in this issue): def equal(a, b): if hasattr(a, "__ne__"): return a.__ne__(b) if hasattr(b, "__ne__"): return b.__ne__(a) if hasattr(a, "__cmp__"): return not (a.__cmp__(b) == 0) if hasattr(b, "__cmp__"): return not (b.__cmp__(a) == 0) return not (a is b) There's absolutely nothing explicit about this. I wasn't arguing for making behaviour implicit; I was arguing for changing the stupid implict behaviour to something more sensible and less surprising. The sad thing is there are plenty of smart Python programmers who will justify all kinds of idiocy in the name of their holy crusade against the implict. If there was one change I could make to Python, it would be to get that damn line out of the Zen.

27 73

Python Written in C?
by giveitawhril2008＠gmail.com Aug. 1, 2008

Aug. 1, 2008

I'm just learning about Python now and it sounds interesting. But I just read (on the Wiki page) that mainstream Python was written in C. That's what I was searching for: Python was written in what other language? See, my concern was something like: OK, if Python is so hot, then, hopefully someone is writing it in assembly language for each MPU chip out there. Otherwise, if, say, they've written it in C#, then it looks like the REAL, generally useful language to learn is C# and Python is akin to Visual Basic or something: a specialty language....whereas REAL WORLD programmers who want to be generally useful go and learn C#. So I was suspecting the Python compiler or interpreter is written in a REAL language like C#. So, Wiki says it's written in C! It's almost as if it were an intentional trick...write your own, new language in an OLD, real world language that is passe. Compile it into executable modules of course, so it is a real, working compiler, alright. But the SOURCE is some old, high level language which no one wants to use anymore! So now you've got a hot new language package and no one can say "well, it is written in, the SOURCE code is written in, a REAL language." No, it's not! The source is some outdated language and compiler and no one is going to prefer learning THAT to learning your hot new language! I'm not dissing Python, here. Just noting that, if it is written in C, that throws a curve at me in trying to balance the value of learning Python vs. some other major language.

37 47

Re: like py2exe, but on a mac
by William McBrine Aug. 1, 2008

Aug. 1, 2008

On Sun, 13 Jul 2008 00:58:59 +0200, Python.Arno wrote: > http://undefined.org/python/py2app.html py2app bundles Python itself into the app, right? I wonder, is there no way to create an app bundle that relies on the existing installation of Python, since OS X already comes with Python? I have a tiny little program (~20k) that I'd like to make into an app bundle, if only to suppress the console window, and I'd rather not lump in the whole Python interpreter if I can avoid it. -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- pass it on

4 5

find and replace with regular expressions
by chrispoliquin＠gmail.com Aug. 1, 2008

Aug. 1, 2008

I am using regular expressions to search a string (always full sentences, maybe more than one sentence) for common abbreviations and remove the periods. I need to break the string into different sentences but split('.') doesn't solve the whole problem because of possible periods in the middle of a sentence. So I have... ---------------- import re middle_abbr = re.compile('[A-Za-z0-9]\.[A-Za-z0-9]\.') # this will find abbreviations like e.g. or i.e. in the middle of a sentence. # then I want to remove the periods. ---------------- I want to keep the ie or eg but just take out the periods. Any ideas? Of course newString = middle_abbr.sub('',txt) where txt is the string will take out the entire abbreviation with the alphanumeric characters included.

5 6

saving an e-mail attachement
by robinsiebler＠gmail.com Aug. 1, 2008

Aug. 1, 2008

I'm trying to figure out how to save an e-mail attachment from a POP3 mailbox. I've scoured the web, but -none- of the examples I have found have actually worked. For instance, in this example: http://groups.google.com/group/comp.lang.python/browse_thread/thread/8423ca…, fn is always None, but the e-mail -does- have an attachment (an xml file).

2 1

how to split text into lines?
by kj Aug. 1, 2008

Aug. 1, 2008

In Perl, one can break a chunk of text into an array of lines while preserving the trailing line-termination sequence in each line, if any, by splitting the text on the regular expression /^/: DB<1> x split(/^/, "foo\nbar\nbaz") 0 'foo ' 1 'bar ' 2 'baz' But nothing like this seems to work in Python: >>> re.split('^', 'foo\nbar\nbaz') ['foo\nbar\nbaz'] (One gets the same result if one adds the re.MULTILINE flag to the re.split call.) What's the Python idiom for splitting text into lines, preserving the end-of-line sequence in each line? -- NOTE: In my address everything before the first period is backwards; and the last period, and everything after it, should be discarded.

4 5

Re: Boolean tests [was Re: Attack a sacred Python Cow]
by Russ P. Aug. 1, 2008

Aug. 1, 2008

On Jul 30, 12:03 am, Heiko Wundram <modeln...(a)modelnine.org> wrote: > Am Mittwoch, 30. Juli 2008 08:30:48 schrieb Russ P.: > > > On Jul 29, 11:09 pm, Erik Max Francis <m...(a)alcyone.com> wrote: > > > I'm getting this sneaking suspicion that you guys are all putting us on. > > > As I said in an earlier post, I realize that this would only work if > > there were only one copy of "empty" (as there is only one copy of > > "None"). I don't know off hand if that is feasible or not. > > > You reply reeks of the kind of pedantic snobbishness that makes me > > sick. > > I can understand (and pretty much sympathise) that you get this kind of reply, > simply because the point you and Carl Banks (formulated somewhat differently) > put up has been answered again and again (in this thread), and I can only > repeat it once more: > > __nonzero__(), i.e. the "cast" to boolean, is THE WAY to test whether a > container is empty or not. Like this design decision, or don't like it, but > the discussion is not going to go anywhere unless you concede that there is a > (very explicit!) way to test for non-emptiness of a container already, and > you're currently simply discussing about adding/using syntactic sugar > (different means of expressing the test) to suit your own personal taste > better. Anyway, check the documentation for __nonzero__(): if the object > doesn't implement that, but implements __len__(), the interpreter "replaces" > the __nonzero__() test by __len__()>0, so I guess someone in the design > department must've seen it logical for the truth value of a container to > express the test "len(x)>0" at some point in time to make this interpretation > for the truth value of a container. > > There cannot be an argument about missing/misplaced functionality (that's what > you make it sound like), if the functionality for doing what you want to do > is there and you simply don't like the syntax, which I can somewhat relate to > because style is a personal thing, even though I don't see either points made > by you or Carl Banks, because implicit casting to bool is so common in pretty > much every programming language to test for "truth" of an object, and IMHO > it's completely logical to extend that idea to containers to mean > empty/non-empty. > > Eric Max Francis tried to explain why your syntactic "enhancement" would come > at a much greater price than its worth, and he's absolutely right in that, as > it's an abuse of the "is" operator, but again, that's a somewhat different > point. It changes nothing about the fact that all this discussion centers > around something that is a non-point, but simply a matter of personal taste. > > -- > Heiko Wundram Oh, Lordy. I understand perfectly well how boolean tests, __len__, and __nonzero__ work in Python. It's very basic stuff. You can quit patronizing me (and Carl too, I'm sure). The point that you seem to be missing, or refuse to acknowledge for some reason, is that "if x" can be mistakenly applied to any object when the programmer thinks that x is a list -- and the programmer will receive no feedback on the error. I have made errors like that, and I could have saved some time had I used an "empty" method that only applies to a list or other sequence. Is that an important issue? I don't know. I'm not claiming it is. But you cannot just sweep it away as nothing.

7 18