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 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 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 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 wrote: > En Sun, 22 May 2011 10:42:08 -0300, Selvam > 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 wrote: > On Thu, May 26, 2011 at 5:20 PM, Chris Angelico 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 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 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 > 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
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.org&group=gmane.comp.python.devel&sort=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 fo
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" wrote in message news:[email protected]... > > 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" wrote in message > news:[email protected]... > > > > 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 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 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 <[email protected]>, Neil Cerutti wrote: > On 2011-05-25, Matty Sarro 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 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 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 "", line 1, in 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, [email protected] 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 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 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] ) 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 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 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 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 wrote: > On Thu, May 26, 2011 at 19:39, Raymond Hettinger 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 : (1, 2, 3)
building list from : {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, [email protected] 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 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 Finney 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 Hettinger 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 Finney 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" To: Sent: Thursday, May 26, 2011 11:50 AM Subject: The worth of comments On May 26, 2011, at 4:28 AM, [email protected] 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 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 wrote: > From: Thorsten Kampe > Subject: Re: English Idiom in Unix: Directory Recursively > Date: Thu, 26 May 2011 12:46:58 +0200 > To: [email protected] > > * 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 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 "", line 1, in
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 "", line 1, in
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
> wrote:
> > From: Thorsten Kampe
> > 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 wrote: > On Wed, May 25, 2011 at 3:10 AM, Octavian Rasnita 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 "", line 1, in
> > 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 "", line 1, in
> 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 ,
Ethan Furman wrote:
> --> 'this is a test'.startswith('this')
> True
> --> 'this is a test'.startswith('this', None, None)
> Traceback (most recent call last):
>File "", line 1, in
> 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 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 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 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 writes: > On May 26, 2011, at 4:28 AM, [email protected] 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 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 , Richard Parker wrote: > On May 26, 2011, at 4:28 AM, [email protected] 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 , Chris Angelico 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, [email protected] -- 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 "", line 1, in
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 Finney 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 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(?P\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 > 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 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 "", line 1, in
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 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
Re: Puzzled by list-appending behavior
MRAB wrote: > >I'd just like to point out that it's a convention, not a rigid rule. Reminds me of the catch-phrase from the first Pirates of the Caribbean movie: "It's more of a guideline than a rule." -- Tim Roberts, [email protected] Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
