Re: More list building
On Wednesday, May 11, 2016 at 1:22:09 PM UTC-4, DFS wrote:
> Have:
> p1 = ['Now', 'the', 'for', 'good']
> p2 = ['is', 'time', 'all', 'men']
>
> want
> [('Now','is','the','time'), ('for','all','good','men')]
>
> This works:
>
> p = []
> for i in xrange(0,len(p1),2):
> p.insert(i,(p1[i],p2[i],p1[i+1],p2[i+1]))
>
>
> But it seems clunky.
>
> Better way(s)?
>
> Thanks
Would this work for you? Or do you need something more general?
t = list(zip(p1,p2))
p = [t[0]+t[1],t[2]+t[3]]
--
https://mail.python.org/mailman/listinfo/python-list
Re: A Pragmatic Case for Static Typing
On Monday, September 2, 2013 1:10:34 AM UTC-7, Paul Rubin wrote: > "Russ P." writes: > > > I just stumbled across this video and found it interesting: > > > http://vimeo.com/72870631 > > > My apologies if it has been posted here already. > > > > The slides for it are here, so I didn't bother watching the 1 hour video: > > > > http://gbaz.github.io/slides/hurt-statictyping-07-2013.pdf > > > > I guess for Python programmers looking to expand their horizons a bit, > > it's worth at least looking at the slides. But, it may overstate its > > case a little bit. Haskell's type system is way cool but the language > > introduces other headaches into programming. I thought the video was amusing, but I am probably easily amused. I noticed that he did not list my current main language, Scala, as statically typed. I am not sure why, but perhaps because it inherits null from Java. In any case, his main point was that static typing reduces time to working code. I have no doubt that is true for large-scale programming, but I doubt it is true for small-scale programming. The question is where the crossover point is. -- http://mail.python.org/mailman/listinfo/python-list
A Pragmatic Case for Static Typing
I just stumbled across this video and found it interesting: http://vimeo.com/72870631 My apologies if it has been posted here already. -- http://mail.python.org/mailman/listinfo/python-list
Re: Idea for key parameter in all() builting, would it be feasible?
>All you need is the iterator version of map(). In Python 3, that's the >normal map(); in Python 2, use this: from itertools import imap all(imap(lambda x: bool(x), xrange(10**9))) >False >It's roughly instant, like you would expect. >ChrisA This probably isn't the way to post a reply on your own thread (I added an angle bracket to every line above :P) but last time clicked reply to author not knowing that is email. Anyways... Thanks, I like itertools but had no idea imap. Although I did suspect Python3 would have something to say about this just to make me envious :D It works like a charm! -- http://mail.python.org/mailman/listinfo/python-list
Idea for key parameter in all() builting, would it be feasible?
I was mucking around, trying to code a prime sieve in one line. I don't know about filters and bit shifting and stuff like that but I thought I could do it with builtins, albeit a very long one line. This is the part of my stupid trick in question that got me wondering about a key parameter for all() and the "why" is below that. [n for n in xrange(3, int(pow(upper, 0.5) + 1), 2) if all(map(lambda d: n%d!=0, xrange(2, int(pow(n, 0.5) + 1] Where upper is the upper bound for the sieve. That list comprehension will provide a list of prime numbers up to the square root of upper using trial division. Then that list was going to be used for the rest of the sieve using the set.difference method to remove multiples of all those primes. That's when I realized that all() doesn't necessarily go through every item in the alterable. It's stops the moment it finds a false value. You can test that that's true with. >>> all(xrange(10**9)) It's instant because 0 is the false value and so it stops and returns false after only checking the first value. Also because we're using xrange the generator function cousin of range. The following on the other hand should take a while. >>> all(xrange(1, 10**9)) And the following, although the same thing really as all(xrange(10**9)), is not as instant and will take even longer than the above. >>> all(map(lambda x: bool(x), xrange(10**9))) However if all by some chance (I don't know how this stuff works underneath) has a key parameter then we could do something like. >>> all(xrange(10**9), key=lambda x: bool(x)) Which would return False instantly (ideally). -- http://mail.python.org/mailman/listinfo/python-list
Re: My son wants me to teach him Python
I couldn't read every post here so don't know if this has been suggested, or if there is perhaps a better suggestion which I haven't read in this thread, but in as far as I've read I feel the need to recommend: learnpythonthehardway.org Knowing a little JavaScript and even allot of HTML doesn't take him out of the total noob category when it comes to programming (did someone say game programming? Hold your horses!). I took a visual basic course (which I dropped out of admittedly after 3 months) and still knew absolutely nothing, which isn't necessarily just because I'm dumb. After eventually learning Python in incremental and sporadic episodes of free time, I did come across a few resources and by virtue of the frustration of having taken so long to learn to code in the easiest damn programming language to learn, I found myself scrutinizing allot of the tutorials I'd been passing by. I noticed developers.google.com somewhere up there. That's just a no no. Sorry. Maybe some of the people here are more than "pretty smart" but there's a good chance it'll be over his head at first, and at first is a bad place to be in over your head when you're learning the fundamentals. I also notice Invent with python. I personally would go for 2.x rather than 3 but that aside, for reasons I'm too tired to word, I didn't find it a good fit for me. I takes a "dive right in" approach and well, I never did learn to swim. Udacity was the third suggestion I noticed. This is also a no no. I completed the cs101 udacity course which I'm sure is the course in question here, and I loved it! Really I learn crap load from it, but at every step I asked myself, would this had helped if it was the first place I went to to learn to code? No. There were allot of gaps I noticed when looking from a complete beginners perspective and even though the course claims to has no prerequisites, I would have hated if I started with that. However that was last year and I think it was only a few months old, so it may be allot different now, I haven't checked. I read How to think like a computer scientist, A byte of python, and even the official docs. The only one I came across that made me say "&*#! why didn't I google that?" was learnpythonthehardway. I do think it depends a great deal on the individual, and for me personally, that style of learning was just it. For one you learn from the bottom up. It's a compulsion for some to know that that know a thing before they're brave enough to move forward. In cases where a "leap" is the only way forward, the tutor pulls you across that divide by your ankles. You feel a sense of obligation to take to his instruction. And above all, it greatly emphasizes the "learn by doing" approach, in small steps, not big projects that you end up completing just to get through it but don't learn much from. So that's my recommendation. But all that aside, my biggest point would be, just pick one do it. As you can see if you read that, my biggest flaw was simply the lack of devotion to one path. Game programming if he still wants to do that is another question entirely I feel. Fundamentals are fundamentals. The only variable is how long it might take him to get passed it. Even with Python, some people just never get it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Simple program question.
input() is a function which returns a string. You can assign this return value to a variable. That's what variables are for. option = input() Now you can use the variable named option in place of all those calls to input(). i.e: ...instead of.. if input() == 'parry': # etc ...do this... option = input() if option == 'parry': # etc elif option == 'whatever': # etc -- http://mail.python.org/mailman/listinfo/python-list
Re: Reply to post 'Tryign to add a valkue to a set'
Just try this in the interpreter and see. for key, value in sorted(months.items(), key=lambda x:x[1]): print "%s %s" % (value, key) -- http://mail.python.org/mailman/listinfo/python-list
Re: Reply to post 'Tryign to add a valkue to a set'
for key, value in sorted(months.items(), key=lambda x:x[1]):
print("""'\t%s'\n""" % (value, key))
Explanation:
- - - - - -
dict.items is a method associated with dicts just like dict.keys or
dict.values, and returns a list of (key, value) pairs.
sorted and some other builtin functions have an optional key argument, which
tells the function what exactly to look at when sorting the sequence. (I say
sequence because you can sort a string or tuple or dict and get a list back in
return). In this case we use a simple lambda function to tell it to look at the
value not the key (i.e. (key, value)[1] returns value)
Alternatively you could do this.
def get_value(item):
return item[1]
for key, value in sorted(months.items(), key=get_value):
...etc...
You might also wonder what this would do
for key, value in sorted(months.items()):
...etc...
Which becomes a question of what would something like this do
sorted([(1,3), (2,2), (3,1)])
Well sorted is a function that expects to get some iterable (sequence of some
kinda items) to sort. If those items happens to be sequences themselves, like
(key, value) which is a sequence of two items, then it's only going to care
about the first item and ignore the rest (i.e ignore value).
So the above will return
[(1,3), (2,2), (3,1)] which as far as sorted() is concerned, is already sorted.
About the string being printed:
- - - - - - - - - - - - - - - -
I'm not sure why or if you want a single quotation around the entire element to
be printed as well but if so then that's how I'd do it. The \t is for a tab.
You also don't have to worry about adding newlines because print will print
each statement on a newline anyways by default unless you tell it otherwise by
specifying the sep argument.
Sorry my first post, I said allot didn't I.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
On Thursday, June 6, 2013 2:29:02 AM UTC-7, Steven D'Aprano wrote: > On Thu, 06 Jun 2013 12:29:44 +1000, Chris Angelico wrote: > > > > > On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano > > > wrote: > > >> On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote: > > >>> As for Python, my experience with it is that, as your application > > >>> grows, you start getting confused about what the argument types are or > > >>> are supposed to be. > > >> > > >> Whereas people never get confused about the arguments in static typed > > >> languages? > > >> > > >> The only difference is whether the compiler tells you that you've > > >> passed the wrong type, or your unit test tells you that you've passed > > >> the wrong type. What, you don't have unit tests? Then how do you know > > >> that the code does the right thing when passed data of the right type? > > >> Adding an extra couple of unit tests is not that big a burden. > > > > > > The valid type(s) for an argument can be divided into two categories: > > > Those the compiler can check for, and those the compiler can't check > > > for. Some languages have more in the first category than others, but > > > what compiler can prove that a string is an > > > HTML-special-characters-escaped string? In a very few languages, the > > > compiler can insist that an integer be between 7 and 30, but there'll > > > always be some things you can't demonstrate with a function signature. > > > > > > That said, though, I do like being able to make at least *some* > > > declaration there. It helps catch certain types of error. > > > > *shrug* > > > > I don't terribly miss type declarations. Function argument declarations > > are a bit simpler in Pascal, compared to Python: > > > > > > Function Add(A, B : Integer) : Integer; > > Begin > > Add := A + B; > > End; > > > > > > versus > > > > > > def add(a, b): > > if not (isinstance(a, int) and isinstance(b, int)): > > raise TypeError > > return a + b > Scala also has isInstanceOf[Type] which allows you to do this sort of thing, but of course it would be considered terrible style in Scala. > > > > but not that much simpler. And while Python can trivially support > > multiple types, Pascal cannot. (Some other static typed languages may.) > > > > Whatever benefit there is in declaring the type of a function is lost due > > to the inability to duck-type or program to an interface. There's no type > > that says "any object with a 'next' method", for example. And having to > > declare local variables is a PITA with little benefit. > > > > Give me a language with type inference, and a nice, easy way to keep duck- > > typing, and I'll reconsider. But until then, I don't believe the benefit > > of static types comes even close to paying for the extra effort. Scala has type inference. For example, you can write val x = 1 and the compiler figures out that x is an integer. Scala also has something called structural typing, which I think is more or less equivalent to "duck typing," although I don't think it is used very often. Are you ready to try Scala yet? 8-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
On Wednesday, June 5, 2013 7:29:44 PM UTC-7, Chris Angelico wrote: > On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano > > wrote: > > > On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote: > > >> As for Python, my experience with it is that, as > > >> your application grows, you start getting confused about what the > > >> argument types are or are supposed to be. > > > > > > Whereas people never get confused about the arguments in static typed > > > languages? > > > > > > The only difference is whether the compiler tells you that you've passed > > > the wrong type, or your unit test tells you that you've passed the wrong > > > type. What, you don't have unit tests? Then how do you know that the code > > > does the right thing when passed data of the right type? Adding an extra > > > couple of unit tests is not that big a burden. > > > > The valid type(s) for an argument can be divided into two categories: > > Those the compiler can check for, and those the compiler can't check > > for. Some languages have more in the first category than others, but > > what compiler can prove that a string is an > > HTML-special-characters-escaped string? In a very few languages, the > > compiler can insist that an integer be between 7 and 30, but there'll > > always be some things you can't demonstrate with a function signature. > > > > That said, though, I do like being able to make at least *some* > > declaration there. It helps catch certain types of error. I recall reading a few years ago that Guido was thinking about adding optional type annotations. I don't know if that went anywhere or not, but I thought it was a good idea. Eventually I got tired of waiting, and I realized that I just wanted a statically typed language, so I started using one. Steven's view on static vs. dynamic typing are interesting, but I think they are "out of the mainstream," for whatever that's worth. Does that mean he is wrong? I don't know. But I do know that statically typed code just seems to me to fit together tighter and more solidly. Maybe it's a liberal/conservative thing. Do liberals tend to favor dynamic typing? -- http://mail.python.org/mailman/listinfo/python-list
Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
On Wednesday, June 5, 2013 4:18:13 PM UTC-7, Michael Torrie wrote: > On 06/05/2013 12:11 AM, Russ P. wrote: > > > But then, what would you expect of a language that allows you to > > > write > > > > > > x = 1 > > > x = "Hello" > > > > > > It's all loosey goosey -- which is fine for many applications but > > > certainly not for critical ones. > > > > This comment shows me that you don't understand the difference between > > names, objects, and variables. May sound like a minor quibble, but > > there're actually major differences between binding names to objects > > (which is what python does) and variables (which is what languages like > > C have). It's very clear Rick does not have an understanding of this > > either. My comment shows you nothing about what I understand about names, objects, and variables. You have chosen to question my understanding apparently because my point bothered you but you don't have a good reply. Then you link me with Rick for good measure. That's two ad hominems in three sentences. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
On Wednesday, June 5, 2013 9:59:07 AM UTC-7, Chris Angelico wrote: > On Thu, Jun 6, 2013 at 2:15 AM, Russ P. wrote: > > > On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote: > > >> I want to launch this rocket with an expensive satellite on top. I know > > >> > > >> it's safe as the code is written in ADA. Whoops :( > > > > > > > > > So Python would have been a better choice? Yeah, right. If you know > > anything about that rocket mishap, you should know that Ada was not the > > source of the problem. Ada won't keep airplane wings from breaking either, > > by the way. It's not magic. > > > > Frankly, I don't think the language much matters. It's all down to the > > skill of the programmers and testers. Ada wasn't the source of the > > problem unless Ada has a bug in it... which is going to be true of > > pretty much any language. Maybe Python would be a better choice, maybe > > not; but let me tell you this, if the choice of language means the > > difference between testable in three months and testable code in three > > years, I'm going for the former. > > > > ChrisA I'm not an Ada guy, but Ada advocates claim that it reduces development time by half in the long run compared to C and C++ due to reduced debugging time and simpler maintenance. Then again, I think Java people make a similar claim. As for Python, my experience with it is that, as your application grows, you start getting confused about what the argument types are or are supposed to be. That requires the developer to keep much more of the design in his head, and that undesirable. Of course, you can always put the argument types in comments, but that won't be verified by the compiler. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote: > On 05/06/2013 07:11, Russ P. wrote: > > > > > But then, what would you expect of a language that allows you to write > > > > > > x = 1 > > > x = "Hello" > > > > > > It's all loosey goosey -- which is fine for many applications but certainly > > not for critical ones. > > > > > > > I want to launch this rocket with an expensive satellite on top. I know > > it's safe as the code is written in ADA. Whoops :( So Python would have been a better choice? Yeah, right. If you know anything about that rocket mishap, you should know that Ada was not the source of the problem. Ada won't keep airplane wings from breaking either, by the way. It's not magic. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
On Wednesday, June 5, 2013 12:15:57 AM UTC-7, Chris Angelico wrote: > On Wed, Jun 5, 2013 at 4:11 PM, Russ P. wrote: > > > On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote: > > > > > >> Yes, but the problem is not "my approach", rather the lack > > >> > > >> of proper language design (my apologizes to the "anointed > > >> > > >> one". ;-) > > > > > > If you don't like implicit conversion to Boolean, then maybe you should be > > using another language -- and I mean that in a constructive sense. I'm not > > particularly fond of it either, but I switched from Python to another > > language a while back. The issue is not a lack of "proper language design" > > but rather a language design philosophy that values conciseness and > > simplicity over explicitness and rigor. > > > > (Out of curiosity, which language? Feel free to not answer, or to > > answer off-list, as that's probably not constructive to the thread.) No problem. I'm using Scala. It has a sophisticated type system. The language is not perfect, but it seems to suit my needs fairly well. > > > I cannot name a single modern programming language that does NOT have > > some kind of implicit boolification. The only such language I know of > > is REXX, which has a single data type for everything, but insists on > > the exact strings "1" and "0" for True and False, anything else is an > > error. Every other language has some definition of "these things are > > true, these are false"; for instance: Scala (and Java) don't do that. Nor does Ada. That's because Ada is designed for no-nonsense critical systems. It is the standard higher-order language for flight control systems, for example. > > It's all loosey goosey -- which is fine for many applications but certainly > > not for critical ones. > > > > The looseness doesn't preclude critical applications. It's all a > > question of what you're testing. Does your code care that this be a > > list, and not something else? Then test! You have that option. What > > happens if it isn't a list, and something is done that bombs with an > > exception? Maybe that's not a problem. > > > > Critical applications can often be built in layers. For instance, a > > network server might listen for multiple socket connections, and for > > each connection, process multiple requests. You would want to catch > > exceptions at the two boundaries there; if a request handler crashes, > > the connection should not be dropped, and if a connection handler > > crashes, the server should keep running. With some basic defenses like > > that, your code need no longer concern itself with trivialities - if > > something goes wrong, there'll be an exception in the log. (BTW, this > > is one of the places where a bare or very wide except clause is > > appropriate. Log and move on.) Well, I don't really want to open the Pandora's box of static vs. dynamic typing. Yes, with enough testing, I'm sure you can get something good out of a dynamically typed language for small to medium-sized applications, but I have my doubts about larger applications. However, I don't claim to be an expert. Someone somewhere has probably developed a solid large application in Python. But I'll bet a dollar to a dime that it took more work than it would have taken in a good statically typed language. Yes, extensive testing can go a long way, but extensive testing combined with good static typing can go even further for the same level of effort. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote: > Yes, but the problem is not "my approach", rather the lack > > of proper language design (my apologizes to the "anointed > > one". ;-) If you don't like implicit conversion to Boolean, then maybe you should be using another language -- and I mean that in a constructive sense. I'm not particularly fond of it either, but I switched from Python to another language a while back. The issue is not a lack of "proper language design" but rather a language design philosophy that values conciseness and simplicity over explicitness and rigor. Implicit conversion to Boolean is only one of many language features that are questionable for critical production software. Another is the convention of interpreting negative indices as counting backward from the end of a list or sequence. Yeah, I thought that was elegant... until it bit me. Is it a bad idea? Not necessarily. It certainly enhances programmer productivity, and it can be done correctly "almost" all the time. But that one time in a hundred or a thousand when you accidentally use a negative index can be a bitch. But then, what would you expect of a language that allows you to write x = 1 x = "Hello" It's all loosey goosey -- which is fine for many applications but certainly not for critical ones. -- http://mail.python.org/mailman/listinfo/python-list
Re: Controlling number of zeros of exponent in scientific notation
One possibility is to form the string as usual, split on the "e", format each part separately, then rejoin with an "e". On Tuesday, March 5, 2013 12:09:10 PM UTC-8, fa...@squashclub.org wrote: > Instead of: > > > > 1.8e-04 > > > > I need: > > > > 1.8e-004 > > > > So two zeros before the 4, instead of the default 1. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy (matrix solver) - python vs. matlab
On May 3, 4:59 pm, someone wrote: > On 05/04/2012 12:58 AM, Russ P. wrote: > > > Yeah, I realized that I should rephrase my previous statement to > > something like this: > > > For any *empirical* engineering or scientific work, I'd say that a > > condition number of 1e6 is likely to be unacceptable. > > Still, I don't understand it. Do you have an example of this kind of > work, if it's not FEM? > > > I'd put finite elements into the category of theoretical and numerical > > rather than empirical. Still, a condition number of 1e6 would bother > > me, but maybe that's just me. > > Ok, but I just don't understand what's in the "empirical" category, sorry... I didn't look it up, but as far as I know, empirical just means based on experiment, which means based on measured data. Unless I am mistaken , a finite element analysis is not based on measured data. Yes, the results can be *compared* with measured data and perhaps calibrated with measured data, but those are not the same thing. I agree with Steven D's comment above, and I will reiterate that a condition number of 1e6 would not inspire confidence in me. If I had a condition number like that, I would look for a better model. But that's just a gut reaction, not a hard scientific rule. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy (matrix solver) - python vs. matlab
Yeah, I realized that I should rephrase my previous statement to something like this: For any *empirical* engineering or scientific work, I'd say that a condition number of 1e6 is likely to be unacceptable. I'd put finite elements into the category of theoretical and numerical rather than empirical. Still, a condition number of 1e6 would bother me, but maybe that's just me. --Russ P. On May 3, 3:21 pm, someone wrote: > On 05/03/2012 07:55 PM, Russ P. wrote: > > > > > On May 3, 10:30 am, someone wrote: > >> On 05/02/2012 11:45 PM, Russ P. wrote: > >>> For any practical engineering or scientific work, I'd say that a > >>> condition number of 1e6 is very likely to be completely unacceptable. > > >> So how do you explain that the natural frequencies from FEM (with > >> condition number ~1e6) generally correlates really good with real > >> measurements (within approx. 5%), at least for the first 3-4 natural > >> frequencies? > > >> I would say that the problem lies with the highest natural frequencies, > >> they for sure cannot be verified - there's too little energy in them. > >> But the lowest frequencies (the most important ones) are good, I think - > >> even for high cond number. > > > Did you mention earlier what "FEM" stands for? If so, I missed it. Is > > it finite-element modeling? Whatever the case, note that I said, "If > > Sorry, yes: Finite Element Model. > > > you are just doing pure mathematical or numerical work with no real- > > world measurement error, then a condition number of > > 1e6 may be fine." I forgot much more than I know about finite-element > > modeling, but isn't it a purely numerical method of analysis? If that > > I'm not sure exactly, what is the definition of a purely numerical > method of analysis? I would guess that the answer is yes, it's a purely > numerical method? But I also thing it's a practical engineering or > scientific work... > > > is the case, then my comment above is relevant. > > Uh, I just don't understand the difference: > > 1) "For any practical engineering or scientific work, I'd say that a > condition number of 1e6 is very likely to be completely unacceptable." > > vs. > > 2) "If you are just doing pure mathematical or numerical work with no > real-world measurement error, then a condition number of, 1e6 may be fine." > > I would think that FEM is a practical engineering work and also pure > numerical work... Or something... > > > By the way, I didn't mean to patronize you with my earlier explanation > > of orthogonal transformations. They are fundamental to understanding > > the SVD, and I thought it might be interesting to anyone who is not > > familiar with the concept. > > Don't worry, I think it was really good and I don't think anyone > patronized me, on the contrary, people was/is very helpful. SVD isn't my > strongest side and maybe I should've thought a bit more about this > singular matrix and perhaps realized what some people here already > explained, a bit earlier (maybe before I asked). Anyway, it's been good > to hear/read what you've (and others) have written. > > Yesterday and earlier today I was at work during the day so > answering/replying took a bit longer than I like, considering the huge > flow of posts in the matlab group. But now I'm home most of the time, > for the next 3 days and will check for followup posts quite frequent, I > think... -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy (matrix solver) - python vs. matlab
On May 3, 10:30 am, someone wrote: > On 05/02/2012 11:45 PM, Russ P. wrote: > > > > > On May 2, 1:29 pm, someone wrote: > > >>> If your data starts off with only 1 or 2 digits of accuracy, as in your > >>> example, then the result is meaningless -- the accuracy will be 2-2 > >>> digits, or 0 -- *no* digits in the answer can be trusted to be accurate. > > >> I just solved a FEM eigenvalue problem where the condition number of the > >> mass and stiffness matrices was something like 1e6... Result looked good > >> to me... So I don't understand what you're saying about 10 = 1 or 2 > >> digits. I think my problem was accurate enough, though I don't know what > >> error with 1e6 in condition number, I should expect. How did you arrive > >> at 1 or 2 digits for cond(A)=10, if I may ask ? > > > As Steven pointed out earlier, it all depends on the precision you are > > dealing with. If you are just doing pure mathematical or numerical > > work with no real-world measurement error, then a condition number of > > 1e6 may be fine. But you had better be using "double precision" (64- > > bit) floating point numbers (which are the default in Python, of > > course). Those have approximately 12 digits of precision, so you are > > in good shape. Single-precision floats only have 6 or 7 digits of > > precision, so you'd be in trouble there. > > > For any practical engineering or scientific work, I'd say that a > > condition number of 1e6 is very likely to be completely unacceptable. > > So how do you explain that the natural frequencies from FEM (with > condition number ~1e6) generally correlates really good with real > measurements (within approx. 5%), at least for the first 3-4 natural > frequencies? > > I would say that the problem lies with the highest natural frequencies, > they for sure cannot be verified - there's too little energy in them. > But the lowest frequencies (the most important ones) are good, I think - > even for high cond number. Did you mention earlier what "FEM" stands for? If so, I missed it. Is it finite-element modeling? Whatever the case, note that I said, "If you are just doing pure mathematical or numerical work with no real- world measurement error, then a condition number of 1e6 may be fine." I forgot much more than I know about finite-element modeling, but isn't it a purely numerical method of analysis? If that is the case, then my comment above is relevant. By the way, I didn't mean to patronize you with my earlier explanation of orthogonal transformations. They are fundamental to understanding the SVD, and I thought it might be interesting to anyone who is not familiar with the concept. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy (matrix solver) - python vs. matlab
On May 2, 1:29 pm, someone wrote: > > If your data starts off with only 1 or 2 digits of accuracy, as in your > > example, then the result is meaningless -- the accuracy will be 2-2 > > digits, or 0 -- *no* digits in the answer can be trusted to be accurate. > > I just solved a FEM eigenvalue problem where the condition number of the > mass and stiffness matrices was something like 1e6... Result looked good > to me... So I don't understand what you're saying about 10 = 1 or 2 > digits. I think my problem was accurate enough, though I don't know what > error with 1e6 in condition number, I should expect. How did you arrive > at 1 or 2 digits for cond(A)=10, if I may ask ? As Steven pointed out earlier, it all depends on the precision you are dealing with. If you are just doing pure mathematical or numerical work with no real-world measurement error, then a condition number of 1e6 may be fine. But you had better be using "double precision" (64- bit) floating point numbers (which are the default in Python, of course). Those have approximately 12 digits of precision, so you are in good shape. Single-precision floats only have 6 or 7 digits of precision, so you'd be in trouble there. For any practical engineering or scientific work, I'd say that a condition number of 1e6 is very likely to be completely unacceptable. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy (matrix solver) - python vs. matlab
On May 1, 11:03 pm, someone wrote: > On 05/02/2012 01:38 AM, Russ P. wrote: > > > > > > > > > > > On May 1, 4:05 pm, Paul Rubin wrote: > >> someone writes: > >>> Actually I know some... I just didn't think so much about, before > >>> writing the question this as I should, I know theres also something > >>> like singular value decomposition that I think can help solve > >>> otherwise illposed problems, > > >> You will probably get better advice if you are able to describe what > >> problem (ill-posed or otherwise) you are actually trying to solve. SVD > >> just separates out the orthogonal and scaling parts of the > >> transformation induced by a matrix. Whether that is of any use to you > >> is unclear since you don't say what you're trying to do. > > > I agree with the first sentence, but I take slight issue with the word > > "just" in the second. The "orthogonal" part of the transformation is > > non-distorting, but the "scaling" part essentially distorts the space. > > At least that's how I think about it. The larger the ratio between the > > largest and smallest singular value, the more distortion there is. SVD > > may or may not be the best choice for the final algorithm, but it is > > useful for visualizing the transformation you are applying. It can > > provide clues about the quality of the selection of independent > > variables, state variables, or inputs. > > Me would like to hear more! :-) > > It would really appreciate if anyone could maybe post a simple SVD > example and tell what the vectors from the SVD represents geometrically > / visually, because I don't understand it good enough and I'm sure it's > very important, when it comes to solving matrix systems... SVD is perhaps the ultimate matrix decomposition and the ultimate tool for linear analysis. Google it and take a look at the excellent Wikipedia page on it. I would be wasting my time if I tried to compete with that. To really appreciate the SVD, you need some background in linear algebra. In particular, you need to understand orthogonal transformations. Think about a standard 3D Cartesian coordinate frame. A rotation of the coordinate frame is an orthogonal transformation of coordinates. The original frame and the new frame are both orthogonal. A vector in one frame is converted to the other frame by multiplying by an orthogonal matrix. The main feature of an orthogonal matrix is that its transpose is its inverse (hence the inverse is trivial to compute). The SVD can be thought of as factoring any linear transformation into a rotation, then a scaling, followed by another rotation. The scaling is represented by the middle matrix of the transformation, which is a diagonal matrix of the same dimensions as the original matrix. The singular values can be read off of the diagonal. If any of them are zero, then the original matrix is singular. If the ratio of the largest to smallest singular value is large, then the original matrix is said to be poorly conditioned. Standard Cartesian coordinate frames are orthogonal. Imagine an x-y coordinate frame in which the axes are not orthogonal. Such a coordinate frame is possible, but they are rarely used. If the axes are parallel, the coordinate frame will be singular and will basically reduce to one-dimensional. If the x and y axes are nearly parallel, the coordinate frame could still be used in theory, but it will be poorly conditioned. You will need large numbers to represent points fairly close to the origin, and small deviations will translate into large changes in coordinate values. That can lead to problems due to numerical roundoff errors and other kinds of errors. --Russ P. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy (matrix solver) - python vs. matlab
On May 1, 4:05 pm, Paul Rubin wrote: > someone writes: > > Actually I know some... I just didn't think so much about, before > > writing the question this as I should, I know theres also something > > like singular value decomposition that I think can help solve > > otherwise illposed problems, > > You will probably get better advice if you are able to describe what > problem (ill-posed or otherwise) you are actually trying to solve. SVD > just separates out the orthogonal and scaling parts of the > transformation induced by a matrix. Whether that is of any use to you > is unclear since you don't say what you're trying to do. I agree with the first sentence, but I take slight issue with the word "just" in the second. The "orthogonal" part of the transformation is non-distorting, but the "scaling" part essentially distorts the space. At least that's how I think about it. The larger the ratio between the largest and smallest singular value, the more distortion there is. SVD may or may not be the best choice for the final algorithm, but it is useful for visualizing the transformation you are applying. It can provide clues about the quality of the selection of independent variables, state variables, or inputs. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy (matrix solver) - python vs. matlab
On May 1, 11:52 am, someone wrote: > On 04/30/2012 03:35 AM, Nasser M. Abbasi wrote: > > > On 04/29/2012 07:59 PM, someone wrote: > > I do not use python much myself, but a quick google showed that pyhton > > scipy has API for linalg, so use, which is from the documentation, the > > following code example > > > X = scipy.linalg.solve(A, B) > > > But you still need to check the cond(). If it is too large, not good. > > How large and all that, depends on the problem itself. But the rule of > > thumb, the lower the better. Less than 100 can be good in general, but I > > really can't give you a fixed number to use, as I am not an expert in > > this subjects, others who know more about it might have better > > recommendations. > > Ok, that's a number... > > Anyone wants to participate and do I hear something better than "less > than 100 can be good in general" ? > > If I don't hear anything better, the limit is now 100... > > What's the limit in matlab (on the condition number of the matrices), by > the way, before it comes up with a warning ??? The threshold of acceptability really depends on the problem you are trying to solve. I haven't solved linear equations for a long time, but off hand, I would say that a condition number over 10 is questionable. A high condition number suggests that the selection of independent variables for the linear function you are trying to fit is not quite right. For a poorly conditioned matrix, your modeling function will be very sensitive to measurement noise and other sources of error, if applicable. If the condition number is 100, then any input on one particular axis gets magnified 100 times more than other inputs. Unless your inputs are very precise, that is probably not what you want. Or something like that. -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy (matrix solver) - python vs. matlab
On Apr 29, 5:17 pm, someone wrote: > On 04/30/2012 12:39 AM, Kiuhnm wrote: > > >> So Matlab at least warns about "Matrix is close to singular or badly > >> scaled", which python (and I guess most other languages) does not... > > > A is not just close to singular: it's singular! > > Ok. When do you define it to be singular, btw? > > >> Which is the most accurate/best, even for such a bad matrix? Is it > >> possible to say something about that? Looks like python has a lot more > >> digits but maybe that's just a random result... I mean Element 1,1 = > >> 2.81e14 in Python, but something like 3e14 in Matlab and so forth - > >> there's a small difference in the results... > > > Both results are *wrong*: no inverse exists. > > What's the best solution of the two wrong ones? Best least-squares > solution or whatever? > > >> With python, I would also kindly ask about how to avoid this problem in > >> the future, I mean, this maybe means that I have to check the condition > >> number at all times before doing anything at all ? How to do that? > > > If cond(A) is high, you're trying to solve your problem the wrong way. > > So you're saying that in another language (python) I should check the > condition number, before solving anything? > > > You should try to avoid matrix inversion altogether if that's the case. > > For instance you shouldn't invert a matrix just to solve a linear system. > > What then? > > Cramer's rule? If you really want to know just about everything there is to know about a matrix, take a look at its Singular Value Decomposition (SVD). I've never used numpy, but I assume it can compute an SVD. -- http://mail.python.org/mailman/listinfo/python-list
Re: are int, float, long, double, side-effects of computer engineering?
On Mar 6, 7:25 pm, rusi wrote: > On Mar 6, 6:11 am, Xah Lee wrote: > > > some additional info i thought is relevant. > > > are int, float, long, double, side-effects of computer engineering? > > It is a bit naive for computer scientists to club integers and reals > as mathematicians do given that for real numbers, even equality is > undecidable! > Mostly when a system like mathematica talks of real numbers it means > computable real numbers which is a subset of mathematical real numbers > (and of course a superset of floats) > > Seehttp://en.wikipedia.org/wiki/Computable_number#Can_computable_numbers... I might add that Mathematica is designed mainly for symbolic computation, whereas IEEE floating point numbers are intended for numerical computation. Those are two very different endeavors. I played with Mathematica a bit several years ago, and I know it can do numerical computation too. I wonder if it resorts to IEEE floating point numbers when it does. -- http://mail.python.org/mailman/listinfo/python-list
Re: are int, float, long, double, side-effects of computer engineering?
On Mar 5, 10:34 pm, Xah Lee wrote: > On Mar 5, 9:26 pm, Tim Roberts wrote: > > > Xah Lee wrote: > > > >some additional info i thought is relevant. > > > >are int, float, long, double, side-effects of computer engineering? > > > Of course they are. Such concepts violate the purity of a computer > > language's abstraction of the underlying hardware. We accept that > > violation because of performance reasons. There are, as you point out, > > languages that do maintain the purity of the abstraction, but that purity > > is ALWAYS at the expense of performance. > > > I would also point out pre-emptively that there is nothing inherently wrong > > with asking us to accept an impure abstraction in exchange for performance. > > It is a performance choice that we choose to make. > > while what you said is true, but the problem is that 99.99% of > programers do NOT know this. They do not know Mathematica. They've > never seen a language with such feature. The concept is alien. This is > what i'd like to point out and spread awareness. I seriously doubt that. I think most decent programmers are well aware of the limitations of floating point math. If properly used, double- precision arithmetic is more than adequate for the vast majority of practical scientific and engineering problems. > also, argument about raw speed and fine control vs automatic > management, rots with time. Happened with auto memory management, > managed code, compilers, auto type conversion, auto extension of > array, auto type system, dynamic/scripting languages, etc. First of all, "dynamic/scripting languages" are still a long, long way from being "fast enough" for computationally intensive applications. Secondly, nothing is stopping anyone from writing a library to implement rational numbers or infinite-precision arithmetic in python (or just about any other language). They are just not needed for most applications. -- http://mail.python.org/mailman/listinfo/python-list
Re: killing a script
On Aug 28, 8:16 pm, Chris Rebert wrote:
> On Sun, Aug 28, 2011 at 8:08 PM, Russ P. wrote:
> > On Aug 28, 7:51 pm, Chris Angelico wrote:
> >> On Mon, Aug 29, 2011 at 12:41 PM, Russ P. wrote:
> >> > On Aug 28, 6:52 pm, MRAB wrote:
> >> >> You could look at the return value of os.system, which may tell you the
> >> >> exit status of the process.
>
> >> > Thanks for the suggestion. Yeah, I guess I could do that, but it seems
> >> > that there should be a simpler way to just kill the "whole enchilada."
> >> > Hitting Control-C over and over is a bit like whacking moles.
>
> >> I believe the idea of this suggestion is for the outer script to
> >> notice that the inner script terminated via Ctrl-C, and would then
> >> immediately choose to terminate itself - thus avoiding the
> >> whack-a-mole effect.
>
> >> ChrisA
>
> > Yes, but if I am not mistaken, that will require me to put a line or
> > two after each os.system call.
>
> Er, just write a wrapper for os.system(), e.g.:
>
> def mysystem(cmd):
> if os.system(cmd):
> sys.exit()
>
> Also, you may want to switch to using the `subprocess` module instead.
>
> Cheers,
> Chris
I ended up with this:
def systemx(cmd):
if system(cmd): exit("\nERROR: " + cmd + " failed\n")
This is good enough for my purposes in this case. Thanks for all the
suggestions.
--Russ P.
--
http://mail.python.org/mailman/listinfo/python-list
Re: killing a script
On Aug 28, 8:16 pm, Chris Rebert wrote: > On Sun, Aug 28, 2011 at 8:08 PM, Russ P. wrote: > > On Aug 28, 7:51 pm, Chris Angelico wrote: > >> On Mon, Aug 29, 2011 at 12:41 PM, Russ P. wrote: > >> > On Aug 28, 6:52 pm, MRAB wrote: > >> >> You could look at the return value of os.system, which may tell you the > >> >> exit status of the process. > > >> > Thanks for the suggestion. Yeah, I guess I could do that, but it seems > >> > that there should be a simpler way to just kill the "whole enchilada." > >> > Hitting Control-C over and over is a bit like whacking moles. > > >> I believe the idea of this suggestion is for the outer script to > >> notice that the inner script terminated via Ctrl-C, and would then > >> immediately choose to terminate itself - thus avoiding the > >> whack-a-mole effect. > > >> ChrisA > > > Yes, but if I am not mistaken, that will require me to put a line or > > two after each os.system call. > > Er, just write a wrapper for os.system(), e.g.: > > def mysystem(cmd): > if os.system(cmd): > sys.exit() > > Also, you may want to switch to using the `subprocess` module instead. > > Cheers, > Chris Sounds like a good idea. I'll give it a try. Thanks. --Russ P. -- http://mail.python.org/mailman/listinfo/python-list
Re: killing a script
On Aug 28, 7:51 pm, Chris Angelico wrote: > On Mon, Aug 29, 2011 at 12:41 PM, Russ P. wrote: > > On Aug 28, 6:52 pm, MRAB wrote: > >> You could look at the return value of os.system, which may tell you the > >> exit status of the process. > > > Thanks for the suggestion. Yeah, I guess I could do that, but it seems > > that there should be a simpler way to just kill the "whole enchilada." > > Hitting Control-C over and over is a bit like whacking moles. > > I believe the idea of this suggestion is for the outer script to > notice that the inner script terminated via Ctrl-C, and would then > immediately choose to terminate itself - thus avoiding the > whack-a-mole effect. > > ChrisA Yes, but if I am not mistaken, that will require me to put a line or two after each os.system call. That's almost like whack-a-mole at the code level rather than the Control-C level. OK, not a huge deal for one script, but I was hoping for something simpler. I was hoping I could put one line at the top of the script and be done with it. --Russ P. -- http://mail.python.org/mailman/listinfo/python-list
Re: killing a script
On Aug 28, 6:52 pm, MRAB wrote: > On 29/08/2011 02:15, Russ P. wrote:> I have a Python (2.6.x) script on Linux > that loops through many > > directories and does processing for each. That processing includes > > several "os.system" calls for each directory (some to other Python > > scripts, others to bash scripts). > > > Occasionally something goes wrong, and the top-level script just keeps > > running with a stack dump for each case. When I see that, I want to > > just kill the whole thing and fix the bug. However, when I hit Control- > > C, it apparently just just kills whichever script happens to be > > running at that instant, and the top level script just moves to the > > next line and keeps running. If I hit Control-C repeatedly, I > > eventually get "lucky" and kill the top-level script. Is there a > > simple way to ensure that the first Control-C will kill the whole darn > > thing, i.e, the top-level script? Thanks. > > You could look at the return value of os.system, which may tell you the > exit status of the process. Thanks for the suggestion. Yeah, I guess I could do that, but it seems that there should be a simpler way to just kill the "whole enchilada." Hitting Control-C over and over is a bit like whacking moles. --Russ P. -- http://mail.python.org/mailman/listinfo/python-list
killing a script
I have a Python (2.6.x) script on Linux that loops through many directories and does processing for each. That processing includes several "os.system" calls for each directory (some to other Python scripts, others to bash scripts). Occasionally something goes wrong, and the top-level script just keeps running with a stack dump for each case. When I see that, I want to just kill the whole thing and fix the bug. However, when I hit Control- C, it apparently just just kills whichever script happens to be running at that instant, and the top level script just moves to the next line and keeps running. If I hit Control-C repeatedly, I eventually get "lucky" and kill the top-level script. Is there a simple way to ensure that the first Control-C will kill the whole darn thing, i.e, the top-level script? Thanks. --Russ P. -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Hans Georg Schaathun writes: > ["Followup-To:" header set to comp.lang.python.] Ignored, since I don't follow that group. > On Wed, 18 May 2011 20:20:01 +0200, Raymond Wiker >wrote: > : I don't think anybody mentioned *binary* trees. The context was > : directory traversal, in which case you would have nodes with an > : arbitrary (almost) number of children. > > If we are being specific, then directory trees do have parent pointers. > My point was really that «standard tree representations» is not a > well-defined concept, and having parent pointers is as standard as > not having them. I suppose that I just assumed the standard mathematical definition of a tree as a directed, acyclic graph. It seems that in the context of computability that one would tend toward using the mathematical definitions. Certainly in a complex graph with labeled links or trees with backpointers, you would have an alternate data structure that you could follow. So, to be more precise, then: For directed, acyclic graphs without backpointers, you cannot write an iterative tree walker without simulating a stack. The larger point is that there are algorithms that are inherently recursive and for which there is no natural iterative algorithm. -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
"Pascal J. Bourguignon" writes: > t...@sevak.isi.edu (Thomas A. Russ) writes: > > > > This will only work if there is a backpointer to the parent. > > No, you don't need backpointers; some cases have been mentionned in the > other answer, but in general: > > (defun parent (tree node) >(if (member node (children tree)) > tree > (some (lambda (child) (parent child node)) (children tree > > Yes, the question wasn't about time complexity. :-p Um, this is a recursive function. Inside PARENT, there is another call to PARENT. -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
Hans Georg Schaathun writes: > ["Followup-To:" header set to comp.lang.python.] > On 17 May 2011 23:42:20 -0700, Thomas A. Russ >wrote: > : Tree walks are the canonical example of what can't be done in an > : iterative fashion without the addition of an explicitly managed stack > > Of course you can do it. It isn't nice, but it is possible. > I assume that you refer to depth first walks, as breadth first > is more easily described by iteration on a queue in the first place. > > Depth first can be achieved by looping over the nodes, with a > state keeping references to the current and the previous node > considered. Well, unless you have a tree with backpointers, you have to keep the entire parent chain of nodes visited. Otherwise, you won't be able to find the parent node when you need to backtrack. A standard tree representation has only directional links. Consider: A--+---B+---D || |+---E || |+---F | +---C If all you keep is the current and previous node, then the only thing you have reference do when doing the depth-first traverse is: 1. Current = A, Previous = null 2. Current = B. Previous = A 3. Current = D Previous = B 4. Current = E Previous = D 5. now what? You can't get from E or D back to B. > By comparing the previous node (pointer or ID) to the > current node's parent and children one will know wherefrom the > current node was entered, and can choose the next child in the > list as the next node, or the parent if all children have been > visited. A visit action may be added in any or all times the > node is visited. > > This node requires no stack. The only state space is constant, > regardless of the size of the tree, requiring just the two pointers > to previous and current. This will only work if there is a backpointer to the parent. So you have to add one extra pointer for each node back to its parent. This extra pointer will be the size of the graph, rather than (on average) log of the size of the graph stack frames. -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: English Idiom in Unix: Directory Recursively
"Pascal J. Bourguignon" writes: > Roland Hutchinson writes: > > Tail recursion can always be turned into an iteration when it is > > executed. > > All recursions can be turned into iterations, before execution. True, but only by simulating the call stack in the iterative code. To my mind that isn't really an iterative algorithm anymore if it ends up simulating the call stack. Tree walks are the canonical example of what can't be done in an iterative fashion without the addition of an explicitly managed stack -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
"BartC" writes: > "Thomas A. Russ" wrote in message > news:ymi1v7vgyp8@blackcat.isi.edu... > > torb...@diku.dk (Torben ZÆgidius Mogensen) writes: > > > >> Trigonometric functions do take arguments of particular units: radians > >> or (less often) degrees, with conversion needed if you use the "wrong" > >> unit. > > > > But radians are dimensionless. > > But they are still units, so that you can choose to use radians, degrees > or gradians for literals, so that functions that take angle arguments > can verify they are angles and not just numbers, and so that they can be > displayed appropriately. > > You can't do all that if angles are just numbers. But if you need to supply the units, that only really helps you when you actually input them. The problem comes when you have computed quantities, such as you might get when trying to do more involved computations. If you have a system where 10m/1m => 10 then it means you couldn't have a calculation like 100km*sin(10m/1m) and have it work, because the dimensionless 10 that you get from the calculation would be incorrect. You would have to know something else about the division in order to get the correct dimensionless "units". This is also an issue in sorting out torque and work, since they also have the same base units. You can't really tell if N*m is supposed to be a measure of work or of torque, which also means that you can't use that to distinguish the results of such a multiplication just by using dimensional analysis. Often it works, but sometimes you just run into ambiguity, so IMHO you have to live with that ambiguity in order to build a computational system that really works. -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
torb...@diku.dk (Torben Ægidius Mogensen) writes: > Trigonometric functions do take arguments of particular units: radians > or (less often) degrees, with conversion needed if you use the "wrong" > unit. But radians are dimensionless. The definition of a radian is length/length (or m/m) which simplifies to dimensionless. In fact, the units package in Lisp that I worked on actually handles this by making "radian" one of the dimensionless "units" precisely so that one can use degrees and radians with appropriate conversion. But they remain dimensionless. Interestingly, that also allows one to treat percent (%) as a dimensionless unit with a conversion factor of 1/100. -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
RG writes: > > More power to you. What are you doing here on cll then? This thread is massively cross-posted. -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
George Neuner writes: > On Tue, 28 Sep 2010 12:15:07 -0700, Keith Thompson > wrote: > >He didn't say it was. Internal calculations are done in SI units (in > >this case, m^3/sec); on output, the internal units can be converted to > >whatever is convenient. > > That's true. But it is a situation where the conversion to SI units > loses precision and therefore probably shouldn't be done. I suppose that one has to choose between two fundamental designs for any computational system of units. One can either store the results internally in a canonical form, which generally means an internal representation in SI units. Then all calculations are performed using the interal units representation and conversion happens only on input or output. Or one can store the values in their original input form, and perform conversions on the fly during calculations. For calculations one will still need to have some canonical representation for cases where the result value doesn't have a preferred unit provided. For internal calculations this will often be the case. Now whether one will necessarily have a loss of precision depends on whether the conversion factors are exact or approximations. As long as the factors are exact, one can have the internal representation be exact as well. One method would be to use something like the Commmon Lisp rational numbers or the Gnu mp library. And a representation where one preserves the "preferred" unit for display purposes based on the original data as entered is also nice. Roman Cunis' Common Lisp library does that, and with the use of rational numbers for storing values and conversion factors allows one to do nice things like make sure that 30mph * 3h = 90mi even when the internal representation is in SI units (m/s, s, m). -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
Malcolm McLean writes: > I'd like to design a language like this. If you add a quantity in > inches to a quantity in centimetres you get a quantity in (say) > metres. If you multiply them together you get an area, if you divide > them you get a dimeionless scalar. If you divide a quantity in metres > by a quantity in seconds you get a velocity, if you try to subtract > them you get an error. Done in 1992. See <http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/measures/0.html> citation at <http://portal.acm.org/citation.cfm?id=150168> and my extension to it as part of the Loom system: <http://www.isi.edu/isd/LOOM/documentation/loom4.0-release-notes.html#Units> -- Thomas A. Russ, USC/Information Sciences Institute -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 23, 7:46 pm, alex23 wrote: > "Russ P." wrote: > > However, I've switched from Python to > > Scala, so I really don't care. > > Really? Your endless whining in this thread would seem to indicate > otherwise. Yes, I guess I care some, but not much. I still use Python for some things, and I still have lots of "legacy" Python code that I still use. I just like to "whine" about zero-based indexing (but Scala is no different in that regard). It's my number one gripe. (My number zero gripe is semicolons after each statement -- but both Python and Scala got that one right, thank goodness.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 22, 12:47 am, Chris Rebert wrote: > On Sun, Aug 22, 2010 at 12:23 AM, Russ P. wrote: > > On Aug 21, 1:33 am, Steven D'Aprano > cybersource.com.au> wrote: > >> On Fri, 20 Aug 2010 11:01:42 -0700, Russ P. wrote: > >> > Most programmers probably never use vectors and matrices, so they don't > >> > care about the inconsistency with standard mathematical notation. > > >> Perhaps you should ask the numpy programmers what they think about that. > > > Why would I care in the least about something called "numpy"? > > Because it's a popular matrix math package for Python. Its users are > thus a subset of programmers which by definition don't fall into the > "most programmers" group you describe. Yes, I know what numpy is, and I'm sure it's great. I was just taking a light-hearted jab at the name. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 21, 1:33 am, Steven D'Aprano wrote: > On Fri, 20 Aug 2010 11:01:42 -0700, Russ P. wrote: > > Most programmers probably never use vectors and matrices, so they don't > > care about the inconsistency with standard mathematical notation. > > Perhaps you should ask the numpy programmers what they think about that. Why would I care in the least about something called "numpy"? > Vectors and matrices are just arrays, and the suggestion that most > programmers don't use arrays (or array-like objects like lists) is > ludicrous. But the vast majority of arrays are not vectors or matrices in the mathematical sense. And the vast majority of programmers who use arrays have no clue about vectors and matrices in the mathematical sense. Ask your typical programmer what an SVD is. > > And yes, I understand that zero-based indexing can be slightly more > > efficient. That's why I think it's appropriate for low-level languages > > such as C. However, I think one-based indexing is more appropriate for > > high-level languages. > > Only if your aim is to reduce the learning curve for newbies and non- > programmers, at the expense of making it easier for them to produce buggy > code. If you're suggesting that one-based indexing makes it easier to produce buggy code, I think you must be smoking something. > That's a defensible choice. I'm a great fan of Apple's Hypercard from the > late 80s and early 90s, and it used one-based indexing, as well as > English-like syntax like: Python is a high level language, and high-level languages have many features that make it easier for newbies as well as experienced programmers at the expense of extreme efficiency. But the array indexing in Python is a throwback to C: it is zero-based and uses square brackets. Say what you will, but both of those aspects just seem wrong and awkward to me. However, I've switched from Python to Scala, so I really don't care. You guys can have it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 20, 11:19 am, geremy condra wrote: > Not sure what you read, but for me (mostly number theory, numerical > analysis, and abstract algebra) zero-based indexing is quite common. My background is in aerospace control engineering. I am certainly not familiar with the literature in pure mathematics, but I assume that the math textbooks I used on college used standard mathematical notation. If one-based indexing is becoming more common in the literature, I'll bet that is only because it is so widely used in computer programming -- not because the writers decided independently that it is a better notation. But that's just a guess on my part. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 20, 1:23 am, Martin Braun wrote: > I find this thread extremely interesting, but what surprised me that > everyone seems to agree that mathematics is 1-based, but we Pythoneers > should stick to zero-based. I disagree. To make sure I'm not going > crazy, I took the top five books lying on my desk, which were the DSP > book by Oppenheim/Schafer, two books by Stephen M. Kay (Spectral > Estimation and Estimation Theory) and the Channel Coding book by Lin & > Costello. This is isn't pure mathematics (as in proving the Goldbach > conjecture), but nevertheless, this is serious mathematics and, > surprise, they most exclusively use zero-based notation. > You probably don't have those books in grabbing distance, so here's some > examples for zero-based stuff: That's interesting, but I think zero-based indexing is rare in the literature of mathematics, applied math, science and engineering. All the literature I've ever seen that uses vectors and matrices is one- based, and that includes text books and technical papers. It all boils down to personal preference, but I just find it strange that we would not try to make programming as consistent as possible with notational conventions in the literature. If I try to implement some algorithm I find in a technical book or paper, why should I have to mentally offset every index by one? That's very error prone, and I have more important things to think about. Then again, I don't do that very often, so maybe it's not a big deal. The zero-based indexing just seemed wrong to me when I first saw it. I'm used to it by now, but it still doesn't seem quite right to me. It's almost right -- but it's off by one. I still have a habit of taking the "1" element when I really want the "0" element. Most programmers probably never use vectors and matrices, so they don't care about the inconsistency with standard mathematical notation. And yes, I understand that zero-based indexing can be slightly more efficient. That's why I think it's appropriate for low-level languages such as C. However, I think one-based indexing is more appropriate for high-level languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 19, 12:13 pm, Steven D'Aprano While businesses are conservative in which languages they choose, > language designers are not conservative in the design features they come > up with. That there has been a gradual (although as yet incomplete) > convergence towards zero-based indexing in languages aimed at > programmers, and one-based indexing in languages aimed at non- > programmers, tells you everything you need to know. I beg to differ. I remember reading Bjarne Stroustrup's rationale for adopting all sorts of junk from C that he really didn't want, just to make C++ reasonably compatible with it. Had he not done that, C++ probably would have died on the vine. I'm sure the same was true of Java and Python too. In any case, I need to drop this discussion and move on. Mr. D'Aprano, I usually find your posts enlightening and amusing, but in this case just don't seem to be converging. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
Yes, apparently Basic uses one-based indexing too. As for Ada, apparently, the programmer needs to explicitly define the index range for every array. Weird. But I get the impression that one- based indexing is used much more than zero-based indexing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 19, 11:42 am, Steven D'Aprano wrote: > On Thu, 19 Aug 2010 11:03:53 -0700, Russ P. wrote: > > For those who insist that zero-based indexing is a good idea, why you > > suppose mathematical vector/matrix notation has never used that > > convention? I have studied and used linear algebra extensively, and I > > have yet to see a single case of vector or matrix notation with zero- > > based indexing in a textbook or a technical paper. Also, mathematical > > summation is traditionally shown as "1 to N", not "0 to N-1". > > In my experience, it's more likely to be "0 to N" than either of the > above, thus combining the worst of both notations. > > > Are > > mathematicians just too simple-minded and unsophisticated to understand > > the value of zero-based indexing? > > No, mathematicians are addicted to tradition. That is probably true. But computer languages are addicted to more than tradition. They're addicted to compatibility and familiarity. I don't know where zero-based indexing started, but I know that C used it very early, probably for some minuscule performance advantage. When C++ came along, it tried to be somewhat compatible with C, so it continued using zero-based indexing. Then Java was loosely modeled after C++, so the convention continued. Python was written in C, so zero-based indexing was "natural." So the whole thing is based on a decision by some guy who was writing a language for operating systems, not mathematics or application programming. > Unlike computer scientists, who create new languages with radically > different notation and syntax at the drop of a hat, mathematicians almost > never change existing notation. Sometimes they *add* new notation, but > more often they just re-use old notation in a new context. E.g. if you > see (5, 8), does that mean a coordinate pair, a two-tuple, an open > interval, or something else? > > Additionally, mathematical notation isn't chosen for its ability to > encourage or discourage errors. It seems often to be chosen arbitrarily, > or for convenience, but mostly out of tradition and convention. Why do we > use "x" for "unknown"? Why do we use i for an integer value, but not r > for a real or c for a complex value? > > Mathematicians are awfully lazy -- laziness is one of the cardinal > virtues of the mathematician, as it is of programmers -- but they value > brevity and conciseness over notation that improves readability and > robustness. That's why they (e.g.) they use implicit multiplication, a > plethora of "line noise" symbols that would boggle even Perl programmers, > and two-dimensional syntax where the meaning of tokens depends on where > they are written relative to some other token. (E.g. subscript, > superscript, and related forms.) > > There is one slightly mainstream language that uses mathematical > notation: APL. The result isn't pretty. As I wrote above, the use of zero-based indexing in C++, Java, and Python are all simply based on the fact that C used it. I wouldn't have guessed that APL is a "mainstream" language. As I wrote in recent posts, Fortran, Matlab, and Mathematica all used one- based indexing. Maybe Basic too, but I haven't checked. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
I just checked, and Mathematica uses one-based indexing. Apparently they want their notation to look mathematical. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 19, 11:04 am, Steven D'Aprano wrote: > On Tue, 17 Aug 2010 19:15:54 -0700, Russ P. wrote: > > The convention of starting with zero may have had some slight > > performance advantage in the early days of computing, but the huge > > potential for error that it introduced made it a poor choice in the long > > run, at least for high-level languages. > > People keep saying this, but it's actually the opposite. Signpost errors > and off-by-one errors are more common in languages that count from one. > > A simple example: Using zero-based indexing, suppose you want to indent > the string "spam" so it starts at column 4. How many spaces to you > prepend? > > 0123456789 > spam > > Answer: 4. Nice and easy and almost impossible to get wrong. To indent to > position n, prepend n spaces. > > Now consider one-based indexing, where the string starts at column 5: > > 1234567890 > spam > > Answer: 5-1 = 4. People are remarkably bad at remembering to subtract the > 1, hence the off-by-one errors. > > Zero-based counting doesn't entirely eliminate off-by-one errors, but the > combination of that plus half-open on the right intervals reduces them as > much as possible. > > The intuitive one-based closed interval notation used in many natural > languages is terrible for encouraging off-by-one errors. Quick: how many > days are there between Friday 20th September and Friday 27th September > inclusive? If you said seven, you fail. The error mode you refer to is much less common than the typical off- by-one error mode. In the far more common error mode, zero-based indexing is far more error prone. > One-based counting is the product of human intuition. Zero-based counting > is the product of human reason. I suggest you take that up with mathematicians, who have used one- based indexing all along. That's why it was used in Fortran and Matlab, among other more mathematical and numerically oriented and languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 19, 9:07 am, "J.B. Brown" wrote:
> 2010/8/9 MRAB :
>
> > Default User wrote:
>
> >> Not to prolong a good "food fight", but IIRC, many years ago in QBasic,
> >> one could choose
>
> >> OPTION BASE 0
>
> >> or
>
> >> OPTION BASE 1
>
> When I wrote my own C++ 2-D matrix class, I wrote a member function
> which did exactly this - allow you to specify the initial index value.
> Then users of my class (mainly my research lab coworkers) could
> specify whichever behavior they wanted.
>
> In terms of providing readable code and removing beginning programmer
> confusion, why not extend python lists by using something similar to
> (but not necessarily identical to) the C++ STL containers:
>
> C++
> int myX[ ] = { 1,2,3,4,5 };
> std::vector vectorX( myX, &myX[ sizeof( myX ) - 1 ] );
> std::cout << vectorX.begin() << std::endl;
> std::cout << vectorX.end() << std::endl;
>
> Python
> x = [ 1 , 2 , 3 , 4 , 5 ]
> print x.first()
> print x.last() ,
Many years ago I wrote a fairly comprehensive vector/matrix class in C+
+. (It was an exercise to learn the intricacies of C++, and I also
really needed it.) I used a system of offset pointers to realize
indexing that starts with 1.
Years later, after I had quit using it, I decided that I should have
just bit the bullet and let the indexing start with zero for
simplicity. I believe that zero-based indexing is a mistake, but
attempts to fix it require additional boilerplate that is prone to
error and inefficiency. Short of a major language overhaul, we are
essentially stuck with zero-based indexing.
But that doesn't mean we should pretend that it was the right choice.
For those who insist that zero-based indexing is a good idea, why you
suppose mathematical vector/matrix notation has never used that
convention? I have studied and used linear algebra extensively, and I
have yet to see a single case of vector or matrix notation with zero-
based indexing in a textbook or a technical paper. Also, mathematical
summation is traditionally shown as "1 to N", not "0 to N-1". Are
mathematicians just too simple-minded and unsophisticated to
understand the value of zero-based indexing? Or have you perhaps been
mislead?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 18, 7:58 pm, Steven D'Aprano wrote: > On Wed, 18 Aug 2010 14:47:08 -0700, Russ P. wrote: > > Is the top team in the league the number 1 team -- or the number 0 team? > > I have yet to hear anyone call the best team the number 0 team! > > Why is the top team the one with the lowest number? How could it be otherwise? What is the highest number? Here's a couple of things I'd like to see just once before I die: 1. The winner of the championship game chanting, "We're number zero! We're number zero! 2. The loser of the championship game chanting, "We're number one! We're number one! > > > Unfortunately, we're stuck with this goofy numbering system in many > > languages. Fortunately, the trend is away from explicit indexing and > > toward "for" loops when possible. > > Agreed on the second sentence there, but not on the first. There's > nothing "goofy" about indexing items from 0. Yes, it does lead to slight > more difficulty when discussing which item you want in *human* languages, > but not in *programming* languages. The nth item is always the nth item. > The only difference is whether n starts at 0 or 1, and frankly, if you > (generic you, not you personally) can't learn which to use, you have no > business pretending to be a programmer. Maybe "goofy" was too derogatory, but I think you are rationalizing a bad decision, at least for high-level languages. I don't think programming languages should always mimic human languages, but this is one case where there is no advantage to doing otherwise. Why do you think "off by one" errors are so common? Because the darn indexing convention is off by one! And I'd still like to know if the "1st" element of aList is aList[0] or aList[1]. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 18, 2:01 pm, AK wrote: > On 08/17/2010 10:15 PM, Russ P. wrote: > > > > > On Aug 7, 5:54 am, "D'Arcy J.M. Cain" wrote: > > >> Would said beginner also be surprised that a newborn baby is zero years > >> old or would it be more natural to call them a one year old? Zero > >> based counting is perfectly natural. > > > You're confusing continuous and discrete variables. Time is a > > continuous variable, but a list index is discrete. > > > Take a look at any numbered list, such as the top ten football teams > > or the top ten software companies. Have you ever seen such a list > > start with zero? If so, where? I sure haven't. > > > When I studied linear algebra way back, vector and matrix indices also > > always started with one, and I assume they still do. > > > The convention of starting with zero may have had some slight > > performance advantage in the early days of computing, but the huge > > potential for error that it introduced made it a poor choice in the > > long run, at least for high-level languages. > > Besides that, the way things are now, it's almost an Abbot & Costello > routine: > > - How many folders are there? > - 5 > - Ok, give me the fourth one. > - Here. > - No, that's the last one! > - That's what you said! > - No, I said, fourth one! > - That's what I did! > - How many are there in all? > - I already said, five! > - You gave me the last one!! > - Just like you said - fourth Yes, it's confusing. Which element of a list is the "first" element? Wait, "first" is sometimes abbreviated as "1st". So is the 1st element the 0 element or the 1 element? I honestly don't know. Is the top team in the league the number 1 team -- or the number 0 team? I have yet to hear anyone call the best team the number 0 team! Unfortunately, we're stuck with this goofy numbering system in many languages. Fortunately, the trend is away from explicit indexing and toward "for" loops when possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python "why" questions
On Aug 7, 5:54 am, "D'Arcy J.M. Cain" wrote: > Would said beginner also be surprised that a newborn baby is zero years > old or would it be more natural to call them a one year old? Zero > based counting is perfectly natural. You're confusing continuous and discrete variables. Time is a continuous variable, but a list index is discrete. Take a look at any numbered list, such as the top ten football teams or the top ten software companies. Have you ever seen such a list start with zero? If so, where? I sure haven't. When I studied linear algebra way back, vector and matrix indices also always started with one, and I assume they still do. The convention of starting with zero may have had some slight performance advantage in the early days of computing, but the huge potential for error that it introduced made it a poor choice in the long run, at least for high-level languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: (a==b) ? 'Yes' : 'No'
On Mar 30, 10:08 am, John Nagle wrote:
> Chris Rebert wrote:
> > On Tue, Mar 30, 2010 at 8:40 AM, gentlestone wrote:
> >> Hi, how can I write the popular C/JAVA syntax in Python?
>
> >> Java example:
> >> return (a==b) ? 'Yes' : 'No'
>
> >> My first idea is:
> >> return ('No','Yes')[bool(a==b)]
>
> >> Is there a more elegant/common python expression for this?
>
> > Yes, Python has ternary operator-like syntax:
> > return ('Yes' if a==b else 'No')
>
> > Note that this requires a recent version of Python.
>
> Who let the dogs in? That's awful syntax.
>
> John Nagle
Baloney. The Python ternary syntax is perfectly fine. The "if" could
have been put in front, as in Scala:
return if a == b "yes" else "no"
but either way is fine and perfectly readable as far as I am concerned.
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Usability, the Soul of Python"
According to Wikipedia, this is called the Whitesmith style:
for(i = 99; i > 0; ++i)
{
printf("%d slabs of spam in my mail!\n", i);
printf("%d slabs of spam,\n", i);
printf("Send one to abuse and Just Hit Delete,\n");
printf("%d slabs of spam in my mail!\n\n", i + 1);
}
I agree with the Mr. Hayward that it is preferable to the more common
K&R style, because the braces do not violate and visually clutter the
logical indentation structure. It looks more like Python. The deeper
the level of nesting, the more this style reduces visual clutter
compared to the conventional style.
A slightly better style, in my opinion, is the Banner style:
for(i = 99; i > 0; ++i) {
// a blank line here is optional
printf("%d slabs of spam in my mail!\n", i);
printf("%d slabs of spam,\n", i);
printf("Send one to abuse and Just Hit Delete,\n");
printf("%d slabs of spam in my mail!\n\n", i + 1);
}
On Mar 30, 4:40 am, "Alf P. Steinbach" wrote:
> * Jean-Michel Pichavant:
>
> > John Nagle wrote:
> >> Jonathan Hayward wrote:
> >>> I've posted "Usability, the Soul of Python: An Introduction to the
> >>> Python Programming Language Through the Eyes of Usability", at:
>
> >>> http://JonathansCorner.com/python/
>
> >> No, it's just a rather verbose introduction to Python, in dark brown
> >> type on a light brown background. One could write a good paper on this
> >> topic, but this isn't it.
>
> >> John Nagle
> > Why is it bad ?
>
> Consider
>
>
> From a usability standpoint, the braces go with the lines to print out the
> stanza rather than the for statement or the code after, so the following is
> best:
>
> for(i = 99; i > 0; ++i)
> {
> printf("%d slabs of spam in my mail!\n", i);
> printf("%d slabs of spam,\n", i);
> printf("Send one to abuse and Just Hit Delete,\n");
> printf("%d slabs of spam in my mail!\n\n", i + 1);
> }
>
>
> This is just unsubstantiated opinion, but worse, it makes a tacit assumption
> that there is "best" way to do indentation. However, most programmers fall
> into
> that trap, and I've done it myself. In fact, when I worked as a consultant
> (then
> in Andersen Consulting, now Accenture) I used the style above. Petter
> Hesselberg, author of "Industrial Strength Windows Programming" (heh, I'm
> mentioned) asked my why on Earth I did that, like, nobody does that? It was a
> habit I'd picked up in Pascal, from very naïve considerations of parse nesting
> levels, a kind of misguided idealism instead of more practical pragmatism, but
> since I realized that that was an incredibly weak argument I instead answered
> by
> pointing towards Charles Petzold's code in his "Programming Windows" books.
> And
> amazingly I was allowed to continue using this awkward and impractical style.
>
> I may or may not have been responsible for the similarly impractical
> compromise
> convention of using three spaces per indentation level. At least, in one big
> meeting the question about number of spaces was raised by the speaker, and I
> replied from the benches, just in jest, "three!". And that was it (perhaps).
>
> Cheers,
>
> - Alf (admitting to earlier mistakes)
--
http://mail.python.org/mailman/listinfo/python-list
Re: New syntax for blocks
On Nov 17, 7:28 am, Jonathan Saxton wrote: > On Thu, 12 Nov 2009 21:27:31 +0100, Bruno Desthuilliers wrote: > >> Congratulations, you just reinvented one of the most infamous source of > >> bugs in C, C++, Java, PHP, javascript and quite a few other languages. > >> Believe it or not, but not allowing this in Python was a very deliberate > >> design choice. > > > Oh, but those hundreds of thousands of man-hours lost to bugs caused by > > assignment-as-an-expression is nothing compared to the dozens of man- > > minutes saved by having one fewer line of code! > > > *wink* > > And if I ever find the genius who had the brilliant idea of using = to mean > assignment then I have a particularly nasty dungeon reserved just for him. > Also a foul-smelling leech-infested swamp for those language designers and > compiler writers who followed his example. (Come to think of it, > plagiarizing a bad idea is probably the worse evil.) There is absolutely nothing wrong with using = for assignment. The problem in C was allowing an assignment within a conditional expression. Now *that* was a bonehead idea! (Hingsight is 20/20, of course.) Python does not allow that, so there is no problem. Nor do most other languages allow it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Psyco on 64-bit machines
On Nov 12, 12:06 pm, "Russ P." wrote: > I have a Python program that runs too slow for some inputs. I would > like to speed it up without rewriting any code. Psyco seemed like > exactly what I need, until I saw that it only works on a 32-bit > architecture. I work in an environment of Sun Ultras that are all 64- > bit. However, the Psyco docs say this: > > "Psyco does not support the 64-bit x86 architecture, unless you have a > Python compiled in 32-bit compatibility mode." > > Would it make sense to compile Python in the 32-bit compatibility mode > so I can use Psyco? What would I lose in that mode, if anything? > Thanks. I just stumbled across "unladen swallow," a "faster implementation of Python." Is it ready for operational usage? How does it compare to Psyco? I poked around their website a bit, but I don't see answers to those questions. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Psyco on 64-bit machines
On Nov 14, 10:15 am, "Diez B. Roggisch" wrote: > Russ P. schrieb: > > > I have a Python program that runs too slow for some inputs. I would > > like to speed it up without rewriting any code. Psyco seemed like > > exactly what I need, until I saw that it only works on a 32-bit > > architecture. I work in an environment of Sun Ultras that are all 64- > > bit. However, the Psyco docs say this: > > > "Psyco does not support the 64-bit x86 architecture, unless you have a > > Python compiled in 32-bit compatibility mode." > > > Would it make sense to compile Python in the 32-bit compatibility mode > > so I can use Psyco? What would I lose in that mode, if anything? > > Thanks. > > Isn't the SUN Ultra using an ULTRA-Sparc core? If so, the point is moot. > > Diez No, it's Intel based. -- http://mail.python.org/mailman/listinfo/python-list
Re: Psyco on 64-bit machines
On Nov 12, 12:06 pm, "Russ P." wrote: > I have a Python program that runs too slow for some inputs. I would > like to speed it up without rewriting any code. Psyco seemed like > exactly what I need, until I saw that it only works on a 32-bit > architecture. I work in an environment of Sun Ultras that are all 64- > bit. However, the Psyco docs say this: > > "Psyco does not support the 64-bit x86 architecture, unless you have a > Python compiled in 32-bit compatibility mode." > > Would it make sense to compile Python in the 32-bit compatibility mode > so I can use Psyco? What would I lose in that mode, if anything? > Thanks. Has anyone tried this? -- http://mail.python.org/mailman/listinfo/python-list
Psyco on 64-bit machines
I have a Python program that runs too slow for some inputs. I would like to speed it up without rewriting any code. Psyco seemed like exactly what I need, until I saw that it only works on a 32-bit architecture. I work in an environment of Sun Ultras that are all 64- bit. However, the Psyco docs say this: "Psyco does not support the 64-bit x86 architecture, unless you have a Python compiled in 32-bit compatibility mode." Would it make sense to compile Python in the 32-bit compatibility mode so I can use Psyco? What would I lose in that mode, if anything? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against "while True:" loops
On Oct 10, 1:15 pm, kj wrote: > I'm coaching a group of biologists on basic Python scripting. One > of my charges mentioned that he had come across the advice never > to use loops beginning with "while True". Of course, that's one > way to start an infinite loop, but this seems hardly a sufficient > reason to avoid the construct altogether, as long as one includes > an exit that is always reached. (Actually, come to think of it, > there are many situations in which a bona fide infinite loops > (typically within a try: block) is the required construct, e.g. > when implementing an event loop.) > > I use "while True"-loops often, and intend to continue doing this > "while True", but I'm curious to know: how widespread is the > injunction against such loops? Has it reached the status of "best > practice"? Never, ever use "while True". It's an abomination. The correct form is "while 1". But seriously, folks ... "while condition" is nice when the desired break is at the beginning or end of the block, but otherwise it forces unnecessary contortions that can hamper readability. -- http://mail.python.org/mailman/listinfo/python-list
IDLE Config Problems
I am just getting started with Python and have installed v. 2.5.4 Idle version 1.2.4 I can't seem to get the idle to display text. It seems as if the install went fine. I start up the idle and the screen is blank. No text. It seems as if I can type on the screen but I just can't see the characters. I go to the config menu and it bombs and brings up the Visual Studio debugger. The computer that I am trying to install it on is a windows xp laptop serv pack 2. I have a workstation here that I am using also with the same os and the idle works fine. Any hints as to what might be interfering with the idle config. Thanks Russ Russell Davis PP, AICP, GISP GIS Administrator State of New Jersey Pinelands Commission Office of Land Use and Technology GIS Laboratory Po Box 7 New Lisbon, NJ 08064 Phone 609-894-7300 Fax 609-894-7330 russ.da...@njpines.state.nj.us -- http://mail.python.org/mailman/listinfo/python-list
Is Psyco good for Python 2.6.1?
I need to speed up some Python code, and I discovered Psyco. However, the Psyco web page has not been updated since December 2007. Before I go to the trouble of installing it, does anyone know if it is still good for Python 2.6.1? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Why am I getting "[10263 refs]"?
I am running 2.5.2 on Red Hat 5. I am getting many printouts of reference counts, such as [10263 refs] I do not recall ever seeing this until recently. Why am I getting this? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 4, 5:35 am, Luis Zarrabeitia wrote: > Quoting "Russ P." : > > > Imagine you own a company, and you decide to lease an office building. > > Would you expect the office doors to have locks on them? Oh, you > > would? Why? You mean you don't "trust" your co-workers? What are locks > > but enforced access restriction? > > This analogy is nonsense. There is no way you will execute code on my system > if > I don't authorize it, regardless of how "public" are the variables declared in > my code. No one will execute code on _your_ system either, without your > authorization. That puts you in a different position: you can easily _check_ > that everything is alright before executing, whereas in the office example, it > cannot be done. I don't follow your point, but I think you are reading too much into the analogy. Obviously, an office building cannot be "copied" in a few seconds as a software library can, so the analogy obviously cannot be taken too far. The locks on the doors are analogous to enforced access restrictions. When you lease the building, you are presumably given a complete set of keys, including master keys. The keys are analogous to the source code, which allows you to trivially disable the access restrictions. People like you are saying that keys are not enough. You don't want to be bothered with keys. You want the office doors to come with no locks on them at all, because you don't intend to lock them anyway, and someone could possibly get locked out someday. You are saying that locks are unnecessary because you trust your co-workers (aren't you lucky!), and you can just put "keep-out" signs on the doors (leading underscores). Well, that may be reasonable for a small group of developers working on a small, "cool" project. It is inappropriate, however, for a large, safety-critical project with dozens or hundreds of developers that are hired off the street in accordance with current labor laws. Now, if you concede that Python is just not intended for such projects, then fine, but please don't claim that access restrictions are useless for all applications and domains. That's just ridiculous. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 3, 7:49 pm, "Rhodri James" wrote: > On Wed, 04 Feb 2009 01:13:32 -, Russ P. wrote: > > On Feb 3, 4:05 pm, "Rhodri James" wrote: > >> I'm very much of the second opinion; it was Russ who did the sudden > >> volte > >> face and declared that it was trivial to circumvent. > > > Whoa! Hold on a minute here. Your failure to understand a simple idea > > does not constitute a "sudden volte" (whatever that is) on my part. > > My apologies. "Volte-face" should have had a hyphen in it. > > > Let me try to explain again what should be fairly obvious. > > I understood you just fine. It was how what you described was > consistent with your previous position that "private" was needed > for enforcement purposes, while the leading underscore convention > relied on team discipline and was therefore insufficient. Since > you've clarified that "private" enforces privacy through... er... > team discipline, I'm now just very confused as to what you think > it buys you. > > -- > Rhodri James *-* Wildebeeste Herder to the Masses You need team discipline either way. The question here is to what extent the language supports the discipline. If you are going to check for access violations anyway with third-party tools or code reviews, why not let the language do the job for you automatically (or at least take a first cut at it)? Imagine you own a company, and you decide to lease an office building. Would you expect the office doors to have locks on them? Oh, you would? Why? You mean you don't "trust" your co-workers? What are locks but enforced access restriction? What people like you are saying is that you don't need no stinkin' locks because your co-workers are all "consenting adults" whom you trust. Actually, you're saying even more than that. You're saying that office doors never need locks, because everyone should trust their co- workers. All you need is a "keep-out" sign on the door (leading underscores). And you are presenting as evidence for your position the fact that people occasionally get locked out of an office that they need to get into. I'm saying, fine, if you trust your co-workers, then keep the doors unlocked, but please don't insist that office doors come without locks. Yes, locks occasionally cause inconvenience, but they serve a very useful purpose if used properly. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 3, 4:14 pm, "Rhodri James" wrote: > On Tue, 03 Feb 2009 05:37:57 -, Russ P. wrote: > > On Feb 2, 7:48 pm, "Rhodri James" wrote: > >> On Tue, 03 Feb 2009 02:16:01 -, Russ P. > >> wrote: > >> > Here we go again. If you have access to the source code (as you nearly > >> > always do with Python code), then "breaking the language-enforced data > >> > hiding" is a trivial matter of deleting the word "private" (or > >> > equivalent). > > >> If it's that trivial to defeat something that its proponents appear to > >> want to be close to an iron-clad guarantee, what on earth is the point > >> of using "private" in the first place? > > > If a library developer releases the source code of a library, any user > > can trivially "defeat" the access restrictions. But if a team of > > developers is checking in code for a project, the leader(s) of the > > project can insist that the access restrictions be respected to > > simplify the management of interfaces. The larger the team, the more > > useful that can be. That's why Java, C++, Ada, Scala, and other > > languages have a "private" keyword. > > Indeed he can. He can even do that in Python; it just requires a little > self-discipline from the team, or a validation script on the code > repository if he really doesn't trust them. Not only can this be done > without forcing the rest of the world to play, it makes things a little > less daunting when those nice clean interfaces turn out to be > incomplete/too slow/not what you thought. This has already been refuted several times on this thread alone, so I will not bother doing it again. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 3, 4:05 pm, "Rhodri James" wrote: > On Tue, 03 Feb 2009 08:45:23 -, Steven D'Aprano > > wrote: > > I find this extreme position is rather incoherent. If I may paraphrase > > the argument as I see it: > > "Enforced data hiding is useless, because it is utterly trivial to bypass > > it, AND it's wicked, because it makes it unbelievably painful and > > difficult to bypass it when you need to." > > If it is trivial to bypass, surely it can't be that painful to bypass? > > I think you haven't noticed which of the parties is shifting their ground. > I'm very much of the second opinion; it was Russ who did the sudden volte > face and declared that it was trivial to circumvent. Whoa! Hold on a minute here. Your failure to understand a simple idea does not constitute a "sudden volte" (whatever that is) on my part. Let me try to explain again what should be fairly obvious. If the user of the library has the source code (and the right to modify it), disabling access restrictions is trivial. You simply delete the "private" keyword (or equivalent) wherever necessary. If you are working with a team, however, you cannot just do that unilaterally unless you have the authority to do so. In other words, you may be required to conform to the APIs established by the team. In that case, disabling access restrictions may not be impossible (or even difficult), but it is no longer trivial. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 3, 12:45 am, Steven D'Aprano wrote: > Another extreme position is that enforced data hiding is useless, that > there is *never* any need for it *at all*, and therefore Python doesn't > need it, there's no reason except stupid PHB's belief in cargo-cult > coding why Python couldn't be used for controlling nuclear reactors or > the Space Shuttle. There's been some claims remarkably close to that in > this or the previous thread. My recollection is that several people have said exactly that in no uncertain terms, if not in this thread then in the one a few days ago. > I trust that nobody really believes this > extreme position -- it's not that far off claiming that procedures and > functions are pointless and stupid because we have GOTO. If nobody believes it, several participants here could have fooled me. -- http://mail.python.org/mailman/listinfo/python-list
Re: what IDE is the best to write python?
On Feb 2, 9:09 pm, a...@pythoncraft.com (Aahz) wrote: > You favor bleeding eyes? If I am going to bleed anywhere, I'd actually prefer it be somewhere other than the eyes. Well, maybe not the gonads either. That's a tough call. In any case, I use xemacs, and I've always liked color highlighting. Not that it really helps much, but it "spices up" the code and stimulates the eyes and brain. When I see the same code without color highlighting, it just seems bland, like something is missing. It seems like just "text" rather than "code." -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 7:48 pm, "Rhodri James" wrote: > On Tue, 03 Feb 2009 02:16:01 -, Russ P. wrote: > > Here we go again. If you have access to the source code (as you nearly > > always do with Python code), then "breaking the language-enforced data > > hiding" is a trivial matter of deleting the word "private" (or > > equivalent). > > If it's that trivial to defeat something that its proponents appear to > want to be close to an iron-clad guarantee, what on earth is the point > of using "private" in the first place? > > -- > Rhodri James *-* Wildebeeste Herder to the Masses If a library developer releases the source code of a library, any user can trivially "defeat" the access restrictions. But if a team of developers is checking in code for a project, the leader(s) of the project can insist that the access restrictions be respected to simplify the management of interfaces. The larger the team, the more useful that can be. That's why Java, C++, Ada, Scala, and other languages have a "private" keyword. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 4:35 pm, "Rhodri James" wrote: > This really, really, *really* isn't a tangent. It's the heart of > the matter. You are advocating a change that doesn't fit with > Python's "consenting adults" approach to programming. It's trivial > to enforce hiding using static checking tools if you really feel the > need to not trust yourself; it's much harder (though by no means > impossible) to break language-enforced hiding when (not if) an > interface turns out to be inadequate. Here we go again. If you have access to the source code (as you nearly always do with Python code), then "breaking the language-enforced data hiding" is a trivial matter of deleting the word "private" (or equivalent). I know ... changing one word constitutes a "fork." Yeah, right. You can't be bothered to change one word, but the library developer should be required to litter his code with leading underscores everywhere, and large development teams should depend on labor intensive code reviews for checks that could be automated by the language. (And, please ... I am not suggesting that enforced access restrictions would render code reviews unnecessary, but it could certainly simplify them.) -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 2:46 pm, Tim Rowe wrote: > 2009/2/2 Russ P. : > > > Are we supposed > > to believe that the designers of C++, Java, Ada, and Scala are all > > idiots? > > No, we're supposed to believe that the designers of C++, Java, Ada, > and Scala are all designers of languages that are not Python. If all > languages had the same philosophy what would be the point of different > languages? Is it worth mentioning (again) that Python is not Java? > > -- > Tim Rowe I am not sure why people keep "mentioning" that "Python is not Java." As a slogan, it is rather misleading. Python is not C++, Ada, or Scala either. All of those languages have enforced access restriction. Why only mention Java? For the record, I have never used Java, nor do I have any desire to ever use it. That is why I am intrigued by the apparent obsession with it here. I suspect that many programmers are forced to use against their wishes. If that's the case, you have my sympathies, but let's not pretend that Java is the only popular OO language with enforced access restrictions. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 9:02 am, thmpsn@gmail.com wrote: > On Feb 2, 2:55 am, Stephen Hansen wrote: > > > > This is proven > > > by your statement above, whereby you are driving a user away, > > > simply because the language, in one small aspect, does not > > > give him what he wants, and the tenor of this thread has been > > > very much: "That's how it is - like it or lump it", and no amount > > > of careful explanation of why people want the feature has cut > > > any ice - > > > I'm missing the careful explanation. What I've heard is that the lack > > of enforced encapsulation is "a danger". What I've heard is that > > people want it because they've been told they should want it and > > believe that. Why? > > Who has said the latter? Are you just trying to spread FUD? > > > There have been no "careful explanations" to answer that, in my mind. > > And thus my response is: the practical possibility of needing access > > vastly outweights the theoretical situation that might go bad if > > encapsulation wasn't there. Why? Because in any real situation, IMHO, > > *forced* encapsulation is pointless. > > I think you've gotten too subjective on this matter. You might as well > say that we don't need no stinkin' OOP, we could all just be > programming with goto's. > > Sure, hey, let's do OOP in C, using structs, POD STRUCTS (), and > PLAIN FUNCTIONS () > > Heck, why do we even need OOP?? Long live procedural!! > > We don't even need no stinkin programming languages, we could just > program using 1's and 0's! > > What's with this luddite attitude, Python community? > > > > It has all the time been countered with statements > > > about how the proponents of private attributes "don't need it", > > > (as if they are plain dumb), > > > They don't need it. No one has shown a *real* reason why. The only > > reasons provided are "its a DANGER" that someone "MIGHT DO BAD". > > That's not a real reason. If its your project that someone is doing > > bad in, this is a situation which can be *clearly* specified in a > > projects policy and coding standards and can be *trivially* tested for > > with simple static analysis in nearly all cases. The problem is the > > person and not the code then. There's *countless* other ways that > > person can do bad if you're allowing them to commit blindly anything > > into your project. > > Aha! I see this attitude quite often among C/C++ people, regarding > buffer overflows and uninitialized pointer dereferences: someone will > say "C and C++ are unsafe languages because they allow you to overrun > buffers", then a C/C++ zealot will respond "Hire some good > programmers". > > SAME ATTITUDE. I couldn't agree more. As I said before, as an aeronautical engineer I don't know if enforced access restriction can be added to Python without compromising or unduly complicating the language. Maybe it can't. If that's the case, then people should make that argument. But just saying that enforced access restriction is useless in general is nonsense. Are we supposed to believe that the designers of C++, Java, Ada, and Scala are all idiots? Several participants here keep repeating that the leading-underscore convention is perfectly adequate. Aside from the aesthetic problem of littering code with leading underscores, let me try to explain the problem with leading underscores. Suppose a library developer (or a module developer on a large team) uses leading underscores. Now suppose that, for whatever reason (pressure from the users, perhaps), the library developer decides to change a "private" attribute to public. Now all occurrences of the identifier need to be changed. If an assignment to the previously "private" attribute is missed, no warning will be issued (because Python allows new attributes to be added anywhere, even completely outside the class definition itself). And if the library is widely used, the probability of such bugs occurring is very high. If a "private" keyword (or equivalent) were available, then the change would need to be made in only one location rather than at every occurrence off the identifier. That is much less error prone. Sure, you can argue (as I'm sure someone will) that the users of the library should be more careful. Yes they should, but why not let the language help with such low-level details. That's what high-level languages are for. Several people have argued that an advantage of the leading-underscore convention is that it tells you at every occurrence of the identifier that it is private. Of course, the leading-underscore convention could still be used even in combination with enforced access restriction. But the larger point is this: that is like saying that global parameters should be repeated as literal numbers at every occurrence so the user can see the value instantly. Sure, that saves you the trouble of looking up the value when you need to know it, but it also requres that any change must be carefully made at every location. No competent p
Re: Function Application is not Currying
On Jan 28, 1:32Â pm, Xah Lee wrote: > Function Application is not Currying > > Xah Lee, 2009-01-28 > > In Jon Harrop's book Ocaml for Scientist > athttp://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html > > It says: > > Â Â Currying > > Â Â A curried function is a function which returns a function as its > result. > > LOL. That is incorrect. What does that have to do with the price of bananas in Costa Rica? -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 27, 11:40 am, Luis Zarrabeitia wrote: > I think you still fail to see that what we are objecting is not that the > original writer can "optionally" use the enforced data hiding (which, as > someone pointed out before me, can be done with tools like pylint). The > objection is about the _user_ of the library. If you don't force it into the > _user_, how is it different from the current situation? And if you do force > it, how can you say that it is optional? As I have pointed out several times, the user cannot be forced to respect data hiding if he has access to the source code (and the right to modify it). If Python had a "private" keyword (or equivalent), for example, the user would only need to delete it wherever necessary to gain the desired access. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 26, 6:09 am, Steve Holden wrote: > Quite. Python is a language "for consenting adults". It has perceived > deficiencies for certain software engineering environments. Can we drop > the subject now? This horse was flogged to death long ago, and it's > pointless and cruel to keep on beating the remains. Judging from this thread, not everyone got the memo yet. At least three or four people on this thread alone have argued that enforced data hiding is of no value whatsoever for any application or domain. And more than one of them has argued that Python is perfectly appropriate for even the largest and most safety-critical projects. We are moving into an era of increasing dependence on computers and software for safety-critical, mission-critical, and financial systems. If people who do not understand the principles necessary for ultra-reliable software get in charge of developing these systems, we will have serious problems that could have been avoided. I suggested that maybe -- maybe! -- the versatility of Python could be enhanced with enforced data hiding. I was careful to say several times that I don't know if that can even be done in Python (with all its introspection and so forth). And it would always be optional, of course (as far as I know, no language forces anyone to declare anything private). Several people here seem to take that suggestion as an assault on Python and, by projection, an assault on their worldview. We all know that Python is a fantastic language for many purposes, but it is only a language, and failing to recognize and address its limitations serves no useful purpose. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 26, 1:07 am, Bruno Desthuilliers wrote: > No. I can change the *team's* code. Please *read*. "team's ownership", > ok ? Or do I have to spell it out loud ? TEAM'S OWNERSHIP. Uh. You get > the message, now ? Team ownership doesn't necessarily mean that you can just change code at will. In industry, teams usually have a leader that you need to check with before you can change an interface. A language with enforced access restriction merely provides language support for such coordination. That was my only point. > > Would you give all those developers your password to get into the > > system? No? Wait a minute ... you mean you wouldn't "trust" them with > > your password? But what about "openness"? Are you some sort of fascist > > or what? > > Goodwin point. You loose. Good bye again, Mr P. You missed the point once again. In asking if you are a "fascist," I was *parodying* your attitude that languages with enforced access restrictions are for "fascists" who don't trust their co-workers or employees. [I don't recall if you actually used that word or if it was someone else, but you did use "B&D", which carries the same general impression.] So I parodied your hyperbole, and you dismiss me for it. Without realizing it, you just dismissed yourself, sir. Thanks for saving me the trouble. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 25, 7:56 pm, Mark Wooding wrote: > "Russ P." writes: > > [snip stuff I don't disagree with] > > > That makes renaming and refactoring riskier in general in Python than > > in statically typed languages with enforced access restrictions. More > > care and attention to detail is needed to do it right in Python. > > In fact, I don't disagree with this statement either. It's just that I > think there's a legitimate tradeoff between the assurances you can get > from a language designed for static analysis and strictness, and the > freedom and dynamicness of languages like Python. It's just that I > rather like where Python is now on this continuum, and disagree that > shifting it is necessarily a good idea. > > -- [mdw] I would like to have the option to use Python either way, if possible -- and I honestly don't know if it is possible. The new type annotations are a step in that direction. They are optional, but if used they could make refactoring safer and facilitate static analysis. Enforced access restrictions, if they can be added to Python, would be optional too -- as they are in any language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 25, 5:31 pm, Steven D'Aprano wrote: > It seems to me that Russ' latest objection to _private names is not > specific to _private names. The same problem: > > "You will get no warning at all. You will just be inadvertently > creating a new "private" attribute -- and the assignment that you > really want will not get done." > > occurs with public names as well. That is true. Any name change could cause that sort of problem. But I brought it up specifically in reply to Mr. Wooding, who pointed out that it is hard to "accidentally" type a name with a leading underscore without realizing what you are doing. You may fully understand what you are doing when you type it, but you may not realize what has happened later when you forget to change it to be consistent with the new version of the library (or another module in an application). To change an attribute from private to public, the leading-underscore convention requires that every occurrence of the name be changed. That is more error prone than if the change only needs to be done in one place. And the fact that Python allows you to create new attributes on the fly also contributes to this problem, of course. That makes renaming and refactoring riskier in general in Python than in statically typed languages with enforced access restrictions. More care and attention to detail is needed to do it right in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 25, 10:04 am, Mark Wooding wrote: > > But what if I want an automatic check to verify that I am using it as > > the author intended? Is that unreasonable? > > You mean that you can't /tell/ whether you typed mumble._seekrit? > You're very strange. It's kind of hard to do by accident. But what if you type "mumble._seekrit" in several places, then the library implementer decides to give in to your nagging and makes it "public" by changing it to "mumble.seekrit". Now suppose you forget to make the corresponding change somewhere in your code, such as mumble._seekrit = zzz You will get no warning at all. You will just be inadvertently creating a new "private" attribute -- and the assignment that you really want will not get done. For that matter, the library implementer himself could make the same mistake and get no warning. When you think about it, you soon realize that the leading underscore convention violates the spirit if not the letter of one of the first principles of programming 101: if you have a constant parameter that appears in several places, assign the literal value in one place rather than repeating it everywhere. Then if you need to change the value, you only need to change it in one place. That reduces effort, but more importantly it reduces the potential for error. The same principle applies to "declaring" an attribute private. If that "declaration" is encoded in every occurrence of its identifier, then if you decide to change it to public, you need to change the identifier at each and every location. But if a "private" or "priv" keyword were available, you would only need to make the change in one location. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 25, 10:04 am, Mark Wooding wrote: > "Russ P." writes: > > Calling a one-word change a "fork" is quite a stretch, I'd say. > > I wouldn't. I've forked a project P if I've made a different version of > it which isn't going to be reflected upstream. Now I've got to maintain > my fork, merging in changes from upstream as they happen, and upgrading > all the things which use my new version; if I want to distribute my > program M to other people, they'll also need my forked version of > whatever. Now suppose that two programs A and B both require one-word > changes in P: there's a combinatorial explosion of little patches which > need to be managed. > > A fork is a fork, regardless of how big the change is. The problem with > a fork is the maintenance problem it entails. Not really. A "fork" is something that *diverges* from the original. That means the differences *grow* over time. In this case, the differences will not grow over time (unless you access more private attributes). As I pointed out before, you don't even need to keep track of the changes you made. You will be automatically reminded as soon as you get a new version of the library and try to use it (again, assuming that your tests provide sufficient coverage and the attribute is not changed to public). > >> > Has it occurred to you that some users might actually *want* access > >> > controls? Maybe some users want to actually use the library as the > >> > author intended it to be used. What a bizarre concept! > > >> Huh? > >> Then... use it as the author intended. I am _not_ forcing you to use the > >> obj._protected attributes! > > > But what if I want an automatic check to verify that I am using it as > > the author intended? Is that unreasonable? > > You mean that you can't /tell/ whether you typed mumble._seekrit? > You're very strange. It's kind of hard to do by accident. I'd have If I have a team of 200 programmers, I can't easily tell if one of them did that somewhere. Why do people like you have such a hard time understanding that I'm not talking here about smallish programs with one or a few developers? And even with only one programmer, he might access "mumble._seekrit" for a debugging test, then forget to take it out. > thought that you could do that with grep, err... > > git grep '\._' | sed 's/self\._//g' | grep '\._' > > ought to do as a rough start. > > If you can't trust your programmers to make it clear when they're doing > something dubious, I think you have bigger problems. Yes, I think I have bigger problems. But I like the challenge. I don't think I'd be happy working on small problems, but to each his own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 24, 9:54 pm, Luis Zarrabeitia wrote: > Quoting "Russ P." : > > > Once again, if you have the source code for the library (and the right > > to modify it), how does the "power" lie with the library implementer > > rather than you the user? > > > You say you don't want to "fork" the library. Let's stipulate for the > > sake of argument that a one-line change is indeed a "fork." > > It is. For starters, I'd lose the information of "this attribute was intended > to > be internal and I'm accessing it anyway". Not really. When you get a new version of the library and try to use it, you will quickly get a reminder about the change (assuming your tests provide sufficient converage, and also assuming that the attribute is not made public in the new version). So you don't really even need to keep track of the change. > > Think > > about what you are saying. You are saying that you should dictate how > > the producer of the library should implement it because you don't want > > to be bothered to "fork" it. > > No. I am not dictating _anything_. The beauty of it, you don't have to do > _anything_ for this to happen. You are trying to dictate that the library implementer not be allowed to use enforced access restriction. And, in the larger sense, you are trying to dictate that access restrictions not be enforced in Python. > Now, you may say that I'm trying to force you to relax and do nothing instead > of > complaining because the language I use doesn't put enough restrictions on me. And you are trying to put restrictions on anyone who might prefer to enforce access restrictions. If you don't allow them to do that, you are restricting them. > > If you don't like his design decisions, > > shouldn't the onus be on *you* to make the trivial change necessary to > > get access to what you want? > > Or contacting him about it and maybe send him a patch, sure, why not. But this > has nothing to do with enforced data hiding. Having obj._public_var is just as > badly designed as having "private public_var". Sure, go ahead and contact him. If he agrees that a private attribute should be public, then the problem is solved. But if he does not agree, he should not be forced to bend to your desire. > > Imagine a person who repairs computers. He is really annoyed that he > > constantly has to remove the cover to get at the guts of the computer. > > So he insists that computers cases should be made without covers. > > After all, manufacturers put covers on computers only because they > > don't trust us and think we're too "stupid" to safely handle an > > uncovered computer box. > > > That is logically equivalent to your position on enforced access > > restrictions in software. > > Do you realize that most computer cases are trivially easy to open? (Nevermind That was exactly my point. Deleting the word "private" (or whatever) is also trivially easy if you have access to the source code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 24, 5:09 pm, Luis Zarrabeitia wrote: > I didn't say "at all". Those were your words, not mine. > I said that it makes no sense that the power lies on _you_ instead of on _my > team_. And, when I said that, I recall we were talking about the python > language, not C. Once again, if you have the source code for the library (and the right to modify it), how does the "power" lie with the library implementer rather than you the user? You say you don't want to "fork" the library. Let's stipulate for the sake of argument that a one-line change is indeed a "fork." Think about what you are saying. You are saying that you should dictate how the producer of the library should implement it because you don't want to be bothered to "fork" it. If you don't like his design decisions, shouldn't the onus be on *you* to make the trivial change necessary to get access to what you want? Imagine a person who repairs computers. He is really annoyed that he constantly has to remove the cover to get at the guts of the computer. So he insists that computers cases should be made without covers. After all, manufacturers put covers on computers only because they don't trust us and think we're too "stupid" to safely handle an uncovered computer box. That is logically equivalent to your position on enforced access restrictions in software. > And, FYI, when programming in java, C++ or C#, I do use "private" and > "protected" variables, not becasue I want to forbid others from using it, but > because it is [rightly?] assumed that everything marked as public is safe to > use > - and I consider that a strong enough "external" reason to do it. You could just use leading underscores and note their meaning in the documentation. If that's such a great approach, why not do it? Yes, I know, it's not a widely used convention in those other languages. Fair enough. But you could still do it if it's such a good idea. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 24, 4:17 pm, Luis Zarrabeitia wrote: > Quoting "Russ P." : > > > On Jan 23, 6:36 pm, Luis Zarrabeitia wrote: > > > > > Makes *no* sense? There's *no* good reason *at all* for the original > > > > author to hide or protect internals? > > > > My bad, sorry. > > > It makes sense... if the original author is an egotist who believes he > > must > > > control how I use that library. > > > If the original author provides you with the source code and the right > > to modify it, he cannot possibly control how you use the library. You > > can trivially disable any access controls. But for some reason that's > > not enough for you. > > No, I'm not satisfied with forking python just to use sys._getframe. Calling a one-word change a "fork" is quite a stretch, I'd say. > > Has it occurred to you that some users might actually *want* access > > controls? Maybe some users want to actually use the library as the > > author intended it to be used. What a bizarre concept! > > Huh? > Then... use it as the author intended. I am _not_ forcing you to use the > obj._protected attributes! But what if I want an automatic check to verify that I am using it as the author intended? Is that unreasonable? Think of enforced access restriction as an automatic "assert" every time an attribute is accessed that it is not a private attribute. I may want this automatic verification in my own code just for peace of mind. More importantly, a project manager may want it to verify that no one on the development team is accessing private attributes. Sure, he could do that with code reviews, but code reviews are far more expensive (and less reliable in some ways) than a simple check enforced by the language itself. Without enforced access protection, depending on code reviews to detect the use of private attributes is a bit like depending on security guards to keep doors closed without putting locks on the doors. You don't need a lock on a door if you can afford to post a security guard there full time, but doesn't it make more sense to put a lock on the door and have a security guard check it only occasionally? -- http://mail.python.org/mailman/listinfo/python-list
Re: I'm a python addict !
On Jan 24, 4:03 pm, Robert Kern wrote: > On 2009-01-23 22:25, Aahz wrote: > > > In article, > > Linuxguy123 wrote: > >> I just started using python last week and I'm addicted. > > > Welcome! Just be aware that excessive Perl-bashing is considered > > somewhat tasteless on this newsgroup, but the occasional snide comment > > should be fine. ;-) > > Or bash-bashing for that matter. :-) > > but-zsh-really-is-better'ly yrs, > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco Come to think of it, when I use bash to run a series of python scripts, I could call it "bashing Python." -- http://mail.python.org/mailman/listinfo/python-list
Re: I'm a python addict !
On Jan 23, 6:58 pm, Linuxguy123 wrote: > I will never write another Perl or Bash script again. I still use bash for orchestrating the execution of a series of other scripts and/or programs (including python programs). I know you can do that in python, but I find bash simpler to use for that purpose. Then again, that may be just because I learned bash before I learned python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 23, 6:36 pm, Luis Zarrabeitia wrote: > > Makes *no* sense? There's *no* good reason *at all* for the original > > author to hide or protect internals? > > My bad, sorry. > It makes sense... if the original author is an egotist who believes he must > control how I use that library. If the original author provides you with the source code and the right to modify it, he cannot possibly control how you use the library. You can trivially disable any access controls. But for some reason that's not enough for you. Has it occurred to you that some users might actually *want* access controls? Maybe some users want to actually use the library as the author intended it to be used. What a bizarre concept! Oh, but only a paranoid fool could possibly want access controls, eh? Who's the egotist here? -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 23, 6:21 am, Steve Holden wrote: > I have to say that I thought the example was somewhat bogus. Any > development team that is even slightly concerned about the possibility > of logic bombs in the code will try to mitigate that possibility by the > use of code inspections. Of course they would, but that does not mean that access restrictions enforced by the language are not prudent. Consider a corporation that needs to maintain the physical security of their buildings. You can say that locks on the doors are not sufficient. Of course they're not. Security guards are needed too -- but that doesn't mean the locks are not needed too. The locks may be *insufficient* by themselves, but they are certainly not *unnecessary*. Ditto for the enforced encapsulation for large financial or safety-critical projects. > I'm not sure that there's much to be gained by this level of dogmatism > on either side. "Enforced encapsulation" has been "implemented" in both > C++ and Java, and both have proved to be circumventable. Just the same, > talk of "clueless pointy-haired bosses" is unlikely to be convincing. > Even the pointy-haired types never recognize themselves as such. Do you think the designers of C++, Java, Ada, and Scala would eliminate the enforced encapsulation if they had it to do over again? Of course not. The vast majority of the users of those languages consider it a major plus. And those who don't wish to use it aren't forced to use it except perhaps by their bosses or their customers. Again, I am not saying that Python necessarily needs enforced access restriction. I'm just saying it would be a plus if it can be added without compromising the language in some way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 23, 4:57 am, Bruno Desthuilliers wrote: > Russ P. a écrit : > > As I said before, if you have the source code you can always change > > private attributes to public in a pinch if the language enforces > > encapsulation. > > And then have to maintain a fork. No, thanks. For crying out loud, how many private attributes do you need to access? If it's a dozen, then you and your library developer are obviously not on the same page. If it's one or two, then it's hardly a "fork." Just take note of the one or two places where you needed to remove the access restriction and you're done. Heck, you don't even need to do that, because you will be warned automatically anyway when you get the new version of the library (unless those private attributes are changed to public). > > But if you are working on a team project, you can't > > change the code that another member of a team checks in. > > Why on earth couldn't I change the code of another member of my team if > that code needs changes ? The code is the whole team's ownership. OK, fine, you can change the code of another member of the team. Are you going to check with him first, or just do it? The point is that changing an interface requires agreement of the team members who use that interface, whether on the calling or the implementation side of it. If you change interfaces without getting agreement with the other team members, you probably won't be on the team for long. And without access restrictions, accessing _private is equivalent to changing the interface. > Now and FWIW, in this case (our own code), I just don't need to "mess > with internals" - I just just change what needs to be changed. > > > That is how > > enforced data hiding helps teams of developers manage interfaces. > > I totally fails to find any evidence of this assertion in the above > "demonstration". > > > The > > bigger the team and the bigger the project, the more it helps. > > Your opinion. > > > Mr. D'Aprano gave an excellent example of a large banking program. > > Without enforced encapsulation, anyone on the development team has > > access to the entire program and could potentially sneak in fraudulent > > code much more easily than if encapsulation were enforced by the > > language. > > My my my. If you don't trust your programmers, then indeed, don't use > Python. What can I say (and what do I care ?). But once again, relying > on the language's access restriction to manage *security* is, well, kind > of funny, you know ? Are you seriously saying that if you were managing the production of a major financial software package with hundreds of developers, you would just "trust" them all to have free access to the most sensitive and critical parts of the program? Now *that's*, well, kind of funny, you know? Would you give all those developers your password to get into the system? No? Wait a minute ... you mean you wouldn't "trust" them with your password? But what about "openness"? Are you some sort of fascist or what? -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 23, 4:30 am, Mark Wooding wrote: > Suppose that you write a Python library module and release it. I find > that it's /almost/ the right thing for some program of mine, but it > doesn't quite work properly unless I hack about like so... perfect! I'm > a happy bunny; you've gained a user (maybe that's a good thing, maybe it > isn't!). Now, I've hacked about in your module's internal stuff: how > has this affected you? Answer: not at all; you probably didn't feel a > thing. You release a new version with improved internal structure and > my program breaks: how has this affected you? Answer: still not at all. > How did it affect me? Quite a bit, but then again, I knew what I was > getting into. I gambled and lost; oh, well, that happens sometimes. Was this library module released in source form? If so, then why would you care that it has enforced access restrictions? You can just take them out, then do whatever you would have done had they not been there to start with. I don't see how that is any more work than figuring out what internals you need to access. Either way you need to read and understand the code. Wait ... it wasn't released in source form? Then how would you even know what internals you need to access? And why would you use something that goes against your philosophy of openness anyway? -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 22, 9:22 pm, "Russ P." wrote: > code. You can play around with the internals all you want in your own > little world, but as when you are working with a team, you need to > adhere to the interfaces they define (if any). The word "as" should not be there: ... but when you are working with a team, ... Sorry, but that was bothering me. I sure wish these posts could be edited after they are submitted. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 23, 1:54 am, Bruno Desthuilliers wrote: > Steven D'Aprano a écrit : > > > > > On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote: > > >> Steven D'Aprano writes: > > >>> On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote: > Steven D'Aprano a écrit : > > But if you have free access to attributes, then *everything* is > > interface. > Nope. > >>> How could anyone fail to be convinced by an argument that detailed and > >>> carefully reasoned? > >> Well, your claim /was/ just wrong. But if you want to play dumb: the > >> interface is what's documented as being the interface. > > > But you miss my point. > > > We're told Python doesn't have private attributes. > > Yes. > > > We're told that we're > > allowed to "mess with the internals", > > Given that we're willing and able to cope with possible consequences. > > > we're *encouraged* to do so > > Certainly not. > > > Python > > gives you the freedom to do so, and any suggestion that freedom might be > > reduced even a tiny bit is fought passionately. > > Won't comment on this. > > > When people ask how to > > implement private attributes, they're often told not to bother even using > > single-underscore names. > > "often" ? Not as far as I can tell. I think you're confusing this with > the advice to not use getters/setters for no good reason, given Python's > support for computed attributes - which is not exactly the same thing. > > > When it is suggested that Python should become > > stricter, with enforced data hiding, the objections come thick and fast: > > people vehemently say that they like Python just the way it is, that they > > want the ability to mess with the internals. > > Indeed. There's no shortage of B&D languages, and well, Python is OSS, > so if you want a B&D Python (now that's an oxymoron), please feel free > to implement it. But by all mean, leave my favorite language alone. Thanks. > > > You even argued that you disliked data structures implemented in C and > > preferred those written in Python because you have more ability to mess > > with the private attributes. > > In context, I had just mentioned that lists' > > internals were inaccessible from Python code. I neglected to give an > > example at the time, but a good example is the current length of the > > list. Consider the experience of Microsoft and Apple. > > Yes, two great examples of freedom champions. > > > No matter how often > > they tell people not to mess with the internals, people do it anyway, and > > always believe that their reason is a good reason. > > And who are *you* to pronounce any judgement about that ? > > > And Python culture encourages that behaviour (albeit the consequences are > > milder: no buffer overflows or core dumps). > > > Add to that the culture of Open Source that encourages reading the source > > code. > > Indeed. A *very* good thing FWIW. > > > You don't need to buy a book called "Undocumented Tips and Tricks > > for Python" to discover the internals. You just need to read the source > > code. > > Exactly. > > > And then you have at least two places in the standard library where > > _attributes are *explicitly* public: > > >http://bugs.python.org/issue3152 > > > Given this permissive culture, any responsible > > For your personal definition of "responsible". > > > library writer must assume > > that if he changes his so-called "private" attributes, he will break > > other people's code. > > You still don't get the point. If someone's code breaks because he > messed with my implementation code, then *he* is responsible. The > contract is very clear : "warranty void if unsealed". > > > > > In principle it could break just as much code as if > > he didn't even bother flagging them with a leading underscore, which is > > probably why many people don't even bother with _names. > > > In other words, if you make it easy for people to mess with your > > internals, if you have a culture that allows and even encourages them to > > mess with your internals, then you don't have internals. Everything is de > > facto public. > > Now that you've exposed your opinions, let's face reality (I mean, > *facts*): Python developpers very rarely mess with implementation, > usually do so for very good (and documented) reasons, and from what I've > seen usually tend to get in touch with the library author to explain > their case and find a better solution. > > Funny enough, it looks that the more you treat programmers as > responsible, normally intelligent adult person, the more they tend to > behave as such. And the other way around, too. > > Now, you comprehensively exposed your personnal distaste for Python's > and more generally OSS philosophy. So I can only - as I already did way > before in this thread - wonder *why* are you using Python ? > > I mean, is it because your bosses forces you to do so ? If yes, then, > I'm truly sorry for you - I sometimes have to work with languages I > really dislike so I can feel your pain (but
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 21, 4:04 am, Bruno Desthuilliers wrote: > Russ P. a écrit : > (snip) > > > Your mistake for being a moron. But it seems to happen regularly, > > doesn't it. How much more of my time are you going to waste, loser? > > Calling people names is certainly not the best way to defend your > opinions here. Adios, Mr. P. You are absolutely right, Mr. D. I regret that post, and I have since apologized to the person I was addressing. This stuff really isn't important enough to get that worked up about. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 22, 6:30 pm, Steven D'Aprano wrote:
> On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote:
> > Steven D'Aprano writes:
>
> >> On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
> >>> Steven D'Aprano a écrit :
> But if you have free access to attributes, then *everything* is
> interface.
>
> >>> Nope.
>
> >> How could anyone fail to be convinced by an argument that detailed and
> >> carefully reasoned?
>
> > Well, your claim /was/ just wrong. But if you want to play dumb: the
> > interface is what's documented as being the interface.
>
> But you miss my point.
>
> We're told Python doesn't have private attributes. We're told that we're
> allowed to "mess with the internals", we're *encouraged* to do so: Python
> gives you the freedom to do so, and any suggestion that freedom might be
> reduced even a tiny bit is fought passionately. When people ask how to
> implement private attributes, they're often told not to bother even using
> single-underscore names. When it is suggested that Python should become
> stricter, with enforced data hiding, the objections come thick and fast:
> people vehemently say that they like Python just the way it is, that they
> want the ability to mess with the internals.
>
> You even argued that you disliked data structures implemented in C and
> preferred those written in Python because you have more ability to mess
> with the private attributes. In context, I had just mentioned that lists'
> internals were inaccessible from Python code. I neglected to give an
> example at the time, but a good example is the current length of the
> list. Consider the experience of Microsoft and Apple. No matter how often
> they tell people not to mess with the internals, people do it anyway, and
> always believe that their reason is a good reason.
>
> And Python culture encourages that behaviour (albeit the consequences are
> milder: no buffer overflows or core dumps).
>
> Add to that the culture of Open Source that encourages reading the source
> code. You don't need to buy a book called "Undocumented Tips and Tricks
> for Python" to discover the internals. You just need to read the source
> code.
>
> And then you have at least two places in the standard library where
> _attributes are *explicitly* public:
>
> http://bugs.python.org/issue3152
>
> Given this permissive culture, any responsible library writer must assume
> that if he changes his so-called "private" attributes, he will break
> other people's code. In principle it could break just as much code as if
> he didn't even bother flagging them with a leading underscore, which is
> probably why many people don't even bother with _names.
>
> In other words, if you make it easy for people to mess with your
> internals, if you have a culture that allows and even encourages them to
> mess with your internals, then you don't have internals. Everything is de
> facto public.
>
> > You can tell that your claim is simply wrong by pushing it the other
> > way. If everything you have free access to is interface then all
> > behaviour observable by messing with the things you have access to is
> > fair game: you can rely on cmp returning one of {-1, 0, 1} on integer
> > arguments, for example.
>
> > But no: the Library Reference says only that it returns a negative, zero
> > or positive integer, and /that/ defines the interface. Everything else
> > is idiosyncrasy of the implementation, allowed to change at whim.
>
> And yet people still assume that cmp returns -1, 0 or 1. Even Guido
> himself makes that mistake occasionally. Quoting from PEP 285:
>
> "...you might be tempted to believe that cmp() also returned a
> truth value, whereas in reality it can return three different values
> (-1, 0, 1)."
>
> http://www.python.org/dev/peps/pep-0285/
>
> No, cmp() can return an infinite number of values. It just never does, at
> least not yet, but it might. But when Guido himself says that cmp() can
> return three values, can you blame people for acting as if cmp() can
> return three values?
>
> Here's a thought experiment for you. You've suggested that the values
> returned by cmp() are allowed to change "at whim". Okay, let's do it:
> make a patch that changes cmp() to return -17, 0 or 53, and promise to
> support it for at least three years. Try to get it accepted on python-
> dev. What do you expect they will say?
>
> My money is on them saying "No, this will pointlessly break code for no
> good reason. Rejected."
>
> --
> Steven
Needless to say, I agree with your post.
My understanding is that the vast majority of Python software is
provided as open source. Hence, I am a bit confused by all the talk
about the need for freedom and openness in Python. If data hiding were
enforced, and you need access to something marked as private, you can
just change it to public in the source code. What's the problem?
Note: that change would be much easier to make if a "private" (or
perhaps "priv") keyword were used instead of the lea
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 21, 9:34 am, Luis Zarrabeitia wrote: > But you keep failing to explay why do you need it to be _part of the standard_ > library (or whatever). Technically, it doesn't need to be. But if someone proposes using particular language for a major safety-critical project, the critical features realistically need to be part of the standard language or at the very least in the standard library. The requirements are different for government-regulated code than they are for non-critical commercial code, as well they should be. Imagine trying to explain to the FAA that you are going to use a language that is inappropriate by itself for a safety-critical system but will be appropriate with the addition of third-party software. That just won't fly. Then again, the FAA might not approve Python for flight-critical or safety-critical code even if it gets enforced data hiding, so perhaps the point is moot. > If you need it in your project, _use_ it. If you don't, then don't use it. If > _you_ need that thing you call security, just use it already and quit > complaining that we don't use it. Is there a policy in your project that you > can't use any external? I don't recall complaining that anyone doesn't use something. In fact, in the unlikely event that enforced data hiding is ever added to Python, nobody would be forced to use it (except perhaps by your boss or your customer, but that's another matter). -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 20, 11:16 pm, alex23 wrote: > I think this is the main issue we disagree on. I'm happier for Python > to remain lightweight where such features can be easily added on > demand through external libraries. I see no reason why a library > couldn't be as "well-engineered" a solution as an extension to the > interpreter, its use being a mandated (and enforced) requirement > within personal projects. The language just has to enable such > solutions, which I feel Python does well. That could work. As long as it's well-engineered (not a hack), well- supported (part of the standard library), and does the job, that's probably all that matters. -- http://mail.python.org/mailman/listinfo/python-list
Re: Does Python really follow its philosophy of "Readability counts"?
On Jan 20, 11:03 pm, James Mills wrote: > Then -don't- use python. Use some other boring > language. (!...@#$!@#) > > --JamesMills You're emailing me again. Please don't do that. It's bad enough to get death threats in a newsgroup -- I don't need them in my inbox too. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
