Re: Py3K idea: why not drop the colon?
Robert Kern wrote: > Michael Hobbs wrote: > >> True enough. Although, I have to ask how many times you define a new >> function only to have Python spit a syntax error out at you saying that >> you forgot a colon. It happens to me all the time. (Usually after an >> "else") If you'd never notice that the colon was missing if the compiler >> didn't point it out, is it really that readable? For me, I tend to get >> annoyed at language "features" that I'm constantly tripping over. >> > > Never. > Now I see where we disagree. Also gaging from everyone else's reaction, I must have some strange no-colon circuitry wired into my brain. I guess that's it then, - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Robert Kern wrote: > Michael Hobbs wrote: > >> In the end, I have to admit that I really couldn't give a flying frog if >> the colon is there or not. It's just a colon, after all. I *was* hoping >> that I could convince someone to honestly think about it and consider if >> the colon is really that noticeable. But so far, the only response that >> I've received is that there's that ABC study somewhere and that settles >> that. >> > > Empirical usability research carries a lot of weight. Certainly more so than > projection of personal preferences. > Yes, but all we have is a passing mention of it in the FAQ. If someone could actually find the full content of the study and show that it is [still] relevant to Python, I'd give it a lot of weight too. As it stands, I've become far too jaded by so-called "studies" (both technical and medical) to accept them on blind faith. > But for what it's worth, my personal preference is that having the colon is > more > readable. Yours isn't. That's fine. Debating on that basis, however, is pretty > pointless. > True enough. Although, I have to ask how many times you define a new function only to have Python spit a syntax error out at you saying that you forgot a colon. It happens to me all the time. (Usually after an "else") If you'd never notice that the colon was missing if the compiler didn't point it out, is it really that readable? For me, I tend to get annoyed at language "features" that I'm constantly tripping over. - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Ron Adam wrote: > Michael Hobbs wrote: > >> Ron Adam wrote: >> >>> LOL, of course it would. I would expect that too after a suitable amount >>> of >>> 'brain washing', oops, I mean training and conditioning. ;-) >>> >>> >> Trust me, my brain is quite filthy and doesn't wash easily. I do >> appreciate aesthetics, which is why still stay with Python, even after >> programming in Ruby for several months. I've used Java/C/C++ for years, >> yet I make no complaint about the lack of static typing in Python. Even >> so, I'd like to think that I know a good thing when I see it. >> > > I find if I approach things on a learning basis and always presume there are > things I still don't know. I then tend to get much more help and support > than > if I approach things on a 'I'm right/your wrong' basis. Also, if I do turn > out > to have a point a view that is not exactly right, it is then much easier for > me > to take a new position or even the reverse position and move on. > > To clarify my position, I'm not intentionally being contradictory. In fact, when I first posed my question, I asked if anyone had a good reason for why the redundancy should continue to exist. Expecting to get a nice grammatical counter-example, the only viable answer that anyone could come up with is the FAQ answer that it improves readability. Since then, I've been fighting my point that the colon really doesn't improve readability all that much. In the end, I have to admit that I really couldn't give a flying frog if the colon is there or not. It's just a colon, after all. I *was* hoping that I could convince someone to honestly think about it and consider if the colon is really that noticeable. But so far, the only response that I've received is that there's that ABC study somewhere and that settles that. - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Ron Adam wrote: > LOL, of course it would. I would expect that too after a suitable amount of > 'brain washing', oops, I mean training and conditioning. ;-) > Trust me, my brain is quite filthy and doesn't wash easily. I do appreciate aesthetics, which is why still stay with Python, even after programming in Ruby for several months. I've used Java/C/C++ for years, yet I make no complaint about the lack of static typing in Python. Even so, I'd like to think that I know a good thing when I see it. > The point is what is more natural to "read" with a minimum amount of > explanation. I would think for most people who are learning programming for > the > first time, it is things that resemble things they already know. Such as > outlining with colons. > > Leaving the colon out probably would feel more natural for writing once you > get > used to it. After all it is a bit less typing. But I don't think it would > be > the most readable choice for most people. It's probably a trade off, > readability vs writability. Another python development guideline is to favor > readability over writability on the presumption we tend to write code once, > but > read code many times. > Not to repeat myself from an earlier post, but any pretense that Python's primary objective is readability went out the window with the invention of such constructs as "__del__", "__repr__", and "super(MyClass, self).__init__()". There are obviously other goals to the language's development that inspired these constructs and override the priority of readability. > Here's an alternative test. Write a program to remove all the end of line > colons from pythons library and then write another separate program to put > them > back in. Will it miss any? will it pass the python test suite? > I just may take you up on that. ;-) Not for a few days, though. Not enough time right now. - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Carsten Haese wrote: > On Sat, 2006-11-11 at 23:18 -0800, Doug wrote: > >> Michael Hobbs wrote: >> >>> I think the colon could be omitted from every type of compound >>> statement: 'if', 'for', 'def', 'class', whatever. Am I missing anything? >>> >>> Thanks, >>> - Mike >>> >> It is a very good idea as the colon is technically redundant (not >> necessary for parsing, aside from one liners) and actually hurts >> readability (and writeability). The "evidence" people cite for the >> advantage of using a colon is research done by users of the ABC >> language, python's predecessor. They forget that A) that was like 20 >> years ago, >> > > Research being old does not automatically invalidate it. Old research is > invalidated by newer research that invalidates it. > > No, old research does is not automatically invalidated, but out-of-context research is. I'm sure there's research somewhere proving that code written in ALL UPPERCASE is preferable, since it makes punched-cards easier to read by humans. Python 1.0 may have been a nice language for "newbies", with a lot of similarities to ABC, but there has been a lot of evolution since then. Sure, it's still very easy to teach basic Python, but if you're concerned about readability, take a look at any real-world Python app or library. You'll find it's filled with things such as "__getattr__", "__repr__", "__nonzero__", and "super(MyClass, self).__init__()". Hardly newbie stuff. I think waving the banner of ABC simplicity in the context of Py3K is about as applicable as complaining that an RSS aggregator isn't written in assembly. (An RSS aggregator is so far beyond being CPU-bound that it's pointless to argue which language it should be written in.) - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Ron Adam wrote: > [EMAIL PROTECTED] wrote: > >> > I'm not sure why '\'s are required to do multi-line before the >> colon. >> Special cases aren't special enough to break the rules. >> >> Georg >> >>> A bit of a circular answer. >> >>> >> >>> Why the rule? -> So not to break the rule? >> >> >> >> You proposed to allow leaving off line continuation '\' only in the >> >> "if", "for" and "while" headers. This is a special case in my eyes. >> >> Ron> I wasn't that specific and it was related to Michael's suggestion >> Ron> the colon wasn't needed. If the need for '\' was dropped in >> Ron> multi-line block headers, then the colon would be required for an >> Ron> obvious reason. >> >> But \ is used to continue all sorts of statements/expressions, e.g.: >> >> x = a + \ >> b >> >> not just conditionals. >> >> Skip >> > > Of course, and your point is? > > How about if it be ok to continue to use '\' in headers, but it also be ok to > not to? That would be the backward compatible way to change it. > > This doesn't answer the question I was asking, are there any situation where > it > would cause problems? And if so, that reason would be a good and explicit > reason for not making such a change To be clear, this is the actual thrust of my argument. It seems redundant to have *both* line continuations and colons in compound statements. I've been arguing for the removal of colons, though to be honest, I'd be content with the opposite approach as well. - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Georg Brandl wrote: > Ron Adam wrote: > >> Michael Hobbs wrote: >> >> >>> The same problem that is solved by not having to type parens around the >>> 'if' conditional, a la C and its derivatives. That is, it's unnecessary >>> typing to no good advantage, IMHO. I was coding in Ruby for several >>> months and got very comfortable with just typing the if conditional and >>> hitting return, without any extra syntax. When I came back to Python, I >>> found that I felt annoyed every time I typed the colon, since it >>> obviously isn't required. The FAQ says that the colon increases >>> readability, but I'm skeptical. The indentation seems to provide more >>> than enough of a visual clue as to where the if conditional ends. >>> >> I'm not sure why '\'s are required to do multi-line before the colon. >> > > Special cases aren't special enough to break the rules. > > Georg > Eh? So multi-line strings are special enough to create a new syntax, like, say, triple-quoted strings? Very long expressions aren't special enough to create a special backslash token to continue the expression on the next line? Multiple short expressions aren't special enough to create a special semi-colon token to combine them on a single line? Programming language design is nothing more than deciding the best way to deal with special cases. That even includes Lisp. - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Antoon Pardon wrote: > On 2006-11-11, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > >> On Fri, 10 Nov 2006 13:16:32 -0600, Michael Hobbs wrote: >> >> >>> Yeah, okay, I didn't read through the details of the PEP. I picked a bad >>> example to illustrate a point that is still true. The FAQ also tries to >>> argue that it's a Good Thing that join() is a string method, not a list >>> method. It also tries to argue that there's a good reason that lists are >>> different than tuples. I don't think it would surprising that many >>> Python developers don't really buy those arguments either. >>> >> Well, as far as I'm concerned, you've just blown your credibility >> completely out the water now. >> >> Yes, I'm aware that there are many Python programmers who don't get join() >> or lists/tuples, but I'm constantly surprised by that fact. At the risk of >> starting another argument, to my mind that's like discovering that there >> are professional butchers who don't think that using a sharp knife is a >> good idea. >> > > Well I would think that if you would find out that many professional > butchers would think so, you might consider the idea has some merrit. > As they say, insanity is nothing more than having a minority opinion. As more people take the opposite side, who's left being the crazy one? ;-) - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Steven D'Aprano wrote: > On Fri, 10 Nov 2006 15:18:55 -0600, Michael Hobbs wrote: > > >> Ron Adam wrote: >> >>> It is also an outline form that frequently used in written languages. >>> Something >>> python tries to do, is to be readable as if it were written in plain >>> language >>> where it is practical to do so. So the colon/outline form makes a certain >>> sense >>> in that case as well. >>> >>> >> That is perhaps the most convincing argument that I've heard so far. >> Indeed, I often find myself writing out colons when writing pseudo-code >> out on paper. The reason, however, is usually because my indents don't >> quite line up as perfectly on paper as they do in an editor. The colons >> provide a form of backup separation for when my columns start to get >> sloppy. (Natural language is actually filled with such redundancies in >> order to compensate for sloppy handwriting.) >> > > Er, natural language pre-dates handwriting by many tens or hundreds of > thousands of years. The redundancy of natural language has many reasons, > but compensating for sloppy handwriting is not one of them. I was using the term "natural language" in a wider sense, as in spoken languages, unspoken languages (sign languages), and writing systems. As far redundancies in writing systems go, it has been estimated that there is ~50% redundancy in the characters alone. That is, you can usually determine what a character is even when half of its strokes are removed. That's not even considering other redundancies such as using a phonetic alphabet vs. ideographs, or writing the vowels between consonants, which only started with the Greek alphabet. >> This backup function >> obviously isn't needed when a computer is taking care of the layout. >> > > That word you use, "obviously", I don't think it means what you think it > means. There's nothing obvious about your conclusion to me. > > while (this really long expression > (which extends over multiple lines > and contains many statements) > some of which (like this one) contain > nested bracketed terms such as (this > expression here) but like all good > things) it eventually ends > and we can get to the business > of executing the while-block > > Compare that to the version with a colon: > > while (this really long expression > (which extends over multiple lines > and contains many statements) > some of which (like this one) contain > nested bracketed terms such as (this > expression here) but like all good > things) it eventually ends: > and we can get to the business > of executing the while-block > > > Arguably, the parser might not find the first version any more difficult > than the second, but I know which one I'd rather read. I'd rather read neither. Both of them are obviously illegible. As the saying goes, you can write FORTRAN code in any language. That is, no language, no matter what its parsing rules, can prevent you from writing illegible code if you're determined to do so. To me, the second example is no more legible simply because it contains a colon somewhere. Proper style would dictate that you make some form of obvious break when writing a multi-line conditional, no matter which language you're using. Some possibilities: while (this really long expression (which extends over multiple lines and contains many statements) some of which (like this one) contain nested bracketed terms such as (this expression here) but like all good things) it eventually ends: and we can get to the business of executing the while-block or while (this really long expression (which extends over multiple lines and contains many statements) some of which (like this one) contain nested bracketed terms such as (this expression here) but like all good things) it eventually ends: and we can get to the business of executing the while-block or while (this really long expression (which extends over multiple lines and contains many statements) some of which (like this one) contain nested bracketed terms such as (this expression here) but like all good things) it eventually ends: BODY and we can get to the business of executing the while-block >> My final argument against the colons is to simply try programming in >> Ruby for a while and then come back to Python. I think you'll find that >> programming without the colons just simply feels more "natural". >> > &
Re: Py3K idea: why not drop the colon?
Ron Adam wrote: > It is also an outline form that frequently used in written languages. > Something > python tries to do, is to be readable as if it were written in plain language > where it is practical to do so. So the colon/outline form makes a certain > sense > in that case as well. > That is perhaps the most convincing argument that I've heard so far. Indeed, I often find myself writing out colons when writing pseudo-code out on paper. The reason, however, is usually because my indents don't quite line up as perfectly on paper as they do in an editor. The colons provide a form of backup separation for when my columns start to get sloppy. (Natural language is actually filled with such redundancies in order to compensate for sloppy handwriting.) This backup function obviously isn't needed when a computer is taking care of the layout. My final argument against the colons is to simply try programming in Ruby for a while and then come back to Python. I think you'll find that programming without the colons just simply feels more "natural". - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Ron Adam wrote: > The faq also pointed out a technical reason for requiring the colon. It > makes > the underlying parser much easier to write and maintain. This shouldn't be > taken to lightly in my opinion, because a simpler easer to maintain and more > reliable python parser means development time can be spent improving the > language in other areas instead of fixing parsing problems every time a new > feature is added that might be used in a conditional expression. > Not to be too picky about it, but the FAQ was referring to editor parsers, not the parser used by Python itself. The Python parser could easily change its grammar to make the colon optional. I find the editor parsing excuse to be weak since most editors tend to get hung up on Python code anyway, regardless of the colons. (Except for the ones that are specifically written to support Python, or are insanely programmable, like emacs.) In fact, I find that my editor usually gets confused when it comes across colons in dictionary literals or lambda expressions. If it just stuck to looking at the indentation, instead of trying to play off syntax tricks, it would behave much better. - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Steve Holden wrote: > Michael Hobbs wrote: > >> Ben Finney wrote: >> > [...] > >>> A use case. What problem is being solved by introducing this >>> inconsistency? >>> >>> >> The same problem that is solved by not having to type parens around the >> 'if' conditional, a la C and its derivatives. That is, it's unnecessary >> typing to no good advantage, IMHO. I was coding in Ruby for several >> months and got very comfortable with just typing the if conditional and >> hitting return, without any extra syntax. When I came back to Python, I >> found that I felt annoyed every time I typed the colon, since it >> obviously isn't required. The FAQ says that the colon increases >> readability, but I'm skeptical. The indentation seems to provide more >> than enough of a visual clue as to where the if conditional ends. >> >> > So you'd also like us to shorten the names of the builtins and the the > keywords? Why bother with "def" when we could just use "d", "class" when > we could just use "c"? Or *does* readability matter to some degree? > > Like I said in that paragraph, removing the colon wouldn't seem to degrade readability *that much*, if at all. Personally, even though I find typing the colon to be a small annoyance, that annoyance exceeds any improvement to readability that it might provide; especially considering that indentation sticks out like a big red sign saying the code block starts "HERE, HERE, HERE". >> As far as using the FAQ as gospel, the FAQ also provides arguments for >> why there isn't a with statement or a switch statement. The with >> statement has already been implemented in 2.5 and there's a PEP to >> implement switch (3103). >> >> > But the "with" statement isn't the one that "with" was reserved for in > the FAQ, which is really talking about the same kind of "with" statement > that Visual Basic uses: an implied left operand for unary "." operations. > > Yeah, okay, I didn't read through the details of the PEP. I picked a bad example to illustrate a point that is still true. The FAQ also tries to argue that it's a Good Thing that join() is a string method, not a list method. It also tries to argue that there's a good reason that lists are different than tuples. I don't think it would surprising that many Python developers don't really buy those arguments either. - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Ben Finney wrote: > Please don't hide your new thread as a reply to an existing, unrelated > message. Start a new message if your message isn't actually a reply. > > My apologies. My email client was apparently hiding some important headers from me. >> The colon that divides the statement therefore seems redundant. The >> colon could continue to be used for single-line statements: >> if self.hungry: self.eat() >> > > Why have two different syntaxes for the same statement? > > Why am I allowed separate statements with semi-colons in addition to newlines? Why have triple-quoted long strings in addition to single-quoted short strings? Why do I have to type backslash to continue a line, except when I'm currently inside parens, brackets, or braces? The answer is that it's a matter of convenience for the most common case, with some exceptions allowed for the exceptional cases. >> I think the colon could be omitted from every type of compound >> statement: 'if', 'for', 'def', 'class', whatever. Am I missing >> anything? >> > > A use case. What problem is being solved by introducing this > inconsistency? > The same problem that is solved by not having to type parens around the 'if' conditional, a la C and its derivatives. That is, it's unnecessary typing to no good advantage, IMHO. I was coding in Ruby for several months and got very comfortable with just typing the if conditional and hitting return, without any extra syntax. When I came back to Python, I found that I felt annoyed every time I typed the colon, since it obviously isn't required. The FAQ says that the colon increases readability, but I'm skeptical. The indentation seems to provide more than enough of a visual clue as to where the if conditional ends. As far as using the FAQ as gospel, the FAQ also provides arguments for why there isn't a with statement or a switch statement. The with statement has already been implemented in 2.5 and there's a PEP to implement switch (3103). - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Paul Boddie wrote: > Michael Hobbs wrote: > >> I think the colon could be omitted from every type of compound >> statement: 'if', 'for', 'def', 'class', whatever. Am I missing anything? >> > > The FAQ answer. ;-) > > http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements > > Paul > I knew there was a document somewhere that I missed. ;-) I even scanned all the Py3K PEPs before posting. Anyway, the FAQ answer seems to be a weak argument to me. But if the BDFL insists that it remains, why not take the converse approach? That is, assume that the expression ends at the colon, not at the newline. That would make this type of statement possible: if color == red or color == blue or color == green: return 'primary' Right now, such a statement would have to be spelled thus: if color == red or \ color == blue or \ color == green: return 'primary' or if (color == red or color == blue or color == green): return 'primary' -- http://mail.python.org/mailman/listinfo/python-list
Py3K idea: why not drop the colon?
Can anyone find a flaw with this change in syntax? Instead of dividing a compound statement with a colon, why not divide it on a newline? For example, the colon could be dropped from this statement: if self.hungry: self.eat() to if self.hungry self.eat() Python is already sensitive to whitespace and the newline anyway, so why not put it to good use? For example, Python rejects this statement because of the newline present: if self.hungry or self.depressed: self.eat() You need to use the backslash to continue the expression on the next line: if self.hungry or \ self.depressed: self.eat() The colon that divides the statement therefore seems redundant. The colon could continue to be used for single-line statements: if self.hungry: self.eat() I think the colon could be omitted from every type of compound statement: 'if', 'for', 'def', 'class', whatever. Am I missing anything? Thanks, - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: problemi con POST
Bruno Desthuilliers wrote: > Heavy a écrit : > >> Ciao a tutti, >> sto creando una applicazione in python, che deve fungere anche da >> server web... >> non ho assolutamente problemi a prendere i parametri di una 'GET', mi >> limito a fare il parsing della URL, ma come faccio a prendere i >> parametri di una 'POST'? io cerco di leggere dal socket di lettura >> 'rfile' ma poi resto bloccato all'infinito perché evidemente resta in >> attesa di qualcosaltro... c'è già qualche metodo che mi può >> aiutare?? oppure sapete darmi qualche dritta? grazie... >> >> > Désolé, mais je n'ai rien compris (enfin, si : que tu avais des > problèmes pour parser une requête HTTP POST et que tu te retrouvais avec > une lecture bloquante sur un socket, mais ce n'est pas avec ça qu'on va > pouvoir t'aider). Tu pourrais nous reposter ça en english ?-) > Aay Enchfray eplyray otay anay Italianay estionquay? Ellway, Iay ancay itewray inay aay oreignfay anguagelay ootay! - Ikemay -- http://mail.python.org/mailman/listinfo/python-list
ANN: iTorrent alpha-2
Announcing the second alpha release of iTorrent. iTorrent allows you to download BitTorrent podcasts from iTunes. It transforms BitTorrent podcasts so that you can update them just like any other podcast in iTunes. Details can be found at http://www.itorrent.cc. iTorrent is written in Python and is released under the GPL. With its second alpha release, iTorrent still isn't pretty, but it is much easier to install and run. Technical Details: iTorrent runs as an RSS proxy on your local machine and will fetch enclosures from a BitTorrent network on behalf of iTunes. The BitTorrent content will then be fed to iTunes via a standard HTTP loopback connection. It uses the official BitTorrent 4.4.0 code to perform the actual downloads from a BitTorrent network. (http://www.bittorrent.com) Regards, - Michael Hobbs <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list
Re: how to comment lot of lines in python
Eric Deveaud wrote: > [EMAIL PROTECTED] wrote: > >> Eric Deveaud wrote: >> >>> [EMAIL PROTECTED] wrote: >>> Like in C we comment like /* Bunch of lines of code */ Should we use docstring """ """ >>> I would say NO. docstring are displayed by pydoc, thus a pydoc on your >>> code will display some inconsistent information ;-) >>> >>> >> docstrings are a bit of a magical construct. Not all strings in a >> function are docstrings. >> > > > yep fogotten that triple quotted strings are considered as docstring > only if they are the first lines of the module/fonction/class/method > excluding the comments lines. > The official rule is that if *any* string is the first line of a function/etc, it is considered a docstring. It's just standard convention to use the triple quotes for docstrings. As you mentioned, you can use triple quotes for any string; likewise, you can use standard quotes ( ' or " ) for docstrings as well. - Mike -- http://mail.python.org/mailman/listinfo/python-list
ANN: iTorrent alpha-1
Announcing the first alpha release of iTorrent. iTorrent allows you to download BitTorrent podcasts from iTunes. It transforms BitTorrent podcasts so that you can update them just like any other podcast in iTunes. Details can be found at http://www.itorrent.cc. iTorrent is written in Python and is released under the GPL. Since this is its first alpha release, iTorrent isn't pretty, but it does work well -- for me. Please try it out on your own podcasts and let me know what doesn't work. Also, since this is an early release, I am only announcing it to a select group of knowledgeable Python users. Please don't spread the word; I'm not ready yet to handle bug reports from casual end users. Technical Details: iTorrent runs as an RSS proxy on your local machine and will fetch enclosures from a BitTorrent network on behalf of iTunes. The BitTorrent content will then be fed to iTunes via a standard HTTP loopback connection. It uses the official BitTorrent 4.4.0 code to perform the actual downloads from a BitTorrent network. (http://www.bittorrent.com) Regards, - Michael Hobbs <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list
Anyone else experience Thread.join() returning early?
I just wanted to see if anyone else experienced a problem with the Thread.join() method in Python 2.4. Unfortunately, I did not debug this problem fully before re-writing my code to avoid Thread.join(). My specific situation was that I called subprocess.Popen() to spawn a separate process with the stdout redirected to a pipe. I then created a Thread to process the data coming through the pipe. The thread would terminate when it encountered EOF on the pipe. When I used Thread.join(), I would encounter symptoms that lead me to believe that join() was returning before the subprocess actually terminated. After I rewrote the code to manually manipulate a lock instead of using Thread.join(), the symptoms went away. I guess that I'm just curious to see if anyone else has encountered a problem here, so that a bug can be filed if necessary. I did a quick Google search, but didn't see any other reports. Thanks, - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: why are people still using classic classes?
Simon Wittber <[EMAIL PROTECTED]> wrote: > I've noticed that a few ASPN cookbook recipes, which are recent > additions, use classic classes. > > I've also noticed classic classes are used in many places in the > standard library. > > I've been using new-style classes since Python 2.2, and am suprised > people are still using the classic classes. > > Is there a legitimate use for classic classes that I am not aware of? > Is there a project to specifically migrate standard library classes to > new-style classes? I'm guessing that the biggest contributor to the continued prevalence of classic classes is the official Python Tutorial: http://docs.python.org/tut/node11.html#SECTION001130 I came into Python around the 2.2 timeframe and used the tutorial as my starting point. I had often read people referring to "classic classes" but assumed that it was some old pre-2.2 thing that I need not worry about. For the longest time, I had assumed that I was using new style classes because I created them exactly as prescribed in the 2.2 tutorial (which still hasn't changed for 2.3 or 2.4). Now, classic classes are my habit and I see no compelling reason to put in the effort to change my habits. Regards, - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Detecting shutdown of remote socket endpoint.
Tim Gosselin <[EMAIL PROTECTED]> wrote: > I am writing a tcp tunnel but cannot find a way of detecting when a socket > shuts down its read end without writing to the socket. For testing the > write end of the remote endpoint I just do a: > > if not sock.recv(buffsize) > > I cannot write to the socket and check if send returns 0 though, because > that involves sending data out of the which may not have come in yet. > > When I try polling the socket with: > r, w, e=select([],[sock],[], 0) > w returns with the socket still writable, even if the other end was > closed. Even at the C level, I believe there were some differences between Unix and Windows sockets in regard to this, so this advice may be dependent on your platform. At any rate, on both Unix and Windows, a closed socket will continue to report itself as writable. To detect the closed socket, I believe that one system reports the socket as being in error whereas the other system reports the socket as being readable (where read() will then immediately return 0 because the socket is closed). So in summary, instead of: r, w, e=select([],[sock],[], 0) try this: r, w, e=select([sock],[],[sock], 0) If r or e is non-empty, then the socket has been closed (or there's some other error). HTH, - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
David Brown <[EMAIL PROTECTED]> wrote: > Hello. I recently came across a free operating system called Unununium (or > something like that) and it was developed in Python and Assembly. > > Now, I have been looking for a way to make an operating system for a long > long time and the only possibilities I could find were C++ and assembly. The problem when using Python instead of C for OS development is that C was *specifically designed* to create an OS, while Python was designed for completely different purposes. If you want to write an OS, it would be wise to use a language that is suited for that purpose. If you dislike C so much and prefer Python so much more, your first step should be to design a Python dialect that is more appropriate for writing OS's. (I know that you mentioned C++, not C, but I decided to setup C as a straw-man to make my argument.) - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting rid of "self."
Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Wait for Python 3k when this will work: > > class c: > def __init__(self): > with self: > .x = 1 > .y = 2 > .hi = "Hi there!" Python is looking more like JavaScript every day... -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing: Part II
John Roth <[EMAIL PROTECTED]> wrote: > Now, the base objective seems to be to incorporate PyChecker > functionality into the root. This in turn requires type inference, > which in turn strongly suggests type annotations to help the > inferencer out over rough spots. > > I like this approach a lot. If he makes the type inferencer "proud", that might help alleviate the fears around here that it will become standard practice to put type annotations on everything. That is, if you explicitly annotate a function in the same way that the inferencer would have inferenced it, the PyChecker thingie would emit a message saying: "I'm no dummy! I could have told you that foo() takes an 'int' and returns a 'bool'. What do you think I am, stupid? Duuu-uhhh!" :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
Ville Vainio <[EMAIL PROTECTED]> wrote:
> What form of extreme dynamic behaviour have you been using lately?
One real-world example: in my new coverage analysis tool (to be
released any month now), I need to trace threads without changing any
code. To do so, I redefine the thread.start_new_thread() function from
outside the thread module, like so:
orig_start_new_thread = thread.start_new_thread
def traced_start_new_thread(func, args, kwargs={}):
return orig_start_new_thread(traced_func_call, (func, args, kwargs))
def traced_func_call(func, args, kwargs):
sys.settrace(my_trace_func)
func(*args, **kwargs)
thread.start_new_thread = traced_start_new_thread
Granted, doing something like this on a regular basis is really bad
coding style, but the ability to do something like this when I really
need it is what I love about Python.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing - Haskell?
Neal D. Becker <[EMAIL PROTECTED]> wrote: > I've just started learning about Haskell. I suggest looking at this for an > example. > > A good intro: http://www.haskell.org/tutorial > I've always found that with Haskell, if I can get my program to compile without error, it usually runs flawlessly. (Except for the occasional off-by-one error. :-) I don't know if that's due to the fact that Haskell enforces pure functional programming, or if it's due to Haskell's strict static typing, or the combination of the two. But if anyone ever demanded that I wrote code that absolutely positively has to work, no matter the cost, I would probably choose Haskell. Tying Haskell back to Python, if static type checking ever is grafted on to Python, I would propose that it uses type inference, a la Haskell or O'Caml, and raise an Error only when it detects a truly unmistakable type error. This may be easier said than done, however, given Python's dynamic nature. For example, a class's method may be re-bound to any other function at runtime, which would wreak havoc on any static type checker. - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
Rahul <[EMAIL PROTECTED]> wrote: > I am assuming that optional type checking is being added for easier > debugging only. So if 'expects' are turned on , python raises > warnings(which do not halt the system) but not when they are turned > off. These will enable easier debugging for new people while not > affecting masters. Also,perhaps, it will be easier to accomodate till > type checking mechanism is perfected(if it is implemented at all that > is) so that python does not stop you when it is in fact python which > might be making some mistake.(This last statement is a guess only...) > > It is similar to assert and __debug__=1 in a way. > > So the crux is : > 1.Expects is only a bridge between type checking and dynamic typing. > 2.Type checking is done only as a tool which you are free to override > if you want to. > 3.The objective of type checking here is only to make debugging easier > and not speed/optimization. > 4.The point is not that 'expects' be a additional keyword.You can go > like this also : > def (int a,int b): or whatever you like. Only that expects make it a > bit clearer IMHO. > > sincerely., > rahul Your proposition reminds me very much of Design by Contract, which is a prominent feature of the Eiffel programming language. Considering that Python is an interpreted language where type checking would naturally occur at runtime, I think Design by Contract would be more appropriate than static typing. In a function's contract, not only could it state that its parameter must be an integer, but also that it must be > 50 and be divisible by 7. If a value is passed to the function that violates the contract, it raises an exception. In Eiffel, contract checking can be turned on or off based on a compiler flag or a runtime switch. - Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: installing wxPython on Linux and Windows
Daniel Bickett <[EMAIL PROTECTED]> wrote: >> I have no way to build it on Windows though, as I don't have Visual C++ >> 7.1, for that we must wait for Robin Dunn. > > Would it be too difficult of a task to try getting the build working > with Dev-C++? That way those without enough incentive for purchasing > Visual C++ (in excess of $100, I believe) could build it. Forgive my > ignorance if this has already been considered ;) I'm pretty sure that I once built wxPython using Cygwin. It was a while ago, though, and I was switching back and forth between windows and Linux very frequently; so I may just be imagining it... - Mike -- http://mail.python.org/mailman/listinfo/python-list
