Re: Simple unicode-safe version of str(exception)?
In article [EMAIL PROTECTED], Martin v. Löwis [EMAIL PROTECTED] wrote: I have code like this: except Exception, e: self.setState(self.Failed, str(e)) which fails if the exception contains a unicode argument. Fails how? ASCII encoding error, I suppose. It fails only if a) one argument is a Unicode object, and b) that Unicode object contains non-ASCII parameters. Seem ironic that this fails even though pretty nearly anything else is a valid input to str() -- socket, dict, whatever? A sort of generic solution might be to follow str's behavior with respect to '__str__', extending it to fall back to repr() whatever goes wrong. def xtr(a): try: return str(a) except: return repr(a) ... self.setState(self.Failed, xtr(e)) Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: py3k concerns. An example
In article [EMAIL PROTECTED], Martin v. Löwis [EMAIL PROTECTED] wrote: I still think it's a shame [...] pps: I have to note that it would be nice if the ad-hominem (sp?) invective would drop out of these threads -- it doesn't add a lot, I think. shame 1 a. a painful emotion caused by consciousness of guilt, shortcoming, or impropriety 2 a condition of humiliating disgrace or disrepute - [in sing.] a regrettable or unfortunate situation or action: `it is a shame that they are not better known' If English isn't your 1st language, you deserve a lot of credit for your mastery of it, but you need a better dictionary. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: py3k s***s
In article [EMAIL PROTECTED], Aaron Watters [EMAIL PROTECTED] wrote: Maybe there is a secret desire in the Python community to remain a fringe minority underdog forever? I'm sure anyone who has given it any thought understands that the fringe minority situation is a lot more fun in some ways, but I think if you were to apply a sort of conspiracy analysis to the situation - who benefits from language change - this would be a couple items down on the list of motivations. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: py3k s***s
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: Aaron Watters wrote: The cost paid for these minor improvements is too high in my book. But I suppose if it is going to happen do it sooner rather than later. Just *please* *please* don't systematically break the pre-existing code base again for a very long time, preferable ever. I'm pretty sure the 3.0 compatibility breakage is a one-shot deal. If it's not I won't be the only one looking for Guido with a bog stick in my hand ... Depending on what you mean, that appears to be either a truism or an absurdity. If you mean, 3.1 won't break code like 3.0 did ... well, of course. If you mean, there won't be a 4.0 that means the same thing for compatibility that 3.0 means, then I can't imagine how you could be convinced of this. Changes to Python in 3.0 won't satisfy the continuing need for change thereafter. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: py3k s***s
In article [EMAIL PROTECTED], Sverker Nilsson [EMAIL PROTECTED] wrote: No one forces me, but sooner or later they will want a Python 3.0 and then a 3.1 whatever. I don't want that fuzz. As about the C versions, I am not that worried. What's your point? I just like want to write a program that will stay working. And maybe I can go on with something else hopefully than just compatibility fixes. They take some work afterall. It seems hard with Python. Esp. 2 - 3 Welcome to the world of Python. There was a period of relative stability in the '90s, culminating with version 1.5.2, which just happens to be about the time that people started taking Python seriously. It turns out that this stability was only due to lack of resources, though. I think most of us are working under two imperatives here that really boil down to the same thing: we want a programming language that lets us focus on the goal of the program. On one hand, that means things like automatic memory management that are brought to us by newer languages (i.e., less than 30 years old.) On the other hand it means stability that allows our deployed code to go on working without constant intervention, which usually we find in languages that have become utterly boring and out of fashion (i.e., more than 30 years old.) It's hard to find a good compromise between these two, in an interpreted language. I don't know what the current party line may be on this matter, but some years back it was that you should consider the interpreter part of your application. That is, each application should deploy with its own dedicated Python interpreter, complete with libraries and everything. This naturally relieves some of the maintenance issues, since at least you can upgrade on your own schedule, but of course it has its costs too. Anyone who might be thinking about using Python for an application should seriously think about this. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: pty.spawn directs stderr to stdout
In article [EMAIL PROTECTED], Wilbert Berendsen [EMAIL PROTECTED] wrote: Hi, using pty.spawn() it seems that stderr output of the spawned process is directed to stdout. Is there a way to keep stderr separate and only direct stdin and stdout to the pty? There is, of course. First, you have to decide where you want unit 2 (stderr) to go, and then get the spawned process to redirect it there. If a disk file will do, then your question is just how do I redirect error output to a disk file, in ___ (fill in the blank with language used to implement the spawned process - UNIX shell? Python? C?) More likely, you want the spawned process' error output to go wherever the parent's error output was going. This is a little trickier. Ideally, your spawned shell script can conveniently take a new parameter that identifies the new file descriptor unit number for error output. In this case, use fd2 = os.dup(2) to get a new duplicate, add a parameter like -e str(fd2), and in the spawned process, redirect from that unit - in UNIX shell, exec 2$fd2 Or you could use an environment variable to identify the backup error unit, if the command line parameter option isn't available for some reason. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Orphaned child processes
In article [EMAIL PROTECTED], John Nagle [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I'm using the Python processing module. I've just run into a problem though. Actually, it's a more general problem that isn't specific to this module, but to the handling of Unix (Linux processes) in general. Suppose for instance that for some reason or another, after forking several child processes, the main process terminates or gets killed (or segfaults or whatever) and the child processes are orphaned. Is there any way to automatically arrange things so that they auto- terminate or, in other words, is there a way to make the child processes terminate when the parent terminates? Thank you. Put a thread in the child which reads stdin, and make stdin connect to a pipe from the parent. When the parent terminates, the child will get a SIGPIPE error and raise an exception. John Nagle That could work, but not precisely in that manner. You get SIGPIPE when you write to a closed pipe. When you read from one, you get end of file, i.e., a normal return with 0 bytes. When you test it, make sure to try a configuration with more than one child process. Since the parent holds the write end of the pipe, subsequently forked child processes could easily inherit it, and they'll hold it open and spoil the effect. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Summary of threading for experienced non-Python programmers?
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: Select blocks until the data is ready, while with AIO the i/o happens completely in the background and your process gets an interrupt when the i/o completes. Also, with select based i/o, usually the kernel reads data from the external device into a system buffer, and then you do a read system call that copies the data from the system buffer to your buffer. AIO can be set up so the i/o happens directly into your buffer, avoiding the extra copying. You can also initiate a bunch of different i/o events with a single system call, avoiding some context switches. http://www.ibm.com/developerworks/linux/library/l-async/ describes select as asynchronous, blocking as opposed to AIO which is asynchronous and nonblocking. Other descriptions I've seen reserve asynchronous i/o for AIO-like schemes. It's just a terminological thing. kqueue(2) on MacOS X mentions an EVFILT_AIO option. It isn't supported on that platform, but maybe that's a vestige of some other platform that does support asynchronous, blocking with aio -- as VAX/VMS did (and presumably still does), with event flags. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Summary of threading for experienced non-Python programmers?
In article [EMAIL PROTECTED], Diez B. Roggisch [EMAIL PROTECTED] wrote: systems. (In theory, file input/output should also be available as asynchronous code, but async IO is low-level and not available in Python.) While threads shouldn't be considered a replacement for I suggest you tell that the twisted-guys. And the ones from the built-in asyncore-module. They will be surprised to hear that their years worth of working code will evaporate in a rosa cloud. Diez I appreciate the droll sense of humor, but do you mean to assert that asyncore.py supports asynchronous disk file I/O? What that means to me is, you queue a disk read, and there's an event flag or something that you can wait for before you come back to find the data in your buffer. (That's how I remember it from the old days, when it mattered a little, though not enough that I ever remember actually doing it, and 20 years later I guess the incentive is even less.) I see MacOS supports an F_RDADVISE that might give you a head start on reading into the system buffer, but that's 3rd rate asynchrony because there's no way to know when the data is ready, and 3rd rate I/O because afterwards you still have the copying to do. I don't see even this much in asyncore.py, but I just gave it a glance. thanks, Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: What Programming Languages Should You Learn Next?
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: ... I think it's easier to write complex code in Haskell because: 1) it has a powerful static type system that lets you express important invariants and have them enforced at compile time. This not only catches errors but helps you understand the program logic almost like running the code under a debugger does. If you try to fill a gap by putting in a piece of the wrong shape, it just won't fit and the compiler will tell you what you really wanted. On the other hand, most types are inferred by the compiler, so you don't need a lot of cumbersome declarations like in Java. Worth repeating. One of the perhaps surprising consequences, Haskell code can be very easy to modify. I've been fooling around with computer programs for a couple decades, and I'm just getting used to the idea that I can casually rewrite Haskell code and get the compiler to find what I missed. I have come to feel that the indiscipline of dynamic typing in languages like Python leads to an intuitively surprising rigidity. Ten years ago I would cheerfully accept this, given the meager and clumsy support for static typing in languages like C++, but today, it makes me appreciate Haskell's potential for complex projects. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt should not kill subprocess
In article [EMAIL PROTECTED], Michael Goerz [EMAIL PROTECTED] wrote: But as it seems, a keyboard interrupt will automatically pass down to the subprocesses, causing them to abort. Is there a way that I can prevent the subprocesses from being canceled by a keyboard interrupt? You might try posix.setsid(), from the child fork. The object is to get the child fork out of the foreground process group for the Berkeley terminal driver. This defines who gets signals, when they originate in terminal control keys. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: How to Teach Python Variables
In article [EMAIL PROTECTED], Aaron Watters [EMAIL PROTECTED] wrote: I would try to avoid talking in generalities about python variables versus C or lisp or whatever, unless I was teaching an upper division college programming languages survey class. Instead, I'd fire up the interactive interpreter and illustrate how things work via examples, avoiding the weird cases at all costs. If they ask about the relationship to C or java or whatever I would encourage them to not worry about it, and only go deeper if pressed. I don't know if that explains enough on its own - I suppose it depends on how ambitious your programmer is. But the key point is that by approaching it this way, you're teaching them how to teach themselves as required: write an example, see what happens. A programmer who does this by reflex and remains confused about how the language works is, in my opinion, not going to get very far anyway. (This may have changed somewhat in recent years as more esoteric junk has has been stuffed into the language, I haven't really been keeping track.) In contrast, I suspect that someone who learns Python concepts in terms of explanations like `boxes' or `pointers' or whatnot is at some disadvantage while that lasts, like translating a foreign language to your own instead of attaching meaning directly. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Would Anonymous Functions Help in Learning Programming/Python?
In article [EMAIL PROTECTED],
Cristian [EMAIL PROTECTED] wrote:
...
To someone who's learning to program wouldn't a syntax like the
further give them all they need and also reinforces the idea that
functions are data just like everything else?
my_function = function(foo, bar): pass
an_instance_method = function(self, foo): pass
a_method_declaration = method(self, foo): pass
I think one followup has already alluded to the division
between Python `statements' and `expressions'. The `def'
statement may create and bind a value, but since it's a
statement and not an expression, it doesn't have any value.
Python is not a functional programming language. It probably
could be reinvented to eliminate statements, but ... there
are already plenty of languages to choose from.
If we're going there, though, I think it's obvious that
once you have defined
an_instance_method = function(self, foo): ...
it should be invoked
an_instance_method(an_instance, foo)
which would be much less messy in nested expressions where
the current standard OOP notation flips from right to left
too much ...
string.join(x.split('-'), '').lower()
-- lower(string.join('', split(x, '-')))
It might make for some interesting problems, but that's what
it's about, changing things so it stays fun for everyone.
At the same time, partial function parameter binding should
be implemented, so you could say
dotted = string.join('.')
...
v = dotted(['comp', 'lang', 'python'])
As you probably well know, that isn't my idea, it's a common
functional programming language idiom.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: imaplib Received: header(s)???
Quoth Petri Savolainen [EMAIL PROTECTED]: | Is there a way to get at the Received header(s) or is there something | in imaplib or imap server implementations that hides these? If not, what | IMAP FETCH command should be used? I've used for example | BODY[HEADER.FIELDS (RECEIVED)] and it always returns empty (\r\n). | Despite the Received - header existing, as demonstrated by taking a look | at message sources via desktop email clients. | | I need to get at the Received-for header to figure out at which address | we received an email. We subscribe to a number of mailing lists using | per-mailing-list addresses, and often, To: field contains something else | than our address, thus the need for Received-for. | | Any help would be much appreciated - this is baffling me and I've not | found anything recent that would help. Anything recent? If you're getting IMAP advice from comp.lang.python, I think it's fair to say you will need to be more resourceful. The RFC for IMAP4rev1 should be helpful. I don't know the IMAP to get a single header field, but my guess is that your error is there. Can you retrieve other fields that way? Does the one you're looking for appear in the data if you get the whole header, for example with 'RFC822.HEADER'? It certainly does in my Python IMAP client, and this would have at least helped you refine your question. Donn Cave -- http://mail.python.org/mailman/listinfo/python-list
Re: Who told str() to round my int()'s!!!
In article [EMAIL PROTECTED], A.T.Hofkamp [EMAIL PROTECTED] wrote: On 2007-08-11, Adam W. [EMAIL PROTECTED] wrote: After a fair amount of troubleshooting of why my lists were coming back a handful of digits short, and the last digit rounded off, I determined the str() function was to blame: foonum 0.0071299720384678782 str(foonum) '0.00712997203847' Why in the world does str() have any business rounding my numbers, and how do I get around this? You have got a few good reactions already. What is not mentioned yet however is the difference between str() and repr(). If only it could have stayed that way. Python has two ways to stringify an object: str() is intended to deliver a 'human-readable' representation of its argument, and typically, humans think a few digits of a float is enough. This is precisely the problem with this notion though: you don't have a good way to predict what will be readable (or worse, friendly as people used to say in this context) to a human. Adam W reads the output of str() and it isn't what he expected, though usually it's the other way around where people complain about repr(). More generally, there just isn't any humanity in the way we render objects as text strings, a priori. If there is any such thing, it depends completely on the context. To invite the author of an object to devise a text rendition that will be humane (friendly, readable or whatever) is to waste his or her time. There are better ways to conceive of this str/repr distinction, and they've been discussed to death. python.org documentation will probably never be fixed. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Semantics of file.close()
In article [EMAIL PROTECTED], Evan Klitzke [EMAIL PROTECTED] wrote: ... How do I ensure that the close() methods in my finally clause do not throw an exception? You should take a look at the man pages for close(2) and write(2) (not fclose). Generally you will only get an error in C if you try to close a file that isn't open. In Python you don't even have to worry about that -- if you close a regular file object more than once no exception will be thrown, _unless_ you are using os.close(), which mimics the C behavior. If you are out of space, in C you will get an error returned by the call to write (even if the data isn't actually flushed to disk yet by the kernel). I'm pretty sure Python mimics this behavior, so an exception would be called on the write, not on the close operation. No, he went to the trouble to test this, and he knows how it works. C library I/O can return a disk full error on close, because the last of the buffer will be flushed with write(2), and Python should raise an exception at this point. I don't think there's any remedy for it, other than the obvious - either always flush, or wrap an explicit close in its own exception handler. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] writes: This is interesting. Do you have any references we can read about this assertion -- specifically, that GOTO was not well loved (I assume by the programming community at large) even by around 1966? Dijkstra's famous 1968 GOTO considered harmful letter (http://www.acm.org/classics/oct95/) quotes a 1966 article by N. Wirth and C.A.R. Hoare: The remark about the undesirability of the go to statement is far from new. I remember having read the explicit recommendation to restrict the use of the go to statement to alarm exits, but I have not been able to trace it; presumably, it has been made by C. A. R. Hoare. In [1, Sec. 3.2.1.] Wirth and Hoare together make a remark in the same direction in motivating the case construction: Like the conditional, it mirrors the dynamic structure of a program more clearly than go to statements and switches, and it eliminates the need for introducing a large number of labels in the program. Reference: 1. Wirth, Niklaus, and Hoare C. A. R. A contribution to the development of ALGOL. Comm. ACM 9 (June 1966), 413-432. So, all I need is comments from a computer scientist or two, pointing out problems with the procedural/imperative programming model, and we can establish that it was already hated and on its way out by the late 90's? How about OOP? Already on its way out by the time Python 1.0 hit the streets? The thing that allows us to be so smug about the follies of the past, is that we can pretend everyone knew better. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: Donn Cave wrote: Someday we will look at variables like we look at goto. How very functional. I believe some people naturally think in terms of state transformations and some in terms of functional evaluation. I am pretty firmly in the former camp myself, so variables are a natural repository for state to me. Don't worry - there will be a state transformation monad for you! Nature or nurture? it would be interesting to see some identical twin studies on novice programmers. Since few of us were exposed first to strictly functional programming, though, you have to wonder. In its day, goto was of course very well loved. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: Paul Rubin http://[EMAIL PROTECTED] writes: The idea of designing languages with more and more support for ensuring program correctness is to put the established, repetitive processes into the computer where it belongs, freeing the programmer to be innovative while still providing high assurance of that the program will be right the first time. This seems to make the dangerous assumption that the programmer has the correct program in mind, and needs only to transfer it correctly to the computer. I would warrant that anyone who understands exactly how a program should work before writing it, and makes no design mistakes before coming up with a program that works, is not designing a program of any interest. I don't get it. Either you think that the above mentioned support for program correctness locks program development into a frozen stasis at its original conception, in which case you don't seem to have read or believed the whole paragraph and haven't been reading much else in this thread. Certainly up to you, but you wouldn't be in a very good position to be drawing weird inferences as above. Or you see original conception of the program as so inherently suspect, that random errors introduced during implementation can reasonably be seen as helpful, which would be an interesting but unusual point of view. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
In article [EMAIL PROTECTED], Chris Mellon [EMAIL PROTECTED] wrote: I don't think it's the syntax that keeps people from checking for errors. It's more a difference of error handling philosophy - in Python, if you can't do something sensible with an error you just pretend it can't happen and rely on your caller to do something sensible. In a lot of cases, this means that nobody does anything and errors propagate all the way up and thats fine. What you're describing with the type inference solution feels more like Javas checked exceptions to me, where the compiler ends up signaling an error if you don't pretend like you considered the error condition. In Java, at least, this tends to create actively harmful code where you stick in empty or otherwise useless exception handlers to shut up the compiler, and when can't happen errors actually do occur they are lost or worse. Maybe this doesn't happen in Haskel, but I'd be interested in how it doesn't. As Paul mentioned parenthetically, Haskell's type system doesn't support all this by itself. You can write a function that is defined for only some cases of a value, so indeed you can fail to check for an error status, or match the first element of an empty list, and in general it is quite possible to get a run time error in this way. There is naturally some dissatisfaction with this state of affairs. Another point about this is that a The second point, about syntax and failure handling is another matter. In the example - g1 = re.match(pattern, string) a = g2.group(0) g2 = re.match(template % a, other_string) result = g2.group(1) ... if all these re functions have a monad type that supports it, this would be a sequence of monad bindings with failure options. The algebra of these things is such that a failure short circuits the larger expression just like a false result short circuits evaluation of an and sequence. I wouldn't say this prevents data errors in Haskell, though, it only simplifies them in a sequential computation where such a monad type is convenient. I missed the type error - data error point that this evidently was all supposed to be some response to, and I don't know what that was supposed to mean, but Haskell's type system addresses just what we all would expect, the structural consistency of the program in terms of data types. It doesn't generally prevent data errors or correct your misunderstanding of an algorithm or in general avoid every kind of error. What it does, though, it does rather well. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: Paul Rubin wrote: Steven D'Aprano [EMAIL PROTECTED] writes: As far as I can see, the only difference is that the list comp variable isn't explicitly created with a statement of the form name = value. Why is that a problem? I don't know that listcomp vars are worse problem than other vars; however there is an easy workaround for the listcomp vars so I use it. If there was a way to restrict the scope of other local vars (I gave examples from other languages of how this can be done), I'd use that too. Someday we will look at variables like we look at goto. Maybe we just have different styles, and I naturally tend to write in smaller scopes than you do. I've wondered if programmers might differ a lot in how much they dread errors, or how they react to different kinds of errors. For example, do you feel a pang of remorse when your program dies with a traceback - I mean, what a horrible way to die? Do you resent the compiler's reprimands about your code errors, or nagging about warnings? Maybe the language implementation's job has as much to do with working around our feelings as anything else. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
In article [EMAIL PROTECTED], Paul Boddie [EMAIL PROTECTED] wrote: However, it's interesting to consider the work that sometimes needs to go in to specify data structures in some languages - thinking of ML and friends, as opposed to Java and friends. The campaign for optional static typing in Python rapidly became bogged down in this matter, fearing that any resulting specification for type information might not be the right combination of flexible and powerful to fit in with the rest of the language, and that's how we really ended up with PEP 3107: make the semantics vague and pretend it has nothing to do with types, thus avoiding the issue completely. I missed the campaign for optional static typing, must have been waged in the developer list. Unless it was not much more than some on-line musings from GvR a year or two ago. I don't see how it could ever get anywhere without offending a lot of the Python crowd, however well designed, so I can see why someone might try to sneak it past by pretending it has nothing to do with types. But he didn't -- look at the examples, I think he rather overstates the potential for static typing applications. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Alex Martelli) wrote: Dynamic typing is recommended, they conclude, when programs must be as flexible as possible. I recommend reading the Agile Manifesto to understand why maximal flexibility is crucial in most real-world application programming -- and therefore why, in said real world rather than in the more academic circles Dr. Van Roy and Dr. Hadidi move in, dynamic typing is generally preferable, and not such a tiny issue as they make the difference to be. I guess there may be more than one kind of flexibility. The language I fool around with sometimes that has strong static typing is Haskell. Though a relatively elementary Haskell programmer (the learning curve with this language is something you would have to experience to believe), I feel that the type checking actually helps me program faster. The compiler's check for structural correctness is after all for my benefit, and expedites development and maintenance of code, in my limited experience. The more extensive my changes, the more useful the type checking is - I'm much more casual about significant code revision when writing in Haskell, somewhat more casual when writing in C, and worried when writing Python. This is the kind of flexibility where you make significant changes to something, but the result is as structurally consistent as it would have been if written that way from the start. I have also seen the kind of flexibility where you use expedient hacks to make changes with relatively small amounts of code, and I've seen it in Python applications. It's flexibility when you're doing it, but it paradoxically causes rigidity as the hacks create more points of articulation and more things that aren't obvious to the person making the changes. If that's flexibility, you can have it. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3107 and stronger typing (note: probably a newbie question)
In article [EMAIL PROTECTED],
Bruno Desthuilliers [EMAIL PROTECTED] wrote:
John Nagle a écrit :
Bruno Desthuilliers wrote:
Indeed - static typing is for compilers, not for programmers.
Actually, static typing is for detecting errors before the
program is run.
[EMAIL PROTECTED] ~ $ cat toto.c
#include stdio.h
int main(void)
{
char *toto = (char *)42;
printf(%s, toto);
return 0;
}
[EMAIL PROTECTED] ~ $ gcc -ototo toto.c
[EMAIL PROTECTED] ~ $ ./toto
Erreur de segmentation
[EMAIL PROTECTED] ~ $
You said ?
A discussion about static typing on comp.lang.python is liable
to be a little tiresome even when it isn't conducted on such a
silly level.
The GvR ideas I've seen on V3 typing show some acquaintance with
type inference etc. as used in modern functional languages.
While C++ or Java may represent static typing to Python users,
I don't think there's much risk that they will have anything to do
with static typing in V3, if it's supported in some way.
Secondly, one can reasonably argue that steel toed boots
prevent injuries to the toe, without having to prove that
they withstand a welding torch, a nuclear blast, etc.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: 0 == False but [] != False?
In article [EMAIL PROTECTED], Erik Max Francis [EMAIL PROTECTED] wrote: Donn Cave wrote: Anyone who finds this surprising, might enjoy reading this article from the time several years ago when the feature was being considered. When you have some time - it's long, but interesting. The present confusion is more directly addressed towards the end. Yes, it's the Laura Creighton article again: http://groups.google.com/group/comp.lang.python/msg/2de5e1c8384c0360 If so, be sure to click More options, then View thread, and then read the responses. There were many reasonable objections to her points. Not that it is of no historical interest to review all these reasonable arguments, but allow me to restore the context quote from my follow-up: In article [EMAIL PROTECTED], Paul McGuire [EMAIL PROTECTED] wrote: This has *got* to rank up there among the VFAQ's of them all, along with the mysterious shared default empty list argument. I think this particular question has been asked in one form or another at least twice a week for the past month! Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: 0 == False but [] != False?
In article [EMAIL PROTECTED], Erik Max Francis [EMAIL PROTECTED] wrote: Donn Cave wrote: Not that it is of no historical interest to review all these reasonable arguments, but allow me to restore the context quote from my follow-up: If the counterpoints are of no historical interest, then the original point must be of no historical interest either, since it was not widely granted as true. Not that it is of no historical interest may have been too hard to follow, my apologies. I should have said It may be of historical interest After that, you lost me, but I guess I'm not going to worry about it. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: 0 == False but [] != False?
In article [EMAIL PROTECTED], Paul McGuire [EMAIL PROTECTED] wrote: This has *got* to rank up there among the VFAQ's of them all, along with the mysterious shared default empty list argument. I think this particular question has been asked in one form or another at least twice a week for the past month! Anyone who finds this surprising, might enjoy reading this article from the time several years ago when the feature was being considered. When you have some time - it's long, but interesting. The present confusion is more directly addressed towards the end. Yes, it's the Laura Creighton article again: http://groups.google.com/group/comp.lang.python/msg/2de5e1c8384c0360 Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3131: Supporting Non-ASCII Identifiers
In article [EMAIL PROTECTED], Duncan Booth [EMAIL PROTECTED] wrote: Yes, non-English speakers have to learn a set of technical words which are superficially in English, but even English native speakers have to learn non-obvious meanings, or non-English words 'str', 'isalnum', 'ljust'. That is an unavoidable barrier, but it is a limited vocabulary and a limited set of syntax rules. What I'm trying to say is that we shouldn't raise the entry bar any higher than it has to be. The languages BTW in the countries I mentioned are: in Nigeria all school children must study both their indigenous language and English, Brazil and Uruguay use Spanish and Nepali is the official language of Nepal. [Spanish in Brazil? Not as much as you might think.] This issue reminds me a lot of CP4E, which some years back seemed to be an ideological driver for Python development. Computer Programming 4 Everyone, for those who missed it. I can't say it actually had a huge effect on Python, which has in most respects gone altogether the opposite direction, but it was always on the table and certainly must have had some influence. One of the reasons these initiatives make soggy footing for a new direction is that everyone's an expert, when it comes to one or another feature that may or may not work for children, but no one has a clue when it comes to the total package, sometimes to the point of what seems like willful blindness to the deficiencies of a favorite programming language. If we have a sound language proposal backed by a compelling need, fine, but don't add a great burden to the language for the sake of great plans for Nepalese grade school programmers. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Access to raw command line?
In article [EMAIL PROTECTED], Grant Edwards [EMAIL PROTECTED] wrote: On 2007-04-26, Donn Cave [EMAIL PROTECTED] wrote: One possible way to work around this is to get the raw command line and do the shell expansions ourselves from within Python. Ignoring the question of whether it is worth the trouble, does anybody know if it is possible to obtain the raw (unexpanded) command line? If you're on VMS (well, you didn't say), you're in luck. The UNIX shell has already expanded the file globbing by the time your program starts up, but VMS leaves it to the application, with the help of a handy RMS$ function or two so it gets done in a consistent way. This allows the command line interface to interact with the user in a little more transparent way, since the input seen by the program is congruent with what the user typed in. E.g., rename *.jpeg *.jpg is trivial on VMS, impossible on UNIX. Typing rename '*.jpeg' '*.jpg' is impossible? It is not (of course, nor is implementation impossible), but as noted earlier in this thread it isn't idiomatic. You can present an interface like this to a user who has been specially trained to use it, but no one would naturally expect it to work, without prior instruction, so it isn't any more or less interesting than, say, rename *.jpeg .jpeg. (Oops, now that I think of it, that's what I should have said works on VMS anyway. Been too long.) Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Access to raw command line?
In article [EMAIL PROTECTED], Pieter Edelman [EMAIL PROTECTED] wrote: One possible way to work around this is to get the raw command line and do the shell expansions ourselves from within Python. Ignoring the question of whether it is worth the trouble, does anybody know if it is possible to obtain the raw (unexpanded) command line? If you're on VMS (well, you didn't say), you're in luck. The UNIX shell has already expanded the file globbing by the time your program starts up, but VMS leaves it to the application, with the help of a handy RMS$ function or two so it gets done in a consistent way. This allows the command line interface to interact with the user in a little more transparent way, since the input seen by the program is congruent with what the user typed in. E.g., rename *.jpeg *.jpg is trivial on VMS, impossible on UNIX. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python not giving free memory back to the os get's me in real problems ...
In article [EMAIL PROTECTED], Steven Howe [EMAIL PROTECTED] wrote: Interesting questions. What happens when an object is 'cleaned' up by using the 'del' command. Does the memory space stay in the python process, get handed back to the OS, or some combination of both? I remember 'C' on VMS at least, could be coerced into return memory on block boundaries. 'C++' was suppose to have garbage collect, but I was always doubtful it worked well. Note that UNIX (and VMS) use virtual memory. Real memory space gets handed back to the OS by default -- if you don't use it, you lose it. It isn't coercion, but it does happen on a per page basis, so fragmentation wastes space. If a Python program uses more space than it ought to need, then some knowledge of Python's reference counting allocation scheme will be useful. In particular, you need a fairly good grasp of what a reference is. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Select weirdness
In article [EMAIL PROTECTED], Ron Garret [EMAIL PROTECTED] wrote: The answer is obvious: select is looking only at the underlying socket, and not at the rfile buffers. So... is this a bug in select? Or a bug in my code? Yes. I don't see any specific followup to this point, but it is or at least should be a well known limitation of C library I/O and select. select() is an operating system function that has no way to know the state of your process I/O buffers, nor do the C stdio buffers don't come with a standard way to inspect that state. Therefore, if you mix C I/O with select(), you're more or less out of luck. This applies directly to Python, because it calls the operating system select() function and it uses C stdio buffers for its file object (and entices you to make this mistake by supporting a file object as an input to select().) This conflict can be relieved after a fashion by eliminating the buffer. The now unbuffered C fgets / Python readline won't store extra lines that select can't see, but the semantics of the operation are still a poor fit with the usual application of select. The number of system-level I/O calls is significantly greater as you transfer data one byte at a time, which may add a lot of overhead if you transfer a lot of data, and your readline() function still can't return until it gets that '\n', so a half line can block your application. It isn't a lot of work to read data with operating system functions that are compatible with select - os.read(), socket.recv() - and break it up into lines on your own, and this completely and efficiently resolves the problem. I haven't looked at your code. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: tuples, index method, Python's design
In article [EMAIL PROTECTED], Hendrik van Rooyen [EMAIL PROTECTED] wrote: Donn Cave [EMAIL PROTECTED] wrote: Well, yes - consider for example the tm tuple returned from time.localtime() - it's all integers, but heterogeneous as could be - tm[0] is Year, tm[1] is Month, etc., and it turns out that not one of them is alike. The point is exactly that we can't discover these differences from the items itself - so it isn't about Python types - but rather from the position of the item in the struct/tuple. (For the person who is about to write to me that localtime() doesn't exactly return a tuple: QED) This is the point where the whole thing falls apart in my head and I get real confused - I can't find a reason why, list or tuple, the first item can't be something, the second something else, etc... Of course, you may do what you like. Don't forget, though, that there's no index method for a tuple. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: tuples, index method, Python's design
In article [EMAIL PROTECTED], Alan Isaac [EMAIL PROTECTED] wrote: As I said: I doubt that *anyone* who programs in Python has not encountered the situation where they change a tuple to a list *solely* for the purpose of getting access to the index method. This suggests a missing method, does it not? Who has not done this? Name yourself! I am pleased to find myself in this company. My name is Donn Cave. I have been using Python since version 1.1, though frankly I haven't used it a lot in recent years. I have a confession to make, though. Early in my career, I used to do the opposite - given a list, I would sometimes convert it to a tuple because I had some notion that once its contents were fixed, a list would be more economically and robustly represented as a tuple. This was an error in my thinking, on a couple of levels, and I quit doing that fairly early on. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: tuples, index method, Python's design
In article [EMAIL PROTECTED],
Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-04-11, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED], Antoon Pardon wrote:
On 2007-04-11, Steven D'Aprano [EMAIL PROTECTED]
wrote:
Lists are designed for sequences of homogeneous items, e.g.:
L = [1, 2, 4, 8, 16, 32]
while tuples are designed to be more like structs or records, with
heterogeneous items, e.g.:
T = (Fred, 32, 12.789, {}, None, '\t')
I think you are confused. Last time I heard this homogeneous items stuf,
it had nothing to do with the types being the same. They were homogeneous
because they somehow belonged together and heterogeneous because they
just happened to live together. Similarity of type played no part in
calling the data homogeneous or heterogeneous.
Then you are confused. The typical use case for tuples are database
records. The columns in the table can have completely different types but
the values in a row, represented as a Python tuple, of course belong
together.
Don't blame me. I don't agree with the view. But that was sort of the
explanation that was given here last time I remember this topic came
up in defending why tuples and lists differ in a number of ways that
are less obvious.
They wrote about lists containing homogeneous items and tuples
containing hetergenous items but stressed rather strongly that
this shouldn't be understood in terms of type similarities.
Well, yes - consider for example the tm tuple returned
from time.localtime() - it's all integers, but heterogeneous
as could be - tm[0] is Year, tm[1] is Month, etc., and it
turns out that not one of them is alike. The point is exactly
that we can't discover these differences from the items itself -
so it isn't about Python types - but rather from the position
of the item in the struct/tuple. (For the person who is about
to write to me that localtime() doesn't exactly return a tuple: QED)
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dialog with a process via subprocess.Popen blocks forever
In article [EMAIL PROTECTED], Gabriel Genellina [EMAIL PROTECTED] wrote: En Fri, 02 Mar 2007 14:38:59 -0300, Donn Cave [EMAIL PROTECTED] escribió: In article [EMAIL PROTECTED], Gabriel Genellina [EMAIL PROTECTED] wrote: On http://docs.python.org/lib/popen2-flow-control.html there are some notes on possible flow control problems you may encounter. It's a nice summary of one problem, a deadlock due to full pipe buffer when reading from two pipes. The proposed simple solution depends too much on the cooperation of the child process to be very interesting, though. The good news is that there is a real solution and it isn't terribly complex, you just have to use select() and UNIX file descriptor I/O. The bad news is that while this is a real problem, it isn't the one commonly encountered by first time users of popen. More bad news: you can't use select() with file handles on Windows. Bad news about UNIX I/O on Microsoft Windows is not really news. I am sure I have heard of some event handling function analogous to select, but don't know if it's a practical solution here. If you have no control over the child process, it may be safer to use a different thread for reading its output. Right - `I used threads to solve my problem, and now I have two problems.' It can work for some variations on this problem, but not the majority of them. Any pointers on what kind of problems may happen, and usual solutions for them? On Windows one could use asynchronous I/O, or I/O completion ports, but neither of these are available directly from Python. So using a separate thread for reading may be the only solution, and I can't see why is it so bad. (Apart from buffering on the child process, which you can't control anyway). I wouldn't care to get into an extensive discussion of the general merits and pitfalls of threads. Other than that ... let's look at the problem: - I am waiting for child process buffered output - I have no control over the child process Therefore I spawn a thread to do this waiting, so the parent thread can continue about its business. But assuming that its business eventually does involve this dialogue with the child process, it seems that I have not resolved that problem at all, I've only added to it. I still have no way to get the output. Now if you want to use threads because you're trying to use Microsoft Windows as some sort of a half-assed UNIX, that's a different issue and I wouldn't have any idea what's best. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Dialog with a process via subprocess.Popen blocks forever
In article [EMAIL PROTECTED], Gabriel Genellina [EMAIL PROTECTED] wrote: En Thu, 01 Mar 2007 14:42:00 -0300, [EMAIL PROTECTED] escribió: BUT If I use PIPE for both (so I can .write() on the stdin and .read() from the subprocess' stdout stream (better: file descriptor)) reading from the subprocess stdout blocks forever. If I write something onto the subprocess' stdin that causes it to somehow proceed, I can read from its stdout. On http://docs.python.org/lib/popen2-flow-control.html there are some notes on possible flow control problems you may encounter. It's a nice summary of one problem, a deadlock due to full pipe buffer when reading from two pipes. The proposed simple solution depends too much on the cooperation of the child process to be very interesting, though. The good news is that there is a real solution and it isn't terribly complex, you just have to use select() and UNIX file descriptor I/O. The bad news is that while this is a real problem, it isn't the one commonly encountered by first time users of popen. The more common problem, where you're trying to have a dialogue over pipes with a program that wasn't written specifically to support that, is not solvable per se - I mean, you have to use another device (pty) or redesign the application. If you have no control over the child process, it may be safer to use a different thread for reading its output. Right - `I used threads to solve my problem, and now I have two problems.' It can work for some variations on this problem, but not the majority of them. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: f---ing typechecking
Quoth Paul Rubin http://[EMAIL PROTECTED]: | Donn Cave [EMAIL PROTECTED] writes: | What this proves is that you can implement | an argument list at run time, but it by no means changes the | nature of the argument list as a sequence. | | Right, it's treated as a sequence rather than a record structure. | So is that consistent with the tuples are record structures view, | as opposed to the tuples are immutable lists view? A struct is a sequence, and your stdargs example is a pretty good case in point. When I said the function implemented with stdarg (...) support needs information about its parameters to simulate a normal function, that applies not only to the order of parameters but also their type. Because -- as with structs, but unlike arrays -- the parameter list has variable alignment to accommodate different sized types. So the C parameter list really has every property of a struct -- naturally contains mixed types, has variable alignment, normally accessed by name -- but it does have a defined order, and stdarg is a gimmick that uses it. Order IS the struct property that you get from a tuple, so it is of course important that the tuple is a sequence. The point is not whether it's a sequence or not, but what kind of order it represents. What I'm saying with the evidently overly abstract discussion in previous posts, is that in a struct-like application, a tuple's order is of a different nature than a list. Because in such application, that order is absolute and in a sense atomic. Like a struct. Like an argument list. That's why tuple has different applications than list, that's why it lacks some of the sequential access features that lists have. This must be more obvious in other languages that have a tuple type. None that I know of support so many list or array sequence operations on tuples, and in at least some the struct/record type is implemented by adding names to a tuple but can still be treated as one (like Python's mtime and stat types.) Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Approaches of interprocess communication
Quoth Steve Holden [EMAIL PROTECTED]: | Ben Finney wrote: ... | If a programmer decides on behalf of the user that localhost should | be treated specially, that programmer is making an error. | | Inter-process TCP/IP communication between two processes on the same | host invariably uses the loopback interface (network 127.0.0.0). | According to standards, all addresses in that network space refer to the | local host, though 127.0.0.1 is conventionally used. | | The transmit driver for the loopback interface receives a datagram from | the local network layer and immediately announces its reception back to | the local network layer. Are you saying, in that first paragraph, that if for example I telnet to my local host's external IP address, to a service that bound explicitly to the external interface -- I'll actually be going through the loopback interface anyway, invariably regardless of host network implementation? Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: f---ing typechecking
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: Donn Cave [EMAIL PROTECTED] writes: If t is a valid argument tuple for function f, then can t[1:] also be a valid argument tuple for function f? For ordinary functions without special argument handling, no. We know that without having to know anything about t, and not much about f. This is characteristic of tuple applications. I'm not sure what you're saying. The current situation is if I say def f(*args): print args f (1,2,3,4,5,6,7) f receives a 7-element tuple, but if I say f (8, 9, 10) f receives a 3-element tuple. OK, and of course - f has some implementation which assigns meaning to each parameter, according to its position. - it does this by assigning names to those positions (this isn't essential to my point, but reinforces the struct analogy) For any basic, no-tricks implementation of f, the second application is going to have problems: - fourth and following positions have no actual parameters - if you meant to portray (8, 9, 10) as t[4:], where t is (_, _, _, _, 8, 9, 10), following my proposition above, then it should be clear that inasmuch as t[4] for example has some meaning in terms of f, one cannot preserve this meaning in a smaller slice of t. Please think about it, because I do not intend to try to explain this again. So the parameters of f form a sort of type -- an ordered sequence of values, where each item has a different meaning according to its absolute position in the sequence, and where a name is assigned (by at least f and optionally by its caller) to each position. This type can be represented by many possible values, but we can observe that just as a matter of principle, for any value of this type, a smaller slice is not also of this type. Of course the word type above is about something that is not formally implemented in Python, so you can obtusely quibble about whether it's a type or not, but the constraints are real. I'm asking whether f should receive a list instead. I think that is more in keeping with the notion of a tuple being like a structure datatype. How can there be a structure datatype with an unpredictable number of members? Unpredictable? How do you manage to write functions in this case? Are all your formal parameter lists like (*a), with logic to deal with the variable lengths? But even that wouldn't by itself make your point. Any experienced C programmer is likely to have subtyped a struct, adding one or more values to the end of the parent struct, so the value can be passed to functions that expect the parent type. Variable length isn't strictly foreign to struct types. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 4] Interrupted system call
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: i'm getting the same error when trying to read results from popen2 within a pyQt window. is this a threading issue? is my pyQt window responsible for interrupting the read? i'm fairly new to python so i'm struggling to figure this out. can you recommend any possible methods of preventing this? for instance, could acquiring a thread lock before calling popen solve the problem? No. Did you look at the text of the post you responded to here? What do you think about that advice? Do you have any signal handlers? Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: f---ing typechecking
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: Donn Cave [EMAIL PROTECTED] writes: Unpredictable? How do you manage to write functions in this case? Are all your formal parameter lists like (*a), with logic to deal with the variable lengths? I'm thinking of functions like printf, which take a variable number of args and don't assign them into variables by position. I don't really see why you're thinking of them, but if you look at how they do it, you'll see that they use some run time magic to work as if they were written as conventional functions. This invariably involves some accessory data, like printf's format string, that in effect tells the function its parameter implementation at run time - including number of parameters, since you can't tell even that from standard args data as far as I know. What this proves is that you can implement an argument list at run time, but it by no means changes the nature of the argument list as a sequence. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 4] Interrupted system call
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
i don't have any signal handlers in my code, but i have no idea what
is going on in the internals of the pyQt framework that i'm using for
the GUI.
as far as simply ignoring the exception, that does not seem to work.
for instance, here's some code i've tried:
p = subprocess.Popen('mycommand', shell=True, stdin=subprocess.PIPE,
stdout=subprocess.PIPE, close_fds=True)
output = ''
tries = 0
while tries 12:
try:
tries = tries+1
print retrieving results
output = p.stdout.readlines()
except IOError:
print IOError! try %s % tries
print output:, output
#time.sleep(1)
else:
print Great Success
print output:, output
break
...
if the first try raises an error output does not get set and then the
second try succeeds but returns an empty list when it should return
results. moving the Popen inside the loop isn't an option either,
because, in addition to returning results, the command performs an
action which should only run once.
sorry if i'm missing something obvious here, i'm a python newb.
No, actually this is somewhat non-obvious, if I'm right.
You can't use readlines() like that, it's a Python
thing that evidently loses some or all of its buffered
data, and you start over from scratch.
Instead, probably the simplest thing would be to implement
your own readlines around that restart loop, actually reading
one line at a time and appending to the line list. I'm not
sure that's totally bulletproof - probably will work, but
if you need a sure thing, I would go to UNIX I/O (posix.read),
in a loop, and then split the concatenated results by newline.
Or, of course if you could shut down the signals...
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: f---ing typechecking
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: My original comment was that tuples could be thought of more like C structs or Pascal records. Should f(*args) receive a list rather than a tuple arg? No, clearly not. Function parameters are good example of exactly what tuples are about, with some extra struct/dict stuff for emphasis. If t is a valid argument tuple for function f, then can t[1:] also be a valia argument tuple for function f? For ordinary functions without special argument handling, no. We know that without having to know anything about t, and not much about f. This is characteristic of tuple applications. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: os.popen and broken pipes
In article [EMAIL PROTECTED],
Philipp Pagel [EMAIL PROTECTED] wrote:
Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-02-09, Philipp Pagel [EMAIL PROTECTED] wrote:
for filename in file_list:
file = os.popen('uncompress -c '+filename, 'r')
do_something(file)
file.close()
This works fine for some files but results in
'write error onstdout: Broken pipe'
As far as I can tell, your do_something doesn't consume the entire file.
So you close the file prematurly, which results in the uncompress/zcat
program trying to write to a pipe that is closed on the otherside,
giving you the above message.
You are right: some of the files do not fulfill certain
critereia causing so_somehting() to return before the entire file is
processed.
Most programming environments don't have this problem, though.
If you like, your program can undo what Python does:
signal.signal(signal.SIGPIPE, signal.SIG_DFL)
for filename in file_list:
...
Then it will work as if you had written it in C, or awk
or whatever.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: IOError: [Errno 4] Interrupted system call
In article [EMAIL PROTECTED], Marco [EMAIL PROTECTED] wrote: Hello,every one, I meet a question: in my old script, I usually use os.popen2() to get info from standard unix(LinuX) program like ps,ifconfig... Now, I write a OO-based programme, I still use os.popen2( check whether mplayer still working via ps command ), but some things I got the following message: Traceback (most recent call last): File ./mkt.py, line 351, in loop_timeout self.process(self.event.get_next()) File ./mkt.py, line 361, in process self.player.play(command[1]) File ./mkt.py, line 107, in play if self.is_playing(): File ./mkt.py, line 78, in is_playing info = rfd.readlines() IOError: [Errno 4] Interrupted system call why? Thank you! Some signal was evidently delivered to your process, while you had a slow read in progress (i.e., not from disk.) The read was interrupted to deliver the signal. Look for signal handlers in your code and any library functions you call. I hope library functions don't have signal handlers, sounds like a horrible idea to me. If your code has a signal handler for SIGCHLD, try to get rid of that - the handler itself is causing your problem. OO (Object Oriented?) doesn't have anything to do with the problem, that I can think of. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Repr or Str ?
In article [EMAIL PROTECTED], Johny [EMAIL PROTECTED] wrote: Where and when is good/nescessary to use `repr` instead of `str` ? Can you please explain the differences You expect repr to include information that you might call `meta-data' or `type' -- object class and so forth. To the extent that this is of any interest, it's more or less equally of interest with all objects. If you go to the trouble to support str separately, it's a data conversion and of course should render only the data. An application should be able to use str() to force data to string type (that's what I mean by conversion.) If the object can't sensibly be converted to string type, then normally __str__ is omitted, and defaults to __repr__. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Is any python like linux shell?
In article [EMAIL PROTECTED], James Stroud [EMAIL PROTECTED] wrote: ... Paddy wrote:' Frank, IPython is great, but it is not a replacement for a shell like bash. If you have a Linux system then you still need to know the rudiments of bash Or better yet, csh. ;) Careful, someone will think you're serious. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to find out if another process is using a file
In article [EMAIL PROTECTED], Gabriel Genellina [EMAIL PROTECTED] wrote: Tom Wright [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] I'm writing a program which reads a series of data files as they are dumped into a directory by another process. At the moment, it gets sporadic bugs when it tries to read files which are only partially written. I'm looking for a function which will tell me if a file is opened in write-mode by another process - if it is, my program will ignore it for now and come back to it later. This needs to work on linux and windows. Mac OS would be a bonus too. An os-independent solution would be good, but I could write os-specific options and have it pick the appropriate one. Use os.open with the O_EXCL flag; will fail if the other process has the file still open (and will fail if another process is reading the file, too, not just if someone is writing). O_EXCL fails if the file exists at all - whether closed or open. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: How to find out if another process is using a file
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Nick Maclaren) wrote: In article [EMAIL PROTECTED], Donn Cave [EMAIL PROTECTED] writes: | In article [EMAIL PROTECTED], | Gabriel Genellina [EMAIL PROTECTED] wrote: | Tom Wright [EMAIL PROTECTED] escribió en el mensaje | news:[EMAIL PROTECTED] | Use os.open with the O_EXCL flag; will fail if the other process has the | file still open (and will fail if another process is reading the file, | too, | not just if someone is writing). | | O_EXCL fails if the file exists at all - whether closed or open. Yes. In theory. In practice, it usually works on normal files, provided that all opens are local. Under some circumstances, it will even work for NFS mounted files, as far as I recall. Mm, by fail, I meant An attempt to open with O_EXCL set will fail if the file exists at all, i.e., the file will not be opened, a negative value will be returned, and errno will be set to EEXIST. What I neglected to mention is that this effect obtains when O_EXCL is used in combination with O_CREAT. Without O_CREAT, O_EXCL doesn't mean anything and is ignored. If there is any significant difference between theory and practice in this matter, it's news to me. Donn -- http://mail.python.org/mailman/listinfo/python-list
Re: Non-blocking pipes during subprocess handling
In article [EMAIL PROTECTED], Tom Plunket [EMAIL PROTECTED] wrote: I'm using subprocess to launch, well, sub-processes, but now I'm stumbling due to blocking I/O. Is there a way for me to know that there's data on a pipe, and possibly how much data is there so I can get it? Currently I'm doing this: process = subprocess.Popen( args, bufsize=1, universal_newlines=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) def ProcessOutput(instream, outstream): text = instream.readline() if len(text) 0: print outstream, text, return True else: return False I think it would be fair to say that your problem is not due to blocking I/O, so much as buffered I/O. Since you don't appear to need to read one line at a time, you can detect and read data from the file descriptor without any buffering. Don't mix with buffered I/O, as this will throw the select off. From memory - better check, since it has been a while since I wrote anything real like this (or for that matter much of anything in Python) -- import select def ProcessOutput(instream, outstream): fdr = [instream.fileno()] (r, w, e) = select.select(fdr, [], [], 0.0) for fd in r: text = os.read(fd, 4096) outstream.write(text) Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with imaplib (weird result if mailbox contains a %)
In article [EMAIL PROTECTED],
Antoon Pardon [EMAIL PROTECTED] wrote:
...
$ telnet machine.domain imap
Trying xxx.xxx.xxx.xxx...
Connected to machine.domain
Escape character is '^]'.
* OK maxi Cyrus IMAP4 v2.2.13 server ready
0001 LOGIN ...
0001 OK User logged in
0002 LIST user/cpapen/*
* LIST (\HasNoChildren) / user/cpapen/Out
...
* LIST (\HasNoChildren) / user/cpapen/music - beats
* LIST (\HasNoChildren) / {25}
user/cpapen/newsletters %
* LIST (\HasNoChildren) / user/cpapen/organisatie - structuur
* LIST (\HasNoChildren) / user/cpapen/sociale wetenschappen
{5}\r\nhello\r\n is an IMAP literal. It's unlucky that
Cyrus uses this for some LIST responses and not others, since
that will be a surprise to clients that use ad hoc parsing -
like imaplib users.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: question about True values
In article [EMAIL PROTECTED], Antoon Pardon [EMAIL PROTECTED] wrote: ... I think you are incorrect. Thanks! I rest my case! And how do I express that a number has to be greater than 100 into a Nothing vs Something dichotomy? Declare all greater numbers as Something and the rest as Nothing? Well, would you declare numbers less than 100 False? Think about it in more philosophical terms. What is Truth? The Internet Encyclopedia of Philosophy may be some help with this - http://www.iep.utm.edu/t/truth.htm Then when you get tired of that, suppose that if and while are asking for yes and no, instead of true and false, and ask yourself if we have the philosophical problems with yes that we do with true. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: question about True values
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: ... Maybe so, but that rule (and let's not forget that the zen is not actually a set of prescriptive rules but rather guidelines for the informed) is immediately preceded by the most important rule of all: Beautiful is better than ugly. Nobody will shout at you (well, hopefully, not on this list they won't) for writing if my_list != []: ... in your code, but if they have to incorporate it into their own they will almost certainly reduce it to if my_list: It's just idiomatic in Python, the same way that 'Sup? is idiomatic in English (or what passes for it nowadays ;-) but grates on those who aren't used to hearing it. It is idiomatic, but not _just_ idiomatic. The former requires a list object (or a tricky __eq__()), the latter works with a variety of objects, exhibiting a useful polymorphism. As for similarities between computer programming languages and natural languages, I think that breaks down pretty fast. Part of the problem is something that pinches Python pretty hard right here, a lack of words that conveniently express important concepts in the language. A few posts back, Carl Banks made a distinction between equaling and being, and if I understood that right, it expresses a fundamental notion about the meaning of Python's if, while etc. statements. Unfortunately, though, English conflates existence and identity in this word (be), so it's not going to serve our purposes very well, and when it comes to words like if -- well, we just have to use what we have. If there were better words to use with the notion of something-ness, I think we would see booleans as a silly thing of little use to Python programmers. If you can see if and while as constructs that respond to something-ness, you will appreciate idiomatic Python better, because that arguably is just what it's about. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: question about True values
In article [EMAIL PROTECTED], John Coleman [EMAIL PROTECTED] wrote: Very good point, though one could argue perhaps that when one is comparing an object with a truth value then one is implicitly asking for the truth value of that object On the contrary -- since there is normally no need to ever compare an object with a truth value, then I would interpret this usage as an attempt to distinguish True or False from other objects in general. Some kind of placeholders for missing values, who knows. I'm not saying it's a great idea, but it could work in recent versions of Python. This would make code like 'if s: ' equivalent to 'if s == True:' with a possible gain in readability. But - as you demonstrate the cost of that (minimal) gain in readability would be too high. In any event - I think it is mostly bad style to use a non-boolean variable in 'if s:' - it reminds me too much of obscure C code (though others might disagree). Others will indeed disagree. I don't think you'll find much support for this position. But it's not as bad as your notion that if s == True, where s is not a boolean object, might represent a gain in readability. That really redefines readability. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: using mmap on large ( 2 Gig) files
In article [EMAIL PROTECTED], sturlamolden [EMAIL PROTECTED] wrote: ... It seems that Python does take a length argument, but not an offset argument (unlike the Windows' CreateFileMapping/MapViewOfFile and UNIX' mmap), so you always map from the beginning of the file. Of course if you have ever worked with memory mapping files in C, you will probably have experienced that mapping a large file from beginning to end is a major slowdown. I certainly have not experienced that. mmap itself takes nearly no time, there should be no I/O. Access to mapped pages may require I/O, but there is no way around that in any case. I haven't looked at the source, but I'd be surprised if Python actually maps the file into the process image when mmap is called. I believe Python is not memory mapping at all; rather, it just opens a file in the file system and uses fseek to move around. Wow, you're sure a wizard! Most people would need to look before making statements like that. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Obtaining SSL certificate info from SSL object - BUG?
In article [EMAIL PROTECTED], John Nagle [EMAIL PROTECTED] wrote: The Python SSL object offers two methods from obtaining the info from an SSL certificate, server() and issuer(). The actual values in the certificate are a series of name/value pairs in ASN.1 binary format. But what server() and issuer() return are strings, with the pairs separated by /. The documentation at http://docs.python.org/lib/ssl-objects.html; says Returns a string containing the ASN.1 distinguished name identifying the server's certificate. ... /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign. Note that OU=Terms of use at www.verisign.com/rpa (c)00 with a / in the middle of the value field. ... Is there a workaround for this? Without rebuilding Python and becoming incompatible? As a practical matter, I think it's fairly safe to assume there will be no values that include / in a context like really looks like that X.500 style distinguished name. So if you parse out that string in those terms, and require each of those key = value pairs to have reasonable values - key has no embedded spaces, value has non-zero length - then you should be OK. Re-join any invalid component to its predecessor's value. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: commands.getstatusoutput result is not command line exit value!!!
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: Basically the value you want is shifted up 8 bits. Perhaps I should more understandably have said: 12 8 == 3072 Or as already suggested in other followups, use os.WEXITSTATUS (and os.WIFEXITED.) Not only does this do more precisely the right thing, it will work on any platform that supports a POSIX wait -- which doesn't require that exit == status 8, only that WEXITSTATUS be able to return that value. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about pipes/os.popen
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: [ someone's command that fails, run in popen ] cmd.read() This returns output of . ... I'm not sure what I'm doing wrong here. Probably expecting sudo to read the standard input for its password. Also probably having inflated expectations for popen(), and other related functions for that matter. Where in most Python library functions you can expect an exception when something fails, that doesn't apply to failures in shell commands. Not that it strictly couldn't be done, but on the whole I haven't noticed that anyone cares. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: eval(repr(object)) hardly ever works
In article [EMAIL PROTECTED],
Hardcoded Software [EMAIL PROTECTED] wrote:
Matthew Wilson wrote:
I understand that idea of an object's __repr__ method is to return a
string representation that can then be eval()'d back to life, but it
seems to me that it doesn't always work.
For example it doesn't work for instances of the object class:
In [478]: eval(repr(object()))
File string, line 1
object object at 0xf233e8
^
SyntaxError: invalid syntax
It seems to work for types like integers and dictionaries and lists,
but not for much else.
I don't think that repr() is for eval(). repr() is for outputting a
string that represent the object and is not ambiguous. Example: print
'foo' == print u'foo' but print repr('foo') != print repr(u'foo')
Right, but that eval() idea dies hard. The document excerpt
quoted in an earlier followup, for __repr__, now admits that it
might not be possible ... but then the documentation for __str__
right below it says differs from __repr() in that it does not
have to be a valid Python expression. There's plenty of evidence
in the standard libraries that people understand these two functions,
but they certainly have arrived at that understanding from some
other route than reading the documentation.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Make Object Oriented?
In article [EMAIL PROTECTED], Simon Hibbs [EMAIL PROTECTED] wrote: I can't even vaguely concieve of how such a think could work, even at a trivial, hypothetical level. The code converter would ahve to actualy understand at a general level what the program does and how it does it, then come up with an orriginal way to solve the same problem using a different methodology. As to the simple case, even here, the converter would have to make inteligent decisions. Which methods and properties should it move to the base class, and which should it keep local? What criteria might it use for making such a choice? How could you be sure that the decisions it made would be useful or appropriate? Yes indeed. This must be OO fever in its most rarified form - the notion that even mechanical conversion to OO would be an improvement. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python open a named pipe == hanging?
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Alex Martelli) wrote:
Donn Cave [EMAIL PROTECTED] wrote:
...
I believe your problem is that, by the time you open the
pipe for read, it has already been closed by its writer.
Hmmm, no: the problem is, he never opens the pipe for write, because the
open blocks (will not proceed until somebody opens the fifo for reading,
which in turn won't happen here because the open blocks).
Try:
a = open('my_fifo', 'w')
b = os.popen('cat my_fifo')
a.write ...
a.close()
c = b.read()
this STILL doesn't work, since the very first statement blocks. (I've
also removed the 'r+' mode in favor of 'w', since opening a FIFO for
reading AND writing produces undefined behavior, at least in all Unix
versions and variants I'm familiar with).
But it does work. I edited that excerpt only to complete
missing parts, and ran it on MacOS X and GNU Linux.
import os
f = '/tmp/r'
try:
os.unlink(f)
except:
pass
You forgot to add os.mkfifo(f) here -- so you're writing and reading a
perfectly ordinary file... of course *that* gives no problems!-)
Of course you're right about that, and with that fixed we
see that you're right, the open blocks. In order to avoid
that, you have to open r+, which after all is what the
original post proposed to do.
os.mkfifo(f)
a = open(f, 'r+')
a.write('chunks\n')
b = os.popen('cat %s' % f)
a.close()
c = b.readline()
print repr(c)
And again, if the close() moves up before the cat, there's
no data - the read end has to open before the write end closes.
But I cheated when I replaced read() with readline(). The read end
(cat) doesn't detect the end of file, when there are two processes
involved. On NetBSD, when the child process closes the write
descriptor, that operation doesn't entirely succeed and the file
descriptor is left in a `no more information' state. On Linux,
one doesn't see that, but the result is the same. In any case, a
stream that can't have an end is not going to be very satisfactory.
[I don't know why I get tangled up in these named pipe problems,
when I know better myself than to use them!]
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python open a named pipe == hanging?
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Alex Martelli) wrote:
Donn Cave [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Rochester [EMAIL PROTECTED] wrote:
I just found out that the general open file mechanism doesn't work
for named pipes (fifo). Say I wrote something like this and it
simply hangs python:
#!/usr/bin/python
import os
os.mkfifo('my fifo')
open('my fifo', 'r+').write('some strings.')
x = os.popen('cat my fifo').read()
print x
I believe your problem is that, by the time you open the
pipe for read, it has already been closed by its writer.
Hmmm, no: the problem is, he never opens the pipe for write, because the
open blocks (will not proceed until somebody opens the fifo for reading,
which in turn won't happen here because the open blocks).
Try:
a = open('my_fifo', 'w')
b = os.popen('cat my_fifo')
a.write ...
a.close()
c = b.read()
this STILL doesn't work, since the very first statement blocks. (I've
also removed the 'r+' mode in favor of 'w', since opening a FIFO for
reading AND writing produces undefined behavior, at least in all Unix
versions and variants I'm familiar with).
But it does work. I edited that excerpt only to complete
missing parts, and ran it on MacOS X and GNU Linux.
import os
f = '/tmp/r'
try:
os.unlink(f)
except:
pass
a = open(f, 'w')
b = os.popen('cat %s' % f)
a.write('chunks\n')
a.close()
c = b.read()
print repr(c)
it. (You can't read all the data, though - since you still
have the file open, it has no end of file - so you can't
solve the problem exactly as stated above.)
Actually, in CPython (1.5.2 to 2.5 included, at least), _IF_ open worked
normally then the file WOULD be closed by the statement
open('my fifo', 'r+').write('some strings.')
Sure, but now we're back to closing the pipe before the reader
gets to it. That doesn't work.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python open a named pipe == hanging?
In article [EMAIL PROTECTED],
Rochester [EMAIL PROTECTED] wrote:
I just found out that the general open file mechanism doesn't work
for named pipes (fifo). Say I wrote something like this and it
simply hangs python:
#!/usr/bin/python
import os
os.mkfifo('my fifo')
open('my fifo', 'r+').write('some strings.')
x = os.popen('cat my fifo').read()
print x
I believe your problem is that, by the time you open the
pipe for read, it has already been closed by its writer.
If you contrive to keep the file pointer around until after
the reader has opened it, then you can read some data from
it. (You can't read all the data, though - since you still
have the file open, it has no end of file - so you can't
solve the problem exactly as stated above.)
And the odds are fair that when you get this working, you
will run into some other inconvenient behavior. Named pipes
are a little tricky.
I know I could use a tempfile instead of a fifo in this very
simple case, I just want to know is there a standard way of
handling fifos withing python. Especially the non-trivial case
when I want to call a diff like system program which takes two
files as input. Say I have two python string objects A and B, I
want to call diff to see what is the different between those two
strings, and return the finding as a string obj C back to python.
This certainly can be done in this way:
open('tmpfile1', 'w').write(A)
open('tmpfile2', 'w').write(B)
C = os.popen('diff tmpfile1 tmpfile2').read()
But that's kinda awkward isn't it? :-) The Bash way of doing this
would be (suppose A is the stdout of prog2, B is the stdout of
prog3):
diff (prog2) (prog3) C
What is the best way of doing this in Python?
Version 1. That's also how shell programmers do it, as far
as I know. That bash thing is a neat gimmick, borrowed from
Plan 9's rc, but not a standard shell feature and not needed
for conventional UNIX programming. That's my opinion.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python open a named pipe == hanging?
In article [EMAIL PROTECTED], Rochester [EMAIL PROTECTED] wrote: Thank you for your advise. So, it turns out that fifos are quite useless in Python programming then, which is quite disappointing to me :-( I am not saying that I _have to_ use fifo, afterall it is a rather odd thingy not in fasion since the last iceage... I am just disappointed by the fact that the old plain Bash seems to excel Python in this special aspect. Not by a very great margin, but it is indeed very convenient for process creation and redirection, so when that's the nature of the task, it's likely the right choice. I am new to Python and much more comfortable in Bash programming. A simple Bash script like this would take the advantage of a fifo, hence reduce the overhead of unneccesarry temporary files creation: #!/bin/bash mkfifo my_fifo echo this is a string in my fifo! my_fifo cat my_fifo rm my_fifo Isn't it neat? If you like it, good for you. Do you understand why it works, when your Python one didn't? You put the output in a background process; did it occur to you to try that in Python? Anyway, I think every scripting language has its pros and cons. Bash is probably more flexible in dealing with fifos and multiway pipes (through the magic menchanism of process substitution). Multiway pipes? Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Depricated String Functions in Python
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: Anoop wrote: Thanks Stefen let me be more specific how would i have to write the following function in the deprecated format map(string.lower,list) To avoid the deprecated usage you would use the unbound method of the str type (that's the type of all strings): lst = ['Steve', 'Holden'] map(str.lower, lst) ['steve', 'holden'] Oh, excellent - the string module is dead, long live the string module! I can replace string.join with str.join, and never have to defile my code with that ' '.join(x) abomination. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Coding style
In article [EMAIL PROTECTED], Antoon Pardon [EMAIL PROTECTED] wrote: On 2006-07-19, Donn Cave [EMAIL PROTECTED] wrote: ... http://groups.google.com/group/comp.lang.python/msg/2de5e1c8384c0360 It's lengthy but very readable, and for me it has that quality of exposition where you feel at first reading as though you had already known all that -- even if you really hadn't. Well for me it wasn't, I don't agree with it at all. People sometimes ask, what does `the exception that proves the rule' mean? Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Coding style
In article [EMAIL PROTECTED], Georg Brandl [EMAIL PROTECTED] wrote: Lawrence D'Oliveiro wrote: One of my rules is, always program like the language actually has a Boolean type, even if it doesn't. That means, never assume that arbitrary values can be interpreted as true or false, always put in an explicit comparison if necessary so it's obvious the expression is a Boolean. You can do that, but it's not considered Pythonic. And it might be ineffective. Other than in PHP, Python has clear rules when an object of a builtin type is considered false (i.e. when it's empty). So why not take advantage of this? I don't know whether she would welcome this or not, but here I provide an archive link to a classic post by Laura Creighton on this matter: http://groups.google.com/group/comp.lang.python/msg/2de5e1c8384c0360 It's lengthy but very readable, and for me it has that quality of exposition where you feel at first reading as though you had already known all that -- even if you really hadn't. But I don't know where she is today, or the Python she was writing about. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Coding style
In article [EMAIL PROTECTED], Carl Banks [EMAIL PROTECTED] wrote: 1. This is fine in a perfect world where all code clearly conforms to expectation. Problem is, a lot doesn't. I think it's quite easy to accidentally check something intended as an iterable for emptiness. And, as I've explained in other posts, this can lead to subtle bugs. Whereas if you check for emptiness using len, it throws an exception right away, no bugs. It's safer to use len. (Safest of all is not to check for emptiness at all.) Yes, it's clearly more direct to catch IndexError, than to try to anticipate it. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: How to lock files (the easiest/best way)?
In article [EMAIL PROTECTED],
Elmo Mäntynen [EMAIL PROTECTED] wrote:
On Sat, 15 Jul 2006 23:52:10 +0200, Sybren Stuvel wrote:
Elmo Mäntynen enlightened us with:
Only locally. I want to be able to read/write to a single file from
multiple possibly parallel processes. Would 'touch lock' (or
something like that) work reliably (this just occured to me)?
I use a lock directory for that, os.mkdir('/var/lock/somedir').
If you use a file, you need two steps:
1) Check whether the lock-file exists
2) Create the lock-file
This is not atomic. With a directory, creating it will fail if it
already exists. This means you can atomically check for the lock, and
if it doesn't exist already, you've immediately created it too.
Sybren
Thanks. Is that what atomic basically means?
Yes, and also race condition. That's why Jim Segrave's
example code uses O_EXCL with open(2).
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Coding style
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: tac-tics wrote: ... I'd say the second one. Empty lists are not false. They are empty. Long live dedicated boolean data types. Take them off to where they belong! Tac-tics is right, an empty list is not False. Anyway, just for some variety, I think (2) is preferrable to (1), as is the following while 1: try: lst.pop() except IndexError: break Rather than blindly apply familiar patterns to our work, I think everyone would agree that coding style in matters like this should follow the underlying point of the code. In this case, the body of the test refers implicitly to the length of the list, since .pop() - (list[a], list[:a]) where a is (len(list) - 1) It's therefore quite appropriate for the test to be length. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: References and copying
In article [EMAIL PROTECTED], bruno at modulix [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: ... And I don't understand it. I thought, that b will be a reference to a, so changing b should change a as well. No, you've set the name b to reference a slice of a. Slicing a list always returns a new list. Please verify before asserting: a = [[1, 2], [3, 4]] b = a[1] b is a[1] True id(b) 46912496915448 id(a[1]) 46912496915448 You're right - he actually didn't set the name b to reference a slice of a. But if he had - slicing a list does return a new list. Indexing, as in the example, returns the item object. Or, binds a reference to the left hand side identifier, whatever, but there is no way to bind anything to the list location. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Select hangs after some reads
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: The PSH flag indicates that the data stream must be flushed right through to the other end. This is essential for interactive protocols such as FTP: without it the server has no way to know that the client has sent a complete command, and vice versa. So you would expect to see this done explicitly in the source for an FTP client or server implementation -- something that sets this PSH flag or else the protocol won't work? Or am I misunderstanding what you mean? I don't see that specific string anywhere in a the particular FTP implementation whose source happened to be handy, basically a Berkeley 4.4 variant as I think most are on UNIX. Somewhere around here I have a pass-through FTP client/server application that adds GSSAPI-Kerberos5 authentication to the protocol traffic, and I don't remember needing to do any such thing there. I'd have to look harder at the details, but as I recall it, like any sane application the protocol is defined in terms of data, so you know if you have a complete command by looking at what you have. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: os.chdir doesn't accept variables sometimes
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
#!/usr/bin/python
from os import *
chdir(/home/chainlynx/Desktop/Music)
for artist in listdir(getcwd()):
print ===ARTIST: +artist
chdir(artist)
for album in listdir(getcwd()):
print ---ALBUM: +album
print CWD: + getcwd()
chdir(album) ##ERROR ON THIS
LINE
for string in listdir(album):
...
Traceback (most recent call last):
File /home/chainlynx/workspace/PyTest/src/pypack/__init__.py, line
12, in ?
for string in listdir(album):
OSError: [Errno 2] No such file or directory: 'Album1'
To start with, note that your traceback implicates the listdir()
on line 12, not the chdir() before it. This listdir() uses the
same parameter as that preceding chdir(), that appears to be your
problem.
One of your problems, anyway. You're doing a lot of downwards
chdirs, but no upwards, which is going to limit the extent of
your directory traversal.
The from os import * is a terrible idea, where did you get that?
os has a lot of identifiers in it that tend to collide with other
namespaces. open is a classic example. Don't do that, with os
or generally any module.
As a more general direction, it would be a good idea to look
into standard library functions, e.g., os.path.walk
P.S. Bonus points: is there any way to bash shell script this on the
command line instead (recursively)?
Depends on what you want it to do, but maybe something like
find . -name \*.mp3 -exec $HOME/bin/cvt .mp4 {} \;
where cvt would be something like
#!/bin/sh
case $1:$2 in
.mp4:*.mp3) mp3_to_mp4 $2 ${2%.mp3}.mp4 ;;
...
You'd have to think about it.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: [fcntl]how to lock a file
In article [EMAIL PROTECTED], marcello [EMAIL PROTECTED] wrote: Carl J. Van Arsdall wrote: [...] If you end up having problems working with the python fcntl module let me know your configuration I'd be interested to see if anyone else had similar problems to me. Python 2.2.3 (#1, Aug 8 2003, 08:44:02) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-13)] on linux2 kernel 2.4.21-4.0.1.ELsmp glibc-2.3.2-95.6 What else can i add? Maybe something about the problem? There are four functions in that module - fcntl, flock, ioctl, lockf. Which one were you using? What were you trying to do with it? Did it raise an exception? Returned but didn't effectively interlock against other processes -- on the same host, on other hosts? Failed to return when the file should have been OK to lock? Is it possible that locks would work fine in a test program, but fail in your application due to brain damaged POSIX filesystem locking semantics? We can start with stuff you probably already know. - The Berkeley flock(2) function is great but is not supported by NFS. - fcntl(2) F_SETLK etc. are supported by NFS, but have extremely inconvenient semantics, part of the POSIX 1003.1 specifications, particularly the part about losing a lock on ANY close(), even if the file descriptor remains open for fcntl(2)'s caller. - lockf(3) is fcntl(2). - Some platforms provide an flock() that is actually fcntl(2), can't think of the right words to express how deplorable that practice is. - On the rare platform that doesn't do this - where they are honest enough to just admit that they don't support flock() - Python implements fcntl.flock() with fcntl(2), I guess on the theory that you can't have enough brain damage. The worst case would be if Python's configure missed a bona fide flock(2), which is unlikely but may be worth checking if you use flock(2) for a reason. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did someone write this?
In article [EMAIL PROTECTED], Sandra-24 [EMAIL PROTECTED] wrote: I can't believe I missed it in the documentation. Maybe it wasn't in the offline version I was using, but more likely it was just one of those things. So the trouble seems to be that the traceback holds a reference to the frame where the exception occurred, and as a result a local variable that references the traceback in that frame now holds a reference to it's own frame (preventing the frame from being recliamed) and can't be cleaned up prior to python 2.2 with GC enabled. Which means it's fine to hold a reference to the traceback in a frame not in the traceback, or (I think) to create a temporary unamed reference to it. I don't think that's exactly it - the problem wasn't exactly circularity, and GC wouldn't help. But as I try to write a test program that demonstrates, it looks like current versions of Python have done something with sys.exc_traceback that avoids at least some of the problems. import sys class A: def __del__(self): print 'A.__del__' def f(): a = A() try: xyz except: print 'caught expected error' print 'returning from f' return sys.exc_traceback t = f() print 'Done' In order to get the traceback to preserve a past its natural lifetime, I had to return it to the caller, because today sys.exc_traceback disappears when f() returns. But it shows the effect on order of execution: 'A.__del__' will appear after 'Done', when it should appear before it. When I did this (sys.exc_traceback = None), the applications used a terminal graphics library, like curses, and I often depended on finalization (__del__) to run the close rendering for a graphic element. Worked fine until an exception, so I add this precaution to every I/O flush. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Capturing stdout without waiting for the process end
In article [EMAIL PROTECTED], Luigi [EMAIL PROTECTED] wrote: The question is that I have a C program (by third part) that streams the logs into the stderr and stdout devices. I need to create an envelopment that captures the outputs and puts them in a file generating log events (for a real-time view). As suggested in another followup, the C program's output will probably be block buffered when its output is a pipe. In this case, you'll get output only when the buffer is full, or when the program exits. If the program can be modified, it only needs to flush stdout after each output event. Otherwise, you need to use a device that looks like a tty, just so the C stdio library will switch to line buffering as it generally does with terminals. This is called a pseudotty. It's a little more difficult to use than a pipe, but you can probably get something going with openpty or forkpty from the os/posix module, or there may still be 3rd party packages for this. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Redirect output
In article [EMAIL PROTECTED], abcd [EMAIL PROTECTED] wrote: I have a program which is written in C and interfaced with python via Swig. However, the function I call prints stuff out to the console. I would like to capture what it is printing out. I tried: [code] import MyCProg, sys f = open(tmp.txt, wb) sys.stdout = f MyCProg.getData() f.close() sys.stdout = sys.__stdout__ print open(tmp.txt, rb).read() [/code] However, it just prints the data to the screen. I tried redirecting stderr as well. other than modifying the C code and re-generating the interface via Swig, any ideas? just asking before i have to do that. As you probably surmised, C I/O doesn't notice when you've swapped the stdout object in the Python sys module. If that's what you're trying to do, redirect the output of something like printf() or puts(), then you might look at the os.dup2() function as a way to redirect unit 1. Get the new output unit from os.open() with os.O_CREAT plus whatever other flags, or open the output file some other way that creates a file object and use its fileno() function. Flush stdout before each dup2(). To revert back to the original stdout, you will want a copy of that stream, which you can get with the os.dup() function, prior to redirection. All the left over file descriptors can be closed afterwards. I assume you're on a UNIX platform or something to that effect. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: access mbx files?
Quoth David Isaac [EMAIL PROTECTED]: | Donn Cave, [EMAIL PROTECTED] | I suppose it isn't supported by the mailbox module basically because | it isn't all that commonly encountered. It may be more common on mail | servers, but there it's email net protocol data, POP or IMAP. If | Mahogany has been using this format for `local' folders (i.e., via | filesystem), I think that may have been kind of poor judgement on the | part of its developers. | | I cannot judge that, although I think I recall the choice was made | for reasons of speed. What do you see as the downsides? | Just that it is uncommon (and thus questions like my original | questions arise)? That's one problem, it's inaccessible to a wide variety of email software you might want to run. Maybe worse, it's fragile. It has, for no particular reason, a header full of NUL bytes, which some editors will through away. Any change to contents without the corresponding change to the header destroys the folder past that point. Etc. And for all that, it doesn't buy you much. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference between 'is' and '=='
In article [EMAIL PROTECTED], Diez B. Roggisch [EMAIL PROTECTED] wrote: ... So - your conclusion is basically right: use is on (complex) objects, not on numbers and strings and other built-ins. The exception from the rule is None - that should only exist once, so foo is not None is considered better style than foo == None. But even better style is just `foo' or `not foo'. Or not, depending on what you're thinking. The key point between `is' and `==' has already been made - - use `is' to compare identity - use `==' to compare value It's that simple, and it's hard to add to this without potentially layering some confusion on it. While Python's implementation makes the use of identity with small numbers a slightly more complicated issue, there isn't a lot of practical difference. To take a common case that has already been mentioned here, if I define some constant symbolic values as small integers, as long as I take care that their values are distinct, I can reasonably use identity and ignore this technical weakness. I can assume that no one is going to supply randomly selected integers in this context. Meanwhile, the use of identity clarifies the intent. Depending, of course, on what the intent may be, which brings us to None, and a point about values in Python that was brought to a fairly brilliant light some years back by someone we don't hear from often here any more, unfortunately. - use `is' to compare identity - use `==' to compare value - use neither to test for `somethingness' I'm not going to try to elucidate the theory of something and nothing in Python, but suffice it to say that there are places where it may be better to write if not expr: than if expr is None: or worse yet, if expr == False: That's what I think, anyway. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: access mbx files?
Quoth David Isaac [EMAIL PROTECTED]: | Alan Isaac [EMAIL PROTECTED] wrote in message | news:[EMAIL PROTECTED] | Should I be able to access mail messages in Mahogany mail's mbx | format using the Python mailbox module? If so, can someone | please post a working example? If not, can you please | point me to documentation of the file format or better yet | Python code to parse it? | | OK, from what I have been able to learn (not a lot), | my original question may boiled down to: | has anyone wrapped the cclient library for Python? ... | Will I need to pursue this, or is this functionality | somewhere in the mailbox module. (And if not, | can someone please explain why not?) In the end it depends on what you want to do. But to simply read the messages out of an MBX format folder, without necessarily accounting for concurrent access from other applications, c-client is overkill. If you look at the folder file - after the 4K header (2K? I forget), the structure is 1-line-headermessage, and the header doesn't carry a lot of information that's of supreme importance. The one thing you want to extract from it is the length field, which allows you to index to the next header. The message data is CRLF. As far as I can recall, that's all there is to it. I suppose it isn't supported by the mailbox module basically because it isn't all that commonly encountered. It may be more common on mail servers, but there it's email net protocol data, POP or IMAP. If Mahogany has been using this format for `local' folders (i.e., via filesystem), I think that may have been kind of poor judgement on the part of its developers. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: don't understand popen2
Quoth gry@ll.mit.edu: | Martin P. Hellwig wrote: ... | import popen2 | | std_out, std_in = popen2.popen2(testia.py) | | x=std_out.readline() | print(x) | | std_in.writelines(notgood) | | x=std_out.readline() | print(x) ... | Traceback (most recent call last): |File F:\coding\pwSync\popen_test\popen_test.py, line 8, in ? | std_in.writelines(notgood) | IOError: [Errno 22] Invalid argument | ... | You gave it a single string, not a list(sequence) of strings. Try | something like: | std_in.writelines([notgood]) Did you try it? For me, writelines(string) works fine. Since in Python, a string is in a sense a sequence of strings, this doesn't even really contradict the documentation - | ... The sequence can be any iterable object producing strings. Anyway, it seems unlikely he would get that INVARG error for this reason. That's an error from the host operating system, not the interpreter, and it mostly likely refers to the file descriptor. Since it works for me, I guess his problem is basically this: | (python 2.4 + win32 extensions on XPProSP2) Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: IMAP Checking Folder Size
In article [EMAIL PROTECTED], Kevin F [EMAIL PROTECTED] wrote: I'm trying to use the following code to get my remote server's folder size information. Unfortunately, i'm getting the error: Traceback (most recent call last): File /Life/School/Homework/Spring 2006/OPIM 399/Tutorial/IMAP/mailboxsize.py, line 23, in -toplevel- number_of_messages_all += int(number_of_messages[0]) ValueError: invalid literal for int(): The requested item could not be found. ... # Select the desired folder result, number_of_messages = M.select(mailbox, readonly=1) number_of_messages_all += int(number_of_messages[0]) A general observation about imaplib, the caller usually has some analysis to do on the returned data. For example, you have to check that `result' value, before you can assume that you got the data you asked for. I would suggest that you print these values out somewhere, it will put you in a position where you can probably answer your question better than we can. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Bidirectional communication over unix socket (named pipe)
In article [EMAIL PROTECTED], J Rice [EMAIL PROTECTED] wrote: The problem I have is that the client can send to the server, but the server can't send back to the client because it gets this error: socket.error: (107, 'Transport endpoint is not connected') This is despite the client waiting on a socket.recv() statement. Is the client really not connected, or is the server unaware of the connection? And how do I fix this? You can either connect() as well as bind(), or use sendto(data, file) Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Bidirectional communication over unix socket (named pipe)
In article [EMAIL PROTECTED], J Rice [EMAIL PROTECTED] wrote: Hi Donn, Not sure I fully understand your suggestion. bind() only works once -- I can't bind again in the client. Same thing with connect() -- once I issue a connect in the server, it rejects it in the client. Doing this as a stream works for what I want, but I would like to understand why it didn't work with datagram. Right, bind should be on one end only, as it creates the actual socket file. Connect works on either end, with SOCK_DGRAM. From man 2 connect: The parameter s is a socket. If it is of type SOCK_DGRAM, this call specifies the peer with which the socket is to be associated; this address is that to which datagrams are to be sent, and the only address from which datagrams are to be received. If the socket is of type SOCK_STREAM, this call attempts to make a connection to another socket. However, even if we're straight on this, I confess I have only addressed your question about the unconnected endpoint. The other part of the problem remains, as I don't know how to get data to actually go both ways. I was a little surprised by this, and have not been able to scare up any explicit documentation, but the only example program I could find for two-way UNIX domain datagram IPC, uses two sockets, not one - http://docs.hp.com/en/B2355-90136/ch07s06.html Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: os.execve(pth,args,env) and os.chroot(pth) = problems
In article [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... It seems me that the os.chroot() call is messing up the os.execve() (which executes the cgi script). os.execve(pth, args, envVariables) is only executed if os.path.exists(pth) returns True. But when I run a CGI script that os.path.exists(pth) returns True for, then os.execve(pth) python throws back the error: File /***/***/***/Unpriv.py, line 201, in execCGI OSError: [Errno 2] No such file or directory However I don't see how this is possible if os.path.exists(pth) returns True, why is it os.execve() has problems finding it. I haven't used chroot enough to know all the pitfalls, but here's one guess: suppose the CGI script file `pth' might actually be a script, with a `#!' top line that points to an interpreter that isn't there, in your chroot space? Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Type Hinting vs Type Checking and Preconditions
In article [EMAIL PROTECTED], Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: You can look at this, its API looks very well thought out to me: http://oakwinter.com/code/typecheck/ Now, on the other hand, if we were to introduce a purely optional type hint to the function prototype, such as follows: def multiplyByTwo(value:int): return value * 2 I don't think Python will have something like this... It's actually something that has been being considered for Python 3.0 for a long time. Search for `python optional static typing` for discussions - the first two links from Google are blog entries by Guido from a year ago (there's also a third one linked from PEP 3000). But surely, never with the proposed semantics (quoted to match [non]attribution), with automatic conversion of 14 to 14 -- The python interpreter could do the work of casting the incoming parameter to an int (if it is not already) before it is multipled, resulting in the desired result or a typecasting error otherwise. Furthermore, it could do it more efficiently than a developer having to put conditional code at the beginning of traditionally typecasting functions. I know awk works a bit like that, maybe Perl? but it's surely way out of place in Python. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: os.popen3 delivers no error exist status ?
In article [EMAIL PROTECTED], robert [EMAIL PROTECTED] wrote: os.popen3 delivers no error exit status on .close() - while os.popen does Is this intended or a bug? How do I get the status? http://docs.python.org/lib/popen3-objects.html Worth reading the rest of the documentation about these functions, too. They are not just like popen. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Quoth Steven D'Aprano [EMAIL PROTECTED]: ... | Do you honestly believe that the CPU doesn't have to interpret the machine | code, or are you just deliberately playing silly buggers with language? I don't care whether the CPU has to interpret machine code. Are you suggesting that we might in normal conversation wish to use the term interpreter to mean CPU, like what kind of interpreter does your computer have?, that kind of thing? | Your paragraph above that starts with No of course not, | even omits a point that everyone understands, you can in | fact expect a .py file will work independent of machine | architecture - like any interpreted language. | | Amazing. In your previous post you were telling everybody how the | *disadvantage* of interpreted programs is that they won't run unless the | interpreter is present, and in this post you are telling us that | interpreted languages will just work. What happened to the requirement for | an interpreter? Look, this is my last post on this matter, because you have evidently reached a point where every statement has to be spelled out in excruciating detail to avoid absurd interpretations. will work independent of machine architecture does not declare that it is absolutely guaranteed to work - after all, it may have some other flaw that will prevent it from working anywhere. It just says that if it doesn't work, it isn't because it tried to execute on the wrong machine architecture - the file is machine architecture independent. You know that, you know I know that. What is the fucking problem? | In order to force interpreted language and compiled language into two | distinct categories, rather than just two overlapping extremes of a single | unified category, you have to ignore reality. You ignore interpreted | languages that are compiled, you ignore the reality of how machine code is | used in the CPU, you ignore the existence of emulators, and you ignore | virtual machines. Anyone with an interest in computer programming is likely to know what microcode means, that there are emulators, virtual machines, etc. You might find the UCSD Pascal system interesting, to harken back to the early days of my experience with computers, a fascinating twist on the interpreted/compiled story. Interesting as perspective, but it wouldn't change the way we apply these words to Python. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
In article [EMAIL PROTECTED], Steven D'Aprano [EMAIL PROTECTED] wrote: ... Hey Donn, here is a compiled program for the PowerPC, or an ARM processor, or one of IBM's Big Iron mainframes. Or even a Commodore 64. What do you think the chances are that you can execute it on your x86-compatible PC? It's compiled, it should just work!!! Right? No of course not. If your CPU can't interpret the machine code correctly, the fact that the code is compiled makes NO difference at all. In other words, I have three choices: - cross my fingers and hope that you have the required interpreter (CPU); - slip in an interpreter install (perhaps an emulator) and hope you won't notice; - or come clean and tell you that my program needs an interpreter (Hey Donn, do you have a Mac you can run this on?) and you should check to see that you have it. Sure, all this is true, except for the term interpreter. You would surely not use the word that way, unless you just didn't want to communicate. Your paragraph above that starts with No of course not, even omits a point that everyone understands, you can in fact expect a .py file will work independent of machine architecture - like any interpreted language. We all know what native code compilation buys you and what it doesn't. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
In article [EMAIL PROTECTED], Chris Mellon [EMAIL PROTECTED] wrote: ... They won't say Java. Ask them why Python is interpreted and Java isn't and you'll have a hard time getting a decent technical answer, because Python isn't all that different from Java in that regard, especially pre-JIT versions of Java. For me that would be partly because I don't know that much about Java, honestly. Just searching at random for something about the subject, I cam across this - http://www-128.ibm.com/developerworks/java/library/j-native.html?loc=j - which seems like it might be of some interest here. My impression from reading this is that Java actually can be compiled to native code, though in 2002 this was relatively new. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a way to build python without 'posixmodule' ?
In article [EMAIL PROTECTED], mrstephengross [EMAIL PROTECTED] wrote: libpython2.4.a(pystate.o)(.text+0x1e0): In function `PyThreadState_New': C:/cygwin/home/Administrator/sgross/sage/installer/python/i386-mingw-gcc/Pytho n-2.4.2/Python/pystate.c:191: undefined reference to `_PyGILState_NoteThreadState' === It would seem that the python executable is looking for the process management functionality that *would* have been supplied by posixmodule.o. Why would it seem that? Look for a recent thread here about porting Python to LynxOS. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Quoth Carl Friedrich Bolz [EMAIL PROTECTED]: | Torsten Bronger wrote: | Well, I think that it's fair to say that there are by principle deep | run time differences between CPython and, say, a typical | C++-compiled program. Your definition would not reproduce that. I | think it's also fair to say that these differences should be known | if somebody tries to find the best tool for a job. After all, they | include advantages, too. | | My definiton would be that an interpreted language has in its | typical implementation an interpreting layer necessary for typical | hardware. Of couse, now we could discuss what is typical, | however, in practice one would know it, I think. In case of Python: | CPython and all important modern processors. | | Well, if we take any modern Intel/AMD chip (which could be described as | typical), a C++ program would fit the interpreted definition, since | the processor does not execute the machine code directly but rather | breaks it down into smaller microcode instruction -- a process that | could be described as intepretation. That's irrelevant, though. Note, has in its typical implementation. Your processor didn't come along with your C++ compiler, it's not part of its implementation or even necessarily relevant to it - maybe some potential for optimization, but the only hard and fast requirement is that the processor must execute its instruction set as documented. The reason this isn't just an abstruse philosophical argument where it makes sense for us to obtusely cling to some indefensible point of view, is that as the man points out, there are differences that we can't hide forever from potential Python users. The most obvious to me is that your Python program essential includes its interpreter - can't go anywhere without it, and any change to the interpreter is a change to the program. There are various strategies to address this, but pretending that Python isn't interpreted is not one of them. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: why does close() fail miserably on popen with exit code -1 ?!
Quoth Atanas Banov [EMAIL PROTECTED]:
| i ran onto this weirdness today: seems like close() on popen-ed
| (pseudo)file fails miserably with exception instead of returning exit
| code, when said exit code is -1.
|
| here is the simplest example (under Windows):
|
| print popen('exit 1').close()
| 1
| print popen('exit -1').close()
| Traceback (most recent call last):
| File interactive input, line 1, in ?
| IOError: (0, 'Error')
| print popen('exit -2').close()
| -2
|
| has anyone have idea why is that?
I have no idea about Microsoft Windows, and I doubt that you could
reproduce this on UNIX, but neither does this look like a valid
UNIX program. Exit codes are integer values in the range [0..255],
so there are no negative numbers (which is what I think you intended),
nor are there strings (which is what '-1' would have been with the
classic UNIX shell.)
So I will leave it to someone else to wrestle with the Microsoft
problem, but I just wanted to point out that it isn't something you
could expect to work anywhere else.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Quoth Alexander Schmolck [EMAIL PROTECTED]: | Bruno Desthuilliers [EMAIL PROTECTED] writes: ... | bash is a scripting language for *n*x systems. javascript is a scripting | language for web browsers. VBScript is a scripting language for MS | applications. | | Python is also a scripting language for *n*x systems and various applications. | | A scripting languagee is a language whose main purpose is to be embbeded in an | application to provide the user a way of programmaticaly automate some tedious | tasks. | | A few lines ago bash was also a scripting language but I can't personally | recall ever seeing bash embedded in some application. UNIX! The Bourne shell is exactly what M Desthuillers describes, for the UNIX operating system. Python isn't at all - not that you can't rename a file, change working directory, execute some processes and do all that stuff from pure Python, but there's a clear difference in focus. Those things the shell does rather well, at anything else it's pathetic. Of course, scripting is naturally the domain of interpreted languages, and most scripts are trivial in size and complexity. I guess this is why for some people, scripting language just means interpreted and suited to writing trivial programs. It's hard to believe they're thinking very hard about what they're saying, but so what's new? Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Quoth Steven D'Aprano [EMAIL PROTECTED]: ... | Nobody denies that Python code running with no optimization tricks is | (currently) slower than compiled C code. That's a matter of objective | fact. Nobody denies that Python can be easily run in interactive mode. | Nobody denies that *at some level* Python code has to be interpreted. | | But ALL code is interpreted at some level or another. And it is equally | true that at another level Python code is compiled. Why should one take | precedence over the other? I have no idea, what precedence? All I'm saying is that Python matches what people think of as an interpreted language. You can deny it, but but it's going to look like you're playing games with words, and to no real end, since no one could possibly be deceived for very long. If you give me a Python program, you have 3 choices: cross your fingers and hope that I have the required Python interpreter version, slip in a 25Mb Python interpreter install and hope I won't notice, or come clean and tell me that your program needs an interpreter and I should check to see that I have it. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python vs. Lisp -- please explain
Quoth Alexander Schmolck [EMAIL PROTECTED]: | Fredrik Lundh [EMAIL PROTECTED] writes: ... | the only even remotely formal definition I've ever seen is language with | designed to script an existing application, with limited support for handling | its own state. | | Early Tcl and JavaScript are scripting languages, Python is not. | | Right. Which shows that by this definition scripting language is not a | meaningful and useful concept. No one will understand you correctly when you | refer to scripting language and mean only something like the above -- and | unless you spend a lot of your time talking about early tcl and early | javascript I doubt you'd need a word for it, either. Oddly enough, that's what I understand it to mean, too, so you can't strictly say no one. On the other hand, I think it's obvious that a language like Python could be used for scripting, without having been specifically designed for it as described above. There's an ambiguity in the phrase, out of context - I can say Python can serve as a scripting language for some applications, but not Python is a scripting language!, since its place in the taxonomy of languages would be somewhere else. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: A way to discover PIDs of child processes?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Now, because the command is executed in the shell, I end up with the following process tree: PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 233231562332 3412 con 1012 15:34:11 /usr/bin/python2.4 306823322332 2268 con 1012 15:34:11 /usr/bin/sh 158430682332 2620 con 1012 15:34:12 /cygdrive/c/GNATPRO/5.01 a/bin/powerpc-elf-gdb It doesn't always have to be that way, depending on the nature of the command. If it's the last thing the shell has to do, then it can be exec'ed without a fork, which leaves the gdb image running in the immediate child process. Some shells do that automatically. In any case, a Bourne shell exec statement will do it, like exec /.../gdb, with whatever redirections etc. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Exiting os.spawnv's subroutine
In article [EMAIL PROTECTED], IamIan [EMAIL PROTECTED] wrote: I am using os.spawnv in Python 2.1 to do some geoprocessing in a subroutine/process. Everything works great, except when the processing is done the subroutine just waits for a couple minutes before closing itself and returning to the main script. I have tried using sys.exit() and exit() but these aren't doing anything. What is the proper way to terminate this subroutine upon completion, rather than waiting? Thank you. Your description is a little ambiguous, but my guess is your process just isn't done when you think it is. It's flushing data to disk or something like that. Or it could be something else. Why don't you write a sample program that works like this, and demonstrates the problem, and then we'll know. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: How to run shell commands within python
In article [EMAIL PROTECTED], Fredrik Lundh [EMAIL PROTECTED] wrote: (also note that most trivial shell commands are better done in python. most uses of cat, for example, can be trivially emulated with one or two lines of python...) Though the knowledge required to do this may be more trivial for some of us than others! cat probably doesn't have much going for it that a naive implementation would miss - some versions will recreate holes, but most applications will never miss this. You can replace mv with os.rename() if you don't care that it will fail when the destination is on a different filesystem. Etc. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
