Re: Why doesn't threading.join() return a value?
On 2011-09-02, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Roy Smith wrote: I have a function I want to run in a thread and return a value. It seems like the most obvious way to do this is to have my target function return the value, the Thread object stash that someplace, and return it as the return value for join(). Yes, I know there's other ways for a thread to return values (pass the target a queue, for example), but making the return value of the target function available would have been the most convenient. I'm curious why threading wasn't implemented this way. Because then the code launching the thread would have to block, waiting until the thread is completed, so it will have a result to return. Isn't waiting until the thread is completed sort of the point of join()? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-31, Chris Torek nos...@torek.net wrote: (I realize this thread is old. I have been away for a few weeks. I read through the whole thread, though, and did not see anyone bring up this one particular point: there is already a linting script that handles this.) Yes. I've found pylint... A weird mix of very helpful, thanks and oh, come off it. A thread about pylint is where I got my example of the natural Python way to express a parabola: theValueRepresentingTheYAxisLocationOfThePoint = theValueRepresentingTheXAxisLocationOfThe Point * theValueRepresentingTheXAxisLocationOfThe Point I still say that there are times when short names are natural and idiomatic, and much clearer than long names. :P But I do think that, given the basic assumption that pylint is a core tool for vetting code, it is probably adequate for it to provide the warnings. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: A tale of yak shaving
On 2011-08-29, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: This is not exactly fresh (it was written back in March), but it's the first time I saw it and I thought I'd share. Barry Warsaw, one of the lead Python developers, describes one of his most ... interesting ... debugging experiences. That is a truly excellent debugging story. I also like the term yak shaving, and I suspect I'll be using that for future such endeavors. Of which there are a fair number in my line of work. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On 2011-08-23, smith jack thinke...@gmail.com wrote: i have heard that function invocation in python is expensive, but make lots of functions are a good design habit in many other languages, so is there any principle when writing python function? Lots of them. None of them have to do with performance. for example, how many lines should form a function? Between zero (which has to be written pass) and a few hundred. Usually closer to the lower end of that range. Occasionally outside it. Which is to say: This is the wrong question. Let us give you the two laws of software optimization. Law #1: Don't do it. If you try to optimize stuff, you will waste a ton of time doing things that, it turns out, are unimportant. Law #2: (Experts only.) Don't do it yet. You don't know enough to optimize this yet. Write something that does what it is supposed to do and which you understand clearly. See how it looks. If it looks like it is running well enough, STOP. You are done. Now, if it is too slow, and you are running it on real data, NOW it is time to think about why it is slow. And the solution there is not to read abstract theories about your language, but to profile it -- actually time execution and find out where the time goes. I've been writing code, and making it faster, for some longish period of time. I have not yet ever in any language found cause to worry about function call overhead. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: truncating strings
On 2011-08-23, Roy Smith r...@panix.com wrote:
I want to log a string but only the first bunch of it, and add ...
to the end if it got truncated. This certainly works:
logger.error(FAILED: '%s{50}', '%s', %s, %s % (message,
route, params, e.code))
does anything like this exist?
%.50s
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: truncating strings
On 2011-08-23, Ethan Furman et...@stoneleaf.us wrote:
Seebs wrote:
On 2011-08-23, Roy Smith r...@panix.com wrote:
logger.error(FAILED: '%s{50}', '%s', %s, %s % (message,
route, params, e.code))
does anything like this exist?
%.50s
That's not working in 2.7 or 3.2.
Huh.
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type help, copyright, credits or license for more information.
print %.5s % (hello there, truncate me!)
hello
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: truncating strings
On 2011-08-23, Ethan Furman et...@stoneleaf.us wrote: Ah -- that's only part of it -- the OP wants '...' to print as well. :) O. Hmm. That's harder. I can't think of a pretty way, so I think I'd probably write a prettytrunc(string, len) or something similar. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: relative speed of incremention syntaxes (or i=i+1 VS i+=1)
On 2011-08-21, Andreas L?scher andreas.loesc...@s2005.tu-chemnitz.de wrote: Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith: In article mailman.282.1313951079.27778.python-l...@python.org, Christian Heimes li...@cheimes.de wrote: I don't think that's the reason. Modern compiles turn a switch statement into a jump or branch table rather than a linear search like chained elif statements. This is true even for very small values of modern. I remember the Unix v6 C compiler (circa 1977) was able to do this. What is the difference in speed between a jump table that is searched from top to bottom A jump table isn't searched, it's jumped into. You don't look through the table for a matching element, you grab the Nth element of the table. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: try... except with unknown error types
On 2011-08-19, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Even if you don't think it's the ethical thing to do, consider that someday you might be maintaining code written by the OP :) A common further conclusion people reach is but then I will be able to get a job fixing it! Trust me, this is NOT where you want to go. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: List spam
On 2011-08-18, Prasad, Ramit ramit.pra...@jpmorgan.com wrote: Or 'Enter a Python keyword (search the tutorial if you do not know any) ' Sounds good, but now you've trained the spammer who is without a doubt watching this list. Teach them Python before they can post, I like it! I don't. If I want to get started in a language, I might well want to read about it a bit, and maybe ask questions like what is a good book for me to start with? If I have to know the language to do that, well... -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Word Perfect integration
On 2011-08-18, Ethan Furman et...@stoneleaf.us wrote: Yes, we still use Word Perfect, and will as long as it is available. The ability to see the codes in use (bold, margins, columns, etc) has so far been unequaled in anything else I have looked at. I have used other software that had this functionality, but not so much lately. (Although it appears that PageStream still does this, which is totally of relevance to someone, I'm sure.) But yeah, that was an AMAZING feature, and not having it is one of the reasons I'm so often unable to get things done in MS Word. Sadly, Corel dropped Mac and Linux support, and I don't do real work on Windows, so WP has been off my list for a long time now. :( -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 2011-08-17, John Doe jdoe@usenetlove.invalid wrote: Context is lost when you quote only one level. Not significantly. I was not answering a question about my code. I was pointing out the fact that my questioner's terminology is strange/corrupt. Well, that's the thing. There was a question there, with perfectly valid terminology. If you do, it suggests that perhaps one or more of the terms are unfamiliar to you? Yes, even the common term command line is foreign to me. I do some powerful stuff in Windows, without need for a command line. So apparently you *do* know the term. Normally, to say that a term is foreign to you is to say that you have no idea what it means, not that you know what it means but don't use it. I realize it exists and that some people live by it, but it has been nearly useless to me. In which case, you're not using a command line, and are using a GUI, and the other poster's question is answered. The Google results you cite to are uninteresting and frankly irrelevant. If someone asks me whether the ornamental fish in my 55-gallon tank is a koi, that Google has no hits for ornamental fish in your 55-gallon tank is a koi does not mean that the terminology is strange or corrupt. The terminology was fine. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 2011-08-17, peter peter.mos...@talk21.com wrote: Is there an equivalent to msvcrt for Linux users? I haven't found one, and have resorted to some very clumsy code which turns off keyboard excho then reads stdin. Seems such an obvious thing to want to do I am surprised there is not a standard library module for it. Or have I missed someting (wouldn't be the first time!) There's no direct equivalent to the whole of msvcrt. The Unixy way to do stuff like that on the command line is usually curses. But to make a long story short: Unix evolved in a setting where there was often not a user at *THE* console, and users were often on devices such that it made sense to have all the line editing happen on the remote end, with the remote end sending a completed line once the user was done with all that stuff like backspaces. Unix programs that do stuff like this for tty input do exist, of course, but for the most part, they use an entire API designed for creating such utilities, rather than one or two specialized functions. (Another part of the reason for this: The Unix solution scales nicely to the case where the five people using your program will be doing so on physically different hardware terminals which don't use the same escape sequences for cursor movement.) Usually when people omit something obvious from a design, it's because of other constraints or history to the design which make it less obvious. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Chris Angelico ros...@gmail.com wrote: def foo(list): Foo's the list provided and returns True on success or False on failure. def bar(list): Counts the number of bars in the list, assuming it to be made of music. if not foo(list): return You call foo() once and bar() twice. How many shadowings have there been? How many warnings do you get? I'd say two, one when def foo... is parsed, one when def bar... is parsed. A simple implementation would give five warnings for this case - once for each invocation that shadows a builtin. Another simple implementation would give two warnings, at the time that the def statements are executed; this is preferred, but it's still two warnings, and if you have a huge set of functions that do this, that can easily be lines and lines of warnings. Or should it set a flag and say I've already warned this session about shadowing 'list', so suppress all others? That seems confusing. I guess I don't object to multiple warnings if I do the same thing multiple times. I was just thinking in terms of a single parse-time warning for the actual point at which something is shadowed, rather than, say, a warning every time a name is hit during execution of statements and refers to a shadow. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Wed, 17 Aug 2011 01:17 pm Seebs wrote: [...] Another scope is normally a horizontal thing -- you're talking about a different scope such that you are *either* in this one *or* in that one. Built-ins are not in a scope you are never not in. That's technically incorrect. Built-ins are a scope you are never in, if by in you mean code is executed in this scope. No, by in I mean lookups from your code will reach this scope if they don't find something sooner. Hmm. See, I've never reached that, in Python or any other language. I figure it creates a new potential for confusion, and that I would rather avoid any ambiguity. I don't *like* ambiguity in code. Ah, well you see the thing is, this is Python. As soon as you call any function you don't control, you no longer know what your environment is with any certainty. For all you know, the harmless-looking function is monkey-patching builtins like there's no tomorrow. Speaking broadly, perhaps too broadly, we're incredibly proud of the ability to modify nearly everything at runtime. Heh. Fortunately, while we are proud of having that ability, actually *using* it is considered a mortal sin. We're not Ruby developers -- if you actually monkey-patch something, especially built-ins, you can expect to be taken outside and slapped around with a fish if you get caught. Okay, so. Here's what I don't get. If it's such a bad thing, *why is it allowed*? Why are you proud of the ability to do something that you are never socially-allowed to do? I have mixed feelings about Ruby's general tolerance for monkey-patching, although I've seen it do some pretty awesome things, so I am somewhat inclined to accept that it may be worth it. But it's clearly a feature which is used intentionally. It sounds to me like Python is very proud of having a feature which no one would ever use. ... Why? Sure. But they can't have that certainty regardless of whether you shadow something, because how do they know whether you've shadowed it or not? Well, they could trust me. :) In theory, anything could be anything at any time, and you have no protection. In practice, I worry more about being eaten by genetically-engineered flying piranhas than about rogue monkey-patching code. I do too, if I know that people don't shadow built-ins. If I know that people are shadowing built-ins, then some of the time, when I'm editing other peoples' code, they HAVE effectively monkey-patched it. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 2011-08-17, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I shouldn't need to say this to anyone over the age of four, but being obnoxious to people trying to help does not encourage others to answer your question. You don't win points for insulting people who are trying to solve your problems. The frustrating part, of course, is that the people who do this are doing it for reasons such that the explanation seems only proof that they are even more right than they had previously expected. Pathological narcissism is scary. If you ever find yourself going longer than usual without being wrong, start checking your work more carefully. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 2011-08-17, Terry Reedy tjre...@udel.edu wrote: The difference is between Hit enter to continue (which we can do in portable Python) versus Hit any key to continue (which we cannot, and which also leads to the joke about people searching for the 'any' key ;-). And more importantly, frustration and confusion when people pick control or shift. The equivalent contrast for GUIs is Click OK to continue versus Click anywhere to continue If having to click a specific area is okay for GUIs, having to hit a specific key for TUIs should be also. In general I agree. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Ethan Furman et...@stoneleaf.us wrote: Seebs wrote: On 2011-08-17, Steven D'Aprano wrote: Ah, well you see the thing is, this is Python. As soon as you call any function you don't control, you no longer know what your environment is with any certainty. For all you know, the harmless-looking function is monkey-patching builtins like there's no tomorrow. Speaking broadly, perhaps too broadly, we're incredibly proud of the ability to modify nearly everything at runtime. Fortunately, while we are proud of having that ability, actually *using* it is considered a mortal sin. We're not Ruby developers -- if you actually monkey-patch something, especially built-ins, you can expect to be taken outside and slapped around with a fish if you get caught. Here's what I don't get. If it's such a bad thing, *why is it allowed*? Why are you proud of the ability to do something that you are never socially-allowed to do? Monkey-patching built-ins would be something along the lines of import sys sys.modules['__builtin__'].str = my_super_string and is what stands you in jeopardy of being fish-slapped. ;) Merely shadowing a built-in, or stdlib, or whatever, isn't monkey-patching. Oh, I know. I was just noticing that Steven's post is specifically talking about how Python users are proud of having the ability to monkey-patch. If monkey-patching like that is a mortal sin, leads to fish-slapping, and so on.. Why is it possible? Why not just reject such things as invalid code? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Chris Angelico ros...@gmail.com wrote: On Wed, Aug 17, 2011 at 5:33 PM, Seebs usenet-nos...@seebs.net wrote: If it's such a bad thing, *why is it allowed*? ?Why are you proud of the ability to do something that you are never socially-allowed to do? Going back to my original three examples: I may have been unclear about jumping topics; that comment was about monkey-patching, not about shadowing. I greatly prefer this to the alternative, which is another 133 reserved words (based on Python 3.2 for Windows). You have a point there. I guess I'm just used to the assumption that the confusion caused by shadowing names outweighs the benefits of using them -- the world is rich with plausible names. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Ethan Furman et...@stoneleaf.us wrote: Part of the fun of Python is experimentation. And how much fun is it to be told over and over, No, you can't do that? Okay, I buy that. Actually, this sort of fits with my experience of how (sane) people do it in Ruby. And I'm really the wrong person to criticize people for monkey-patching: http://www.yoctoproject.org/projects/pseudo (In which I monkeypatch *the entire Unix filesystem API*. On Linux and OS X. For C programs.) I guess maybe my question shouldn't have been why is it allowed, but and why is it bad to use it? It just seemed like you should never do this, it's horrible and we're proud of being able to do this were not entirely compatible. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Anyone here can do a comparation between Djang and RoR
On 2011-08-16, smith jack thinke...@gmail.com wrote: what is the advantage of Django over RoR:) This question is pretty much... I mean, you're not gonna get useful answers. They're based on such different languages that I think any comparison past that is likely going to be uninteresting to a programmer, and I'm not sure any non-programmers are going to use either. I will say, the things I most value in Rails are pretty much contrary to conventional Python design philosophy. Python's stress on explicit over implicit is probably in contradiction with the Rails philosophy of convention over configuration. So for instance, if all you want of a class that maps to a database table in Rails is that it map the fields in the database, the class body is empty because that's the default. If you want to tell it that the database column foo_id represents the id of the foo object with which this record is associated, and you want to call that item.foo, you write: belongs_to :foo and the rest is all implicit. This is really handy sometimes, but it's not very Pythonic... Mostly, I think you'd probably be better off asking in a completely different kind of forum, but even then, you're going to get mostly language advocacy. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 16 Aug 2011 01:23 pm Philip Semanchuk wrote: Why should built-ins be treated as more sacred than your own objects? Because built-ins are described in the official documentation as having a specific behavior, while my objects are not. *My* objects certainly are, because I write documentation for my code. My docs are no less official than Python's docs. Sure they are. I can't get yours from python.org. You can shadow anything. Sometimes shadowing is safe, sometimes it isn't. I don't see why we should necessarily fear safe shadowing of built-ins more than we fear unsafe shadowing of non-built-ins. I think largely because anyone coming to your code will have expectations about the built-ins. For non-built-ins, they'll have to look around the code to see what they do, but for built-ins, they come to the table with an otherwise-reasonable expectation that they already know what that word means. A warning that is off by default won't help the people who need it, because they don't know enough to turn the warning on. A warning that is on by default will be helpful to the newbie programmer for the first week or so, and then will be nothing but an annoyance for the rest of their career. Will it? I am pretty sure that I'd keep it on and fix anything that triggered it, because shadowing built-ins strikes me as Asking For Trouble. Protecting n00bs from their own errors is an admirable aim, but have you considered that warnings for something which may be harmless could do more harm than good? I would distinguish between may not be causing bugs and may be harmless. I think code which shadows a built-in has a pretty real risk of being harmful at some unspecified future point when some maintainer who hasn't memorized every last line of the code makes the totally reasonable assumption that basic language features are still working and available. Perhaps. But I'm not so sure it is worth the cost of extra code to detect shadowing and raise a warning. After all, the average coder probably never shadows anything, and for those that do, once they get bitten *once* they either never do it again or learn how to shadow safely. I don't see it as a problem. I would guess that it happens moderately often entirely by accident. Not a Python example, but I recently had a heck of a time with some JavaScript I was trying to maintain. Couldn't get it to work on a slightly older Firefox, and the diagnostics from Firebug came across as basically illucid. Problem: I was declaring an array named 'history'. My thoughts would be: 1. It's hard to avoid shadowing anything unless you know the entire language and never forget things. 2. In particular, Python likes to use clear, obvious, names for things. Meaning that your choice of a clear, obvious, name for a similar thing could be the name of a thing in the language. 3. I am not sure at all that shadowing can be safe in code which will some day be maintained. The chances of someone coming along and trying to write clean, idiomatic, Python which happens to blow up interestingly because their code runs in an environment where part of the standard language has been shadowed strike me as Too High. MHO, but speaking only for myself, I'd want that warning on and I'd not consider it harmless. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Ethan Furman et...@stoneleaf.us wrote: I think warnings should be reserved for language changes and such (like DeprecationWarning, RuntimeWarning, and FutureWarning), not for possible programmer mistakes. I disagree, on the basis of the following: The quality of C code I have to deal with has increased dramatically as gcc's aggressive use of warnings has spread. Python can be improved -- I don't see 'hand-holding' as an improvement. IDEs and lints can do this. -W ignore -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Ethan Furman et...@stoneleaf.us wrote: What makes you think it's unintentional? Programming experience. People *often* do things unintentionally. Seems to me the real issue is somebody using a builtin, such as str or int, and that they somehow manage to do this without realizing, wait a sec', that's one of my variables! I don't see that as a problem that Python needs to solve. I think the word my prejudices the case. Imagine stepping into a large project that uses multiple frameworks and class libraries and so on. You know Python but you're new to the project. Under which circumstance will you have more problems? 1. There is not a single shadowed built-in in the entire project. 2. There are dozens of shadowed built-ins based on when the original programmer felt there wasn't going to be a need for a given built-in feature, or possibly just didn't know about it. Also, how easy or hard do you think it will be to debug those problems? What's your first response going to be if, on a screen which doesn't contain the word file at all, you try to use the file built-in and you get some cryptic error? Are you going to know to go looking for the shadow right away? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Ethan Furman et...@stoneleaf.us wrote: Seebs wrote: The quality of C code I have to deal with has increased dramatically as gcc's aggressive use of warnings has spread. With gcc you pay the cost once, with Python you would pay it with every run. A linter would be more along the lines of 'pay it once'. Huh! That is a really good point, which I had not considered. I still prefer to get warnings, but... Hmm. I wonder whether there's a way to mitigate the cost of these things by messing with -W settings, such that runtime that wants to be fast can omit the checks, but the default could still be to, well, prevent likely errors. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-16, Prasad, Ramit ramit.pra...@jpmorgan.com wrote: What exactly is the downside to indentation as flow control? I think a lot of it is personal taste or differences in how peoples' brains work. I don't want free form code, I don't want to write stuff that isn't correctly indented. I want a visual cue I can match up with the start of a loop so I know for sure what I meant, and a way to recover code in the event of Something Going Wrong. I am not sure why people are so stuck on braces. I figured other people would be like me and tired of having to do things like figuring out where I missed an end brace. For me, if I've made an error of that category, the options are: 1. In C, finding out where I missed an end brace, because the compiler warned me, so I go look for an outdent without a brace. 2. In Python, having no clue at all what's wrong or why the program isn't running, and having no cue I can look to to see where the error occurred. Basically, it's parity bits. I love me some parity bits. :) I also recognize that this is a matter of taste; there are sound reasons for other people to have different preferences. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-16, Terry Reedy tjre...@udel.edu wrote: On 8/16/2011 2:56 PM, Seebs wrote: I wonder whether there's a way to mitigate the cost of these things by messing with -W settings, such that runtime that wants to be fast can omit the checks, but the default could still be to, well, prevent likely errors. Warning messages have a cost even if suppressed. Yes, but is it a *significant* cost? My assumption is that the suppression would be of checking, not just of displaying messages. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Chris Angelico ros...@gmail.com wrote: On Wed, Aug 17, 2011 at 12:49 AM, Seebs usenet-nos...@seebs.net wrote: Yes, but is it a *significant* cost? ?My assumption is that the suppression would be of checking, not just of displaying messages. It mightn't be very significant, but there'd still be some cost. However, IMHO the greatest cost is the spamminess; forcing the user to deal with lines and lines of warnings is not a useful way to design a language. Lines and lines? I'd say if it's to be allowed to shadow built-ins (and I'm not sure that's a good thing at all), you'd still be looking at one warning per shadowing, which shouldn't be too many. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-17, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Seebs wrote: On 2011-08-16, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: *My* objects certainly are, because I write documentation for my code. My docs are no less official than Python's docs. Sure they are. I can't get yours from python.org. And what makes that unofficial? python.org is not the sole arbiter of official documentation in the world. But it is the sole arbiter of official *Python* documentation. If I am looking at code in Python, I reasonably expect the Python docs to be correct about that code. Incomplete, sure, but *correct*. I think code which shadows a built-in has a pretty real risk of being harmful at some unspecified future point when some maintainer who hasn't memorized every last line of the code makes the totally reasonable assumption that basic language features are still working and available. Am I the only person who writes functions and methods any more? *wink* Yes. Everyone else converted to single giant blocks of code because they are easier to develop. :P Modern languages, and by modern I mean most languages more than, oh, about fifty years old, provide ways to limit the scope of variables. You don't need to memorise every last line of the code to safely edit a function. Only the parts that are in scope, but... I seem to recall (and I'm pretty Python newbiesh, so I could be wrong) that Python classes create a scope in which bits of the class become visible, and some classes are sorta biggish. def process(list, arg): spam(list) ham(arg) cheese(list, arg) The scope of parameter list is limited to within the function process itself. Inside, it shadows the built-in list. Outside, it doesn't do squat. Yes. But what about the built-in spam? :) Define the entire language. Does that include the names of all the plethora of exceptions? How about the standard library? I'd think standard library or close to it. For what it's worth, I don't care about memorising all the built-ins. I delegate that job to my editor, which has a syntax highlighter for Python. It never forgets built-ins. (In fact, sometimes this is a nuisance. When I'm editing Python 3 code, it still insists that apply and reduce are built-ins.) Heh. I mostly don't use syntax highlighters; at best, they distract me, at worst, they distract me a lot. I also don't use one in English, although I am sure some people would love to have nouns in blue and punctuation in green. Yes, and Python also encourages the use of scopes, so that the clear, obvious name for something in one scope does not clash with the clear, obvious, identical name for something completely different in another scope. Another scope is normally a horizontal thing -- you're talking about a different scope such that you are *either* in this one *or* in that one. Built-ins are not in a scope you are never not in. Oh there's no doubt that shadowing *can* be unsafe. But then, very few things can't be abused. Yup. As I see it, there are (at least) four stages related to shadowing. (1) At first, you don't even know enough to be concerned by shadowing. You blithely call variables list and str without a care in the world... until something goes wrong. (2) Second stage, you know enough to realise that shadowing can be bad. You avoid shadowing everything. Your code is full of variables called my_list and astr and some_tuple. You call your functions things like izip even though it is designed as a replacement for zip, because the caller might use from itertools import * and accidentally replace the built-in zip with my zip. You even avoid using string as a variable name because it might shadow the string module -- even though you haven't actually imported or used the string module in the last four years. Heh. (I got advised by pylint not to grab something from it, but I no longer remember why; I seem to recall being totally unable to find a way to avoid that warning and still have the string processing I needed.) (3) Eventually, you get frustrated writing doc strings like this: def function(astr, myint=0): function(astr [, myint]) - list Arguments: astr - string myint - integer Do something tool-like to a string and optional integer... and begin writing them like this: def function(astr, myint): function(str [, int]) - list Do something tool-like to a string and optional integer... That seems safe enough to me. :) (4) And then, after a while, you decide that perhaps shadowing is not always so bad. (It helps if the Effbot tells you off for objecting to shadowing in a two-line function.) At first, you limit yourself to using parameter names that shadow built-ins in small tool-like functions. Then when the world doesn't implode, you rethink the use of top-level function names
Re: Wait for a keypress before continuing?
On 2011-08-17, John Doe jdoe@usenetlove.invalid wrote: Using does your code have a GUI produces zero search results. Maybe that works better in some other language. You shouldn't need a search engine to answer a question about your code. If you do, it suggests that perhaps one or more of the terms are unfamiliar to you? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-15, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Seebs wrote:
I tend to write stuff like
foo.array_of_things.sort.map { block }.join(, )
I like this a lot more than
array = foo.array_of_things
sorted_array = array.sort()
mapped_array = [block(x) for x in sorted_array]
, .join(mapped_array)
If you insist on a one-liner for four separate operations, what's wrong with
this?
, .join([block(x) for x in sorted(foo.array_of_things)])
Nothing in particular; I was just contrasting two styles, not asserting
that Python couldn't do that.
In general, I don't like to do things that either involve making a lot of
variables that are assigned to once and then read from once, or making a
whole lot of x = foo(x) type assignments to one variable. It feels cluttered
to me.
I think I would be less skeptical about fluent interfaces if they were
written more like Unix shell script pipelines instead of using attribute
access notation:
foo.array_of_things | sort | map block | join ,
Interesting! I think that's probably why I find them so comfortable;
shell was one of the first languages I got serious about.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-15, Roy Smith r...@panix.com wrote:
Demand, no, but sometimes it's a good idea. I've been writing computer
programs for close to 40 years, and I still have no clue what most of
the order of operations is. It's just not worth investing the brain
cells to remember such trivia (especially since the details change from
language to language). Beyond remembering the (apparently) universal
rule that {*, /} bind tighter than {+, -}, I pretty much just punt on
everything else and put in extra parens everywhere.
It's not the most efficient way to write code, and probably doesn't even
result in the prettiest code. But it sure does eliminate those
face-palm moments at the end of a long debugging session when you
realize that somebody got it wrong.
Wholehearted agreement. It is conceivable for me to misremember precedence.
I am pretty reliable at recognizing which things are in which parens.
So I use them even in obvious cases:
foo + (3 * 4)
Never regretted that. Yes, it's extra typing, a little, but it prevents a
whole category of bugs.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why no warnings when re-assigning builtin names?
On 2011-08-15, Ethan Furman et...@stoneleaf.us wrote: Gerrat Rickert wrote: What sayest the Python community about having an explicit warning against such un-pythonic behaviour (re-assigning builtin names)? What makes you think this behavior is unpythonic? Python is not about hand-holding. It seems like something which is sufficiently likely to be a mistake might deserve a warning -- especially since, so far as I can tell, there's never going to be a program which can't easily be written to avoid the problematic behavior. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-16, Roy Smith r...@panix.com wrote: In article 4e492d08$0$30003$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I'm reminded of this quote from John Baez: The real numbers are the dependable breadwinner of the family, the complete ordered field we all rely on. The complex numbers are a slightly flashier but still respectable younger brother: not ordered, but algebraically complete. The quaternions, being noncommutative, are the eccentric cousin who is shunned at important family gatherings. But the octonions are the crazy old uncle nobody lets out of the attic: they are nonassociative. Wow, at first glance, I mis-parsed that name as Joan Baez. Had me really confused for a moment. Would it have been that much weirder than Hedy Lamarr? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ten rules to becoming a Python community member.
On 2011-08-16, Roy Smith r...@panix.com wrote: In article 9att9mf71...@mid.individual.net, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: I don't mind people using e.g. and i.e. as long as they use them *correctly*. The only correct way to use i.e. is to use it to download a better browser. Similarly: Boy, is there, e.g., on my face now! -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ten rules to becoming a Python community member.
On 2011-08-14, rantingrick rantingr...@gmail.com wrote: Follow these simply rules to become an accepted member of the Python community. 1. Bash rantingrick and Xah Lee every chance you get. ... If I'd known you were in the same category as him, I wouldn't have needed to wait until now to know to plonk you. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-14, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Seebs wrote: I guess... The parser is explicitly pushing those tokens, but I can't *SEE* those tokens. If I am looking at the end of a really long thing, and I see: blah blah I only know what's happening if I have absolute confidence that the indentation is always by the same amount, etectera. I believe this is a dubious argument. With only two lines of code in isolation, understanding the indentation changes is the least of your worries. Adding block delimiters doesn't give you any significant help -- ESPECIALLY if the block delimiters don't align with the indentation! blah } blah } Interesting. I am sort of getting to an insight into this, which I am not sure I can articulate. FWIW, I've had to debug C (well, C++) much worse than that (... long story, but rest assured, the lulz justified the effort of reading the transcendantly awful code). I could still do it. :) In isolation, you don't even know whether the above is syntactically valid, since you have no way of knowing that either end brace is closing an open brace or not. Ahh, but the computer can tell me that. I don't have to see it. Who would write such a horrible mis-aligned piece of code? Good question. If you're going to have style-guides that prohibit writing code like the above, then what exactly do the braces give you? I think what they give me is... basically a parity bit. It's easy for people to screw up code, such that the code written does not reflect intent. Braces give me a likely red flag -- if they are screwed up, I know that this is a good palce to start looking. If they're not, then all they're costing me is a little vertical space. Yes, yes, if you paste the code into a web forum the indentation may disappear, and if your hard drive controller is faulty it may randomly overwrite blocks with data belonging to other files. We all agree that environments that destroy data are Bad. Destroy data is a sort of fungible concept. I was reading a comic book recently and it contained a URL for a poem which had been parodied. The URL had been hand-lettered... in block capitals. The actual URL had exactly one upper case letter in it. Whoops. In general, I don't think all data-loss is identical in severity. Outside of Python and Makefiles, I don't use anything where whitespace damage of the sort of losing or changing leading spaces is usually significant, so I *normally* regard it as a trivial change. Do you get worried by books if the last page doesn't include the phrase The End? These days, many movies include an extra clip following the credits. When the clip finishes, and the screen goes dark, how long do you sit waiting before you accept that the movie is over? *wink* It's an actual thing I have been bitten by, especially because I often really enjoy those clips, and I've seen a movie that had two. The above example bugs me too, because it is too close to what I'm used to in Python. I see an open bracket, I wait for a close bracket. Perhaps this would be better: a = array 1, 2, b = array 3, 4, Not so bad now, I betcha. Interesting! For me this triggers the same WHERE IS THE END MARKER??? reflex. These bug me like unmatched brackets. but you still can't nest arrays. This potential syntax doesn't feel like a unified whole, but like a bunch of unrelated fixes for problems. Sometimes a literal START and END delimiter is the right answer. I think so. Python's use of indentation to delimit blocks doesn't feel like that. Unlike arrays, you can't use blocks in an expression, and I think that's the factor which makes all the difference. Ruby folks may call the lack of block expressions a problem with Python, but even if they're right, I don't think it's a *big* problem. I actually really *like* that Ruby and Lua let pretty much everything just be an expression. I was utterly dumbfounded when I found out that print in Python is a kind of statement, not a function or something comparable. (This seems to have changed recentlyish.) Either way, given the restriction that blocks are statements, not expressions, the lack of an overt block markers is not a problem for code (with the proviso that a rogue editor doesn't go making arbitrary changes to your source code). Yeah. I suspect that if I'd never used something with braces, I might not mind as much, but the kinds of errors I've had would probably still be issues. Say I try to indent or outdent something and I grab the wrong set of lines. It's certainly possible for this to result in valid code... And I have no cue as to what happened. Even if I get a warning, I can't necessarily tell what happened. To some extent, I think I like braces for the same reason I like to use ECC memory whenever hardware supports
Re: allow line break at operators
On 2011-08-14, Chris Angelico ros...@gmail.com wrote: Yes. Not everything's an expression; a block of code is not an expression that returns a code object, and variable assignment is a statement. Some day, I'd like to play around with a language where everything's an expression and yet it doesn't look like LISP - just for the fun of it. It probably won't be any more useful for real world coding, but it'd be fun to tinker with. Ruby and Lua are both pretty close. I'm not an expert in either, but I can't think of anything I can write in Ruby which isn't an expression. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-14, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Seebs wrote: Destroy data is a sort of fungible concept. I was reading a comic book recently and it contained a URL for a poem which had been parodied. The URL had been hand-lettered... in block capitals. The actual URL had exactly one upper case letter in it. Er, most URLs are case insensitive, at least the most common ones, including HTTP and HTTPS. So I don't quite see why you think this was a Whoops. Sort of. Host names are case insensitive, so far as I can tell always. Paths past that are distinctly NOT always case insensitive, and since the server in question happened to be doing what appear to be straight path lookups, it mattered a great deal that you had to downcase all but one of the letters. (The obvious technique of downcasing them all failed.) Ys, nd n rdnry nglsh txt, th lss ar chng af vwls cn olsu b e trvl chng. But try that with your source code :) Eh, I'm a C programmer, what makes you think I had any vowels to begin with? Yes, print as a statement was a mistake. But assignment as a statement, not so much. Assignment as an expression in languages that have it tends to be associated with frequent errors. It does. I'm not sure whether the errors are compensated for by the expressiveness. I *think* on the whole they are, but I am honestly not sure. I do like gcc's warning for assignment used as a truth value. The way I see it, if something operates by side-effect, then it has no business being treated as an expression. Interesting! I tend to really like the ability to chain methods, depending on context. I find the side-effect/expression mix pretty normal, so I'm used to it. Say I try to indent or outdent something and I grab the wrong set of lines. It's certainly possible for this to result in valid code... And I have no cue as to what happened. Even if I get a warning, I can't necessarily tell what happened. Then don't do that. If not doing that were a realistic option for me, I'm guessing I'd have stopped making typos thirty years ago. I'm not impressed by arguments based on but if I do something stupid, like select text with my eyes closed and reindent it without looking, I expect the compiler to save my bacon. In my opinion, it's not the compiler's job to protect you from errors caused by sheer carelessness at the keyboard. I don't know about sheer carelessness. Typos happen. Typos are not something you can prevent from happening just by wanting it very much. In any case, while reindenting an arbitrary set of lines may *possibly* result in valid code that runs but does the wrong thing, the likelihood of that happening is remote enough that I'm not going to lose any sleep over it. Ahh, but what about the case where it results in invalid code? It's not necessarily obvious which lines need to be moved after that. foo.each do |bar| bar.do_a_thing do_something_with(bar) end next_thing something else I know immediately that it's wrong. How? The end is misaligned. Therefore SOMETHING is wrong. I don't know what, but I can be confident that something went wrong. Unless I understand the intent of the code, how can I tell whether the END token is in the right place or not? And if I understand the intent of the code, then the END token is redundant. The question is not whether it's on the right line. No amount of indenting or outdenting can ever break that. The question is whether I've gotten the indentation screwed up. If I do something in my editor and end up with: if foo: bar.do_a_thing do_something_with(bar) next_thing something else I can't immediately see that I hit the wrong number key when telling the editor how many lines to adjust. Typos happen. I rely heavily on things that let me catch them in as many ways as possible. I call that a poor user interface design. If you have to count the number of lines before applying an edit, instead of selecting a range of text, then you should stop using a tool that is stuck with a UI from the early 1980s. You keep telling me to stop using this editor. I have not seen a suggested improvement. (Hint: GUI editors are not an improvement for my purposes, as I do about 99.5% of my editing on machines that aren't in the same state that I am. No, the GUI editor cannot offer enough improvement in anything to justify the cost of copying files back and forth constantly.) Please don't take this as an insult, because it is not meant as one, but it seems to me from this discussion that you're a more careless coder than I am[1], and you want more insurance to protect you from your own mistakes. Braces give you that insurance. I have really, really, bad ADHD. When I was a kid a firecracker blew up in my hand because I *forgot* I was holding it. I'm not exactly careless in the pejorative sense (I don't accept
Re: allow line break at operators
On 2011-08-14, Teemu Likonen tliko...@iki.fi wrote:
I understand that Python philosophy does not value freedom of expression
that much. It values a general Pythonic rule which must obeyed and is
called readability. Other languages give too little or too much
freedom. :-)
There is an interesting tradeoff, there, because I tend to find stuff
like variable = {fancy if expression} to be much *more* readable, since
I immediately get the top-level information (we're assigning variable)
and then I can look for details if I care.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: pythonw.exe
On 2011-08-14, Chris Angelico ros...@gmail.com wrote: Just to confuse things even further, it's not unlikely that a Mac or Linux or Windows computer will have DOSBox installed. Is *that* DOS? Technically no, but practically yes. Depending on how you define unlikely, I'd guess it is. Assume that unlikely means roughly the equivalent of if I were optimizing, I'd use a compiler branch prediction hint at this point. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ten rules to becoming a Python community member.
On 2011-08-15, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: And yet, here you are, engaging him in conversation and feeding him the attention he craves :( Many cultures have a tradition of almsgiving. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-15, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Interesting! I tend to really like the ability to chain methods, depending on context. I find the side-effect/expression mix pretty normal, so I'm used to it. As a rule, chaining method calls risks violating the Law of Demeter. Just sayin'. Risks violating isn't the same thing as violates. But a good editor can minimise command typos. User interfaces matter. If your car required you to reach over your left shoulder and pull a lever in order to slow down, it would be a really bad design. It would join these interfaces: Yeah. If your editor doesn't help you minimise bad commands, then your editor doesn't work for you, it works against you. Life is full of tradeoffs. The editor does a lot of things which very much improve my performance, with costs which are usually pretty easily mitigated. I don't know about sheer carelessness. Typos happen. Typos are not something you can prevent from happening just by wanting it very much. I sympathise, but don't care. That's your problem man, not Python's. Debatable. There's a sort of fuzzy boundary between clearly this is a defect in the product (see interfaces that kill), and clearly this is a defect in the user. In fact, one of the major areas of interesting UI research involves interfaces that accommodate things which are generally regarded as defects in the user. Think about colorblindness. Obviously, it's the user's problem, not the editor's, but an editor which picks colors which most colorblind people can't distinguish for something important is going to get castigated for it. I hope you can still be productive in Python, and it's not like anyone *wants* you to stop using Python and use another language, but you have to understand that Python wasn't designed for *your* needs precisely. That doesn't make indentation as syntax a bad choice. I think it depends a lot on the goals. So far as I can tell, the primary goal of the policy was to eliminate a class of errors. It... well, it does this in a strictly technical sense, in that every error which occurs is no longer of that class. It does not seem to me that it's done very much to turn the kinds of things which used to result in that class of errors into non-errors; rather, it's turned them into different errors. Are you talking about code you've moved from somewhere else and need to reindent? Then if the code was working before, it will keep working if you have the same relative indentation. (At least indentation-wise. It may break due to other factors.) Revert your bad reindent and try again, more carefully this time. The point is... I can't *TELL* what the boundaries of the bad-reindent are. Because there's no unambiguous point at which I can say oh, look, here is the line where the indentation starts being wrong, unless there's a syntax error... and even then, the syntax error might be before or after the actual bounds of the bad indent. With properly-braced code in a brace language, any mis-indent you do can be unambiguously identified -- you have a 100% guarantee that you know what the first and last misindented lines are. In Python, you can usually guess within a couple of the lines, more easily if you're familiar with the code. If you're making semantic changes to the code, not just a simple move, then surely you understand what changes you're making and not just randomly indenting and dedenting until it complies? Read the code and decide how to fix it. The case that has historically bitten me is that I move N lines of code, and then I try to adjust the indentation of those N lines, and... SOMETHING happens. Maybe someone somewhere introduced tabs and adding four leading spaces doesn't do anything. Maybe I mis-counted N. I get it that sometimes there will be code which is hard to follow and hard to edit. But if that's the case, you've got more maintenance problems than indentation, and indents are the least of your problems. Not if the only reason that it's hard to follow is that the indentation is screwed up. The end is misaligned. Therefore SOMETHING is wrong. I don't know what, but I can be confident that something went wrong. Okay, now I'm confused... if indentation doesn't matter, how is the end misaligned? Indentation doesn't affect the *compiler*, but we know the rules for indentation. It's a parity bit. If the indentation and the begin/end don't agree, then I *know something is wrong*. And I know on exactly which line it becomes wrong. That turns out to save me a fair bit of time if I have to look at code and try to figure out what's wrong. The question is not whether it's on the right line. No amount of indenting or outdenting can ever break that. The question is whether I've gotten the indentation screwed up. But if indentation doesn't matter, you can't screw it up. Isn't that the whole point of this discussion? I think there is some
Re: allow line break at operators
On 2011-08-15, Chris Rebert c...@rebertia.com wrote:
On Sun, Aug 14, 2011 at 6:54 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
As a rule, chaining method calls risks violating the Law of Demeter. Just
sayin'.
Not in the specific case of fluent interfaces[1] though, which could
have been what Seebach had in mind.
They're the most obvious example, from my point of view.
I tend to write stuff like
foo.array_of_things.sort.map { block }.join(, )
I like this a lot more than
array = foo.array_of_things
sorted_array = array.sort()
mapped_array = [block(x) for x in sorted_array]
, .join(mapped_array)
(I am still not used to Python's attachment of join to strings rather
than to arrays. I don't really object to it, it's just not how I think
about join operations.)
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Before I get to the rest of this: Thinking it through, I've been unreasonable and grumpy here, and I'm trying to figure this out a bit more. A general observation: There's no real data here, so far as I can tell. There is no pair of languages which are exactly identical except for whether they use whitespace or some kind of brace/bracket/thing to indicate blocks, such that we can compare results between them. Humans are *notoriously* unreliable at evaluating the ease with which they do things, how long it takes them, how many mistakes they're making, and so on... So really, this is probably in large part a matter of taste or preference. On 2011-08-11, Ethan Furman et...@stoneleaf.us wrote: The times that whitespace indentation has bitten me, it was still not difficult to fix -- I just had to look and see which line(s) should/should not be where they were. I've been thinking about this, and I just plain can't understand how this could, in general, be done. Given a bunch of lines of code with no indication of where the blocks were supposed to be, I can't figure how this could be fixed in a way that is not-difficult, at least in general. Not so. If the braces do not match /intent/ (which is the problem I care most about) then it cannot be fixed by machine. Question for y'all: Has anyone here ever ACTUALLY encountered a case where braces -- not indentation -- did not match intent in a C-like language? I'm talking only about cases where braces are *actually present*. I haven't. Now, I've only been using C for maybe 20-25 years, but in all that time, I have never, ever, not *once*, seen braces not match intent. I've seen indentation errors galore. I've seen nutjobs writing }}} on a line all by itself. I've seen people forget to add braces and do stuff like: else a(); b(); ... but I've never, ever, seen braces not match intent. It just hasn't ever happened in code I've seen. people who'd picked Python for some stuff I have to work for, point out the hostility of the Python community to newcomers whose workflows don't happen to have been preemptively built entirely around Python's design decisions, and suggest that maybe we use another language. Heck, since I've been encouraged so much to do so, I think I will. Your choice, obviously -- seems a shame to me, though, to give up on Python because of one or two ouchy areas on c.l.py. By and large it's a very helpful and courteous community. I was thinking about this more, and I think the issue that's historically bugged me is this: Most of the people I know and talk to about programming languages regard preferences as a matter of personal taste. I've seen people say that they prefer the significant-indentation thing, and I've seen people say they dislike it. The Python community, as a whole, seems particularly dogmatic about the indentation thing. And coming here as someone who doesn't much like it, and has been bitten by it a few times... Imagine that I were taking care of a cat for the first time, and I came to a cat-owners newsgroup, and found the following: 1. Nearly everyone there hated dogs, utterly. 2. The people who hated dogs were snide and insulting about people who didn't hate dogs. ... oookay, then. So I post my question, about a cat peeing on a bed, and I get the following responses: 1. What kind of idiot are you to continue using a broken non-waterproof matress? You should be using a solid vinyl cover over your mattress to prevent it from geting cat pee. 2. Once you've had a cat for a while you'll find that overall cat pee is superior to a dry mattress. ... At this point, I'm not exactly going to feel like a welcome member of the community. :) Now, that analogy is a little extreme, perhaps, but... Programmers get attached to their editors. And having a bunch of people insist that it's crazy of me to use an editor which has worked perfectly for me in the other ten programming languages I use, with settings that are not merely tolerable but *mandatory* for at least one of them, is... well, it doesn't create the impression that people who don't happen to already have fallen in love with an editor that coexists well with the whitespace thing are welcome. And part of this really is personal taste. I *LIKE* having a matching outdent for everything. I like to look at code and see blah blah blah blah blah because then I know it's balanced. If one of them is missing, *something is wrong*. And I have to keep that instinct to stay functional in most of the other languages I know. I don't have the option of ceasing to use C, but if I used C and didn't watch for missing close-braces, I'd be pretty badly hosed. So I have this strong incentive to prefer an explicit thing that I can see. And in any event, I *do* prefer it. In other language communities, when I find things about the language
Re: allow line break at operators
On 2011-08-12, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net writes: I am pretty sure Python is a pretty nice language. However, the indentation thing has screwed me a few times. Furthermore, I know people who like Python a great deal and acknowledge, without much difficulty, that the indentation thing has caused problems or incompatibilities for them. Yes. It's caused problems for me too, so I'm not going to deny that. This is different from saying ???indentation as block structure??? is a problem; that statement is what I disagree with, and what I think most respondents who disagree with you are objecting to. See below; I think I agree with what I meant by it, and disagree with what you seem to interpret it as. Your interpretation makes as much sense as mine, so far as I can tell. I don't see anyone making the denials you're referring to there. If I did, you would have my support in considering those denials mistaken. I suspect, thinking about it more, that it's a communications problem. Likewise, ???end of line as end of statement??? has caused me and many others problems. I'd go so far as to say that any Python programmer for whom that's not true has not done any significant Python programming. That doesn't make ???end of line as end of statement??? a problem. True, although it does make it a thing which *has* at least one problem. If a language feature is beneficial in far greater proportion to the inconveniences of that feature, I'd say that feature *is not a problem* for users of that language. I wouldn't. Lemme give a concrete example, from C, since that's the language I know best. There are sound technical reasons for which C lets you manipulate pointers. If you couldn't, it wouldn't be C, and you couldn't do the bulk of the stuff that makes C useful. But... Pointer manipulation leads to crashes. LOTS of crashes. I have never met a C programmer with over a day or two of experience who has not had a program crash due to some mishap involving a pointer. When people say that a language like, say, Java, is trying to solve the problems of C's pointer system, I think that's a reasonable thing to try to do. There are tradeoffs. But it would be, IMHO, silly to claim that there are no problems with pointers; there are just benefits which outweigh them *for the things the language is trying to do*. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net writes: Question for y'all: Has anyone here ever ACTUALLY encountered a case where braces -- not indentation -- did not match intent in a C-like language? I'm talking only about cases where braces are *actually present*. What a strange limitation. Why are you not comparing apples with apples? I am trying to. I'm trying to compare C-like languages, with braces, to Python, with indentation. The correct comparison would be ???getting the braces to match the intended structure??? compared with ???getting the indentation to match the intended structure???. Right. I have seen Python programs in which indentation, while it obviously matched what actually happened, did not match intent. It is (at least in principle) easier to debug because you can see that, but... I've seen people in C do stuff like: for (i = 0; i N; ++i); a[i] = 0; This is clearly a case where indentation matches intent, but doesn't match functionality, because C allows indentation to not-match functionality; this is the famous problem Python is solving. However, I've never, ever, seen a problem like that *when people were using braces*. An apples-to-apples comparison between indentation and braces should be a comparison *to braces*, not to people who cleverly omit braces. (If you are looking for a debate on whether C's optional-braces are a good idea, I'm afraid you will have to look elsewhere; if it were up to me, I would totally approve a language change making them mandatory.) As you say, the data is thin on the ground for this issue. Would you accept the charge that you're being just as dogmatic about the superiority of braces-as-block-syntax? I don't think so. If not, what makes your position less dogmatic than ours? A couple of things. 1. I do assert that people who are happy with an editor and have been using it for twenty years ought to change their editor to accommodate a language which uses braces. 2. I will happily grant that braces, written legibly, cost you an extra line per block, and that this space cost can make it harder to see all the code at once. 3. I don't have a problem agreeing that there certainly appear to be people for whom the Python syntax is easier to read. I think #1 is the real point at which I think there's a dogmatism problem. Maybe editors shouldn't helpfully convert spaces to tabs, but that feature has been nearly entirely beneficial to me in everything else I've edited for a long time, and I don't *want* to learn a new editor just for one language. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Chris Angelico ros...@gmail.com wrote: On Fri, Aug 12, 2011 at 7:34 AM, Seebs usenet-nos...@seebs.net wrote: If Python with braces wouldn't be Python at all, why on earth does the language even exist? Every language has its philosophy. Yes. Etcetera. These are the philosophical decisions made by GvR and the Python community, and these define Python's syntax. If you go against these, you could make something that compiles down to Python's byte code; in fact, I'd say you could make something that produces a .pyc file and then hands it to the regular Python interpreter for execution. Is it Python? No, no more than NetREXX is Java just because it can make a .class file. It's a different language. I would argue that any pure syntactic-sugar change which can be done entirely by a naive preprocessor does not constitute a significant shift in the language itself. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, rantingrick rantingr...@gmail.com wrote: What is with you guys and this need to have your hand held to read code. Good question! Great to see that the helpful and welcoming community is living up to its reputation. My brain has quirks. Some people call them defects, some don't, but it really doesn't matter; there are things about which my brain is just plain unreliable and I rely moderately heavily on extra visual cues to reduce the frequency with which I get things wrong when skimming. Out-dents are noise and nothing more. Not for me. When you're driving on a two lane highway that becomes one lane, would you forget to merge (OUTDENT) simply because the merge sign was missing? No, because the *LANE BOUNDARIES* would move. If you did then i would say you need to keep your eyes on the road (CODE) instead of looking for signs on the side of the road. In other words; you need to start acting like an intelligent agent instead of a zombie. Interesting theory. I propose we extend it to expression processing in general. Instead of writing a = (x + y) * z let's just write a = (x + y * z It's obvious that no one would have needed to introduce parentheses here unless they wanted to bind the + more closely than the *, so the ) is just noise and not needed. Hmm, Python's exclusive use of indent/dedent for denoting blocks is rather unique in a world of braces (barring a few other less known languages). Removing that feature and replacing it with braces (or tags or whatever) would change the language significantly! It would, but unless that's the only distinctive trait of the language, I don't think it would make the language cease to be Python. Likewise allowing a directive like use braces = True would also be detrimental to our code bases. A language must always strive to remove ambiguities and multiplicity. Having more than one way to mark blocks is insanity. You never want to induce more overhead than necessary because such things are detrimental to work flow and language evolution. Agreed. This statement leads me to believe you have very little experience with the Python language. Python has many wonderful attributes and design philosophies. Significant indentation is just ONE of many. It was a reductio-ad-absurdum. I don't understand this need for braces. You yearn so badly to be dominated by them. Is this a psychological disorder, a Helsinki syndrome that you cannot shake? There is life after braces my friend, and the future is bright! Man, you really love pushing them buttons, don't you? You don't understand a thing. Therefore... there is no such thing, anyone who experiences life differently from you needs to be insulted? As much as we love people getting on board we are not about to sacrifice our strong beliefs in clean source code just so you and other hardwired C programmers will come along. But you will happily insult people and call them names in order to keep them from having anything to listen to? PS: I will admit that a few of our community members can be rather acerbic at times. Yeah. And the thing is... This can't possibly lead to convincing people of your position, so presumably the purpose is that you don't want anyone who didn't start out agreeing with you to ever come to agree with you? Why's that? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Chris Rebert c...@rebertia.com wrote:
One argument I've heard from braces fans is that sometimes they want
their own structure, which does not match the actual block structure.
EWW!
Example:
FILE* f = fopen(...);
// do stuff with f
// at this indent level
fclose(f);
// back to normal
But really this is just working around other limitations in the
language (i.e. lack of a with-statement equivalent).
That's horrid.
FWIW, the C idiom is:
{
FILE *f = ...
...
fclose(f);
}
It isn't used all that widely, but it is a lot less horrible than
random indenting would be.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Chris Angelico ros...@gmail.com wrote: Why is left-to-right inherently more logical than multiplication-before-addition? I'd say it's certainly more Pythonic in a vacuum. Multiplication-before-addition, and all the related rules, require you to know a lot of special rules which are not visible in the code, and many of which have no real logical basis. Left-to-right is, if nothing else, the way the majority of us read. The problem is that since everyone's used precedence before, not using it violates the principle of least astonishment. ... Hmm. There is a thought; I think it may be useful to distinguish between Pythonic and Pythonic in a vacuum. That is to say, there are things which would fit the basic philosophy of Python very well if previous programming languages and tools were not widespread, and there are other things which fit anyway. Using a simple left-to-right evaluation would probably be easier for people to understand, and more self-explanatory, *IF* there were no prior art. Why is it more logical than right-to-left? And why is changing people's expectations more logical than fulfilling them? Well, playing devil's advocate's advocate here... You could argue that switching from braces to indentation might be changing peoples' expectations, or might be fulfilling them, depending on the people. I think there's certainly cases where it is probably better to say that expectation proves to make it impossible to build a clean language, so we're going to ask you to do things this way, and cases where it is probably better to say that expectation is very deeply established, and doesn't really hurt the language, so we'll adapt to you. Python uses the + and - symbols to mean addition and subtraction for good reason. Let's not alienate the mathematical mind by violating this rule. It would be far safer to go the other way and demand parentheses on everything. I wouldn't mind that. Incidentally, in the original expression, it would be slightly more sane to write it as: a = x + y) * z borrowing from the musical concept that a repeat sign with no corresponding begin-repeat means to repeat from the beginning. But both of these violate XKCD 859. Yes, yes they do. Huh. You know, that's why the outdents-without-symbols bug me; I have a thing with a colon on it introducing something, and then there's nothing ending it. I want that match so I can let the naive stack-depth-counter off somewhere in my brain do its thing without leaving me with a huge feeling of unclosed blocks. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, rantingrick rantingr...@gmail.com wrote: On Aug 12, 11:33?am, Seebs usenet-nos...@seebs.net wrote: My brain has quirks. ?Some people call them defects, some don't, but it really doesn't matter; there are things about which my brain is just plain unreliable and I rely moderately heavily on extra visual cues to reduce the frequency with which I get things wrong when skimming. I think that really boils down to you refusing to open your eyes up to new ways of doing things. You think that, then? Okay. You are clutching the past and it is taking you down with it. I see. This is a brilliant new theory. I will further explore the notion that actually my brain is 100% normal with no limitations except that I have used languages with braces. Doubtless this will prove illuminating. No, because the *LANE BOUNDARIES* would move. The lane boundaries will also move whilst reading code that uses the indent/dedent paradigm. Are you honestly telling me that you will skip over a four spaced dedent without seeing it however you can easily spot a single closing brace and instantly know which corresponding opener brace to which it referrers without looking, and counting, and wasting time? Sorry, i just don't believe you. Nope, not telling you that. Here's my example: if foo: blah blah blah if bar: moreblah moreblah if quux: typingisboring typingisboring typingisboring moreblah moreblah if baz: somuchblah somuchblah somuchblah somuchblah somuchblah somuchblah somuchblah somuchblah abitmoreblah It's not easy for me to be sure, looking at something roughly like that, what's being closed and what isn't. If I have braces, I can tell how many things are being closed. I like that. It makes me happy. I propose we extend it to expression processing in general. ?Instead of writing ? ? ? ? a = (x + y) * z let's just write ? ? ? ? a = (x + y * z I'm glad you brought this up! How about this instead: a = x + y * z ...where the calculation is NOT subject to operator precedence? I always hated using parenthesis in mathematical calculations. All math should resolve in a linear fashion. 3+3*2 should always be 12 and NOT 9! Doesn't matter. At some point, somewhere, it would become desireable to introduce precedence with (), at which point, it is quite possible that the trailing ) would be redundant, so why not omit it? I am not trying to discredit you simply by disagreeing with you. No, but you're certainly being insulting. I have offered facts as to why significant indention is far superior to braces and yet you continue to use the same emotionally charged babble in your defense. Facts: Pry your lips from Ritchie's left teet and stop slurping that brace milk; because it is polluting your mind! Emotionally charged babble: My brain has quirks. Some people call them defects, some don't, but it really doesn't matter; there are things about which my brain is just plain unreliable and I rely moderately heavily on extra visual cues to reduce the frequency with which I get things wrong when skimming. When you offer some real facts then i will give then just consideration, until then i will try to enlighten you of the merits of significant indentation. Well played! -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Chris Angelico ros...@gmail.com wrote: On Fri, Aug 12, 2011 at 5:33 PM, Seebs usenet-nos...@seebs.net wrote: I've seen people in C do stuff like: ? ? ? ?for (i = 0; i N; ++i); ? ? ? ? ? ? ? ?a[i] = 0; This is clearly a case where indentation matches intent, but doesn't match functionality, because C allows indentation to not-match functionality; this is the famous problem Python is solving. There's several solutions to this. One is linting utilities that detect unexpectedly-indented code, which is the concept that Python took to the logical extent of syntactic errors. Another is (again linting) to disallow a direct trailing semicolon; if you want an empty body, you put whitespace before the semicolon. But that wasn't your point, I realise :) I think it sort of is. My current preference would be that C-like languages would simply absolutely eliminate optional-braces. Then the whole category of errors would partially-go-away. You could still have code which didn't do what you meant, but it would be reliably easy to see what it did, and so on. But it's interesting to note that there are many ways to address this. Most of the C I've done has been in circumstances where misindented code was in fact a thing that would fail reviews. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Please don't feed the troll. Responding to Rick's standard obnoxious posts is like wrestling with a pig -- you get tired and filthy, you never accomplish anything useful, and after a while, you realise that the pig is enjoying it. Save yourself a lot of aggravation and kill-file him now. You know... I think I just realized where a big part of my misperception of the Python community was. Which is that until todayish, I had not realized that he was regarded as a troll by the rest of the community. But now that a couple of people have told me this, I am a lot more comfortable referring to the Python community in general as welcoming. I sometimes enjoy trying to extract information from people like that, but I will respect the preferences of the actually-helpful people and drop that line of inquiry. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-12, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Seebs wrote: You know, that's why the outdents-without-symbols bug me; I have a thing with a colon on it introducing something, and then there's nothing ending it. But there is something ending it: a change in indentation level. Hmm. Okay, here's what I'm not getting. Consider this: if foo: blah if bar: blah blah if baz: blah blah Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream. What's being pushed into the stream to indicate that the first outdent is two outdents and the second is one? I guess... The parser is explicitly pushing those tokens, but I can't *SEE* those tokens. If I am looking at the end of a really long thing, and I see: blah blah I only know what's happening if I have absolute confidence that the indentation is always by the same amount, etectera. They're just a change of state in indentation level, which is much more easily seen without the need for counting braces. Python's parser may need to count tokens, but for the human reader merely needs to use its intuitive and highly accurate ability to notice when things line up. Well, that's the thing. In a case like: if foo: if bar: blah blah I notice that *NOTHING* lines up with if bar:. And that affects me about the way unmatched brackets do. (Aside: this is why I dislike two-space indents. That's narrow enough to make the does this line up detector subject to too many false positives.) Yeah. I want that match so I can let the naive stack-depth-counter off somewhere in my brain do its thing without leaving me with a huge feeling of unclosed blocks. Yet another reason to consider brace languages harmful: they spoil the user's intuitive grasp of intuition as grouping. I assume you mean indentation as grouping. I'm... not sold on this. It's not that I don't see indentation as a kind of grouping. It's just that I really, really, want groups to have ends. Consider the hypothetical array syntax: a = [ 1, 2 b = [ 3, 4 This *bugs* me. It's perfectly legible, and if you define it that way, it's unambiguous and everything, but... It bugs me. I want beginnings to have an actual corresponding end. But the human brain is a funny thing: you can train it to expect to do more work than is necessary, and it will complain when you make its job easier. Easier varies somewhat from person to person. I need a LOT of parity checks (speaking metaphorically) because my brain is fantastically prone to dropping bits. But I'm really fast. So a thing with lots of parity checks is much easier for me to actually *successfully* use than a thing which omits all that extra stuff. I was overjoyed when I saw that Ruby would let me write 1_048_576. I can read that with fewer errors than I can read 1048576. (And yes, I could also write 120.) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-13, Terry Reedy tjre...@udel.edu wrote: I have been indenting code neatly for at least 32 years whenever the language I used allowed it. Just over 14 years ago, when Python was an obscure little known or used languge, I adopted it *because* it dropped all the redundant bracket noise and looked to me like 'executable pseudocode', as I explained (with an unfortunate misspelling) in https://groups.google.com/group/comp.lang.python/msg/cc25701a283a3f68 Indentation is part of that. Python-with-brackets would, to me, be something different -- sure, derived from Python, but not the same. Fair enough. I do not need for you to adopt and use Python to validate my choice. If you like it fine, welcome. If not, have fun with something else. If this were among my options, it's probably what I'd do. It is what I do for things where I get a choice of languages. FWIW, yes, I spec machines with ECC memory whenever I can. I am a big fan of redundant data that can detect likely errors. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-13, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net writes: What's being pushed into the stream to indicate that the first outdent is two outdents and the second is one? See URL:http://docs.python.org/reference/lexical_analysis.html for a comprehensive discussion of the lexing done on Python source. Interesting, thanks. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-11, Ben Finney ben+pyt...@benfinney.id.au wrote: What evidence do you have of these? The latter, especially, seems to be mere opinion unfounded in any measurement. Well, on new collection of data, I'm less convinced. The basic rule is: Engineers are nearly always aware of tradeoffs. If I suddenly encounter something where many engineers perceive a tradeoff, and a few deny that there is any tradeoff at all, that usually means that the latter category are not actually doing the engineering thing. Again, I don't know where you've been observing that, but it's not what I've seen. I've seen it some here, and in other Python discussion threads. I've also seen counterexamples, though, more now that I brought it up. You're welcome to attempt to demonstrate the superiority of some other Python-with-braces, but it will (a) be un-Pythonic, and (b) be unlikely to gain the efforts of people who don't think what you're addressing is a problem. I have noticed a tendency for Pythonic to produce fierce debates in which there is absolutely nothing measurable to point to. I'm not sold on it. I guess the thing is this: I am pretty sure Python is a pretty nice language. However, the indentation thing has screwed me a few times. Furthermore, I know people who like Python a great deal and acknowledge, without much difficulty, that the indentation thing has caused problems or incompatibilities for them. So when I see people deny that it is at all a problem, or that there are any possible shortcomings to it, I infer that they have some compelling reason to deny the existence of a thing which is reliably and easily observed. See, that's the thing. If you want to tell me that there are problems with braces, I'll *agree*. I am aware of those problems. I don't feel a need to deny that they exist. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-11, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Seebs wrote: I have seen all the counterarguments, and what I've mostly become convinced of is this: 1. Indentation as flow control was a bad idea. I'm not aware of any language where indentation is used for flow control. Python is not one of those languages: it uses for, while, if, etc. for flow control, just like most other languages. It does however use indentation for grouping code into blocks -- a different concept. Agh! Point granted. Presumably you knew what I meant, but you're right that I said it wrong. You are free to hold whatever opinions you like, but have you considered that the reason people get emotional and angry when others insist that indentation as flow control should be discarded is because they actually believe that the off-side rule (as it is called) makes for a better language and a better coding experience? Yes. And when I talk to people who are *able to admit that there exist problems*, and who argue that the benefits outweigh them, I believe that they are probably making a good point. It's the people who insist that there are no problems that worry me. There are dozens, hundreds of brace languages, and 1-2 dozen using indentation, including Python. If braces are so important to you, go use one of those other languages, don't wreck the language we like by taking away one of the best features of the language. If I had a choice, believe me, I'd do just that. We're fully aware of the tradeoffs of significant indentation. You are. A couple of other people I've talked to are. Many others are not. We believe that brace languages get the trade-offs backwards: they optimise code for environments which mangle source code. 99.999% of code will never pass through a broken mail server that strips leading whitespace, or pasted into broken web forum software that mangles indentation, or go through any other broken tool that messes with indentation. Brace languages optimise for the 0.001% case, Python optimised the 99.999% case. This is a really interesting analysis. My experience, though, puts it more at about 99% and 1%. And the thing is... Because people simply don't like it when their code's indentation doesn't match the actual semantics, people usually manually ensure that the two match, braces or no braces. Editors still have commands to indent and outdent blocks of code. There is no difference between (say) C or Pascal and Python in that regard. Yes, there very much is. You can't outdent a block in Python unless it is already correctly indented. The underlying thing I've noticed is: Braces have problems more often, but the problems are *always* 100% machine-fixable and therefore trivial. It takes milliseconds to get a program fixed so it looks like what it means. Indentation has problems less often, but the problems are *never* machine-fixable. It takes minutes or hours to figure out what was supposed to be there. There is nothing implicit about indentation. This false dichotomy between so-called explicit braces and allegedly implicit indentation gets thrown around all the time, but it is simply *wrong*. Indentation is not implicit. Hmm. Maybe implicit isn't quite the right word, but... The end of an indented block is not a thing, it's the lack-of-a-thing. foo bar How many unindents are there between foo and bar? If you can't answer this from looking between foo and bar, but must instead look at previous lines and *INFER* the number of unindents, then it seems to me that there is something implicit going on here. And ABC, Boo, BuddyScript, Cobra, CoffeeScript, Curry, F#, Genie, HAML, Haskell, ISWIM, Miranda, Nemerle, Occam, PROMAL, Spin and XL, plus any other languages with significant indentation. Point made. No, most mail servers don't mangle whitespace in the body of the email, or in attachments. Most don't, that's true. Part of my frustration comes from a 6-month period during which most of my email was sent through a mail server which, for reasons no one was able to determine, was dutifully converting any plain text it received into HTML, and stripping irrelevant spaces along the way. :) Some mail clients do, usually because they default to using HTML for text. So get a better mail client. I have tried occasionally. Mine does not default to use HTML, but it does sometimes mangle lines. Unfortunately, it's the closest to having other funcitonality I want I've ever seen. Avoid pig-ignorant web forums that think that source code can be reflowed or that remove leading whitespace. Stop using Notepad, and use an editor that offers indent and outdent commands. I'm not using Notepad. And actually, it's the indent/outdent that bit me worst, so far. :) If your mail server had a bug that deleted braces from emails, would you fix the bug, or would you insist that braces were a failed experiment and that C
Re: allow line break at operators
On 2011-08-11, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Steven D'Aprano wrote: indentation as flow control Gah! Of course, I meant indentation for blocks... after making the earlier point that indentation is *not* used for flow control, this was a particularly egregious error. How embarrassment. My fault, I probably hypnotized you with my bad word choice. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-10, Chris Angelico ros...@gmail.com wrote:
And if we require {} then truly free indentation should be OK too! But
it wouldn't be Python any more.
Would it really not be Python at all?
I've seen bits of code in preprocessing-based Python with {} type things,
and they still look like Python to me, only they favor explicit over
implicit a little more strongly.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-11, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Seebs wrote:
On 2011-08-10, Chris Angelico ros...@gmail.com wrote:
And if we require {} then truly free indentation should be OK too! But
it wouldn't be Python any more.
Would it really not be Python at all?
Of course it wouldn't be. Every function, class, if, while, for,
try...except block etc. in existing Python code would be illegal if {} were
required.
So?
Since there has never been an indentation-related problem in the history
of human endeavors, automatically adding the braces would be completely
trivial.
How much of the language *specification* would change?
In general, languages that aim to look like executable pseudo-code will
converge on a similar look, because executable pseudo-code tends to be
based on natural language (usually English) and mathematics syntax.
This is an interesting point. I guess I meant look like in a more abstract
sense; the basic idea of what it's like to read the code, and what you have
to keep in mind while doing so.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
On 2011-08-10, Ben Finney ben+pyt...@benfinney.id.au wrote:
Seebs usenet-nos...@seebs.net writes:
On 2011-08-10, Chris Angelico ros...@gmail.com wrote:
And if we require {} then truly free indentation should be OK too!
But it wouldn't be Python any more.
Would it really not be Python at all?
See the Python interpreter's response to ???from __future__ import braces???.
I'm aware of that. I have seen all the counterarguments, and what I've
mostly become convinced of is this:
1. Indentation as flow control was a bad idea.
2. People are subconsciously aware of this.
3. There is a HUGE degree of emotional investment in defending it.
The responses I have seen on this issue are highly emotional, full of insults,
full of blame-throwing, and utterly contrary to the basic engineering spirit
I usually see in programming communities. In other languages, and even in
Python on any issue but this one, I regularly see people acknowledge
shortcomings and explain either why they think the tradeoffs are good, or why
they are willing to put up with it anyway.
The characteristic vehemence and hostility this issue produces are the surest
sign of people who have a desperate need not to acknowledge the elephant in
the room.
I've seen bits of code in preprocessing-based Python with {} type
things, and they still look like Python to me, only they favor
explicit over implicit a little more strongly.
They introduce unnecessary ambiguity: the indentation-as-structure and
braces-as-structure can then disagree.
Yes, they can.
In which case either the Python interpreter must guess the programmer's
intent (very un-Pythonic), or it throws an error and the programmer must
do busy-work to keep braces and indentation in agreement (also
un-Pythonic).
The obvious answer would be:
* Braces win because they are explicit rather than implicit.
* Everyone would use things configured to throw a warning or error.
The thing is... This whole argument rests on the assumption that if there
are no braces, there is only one set of things, but if you have braces,
there are two.
This is untrue.
If there are no braces, there are two things describing flow control;
indentation and programmer intent. With braces, there's three.
The most common misalignment is between the code as interpreted by the
computer and the programmer's intent. Neither system prevents this, but
that's where all the real hassle comes from.
My expectation would be that the only times braces and indentation
would be ambiguous would be cases where the indentation got screwed up.
In these cases, I would MUCH prefer to get a fatal error than to have
things run in a way entirely unrelated to the intent I had when I wrote
the code.
The ambiguity is resolved by having exactly one of indentation or braces
determining structure: Python uses indentation. In which case, braces
are pointless for indicating block structure.
I don't think so, any more than I think parentheses which happen to align
with the existing precendence rules are pointless.
In the real world, we are confronted constantly with tools which work
perfectly with every programming language but Python or very old FORTRAN,
but which mangle Python code sporadically and inexplicably. Mail servers
chew up whitespace like there's no tomorrow. Web pages find innovative new
explanations for why those leading spaces don't need to be displayed.
I like Python a lot in some ways, but I am really sick of the insistance that
this godawful wart is the sublime epitome of all perfection, never to be
improved on. It was a really interesting experiment. As sometimes happens,
the experiment discovered things that no one could have reasonably anticipated
without running the experiment.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: What was your strategy?
On 2010-11-14, Jorge Biquez jbiq...@icsmx.com wrote: I was wondering if you can share what was the strategy you followed to master Python (Yes I know I have to work hard study and practice a lot). I mean did you use special books, special sites, a plan to learn each subject in a special way. I would like to know, if possible, comments specially from some of you who in the past had other languages, frameworks and platforms and left (almost) all of them and stayed with Python. I've been learning Python the same way I learn any language; get a book, read it over lunch for a few days, start typing, ask people how to improve my code once I have some. This information is almost certainly useless to you, though, unless you've already learned at least six or seven programming languages. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Caret character (^)
(Note followups, this has stopped being very Pythony.) On 2010-11-11, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: Another function that should be deprecated is strncat???I myself was caught out misunderstanding it recently. What purpose does it serve? I'm wondering if you're thinking of strncpy(), which is the famously bogus one. strncat() just has a fencepost error -- given a limit N, it will write at most N+1 characters. strncpy(), however, pads with null bytes if the source string isn't long enough, and does not null terminate if there isn't room to. This behavior is nearly always undesireable. However, if you were building a filesystem in which file path names were given exactly sixteen bytes of space in the directory entry, and you didn't want to truncate them to 15 bytes, you might write precisely this behavior. So that's what we got. I don't know whether anyone's gotten buy-in from the standards people for strlcpy()/strlcat(), but I really hope so. Me, I just use snprintf with a %s format instead of str*cpy(). -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to test if a module exists?
On 2010-11-11, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message mailman.843.1289438674.2218.python-l...@python.org, Tim Chase wrote: Amusingly, as others have noted, you replied with an unobfuscated email address. This http://mail.python.org/pipermail/python-list/2010-November/1260153.html would seem to be an independent, true record of what members of python-list would see of my posting, would it not? It might or might not be. Not all of us are members of python-list. I'm reading this on Usenet. (Where the only distinction I see is that the country name is spelled out.) You would agree that it shows my e- mail address as obfuscated, would you not? I don't know whether that counts as obfuscated. So if you claim to be seeing an unobfuscated e-mail address for my posting on python-list, you would be lying, would you not? I have found that, in general, the chances that someone is lying are very low. The chances are much higher that they are mistaken, or that I have misunderstood their claim. Or for that matter, that there's Something Strange Going On. Say, someone's got a Usenet provider that Helpfully Fixes things, or someone set up an aliasing thing in a Very Clever newsreader some time back so they could reply to your posts and didn't notice it was then performing the same aliasing when displaying the group, or... Usually, with people who aren't obvious frothing kooks, I tend to view lying as being an extremely unusual explanation. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to test if a module exists?
On 2010-11-11, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message mailman.894.1289510633.2218.python-l...@python.org, MRAB wrote: ... the next one at 3 Nov 2010 22:40 Re: Allowing comments after the line continuation backslash and _all_ the subsequent ones arrived with an _unobfuscated_ email address. You mean from this one on http://mail.python.org/pipermail/python-list/2010-November/1259515.html? Just as a data point: I'm using comp.lang.python via NNTP from Megabitz, reader is SLRN, and I still see .gen.new_zealand. Sounds to me like some source may be helpfully fixing the address as it forwards things. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to test if a module exists?
On 2010-11-11, Tim Chase python.l...@tim.thechases.com wrote: === From: Lawrence D'Oliveiro unobfuscated Newsgroups: gmane.comp.python.general Oh, interesting. Gee...your unobfuscated email addresses FROM YOU. No, from gmane. Out here in comp.lang.python (no gmane), it's obfuscated. So it sounds like there is an entity other than Lawrence deobfuscating the addresses, but it's not a specific poster here. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to test if a module exists?
On 2010-11-12, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: I have just received an admission from Barry Warsaw that a hack was done on python-list specifically to deal with bounces caused by a list member trying to reply to my obfuscated e-mail address. That's... Fascinating. But it does mean that the people who were reporting seeing it were, in fact, merely accurately reporting on what they saw. As for those who persisted in posting my address after being warned of this, I???m still deciding what to do. I would suggest, very strongly: Nothing. 1. Genie, bottle, out. 2. At least some were quoting your posts to show what they looked like, which is hardly a great abuse. Look... You're dealing with humans. Walk up to a human holding something. Say smell this, it smells like ass!. Watch them smell it, and then react with shock if it smells bad. Tell them something is too hot to touch safely, and they will touch it to see whether this is true. You told them that your posts were under an obfuscated address, so they quoted the address they saw and said you mean this one? None of the people in question were the ones who decided to de-obfuscate the address. None of them had, prior to your announcement, any way to know that de-obfuscation was even occurring, and from all the evidence available to them, the most reasonable inference would have been that you were mistaken about how your posting software was configured. When I offered the speculative notion that some gateway somewhere was deobfuscating this address, I didn't think it was *likely*, merely more likely than people lying. As a matter of fact, that you jumped directly to the accusation that other people were lying suggests strongly that you the possibility that this was happening *did not even occur to you*. I put it to you that if the possibility is implausible and unusual enough that it did not even *occur* to you to consider it until multiple people had pointed to multiple citations, it is likely that it *also* did not occur to the various other participants. All they could see was posts by you, showing a particular email address, in which you claimed that it was very rude for people other than you to include that email address in posts. I would also suggest a more general observation: Had you approached this with less hostility, I suspect you would have gotten more cooperative responses, rather than indignation. People accused of doing a thing that they very definitely did not do are not going to be inclined to respond in a helpful manner. Had your post said something like: I notice that in your post, my address is no longer obfuscated. I much prefer that my address be obfuscated on Usenet, and when I send it out, it usually is; see for instance this source (link to python-list) showing that my message had an obfuscated address when it reached python-list. ... I think you would have gotten more helpful responses, and we might have more quickly tracked down that it was apparently specific to some of the many mirrors of this traffic. Finally, last but not least: Since the gmane.* archives have that address, and web crawlers are orders of magnitude more common and more active than usenet crawlers, I would consider the question thoroughly academic at this point. The address is out there. Further use of it on Usenet is unlikely to have a statistically measurable impact. Just as a side note: I have an unobfuscated address in both my signature and my From line. This address is live, it delivers to me, and so on. Yes, I get spam to it. Of the last 26,061 spams I've gotten, it's produced a grand total of 239. So, under 1% of my incoming spam. You can measure the interval during which I cared about that, but if you try to represent it as seconds using 32-bit floating point, it'll turn into 0 because it's under FLOAT_EPSILON. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Caret character (^)
On 2010-11-10, Terry Reedy tjre...@udel.edu wrote: I was referring to Schildt using gets() all the time and thereby teaching new C generations to do he same. Ahh, yes. I am told that the current plan is to kill it in C1X. I would shed no tears. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Caret character (^)
On 2010-11-09, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message slrnidhsbg.g2d.usenet-nos...@guild.seebs.net, Seebs wrote: Not so much turgidity as being WRONG. Consistently and often. Wow. And the guy???s written so many books; how does he get away with it? No one knows or cares. I don't mean no one knows or cares how he gets away with it; I mean no one knows or cares that he's awful. The publisher doesn't care whether the books are accurate, as long as they sell, and most reviewers don't read closely enough to realize he's full of crap. In particular, he's very good at making up complications from whole cloth which aren't really problems, and then offering solutions which show people a clever trick to work around the problem. (e.g., his elaborate revelations about how to use feof() in C to work around his failure to understand how EOF works.) -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best exercises for beginers to learn?
On 2010-11-08, brf...@gmail.com brf...@gmail.com wrote: I was wondering if there are any good exercises that you would recommend learning? Yes. *Write something you want to use.* Nothing will teach you programming as fast as programming stuff you care about for the joy of having it. Exercises that you don't care about in their own right will not catch you the same way. If you write something you want to have, you will not stop when it happens to work, but will keep tweaking it and improving it so it does what you want. That will teach you more than *any* prefab exercise that has no particular significance to you. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic/idiomatic?
On 2010-11-09, Jean-Michel Pichavant jeanmic...@sequans.com wrote: One pythonic way to do it, is to use an option parser. That seems like massive overkill -- I don't care about any of the other options. It seems like it'd result in doing more work to get and then extract the options, and most of that would be discarded instnatly. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Caret character (^)
On 2010-11-09, Terry Reedy tjre...@udel.edu wrote: I've been wondering why C programmers keep writing code susceptible to buffer overruns ;=). Because we're dumb! (Actually, in my defense, my code almost never, if ever, has buffer overruns. I do in some rare cases have truncation issues with sufficiently ridiculous input data.) Your two 'nitpicks' about fflush have both come up on this list as real issues causing people problems. So I agree that it needs to be explained properly and completely as you suggest. Huh. Since Schildt fell out of favor, I've almost never seen people trying to fflush(stdin), and the update rules are weird enough that I don't think I've ever seen anyone try to use it. :) -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Caret character (^)
On 2010-11-10, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: What was sad to me to read http://www.seebs.net/c/c_tcn4e.html was this phrase of yours: ... but rather, takes the shortest path to something that won't get those complaints anymore ... To me, this is the sign of someone who doesn't really enjoy what they do. Yes. I both write and program, and I do them because I love them. If I won the lottery tomorrow (and hey, my chances are only very very slightly lower than everyone else's), I wouldn't stop programming or writing. I might change my focus some, but both of them are things I'd keep doing. Because somebody who cares about what they do would take the trouble to get it right. But if he can't be bothered, why does he keep doing it? There must be more pleasant ways of getting a meal ticket... It's hard to say. I get the feeling sometimes that he's one of the people to whom programming is sort-of-fun, but not fun when you have to get all persnickety about it. Similarly, writing is fun if you're getting praised for it, but dealing with criticism is harder. (Trust me, I know of this; I have gotten a fair number of corrections over the years.) That said, I suspect he's made a fairly large amount of money; multiple bestsellers is a pretty good way to make a decent bit of pocket change. I may have my gripes about Python, but I will say this: The Python community seems full of people who are passionate about writing good code. I would much rather be in a community of people who care a lot about how I should do things, but I think they're wrong, than about people who figure anything that the interpreter accepts is fine. I can learn from people I disagree with, but not from people who don't care. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Pythonic/idiomatic?
I have an existing hunk of Makefile code:
CPPFLAGS = $(filter -D* -I* -i* -U*,$(TARGET_CFLAGS))
For those not familiar with GNU makeisms, this means assemble a string
which consists of all the words in $(TARGET_CFLAGS) which start with one
of -D, -I, -i, or -U. So if you give it
foo -Ibar baz
it'll say
-Ibar
I have a similar situation in a Python context, and I am wondering
whether this is an idiomatic spelling:
' '.join([x for x in target_cflags.split() if re.match('^-[DIiU]', x)])
This appears to do the same thing, but is it an idiomatic use of list
comprehensions, or should I be breaking it out into more bits?
You will note that of course, I have carefully made it a one-liner so I
don't have to worry about indentation*.
-s
[*] Kidding, I just thought this seemed like a pretty clear expression.
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-08, Michael Torrie torr...@gmail.com wrote: On 11/06/2010 02:27 AM, Seebs wrote: I have yet to find an editor that allows me to, well, *edit*, more comfortably than vi. Indeed vi (or in my case, vim) works wonderfully well with python. I always use the following vim settings on python files: Ahh, but I use nvi, not vim. If you set up a conditional thing in your vimrc to enable these settings for python files, you shouldn't have any more tab problems. And I don't think I can do that in nvi -- I don't think it has conditionals. Although. You've just caused me to remember something which is in context both amusing and funny. Which is that I believe nvi has support for some embedded scripting functionality, at least as an optional build choice. Which I've never used, on the grounds that I don't know Python... So that may actually be possible. I'll look into it, for sure. Thanks for nudging my memory. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-08, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message 87oca1b8ba.fsf@metalzone.distorted.org.uk, Mark Wooding wrote: Vertical space is a limiting factor on how much code one can see at a time. One thing that helps me is that Emacs has commands for quickly jumping between matching brackets. Of course, this only works for languages that have brackets. Yes. One of the things I find frustrating about the Ruby idiom of preferring do/end for multiline blocks is that you can't fence-match them. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic/idiomatic?
On 2010-11-09, Ben Finney ben+pyt...@benfinney.id.au wrote:
For this purpose, there is a generator expression syntax
URL:http://docs.python.org/reference/expressions.html#generator-expressions,
almost identical to a list comprehension except without the enclosing
brackets.
' '.join(x for x in target_cflags.split() if re.match('^-[DIiU]', x))
Ahh, handy.
I am torn very much on the generator/comprehension syntax, because on the
one hand, I really prefer to have the structure first, but on the other hand,
I can't easily figure out a way to make the syntax work for that.
The regex is less clear for the purpose than I'd prefer. For a simple
???is it a member of this small set???, I'd find it more readable to use a
simple list of the actual strings::
' '.join(
x for x in target_cflags.split()
if x in ['-D', '-I', '-i', '-U'])
The regex is intentionally not anchored with a $, because I'm looking
for starts with, not is.
The latter works only in Python with set literals (Python 2.7 or later).
I think we're stuck with backwards compatibility at least as far as 2.4.
No, I'm not kidding. *sigh*
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Commercial or Famous Applicattions.?
On 2010-11-09, rantingrick rantingr...@gmail.com wrote: Commenting on which language is better than this one or which language boasts the most achievements is nothing more than time very poorly spent. This is mostly true, but I don't think it's entirely true. It is certainly possible for someone else's language choices to affect me (if I get called in to fix their code). And as a result, I do try to do at least a little language advocacy. Specifically, I try to steer people away from PHP. I can live with just about everything else. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic/idiomatic?
On 2010-11-09, Ben Finney ben+pyt...@benfinney.id.au wrote: Seebs usenet-nos...@seebs.net writes: I think we're stuck with backwards compatibility at least as far as 2.4. Then you don't yet have the ???any??? and ???all??? built-in functions, or the tuple-of-prefixes feature of ???str.startswith??? either. Bummer. Eww. At which point, the Pythonic thing to do is to convince your organisation to use a version of Python that's at least officially supported by the PSF :-) Unfortunately, we're selling something to people who will explode if we tell them to upgrade their RHEL4 systems, so we have to work on those. (There is some tiny hope that we'll be able to move the baseline to RHEL5 within another two years.) If it were only a matter of internal use, my job would be orders of magnitude easier. (I'm maintaining something that intercepts and wraps large hunks of the standard C library; if you think dealing with Python 2.4 is a burden, you ain't seen *nothing* compared to that.) -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Carrot character (^)
On 2010-11-09, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message mailman.697.1289067607.2218.python-l...@python.org, Dennis Lee Bieber wrote: Have you ever looked at the reference manual for Ada? Or even worse, the annotated reference. I thought annotations were supposed to clarify things; in this case they seemed to have the opposite effect... Clearly, you've never seen Schildt's infamous Annotated ANSI C Standard. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Caret character (^)
On 2010-11-09, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message slrnidhcns.9m6.usenet-nos...@guild.seebs.net, Seebs wrote: On 2010-11-09, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: Or even worse, the annotated reference. I thought annotations were supposed to clarify things; in this case they seemed to have the opposite effect... Clearly, you've never seen Schildt's infamous Annotated ANSI C Standard. There absolutely no chance (or at least no way I can imagine) that anyone could annotate a concise language like C up to the level of turgidity of the Ada spec. Not so much turgidity as being WRONG. Consistently and often. Hang on, is this Herb Schildt? I bought a couple of his books, back when I was trying to get to grips with C++ (I have the edition of ???C++ The Complete Reference??? which proudly proclaims it ???Covers the New International Standard for C+???). Not as useful as I thought they would be; I ended up referring to the libstdc++ sources to clarify things. Yes, Herb Schildt: http://www.seebs.net/c/c_tcn4e.html (I know too little about C++ to criticize is writings about it, but people have told me they're comparable.) -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Carrot character (^)
On 2010-11-07, Nobody nob...@nowhere.com wrote: I'm arguing that the reference manual reads too much like a specification. E.g. look at 5.2.4. List displays and tell me whether you consider that it adequately /explains/ list displays to someone wishing to use them. Seems pretty explanatory to me. I mean, maybe it helps that I already basically understood both of the things you could put in [], but it's pretty clear. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-07, Grant Edwards inva...@invalid.invalid wrote: On 2010-11-07, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message 87sjzige0r@benfinney.id.au, Ben Finney wrote: The more general answer is: the block is explicitly ended where the indentation ends. That's implicit, not explicit. If you can _see_ it, how is it implicit? Humans can see negative space. It's still implicit. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Carrot character (^)
On 2010-11-07, Roy Smith r...@panix.com wrote: Well, maybe I was being a little sarcastic. The real point was that if you make it hard for people to do the right thing (i.e. look up the details in the reference manual), you should not be surprised if they do the wrong thing (i.e. find some way to make it work by trial and error). Fair enough. That said, I don't think it's the *writing* of the C spec that would make it hard for people to look up details. Dunno for C++. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-07, Mark Wooding m...@distorted.org.uk wrote: I've no idea how people manage with these ridiculous widescreen monitors. Side space used for Other Stuff. It takes some reworking of the layout, but overall I sorta like it now. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-07, Ethan Furman et...@stoneleaf.us wrote:
Seebs wrote:
On 2010-11-05, Ethan Furman et...@stoneleaf.us wrote:
The verifiable benefit for me is ease of use, ease of thought, ease of
typing... I realize these are not benefits for everyone, but they are
for some -- and I would venture a guess that the ease of thought benefit
is one of the primary reasons Python is popular. I am definitely one of
those that think indentation based structure is one of Python's best
features.
Could you explain more the ease of thought thing? I haven't yet noticed
it, but it might be something to look out for as I get more experienced.
Most if my programming experience is in FoxPro versions 2 and 6.
Control structures start with if, for, do case, do while, with,
procedure, and (I think) function. Control structures end with endif,
endfor, endcase, endwhile, endwith, endproc, and (I think) endfunc.
Eww.
In Python, control structures start with if, for, while, try, def, and
class, and each one ends with a dedent.
So they're more consistent.
This really comes into play when developing -- want to change that if to
a while? Go ahead! And no need to worry about tracking down the
closing endif to change it to endwhile, plus it's less clutter on the
screen.
I can see that. I actually mostly prefer an explicit close. Of the things
I've used, I'm happiest with braces, because punctuation is good at
being interpreted unconsciously, but I'm okay with end as long as it's
the same for everything. I do like having a things bounded, though; I
find it easier to read:
if (foo) {
bar;
}
baz;
than
if foo:
bar
baz;
(I'm not quite sure why, but I think it's because the trailing boundary is
part of the thing it bounds, rather than being the start of the thing after
it.)
I would definitely agree, though, that the Python solution is better
than what you describe for FoxPro. It's also better, IMHO, than sh.
I also really like the dynamic typing and not having to declare nor
pre-initialize variable names, as well as the lack of a true global
namespace.
I am torn on declarations -- I am pretty sure I make more mistakes
with clashing variable names when they aren't explicitly declared, but
I do like the much shorter code that results from not having them.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-06, Steve Holden st...@holdenweb.com wrote: If someone were to use a text editor which had always historically mangled whitespace I would find myself wondering why they found it necessary to restrict themselves to such stone-age tools. I have yet to find an editor that allows me to, well, *edit*, more comfortably than vi. As to what it does with whitespace... What it does is exactly what is most desireable in every other kind of file I edit. I wouldn't normally refer to it as mangling in the pejorative sense; it mostly leaves spaces alone, but when preserving indentation from one line to the next, uses tabs. That, it turns out, is useful and desireable in nearly all programming languages, and in particular, in all the other programming languages I use. I don't think it's fair to accuse tools of being stone age on the grounds that they do something which most users want most of the time by default. The no tabs, only spaces thing is an interesting idiosyncrasy of a particular community, which places a high value on telling people to change everything about their computing environment so they can appreciate how robust Python is when you make a point of blaming any and all quirks or nuisances on tools. We might as well insist that everyone use editors which automatically add the braces to C code (such exist) when they complain about the effort of typing matching braces. Surely, if you have to type braces by hand, the problem isn't with C, but with your stone age editor? Oh, wait. That kind of smug dismissiveness is considered rude unless it's done in *favor* of Python. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Carrot character (^)
On 2010-11-06, Hrvoje Niksic hnik...@xemacs.org wrote: I don't speak for Nobody, but to me a reference manual would be a document intended for the user of the language. The thing for the language lawyer is something intended for the implementor, or possibly for the very advanced user who argues with the implementor about intricacies of behavior. The latter document is also known as the specification or the standard. I guess I would think that if such a document cannot be used as a reference, it's not very well done. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Carrot character (^)
On 2010-11-06, rantingrick rantingr...@gmail.com wrote: On Nov 5, 5:51?pm, Seebs usenet-nos...@seebs.net wrote: I'm a bit lost here. ?Could you highlight some of the differences between a reference manual for the language itself and something written for language lawyers? In a word HUMOR! Huh? Obviously the commentator who has a lack of the hidden meaning of language lawyers has no sense of humor -- sadly another lost virtue of the French! It is a shame that there was a guy standing behind you with a gun preventing you from explaining what the alleged hidden meaning was, so all you could do is allude to it without explaining it. Maybe later you can get away from your captors and post an explanation of what the hidden meaning is, in your eyes? -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to test if a module exists?
On 2010-11-06, Roy Smith r...@panix.com wrote: from __future__ import bugs Now I want this. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Carrot character (^)
On 2010-11-07, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: Surely a tutorial tells you *how* to use the language. I wouldn't expect a reference manual to teach me how to run and edit programs -- the *how* of using the language. There's a sort of fuzzy boundary about how the term reference manual is used. Some people view it more in terms of presenting, for each major feature or class of functionality, an overview of what you need to know to use it, which may not be everything you need to know to implement it correctly. Consider: In Python, indentation determines control flow. Statements which take a block of code must be followed by at least one line of a greater indentation level; all following lines of that indentation level are part of the block, ending at the first line which is less indented than the block. Each block should be indented by four spaces from the preceeding block, and tabs should not be used. That might be quite suitable* for a reference manual as many people use the term, but would be useless for a language lawyer. A language lawyer needs to know that \t at the beginning of a line is construed to be the same indentation level as or \t. A typical reference manual might simply ignore that information because it's telling you what you need to write good code, not what you need to know to write a compatible implementation. That said... I am certainly biased on the issue, but IMHO a reference manual should not gloss over things like that, but should be at least as detailed as a formal specification; where it might differ is in *additional* material with explanations and clarifications. YMMV. -s [*] Well, imagine that, only written better and properly edited, and so on. -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-07, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message slrnid9ln8.30fm.usenet-nos...@guild.seebs.net, Seebs wrote: Four spaces followed by a tab nearly always actually means eight spaces to most editors (and Python seems to treat it that way), but it's hard to tell. Worse, a tab may have been intended to be the same thing as four spaces, and someone was expecting it NOT to be the same as eight spaces... Whereas explicitly-bracketed languages leave no ambiguity about how many brackets you need and where. Well, the good ones don't. :P (I think the optional nature of brackets is probably a flaw in C. It would break too much existing code to fix it, sadly.) -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Carrot character (^)
On 2010-11-07, Hrvoje Niksic hnik...@xemacs.org wrote: It's not a matter of quality, but of intended audience. To most ordinary programmers the standards documents such as the C standard, the C++ standard, or the Python reference are quite dense and hard to use as a reference, and yet they are considered quite well done. Huh. I quite liked the C spec as a reference. Yeah, it's a bit dense, but that just means it's all actually *reference*. :) -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Silly newbie question - Carrot character (^)
On 2010-11-07, Roy Smith r...@panix.com wrote: Any self-respecting C++ programmer would have given up the scavenger hunt by now. Just kept throwing typecasts at your code until it compiles, and move on. That does not sound like a self-respecting programmer of anything. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-07, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sun, 07 Nov 2010 14:53:45 +1300, Lawrence D'Oliveiro wrote: In message slrnid9ln8.30fm.usenet-nos...@guild.seebs.net, Seebs wrote: Four spaces followed by a tab nearly always actually means eight spaces to most editors (and Python seems to treat it that way), but it's hard to tell. Worse, a tab may have been intended to be the same thing as four spaces, and someone was expecting it NOT to be the same as eight spaces... Whereas explicitly-bracketed languages leave no ambiguity about how many brackets you need and where. Yes, and? In context, I think the comment was sarcastic, referring to C's famous ambiguities caused by optional braces. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-05, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: How does an edit accidentally add a trailing space to a large number of lines? I would love to know the answer to this question. However, empirically, it happens. My guess would be cutting and pasting in some way. So we keep coming back to work-arounds for tools that mangle your data for no good reason... To some extent, this is true. How about this. How about we make the Python TCP Stack. The Python TCP Stack works on the same principles that you advocate for the Python language. For instance, if any packet it receives is malformed or contrary to the applicable specs, it has a 95% chance of dropping the packet, and a 5% chance of interpreting the packet as being of a different type entirely. This will NEVER be a problem, and is a good design, because handling packets which contain any kind of spec violation is just work-arounds for broken tools, right? And the first thing we should do is *always* to ensure that, if anything anywhere does not live up to our proposed specification, it causes us to fail in spectacular ways. Of course, to fully capture the feel of Python's choice here, we have to include some common packet variant, which violates no RFCs, as one of the broken ones on the grounds that it doesn't make sense to us and isn't easy for a newcomer to read. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-05, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Thu, 04 Nov 2010 20:17:35 +, Seebs wrote: That was the thing which bit me the worst. I had a fairly large block of code in a first-pass ugly program. I wanted to start refactoring it, so I moved a big hunk of code into a method (with plans to further refactor). It took about fifteen minutes to redo the logic. Well there's your problem -- you are relying on tools that operate by magic. Wrong. Rather than re-create the logic, why not just hit Undo and then re-paste the code *without* the magic auto-reformat? Half a second, to undo and re- paste, followed by 10 or 20 seconds to select the appropriate lines and *explicitly* re-indent the lines to the correct level. There was no magic auto-reformat. Where did you invent that from? Why are you making stuff up which I never said or referred to? For somebody who keeps tossing around the mantra that explicit is better than implicit, you're amazingly reliant on a tool that performs massive, apparently irreversible formatting operations implicitly. No, I am not. No such tool was involved. I never mentioned one, referred to one, or hinted at one -- and have never used one, because I hate them. In fact, it is ludicrous to imagine that I was using one, given that I've stated in this very thread that so far as I know such a tool cannot be created for Python. Your decision to invent something I never referred to is not a problem with my approach to the language. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On 2010-11-05, Emile van Sebille em...@fenx.com wrote: So, which of your tools are you married to that are causing your issues? Python. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
