Re: recursive function: use a global or pass a parameter?
Tim wrote: > I have this type of situation and wonder if I should use a global variable > outside the recursive function instead of passing the updated parameter > through. To a first approximation, the answer to: "I have a X, should I use a global variable or a parameter?" is *always* "use a parameter", no matter what X is. To a second and third approximation, the answer is still "use a parameter". Good reasons for using global variables are few and far between. Just about the only good reason for using global variables that I can think of is if you have one or more settings/preference that get set once at the start of the program and then apply to the entire program. Actually, there is one other reason... if your program is a simple script written in imperative style: name = "steve" print "Hello", name do_this() do_that() do_something_else() print "Good bye", name sort of thing. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Gregory Ewing wrote: > Marko Rauhamaa wrote: >> Gregory Ewing : >> >>>If those are 24-bit RGB pixels, you could encode >>>3 characters in each pixel. >> >> Not since Python3. Characters are Unicode now so you'll need to dedicate >> a pixel for each character. > > Depends on which characters you want. With the > Flexible Chromatic Representation, it could be > anything from 1 to 3. Subpixel rendering is 5% slower than full pixel rendering, so it is provably mathematically impossible to print Unicode characters. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Gregory Ewing wrote: > We're really quite spoiled in Python-land. It's easy > to forget just how spoiled we are until you go back > and try to do something in one of the more primitive > languages... Every time I think I would like to learn a new language, I quite quickly run into some obvious feature that Python has but the newer language lacks, and I think "bugger this for a game of soldiers" and abandon it. E.g. Ruby and the lack of keyword arguments. Oh, I see Ruby 2.0 added them to the language! Perhaps it's time for me to give Ruby a go again? Ah, wait, I forgot Ruby's brilliant "feature" that whitespace *between* expressions is significant: [steve@ando ~]$ cat ~/coding/ruby/ws-example.rb #!/usr/bin/ruby def a(x=4) x+2 end b = 1 print "a + b => ", (a + b), "\n" print "a+b => ", (a+b), "\n" print "a+ b => ", (a+ b), "\n" print "a +b => ", (a +b), "\n" [steve@ando ~]$ ruby ~/coding/ruby/ws-example.rb a + b => 7 a+b => 7 a+ b => 7 a +b => 3 A shiny new penny for any non-Ruby coder who can explain that! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Steven D'Aprano writes: > Ah, wait, I forgot Ruby's brilliant "feature" that whitespace > *between* expressions is significant: > > [steve@ando ~]$ cat ~/coding/ruby/ws-example.rb > #!/usr/bin/ruby > > def a(x=4) > x+2 > end > > b = 1 > print "a + b => ", (a + b), "\n" > print "a+b => ", (a+b), "\n" > print "a+ b => ", (a+ b), "\n" > print "a +b => ", (a +b), "\n" > > [steve@ando ~]$ ruby ~/coding/ruby/ws-example.rb > a + b => 7 > a+b => 7 > a+ b => 7 > a +b => 3 > > > A shiny new penny for any non-Ruby coder who can explain that! I've only seen small amounts of Ruby code on the net. The only way I can make some sense of that is if it gets analyzed as follows, using parentheses for calls: a + b => 7 # a() + b => a(4) + b => 4 + 2 + 1 a+b => 7 # a() + b a+ b => 7 # a() + b a +b => 3 # a(+b) => a(b) => a(1) = 1 + 2 I'm not quite fond of such surprise in programming language syntax. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Jussi Piitulainen : > a+ b => 7 # a() + b > a +b => 3 # a(+b) => a(b) => a(1) = 1 + 2 > > I'm not quite fond of such surprise in programming language syntax. Yes, whoever came up with the idea of whitespace having syntactic significance! Marko -- https://mail.python.org/mailman/listinfo/python-list
EuroPython 2015: Landing in Bilbao
After a creative and inspiring Friday afternoon, we are pleased to announce our EuroPython 2015 landing page: http://ep2015.europython.eu/ This will be the URL for EuroPython 2015 - definitely worth a bookmark, we think :-) Enjoy, -— EuroPython Society (EPS) http://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Marko Rauhamaa writes: > Jussi Piitulainen: > > > a+ b => 7 # a() + b > > a +b => 3 # a(+b) => a(b) => a(1) = 1 + 2 > > > > I'm not quite fond of such surprise in programming language > > syntax. > > Yes, whoever came up with the idea of whitespace having syntactic > significance! How far do you want to go? Is "a b + c" the same as "a(b) + c" or the same as "a(b + c)"? There's meant to be two spaces between "a" and "b" but I lost one of them, twice, to my M-q reflex when writing the above paragraph. They may or may not be there as I send this. And I don't really want to know which it is. I prefer parentheses. They are not nearly as fragile. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, Jan 17, 2015 at 5:59 AM, Jussi Piitulainen wrote: > How far do you want to go? Is "a b + c" the same as "a(b) + c" or the > same as "a(b + c)"? I think there is only one practical interpretation, the one that all shells I'm familiar with have adopted: a(b, +, c) > And I don't really want to know which it is. I prefer parentheses. > They are not nearly as fragile. Agreed. Without parens, splitting the command line arguments on white space is the only non-fragile way to do things. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Jussi Piitulainen : > Marko Rauhamaa writes: >> Yes, whoever came up with the idea of whitespace having syntactic >> significance! > > How far do you want to go? [...] > > I prefer parentheses. They are not nearly as fragile. *cough* braces *cough* Seriously, though, I hate the optional semicolon rules of JavaScript and Go. I dread the day when GvR gets it in his head to allow this syntax in Python: average_drop_rate = cumulative_drop_count / observation_period (although, it could be defined Pythonesquely thus: "a spurious indentation means line continuation" — no more backslashes). Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Comparisons and sorting of a numeric class....
Andrew, sorry for the delay in responding. Your response has been extremely long, so for the interest of brevity I've tried to trim things down to the most pertinent points. Andrew Robinson wrote: [...] > So -- From my perspective, Guido making Python go from an open ended and > permissive use of anything goes as a return value that can handle > metastable states That absolutely has not changed. You seem to be mixing the concept of *subclassing* with the concept of being able to handle multi-state (metastable) logic. You can certainly write multi-state logic in Python. > -- into to a historical version of 'logic' being > having *only* two values in a very puritanical sense, is rather -- well > -- disappointing. It makes me wonder -- what hit the fan?! Is it > lemmings syndrome ? a fight ? no idea and is there any hope of > recovery or a work around ? Do you have much programming experience outside of the niche of modelling electronic hardware? I can tell you that it is standard for general purpose programming languages to be restricted to two-state (Boolean) comparisons. The basic decision construct is "if...else", which is based on two states. The only exception that I know of is the very early, and long deprecated, Fortran "Arithmetic IF" statement: IF (e) label1, label2, label3 which did a three-way jump depending on whether e was less than zero, equal to zero, or greater than zero. Some assemblers also included three-way jumps. All forms of N-valued logic can be reduced to Boolean logic with appropriate comparisons. Instead of trying to come up with syntax for a three-way branch: if flag: print True else: print False otherwise: print Indeterminate and four-way branches, a five-way branches, ... ad infinitum, it is easier to leave it up to the programmer to build N-way logic on top of 2-way True/False comparisons: # equality here returns True or False if flag == True: print True else: if flag == False: print False else: print Indeterminate Some programming languages add syntax to make this more friendly: if flag == True: print True elif flag == False: print False else: print Indeterminate or even: case flag of: True: ... False: ... Indeterminate: ... Maybe: ... Uncertain: ... Could_Be: ... (for languages with a case or switch statement). Not only can all N-way logics be mathematically generated from Boolean algebra, but I'll go further and say that *almost certainly* the hardware simulation languages you are used to with 3-way or 4-way logic use 2-way Boolean logic under the hood. The point of this is that you need not think of Guido "taking away" anything. It is normal for programming languages to use Boolean comparisons. But in fact Python is *less* restrictive than many other languages. In Pascal, for instance, comparisons like <= or > etc. can only return true or false, while Python allows them to return anything. > eg: To me -- (as an engineer) undefined *IS* equivalent in useage to an > acutal logic value, just as infinity is a floating point value that is > returned as a 'float'. You COULD/CAN separate the two values from each > other -- but always with penalties. They generally share an OOP 'is' > relationship with respect to how and when they are used. (inf) 'IS' a > float value and -- uncertain -- 'IS' a logic value. That's fine, we have no dispute with the need for multi-state logics. But *which* multi-state logic? There are *at least* three useful ternary logics: Kleene logic, Łukasiewicz logic, Bochvar logic. And then there is Belnap's four-valued relevance logic (True, False, Both True and False, Neither True nor False), and an infinite number of other possible logics. Which should the programming language support? In a sense, any Turing Complete programming language supports *all of them*. All you need to do is program the details yourself. But in the sense of which multi-state logic should the language itself include, I think that the answer is ... none of them. Most programming languages have no need to include this complexity, just as most languages don't include tensors as a language primitive. I guess this is just a long-winded way of me saying that HDLs are effectively a "Domain Specific Language" for hardware, and can *and should* contain specialist semantics needed by hardware designers, e.g. 4-way logic. But Python is a general purpose language, and while you *can* program your own domain specific features, you have to do so within the constraints of the needs of a general-purpose language. In Python's case, those constraints are actually remarkably loose (not as loose as languages like Lisp or Forth, where you can literally redesign the interpreter on the fly!) but they do exist. [...] > So -- let's look at the examples you gave: > >> - don't use True and False at all, create your own multi-valued >>truth values ReallyTrue, MaybeTrue, SittingOnTheFence, ProbablyFalse, >>CertainlyFalse (or whatev
Re: lambdak: multi-line lambda implementation in native Python
Marko Rauhamaa wrote: > Jussi Piitulainen : > >> a+ b => 7 # a() + b >> a +b => 3 # a(+b) => a(b) => a(1) = 1 + 2 >> >> I'm not quite fond of such surprise in programming language syntax. > > Yes, whoever came up with the idea of whitespace having syntactic > significance! Yes, we should go back to the rules of ancient FORTRAN, where: DO100X=1.10,2 and DO 100 X = 1. 10, 2 mean exactly the same thing. Not. Whitespace is significant in nearly all programming languages, and so it should be. Whitespace separates tokens, and lines, and is a natural way of writing (at least for people using Western languages). *Indentation* is significant to Python, while most languages enable tedious and never-ending style wars over the correct placement of braces vis a vis indentation, because their language is too simple-minded to infer block structure from indentation. Python does derive block structure from indentation, as god intended (otherwise he wouldn't have put tab keys on typewriters) and so Python doesn't suffer from the interminable arguments about formatting that most other languages do. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Jussi Piitulainen wrote: > I've only seen small amounts of Ruby code on the net. The only way I > can make some sense of that is if it gets analyzed as follows, using > parentheses for calls: > > a + b => 7 # a() + b => a(4) + b => 4 + 2 + 1 > a+b => 7 # a() + b > a+ b => 7 # a() + b > a +b => 3 # a(+b) => a(b) => a(1) = 1 + 2 > > I'm not quite fond of such surprise in programming language syntax. Full marks! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Marko Rauhamaa writes: > Seriously, though, I hate the optional semicolon rules of JavaScript > and Go. I dread the day when GvR gets it in his head to allow this > syntax in Python: > >average_drop_rate = cumulative_drop_count / >observation_period > > (although, it could be defined Pythonesquely thus: "a spurious > indentation means line continuation" — no more backslashes). I do that: average_drop_rate = ( cumulative_drop_count / observation_period ) -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Skip Montanaro writes: > On Sat, Jan 17, 2015 at 5:59 AM, Jussi Piitulainen wrote: > > How far do you want to go? Is "a b + c" the same as "a(b) + c" or > > the same as "a(b + c)"? > > I think there is only one practical interpretation, the one that all > shells I'm familiar with have adopted: > > a(b, +, c) Sorry, what? Oh, shells, and "a" called with three parameters. Ok. But I think the "+" here should be the usual arithmetical operators. It was supposed to be Ruby syntax and the question was about the significance of different amounts of white space. Hm. What about "b + c"? Or "3 +1", is that calling 3 with 1? No, I don't really want to know. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, Jan 17, 2015 at 9:49 PM, Jussi Piitulainen wrote: > I've only seen small amounts of Ruby code on the net. The only way I > can make some sense of that is if it gets analyzed as follows, using > parentheses for calls: > > a + b => 7 # a() + b => a(4) + b => 4 + 2 + 1 > a+b => 7 # a() + b > a+ b => 7 # a() + b > a +b => 3 # a(+b) => a(b) => a(1) = 1 + 2 > > I'm not quite fond of such surprise in programming language syntax. Every once in a while, someone looks at Py2's print statement and Py3's print function and says, "why not allow function calls without parentheses". This right here is why not. Wow. That is one nasty surprise. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Il 17/01/2015 12.07, Marko Rauhamaa ha scritto: > Jussi Piitulainen : > >> a+ b => 7 # a() + b >> a +b => 3 # a(+b) => a(b) => a(1) = 1 + 2 >> >> I'm not quite fond of such surprise in programming language syntax. > > Yes, whoever came up with the idea of whitespace having syntactic > significance! > > > Marko > Maybe you already knew this "esoteric" language: http://compsoc.dur.ac.uk/whitespace/ https://en.wikipedia.org/wiki/Whitespace_%28programming_language%29 And, just for completeness :) http://www.stroustrup.com/whitespace98.pdf -- https://mail.python.org/mailman/listinfo/python-list
numpy.allclose()
Can anyone explain the rationale for numpy's allclose() semantics? help(allclose) says: allclose(a, b, rtol=1e-05, atol=1e-08) Returns True if two arrays are element-wise equal within a tolerance. The tolerance values are positive, typically very small numbers. The relative difference (`rtol` * abs(`b`)) and the absolute difference `atol` are added together to compare against the absolute difference between `a` and `b`. [...] If the following equation is element-wise True, then allclose returns True. absolute(`a` - `b`) <= (`atol` + `rtol` * absolute(`b`)) I don't understand why they add the error tolerances together. I can understand taking the minimum, or the maximum: * taking the maximum is equivalent to the rule "numbers are close if they differ by no more than EITHER the absolute tolerance OR the relative tolerance"; * taking the minimum is equivalent to the rule "numbers are close if they differ by no more than BOTH the absolute tolerance AND the relative tolerance". But adding them together doesn't make any sense to me. That leads to the situation where two values are deemed "close" if you give two tolerances even though it fails each test individually: py> numpy.allclose([1.2], [1.0], 0.0, 0.1) # Fails absolute error test. False py> numpy.allclose([1.2], [1.0], 0.1, 0.0) # Fails relative error test. False py> numpy.allclose([1.2], [1.0], 0.1, 0.1) # Passes! True -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
In article , Chris Angelico wrote: > >But sure. If you want to cut out complication, dispense with user >accounts altogether and run everything as root. That's WAY simpler! I didn't except this strawman argument from you. Of course you need a distinction between doing system things as root, and working as a normal user. You just don't need sudo. > >ChrisA -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Sun, Jan 18, 2015 at 1:51 AM, Albert van der Horst wrote: > In article , > Chris Angelico wrote: > >> >>But sure. If you want to cut out complication, dispense with user >>accounts altogether and run everything as root. That's WAY simpler! > > I didn't except this strawman argument from you. > Of course you need a distinction between doing system things as > root, and working as a normal user. You just don't need sudo. So you have to have a password on the root account. My systems are more secure, as they do not have a password that someone could learn. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
In article , Chris Angelico wrote: >On Fri, Jan 9, 2015 at 4:02 AM, Steve Hayes wrote: >> On 08 Jan 2015 12:43:33 GMT, [email protected] (Albert van der Horst) >> wrote: >> >>>I don't trust sudo because it is too complicated. >>>(To the point that I removed it from my machine.) >>>I do >> >> How do you do that? >> >> I avoided Ubuntu because it had sudo, and then discovered that Fedora had it >> as well. > >Uhh, 'apt-get remove sudo'? That ought to work on any Debian-based That works. That is exactly what I did. >system. With Debian itself, you get the option during installation of >setting a root password, in which case it won't install sudo by >default. > >ChrisA -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
Re: recursive function: use a global or pass a parameter?
In article <[email protected]>, Steven D'Aprano wrote: > Good reasons for using global variables are few and far between. Just about > the only good reason for using global variables that I can think of is if > you have one or more settings/preference that get set once at the start of > the program and then apply to the entire program. I will commonly put something like: import logging logger = logging.getLogger("logger-name-for-my-module") in every source file in a big project. Now I've got a global logger I can use anywhere in the module (even in static functions). But, maybe that's just a subset of your "setting that gets set once at the start of the program" example. -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Chris Angelico wrote: > On Sun, Jan 18, 2015 at 1:51 AM, Albert van der Horst > wrote: > > In article , > > Chris Angelico wrote: > > > >> > >>But sure. If you want to cut out complication, dispense with user > >>accounts altogether and run everything as root. That's WAY simpler! > > > > I didn't except this strawman argument from you. > > Of course you need a distinction between doing system things as > > root, and working as a normal user. You just don't need sudo. > > So you have to have a password on the root account. My systems are > more secure, as they do not have a password that someone could learn. > Yes, they do (if you use sudo) it's *your* password and IMHO it's less secure as you only need to know one password to get root access. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 01/17/2015 07:51 AM, Albert van der Horst wrote: > In article , > Chris Angelico wrote: > >> >> But sure. If you want to cut out complication, dispense with user >> accounts altogether and run everything as root. That's WAY simpler! > > I didn't except this strawman argument from you. > Of course you need a distinction between doing system things as > root, and working as a normal user. You just don't need sudo. I just don't see the distinction. What's the difference between having to type in a root password and having to type in your own administrative user password? Guess we're all just struggling to understand your logic here. On my laptop sudo has a huge advantage over su, and that is I can use my fingerprint reader to access root. Now I could set up root to accept a fingerprint as well which would work with su, but the sudo solution is much quicker to configure. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why do the URLs of posts here change?
In article , Chris Angelico wrote: >On Sat, Jan 10, 2015 at 2:21 PM, Gregory Ewing > wrote: >> Skip Montanaro wrote: >>> >>> The way this is done, is >>> that the message is removed from the underlying mbox file, and the >>> archive regenerated. That changes the counter for every message after >>> that point >> >> >> Would it help to replace the message with a stub >> instead of deleting it altogether? > >I had the same thought, but apparently not, according to the page >Peter Otten linked to: > >http://wiki.list.org/display/DEV/Stable+URLs Knowing that the source is an mbox file, I don't need to follow that link to conclude that one is not very inventive. It suffices to replace the content of the message by a repetition of '\n'. Maybe also the sender and the subject. > >ChrisA -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Michael Torrie wrote: > On 01/17/2015 07:51 AM, Albert van der Horst wrote: > > In article , > > Chris Angelico wrote: > > > >> > >> But sure. If you want to cut out complication, dispense with user > >> accounts altogether and run everything as root. That's WAY simpler! > > > > I didn't except this strawman argument from you. > > Of course you need a distinction between doing system things as > > root, and working as a normal user. You just don't need sudo. > > I just don't see the distinction. What's the difference between having > to type in a root password and having to type in your own administrative > user password? Guess we're all just struggling to understand your logic > here. > One big distinction is that you need to know two passwords to get root access if there's a real root account as opposed to using sudo. This only applies of course if direct root login isn't allowed (via ssh or whatever). -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
In article <[email protected]>, Steven D'Aprano wrote: > Every time I think I would like to learn a new language, I quite quickly run > into some obvious feature that Python has but the newer language lacks, and > I think "bugger this for a game of soldiers" and abandon it. Wow. Another wonderful English phrase to add to my vocabulary. That's up there with Bob's your uncle :-) > Ah, wait, I forgot Ruby's brilliant "feature" that whitespace *between* > expressions is significant: > > [steve@ando ~]$ cat ~/coding/ruby/ws-example.rb > #!/usr/bin/ruby > > def a(x=4) > x+2 > end > > b = 1 > print "a + b => ", (a + b), "\n" > print "a+b => ", (a+b), "\n" > print "a+ b => ", (a+ b), "\n" > print "a +b => ", (a +b), "\n" > > [steve@ando ~]$ ruby ~/coding/ruby/ws-example.rb > a + b => 7 > a+b => 7 > a+ b => 7 > a +b => 3 > > > A shiny new penny for any non-Ruby coder who can explain that! The last time I looked at Ruby was when it was brand new. I bought the original pickaxe book and read it on a plane trip. It looked pretty cool at the time, but I never really got into it. So I think I qualify. Anyway, I'm going to guess from the above examples, that uttering a name means, "If the referent is callable, call it, if not, get its value". This is the same, for example, as django's template language. Or, kind of like Python's properties. So (a + b) means "Call a(), and add the value of b to that". I'm going to further guess that def a(x=4) means a() takes an optional argument, with a default value of 4, just like in Python. So a returns 6, i.e. 4 + 2. I'm going to further guess that (a +b) is parsed as "call a, passing +b as an argument", and the "+" is taken as a unary prefix. I want my penny. This is not the only example of significant whitespace in programming languages. Old-style C/C++ allowed either += or =+ for the increment operator. This led to parsing ambiguity for things like a=+b, where (IIRC), "a = +b" was parsed as an assignment and unary +, and "a =+ b" was parsed as an increment. Eventually, the syntax was changed to make += the only legal way to write increment. There was also the problem with nested template operators in C++, where "Foo>" was mis-parsed, and you had to write it as "Foo >" (or something like that) to get it to parse right. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
In article , Skip Montanaro wrote: > On Sat, Jan 17, 2015 at 5:59 AM, Jussi Piitulainen > wrote: > > How far do you want to go? Is "a b + c" the same as "a(b) + c" or the > > same as "a(b + c)"? > > I think there is only one practical interpretation, the one that all > shells I'm familiar with have adopted: > > a(b, +, c) > > > And I don't really want to know which it is. I prefer parentheses. > > They are not nearly as fragile. > > Agreed. Without parens, splitting the command line arguments on white > space is the only non-fragile way to do things. > > Skip I once worked with a language (with vaguely C-like syntax) in which: if(x == 4) and y = f (x) were both syntax errors. If statements *required* a space before the paren, and function calls *forbid* it. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
In article <[email protected]>, Steven D'Aprano wrote: > Whitespace is significant in nearly all programming languages, and so it > should be. Whitespace separates tokens, and lines, and is a natural way of > writing (at least for people using Western languages). >>> """x""" == " " "x" " " False > *Indentation* is significant to Python, while most languages enable tedious > and never-ending style wars over the correct placement of braces vis a vis > indentation, because their language is too simple-minded to infer block > structure from indentation. Python does derive block structure from > indentation, as god intended (otherwise he wouldn't have put tab keys on > typewriters) and so Python doesn't suffer from the interminable arguments > about formatting that most other languages do. Well, we do get to argue about x = [1, 2, 3] vs. x = [1, 2, 3, ] vs. a few other variations based on how you group the first element with the opening bracket, or the last element with the closing bracket, and, of course, whether you use the last trailing comma or not. -- https://mail.python.org/mailman/listinfo/python-list
Re: recursive function: use a global or pass a parameter?
In article <[email protected]>, Tim wrote: >I have this type of situation and wonder if I should use a global >variable outside the recursive function instead of passing the updated >parameter through. > >I want to get a union of all the values that any 'things' key may have, >even in a nested dictionary (and I do not know beforehand how deep the >nesting might go): > >d = {'things':1, 'two':{'things':2}} > >def walk(obj, res): >if not hasattr(obj, 'keys'): >return set(), set() > >if 'things' in obj: >res.add(obj['things']) > >for k in obj: >walk(obj[k], res) > >return res > >walk(d, set()) # returns {1, 2} > >Is it better to use a global to keep track of the values or does it even >matter? Neither. You shouldn't pass superfluous parameters, and you shouldn't abuse globals. The proper technique is make the global local to the normal subroutine, then make the subroutine with those parameters you don't want to see also local to that subroutine. E.g. def fib(n): ' return the n-th Fibonacci number ' a,b = 0,1 def fib1(ap,bp): ' for f_n,f_n+1, return f_n+1,f_n+2 ' return bp,ap+b for i in xrange(n): a,b = fib1(a,b) return a > >thanks, >--Tim Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
In article , wrote: >Michael Torrie wrote: >> On 01/17/2015 07:51 AM, Albert van der Horst wrote: >> > In article , >> > Chris Angelico wrote: >> > >> >> >> >> But sure. If you want to cut out complication, dispense with user >> >> accounts altogether and run everything as root. That's WAY simpler! >> > >> > I didn't except this strawman argument from you. >> > Of course you need a distinction between doing system things as >> > root, and working as a normal user. You just don't need sudo. >> >> I just don't see the distinction. What's the difference between having >> to type in a root password and having to type in your own administrative >> user password? Guess we're all just struggling to understand your logic >> here. >> >One big distinction is that you need to know two passwords to get root >access if there's a real root account as opposed to using sudo. This >only applies of course if direct root login isn't allowed (via ssh or >whatever). The other is that if a dozen users have sudo possibility, one compromised password compromises the whole system. The same administrators that like sudo will force the users into a "safe" password of at least 8 characters a special sign a number and a capital, instead of educating them to use a strong password like the_horse_eats_yellow_stones. 1] Chances are that one of the users has a password like ! (first special sign) 1 (first number) Q (first capital) followed by a weak 5 letter word (or even a guessable one). Compare that to "Dear administrator, I've to do this. Can I have the root password." "Sure here it is" Looks over users shoulder. "Are you ready?" Make sure he's logged out. Uses random generator for a new password. If there is something, anything, change the root password and check the disk for suid-root files. There is no such thing as automatic security. Security requires one thing: attention. And effort. So two things: attention and effort. And simplicity. So three things: attention, effort and simplicity. sudo makes administrators careless, lazy and it is not simple at all. >-- >Chris Green Groetjes Albert 1] I don't claim this is *very* strong, just strong. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 17/01/2015 16:47, [email protected] wrote: Michael Torrie wrote: On 01/17/2015 07:51 AM, Albert van der Horst wrote: In article , Chris Angelico wrote: But sure. If you want to cut out complication, dispense with user accounts altogether and run everything as root. That's WAY simpler! I didn't except this strawman argument from you. Of course you need a distinction between doing system things as root, and working as a normal user. You just don't need sudo. I just don't see the distinction. What's the difference between having to type in a root password and having to type in your own administrative user password? Guess we're all just struggling to understand your logic here. One big distinction is that you need to know two passwords to get root access if there's a real root account as opposed to using sudo. This only applies of course if direct root login isn't allowed (via ssh or whatever). Bah humbug, this has reminded me of doing secure work whereby each individual had two passwords, both of which had to be changed every thirty days, and rules were enforced so you couldn't just increment the number at the end of a word or similar. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, 17 Jan 2015 21:33:19 +1100, Steven D'Aprano wrote: > Gregory Ewing wrote: > >> Marko Rauhamaa wrote: >>> Gregory Ewing : >>> If those are 24-bit RGB pixels, you could encode 3 characters in each pixel. >>> >>> Not since Python3. Characters are Unicode now so you'll need to >>> dedicate a pixel for each character. >> >> Depends on which characters you want. With the Flexible Chromatic >> Representation, it could be anything from 1 to 3. > > Subpixel rendering is 5% slower than full pixel rendering, so it is > provably mathematically impossible to print Unicode characters. :-) -- It's union rules. There's nothing we can do about it. Sorry. -- https://mail.python.org/mailman/listinfo/python-list
Re: numpy.allclose()
On Sat, Jan 17, 2015 at 7:26 AM, Steven D'Aprano wrote: > I don't understand why they add the error tolerances together. I can > understand taking the minimum, or the maximum: The usual idea is that the tolerance is calculated as a relative value, but an absolute tolerance is used instead when the values get close to zero, so under normal circumstances the relative tolerance will dominate and the absolute tolerance will be very small in comparison. So why add them instead of taking the maximum? I'm not sure, but I would guess it's probably for efficiency. Determining the maximum requires the CPU to perform a conditional branch that a simple addition does not. In any case, this is not unique to numpy. See e.g.: https://books.google.com/books?id=CbH0AwAAQBAJ&pg=PA164 (equation 8.26) or: https://books.google.com/books?id=j0rY3D9fx-0C&pg=PA71 (equation 7.437) On the other hand, Matlab evidently uses the maximum: http://www.mathworks.com/help/simbio/ref/absolutetolerance.html > * taking the minimum is equivalent to the rule "numbers are close if they > differ by no more than BOTH the absolute tolerance AND the relative > tolerance". This is generally not the desired semantic, and it's not unheard of to pass 0 for one of the tolerances, in which case the minimum would clearly be incorrect. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 2015-01-16, Gregory Ewing wrote: > We're really quite spoiled in Python-land. It's easy > to forget just *how* spoiled we are until you go back > and try to do something in one of the more primitive > languages... I had to do some work in PHP yesterday -- fixing up some code that was written by somebody who only knows how to write C++ [though he can do it in several different languages]. There was lot's of quiet swearing. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
[email protected] (Albert van der Horst) wrote: > In article , wrote: >> Michael Torrie wrote: >>> On 01/17/2015 07:51 AM, Albert van der Horst wrote: In article , Chris Angelico wrote: > > But sure. If you want to cut out complication, dispense with user > accounts altogether and run everything as root. That's WAY simpler! I didn't except this strawman argument from you. Of course you need a distinction between doing system things as root, and working as a normal user. You just don't need sudo. >>> >>> I just don't see the distinction. What's the difference between having >>> to type in a root password and having to type in your own administrative >>> user password? Guess we're all just struggling to understand your logic >>> here. >>> >> One big distinction is that you need to know two passwords to get root >> access if there's a real root account as opposed to using sudo. This >> only applies of course if direct root login isn't allowed (via ssh or >> whatever). > > The other is that if a dozen users have sudo possibility, one compromised > password compromises the whole system. Hmm, but it's much worse if a dozen users have to know the root password. With this they can circumvent sudo completely (e.g. going over IPMI console). > Compare that to > "Dear administrator, I've to do this. Can I have the root password." > "Sure here it is" Looks over users shoulder. "Are you ready?" > Make sure he's logged out. Uses random generator for a new password. This process does not work for dozens of admins maintaining thousands of machines. Especially when something goes wrong in the night shift and has to be fixed quickly. > If there is something, anything, change the root password and check > the disk for suid-root files. Better require public key authc for SSH access and the user's own (one-time) password for sudo. If your security requirements are really high mandate going through a SSH gateway / jumphost. > Security requires one thing: attention. And effort. So two things: > attention and effort. And simplicity. So three things: attention, > effort and simplicity. Yes. > sudo makes administrators careless, lazy and it is not simple at all. Admins must have separate accounts with separate credentials for administrative work and must be careful when using an administrative account. Ciao, Michael. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 2015-01-17, Roy Smith wrote: > In article <[email protected]>, > Steven D'Aprano wrote: > >> Every time I think I would like to learn a new language, I quite quickly run >> into some obvious feature that Python has but the newer language lacks, and >> I think "bugger this for a game of soldiers" and abandon it. > > Wow. Another wonderful English phrase to add to my vocabulary. That's > up there with Bob's your uncle :-) Yup, that one's brilliant. While it's pretty much obvious what phrases like that mean when one stumbles across them for the first time, I find I sometimes don't have a very good grasp of where they fall on the offensive<->polite scale... -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, 17 Jan 2015 18:44:42 +, Grant Edwards wrote: > ... somebody who only knows how to write C++ [though he can do it in > several different languages]. +1 QOTW (brilliant phrases in other threads are off topic and are disqualified) I have also suffered through such maintenance, but I have never described it quite so succinctly. > There was lot's of quiet swearing. "Quiet" is *not* one of my strong points. -- Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: recursive function: use a global or pass a parameter?
On Sun, Jan 18, 2015 at 4:30 AM, Albert van der Horst wrote: > The proper technique is make the global local to the normal subroutine, > then make the subroutine with those parameters you don't want to see > also local to that subroutine. > E.g. > > def fib(n): > ' return the n-th Fibonacci number ' > a,b = 0,1 > def fib1(ap,bp): >' for f_n,f_n+1, return f_n+1,f_n+2 ' >return bp,ap+b > for i in xrange(n): >a,b = fib1(a,b) > return a That's a fairly useless use of a nested function... you could in-line it without any effort at all: def fib(n): a,b = 0,1 for i in xrange(n): a,b = b,a+b return a Even in the OP's example, where the inner function needs to call itself recursively, it doesn't need to be a closure; a simple out-of-line helper function does work (and has already been suggested; Gregory was, I think, first). In my opinion, it's not materially different from having an argument with a default. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, 17 Jan 2015 19:08:21 +, Dan Sommers wrote: > On Sat, 17 Jan 2015 18:44:42 +, Grant Edwards wrote: > >> ... somebody who only knows how to write C++ [though he can do it in >> several different languages]. > > +1 QOTW (brilliant phrases in other threads are off topic and are > disqualified) > > I have also suffered through such maintenance, but I have never > described it quite so succinctly. > >> There was lot's of quiet swearing. > > "Quiet" is *not* one of my strong points. How about "Some programmes have 20 years of experience, some have 1 year of experience 20 times" it covers pretty much the same poor coding practices. -- Ditat Deus. [God enriches] -- https://mail.python.org/mailman/listinfo/python-list
Re: recursive function: use a global or pass a parameter?
Roy Smith wrote:
I will commonly put something like:
import logging
logger = logging.getLogger("logger-name-for-my-module")
But that's not really a global variable, it's a
global constant. There's nothing wrong with those,
we use them all the time -- classes, functions, etc.
If you were to rebind logger to a different one from
time to time in your code, *then* it would be a global
variable, subject to the usual cautions.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: recursive function: use a global or pass a parameter?
Yawar Amin wrote: Cool ... but it looks like this can still potentially hit the max recursion limit? It depends on the nature of your data. If the data is a tree, it's very unlikely you'll reach the recursion limit unless the tree is massively unbalanced. If there's a chance of that, or if the data structure is really a graph that could contain long linear chains, then a non-recursive solution is safer. Incidentally, Python's pickle suffers from this problem -- it's possible to create a structure that can't be pickled due to excessive recursion depth: >>> x = [] >>> for i in range(5000): ... x = [x] ... >>> import pickle >>> s = pickle.dumps(x) Traceback (most recent call last): File "", line 1, in RuntimeError: maximum recursion depth exceeded while pickling an object Fortunately, the kinds of structures that cause this tend not to be used in Python, e.g. we normally use Python list objects instead of linked lists. So most of the time, pickle gets away with using recursion. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Steven D'Aprano wrote: def a(x=4) x+2 end a + b => 7 a+b => 7 a+ b => 7 a +b => 3 A shiny new penny for any non-Ruby coder who can explain that! Seems pretty obvious to me: the Ruby interpreter is infested with demons. DWIM = Demonic Whim Infers Meaning -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Chris Angelico wrote: Every once in a while, someone looks at Py2's print statement and Py3's print function and says, "why not allow function calls without parentheses". This right here is why not. There's also the fact that the parens are needed to distinguish between calling a function and using the function itself as a value. Ruby doesn't have that problem because it doesn't have functions, only methods, and the only thing you can do with a method in Ruby is call it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sun, Jan 18, 2015 at 8:56 AM, Gregory Ewing wrote: > Ruby doesn't have that problem because it doesn't > have functions, only methods, and the only thing you > can do with a method in Ruby is call it. So functions aren't first-class objects in Ruby? Bleh. I've become quite accustomed to passing them around casually, in several languages. Even C lets you pass function pointers around. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why do the URLs of posts here change?
Albert van der Horst wrote: Knowing that the source is an mbox file, I don't need to follow that link to conclude that one is not very inventive. It suffices to replace the content of the message by a repetition of '\n'. Editing the mbox file isn't the problem. From what I gather, telling mailman to regenerate the web pages from the mbox file causes all the messages to be given new ID numbers, even if they remain in the same places in the mbox. So the web pages as well as the mbox would have to be edited by hand, instead of using the auto regen process. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Jussi Piitulainen wrote: I prefer parentheses. They are not nearly as fragile. So do I, but the other day I had occasion to write a small piece of VBScript, and I discovered that it actually *forbids* parens around the arguments to procedure calls (but not function calls). Fortunately, it requires (or at least allows, not sure which) commas between the args, so things aren't as bad as they *could* be. Also fortunately, the error message was, by the usual standard of Microsoft error messages, remarkably helpful. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Mark Lawrence wrote: > Bah humbug, this has reminded me of doing secure work whereby each > individual had two passwords, both of which had to be changed every > thirty days, and rules were enforced so you couldn't just increment the > number at the end of a word or similar. I hate and despise systems that force you to arbitrarily change a good strong password after N days for no good reason. The utterly bad reason often given by people who don't understand probability is that if hackers try to guess your password by brute-force, changing the password regularly will make it harder for them. That's simply wrong, and is based on a misunderstanding of probability. The merely poor reason given by the more thoughtful sys admins is, if the password hashes get stolen, the hacker has a maximum of N days (and possibly less) to crack the hashes and recover the passwords before they get changed. That's okay as far as it goes, but it's the wrong solution for the problem. The right solution is to salt the passwords, and to secure the hashes from theft. Users should only be forced to change their password if the hashes are stolen, not at arbitrary intervals. The problem with regular password changes is that it makes it significantly harder remember passwords, especially one that you might only use rarely. It encourages users to pick weak, trivial passwords that can be trivially incremented each time the computer insists they change it, "blahblah-JAN" or "blahblahblah1", or to simply write the password down or a Post-it note on their computer. In isolation, regular password changes seems like a good idea, but in practice they are not. Password management is hard enough without having to throw away perfectly good, strong, memorable passwords every N days "just in case". -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Sun, Jan 18, 2015 at 10:46 AM, Steven D'Aprano wrote: > The merely poor reason given by the more thoughtful sys admins is, if the > password hashes get stolen, the hacker has a maximum of N days (and > possibly less) to crack the hashes and recover the passwords before they > get changed. That's okay as far as it goes, but it's the wrong solution for > the problem. Related to that is another reason I've heard: if your password is figured out by some means other than hash theft [1], there's a maximum of N days to make use of it. But let's face it, if someone gets hold of one of your accounts, it won't take long to do serious damage. Even if it's not a high-profile target like email or banking, a service with your password known by someone else is a problem *now*, not "after a month of research" or something. Password maximum age is the wrong solution to a few problems, and is itself a problem. Don't do it. ChrisA [1] eg http://xkcd.com/792/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Sorry for necro.
On Sat, Dec 20, 2014 at 10:44 PM, Chris Angelico wrote:
> On Sun, Dec 21, 2014 at 5:31 PM, Terry Reedy wrote:
>> Just to be clear, writing to sys.stdout works fine in Idle.
> import sys; sys.stdout.write('hello ')
>> hello #2.7
>>
>> In 3.4, the number of chars? bytes? is returned and written also.
>>
>> Whether you mean something different by 'stdout' or not, I am not sure. The
>> error is from writing to a non-existent file descriptor.
>
> That's because sys.stdout is replaced. But stdout itself, file
> descriptor 1, is not available:
It surprises me that IDLE, and most other shells, don't dup2
stdout/err/in so that those FDs talk to IDLE.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 01/17/2015 11:47 AM, Michael Ströder wrote: >> sudo makes administrators careless, lazy and it is not simple at all. > > Admins must have separate accounts with separate credentials for > administrative work and must be careful when using an administrative account. Right. This is not a bad idea in a large organization. In any case, Sudo is more auditable than su in my opinion, but more importantly, it's much easier to revoke. With su, if I fire an admin, I have to change root passwords on every machine, and redistribute the new password to every admin that needs it. With sudo, I might still change the root password, but I'll lock the root password up in a safe box somewhere, and life goes on for everyone else. In fact with root disabled entirely, the whole root password needing to be changed when a person leaves the company is completely eliminated. sudo allows us (especially with the idea about separate admin credentials) to have multiple, controllable, auditable, root passwords in effect. Surely the benefit of this can be seen. Another good alternative to sudo is ksu, which is a kerberized su. This also provides an excellent audit trail, and is easy to revoke. This may be more to Mr. van der Horst's liking, as normally ksu is configured to accept only principals with a /admin suffix (arbitrarily chosen). So admins would have their normal principal, and their admin principal. It's a pretty slick system if you have Kerberos up and running. -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Albert van der Horst wrote: > In article , wrote: >>Michael Torrie wrote: >>> On 01/17/2015 07:51 AM, Albert van der Horst wrote: >>> > In article , >>> > Chris Angelico wrote: >>> > >>> >> >>> >> But sure. If you want to cut out complication, dispense with user >>> >> accounts altogether and run everything as root. That's WAY simpler! >>> > >>> > I didn't except this strawman argument from you. >>> > Of course you need a distinction between doing system things as >>> > root, and working as a normal user. You just don't need sudo. >>> >>> I just don't see the distinction. What's the difference between having >>> to type in a root password and having to type in your own administrative >>> user password? Guess we're all just struggling to understand your logic >>> here. >>> >>One big distinction is that you need to know two passwords to get root >>access if there's a real root account as opposed to using sudo. This >>only applies of course if direct root login isn't allowed (via ssh or >>whatever). > > The other is that if a dozen users have sudo possibility, one compromised > password compromises the whole system. The same administrators that like > sudo will force the users into a "safe" password of at least 8 characters > a special sign a number and a capital, instead of educating them to > use a strong password like the_horse_eats_yellow_stones. 1] Sigh. I like XKCD, I really do, but anyone who thinks that brute force attacks cannot simply replace words for characters is deluding themselves. Consider a password like "mg93H$8s". Each character is taken from an alphabet of lowercase and uppercase letters plus digits, plus 32 punctuation characters and other symbols available on a US keyboard. There are 26+26+10+32 = 94 different "letters" in this alphabet. If your password is ten characters long, there is a potential pool of 94**10 available passwords. Let's say we strip out 90% of them for being "too easy to guess" (say, eight "A"s in a row, or it happens to contain your username). That still leaves us with: 94**10//10 = 5386151140948997017 potential passwords. Now consider the XKCD scheme. You pick four words from a dictionary and concatenate them. On my system, /usr/share/dict/words has a little less than 500,000 words. The problem is, most of them are not really memorable, and many of them are very low entropy. Here's a selection from the first few starting with A: A A. a a' a- a. A-1 A1 a1 A4 A5 AA aa A.A.A. AAA aaa So in practice people are going to choose words from a much, much smaller selection. I estimate that most people are going to choose words from a pool of about 10,000 words or so, but let's imagine that you have four times the vocabulary (or imagination) of the average person and pick from a pool of 40,000 words, specially crafted to avoid low-entropy selections such as "AAA A4 aa a". That gives: 4**4 = 256 potential passwords, half that of the conventional scheme. And if people have biases in the words they pick -- and you better believe they will -- that will be reduced even further. Password crackers will take advantage of the fact that most XKCD-style passwords will include at least one of the most common thousand or so words, reducing the search space significantly. I believe that the state of the art of password cracking is such now that people cannot realistically expect to remember sufficiently strong passwords for all the things they need passwords for. I believe that the only good solution is to have one strong passphrase that you use to protect a password manager, which in turn uses long (12 character or more), completely random passwords. Even that doesn't protect you, because your security is controlled by websites and banks etc. with stupid security policies. E.g. I am forced to deal with one bank that uses a cryptographic key to sign in to their bank, but your passphrase is limited to exactly eight characters. Another bank I use limits you to SIX characters, taken from case-insensitive(!) letters, digits, and a small set of punctuation. At least they do enforce rate limiting on account logins: three wrong login attempts and they lock your account and force you to go to a branch in person to recover it. (Can you say "Denial Of Service Attack"? I can.) > Compare that to > "Dear administrator, I've to do this. Can I have the root password." > "Sure here it is" Looks over users shoulder. "Are you ready?" > Make sure he's logged out. Uses random generator for a new password. That is a ridiculously impractical system for anything other than a home system. Problems include: - You have a single point of failure, the one administrator who controls access to the root password. The day he stays home with his phone switched off to play WOW is the day the mail server dies and you need root to fix it. The "Bus Factor" (what do you do when the administrator gets hit by a bus?) is critical. - You might be changing the roo
Re: lambdak: multi-line lambda implementation in native Python
Roy Smith wrote: > In article <[email protected]>, > Steven D'Aprano wrote: > >> Whitespace is significant in nearly all programming languages, and so it >> should be. Whitespace separates tokens, and lines, and is a natural way >> of writing (at least for people using Western languages). > """x""" == " " "x" " " > False I'm not sure what you are trying to say there. The left hand side is the string "x", the right hand side is the string " x ". I can tell you why they're different, I just can't tell you the definitive component in the Python interpreter which causes that difference (parser, lexer, keyhole optimizer, compiler...). I suspect the answer is implementation-dependent. """ is not the same as " " ", just as 123 and 1 2 3 are not the same. >> *Indentation* is significant to Python, while most languages enable >> tedious and never-ending style wars over the correct placement of braces >> vis a vis indentation, because their language is too simple-minded to >> infer block structure from indentation. Python does derive block >> structure from indentation, as god intended (otherwise he wouldn't have >> put tab keys on typewriters) and so Python doesn't suffer from the >> interminable arguments about formatting that most other languages do. > > Well, we do get to argue about > > x = [1, > 2, > 3] > > vs. > > x = [1, > 2, > 3, > ] > > vs. a few other variations based on how you group the first element with > the opening bracket, or the last element with the closing bracket, and, > of course, whether you use the last trailing comma or not. True, but nowhere near the Holy Wars about the One True Brace Style in languages like C. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: numpy.allclose()
Ian Kelly wrote: > On Sat, Jan 17, 2015 at 7:26 AM, Steven D'Aprano > wrote: >> I don't understand why they add the error tolerances together. I can >> understand taking the minimum, or the maximum: > > The usual idea is that the tolerance is calculated as a relative > value, but an absolute tolerance is used instead when the values get > close to zero, so under normal circumstances the relative tolerance > will dominate and the absolute tolerance will be very small in > comparison. That suggests that approx_equal() should return True if the actual error is smaller than *either* the absolute or relative error, that is, using the maximum. > So why add them instead of taking the maximum? I'm not > sure, but I would guess it's probably for efficiency. Determining the > maximum requires the CPU to perform a conditional branch that a simple > addition does not. That's... horrible. "Tell me whether these two numbers differ by at most X or Y%." "Oh, that would take a nanosecond longer than I think is reasonable, so I'm instead going to tell you whether they differ by some arbitrary Z instead." I'm guessing that can only have come from the mindset of C/C++ programmers, where this sort of thing is considered acceptable: http://blogs.msdn.com/b/oldnewthing/archive/2014/06/27/10537746.aspx :-) > In any case, this is not unique to numpy. See > e.g.: > > https://books.google.com/books?id=CbH0AwAAQBAJ&pg=PA164 > (equation 8.26) Ah, well as soon as you start using GPUs for numerical computation, you're already living in a state of sin. GPU's attitude to numerical correctness is best described as "meh, close enough". Seriously, anyone familiar with the horrible state of numeric computing prior to IEEE-756 surely cannot look at GPU numerics without having flashbacks to the bad old days where: if x != 0: y = 1/x could crash with a divide by zero! [...] >> * taking the minimum is equivalent to the rule "numbers are close if they >> differ by no more than BOTH the absolute tolerance AND the relative >> tolerance". > > This is generally not the desired semantic, and it's not unheard of to > pass 0 for one of the tolerances, in which case the minimum would > clearly be incorrect. True. In that case, you would have to treat 0 as a special case, which starts getting messy. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
In article <[email protected]>, Steven D'Aprano wrote: > Even that doesn't protect you, because your security is controlled by > websites and banks etc. with stupid security policies. E.g. I am forced to > deal with one bank that uses a cryptographic key to sign in to their bank, > but your passphrase is limited to exactly eight characters. Another bank I > use limits you to SIX characters, taken from case-insensitive(!) letters, > digits, and a small set of punctuation. Tell me about it. I have an E-Trade ATM card. When I first got it, I set it up with a 6 digit PIN. I was shocked to discover some time later that it actually only looks at the first 4 digits. And, no, I'm not talking *characters*, I'm talking *digits*. There are 10**4 possible PINs. The mind boggles. On the other hand, E-Trade gave me an RSA key fob so I use two-factor authentication on their web site. -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
Roy Smith wrote: > In article <[email protected]>, > Steven D'Aprano wrote: > >> Even that doesn't protect you, because your security is controlled by >> websites and banks etc. with stupid security policies. E.g. I am forced >> to deal with one bank that uses a cryptographic key to sign in to their >> bank, but your passphrase is limited to exactly eight characters. Another >> bank I use limits you to SIX characters, taken from case-insensitive(!) >> letters, digits, and a small set of punctuation. > > Tell me about it. I have an E-Trade ATM card. When I first got it, I > set it up with a 6 digit PIN. I was shocked to discover some time later > that it actually only looks at the first 4 digits. And, no, I'm not > talking *characters*, I'm talking *digits*. There are 10**4 possible > PINs. The mind boggles. > > On the other hand, E-Trade gave me an RSA key fob so I use two-factor > authentication on their web site. You know that two-factor authentication doesn't offer any real security against Man In The Middle attacks? Scenario: * You log in to the bank, and transfer $1 to me. * Evil haxor intercepts the transfer between your PC and the Internet, changing it to a request to transfer ONE MILLION DOLLARS to evil haxor's account. * Bank receives the request and sends you a token. * You receive the token and approve the transfer. * Evil haxor makes the money disappear. * When you complain to the bank that your account is ONE MILLION DOLLARS overdrawn, they insist that you authorized the transfer so their liability is limited to exactly Sweet FA. (I am very cynical about most of the "security features" the banks are pushing for, since in my opinion they are more about giving the banks plausible deniablity so they can push responsibility for security breaches onto the customer.) As soon as I heard that banks were turning to two-factor authentication I predicted that attackers would trivially move to man-in-the-middle and man-in-the-browser attacks to get around them. And sure enough, as long ago as 2006 that's exactly what happened: http://blog.washingtonpost.com/securityfix/2006/07/citibank_phish_spoofs_2factor_1.html More here: https://www.schneier.com/blog/archives/2012/09/man-in-the-midd_5.html (read the comments for more examples) All of the MITM attacks I know of involve social engineering attacks, but if and when customers get too sophisticated to fall for phishing attacks[1], the bad guys will move to scenarios like the one I described, where they hijack your own legitimate transactions. [1] Try not to laugh. It could happen. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On 2015-01-17 22:18, Roy Smith wrote: > Tell me about it. I have an E-Trade ATM card. When I first got > it, I set it up with a 6 digit PIN. I was shocked to discover some > time later that it actually only looks at the first 4 digits. And, > no, I'm not talking *characters*, I'm talking *digits*. There are > 10**4 possible PINs. The mind boggles. You think that's bad, one million Google Authenticator 2-factor verification codes were leaked: https://twitter.com/paulmutton/status/509991378647277568 Those hackers are a wily bunch. ;-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Sun, Jan 18, 2015 at 2:50 PM, Tim Chase wrote: > You think that's bad, one million Google Authenticator 2-factor > verification codes were leaked: > > https://twitter.com/paulmutton/status/509991378647277568 > > Those hackers are a wily bunch. ;-) http://torrent-city.net/download/Li/List-of-ALL-ip-addresses-[hacking-tool]-[source-code-included].5185923.html ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello World
On Sun, Jan 18, 2015 at 2:45 PM, Steven D'Aprano wrote: > (I am very cynical about most of the "security features" the banks are > pushing for, since in my opinion they are more about giving the banks > plausible deniablity so they can push responsibility for security breaches > onto the customer.) Definitely they are. Banks don't care about customers, they care about profits. James Hacker: I see, it's just profits, isn't it, Sir Desmond? Sir Desmond: It's not "just" profits - it's profits! -- Yes Minister ChrisA -- https://mail.python.org/mailman/listinfo/python-list
