Re: Python-list Digest, Vol 92, Issue 223
On Thu, May 26, 2011 at 10:58 AM, Richard Parker r.richardpar...@comcast.net wrote: It's time to stop having flame wars about languages and embrace programmers who care enough about possible future readers of their code to thoroughly comment it. Comments are far more valuable than the actual language in which the code is written, IMHO. The problem with comments (and documentation in general) is that they are often imperfect. If the code is absolutely opaque but it has a comment next to it, you still have that niggling doubt: has the comment been updated whenever the code has? Was it even accurate in the first place? (Comments often say what a piece of code _ought_ to do, but the code might have a bug in it. And sometimes, that bug ends up being part of the function's definition, and people depend on it.) I'd rather have both - reasonably readable code AND a comment, where the comment explains the intent behind the code. Gee...I absolutely agree! I have no problem with anything you said. My intent in writing at all was to express that comments (along with well-written code) are more important than the language in which the code is written. There's no doubt that sometimes comments aren't updated when code is changed and sometimes comments express what the code is attempting to implement; however, code in any language written without accompanying comments is much harder to understand AND maintain. If, given a chunk of readable Python code written by someone else without accompanying comments, I would be scratching my head far longer trying to understand, modify, or maintain it, than if it also had (even imperfect) accompanying comments. So--we agree that reasonably readable code AND a comment that explains the intent of the code is what we should all strive to produce. -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On Thursday 26 May 2011 14:46:45 Uncle Ben wrote: In playing with lists of lists, I found the following: (In 3.1, but the same happens also in 2.7) list = [1,2,3] list.append ( [4,5,6] ) x = list x - [1,2,3,[4,5,6]] as expected. But the shortcut fails: list=[1,2,3] x = list.append( [4,5,6] ) x - nothing Can someone explain this to me? Uncle Ben And why do you insist on calling and instance of list, list? Even a human reader will confuse which is which. What you are showing is an example how confusing things become when a keyword (list) is over-written (with list instance). Why don't you just say lst = [1, 2, 3] rather than list =... It may be permissible, but it is not a good idea! Old (practical) Al. -- Algis http://akabaila.pcug.org.au/StructuralAnalysis.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On Thu, May 26, 2011 at 2:46 PM, Uncle Ben bgr...@nycap.rr.com wrote: In playing with lists of lists, I found the following: (In 3.1, but the same happens also in 2.7) list = [1,2,3] Ben Finney has already answered the main question, but as a side point, I would generally avoid creating a variable called 'list'. That's the name of the type (Python 2) or class (Python 3) of all lists, so it might result in confusion if you have an actual list with that name. If you want the behaviour of joining two lists (or adding something to a list) and saving the result elsewhere, you can use the plain addition: a=[1,2,3] b=a+[[4,5,6]] Note that you have to add a list, and it will append the contents of that list. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On Thu, May 26, 2011 at 5:20 PM, Chris Angelico ros...@gmail.com wrote: Ben Finney has already answered the main question Giving credit where credit's due, it was more Chris Rebert's post that answered the question. Sorry Chris! Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On May 26, 12:46 am, Uncle Ben bgr...@nycap.rr.com wrote: In playing with lists of lists, I found the following: (In 3.1, but the same happens also in 2.7) list = [1,2,3] list.append ( [4,5,6] ) x = list x - [1,2,3,[4,5,6]] as expected. But the shortcut fails: list=[1,2,3] x = list.append( [4,5,6] ) x - nothing Can someone explain this to me? Uncle Ben Thank you all. It is wonderful to have this community as a resource. Uncle Ben -- http://mail.python.org/mailman/listinfo/python-list
Re: Hotshoting recursive function
On Wed, May 25, 2011 at 2:20 PM, Gabriel Genellina gagsl-...@yahoo.com.arwrote: En Sun, 22 May 2011 10:42:08 -0300, Selvam s.selvams...@gmail.com escribió: I am using hotshot module to profile my python function. I used the details from ( http://code.activestate.com/recipes/576656-quick-python-profiling-with-hotshot/ ). The function I profile is a recursive one and I am getting the following error, ProfilerError: profiler already active I guess this is due to the recursive call to the profiling function. I would like to get some suggestions. The recursive call inside your function should call the undecorated function, not the decorated function again. Decorator syntax is not convenient anymore. Using the same names as in the recipe example: # a recursive function def my_slow_function(n): ... return my_slow_function(n-1) my_profiled_slow_function = hotshotit(my_slow_function) my_profiled_slow_function(n) This works, in the sense that it does not raise ProfileError anymore. Interpreting profile data is up to you... Thanks Gabriel, it makes more sense ! -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list -- Regards, S.Selvam SG E-ndicus Infotech Pvt Ltd. http://e-ndicus.com/ I am because we are -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On Thu, May 26, 2011 at 12:23 AM, Chris Angelico ros...@gmail.com wrote: On Thu, May 26, 2011 at 5:20 PM, Chris Angelico ros...@gmail.com wrote: Ben Finney has already answered the main question Giving credit where credit's due, it was more Chris Rebert's post that answered the question. Sorry Chris! Eh, one can't fight chronology! I'm just surprised that the docstring doesn't explicitly state Returns None. by this point, given that this is such a common point of newbie confusion. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
* John Bokma (Wed, 25 May 2011 07:01:07 -0500) Thorsten Kampe thors...@thorstenkampe.de writes: * Chris Angelico (Wed, 25 May 2011 08:01:38 +1000) On Wed, May 25, 2011 at 3:39 AM, D'Arcy J.M. Cain da...@druid.net wrote: One of my favorite quotes (not sure if it was about Perl or APL) is I refuse to use a programming language where the proponents of it stick snippets under each other's nose and say 'I bet you can't guess what this does.' Yes, I believe that was Perl. And an amusing quote. But most of the point of it comes from the fact that Perl uses punctuation for most of its keywords, whereas (say) Python uses English words; it's a lot more fun to crunch something down when you can use $| and friends than when you have to put x and y, complete with spaces, for a simple boolean. But that says nothing about which language is actually better for working with... [...] It does say something about readibility. And yes, readability counts. And yes, readability says a lot about how good a language is for reading and working with. To people used to the latin alphabet languages using a different script are unreadable. So readability has a lot to do with what one is used to. You've made that alphabet argument more than once. Nevertheless it's nonsense (sorry). Perl uses the same alphabet as Python. Only the words Perl uses ($| for instance) are only found in a Perl dictionary not in a English or math dictionary like the one that Python uses. That's why you can /read/ Python but you have to /decode/ Perl to understand the source code. Like I already stated before: if Python is really so much better than Python readability wise, why do I have such a hard time dropping Perl and moving on? What kind of argument is that? Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
* Steven D'Aprano (25 May 2011 21:59:58 GMT) On Wed, 25 May 2011 09:26:11 +0200, Thorsten Kampe wrote: Naming something in the terms of its implementation details (in this case recursion) is a classical WTF. *If* that's true, it certainly doesn't seem to apply to real-world objects. Think about the exceptions: microwave oven vacuum cleaner oven fries electric car chain saw flintlock rifle air gun vulcanised rubber kerosene heater aluminium foil diamond saw gas stove wood stove four-wheel drive car incandescent light bulb electric razor unleaded petrol to mention only a few. Naming the thing after the implementation would often seem to be *good advice*, not bad. We often do care about implementations. You really do need to know whether the car you drive uses leaded or unleaded. That's exactly the point. You don't need to know whether include sub- directories was implemented recursively. It's absolutely pointless. But not to digress, the /real/ problem with commands or idioms like rm -r is /not/ their choice of option names but that they explain these options in the exact same terms. No one would have a problem with -r, --recursive -- remove directories including all sub-directories instead of -r, --recursive -- remove directories and their contents recursively. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
* Steven D'Aprano (25 May 2011 22:58:21 GMT) On Wed, 25 May 2011 00:06:06 +0200, Rikishi42 wrote: What I mean is: I'm certain that over the years I've had more than one person come to me and ask what 'Do you wish to delete this directory recursively?' meant. BAut never have I been asked to explain what 'Do you wish to delete this directory and it's subdirs/with all it's contents?' meant. Never. I know many people who have no idea what a directory is, let alone a subdirectory, unless it's the phone directory. They're non-computer users. Once they start using computers, they quickly work out what the word means in context, or they ask and get told, and then they've learned a new word and never need ask again. This is a good thing. The idiom of recursively delete is no different. Of course some people will have to learn a new term in order to make sense of it. So what? It's not just a new term. It tries to describe something which could be easily described in the terms of what is already known. If someone has learned what a directory or folder is, you don't have to explain what include sub-folders means. Instead of creating a new mysterious term (recursively delete), you simply explain stuff by re- using an already existing term. It's just that simple. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Thu, 26 May 2011 10:48:07 +0200, Thorsten Kampe wrote: But not to digress, the /real/ problem with commands or idioms like rm -r is /not/ their choice of option names but that they explain these options in the exact same terms. No one would have a problem with -r, --recursive -- remove directories including all sub-directories instead of -r, --recursive -- remove directories and their contents recursively. I think you are understanding the description remove directories and their contents recursively as a description of the *mechanism* by which rm removes the directory, i.e. some recursive tree-walking function that visits each node and deletes it. I don't believe that's how the description is meant to be understood. I understand it as describing the effect, not the implementation. If the tree-walker was re-written to be iterative, the description would not need to be changed. It is meant to be understood as: rm -r foo * deletes foo * deletes things inside foo * if any of those things inside foo are directories, delete them too, in exactly the same way (i.e. recursively). Notice that, strictly speaking, the description is impossible. You can't delete the top level directory first. But that's how the human reader will understand it: * delete the directory you point it at, plus the things inside it in the same way rather than how the implementation (probably) does it: * drill down all the way to the bottom, start deleting like mad, and work your way back up the stack, deleting as you go. You're interpreting the reference to recursive as a nod to the implementation. I'm not, and therefore your arguments don't convince me. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python-list Digest, Vol 92, Issue 221
On Thu, 26 May 2011 14:06:56 +1000, Chris Angelico wrote: On Thu, May 26, 2011 at 10:58 AM, Richard Parker r.richardpar...@comcast.net wrote: It's time to stop having flame wars about languages and embrace programmers who care enough about possible future readers of their code to thoroughly comment it. Comments are far more valuable than the actual language in which the code is written, IMHO. The problem with comments (and documentation in general) is that they are often imperfect. [snip more stuff I agree with] It's not the lack of perfection, since no code is perfect, but that comments are frequently missing, obsolete, incorrect, or inane: i.e. actively harmful rather than just imperfect. The classic example of what not to write as a comment: x += 1 # add one to x One of the regulars here -- Aahz -- often has this quote as his sig: At Resolver we've found it useful to short-circuit any doubt and just refer to comments in code as 'lies'. -- Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22 My experience is that comments in Python are of relatively low usefulness. (For avoidance of doubt: not *zero* usefulness, merely low.) I can name variables, functions and classes with sensible, self- documenting names. Why write: x = get_results(arg) # x is a list of 1 or more results [... much later] for y in x: # process each result in turn do_something_with(y) when I can write this? results = get_results(arg) [...] for result in results: do_something_with(result) It's better to write self-documenting code, than code + comments. Another use for comments is to explain *why* rather than *what*. No matter how readable your code is, if you don't understand why it is done, you can't effectively maintain it. If the why is obvious, you don't need a comment. But for me, the main reason # comments are of relatively little use in Python for me is because I write *tons* of docstrings and doctests. Any comment which could be useful to know at run-time goes into the docstring; what's left over, if anything, becomes a # comment. Between self-documenting code and docstrings, I hardly write any # comments. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python-list Digest, Vol 92, Issue 221
On Thu, May 26, 2011 at 8:07 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Another use for comments is to explain *why* rather than *what*. No matter how readable your code is, if you don't understand why it is done, you can't effectively maintain it. If the why is obvious, you don't need a comment. That's what my (contrived) example was. I also often have comments that are leftovers from the pseudocode stage; for instance, iteration 1: //TODO: Look up foo in some table and figure out which bar should be used. Iteration 2: //TODO: Look up foo in the bar_foo table and figure out which bar should be used. legal_bar = bar_foo[foo]; bar=legal_bar[0]; Iteration 3: //Figure out which bar should be used legal_bar = bar_foo[foo]; ... some algorithmic way of figuring out the best one ... When it leaves TODO status, anything that's inherently obvious (Look up foo in the bar_foo table) gets trimmed, but the statements of purpose tend to remain. Especially if the figuring out the best one is several lines of code, it makes sense to keep that comment. But because of the organic growth of the code, the comment will usually still bracket the look up foo in table part, even though the comment doesn't have anything to do with that. Is the comment inappropriate? I don't think so. Is it perfect? Definitely not. But it's still generally worth keeping. But I absolutely agree. The code ought to be self-documenting to the greatest extent possible (but no further - don't just create variables/constants for absolutely no reason than to embody documentation). Docstrings and autodoc comments are superior to general comments, although IMHO all three are pretty much the same thing. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Python-URL! - weekly Python news and links (May 26)
[This edition drafted by Gabriel Genellina.] QOTW: They did a study once to determine the best tool for development. Turns out that the most productive tool was generally the one that the user believed was the most productive. In hindsight I think that that was rather obvious. - D'Arcy J.M. Cain, 2011-05-24 Python 2.6.7 release candidate 2 now available: http://groups.google.com/group/comp.lang.python/t/ebbd57431bb084b2/ Amazing logic: and becomes or and or becomes and http://groups.google.com/group/comp.lang.python/t/b13e786438a609dd/ Equal objects must have equal hashes - but how strong is that requirement? http://groups.google.com/group/comp.lang.python/t/f23f72cf633892f9/ Do secure systems exist? http://groups.google.com/group/comp.lang.python/t/f887168ca476618f/7503714d82b1789b?#7503714d82b1789b os.access() returns totally useless results on Windows, always has, and nobody cares: http://groups.google.com/group/comp.lang.python/t/aa3d9b21c77fa7d7/ Is this PAAS Python mind-blowingly important, or pointless, or a mix of the two? http://www.activestate.com/cloud contextlib.nested() is deprecated - and this example shows why a custom implementation is hard to write well: http://groups.google.com/group/comp.lang.python/t/d6b090b7fd4a92c6/ Why one startup chose Python for development: http://groups.google.com/group/comp.lang.python/t/17dca3bf467c9001/ And more reasons another developer chose it: http://groups.google.com/group/comp.lang.python/t/17dca3bf467c9001/83a7be235c113dac?#83a7be235c113dac And now, things people do *not* like about Python: http://groups.google.com/group/comp.lang.python/t/fff2826d44ea336/ Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html Just beginning with Python? This page is a great place to start: http://wiki.python.org/moin/BeginnersGuide/Programmers Planet Python: you want to visit there: http://planet.python.org But don't confuse it with Planet SciPy: http://planet.scipy.org And don't confuse *that* with SciPyTip, a high-quality daily (!) tip for the numerically-inclined: http://twitter.com/SciPyTip Python Insider is the official blog of the Python core development team: http://pyfound.blogspot.com/2011/03/python-dev-launches-python-insider-blog.html The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donations/ Keep up with the PSF at Python Software Foundation News: http://pyfound.blogspot.com The Python Papers aims to publish the efforts of Python enthusiasts: http://pythonpapers.org/ Doug Hellman's Module of the week is essential reading: http://www.doughellmann.com/PyMOTW/ comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/group/comp.lang.python.announce/topics Python411 indexes podcasts ... to help people learn Python ... Updates appear more-than-weekly: http://www.awaretek.com/python/index.html The Python Package Index catalogues packages. http://www.python.org/pypi/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Summary of Python Tracker Issues is an automatically generated report summarizing new bugs, closed ones, and patch submissions. http://search.gmane.org/?author=status%40bugs.python.orggroup=gmane.comp.python.develsort=date nullege is an interesting search Web application, with the intelligence to distinguish between Python code and comments. It provides what appear to be relevant results, and demands neither Java nor CSS be enabled: http://www.nullege.com Although unmaintained since 2002, the Cetus collection of Python hyperlinks retains a few gems. http://www.cetus-links.org/oo_python.html The Cookbook is a collaborative effort to capture useful and interesting recipes: http://code.activestate.com/recipes/langs/python/ Many Python conferences around the world are in preparation. Watch this space for links to
Re: English Idiom in Unix: Directory Recursively
* Steven D'Aprano (26 May 2011 10:06:44 GMT) On Thu, 26 May 2011 10:48:07 +0200, Thorsten Kampe wrote: But not to digress, the /real/ problem with commands or idioms like rm -r is /not/ their choice of option names but that they explain these options in the exact same terms. No one would have a problem with -r, --recursive -- remove directories including all sub-directories instead of -r, --recursive -- remove directories and their contents recursively. I think you are understanding the description remove directories and their contents recursively as a description of the *mechanism* by which rm removes the directory, i.e. some recursive tree-walking function that visits each node and deletes it. I don't believe that's how the description is meant to be understood. I understand it as describing the effect, not the implementation. It doesn't matter how I interprete the explanation -r = recursively delete. What matters is that I have to explain (interpret, translate the explanation. You're interpreting the reference to recursive as a nod to the implementation. I'm not, and therefore your arguments don't convince me. No one understands what recursively delete means until someone explains (translates) it to him. This is not an argument but a simple fact. I experienced it many times, others here in the thread did and probably you, too. recursively delete is completely unneccessary because there is already a simple explanation that everyone understands without translation (delete including subdirectories). It's unnecessary bullshit buzzword bingo from nerds which adds or helps or explains nothing. It's just that simple. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Thorsten Kampe thors...@thorstenkampe.de wrote in message news:mpg.284834d227e3acd1989...@news.individual.de... If someone has learned what a directory or folder is, you don't have to explain what include sub-folders means. Instead of creating a new mysterious term (recursively delete), you simply explain stuff by re- using an already existing term. It's just that simple. I'm a native english speaker, and to me there is a difference between delete directory and sub-directories (or folders and sub-folders if you follow Microsoft's naming conventions) and recursively delete. I know english is very ambiguous, but to me directory and sub-directories does not necessarily imply sub-directories of sub-directories and so on, while recursively delete does carry the connotation of deleting the sub-directories of sub-directories and sub-directories of sub-directories of sub-directories and so on. Charles -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
I just conducted a rapid poll of a non-technical userbase. (Okay, I just asked my sister who happens to be sitting here. But she's nontechnical.) She explained recursive as it repeats until it can't go any further. I think that's a fair, if not perfectly accurate, explanation. Actually... if we accept that one iteration is deleting all files from one depth level, then yes, the algorithm repeats that operation. And I'm using iteration here without implying that it's an iterative function. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
* Charles (Thu, 26 May 2011 20:58:35 +1000) Thorsten Kampe thors...@thorstenkampe.de wrote in message news:mpg.284834d227e3acd1989...@news.individual.de... If someone has learned what a directory or folder is, you don't have to explain what include sub-folders means. Instead of creating a new mysterious term (recursively delete), you simply explain stuff by re- using an already existing term. It's just that simple. I'm a native english speaker, and to me there is a difference between delete directory and sub-directories (or folders and sub-folders if you follow Microsoft's naming conventions) and recursively delete. I know english is very ambiguous, but to me directory and sub-directories does not necessarily imply sub-directories of sub-directories and so on, Are we playing word games here? You can easily improve my example to delete directory and all sub-directories beneath. Or delete directory and all sub-directories beneath and all content. Or delete directory and all files and directories within. while recursively delete does carry the connotation of deleting the sub-directories of sub-directories and sub-directories of sub-directories of sub-directories and so on. Sure. Because you already know what it means (someone has already translated it to you long time ago). Did your mom tell you to recursively clean up your room?. Does my file manager ask me are you sure you want to recursively delete the folder?? No, it asks 'are you sure you want to remove folder folder name and all its contents?'. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Thu, May 26, 2011 at 9:20 PM, Thorsten Kampe thors...@thorstenkampe.de wrote: Did your mom tell you to recursively clean up your room?. Considering that I don't have a wardrobe with a portal to Narnia, no, she has never had to tell me to clean up the room inside my room. Anyway, my room's full. There's no room in it anywhere. :) Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Question about isodate
Hello list, I am installing and testing istSOS wrote base on Python with its extension like gdal, isodate, easy istall, setuptool, psycopg. I have already installed all these stuff when I was using method POST the error appear is No module named mx.DateTime.ISO , could you please give me your command and advice. Many thanks Quang-- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On 2011-05-25, Matty Sarro msa...@gmail.com wrote: General readability is a farce. If it was true we would only have one section to the library. Different people enjoy reading, and can comprehend better in different ways. THat's why some people are super verbose - hell, just look at this here post! :) Despite individual proclivities, there remain standards of readability enshrined in our dictionaries and grammar handbooks. Claiming that code readability of code is to be judged solely subjectively by each individual absolves code of the responsibility to communicate to more than just its author. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
In article 94709uf99...@mid.individual.net, Neil Cerutti ne...@norwich.edu wrote: On 2011-05-25, Matty Sarro msa...@gmail.com wrote: General readability is a farce. If it was true we would only have one section to the library. Different people enjoy reading, and can comprehend better in different ways. THat's why some people are super verbose - hell, just look at this here post! :) Despite individual proclivities, there remain standards of readability enshrined in our dictionaries and grammar handbooks. Claiming that code readability of code is to be judged solely subjectively by each individual absolves code of the responsibility to communicate to more than just its author. Also, the purpose of source code is to transmit information (to both the compiler and to human readers). That is a much narrower purpose than is served by books in a library, many of which are written as entertainment. Sometimes, the real enjoyment (in literature) comes in figuring out what the author really meant. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
Roy Smith r...@panix.com writes: Also, the purpose of source code is to transmit information (to both the compiler and to human readers). And the relative importance of readability for those two purposes is often misunderstood. Composing source code so that the *machine* will understand it is one thing, and can be unambiguously verified. Composing the same source code so that its meaning will be clearly transmitted to *other humans* is quite another matter: certainly more difficult, and arguably far more important: “Programs must be written for people to read, and only incidentally for machines to execute.” —Abelson Sussman, _Structure and Interpretation of Computer Programs_ Sometimes, the real enjoyment (in literature) comes in figuring out what the author really meant. Right. Unlike that kind of writing, in functional code like a computer program, ambiguity of meaning is a curse. Programmers, if you feel the urge to be subtle and clever and nuanced, take up poetry or literature as a separate pursuit. In your program source code, please be as straightforward and unambiguous and predictable as possible. -- \ “Very few things happen at the right time, and the rest do not | `\ happen at all. The conscientious historian will correct these | _o__) defects.” —Mark Twain, _A Horse's Tale_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On Thu, 26 May 2011 12:44:47 +, Neil Cerutti wrote: On 2011-05-25, Matty Sarro msa...@gmail.com wrote: General readability is a farce. If it was true we would only have one section to the library. Different people enjoy reading, and can comprehend better in different ways. THat's why some people are super verbose - hell, just look at this here post! :) Despite individual proclivities, there remain standards of readability enshrined in our dictionaries and grammar handbooks. Claiming that code readability of code is to be judged solely subjectively by each individual absolves code of the responsibility to communicate to more than just its author. Bravo! +1 Quote of the Thread -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: List of WindowsError error codes and meanings
Am 20.05.2011 19:56, schrieb Andrew Berg: This is probably somewhat off-topic, but where would I find a list of what each error code in WindowsError means? WindowsError is so broad that it could be difficult to decide what to do in an except clause. Fortunately, sys.exc_info()[1][0] holds the specific error code, so I could put in an if...elif...else clause inside the except clause if I needed to, but I don't know what all the different errors are. On Windows, you can use ctypes.FormatError(code) to map error codes to strings: import ctypes ctypes.FormatError(32) 'Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.' For HRESULT codes, you (unfortunately) have to subtract 2**32-1 from the error code: ctypes.FormatError(0x80040005) Traceback (most recent call last): File stdin, line 1, in module OverflowError: long int too large to convert to int ctypes.FormatError(0x80040005 - (2**32-1)) 'Kein Cache zum Verarbeiten vorhanden.' Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On 5/25/2011 7:52 PM, Steven D'Aprano wrote: On Wed, 25 May 2011 17:30:48 -0400, theg...@nospam.net wrote: On 5/24/2011 1:39 PM, D'Arcy J.M. Cain wrote: [snip] One of my favorite quotes (not sure if it was about Perl or APL) is I refuse to use a programming language where the proponents of it stick snippets under each other's nose and say 'I bet you can't guess what this does.' I dunno. That sounds about like how most programming course exams are written, no? The point is that puzzling through arcane bits of code are crucial to learning any language. It's a valuable exercise. You seem to miss the point that a good language shouldn't make it possible to write arcane code that needs to be puzzled out. You seem to be inventing a new point. Try to stay focused please. Perl hackers show each other arcane bits of code because such impractical puzzle programs are good for learning. Such puzzles can be created in any language. For example, I have had formal coursework in a number of languages (Pascal, C++, ML, Scheme, and others) and in each one an important exercise was to puzzle through arcane bits of code in each of those languages. The post I was replying to seemed to question the value of such 'I bet you can't guess what this does.' type challenges. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
Ben Finney b...@benfinney.id.au writes: Get a life. Or better, just fuck off and die. It will improve both the world and the Python community, of which you are nothing but a little, smelly shitstain. That abuse is entirely unwelcome in this community, against any person. Please desist. You should have spoken up sooner, especially as the spokes person of this community. But every bully has is fan club. -- John Bokma j3b Blog: http://johnbokma.com/Perl Consultancy: http://castleamber.com/ Perl for books:http://johnbokma.com/perl/help-in-exchange-for-books.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
So when quora.com fails we can all say it is Python's fault? Maybe they should have focused more on content instead of the bits under the hood? -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On 26/05/2011 06:17, Chris Rebert wrote: On Wed, May 25, 2011 at 9:46 PM, Uncle Benbgr...@nycap.rr.com wrote: In playing with lists of lists, I found the following: (In 3.1, but the same happens also in 2.7) list = [1,2,3] list.append ( [4,5,6] ) Note the lack of output after this line. This indicates that list.append([4,5,6]) returned None. Contrast this with, say, list.pop(). x = list x - [1,2,3,[4,5,6]] as expected. But the shortcut fails: list=[1,2,3] x = list.append( [4,5,6] ) x - nothing Can someone explain this to me? The append() method does *not* return the now-appended-to list. It is a mutator method that modifies the list object in-place; per convention, it therefore returns None to reinforce its side-effecting nature to the user (the interactive interpreter by default does not display None expression results); analogous methods in other languages return void. list.remove(), list.sort(), and list.extend() similarly return None rather than the now-modified list. I'd just like to point out that it's a convention, not a rigid rule. Sometimes it's not followed, for example, dict.setdefault. -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On Fri, May 27, 2011 at 1:58 AM, MRAB pyt...@mrabarnett.plus.com wrote: I'd just like to point out that it's a convention, not a rigid rule. Sometimes it's not followed, for example, dict.setdefault. dict.setdefault is more like dict.get but it also stores the result. It's probably more a name issue than a protocol issue. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
John, You say English is not your first language. Let me assure you that the words you chose to use in reply to Stephen were vulgar as well as rude, and did more to lesson the overall friendliness of this forum than Stephen's adversarial style. You usually have interesting and informative posts -- please don't resort to this tactic. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie question about SQLite + Python and twitter
On 5/25/2011 6:08 PM, Philip Semanchuk wrote: On May 25, 2011, at 2:17 PM, Jayme Proni Filho wrote: Helo guys, I'm building a local application for twitter for my brother's store. I'm in the beginning and I have some newbie problems, so: I create a table called tb_messages with int auto increment and varchar(140) fields; I did three SQL funcionts, insert_tweet, delete_tweet, select_tweet select_tweet is use for getting messages for sending them to twitter; My problem is: How can i make my select_tweet works at the same time that insert or delete funcions. I just got to work when I stop select function. I would like to do my app works all the time. Hi Jayme, You need to provide a lot more information for us to be able to help you. I suspect that the original poster's problem is that he's trying to delete items from a table while reading the results from a SELECT on the same table. SQL systems don't allow that. It has the same problem as, in Python, deleting from a dict while iterating over it. One way to do this properly is something like loop START TRANSACTION SELECT itemid, item FROM tablename WITH ... LIMIT 1 get one item if no item, break do whatever needs to be done with item DELETE FROM tablename WHERE itemid = %s END TRANSACTION Also, it sounds like he's writing a spam program for Twitter. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Python's super() considered super!
I just posted a tutorial and how-to guide for making effective use of super(). One of the reviewers, David Beazley, said, Wow, that's really great!I see this becoming the definitive post on the subject The direct link is: http://rhettinger.wordpress.com/2011/05/26/super-considered-super/ It would also be great if some of you would upvote it on HackerNews. Raymond Hettinger --- follow my python tips on twitter: @raymondh -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's super() considered super!
It would also be great if some of you would upvote it on HackerNews. Here's a link to the super() how-to-guide and commentary: bit.ly/ iFm8g3 Raymod -- http://mail.python.org/mailman/listinfo/python-list
Re: pyGTK identify a button
On Wed, 25 May 2011 10:18:48 +0200, Tracubik wrote: Hi all, i'm trying to write a simple windows with two button in GTK, i need a way to identify wich button is pressed. Consider that: the two button are connected (when clicked) to infoButton(self, widget, data=None) infoButton() is something like this infoButton(self, widget, data=None): # discover wich button was pressed ... # say hello to the button if button1pressed: print Hi, button1! else: print Hi, button2! so, how can I know wich button was pressed without using data and without reading the label of the button (i could have buttons with the same label) If data is needed, can someone pls tell me how to set it properly in glade 3.8 thanks Nico This looks similar to a question I posted about 2 weeks ago In gtk 2.1.6 (i think) earlier you could use widget.get_name() to return the id of the widget. this no-longer works since 2.1.7 the pygtk forum suggests this is because widget id's are not necessarily unique caused problems elsewhere, to be honest most of the explanation went above my head. I did find a work around that was to use gtk.buildable.get_name(widget) but is is probably cleaner to use a discrete callback for each button. -- Disco is to music what Etch-A-Sketch is to art. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's super() considered super!
On Thu, May 26, 2011 at 19:39, Raymond Hettinger pyt...@rcn.com wrote: It would also be great if some of you would upvote it on HackerNews. Here's a link to the super() how-to-guide and commentary: bit.ly/ iFm8g3 Is that the same link as in the OP? I don't click on blind links, so if it isn't then please post a direct link. Thanks. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On May 25, 9:46 pm, Uncle Ben bgr...@nycap.rr.com wrote: list = [1,2,3] Somewhat unrelated, but... is it a good idea to name your list list? Isn't that the name of Python's built-in list constructor method? Shadowing a built-in has contributed to more than one subtle bug in my code, and I've learned to avoid it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's super() considered super!
On Thu, May 26, 2011 at 12:13 PM, Dotan Cohen dotanco...@gmail.com wrote: On Thu, May 26, 2011 at 19:39, Raymond Hettinger pyt...@rcn.com wrote: It would also be great if some of you would upvote it on HackerNews. Here's a link to the super() how-to-guide and commentary: bit.ly/ iFm8g3 Is that the same link as in the OP? I don't click on blind links, so if it isn't then please post a direct link. Thanks. It's a link to ycombinator: http://news.ycombinator.com/item?id=2588262 -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On 5/26/2011 3:18 AM, Algis Kabaila wrote:
And why do you insist on calling an instance of list, list? Even a
human reader will confuse which is which. What you are showing is an
example how confusing things become when a keyword (list) is
over-written (with list instance).
(Minor note: 'list' is not a keyword (if it were, it could not be
over-ridden) but it is a builtin.) You are correct, it is confusing.
Such usage will also lead to bugs if one ever tries to access the class
as 'list' later in the program.
Here is a legitimate usage of builtins masking:
import builtins
def list(iterable):
print('building list from {}: {}'.format(type(iterable),iterable))
return builtins.list(iterable)
a = list((1,2,3))
b = list({1,2,3})
###
building list from class 'tuple': (1, 2, 3)
building list from class 'set': {1, 2, 3}
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
The worth of comments
On May 26, 2011, at 4:28 AM, python-list-requ...@python.org wrote: My experience is that comments in Python are of relatively low usefulness. (For avoidance of doubt: not *zero* usefulness, merely low.) I can name variables, functions and classes with sensible, self- documenting names. Why write: x = get_results(arg) # x is a list of 1 or more results [... much later] for y in x: # process each result in turn do_something_with(y) (It occurred to me that I should use a specific subject for this discussion.) I'm less inclined to use comments on each line, or selected lines, but rather use block comments instead. They require more thought and time to write; however, the intended functionality of the code that follows can be described in full. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's super() considered super!
On Thu, May 26, 2011 at 21:38, Ian Kelly ian.g.ke...@gmail.com wrote: It's a link to ycombinator: http://news.ycombinator.com/item?id=2588262 Thanks. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
python urllib2 data post over https
hello, I am using this code to send data over https with post method:
params='tieto data idu na sevrer\n'
kamodoslat = https://domena.tld/script.php;
req = urllib2.Request(kamodoslat)
req.add_header('User-Agent', 'agent')
resp = urllib2.urlopen(req, params)
how can I make sure that data were really sent over secured protocol
https and all communcation went through https?
--
http://mail.python.org/mailman/listinfo/python-list
RE: Puzzled by list-appending behavior
And why do you insist on calling an instance of list, list? Even a human reader will confuse which is which. What you are showing is an example how confusing things become when a keyword (list) is over-written (with list instance). (Minor note: 'list' is not a keyword (if it were, it could not be over-ridden) but it is a builtin.) You are correct, it is confusing. Such usage will also lead to bugs if one ever tries to access the class as 'list' later in the program. An example of overriding built-ins you *really* do not want to happen (python 2.6.4): True = False True == False True print True False From what I can tell, this does not work in Python 3.x (at least not in Python 3.1.1) Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On 5/26/2011 11:36 AM, John Bokma wrote: Ben Finneyb...@benfinney.id.au writes: [impolite comment not quoted] Get a life. Or better, just fuck off and die. It will improve both the world and the Python community, of which you are nothing but a little, smelly shitstain. That abuse is entirely unwelcome in this community, against any person. Please desist. You should have spoken up sooner, especially as the spokes person of this community. But every bully has is fan club. I agree that the original impolite comment was just that -- impolite -- and perhaps enough so that it should have been spoken out against. But I also agree that the quoted response is at least three times as bad, enough so to understandably push someone to respond. Both comments are atypical here. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's super() considered super!
On 5/26/2011 2:13 PM, Dotan Cohen wrote: On Thu, May 26, 2011 at 19:39, Raymond Hettingerpyt...@rcn.com wrote: It would also be great if some of you would upvote it on HackerNews. Here's a link to the super() how-to-guide and commentary: bit.ly/ iFm8g3 Is that the same link as in the OP? I don't click on blind links, so if it isn't then please post a direct link. Thanks. It is a link to HackerNews http://news.ycombinator.com/item?id=2588262 -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On 05/26/2011 10:03 PM, Terry Reedy wrote: On 5/26/2011 11:36 AM, John Bokma wrote: Ben Finneyb...@benfinney.id.au writes: [impolite comment not quoted] Get a life. Or better, just fuck off and die. It will improve both the world and the Python community, of which you are nothing but a little, smelly shitstain. That abuse is entirely unwelcome in this community, against any person. Please desist. You should have spoken up sooner, especially as the spokes person of this community. But every bully has is fan club. I agree that the original impolite comment was just that -- impolite -- and perhaps enough so that it should have been spoken out against. But I also agree that the quoted response is at least three times as bad, enough so to understandably push someone to respond. Both comments are atypical here. Original one impolite perhaps but only truth could cause such hatred. Cheers -- http://mail.python.org/mailman/listinfo/python-list
Re: The worth of comments
- Original Message - From: Richard Parker r.richardpar...@comcast.net To: python-list@python.org Sent: Thursday, May 26, 2011 11:50 AM Subject: The worth of comments On May 26, 2011, at 4:28 AM, python-list-requ...@python.org wrote: My experience is that comments in Python are of relatively low usefulness. (For avoidance of doubt: not *zero* usefulness, merely low.) I can name variables, functions and classes with sensible, self- documenting names. Why write: x = get_results(arg) # x is a list of 1 or more results [... much later] for y in x: # process each result in turn do_something_with(y) (It occurred to me that I should use a specific subject for this discussion.) I'm less inclined to use comments on each line, or selected lines, but rather use block comments instead. They require more thought and time to write; however, the intended functionality of the code that follows can be described in full. -- http://mail.python.org/mailman/listinfo/python-list Hello Richard - I was recently complimented in a phone screen interview for including comment blocks exactly as you describe above. Regards, Patty -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On Wed, May 25, 2011 at 3:10 AM, Octavian Rasnita orasn...@gmail.com wrote: Once again. Suppose we have array of key-value pairs (two-dimensional array), This is a forced example to fit the way Python can do it with a clean syntax, but I don't think there are cases in which somebody wants to create hashes/dictionaries where the key is not a plain string but an array. This is not a rare case, but a case that probably nobody needs, ever. This is far more popular case than converting flat lists into dicts in Python world. In fact, I *never* had need to convert flat list instead of properly structured one. Thats why we have both lists and tuples, after all. Sure, since perl does not support it at all, perl programmers do not use it and resort to idea of guess which values are keys by index due to lack of better approach, with need of obscure = pseudo-syntax to cover it up. -- With best regards, Daniel Kluev -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On 5/26/2011 11:58 AM, MRAB wrote: On 26/05/2011 06:17, Chris Rebert wrote: list.remove(), list.sort(), and list.extend() similarly return None rather than the now-modified list. I'd just like to point out that it's a convention, not a rigid rule. Sometimes it's not followed, for example, dict.setdefault. The rule for builtin collections is that mutation methods do not return the collection. If there is a member of the collection to return, they return that. Otherwise they return None. list/set.pop and dict.popitem are other mutation methods that have a (former) member to return. The rule applies to special methods like __getitem__ (returns an item) and __setitem__ (returns None). Since a.append(item) is *conceptually* equivalent to a.__setitem(len(a), item) (I know, it raises) and *actually* defined as a.__setitem(len(a):len(a), item), it should not be surprising that all three return None. I think the above should be better documented. http://bugs.python.org/issue12192 has some proposals. Comments there welcome. In another post On 5/26/2011 4:09 AM, Chris Rebert wrote: I'm just surprised that the docstring doesn't explicitly state Returns None. by this point, given that this is such a common point of newbie confusion. I never noticed. After reading the above, I added this to the proposal above. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On Thu, May 26, 2011 at 12:28 PM, sal migondis salmi...@gmail.com wrote: From: Thorsten Kampe thors...@thorstenkampe.de Subject: Re: English Idiom in Unix: Directory Recursively Date: Thu, 26 May 2011 12:46:58 +0200 To: python-list@python.org * Steven D'Aprano (26 May 2011 10:06:44 GMT) On Thu, 26 May 2011 10:48:07 +0200, Thorsten Kampe wrote: But not to digress, the /real/ problem with commands or idioms like rm -r is /not/ their choice of option names but that they explain these options in the exact same terms. No one would have a problem with -r, --recursive -- remove directories including all sub-directories instead of -r, --recursive -- remove directories and their contents recursively. I think you are understanding the description remove directories and their contents recursively as a description of the *mechanism* by which rm removes the directory, i.e. some recursive tree-walking function that visits each node and deletes it. I don't believe that's how the description is meant to be understood. I understand it as describing the effect, not the implementation. It doesn't matter how I interprete the explanation -r = recursively delete. [..] Quite the contrary.. and that's the whole issue: your superficial knowledge of the English language.. :-) You're interpreting the reference to recursive as a nod to the implementation. I'm not, and therefore your arguments don't convince me. No one understands what recursively delete means ... _We_ do.. :-) until someone explains (translates) it to him. This is not an argument but a simple fact. I experienced it many times, others here in the thread did and probably you, too. recursively delete is completely unneccessary because there is already a simple explanation that everyone understands without translation (delete including subdirectories). .. which is very poor 'style' indeed. Style is not a matter of aesthetics. It's all about clarity and expressiveness. It's about effectively communicating your thoughts to your audience. When I hear or read 'delete recursively', I immediately 'get the idea' and I can move on.. Now, if I heard 'delete including subdirectories', my first reaction would be.. ouch, I bet that hurts.. or ugh.. how ugly.. See, I'm distracted already. But it doesn't stop there.. After the initial jolt to my attention, I'd start thinking along the lines of.. hm. subdirectories.. now what about sub sub directories.. etc. not seriously, perhaps.. but by the time I got over it and was able to focus again on what was being said (or what I was reading) I would have lost the thread. This is why the author of the document puts paid to all the nonsense and instinctively uses 'recursively delete', not going into irrelevant details. It's that simple. It's unnecessary bullshit buzzword bingo from nerds which adds or helps or explains nothing. It's just that simple. This has nothing to do with buzzwords whatsoever. Despite polite hints from several other posters, the problem is that (like the OP) you are not a native speaker of English but you will not listen and still think you are qualified to make recommendations regarding usage and abusage in the English language. Sorry pal, but right here, you are like the kellet teaching the fishes to swim. Sal. -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
On May 26, 4:20 am, Thorsten Kampe thors...@thorstenkampe.de wrote: Did your mom tell you to recursively clean up your room?. that had me L O L! i think i'll quote in my unix hating blogs sometimes, if you don't mind. ☺ Xah -- http://mail.python.org/mailman/listinfo/python-list
bug in str.startswith() and str.endswith()
I've tried this in 2.5 - 3.2:
-- 'this is a test'.startswith('this')
True
-- 'this is a test'.startswith('this', None, None)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: slice indices must be integers or None or have an __index__
method
The 3.2 docs say this:
str.startswith(prefix[, start[, end]])
Return True if string starts with the prefix, otherwise return False.
prefix can also be a tuple of prefixes to look for. With optional start,
test string beginning at that position. With optional end, stop
comparing string at that position
str.endswith(suffix[, start[, end]])
Return True if the string ends with the specified suffix, otherwise
return False. suffix can also be a tuple of suffixes to look for. With
optional start, test beginning at that position. With optional end, stop
comparing at that position.
Any reason this is not a bug?
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: bug in str.startswith() and str.endswith()
On 27/05/2011 00:27, Ethan Furman wrote:
I've tried this in 2.5 - 3.2:
-- 'this is a test'.startswith('this')
True
-- 'this is a test'.startswith('this', None, None)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: slice indices must be integers or None or have an __index__
method
The 3.2 docs say this:
str.startswith(prefix[, start[, end]])
Return True if string starts with the prefix, otherwise return False.
prefix can also be a tuple of prefixes to look for. With optional start,
test string beginning at that position. With optional end, stop
comparing string at that position
str.endswith(suffix[, start[, end]])
Return True if the string ends with the specified suffix, otherwise
return False. suffix can also be a tuple of suffixes to look for. With
optional start, test beginning at that position. With optional end, stop
comparing at that position.
Any reason this is not a bug?
Let's see: 'start' and 'end' are optional, but aren't keyword
arguments, and can't be None...
I'd say bug.
--
http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
* sal migondis (Thu, 26 May 2011 17:50:32 -0400) On Thu, May 26, 2011 at 12:28 PM, sal migondis salmi...@gmail.com wrote: From: Thorsten Kampe thors...@thorstenkampe.de It's unnecessary bullshit buzzword bingo from nerds which adds or helps or explains nothing. It's just that simple. This has nothing to do with buzzwords whatsoever. Despite polite hints from several other posters, the problem is that (like the OP) you are not a native speaker of English but you will not listen and still think you are qualified to make recommendations regarding usage and abusage in the English language. *sigh* there is nothing in recursively delete which would be specific to English. It would be the same in French, Spanish, Italian or German (rekursiv löschen). Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On May 26, 5:33 pm, Daniel Kluev dan.kl...@gmail.com wrote: On Wed, May 25, 2011 at 3:10 AM, Octavian Rasnita orasn...@gmail.com wrote: Once again. Suppose we have array of key-value pairs (two-dimensional array), This is a forced example to fit the way Python can do it with a clean syntax, but I don't think there are cases in which somebody wants to create hashes/dictionaries where the key is not a plain string but an array. This is not a rare case, but a case that probably nobody needs, ever. This is far more popular case than converting flat lists into dicts in Python world. In fact, I *never* had need to convert flat list instead of properly structured one. Thats why we have both lists and tuples, after all. I agree that it's almost never needed to convert flat lists. I've used python for over 10 years and I remember exactly one time when I needed to do that. It turned out that it's a bit tricky and hacky to do in python, in the sense that it's hard to remember if I'll ever need it again, but it will only take minutes to google it. For example, in one piece of code I did recently I created a dict of range tuples and counts from a sequential list, like so: ranges = [(x*width, (x+1)*width) for x in range(y)] data = dict((x,0) for x in ranges) A perl programmer would instead create a flat list and then convert it to dict. And if he were new to python he'd create a flat list and then be annoyed that there's no quick and easy way to make it into a dict. Python way in this case is more structured and disciplined, and the only flaw I can see is that it doesn't meet expectations of perl programmers. -Rainy -- http://mail.python.org/mailman/listinfo/python-list
Re: Link errors embedding Python 3.2
Still trying to sort this out, trying various things. If I configure --enable-shared, I get a different ImportError: 'libpython3.3m.so.1.0: cannot open shared object file: No such file or directory'. That file exists in ~/cpython, but sudo make install doesn't put it anywhere else. Pointing LD_LIBRARY_PATH to there causes my program to segfault with thread context errors. Am I asking this in the wrong forum? Would it be more appropriate in python-dev? Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: bug in str.startswith() and str.endswith()
On Thursday, May 26, 2011 4:27:22 PM UTC-7, MRAB wrote:
On 27/05/2011 00:27, Ethan Furman wrote:
I've tried this in 2.5 - 3.2:
-- 'this is a test'.startswith('this')
True
-- 'this is a test'.startswith('this', None, None)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: slice indices must be integers or None or have an __index__
method
The 3.2 docs say this:
str.startswith(prefix[, start[, end]])
Return True if string starts with the prefix, otherwise return False.
prefix can also be a tuple of prefixes to look for. With optional start,
test string beginning at that position. With optional end, stop
comparing string at that position
str.endswith(suffix[, start[, end]])
Return True if the string ends with the specified suffix, otherwise
return False. suffix can also be a tuple of suffixes to look for. With
optional start, test beginning at that position. With optional end, stop
comparing at that position.
Any reason this is not a bug?
Let's see: 'start' and 'end' are optional, but aren't keyword
arguments, and can't be None...
I'd say bug.
I also say bug. The end parameter looks pretty useless for .startswith() and
is probably only present for consistency with other string search methods like
.index(). Yet on .index() using None as an argument works as intended:
cbcd.index(c,None,None)
0
So it's there for consistency, yet is not consistent.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: bug in str.startswith() and str.endswith()
Ethan Furman wrote:
I've tried this in 2.5 - 3.2:
-- 'this is a test'.startswith('this')
True
-- 'this is a test'.startswith('this', None, None)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: slice indices must be integers or None or have an __index__
method
The 3.2 docs say this:
str.startswith(prefix[, start[, end]])
Return True if string starts with the prefix, otherwise return False.
prefix can also be a tuple of prefixes to look for. With optional start,
test string beginning at that position. With optional end, stop
comparing string at that position
str.endswith(suffix[, start[, end]])
Return True if the string ends with the specified suffix, otherwise
return False. suffix can also be a tuple of suffixes to look for. With
optional start, test beginning at that position. With optional end, stop
comparing at that position.
Any reason this is not a bug?
It's a wart at the very least. The same thing happened in Python2 with
range and xrange; there seemed no way to explicitly pass default
arguments.
Mel.
--
http://mail.python.org/mailman/listinfo/python-list
Re: bug in str.startswith() and str.endswith()
In article mailman.2136.1306451668.9059.python-l...@python.org,
Ethan Furman et...@stoneleaf.us wrote:
-- 'this is a test'.startswith('this')
True
-- 'this is a test'.startswith('this', None, None)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: slice indices must be integers or None or have an __index__
method
[...]
Any reason this is not a bug?
+1 for it being a bug.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's super() considered super!
Raymond Hettinger pyt...@rcn.com writes: I just posted a tutorial and how-to guide for making effective use of super(). Thanks very much! We need articles like this. Raymond Hettinger pyt...@rcn.com writes: Here's a link to the super() how-to-guide and commentary: bit.ly/ iFm8g3 We also, though, need *real* URLs. Blind URLs through obfuscation services have their uses, but surely not in a forum like this. The real URL is URL:http://news.ycombinator.com/item?id=2588262. -- \“… it's best to confuse only one issue at a time.” —Brian W. | `\Kernighan and Dennis M. Ritchie, _The C programming language_, | _o__) 1988 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: The worth of comments
Richard Parker r.richardpar...@comcast.net writes: On May 26, 2011, at 4:28 AM, python-list-requ...@python.org wrote: My experience is that comments in Python are of relatively low usefulness. (For avoidance of doubt: not *zero* usefulness, merely low.) I can name variables, functions and classes with sensible, self- documenting names. I am largely in agreement with this position (including the “not *zero* usefulness” caveat). I'm less inclined to use comments on each line, or selected lines, but rather use block comments instead. They require more thought and time to write; however, the intended functionality of the code that follows can be described in full. This I disagree with. If a section of code is interesting enough to deserve an explanation, then it is better to capture it in a helpfully-named function with its doc string having the explanation. -- \“If this is your first visit to the USSR, you are welcome to | `\ it.” —hotel room, Moscow | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On Thu, 26 May 2011 11:27:35 -0700, John Ladasky wrote: On May 25, 9:46 pm, Uncle Ben bgr...@nycap.rr.com wrote: list = [1,2,3] Somewhat unrelated, but... is it a good idea to name your list list? Isn't that the name of Python's built-in list constructor method? Shadowing a built-in has contributed to more than one subtle bug in my code, and I've learned to avoid it. Agreed. However, there are good reasons for sometimes shadowing built- ins, and namespaces make it safe to do so if you are sufficiently careful. E.g. I have a module stats.sum() which shadows the built-in, but only in that module, which is exactly the behaviour I want. (If you do from stats import sum, then you're responsible for whatever happens next.) Or you might isolate the shadow to a function small enough that you can be sure that it won't cause any problems, e.g.: def get(list, object): Append object to a copy of list and return it. return list + [object] For one or two line functions, I think that's perfectly reasonable. Anything more than that, I'd be getting nervous. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The worth of comments
In article mailman.2126.1306435826.9059.python-l...@python.org, Richard Parker r.richardpar...@comcast.net wrote: On May 26, 2011, at 4:28 AM, python-list-requ...@python.org wrote: My experience is that comments in Python are of relatively low usefulness. (For avoidance of doubt: not *zero* usefulness, merely low.) I can name variables, functions and classes with sensible, self- documenting names. Why write: x = get_results(arg) # x is a list of 1 or more results [... much later] for y in x: # process each result in turn do_something_with(y) (It occurred to me that I should use a specific subject for this discussion.) I'm less inclined to use comments on each line, or selected lines, but rather use block comments instead. They require more thought and time to write; however, the intended functionality of the code that follows can be described in full. Over the years, my use of comments has evolved. I was taught, You should comment your code. Eventually, I came to realize that the real mandate is, You should make it easy to understand your code. Comments are just one possible tool to help achieve that goal. Some things that help code be understandable are: * Using good data structures * Using good algorithms * Breaking the code up into manageable pieces (i.e. functions, classes, methods), each of which encapsulates a single concept * Using descriptive names for variables (and functions, classes, methods, etc) All of those fall under the self-documenting code umbrella. But, while those things help, I find it's almost always a good idea to document interfaces, i.e. functions. What the arguments are (not just their types, but valid value ranges, and what they mean). What the function returns. What error conditions are possible. And, in general, what the dang thing does. In other words, enough information to use (and test) the function to its fullest extent without ever having to look at the source code. This stuff tends to go in a big block comment at the beginning of the function. Now, what makes Python interesting in this regard is that the big block comment becomes a doc string. You write exactly the same stuff, except now things like help() can get at it, and things like doctest can do even more interesting things with it (I don't actually use doctest, but I do appreciate its coolness). Comments scattered throughout the code tend to be warnings about tricky stuff, references to classic algorithms, references to ticket tracking systems, and the like. Sometimes it's an explanation of what the next bunch of lines of code are doing, although if you've got a lot of those, that's a hint that maybe you need to be refactoring instead. Sometimes I'll drop in suggestions to future maintainers like, consider refactoring with with perform_frobnitz_action(), or even, Don't change this without first talking to Fred! -- http://mail.python.org/mailman/listinfo/python-list
Re: Link errors embedding Python 3.2
In article BANLkTim=j9wzzv7owppmawxz52u2aop...@mail.gmail.com, Chris Angelico ros...@gmail.com wrote: Still trying to sort this out, trying various things. If I configure --enable-shared, I get a different ImportError: 'libpython3.3m.so.1.0: cannot open shared object file: No such file or directory'. That file exists in ~/cpython, but sudo make install doesn't put it anywhere else. Pointing LD_LIBRARY_PATH to there causes my program to segfault with thread context errors. Am I asking this in the wrong forum? Would it be more appropriate in python-dev? The discussion in http://bugs.python.org/issue4434 might be of some help. -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: bug in str.startswith() and str.endswith()
On 5/26/2011 7:27 PM, Ethan Furman wrote:
I've tried this in 2.5 - 3.2:
-- 'this is a test'.startswith('this')
True
-- 'this is a test'.startswith('this', None, None)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: slice indices must be integers or None or have an __index__
method
The 3.2 docs say this:
str.startswith(prefix[, start[, end]])
Return True if string starts with the prefix, otherwise return False.
prefix can also be a tuple of prefixes to look for. With optional start,
test string beginning at that position. With optional end, stop
comparing string at that position
To me, that says pretty clearly that start and end have to be
'positions', ie, ints or other index types. So I would say that the
error message is a bug. I see so reason why one would want to use None
rather that 0 for start or None rather than nothing for end.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
On Thu, 26 May 2011 16:03:58 -0400, Terry Reedy wrote: On 5/26/2011 11:36 AM, John Bokma wrote: Ben Finneyb...@benfinney.id.au writes: [impolite comment not quoted] Get a life. Or better, just fuck off and die. It will improve both the world and the Python community, of which you are nothing but a little, smelly shitstain. That abuse is entirely unwelcome in this community, against any person. Please desist. You should have spoken up sooner, especially as the spokes person of this community. But every bully has is fan club. I agree that the original impolite comment was just that -- impolite -- and perhaps enough so that it should have been spoken out against. Okay, I've stayed silent while people criticize me long enough. What exactly did I say that was impolite? Is this one of those things where it is impolite to say certain things in public even though in private everyone knows they are true? We all know that some people have adversarial views of all sorts of things, including computer languages. My language of choice is better than your language of choice. Most of us can probably name examples, or if not, it wouldn't take much effort on Google to find them. If we're honest to ourselves, we'd realise that we're all at least a *little bit* adversarial. XKCD's famous cartoon about People are WRONG on the Internet! is funny because we can so often relate to it. We really do think some languages are better than others, in objective ways as well as subjective, and want to support our language. That's partly why we're here, to give back to the language that we enjoy using. We're just more nuanced about our opinion than the trolls. And we also know that people keep going back to their language of choice for all sorts of reasons that aren't objective. Why do I keep going back to Pascal instead of C? I'll give you all sorts of objective reasons why I think Pascal is a better designed language, but the real reason is because it makes me comfortable. It was the first language I learned. Objectively, I should just drop it and move on, but I'm going to keep tilting at those windmills hoping to turn the tide of popular opinion and see a mass migration of C coders to Pascal... *cough* John threw down a distinct challenge: if Python is really so much better than Python [sic] readability wise, why do I have such a hard time dropping Perl and moving on? Am I really the only one who can hear the oh yeah smart guy at the start of that sentence? If this is one of those lines you're not allowed to cross, where everybody knows that people invest self-image in their job or choice of language (dammit, I'm a *Python coder*, I'd never stoop to writing COBOL! sort of thing) but you mustn't mention it because that would be impolite, well, screw that for a game of soldiers. Sometimes politeness is the grease that keeps society's wheels turning, and sometimes it's just blinkers that stops us from understanding ourselves and others. If I got it wrong about John, oh well, I said it was a guess, and trying to get inside someone else's head is always a chancy business. But the fact that he responded so aggressively instead of saying Ha, Freudian projection, much? hints that maybe I hit a button. Or maybe I just ran into him on a bad day. Projection? Yes, I cheerfully admit it. *My* self-image is partly I am a Python coder, not an enterprise Java suit or a VB code monkey. It's more complicated than that, of course, but let's remember also that the Perl community is *full* of people who self-identify as Just Another Perl Hacker. John, I'd apologise if I thought I said something rude or nasty to you, but I don't, so I don't believe I have anything to apologise for. But I will say that I regret that you took it as an attack, and assure you that it was not meant that way. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On Fri, May 27, 2011 at 11:59 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: def get(list, object): Append object to a copy of list and return it. return list + [object] For one or two line functions, I think that's perfectly reasonable. Anything more than that, I'd be getting nervous. But even for something that short, why do it? Why not call the parameter 'lst' or something? Shadowing with something completely different is seldom going to give major advantage, and has the potential to be quite confusing. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: bug in str.startswith() and str.endswith()
On Thu, 26 May 2011 23:00:32 -0400, Terry Reedy wrote: [...] To me, that says pretty clearly that start and end have to be 'positions', ie, ints or other index types. So I would say that the error message is a bug. I see so reason why one would want to use None rather that 0 for start or None rather than nothing for end. def my_string_function(source, x, y, z, start, end): if source.startswith(x+y+z, start, end): ... I want sensible defaults for start and end. What should I set them to? def my_string_function(source, x, y, z, start=0, end=None): if end is None: flag = source.startswith(x+y+z, start) else: flag = source.startswith(x+y+z, start, end) if flag: ... Yuck. Perhaps a better alternative is: def my_string_function(source, x, y, z, start=0, end=None): t = (start,) if end is None else (start, end) if source.startswith(x+y+z, *t): ... but that's still pretty icky. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Why did Quora choose Python for its development?
John Bokma wrote:
A Perl programmer will call this line noise:
double_word_re = re.compile(r\b(?Pword\w+)\s+(?P=word)(?!\w),
re.IGNORECASE)
for match in double_word_re.finditer(text):
print ({0} is duplicated.format(match.group(word))
Actually, Python programmers would tend to call the RE part
of that line noise, too.
It's for that reason that we tend to avoid using REs when
possible, reaching for them only as a tool of last resort.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On Fri, 27 May 2011 13:24:24 +1000, Chris Angelico wrote: On Fri, May 27, 2011 at 11:59 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: def get(list, object): Append object to a copy of list and return it. return list + [object] For one or two line functions, I think that's perfectly reasonable. Anything more than that, I'd be getting nervous. But even for something that short, why do it? Why not call the parameter 'lst' or something? Shadowing with something completely different is seldom going to give major advantage, and has the potential to be quite confusing. Because lst is not a real word. To native readers of languages derived from Latin or Germany, such as English, it is quite a strange word because it has no vowel. In addition, it looks like 1st (first). We use naming conventions like my_list list_ lst alist etc. to avoid shadowing the built-in list, not because they are good to use in and of themselves. (E.g. we don't write my_tree because there's no tree to shadow.) All of these are ugly to some extent, which is to say, they cause some small, or not so small, additional cognitive load to the reader. We don't use the name list_ because we like trailing underscores! We do it because it avoids the cost of shadowing a built-in. But in a small function, there's no real cost to shadowing, so why bother? Any hypothetical confusion caused is no greater than, and probably less than, the increased difficulty in reading any of the alternatives. Either way, we're talking micro-optimizations in readability here. Don't get hung up over the choice of a name. If you'd rather never shadow, I'm fine with that too. I just think never shadow is unnecessarily strict. Sometimes shadowing is harmless, and sometimes it's useful. If you're writing a tutorial for beginners, shadowing a built-in without explanation will cause confusion, but for production code, I think it reasonable to assume the reader knows Python well enough not to stumble over that choice. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzled by list-appending behavior
On Fri, May 27, 2011 at 1:52 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Because lst is not a real word. To native readers of languages derived from Latin or Germany, such as English, it is quite a strange word because it has no vowel. In addition, it looks like 1st (first). Contrived examples are always awkward; in real examples, there's often an alternative based on the list's purpose, which can then be used to offer a name. Sometimes shadowing is harmless, and sometimes it's useful. Agreed on both those halves; and obviously, the times where it's useful are very much important. I have to say, I do like Python's lack of keywords for these things; the ability to shadow is a flexibility that means that, for the most part, new builtins can be added to the language without breaking existing code. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: bug in str.startswith() and str.endswith()
Roy Smith, 27.05.2011 03:13:
Ethan Furman wrote:
-- 'this is a test'.startswith('this')
True
-- 'this is a test'.startswith('this', None, None)
Traceback (most recent call last):
File stdin, line 1, inmodule
TypeError: slice indices must be integers or None or have an __index__
method
[...]
Any reason this is not a bug?
+1 for it being a bug.
Meaning that the right thing to do at this point is to file a bug report.
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: The worth of comments
On Fri, May 27, 2011 at 12:08 PM, Roy Smith r...@panix.com wrote: Sometimes I'll drop in suggestions to future maintainers like, consider refactoring with with perform_frobnitz_action() Usually, I address future-me with comments like that (on the assumption that there's nobody in the world sadistic enough to want to maintain my code). But I never name future-me, the comments will be addressed to the subsequent maintainer or somesuch. I do assume, though, that future-me has forgotten everything about the code, and since past-me left some comments that current-me has read, I think the assumption is fairly accurate. (Did I *really* write that code? It has my name on it.) Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
[issue12182] pydoc.py integer division problem
Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: - ncoghlan nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12174] Multiprocessing logging levels unclear
Changes by Nick Coghlan ncogh...@gmail.com: -- nosy: +jnoller, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12174 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12164] str.translate docstring doesn't mention that 'table' can be None
Changes by Petri Lehtinen pe...@digip.org: -- keywords: +patch nosy: +petri.lehtinen Added file: http://bugs.python.org/file22122/str_translate_docstring.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11109] socketserver.ForkingMixIn leaves zombies, also fails to reap all zombies in one pass
Justin Warkentin justin.warken...@gmail.com added the comment: Sorry, I haven't had a chance to look at this in a couple days. I've been very busy with work. I'm not sure exactly how to write the test for this, so I don't know that I'd be much help there. One last thing, I was just looking through the commits and I noticed in the NEWS update (http://hg.python.org/cpython/rev/3e3cd0ed82bb/) you have my name as Justin Wark. The last name is actually Warkentin, I just didn't have anything showing that. That's my fault, sorry. I just updated my profile to show my full name. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11109 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12157] join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty
Changes by Petri Lehtinen pe...@digip.org: -- nosy: +petri.lehtinen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12161] StringIO AttributeError instead of ValueError after close..
Petri Lehtinen pe...@digip.org added the comment: I tested the patch on current 2.7 tip. It works and looks good to me. -- nosy: +benjamin.peterson, petri.lehtinen, pitrou, stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12161 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11969] Can't launch multiproccessing.Process on methods
Ram Rachum cool...@cool-rr.com added the comment: Why is this still marked as test needed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11969] Can't launch multiproccessing.Process on methods
Ezio Melotti ezio.melo...@gmail.com added the comment: The test should be a diff against Lib/test/test_multiprocessing.py that adds a unit test. -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12082] Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT
Petri Lehtinen pe...@digip.org added the comment: Should the .pyc/.pyo file writing be disabled altogether if stat() and/or fstat() is not available. In this case, there's no way to check mtimes, right? -- nosy: +brett.cannon, ncoghlan, petri.lehtinen versions: +Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12082 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
Petri Lehtinen pe...@digip.org added the comment: IMO it should be explained in a comment why getattr is used instead of just self._child_created. Otherwise the patch looks good and useful. -- nosy: +petri.lehtinen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
STINNER Victor victor.stin...@haypocalc.com added the comment: We can use a class attribute to set the attribute before calling __init__: diff --git a/Lib/subprocess.py b/Lib/subprocess.py --- a/Lib/subprocess.py +++ b/Lib/subprocess.py @@ -664,6 +664,8 @@ _PLATFORM_DEFAULT_CLOSE_FDS = object() class Popen(object): +_child_created = False + def __init__(self, args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=_PLATFORM_DEFAULT_CLOSE_FDS, -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
Petri Lehtinen pe...@digip.org added the comment: STINNER Victor wrote: We can use a class attribute to set the attribute before calling __init__: True, this is clever. Will you commit? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
STINNER Victor victor.stin...@haypocalc.com added the comment: True, this is clever. Will you commit? I'm not sure that it's the pythonic way to solve such problem. Can you work on a patch including a test? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
Petri Lehtinen pe...@digip.org added the comment: I'm not sure that it's the pythonic way to solve such problem. Can you work on a patch including a test? Yeah, getattr() might be more Pythonic indeed. How can this be tested? According to the initial report, exceptions raised in __del__ seem to be ignored. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12082] Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT
STINNER Victor victor.stin...@haypocalc.com added the comment: Does your filesystem store the modification time? Why don't you have/want fstat()? Do you have stat() or a similar function? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12082 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12182] pydoc.py integer division problem
Roundup Robot devnull@devnull added the comment: New changeset 7724b53510c4 by Victor Stinner in branch '2.7': Close #12182: Fix pydoc.HTMLDoc.multicolumn() if Python uses the new (true) http://hg.python.org/cpython/rev/7724b53510c4 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12182] pydoc.py integer division problem
STINNER Victor victor.stin...@haypocalc.com added the comment: Patch applied, thanks for your patch! -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12171] Reset method of the incremental encoders of CJK codecs calls the decoder reset function
Walter Dörwald wal...@livinglogic.de added the comment: +1 on the documentation changes. -- nosy: +doerwalter ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12171 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12185] Decimal documentation lists first and second arguments, should be self and other
New submission from Eric V. Smith e...@trueblade.com: http://docs.python.org/library/decimal.html In 9.4.2, Decimal objects, some of the methods mention the first and second parameters, when really it should be self and the argument, usually named other and sometimes something more specific. These include: compare_total copy_sign next_toward quantize (argument is exp) rotate scaleb shift It looks this is left over from where the same-named functions are described in the Context objects section. -- assignee: docs@python components: Documentation messages: 136947 nosy: docs@python, eric.smith priority: normal severity: normal status: open title: Decimal documentation lists first and second arguments, should be self and other versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
Oleg Oshmyan chor...@inbox.lv added the comment: We can use a class attribute to set the attribute before calling __init__ Ah, yes, I thought about adding a class attribute as well, but the class currently does not have any and initializes instance attributes to default values in __init__, so I chose getattr. How can this be tested? According to the initial report, exceptions raised in __del__ seem to be ignored. Exceptions raised in __del__ are printed to sys.stderr, even if it has been reassigned by Python code: import sys, io, subprocess sys.stderr = io.StringIO() subprocess.Popen(fdsa=1) sys.stderr.getvalue() 'Exception AttributeError: \'Popen\' object has no attribute \'_child_created\' in bound method Popen.__del__ of subprocess.Popen object at 0x1006ee710 ignored\nTraceback (most recent call last):\n File stdin, line 1, in module\nTypeError: __init__() got an unexpected keyword argument \'fdsa\'\n' test_generators.py already uses this trick in a test similar to what would be needed for this issue around line 1856. Should I attempt to modify my patch to include a comment and a test? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
STINNER Victor victor.stin...@haypocalc.com added the comment: Should I attempt to modify my patch to include a comment and a test? Yes please, you can use support.captured_stderr() tool. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
Petri Lehtinen pe...@digip.org added the comment: Oleg Oshmyan wrote: Should I attempt to modify my patch to include a comment and a test? Absolutely, go ahead if it's not too much trouble. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12186] readline.replace_history_item still leaks memory
New submission from stefanholek ste...@epy.co.at:
This is a continuation of issue #9450.
The 'data' element of a history entry may point to an undo list for the entry.
When freeing the entry the associated undo list must be freed as well, and
'free(data)' alone does not cut it. I have not found any other use of the
'data' element in all of GNU Readline, so it is safe to assume it is either
NULL or an undo list.
diff --git a/rl/readline.c b/rl/readline.c
index 26ac1e2..c8efd5b 100644
--- a/rl/readline.c
+++ b/rl/readline.c
@@ -541,8 +541,18 @@
static void
_py_free_history_entry(HIST_ENTRY *entry)
{
- histdata_t data = free_history_entry(entry);
- free(data);
+ UNDO_LIST *undo_list;
+ UNDO_LIST *release;
+
+ /* A history entry may have an undo_list attached */
+ undo_list = (UNDO_LIST *)free_history_entry(entry);
+ while (undo_list) {
+ release = undo_list;
+ undo_list = undo_list-next;
+ if (release-what == UNDO_DELETE)
+ free(release-text);
+ free(release);
+ }
}
--
components: Library (Lib)
messages: 136951
nosy: stefanholek
priority: normal
severity: normal
status: open
title: readline.replace_history_item still leaks memory
type: resource usage
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12186
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12085] subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
Oleg Oshmyan chor...@inbox.lv added the comment: Here is a new patch; please take a look. Do I understand correctly that I should now remove the old one? -- Added file: http://bugs.python.org/file22123/_child_created_2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12184] socketserver.ForkingMixin collect_children routine needs to collect only it's children
Charles-François Natali neolo...@free.fr added the comment: In the common case, I don't think that the os.waitpid(0, 0) is the hot spot, but rather this: for child in self.active_children: os.waitpid(child, os.WNOHANG) It's called every time, and it's O(number of active children). os.waitpid(0, 0) is only called when max_children (40) is reached. Also, I'm not sure why it's called without WNOHANG, because that means that we will block until active_children falls below max_children. That's an arbitrary limit, especially since it's not documented. I've written a first draft patch using process group, that removes active_children and max_children. The only slightly tricky part is the call to setpgid from the child and from the parent, to avoid a race where the child could try to join a stale PGID. Note that I assume that setpgid is available on every Unix, since according to http://pubs.opengroup.org/onlinepubs/007908799/xsh/setpgid.html , it's Derived from the POSIX.1-1988 standard. Also, according to buildbots' configure logs, it's available everywhere. -- keywords: +patch Added file: http://bugs.python.org/file22124/ss_wait_group.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
Erik Cederstrand e...@1calendar.dk added the comment: Uploaded patch adding unit tests for %V and %u. Patch is against python2.7 -- Added file: http://bugs.python.org/file22125/test_strptime.py.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %V or %u directive from libc
Erik Cederstrand e...@1calendar.dk added the comment: Patch by aganders3 doesn't compile. Added comments in review of his patch. Adding a patch against python2.7 with my changes, which pass all unit tests posted previously. -- Added file: http://bugs.python.org/file22126/_strptime.py.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
