Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/25/14 12:48 AM, Chris Angelico wrote: Yup. Welcome to timezones. I'm UTC +11 here, although we'll drop back to +10 shortly as DST finishes (yay!). It's currently 0547 UTC, so you're presumably five hours behind UTC, which would put you east coast USA, most likely. (Especially since your mailer is putting the dates as mm/dd/yy, which is an abomination peculiar to Americans.) No, we're already DST; so we're normally UTC -6, now UTC -5. We're CDST Minnesota (Southeast) Its entirely weird working with people all over the world in seconds 24-7 365 (we're on one tiny planet, you know?) marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/25/14 12:48 AM, Chris Angelico wrote: (Especially since your mailer is putting the dates as mm/dd/yy, which is an abomination peculiar to Americans.) I did not know that; so is 25 Mar 2014 the preferred way? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 15:19:50 +1100, Chris Angelico wrote: On Tue, Mar 25, 2014 at 2:59 PM, Mark H Harris harrismh...@gmail.com wrote: I personally think the answer is extended key maps triggered by meta keys shift ctrl opt alt command | which call up full alternate mappings of Greek|Latin|Math|symbols c which can be chosen by mouse|pointing device. The mac calls these keyboard viewer, and character viewer. In that way the full unicode set can be available from a standard qwerty keyboard without modifying the hardware right away. I can get up a character map on any platform fairly easily, and if not, I can always Google the name of the character I want and copy and paste from fileformat.info or some other handy site. It's not that hard. But if I want to say copyright, it's still quicker for me to type nine letters than to hunt down U+00A9 © to paste in somewhere. I hear what you are saying, but that's not *necessarily* the case. Back when I was a Mac user, in the 1980s and 90s, *every* application accepted the same keyboard shortcuts for the entire Mac character set. Nearly all of the chars had trivially simple mnemonics, e.g Option-p for π. Now, I don't happen to remember what the mnemonic for © (it has been 20 years since I was regularly using a Mac), but I remember it used to be really easy. Easier to type Option-whatever and get a © than typing copyright. So, if applications could standardise on a single interface for at least the common Unicode characters [er, common for who? English speakers? Japanese people? Arabs? Dutch?] then things would be more like 1984 on a Mac... -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 00:14:42 -0500, Mark H Harris wrote:
On 3/25/14 12:08 AM, Chris Angelico wrote:
How quickly can you switch, type one letter (to generate one Cyrillic
character), and switch back?
... very fast.
Is not this nicer?
Π = pi
That's the product operator.
py from unicodedata import name
py name('Π')
'GREEK CAPITAL LETTER PI'
You want lower-case pi, π.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 4:47 PM, Steven D'Aprano st...@pearwood.info wrote: On Tue, 25 Mar 2014 14:57:02 +1100, Chris Angelico wrote: No, I'm not missing that. But the human brain is a tokenizer, just as Python is. Once you know what a token means, you comprehend it as that token, and it takes up space in your mind as a single unit. There's not a lot of readability difference between a one-symbol token and a one-word token. Hmmm, I don't know about that. Mathematicians are heavy users of symbols. Why do they write ∀ instead of for all, or ⊂ instead of subset? Why do we write 40 instead of forty? Because the shorter symbols lend themselves better to the super-tokenization where you don't read the individual parts but the whole. The difference between 40 and forty is minimal, but the difference between 86400 and eighty-six thousand [and] four hundred is significant; the first is a single token, which you could then instantly recognize as the number of seconds in a day (leap seconds aside), but the second is a lengthy expression. There's also ease of writing. On paper or blackboard, it's really easy to write little strokes and curvy lines to mean things, and to write a bolded letter R to mean Real numbers. In Python, it's much easier to use a few more ASCII letters than to write ⊂ ℝ. Also, since the human brain works largely with words, I think that's a fairly controversial opinion. The Chinese might have something to say about that. Well, all the people I interviewed (three of them: me, myself, and I) agree that the human brain works with words. My research is 100% scientific, and is therefore unassailable. So there. :) I think that heavy use of symbols is a form of Huffman coding -- common things should be short, and uncommon things longer. Mathematicians tend to be *extremely* specialised, so they're all inventing their own Huffman codings, and the end result is a huge number of (often ambiguous) symbols. Yeah. That's about the size of it. Usually, each symbol has some read form; ℕ ⊂ ℝ would be read as Naturals are a subset of Reals (or maybe Naturals is a subset of Reals?), and in program code, using the word subset or issubset wouldn't be much worse. It would be some worse, and the exact cost depends on how frequently your code does subset comparisons; my view is that the worseness of words is less than the worseness of untypable symbols. (And I'm about to be arrested for murdering the English language.) Personally, I think that it would be good to start accepting, but not requiring, Unicode in programming languages. We can already write: from math import pi as π Perhaps we should be able to write: setA ⊂ setB It would be nice, if subset testing is considered common enough to warrant it. (I'm not sure it is, but I'm certainly not sure it isn't.) But it violates one obvious way. Python doesn't, as a general rule, offer us two ways of spelling the exact same thing. So the bar for inclusion would be quite high: it has to be so much better than the alternative that it justifies the creation of a duplicate notation. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 11:17:51 AM UTC+5:30, Steven D'Aprano wrote: On Tue, 25 Mar 2014 14:57:02 +1100, Chris Angelico wrote: wrote: What you are missing is that programmers spend 90% of their time reading code 10% writing code You may well be in the super-whiz category (not being sarcastic here) All that will change is upto 70-30. (ecause you rarely make a mistake) You still have to read oodles of others' code No, I'm not missing that. But the human brain is a tokenizer, just as Python is. Once you know what a token means, you comprehend it as that token, and it takes up space in your mind as a single unit. There's not a lot of readability difference between a one-symbol token and a one-word token. Hmmm, I don't know about that. Mathematicians are heavy users of symbols. Why do they write ∀ instead of for all, or ⊂ instead of subset? Why do we write 40 instead of forty? Also, since the human brain works largely with words, I think that's a fairly controversial opinion. The Chinese might have something to say about that. I think that heavy use of symbols is a form of Huffman coding -- common things should be short, and uncommon things longer. Mathematicians tend to be *extremely* specialised, so they're all inventing their own Huffman codings, and the end result is a huge number of (often ambiguous) symbols. Personally, I think that it would be good to start accepting, but not requiring, Unicode in programming languages. We can already write: from math import pi as π Perhaps we should be able to write: setA ⊂ setB Agree with all examples -- chinese being the best! Something that Chris may relate to: You type a music score into lilypond Then call lilypond to convert it into standard western staff notation Why not put up the lilypond (ASCII) directly on the piano/organ when you play? This is far from rhetorical... ABC,Guido,etc (not python's!) have some claim to be *musically* (not just textually) readable and easier to master than standard staff notation Still for someone - used to staff notation - under the standard presumptions of western music: -- harmony -- spelling c# ≠ d♭ -- a note is a note ie C to D is as much a note as D to E staff notation is hard to beat -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 4:56 PM, Mark H Harris harrismh...@gmail.com wrote: On 3/25/14 12:48 AM, Chris Angelico wrote: Yup. Welcome to timezones. I'm UTC +11 here, although we'll drop back to +10 shortly as DST finishes (yay!). It's currently 0547 UTC, so you're presumably five hours behind UTC, which would put you east coast USA, most likely. (Especially since your mailer is putting the dates as mm/dd/yy, which is an abomination peculiar to Americans.) No, we're already DST; so we're normally UTC -6, now UTC -5. We're CDST Minnesota (Southeast) Its entirely weird working with people all over the world in seconds 24-7 365 (we're on one tiny planet, you know?) It is one small planet, in many ways, yes. Plus, as well as timezones, you have different people working different schedules. Some of us are active in the weird hours of the night, others might be posting from work (a good bit of python-dev traffic right now involves one of Red Hat's Python people, so it's entirely possible he's posting during business hours his time), and others will be active here during their evenings. Net result: The list never goes quiet! (Especially since your mailer is putting the dates as mm/dd/yy, which is an abomination peculiar to Americans.) I did not know that; so is 25 Mar 2014 the preferred way? Putting the month in words is unambiguous (at least among users of the Gregorian calendar or its derivatives). For numeric dates, there are broadly three competing formats: d/m/y, m/d/y, and y/m/d. (Or using dots or hyphens between the components, or in the case of y/m/d, no separator at all - I'll write today's date as 20140325 in some contexts.) Of them, y/m/d is both the clearest and the least commonly used; with a four-digit year, there's no way it could be confused for anything else. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Mon, 24 Mar 2014 18:44:37 -0500, Mark H Harris wrote: On 3/24/14 6:01 PM, Chris Angelico wrote: Easy fix. Use the explicit capture notation: adders[n] = lambda a, n=n: a+n And there you are, out of your difficulty at once! Yes, yes, yes, and example: adders= list(range(4)) for n in adders: adders[n] = lambda a, n=n: a+n adders[1](3) 4 adders[2](3) 5 But, and this is the big (WHY?) is that necessary? In other words, its not about experts knowing how to make this work, its about normal people not understanding in the first place why its a problem, and why the various solutions work to fix it; even though we all know that nothing is 'broken'. The reason this is surprising is that people want their functions to magically read their mind and do what they want, even when they want it to do something different each time. If you have early binding, then people who want late binding will complain that it does the wrong thing. If you have late binding, then people who want early binding will complain that it does the wrong thing. Even when they are the same people. And *none of this has anything to do with lambda*. Functions created with def exhibit the exact same behaviour. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Mon, 24 Mar 2014 17:58:11 -0600, Ian Kelly wrote: On Mon, Mar 24, 2014 at 3:43 PM, Mark H Harris harrismh...@gmail.com wrote: Aside from the sin of spelling out lambda, should be ( \x y - x + y ) a b ) but, neither here nor there... Well no, it *should* be λx y . x + y but apparently some people don't have that character on their keyboards, so it gets written as lambda or \ instead. Holy cow! Is that where the Haskell syntax comes from? I never would have guessed in a million years that backslash \ was meant to be an ASCII-ified version of lambda. What a stupid idea that is. Writing lambda out in full is much more sensible. Personally I dislike the \ style; it doesn't really resemble a λ that closely, and to me the backslash denotes escape sequences and set differences. Nor is Python alone in spelling out lambda: Scheme and Common Lisp spell it the same way. As far as I know the \ for λ is unique to Haskell. At least they don't spell it fun. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 5:04 PM, Steven D'Aprano st...@pearwood.info wrote: I can get up a character map on any platform fairly easily, and if not, I can always Google the name of the character I want and copy and paste from fileformat.info or some other handy site. It's not that hard. But if I want to say copyright, it's still quicker for me to type nine letters than to hunt down U+00A9 © to paste in somewhere. I hear what you are saying, but that's not *necessarily* the case. Back when I was a Mac user, in the 1980s and 90s, *every* application accepted the same keyboard shortcuts for the entire Mac character set. Nearly all of the chars had trivially simple mnemonics, e.g Option-p for π. Now, I don't happen to remember what the mnemonic for © (it has been 20 years since I was regularly using a Mac), but I remember it used to be really easy. Easier to type Option-whatever and get a © than typing copyright. Easy enough with a restricted character set. When you're working with, say, 128 common characters and another 128 less common, it's not too hard to organize keystrokes for them all. So, if applications could standardise on a single interface for at least the common Unicode characters [er, common for who? English speakers? Japanese people? Arabs? Dutch?] then things would be more like 1984 on a Mac... And that's the problem. So what we'll have is a programming interface that makes it easy to type a bunch of symbols used in code, and it'll differ from pretty much everything else, and if you want to type lambda into an email you have to jump over to your code window, key it in, and then copy/paste... it wouldn't work without it being pretty much universal. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Mon, 24 Mar 2014 19:16:15 -0500, Mark H Harris wrote: On 3/24/14 7:11 PM, Chris Angelico wrote: On Tue, Mar 25, 2014 at 10:56 AM, Mark H Harrisharrismh...@gmail.com wrote: What is needed is the explicit closure grab recommended by ChrisA. Which does work. You do know why, right? Sure. ... but again, that's not the point. The point is NOT can you explain why it works, the point is that as a lambda construct it is NOT clear why it works, and because the construct does not match what lambda users might expect (naturally) there are *constant* questions about it. So, again, I'll restate that the community might consider (over time) whether the confusion created by lambda in python Functions created with def work exactly the same way. If you are surprised by lambda's binding behaviour, and you replace the lambda with def, you will still be confused. You'll have gone from a nice, concise expression to a bulky statement, and be no better off. You'll be worse off. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 5:10 PM, Rustom Mody rustompm...@gmail.com wrote: Something that Chris may relate to: You type a music score into lilypond Then call lilypond to convert it into standard western staff notation Why not put up the lilypond (ASCII) directly on the piano/organ when you play? This is far from rhetorical... ABC,Guido,etc (not python's!) have some claim to be *musically* (not just textually) readable and easier to master than standard staff notation Still for someone - used to staff notation - under the standard presumptions of western music: -- harmony -- spelling c# ≠ d♭ -- a note is a note ie C to D is as much a note as D to E staff notation is hard to beat I wouldn't say it's hard to beat... I happily beat time while looking at staff notation! (Of course, I shouldn't beat time. He doesn't like that.) Staff notation isn't perfect by any means (and there've been various projects to improve on it), but it's a lot better than the source code form in Lilypond. This is partly because my source code tends to look at multiple (often four) separate lines of harmony, often plus a separate line of chords, but when I'm playing, I want to be able to eyeball all of it at once. But I've used WYSIWYG notation editors plenty, and *for note entry* they offer me nothing above Lilypond's notation. I don't yearn to be able to scribble notes on a paper staff, scan it in, and have that functional. I don't look back with longing at NoteWorthy Composer (for which I do own a license, and could probably hunt down the install CD if I tried). There's a huge difference between the two. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 11:42:50 AM UTC+5:30, Chris Angelico wrote: On Tue, Mar 25, 2014 at 4:47 PM, Steven D'Aprano wrote: On Tue, 25 Mar 2014 14:57:02 +1100, Chris Angelico wrote: No, I'm not missing that. But the human brain is a tokenizer, just as Python is. Once you know what a token means, you comprehend it as that token, and it takes up space in your mind as a single unit. There's not a lot of readability difference between a one-symbol token and a one-word token. Hmmm, I don't know about that. Mathematicians are heavy users of symbols. Why do they write ∀ instead of for all, or ⊂ instead of subset? Why do we write 40 instead of forty? Because the shorter symbols lend themselves better to the super-tokenization where you don't read the individual parts but the whole. The difference between 40 and forty is minimal, but the difference between 86400 and eighty-six thousand [and] four hundred is significant; the first is a single token, which you could then instantly recognize as the number of seconds in a day (leap seconds aside), but the second is a lengthy expression. There's also ease of writing. On paper or blackboard, it's really easy to write little strokes and curvy lines to mean things, and to write a bolded letter R to mean Real numbers. In Python, it's much easier to use a few more ASCII letters than to write ⊂ ℝ. Also, since the human brain works largely with words, I think that's a fairly controversial opinion. The Chinese might have something to say about that. Well, all the people I interviewed (three of them: me, myself, and I) agree that the human brain works with words. My research is 100% scientific, and is therefore unassailable. So there. :) I think that heavy use of symbols is a form of Huffman coding -- common things should be short, and uncommon things longer. Mathematicians tend to be *extremely* specialised, so they're all inventing their own Huffman codings, and the end result is a huge number of (often ambiguous) symbols. Yeah. That's about the size of it. Usually, each symbol has some read form; ℕ ⊂ ℝ would be read as Naturals are a subset of Reals (or maybe Naturals is a subset of Reals?), and in program code, using the word subset or issubset wouldn't be much worse. It would be some worse, and the exact cost depends on how frequently your code does subset comparisons; my view is that the worseness of words is less than the worseness of untypable symbols. (And I'm about to be arrested for murdering the English language.) Personally, I think that it would be good to start accepting, but not requiring, Unicode in programming languages. We can already write: from math import pi as π Perhaps we should be able to write: setA ⊂ setB It would be nice, if subset testing is considered common enough to warrant it. (I'm not sure it is, but I'm certainly not sure it isn't.) But it violates one obvious way. Python doesn't, as a general rule, offer us two ways of spelling the exact same thing. So the bar for inclusion would be quite high: it has to be so much better than the alternative that it justifies the creation of a duplicate notation. I dont think we are anywhere near making real suggestions for real changes which would need to talk of compatibility, portability, editor support and all such other good stuff. Just a bit of brainstorming to see how an alternative python would look like: Heres a quickly made list of symbols that may be nice to have support for × ÷ ≤ ≥ ∧ ∨ ¬ π λ ∈ ∉ ⊂ ⊃ ⊆ ⊇ ∅ ∩ ∪ ← … (ellipsis instead of range) -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 12:03:24 PM UTC+5:30, Chris Angelico wrote: On Tue, Mar 25, 2014 at 5:10 PM, Rustom Mody wrote: Something that Chris may relate to: You type a music score into lilypond Then call lilypond to convert it into standard western staff notation Why not put up the lilypond (ASCII) directly on the piano/organ when you play? This is far from rhetorical... ABC,Guido,etc (not python's!) have some claim to be *musically* (not just textually) readable and easier to master than standard staff notation Still for someone - used to staff notation - under the standard presumptions of western music: -- harmony -- spelling c# ≠ d♭ -- a note is a note ie C to D is as much a note as D to E staff notation is hard to beat I wouldn't say it's hard to beat... I happily beat time while looking at staff notation! (Of course, I shouldn't beat time. He doesn't like that.) Staff notation isn't perfect by any means (and there've been various projects to improve on it), but it's a lot better than the source code form in Lilypond. This is partly because my source code tends to look at multiple (often four) separate lines of harmony, often plus a separate line of chords, but when I'm playing, I want to be able to eyeball all of it at once. ALl of which is isomorphic to Steven's point that forty is less eyeballable than 40 And mine that ∅ is more eyeballable than set([]) -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 5:35 PM, Rustom Mody rustompm...@gmail.com wrote: I dont think we are anywhere near making real suggestions for real changes which would need to talk of compatibility, portability, editor support and all such other good stuff. Just a bit of brainstorming to see how an alternative python would look like: Heres a quickly made list of symbols that may be nice to have support for × ÷ ≤ ≥ ∧ ∨ ¬ π λ ∈ ∉ ⊂ ⊃ ⊆ ⊇ ∅ ∩ ∪ ← … (ellipsis instead of range) Most of those look fine, but that's a fair bunch of characters you'd need to type. And will you stop there? Would other symbols want to be typable too? And if you have ellipsis (the character) would you also support three consecutive U+002E to mean the same thing? (People *will* type it that way, and would be extremely annoyed if it didn't work.) And will you turn Python into APL? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/25/14 12:08 AM, Chris Angelico wrote: How quickly can you switch, type one letter (to generate one Cyrillic character), and switch back? Ok.. after installing Ukelete from Summer Institute of Linguistics SIL I can now edit the installed keymaps and select them from input sources at the top of the menu bar. So, I mapped the alt-l key to λ and whalla, lambda in zero time; whoohoo. Same for π, just alt-p. Control has an entire blank page for key mappings so the sky is the limit. very fast, no mouse marcus λ π -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 5:41 PM, Rustom Mody rustompm...@gmail.com wrote: ALl of which is isomorphic to Steven's point that forty is less eyeballable than 40 And mine that ∅ is more eyeballable than set([]) I don't disagree that it is; the short tokens are easier to read in quantity. I just don't think that it's sufficient to justify piles of new and hard-to-look-up operators and things. (And a literal notation for an empty set would be a good thing. If I were designing a Python-like language from scratch now, I'd probably differentiate sets and dictionaries better, which would allow each one to have its own empty literal.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 12:15:11 PM UTC+5:30, Chris Angelico wrote: On Tue, Mar 25, 2014 at 5:35 PM, Rustom Mody wrote: I dont think we are anywhere near making real suggestions for real changes which would need to talk of compatibility, portability, editor support and all such other good stuff. Just a bit of brainstorming to see how an alternative python would look like: Heres a quickly made list of symbols that may be nice to have support for × ÷ ≤ ≥ ∧ ∨ ¬ π λ ∈ ∉ ⊂ ⊃ ⊆ ⊇ ∅ ∩ ∪ ← … (ellipsis instead of range) Most of those look fine, but that's a fair bunch of characters you'd need to type. And will you stop there? Would other symbols want to be typable too? And if you have ellipsis (the character) would you also support three consecutive U+002E to mean the same thing? (People *will* type it that way, and would be extremely annoyed if it didn't work.) And will you turn Python into APL? Yes APL is a good example to learn mistakes from - being before its time/technology - taking a good idea too far - assuming that I understand clearly implies so do others - maybe some others As for ellipsis I guess its misguided [Was actually looking for 'center-ellipsis' which would not be so ambiguous] -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
On Mon, 24 Mar 2014 21:39:33 -0500, Mark H Harris wrote: On 3/24/14 8:20 PM, Terry Reedy wrote: On 3/24/2014 7:56 PM, Mark H Harris wrote: the list which is used for each of the adder[] functions created. Wrong. Functions look up global and nonlocal names, such as n, when the function is called. hi Terry, yeah, I know; this is what's *wrong* all at once. Functions look up global and nonlocal names such as n, is semantics for each created function 'grabs' the last number (n) in the list, well, because that (n) is bound at call-time to (3). Your version semantically is detailed and correct; my version semantically is how it is perceived by the user, which is also correct. No it isn't. You can demonstrate that some mental models are closer to the actual behaviour of the interpreter, while other models are incorrect, by writing just a little more complex code. py def test(arg): ... results = [] ... for n in [1, 2, 3, 4]: ... results.append(lambda: n) ... n = arg ... return results ... py for func in test(1000): ... print(func()) ... 1000 1000 1000 1000 The functions don't grab the last value from the list. They see whatever value the variable n has at the time the function is called. Are you surprised by this? If you are, it is because you haven't thought it through in any detail. Let me show you something superficially different: py funcs = [] py for n in [1, 2, 3, 4]: ... def f(): ... return n ... funcs.append(f) ... py n = 1000 py for f in funcs: ... print(f()) ... 1000 1000 1000 1000 Are you still surprised? I bet you aren't. How else would you expect a variable to work? Early binding may be *useful* sometimes, but it would be terribly surprising if it were the default: my_name = Fred def greet(): print(Hello, my_name) my_name = Barney greet() Would you expect to see Hello Fred? The problem here is that Python is consistent, but people *want* it to be inconsistent. When it doesn't magically read their mind, they get confused that it isn't working the way they expected. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Mon, 24 Mar 2014 20:56:19 -0700, Rustom Mody wrote: Paren vs tuples: why do we need to write (x,) not (x) You don't. You can write x, without the brackets: py t = 23, py type(t) class 'tuple' It's the comma that makes tuples, not the brackets. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 17:19:10 +1100, Chris Angelico wrote: I'll write today's date as 20140325 in some contexts.) Of them, y/m/d is both the clearest and the least commonly used; with a four-digit year, there's no way it could be confused for anything else. Shame on you Chris! Don't you know the One True Way to write unambiguous dates is the ISO data format? 2014-03-25 -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 6:03 PM, Steven D'Aprano st...@pearwood.info wrote: On Tue, 25 Mar 2014 17:19:10 +1100, Chris Angelico wrote: I'll write today's date as 20140325 in some contexts.) Of them, y/m/d is both the clearest and the least commonly used; with a four-digit year, there's no way it could be confused for anything else. Shame on you Chris! Don't you know the One True Way to write unambiguous dates is the ISO data format? 2014-03-25 Bah, BIND won't let me use ISO format! rosuav@sikorsky:~$ dig kepl.com.au soa +short gideon.rosuav.com. domainmaster.kepl.com.au. 2014030601 7200 3600 2419200 604800 Looks like I last edited that on the 6th inst. But yes, hyphens are more common than slashes for delimited ymd dates. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 12:33:49 PM UTC+5:30, Steven D'Aprano wrote: On Mon, 24 Mar 2014 20:56:19 -0700, Rustom Mody wrote: Paren vs tuples: why do we need to write (x,) not (x) You don't. You can write x, without the brackets: py t = 23, py type(t) It's the comma that makes tuples, not the brackets. Yeah Chris already corrected that misconception of mine Doesn't chage my point much though -- () overloaded to ',' overloaded -- https://mail.python.org/mailman/listinfo/python-list
Re: Asyncio (or something better) for control of a vacuum system/components.
Shishir shish...@gmail.com writes: ... I am writing a software to control and monitor a vacuum furnace+attachments. It has a few mass flow controllers, a butterfly valve, a labjack unit for analog/digital outputs etc. They use RS485, RS232 and USB to communicate with the computer and follow special protocols for commands and response. The response time to execute commands can be from 5 ms to 1 s. To achieve this, I thought of a server which reads commands on a network connections, parses the command and calls methods of appropriate device classes, which then use the corresponding channel protocol to execute the command. The response provided by the devices (flow controllers, valve) is sent back on the network connection. As there can be multiple clients (e.g. for monitoring from several computers), and some commands can take long, the server should not block when getting a command executed. Asyncio is targeted at asynchronous (i.e. non-blocking) input/output. To ensure that the server remains responsive during command execution, you will need something in addition - e.g. threads or subprocesses. This way, the commands can be executed (by a separate thread/subprocess) while the server is still listening to communication. I know of one framework which supports this kind of interaction: medusa/ZServer. However, it is targeted mainly towards standard internet communication protocols (HTTP, FTP, ...). From your message, I have gained the impression that you want to support multiple (concurrent) requests on the same communication channel. This significantly complicates the task as the responses to those requests may arrive out of order and may even mix with one another (on the channel), unless you avoid this carefully. The medusa/ZServer framework (mentioned above) supports HTTP pipelining (i.e. the client can issue multiple requests without waiting for a response). However, it starts processing of a request only when all previous requests from the same (communication) channel have been completed. This way, it ensures that all responses are delivered in the same order as the requests (as required by HTTP pipelining). If out of order responses must be supported, then medusa/ZServer is not an appropriate approach. Special logic is then necessary on both server and client to associate the responses to the proper requests. -- https://mail.python.org/mailman/listinfo/python-list
Re: gdb python how to output integer for examine memory
Wesley nisp...@gmail.com writes: I am trying to use gdb debug python script. I am using gdb7.7 and python2.7.6, here is my simple test script: import time def next(i): time.sleep(10) i = 1 - i i = 1 while True: next(i) When this script running, gdb attach to it, and here is snippet: ... (gdb) frame 5 #5 0x004d01a7 in PyEval_EvalFrameEx (f=Frame 0x201e130, for file test.py, line 6, in next (i=1), throwflag=0) at Python/ceval.c:2666 2666x = call_function(sp, oparg); (gdb) py-locals i = 1 (gdb) pyo i No symbol i in current context. Quite a lot of time has passed since I last had to debug Python processes at C level -- thus, my memory may be unreliable. When I remember right, then pyo is used to interprete a C level variable as a Python object (and print it) -- not a Python level variable. In your case, i is a Python level variable. You must carefully distinguish between the C level and the Python level. Some commands expect C level names/objects; others may expect Python level names/objects. To learn how you can obtain the value of a Python variable, I see two approaches: look through the list of provided commands (and their documentation) and try to figure out which might be applicable and then may some tests; or look at the implementation of py-locals and use this knowledge to define you own command (for this, you will also need to understand the gdb language to define commands). -- https://mail.python.org/mailman/listinfo/python-list
Re: Memory error
Jamie Mitchell jamiemitchell1...@gmail.com writes: ... I then get a memory error: Traceback (most recent call last): File stdin, line 1, in module File /usr/local/sci/lib/python2.7/site-packages/scipy/stats/stats.py, line 2409, in pearsonr x = np.asarray(x) File /usr/local/sci/lib/python2.7/site-packages/numpy/core/numeric.py, line 321, in asarray return array(a, dtype, copy=False, order=order) MemoryError MemoryError means that Python cannot get sufficent memory from the operating system. You have already found out one mistake. Should you continue to get MemoryError after this is fixed, then your system does not provide enough resources (memory) to solve the problem at hand. You would need to find a way to provide more resources. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
Chris Angelico ros...@gmail.com: On Tue, Mar 25, 2014 at 4:14 PM, Mark H Harris harrismh...@gmail.com wrote: Π = pi That's good! (Although typing Π quicker than pi is majorly pushing it. It don't think that's good. The lower-case letter π should be used. The upper-case letter is used for a product, although unicode dedicates a separate character for the purpose: ∏. I often see Americans, especially, confuse upper and lower-case letters in symbols (KM for km, L for l etc). However, we are dealing with case-sensitive programming languages, so our eyes should have been trained to address meaning to upper and lower case. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: gdb python how to output integer for examine memory
在 2014年3月25日星期二UTC+8下午3时49分09秒，dieter写道： Wesley nisp...@gmail.com writes: I am trying to use gdb debug python script. I am using gdb7.7 and python2.7.6, here is my simple test script: import time def next(i): time.sleep(10) i = 1 - i i = 1 while True: next(i) When this script running, gdb attach to it, and here is snippet: ... (gdb) frame 5 #5 0x004d01a7 in PyEval_EvalFrameEx (f=Frame 0x201e130, for file test.py, line 6, in next (i=1), throwflag=0) at Python/ceval.c:2666 2666x = call_function(sp, oparg); (gdb) py-locals i = 1 (gdb) pyo i No symbol i in current context. Quite a lot of time has passed since I last had to debug Python processes at C level -- thus, my memory may be unreliable. When I remember right, then pyo is used to interprete a C level variable as a Python object (and print it) -- not a Python level variable. In your case, i is a Python level variable. You must carefully distinguish between the C level and the Python level. Some commands expect C level names/objects; others may expect Python level names/objects. To learn how you can obtain the value of a Python variable, I see two approaches: look through the list of provided commands (and their documentation) and try to figure out which might be applicable and then may some tests; or look at the implementation of py-locals and use this knowledge to define you own command (for this, you will also need to understand the gdb language to define commands). Hi Dieter, Thanks. Actually, I can now see the varialbe names at Python level and C level. I just want to verify x command to monitor the memory content. So, in my origin post, I can get variable i's address, and see the value is 1, then, I wanna have a try x command, the issue is, when use x/format i's address, the output is not 1, but other things:-( -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Tue, Mar 25, 2014 at 7:05 PM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: On Tue, Mar 25, 2014 at 4:14 PM, Mark H Harris harrismh...@gmail.com wrote: Π = pi That's good! (Although typing Π quicker than pi is majorly pushing it. It don't think that's good. The lower-case letter π should be used. The upper-case letter is used for a product, although unicode dedicates a separate character for the purpose: ∏. I often see Americans, especially, confuse upper and lower-case letters in symbols (KM for km, L for l etc). However, we are dealing with case-sensitive programming languages, so our eyes should have been trained to address meaning to upper and lower case. This has been pointed out multiple times, and I did notice it myself. But it's not significant, and I was trying to avoid nit-picking. If you can type a capital ∏, you can type a lower-case π, unless there's something very weird going on. So it still makes his point. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Tue, 25 Mar 2014 19:23:45 +1100, Chris Angelico wrote: I was trying to avoid nit-picking What, on comp.lang.python? What's wrong with you? :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Tue, Mar 25, 2014 at 7:59 PM, Steven D'Aprano st...@pearwood.info wrote: On Tue, 25 Mar 2014 19:23:45 +1100, Chris Angelico wrote: I was trying to avoid nit-picking What, on comp.lang.python? What's wrong with you? :-) I know, it's like refraining from bike-shedding on python-ideas or not reading the Bible in a Presbyterian church service. But occasionally I do try to be polite, or to make a point without worrying about the detlais... :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 06:08, Chris Angelico wrote: On Tue, Mar 25, 2014 at 4:00 PM, Rustom Mody rustompm...@gmail.com wrote: Its already there -- and even easier Switch to cyrillic-jis-russian (whatever that is!) and I get л from k Л from K How quickly can you switch, type one letter (to generate one Cyrillic character), and switch back? If you can do that more quickly than typing a word, then (for you!) it might be worth using those letters as symbols. ChrisA I thought programs were read more than written. So if writing is made a bit more problematic but the result is more readable because we are able to use symbols that are already familiar from other contexts, I would say it is worth it. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: I thought programs were read more than written. So if writing is made a bit more problematic but the result is more readable because we are able to use symbols that are already familiar from other contexts, I would say it is worth it. It's a matter of extents. If code is read ten times for every time it's written, making it twenty times harder to write and a little bit easier to read is still a bad tradeoff. Also: To what extent IS that symbol familiar from some other context? Are you using Python as a programming language, or should you perhaps be using a mathematical front-end? Not everything needs to perfectly match what anyone from any other context will expect. This is, first and foremost, a *programming* language. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
x = [[1, 2], [3, 4]] for x in x: ... for x in x: ... print(x) This is valid in the syntax level in python. But it is only good for those writing obscure programs in my opinions at most team works. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 05:14, Chris Angelico wrote:
On Tue, Mar 25, 2014 at 2:56 PM, Rustom Mody rustompm...@gmail.com
I don't know about the difference between {} in set theory and Python,
but the multiple uses of () actually boil down to two:
In set theory {} makes sets
In python {} makes dictionaries
That's a backward-compatibility issue. Braces in Python meant a
dictionary before it acquired a set type (at least, so I learned in
history class - I wasn't using Python back then), so empty braces have
to continue to mean empty dictionary.
No they didn't have to. With the transition to python3, the developers
could have opted for empty braces to mean an empty set. And if they
wanted a literal for an empty dictionary, they might have chosen {:}.
Backward-compatibility was already broken so that wasn't an argument.
I sympathize with the confusion,
but short of confusing everyone terribly by changing dicts to use
something other than braces (maybe borrow Pike's mapping notation, ([
])??), I don't really see a solution.
Come on. The problem isn't that both set and dictionary literal use
braces. That doesn't seem to be a problem in python3. The only question
was what should {} represent and how do we get an empty collection of
the other kind. If {} had been an empty set, dict() could have been
used for an empty dictionary is {:} had been unacceptable.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
[newbie] confusion concerning fetching an element in a 2d-array
I'm confused by the behaviour of the following python-script I wrote:
#!/usr/bin/env python
#I first made a data file 'test.dat' with the following content
#1.0 2 3
#4 5 6.0
#7 8 9
import numpy as np
lines=[line.strip() for line in open('test.dat')]
#convert lines-list to numpy-array
array_lines=np.array(lines)
#fetch element at 2nd row, 2nd column:
print array_lines[1, 1]
When running the script I always get the following error:
IndexError: invalid index
Can anyone here explain me what I am doing wrong and how to fix it?
thanks in advance
jean
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 10:54, Chris Angelico wrote: On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: I thought programs were read more than written. So if writing is made a bit more problematic but the result is more readable because we are able to use symbols that are already familiar from other contexts, I would say it is worth it. It's a matter of extents. If code is read ten times for every time it's written, making it twenty times harder to write and a little bit easier to read is still a bad tradeoff. Also: To what extent IS that symbol familiar from some other context? Are you using Python as a programming language, or should you perhaps be using a mathematical front-end? Not everything needs to perfectly match what anyone from any other context will expect. This is, first and foremost, a *programming* language. So? We do use + -, so why shouldn't we use × for multiplication. Would such a use already indicate I should use a mathematical front-end? When a programming language is borrowing concepts from mathematics, I see no reason not to borrow the symbols used too. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Have you ever wondered why there are so many flavors of python. This post answers all your queries.
http://www.techdarting.com/2014/03/why-different-flavors-of-python.html -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
On Tue, 25 Mar 2014 03:26:26 -0700, Jean Dubois wrote:
I'm confused by the behaviour of the following python-script I wrote:
#!/usr/bin/env python
#I first made a data file 'test.dat' with the following content
#1.0 2 3
#4 5 6.0
#7 8 9
import numpy as np
lines=[line.strip() for line in open('test.dat')]
#convert lines-list to numpy-array
array_lines=np.array(lines)
#fetch element at 2nd row, 2nd column:
print array_lines[1, 1]
When running the script I always get the following error: IndexError:
invalid index
Can anyone here explain me what I am doing wrong and how to fix it?
Yes. Inspect the array by printing it, and you'll see that it is a one-
dimensional array, not two, and the entries are strings:
py import numpy as np
py # simulate a text file
... data = 1.0 2 3
... 4 5 6.0
... 7 8 9
py lines=[line.strip() for line in data.split('\n')]
py # convert lines-list to numpy-array
... array_lines = np.array(lines)
py print array_lines
['1.0 2 3' '4 5 6.0' '7 8 9']
The interactive interpreter is your friend! You never need to guess what
the problem is, Python has powerful introspection abilities, one of the
most powerful is also one of the simplest: print. Another powerful tool
in the interactive interpreter is help().
So, what to do about it? Firstly, convert your string read from a file
into numbers, then build your array. Here's one way:
py values = [float(s) for s in data.split()]
py print values
[1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]
py array_lines = np.array(values)
py array_lines = array_lines.reshape(3, 3)
py print array_lines
[[ 1. 2. 3.]
[ 4. 5. 6.]
[ 7. 8. 9.]]
There may be other ways to do this, but that works for me.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
No they didn't have to. With the transition to python3, the developers
could have opted for empty braces to mean an empty set. And if they
wanted a literal for an empty dictionary, they might have chosen {:}.
Backward-compatibility was already broken so that wasn't an argument.
Python 3.0 didn't just say to Hades with backward compatibility. The
breakage was only in places where it was deemed worthwhile. Changing
the meaning of {} would have only small benefit and would potentially
break a LOT of programs, so the devs were right to not do it.
Python 3 and Python 2 are not, contrary to some people's opinions,
completely different languages.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 11:38:38 +0100, Antoon Pardon wrote: On 25-03-14 10:54, Chris Angelico wrote: On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: I thought programs were read more than written. So if writing is made a bit more problematic but the result is more readable because we are able to use symbols that are already familiar from other contexts, I would say it is worth it. It's a matter of extents. If code is read ten times for every time it's written, making it twenty times harder to write and a little bit easier to read is still a bad tradeoff. Also: To what extent IS that symbol familiar from some other context? Are you using Python as a programming language, or should you perhaps be using a mathematical front-end? Not everything needs to perfectly match what anyone from any other context will expect. This is, first and foremost, a *programming* language. So? We do use + -, so why shouldn't we use × for multiplication. I can't find × on my keyboard! I tried using x instead, but I got a syntax error: py 2x3 File stdin, line 1 2x3 ^ SyntaxError: invalid syntax Would such a use already indicate I should use a mathematical front-end? When a programming language is borrowing concepts from mathematics, I see no reason not to borrow the symbols used too. I'd like to sum the squares of the integers from n=1 to 10. In the old Python, I'd write sum(n**2 for n in range(1, 11)), but with the brave new world of maths symbols, I'd like to write this: http://timmurphy.org/examples/summation_large.jpg How do I enter that, and what text editor should I use? -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 12:14, Steven D'Aprano wrote: On Tue, 25 Mar 2014 11:38:38 +0100, Antoon Pardon wrote: On 25-03-14 10:54, Chris Angelico wrote: On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: I thought programs were read more than written. So if writing is made a bit more problematic but the result is more readable because we are able to use symbols that are already familiar from other contexts, I would say it is worth it. It's a matter of extents. If code is read ten times for every time it's written, making it twenty times harder to write and a little bit easier to read is still a bad tradeoff. Also: To what extent IS that symbol familiar from some other context? Are you using Python as a programming language, or should you perhaps be using a mathematical front-end? Not everything needs to perfectly match what anyone from any other context will expect. This is, first and foremost, a *programming* language. So? We do use + -, so why shouldn't we use × for multiplication. I can't find × on my keyboard! Then use an editor that allows you to configure it, so you can easily use it. That's the kind of advice that is often enough given here if some python feature is hard for the tools someone is using. So why should it be different now? Would such a use already indicate I should use a mathematical front-end? When a programming language is borrowing concepts from mathematics, I see no reason not to borrow the symbols used too. I'd like to sum the squares of the integers from n=1 to 10. In the old Python, I'd write sum(n**2 for n in range(1, 11)), but with the brave new world of maths symbols, I'd like to write this: http://timmurphy.org/examples/summation_large.jpg How do I enter that, and what text editor should I use? You have a point. Blindly following mathematical notation will not work, because mathematics often enough uses positional clues that will be very hard to incorparate in a programming language. But often enough languages tried to use the symbols that were available to them. Now that more are, I see little reason for avoiding there use. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 12:12, Chris Angelico wrote:
On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
No they didn't have to. With the transition to python3, the developers
could have opted for empty braces to mean an empty set. And if they
wanted a literal for an empty dictionary, they might have chosen {:}.
Backward-compatibility was already broken so that wasn't an argument.
Python 3.0 didn't just say to Hades with backward compatibility. The
breakage was only in places where it was deemed worthwhile. Changing
the meaning of {} would have only small benefit and would potentially
break a LOT of programs, so the devs were right to not do it.
More programs than those who broke because print was now a function?
Do you think it would have been so problamatic that it couldn't have
been handled by '2to3'?
Maybe breaking backward-compatibility wasn't considered worthwhile,
but that is not the same as stating backward-compatibility was
necessary. And that is how I understood how you stated your claim.
Python 3 and Python 2 are not, contrary to some people's opinions,
completely different languages.
And changing the meaning of {} to now indicate the emppty set, wouldn't
have turned it in a completely different language either.
--
Antoon Pardon.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 5:16:14 PM UTC+5:30, Antoon Pardon wrote: On 25-03-14 12:14, Steven D'Aprano wrote: Would such a use already indicate I should use a mathematical front-end? When a programming language is borrowing concepts from mathematics, I see no reason not to borrow the symbols used too. I'd like to sum the squares of the integers from n=1 to 10. In the old Python, I'd write sum(n**2 for n in range(1, 11)), but with the brave new world of maths symbols, I'd like to write this: http://timmurphy.org/examples/summation_large.jpg How do I enter that, and what text editor should I use? You have a point. Blindly following mathematical notation will not work, because mathematics often enough uses positional clues that will be very hard to incorparate in a programming language. Two completely separate questions 1. Symbols outside of US-104-keyboard/ASCII used for python functions/constants 2. Non-linear math notation It goes back not just to the first programming languages but to Turing's paper that what a mathematician can do on 2-d paper can be done on a 1-d 'tape'. IOW conflating 1 and 2 is not even a poor strawman argument -- Its only 1 that anyone is talking about. The comparison with APL which had/has at least some pretensions to being mathematics and also simultaneously being a programming language are more appropriate So adding to my earlier list: Yes APL is a good example to learn mistakes from - being before its time/technology - taking a good idea too far - assuming that I understand clearly implies so do others - not taking others' good ideas seriously Structured programming constructs were hardly known in 1960 when APL was invented. 10 years down they were the rage. APL ignored them -- to its own detriment On Tue, 25 Mar 2014 11:38:38 +0100, Antoon Pardon wrote: On 25-03-14 10:54, Chris Angelico wrote: On Tue, Mar 25, 2014 at 8:43 PM, Antoon Pardon I thought programs were read more than written. So if writing is made a bit more problematic but the result is more readable because we are able to use symbols that are already familiar from other contexts, I would say it is worth it. It's a matter of extents. If code is read ten times for every time it's written, making it twenty times harder to write and a little bit easier to read is still a bad tradeoff. Also: To what extent IS that symbol familiar from some other context? Are you using Python as a programming language, or should you perhaps be using a mathematical front-end? Not everything needs to perfectly match what anyone from any other context will expect. This is, first and foremost, a *programming* language. So? We do use + -, so why shouldn't we use × for multiplication. I can't find × on my keyboard! Then use an editor that allows you to configure it, so you can easily use it. That's the kind of advice that is often enough given here if some python feature is hard for the tools someone is using. So why should it be different now? But often enough languages tried to use the symbols that were available to them. Now that more are, I see little reason for avoiding there use. I am reminded that when Unix first came out, some of both the early adoption as well as the early pooh-pooh-ing was around the novelty/stupidity of using lower-case in programming -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
In article mailman.8511.1395743071.18130.python-l...@python.org,
Antoon Pardon antoon.par...@rece.vub.ac.be wrote:
Come on. The problem isn't that both set and dictionary literal use
braces. That doesn't seem to be a problem in python3. The only question
was what should {} represent and how do we get an empty collection of
the other kind. If {} had been an empty set, dict() could have been
used for an empty dictionary is {:} had been unacceptable.
By analogy to tuples, it could have been {,}.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
In article lgquvt$b7t$1...@speranza.aioe.org,
Mark H Harris harrismh...@gmail.com wrote:
On 3/24/14 10:51 PM, Chris Angelico wrote:
Supporting both may look tempting, but you effectively create two ways
of spelling the exact same thing; it'd be like C's trigraphs. Do you
know what ??= is,
This was a fit for me, back in the day IBM (system36 system38). When
we started supporting the C compiler (ha!) and non of our 5250 terminals
could provide the C punctuation we take for granted today--- so we
invented tri-graphs for { and } and others. It was a hoot.
Our ASR-33s didn't have { and }, so we used \( and \). To be honest, I
don't remember if the c compiler understood those, or if it was mapped
at the tty driver level.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
In article lgr5pq$olp$1...@speranza.aioe.org, Mark H Harris harrismh...@gmail.com wrote: (we're on one tiny planet, you know?) Speak for yourself. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 11:07 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
On 25-03-14 12:12, Chris Angelico wrote:
On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon
antoon.par...@rece.vub.ac.be wrote:
No they didn't have to. With the transition to python3, the developers
could have opted for empty braces to mean an empty set. And if they
wanted a literal for an empty dictionary, they might have chosen {:}.
Backward-compatibility was already broken so that wasn't an argument.
Python 3.0 didn't just say to Hades with backward compatibility. The
breakage was only in places where it was deemed worthwhile. Changing
the meaning of {} would have only small benefit and would potentially
break a LOT of programs, so the devs were right to not do it.
More programs than those who broke because print was now a function?
Do you think it would have been so problamatic that it couldn't have
been handled by '2to3'?
It makes the same notation mean different things, in ways that are
hard to render clearly. You can write a Py3 program and put this at
the top for Py2:
try:
input = raw_input
range = xrange
except NameError:
# We're running on Python 3
pass
But you can't do the same for braces. You'd have to eschew *both*
literal-ish notations and use explicit constructors everywhere. Not
clean.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
In article 281c8ce1-4f03-4e93-b5cd-d45b85e89...@googlegroups.com, Rustom Mody rustompm...@gmail.com wrote: And Chris is right in (rephrasing) we may have unicode-happy OSes and languages. We cant reasonably have unicode-happy keyboards. [What would a million-key keyboard look like? Lets leave the cost aside...] In a true unicode environment, the input device may be nothing like our current keyboards. Star Trek has been amazingly accurate about it's predictions of the future. Doors that open automatically as you approach them are now routine. One thing they messed up on was mobile devices; they assumed tricorders and communicators would be separate devices, when in reality our phones now perform both functions. Today's 3-d printers are giving replicators a run for their money. Some people still get bent out of shape when a white man kisses a black woman, but we're working on that. When's the last time you saw somebody typing commands to a computer on Star Trek? -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 4:08:38 PM UTC+5:30, Antoon Pardon wrote: So? We do use + -, so why shouldn't we use × for multiplication. Would such a use already indicate I should use a mathematical front-end? When a programming language is borrowing concepts from mathematics, I see no reason not to borrow the symbols used too. Well... Matters of taste are personal, touchy-feely things and not easily explainable. Some of mine: * for multiply does not bother me; ** for power for some reason does. Even though the only standard math notation is non-linear and is off-limits 'and' bothers me slightly (maybe because I was brought up on Pascal?) '' less (and then C) ∧ is of course best (I am a Dijkstra fan) [But then Dijkstra would probably roll over and over in his grave at short-circuit 'and'. Non-commutative?!?! Blasphemy!] ÷ for some reason seems inappropriate (some vague recollection that its an only English; Europeans dont use it??) And if we had hyphen '‐' distinguished from minus '-' then we could have lispish names like call‐with‐current‐continuation properly spelt. And then generations of programmers will thank us for increasing their debugging overtime!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 13:45, Chris Angelico wrote: It makes the same notation mean different things, in ways that are hard to render clearly. You can write a Py3 program and put this at the top for Py2: try: input = raw_input range = xrange except NameError: # We're running on Python 3 pass But you can't do the same for braces. You'd have to eschew *both* literal-ish notations and use explicit constructors everywhere. Not clean. What about it, is not clean? I understand that you prefer it how it worked out. That is fine by me. But that doesn't make the alternative unclean. Is having to write set() unclean somehow when you need an empty set? I wouldn't think so. So I see no reason why having to write dict() when you need an empty dictionary wouldn't be clean. Nor would it be unclean, when you have to write somethings a bit differently when you want your program to be compatible both with python2 and python3. You will also need to prefix all your (unicode) strings with u and all your byte strings with b. And probably some more stuff if you want to avoid some pitfalls. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 6:15:16 PM UTC+5:30, Chris Angelico wrote:
On Tue, Mar 25, 2014 at 11:07 PM, Antoon Pardon
On 25-03-14 12:12, Chris Angelico wrote:
On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon
No they didn't have to. With the transition to python3, the developers
could have opted for empty braces to mean an empty set. And if they
wanted a literal for an empty dictionary, they might have chosen {:}.
Backward-compatibility was already broken so that wasn't an argument.
Python 3.0 didn't just say to Hades with backward compatibility. The
breakage was only in places where it was deemed worthwhile. Changing
the meaning of {} would have only small benefit and would potentially
break a LOT of programs, so the devs were right to not do it.
More programs than those who broke because print was now a function?
Do you think it would have been so problamatic that it couldn't have
been handled by '2to3'?
It makes the same notation mean different things, in ways that are
hard to render clearly. You can write a Py3 program and put this at
the top for Py2:
try:
input = raw_input
range = xrange
except NameError:
# We're running on Python 3
pass
But you can't do the same for braces. You'd have to eschew *both*
literal-ish notations and use explicit constructors everywhere. Not
clean.
What you are answering (2) is somewhat different from what Anton is asking (1).
1. Use a tool (2to3 inspired) to help move programs to the the new lexicon
2. Use 2to3 to (help) write code that is backward-compatible
It is an invariable given that when heavily compatible code is desired, the
programmer gets the worst of all worlds
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 11:35 PM, Roy Smith r...@panix.com wrote: When's the last time you saw somebody typing commands to a computer on Star Trek? That's more like what comes up in Cars 2. It's voice activated... but then, everything is these days! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: advice on sub-classing multiprocessing.Process and multiprocessing.BaseManager
ChrisA - I wasn't really asking is multiprocessing appropriate? but whether there was a cleaner way to subclass multiprocessing.BaseManager() to use a subclass of Process(). I can believe the answer is No, but thought I'd ask. I've never subclassed BaseManager like this. It might be simpler to spin off one or more workers and not have them do any network communication at all; that way, you don't need to worry about the cache. Set up a process tree with one at the top doing only networking and process management (so it's always fast), and then use a multiprocessing.Queue or somesuch to pass info to a subprocess and back. Then your global connection state is all stored within the top process, and none of the others need care about it. You might have a bit of extra effort to pass info back to the parent rather than simply writing it to the connection, but that's a common requirement in other areas (eg GUI handling - it's common to push all GUI manipulation onto the main thread), so it's a common enough model. But if subclassing and tweaking is the easiest way, and if you don't mind your solution being potentially fragile (which subclassing like that is), then you could look into monkey-patching Process. Inject your code into it and then use the original. It's not perfect, but it may turn out easier than the subclass everything technique. ChrisA Thanks, I agree that restricting network communications to a parent process would be a good recommended solution, but it's hard to enforce and easy to forget such a recommendation. It seems better to provide lightweight library-specific subclasses of Process (and Pool) and explaining why they should be used. This library (pyepics) already does similar things for interaction with other libraries (notably providing decorators to avoid issues with wxPython). Monkey-patching multiprocessing.Process seems more fragile than subclassing it. It turned out that multiprocessing.pool.Pool was also very easy to subclass. But cleanly subclassing the Managers in multiprocessing.managers look much harder. I'm not sure if this is intentional or not, or if it should be filed as an issue for multiprocessing. For now, I'm willing to say that the multiprocessing managers are not yet available with the pyepics library. Thanks again, --Matt -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 08:21:19 -0400, Roy Smith wrote:
In article mailman.8511.1395743071.18130.python-l...@python.org,
Antoon Pardon antoon.par...@rece.vub.ac.be wrote:
Come on. The problem isn't that both set and dictionary literal use
braces. That doesn't seem to be a problem in python3. The only question
was what should {} represent and how do we get an empty collection of
the other kind. If {} had been an empty set, dict() could have been
used for an empty dictionary is {:} had been unacceptable.
By analogy to tuples, it could have been {,}.
An empty tuple is (), not (,). {,} is just making up random syntax almost
unrelated to anything else. One might as well used {?} or {+}.
If Python 3 had introduced {} to mean the empty set, I *guarantee* that
right now people would be arguing that Python 3 could have used {} for
the empty dict, and used set() for the empty set -- and very likely the
same people now arguing the opposite.
Yes, Python could have changed the meaning of {} to mean the empty set.
But you know what? The empty set is not that important. Sets are not
fundamental to Python. Python didn't even have sets until 2.3, and at
first they were just a standard library module, not even built-in. Dicts,
on the other hand, are fundamental to Python. They are used everywhere.
Python is, in a very real sense, built on dicts, not sets. You can
implement sets starting from dicts, but not the other way around: dicts
are more fundamental than sets.
I'm sure it is awfully impressive that mathematicians can derive the laws
of integer maths starting only from the empty set ∅, but as far as
programming goes that's not a very useful thing. Dicts are much more
important, and they are much more commonly used.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 13:53, Rustom Mody wrote: On Tuesday, March 25, 2014 4:08:38 PM UTC+5:30, Antoon Pardon wrote: So? We do use + -, so why shouldn't we use × for multiplication. Would such a use already indicate I should use a mathematical front-end? When a programming language is borrowing concepts from mathematics, I see no reason not to borrow the symbols used too. Well... Matters of taste are personal, touchy-feely things and not easily explainable. Some of mine: * for multiply does not bother me; ** for power for some reason does. Even though the only standard math notation is non-linear and is off-limits 'and' bothers me slightly (maybe because I was brought up on Pascal?) '' less (and then C) ∧ is of course best (I am a Dijkstra fan) [But then Dijkstra would probably roll over and over in his grave at short-circuit 'and'. Non-commutative?!?! Blasphemy!] ÷ for some reason seems inappropriate (some vague recollection that its an only English; Europeans dont use it??) It doesn't bother me. IIRC in primary school before fractions were introduced, a colon was used to indicate division. And if we had hyphen '‐' distinguished from minus '-' then we could have lispish names like call‐with‐current‐continuation properly spelt. And then generations of programmers will thank us for increasing their debugging overtime!! Sure we could argue some partciculars. Personnaly I would prefer an up-arrow for exponentiation. IMO the advantage would be mainly in allowing more disambiguity. So that if you as a programmer think about something as an operator, you are not obligated to somehow force it into the mold of + - * / % //. If → would have been used for attribute access, then we could just write 5→to_bytes(4, little) without having to consider that the lexer would try to interpret it as a floating point. And maybe ⤚ could have been used for concatenation. Which would mean that if you had a class whose instances could both be added and concatenated, you could implement both as an operator. Finally, I think I would prefer the middle dot ⸱ for lispish names so we would have call⸱with⸱current⸱continuation. -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano:
On Tue, 25 Mar 2014 03:26:26 -0700, Jean Dubois wrote:
I'm confused by the behaviour of the following python-script I wrote:
#!/usr/bin/env python
#I first made a data file 'test.dat' with the following content
#1.0 2 3
#4 5 6.0
#7 8 9
import numpy as np
lines=[line.strip() for line in open('test.dat')]
#convert lines-list to numpy-array
array_lines=np.array(lines)
#fetch element at 2nd row, 2nd column:
print array_lines[1, 1]
When running the script I always get the following error: IndexError:
invalid index
Can anyone here explain me what I am doing wrong and how to fix it?
Yes. Inspect the array by printing it, and you'll see that it is a one-
dimensional array, not two, and the entries are strings:
py import numpy as np
py # simulate a text file
... data = 1.0 2 3
... 4 5 6.0
... 7 8 9
py lines=[line.strip() for line in data.split('\n')]
py # convert lines-list to numpy-array
... array_lines = np.array(lines)
py print array_lines
['1.0 2 3' '4 5 6.0' '7 8 9']
The interactive interpreter is your friend! You never need to guess what
the problem is, Python has powerful introspection abilities, one of the
most powerful is also one of the simplest: print. Another powerful tool
in the interactive interpreter is help().
So, what to do about it? Firstly, convert your string read from a file
into numbers, then build your array. Here's one way:
py values = [float(s) for s in data.split()]
py print values
[1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]
py array_lines = np.array(values)
py array_lines = array_lines.reshape(3, 3)
py print array_lines
[[ 1. 2. 3.]
[ 4. 5. 6.]
[ 7. 8. 9.]]
Dear Steve,
Thanks for answering my question but unfortunately now I'm totally
confused.
Above I see parts from different programs which I can't
assemble together to one working program (I really tried hard).
Can I tell from your comment I shouldn't use numpy?
I also don't see how to get the value an element specified by (row,
column) from a numpy_array like array_lines in my original code
All I need is a little python-example reading a file with e.g. three lines
with three numbers per line and putting those numbers as floats in a
3x3-numpy_array, then selecting an element from that numpy_array using
it's row and column-number.
thanks in advance and kind regards,
jean
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Wed, Mar 26, 2014 at 12:43 AM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: It doesn't bother me. IIRC in primary school before fractions were introduced, a colon was used to indicate division. The way I learned it, a colon was for a ratio, and a horizontal line was for a fraction. Both of them effectively indicate division, but with a distinct difference. If you have four red objects and two blue ones, the ratio of red to blue is 4 : 2 or 2 : 1, but the fraction (proportion) that are red is 4 / 6 or 2 / 3. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Wed, Mar 26, 2014 at 12:07 AM, Rustom Mody rustompm...@gmail.com wrote: What you are answering (2) is somewhat different from what Anton is asking (1). 1. Use a tool (2to3 inspired) to help move programs to the the new lexicon 2. Use 2to3 to (help) write code that is backward-compatible It is an invariable given that when heavily compatible code is desired, the programmer gets the worst of all worlds That is true. But writing cross-compatible code IS important, and that means that backward compatibility is still important, and that breaking it is a cost - which was my original point. Other non-backward-compatible changes at 3.0 are not justification to arbitrarily change the meanings of syntactic elements. Don't forget, even if you're not writing a single file that gets executed unmodified on two versions, you still have to worry about your brain changing gear. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: advice on sub-classing multiprocessing.Process and multiprocessing.BaseManager
On Wed, Mar 26, 2014 at 12:34 AM, matt.newvi...@gmail.com wrote: Monkey-patching multiprocessing.Process seems more fragile than subclassing it. It turned out that multiprocessing.pool.Pool was also very easy to subclass. But cleanly subclassing the Managers in multiprocessing.managers look much harder. I'm not sure if this is intentional or not, or if it should be filed as an issue for multiprocessing. For now, I'm willing to say that the multiprocessing managers are not yet available with the pyepics library. Subclassing is actually more fragile than you might think. As you've found, you need to fidget with more and more classes to make your change stick, and also, any small change to implementation details in the superclass could suddenly break things. It's not really any safer than monkeypatching, despite all the OO fanatics saying how easy it is to rework by subclassing. At least when you monkeypatch, you *know* you're fiddling with internals. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 25-03-14 14:36, Steven D'Aprano wrote:
On Tue, 25 Mar 2014 08:21:19 -0400, Roy Smith wrote:
In article mailman.8511.1395743071.18130.python-l...@python.org,
Antoon Pardon antoon.par...@rece.vub.ac.be wrote:
Come on. The problem isn't that both set and dictionary literal use
braces. That doesn't seem to be a problem in python3. The only question
was what should {} represent and how do we get an empty collection of
the other kind. If {} had been an empty set, dict() could have been
used for an empty dictionary is {:} had been unacceptable.
By analogy to tuples, it could have been {,}.
An empty tuple is (), not (,). {,} is just making up random syntax almost
unrelated to anything else. One might as well used {?} or {+}.
If Python 3 had introduced {} to mean the empty set, I *guarantee* that
right now people would be arguing that Python 3 could have used {} for
the empty dict, and used set() for the empty set -- and very likely the
same people now arguing the opposite.
Sure and other people would have defended that choice and very likely
the same people that are defending the current choice now. What is
your point?
Yes, Python could have changed the meaning of {} to mean the empty set.
But you know what? The empty set is not that important. Sets are not
fundamental to Python. Python didn't even have sets until 2.3, and at
first they were just a standard library module, not even built-in. Dicts,
on the other hand, are fundamental to Python. They are used everywhere.
Python is, in a very real sense, built on dicts, not sets. You can
implement sets starting from dicts, but not the other way around: dicts
are more fundamental than sets.
Fine, dicts are more fundamental. I just don't see that as such a big
argument against using a different literal for the empty dictionary
than was used in python2 and using {} to indicate the empty set. I
would have preferred it that way, but I don't consider it a big deal.
I just consider the arguments weak for those who seem to argue that
using {} for an empty dictionary in python3 was as good as unavoidable.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 7:26:47 PM UTC+5:30, Chris Angelico wrote: On Wed, Mar 26, 2014 at 12:43 AM, Antoon Pardon It doesn't bother me. IIRC in primary school before fractions were introduced, a colon was used to indicate division. The way I learned it, a colon was for a ratio, and a horizontal line was for a fraction. Both of them effectively indicate division, but with a distinct difference. If you have four red objects and two blue ones, the ratio of red to blue is 4 : 2 or 2 : 1, but the fraction (proportion) that are red is 4 / 6 or 2 / 3. http://www.unicode.org/mail-arch/unicode-ml/y2012-m07/0053.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 7:13:09 PM UTC+5:30, Antoon Pardon wrote: On 25-03-14 13:53, Rustom Mody wrote: On Tuesday, March 25, 2014 4:08:38 PM UTC+5:30, Antoon Pardon wrote: So? We do use + -, so why shouldn't we use × for multiplication. Would such a use already indicate I should use a mathematical front-end? When a programming language is borrowing concepts from mathematics, I see no reason not to borrow the symbols used too. Well... Matters of taste are personal, touchy-feely things and not easily explainable. Some of mine: * for multiply does not bother me; ** for power for some reason does. Even though the only standard math notation is non-linear and is off-limits 'and' bothers me slightly (maybe because I was brought up on Pascal?) '' less (and then C) ∧ is of course best (I am a Dijkstra fan) [But then Dijkstra would probably roll over and over in his grave at short-circuit 'and'. Non-commutative?!?! Blasphemy!] ÷ for some reason seems inappropriate (some vague recollection that its an only English; Europeans dont use it??) It doesn't bother me. IIRC in primary school before fractions were introduced, a colon was used to indicate division. And if we had hyphen '‐' distinguished from minus '-' then we could have lispish names like call‐with‐current‐continuation properly spelt. And then generations of programmers will thank us for increasing their debugging overtime!! Sure we could argue some partciculars. Personnaly I would prefer an up-arrow for exponentiation. Ok IMO the advantage would be mainly in allowing more disambiguity. So that if you as a programmer think about something as an operator, you are not obligated to somehow force it into the mold of + - * / % //. If → would have been used for attribute access, then we could just write Nice 5→to_bytes(4, little) without having to consider that the lexer would try to interpret it as a floating point. And maybe ⤚ could have been used for concatenation. Which would mean that Super! Anything but a (randomly overloaded) +! if you had a class whose instances could both be added and concatenated, you could implement both as an operator. Finally, I think I would prefer the middle dot ⸱ for lispish names so we would have call⸱with⸱current⸱continuation. A bit unreadable out here but not too bad -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 08:35:02 -0400, Roy Smith wrote: In article 281c8ce1-4f03-4e93-b5cd-d45b85e89...@googlegroups.com, Rustom Mody rustompm...@gmail.com wrote: And Chris is right in (rephrasing) we may have unicode-happy OSes and languages. We cant reasonably have unicode-happy keyboards. [What would a million-key keyboard look like? Lets leave the cost aside...] In a true unicode environment, the input device may be nothing like our current keyboards. I doubt it. I expect that they will be based on our current keyboards. Star Trek has been amazingly accurate about it's predictions of the future. O_o Doors that open automatically as you approach them are now routine. It's very easy to predict things that have already happened. Star Trek was created in 1966. The electric automatic door was invented in 1954 by Lew Hewitt and Dee Horton. (Well, actually the first automatic door was built in the 1st century CE by Heron of Alexandra, but that's another story.) Electric doors may be common in some commercial premises, such as shopping centres and some office buildings, but I wouldn't call them routine. One thing they messed up on was mobile devices; they assumed tricorders and communicators would be separate devices, when in reality our phones now perform both functions. Today's 3-d printers are giving replicators a run for their money. Today's 3D printers are to replicators what a stone axe is to a full wood- working tool shop. Some people still get bent out of shape when a white man kisses a black woman, but we're working on that. When's the last time you saw somebody typing commands to a computer on Star Trek? 1986, when I last saw Star Trek IV. The Star Trek universe also predicts that money will be obsolete. How's that prediction working out? -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Wed, Mar 26, 2014 at 1:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Mar 2014 08:35:02 -0400, Roy Smith wrote: In article 281c8ce1-4f03-4e93-b5cd-d45b85e89...@googlegroups.com, Rustom Mody rustompm...@gmail.com wrote: And Chris is right in (rephrasing) we may have unicode-happy OSes and languages. We cant reasonably have unicode-happy keyboards. [What would a million-key keyboard look like? Lets leave the cost aside...] In a true unicode environment, the input device may be nothing like our current keyboards. I doubt it. I expect that they will be based on our current keyboards. Rule #0 of any voice-activated system: The command word Console MUST summon a terminal window, and make available a keyboard and screen on which to use it. This console MAY demand authentication (via typed password) before operating. I don't know if that's written anywhere, but it ought to be. It should be as fundamental as Asimov's laws of robotics. That one simple rule would improve scifi like Eureka no end. Hey look, we have a rogue AI... CONSOLE!... hey look, we have a rogue AI on a system that's now powered off. Crisis averted, now go solve the problem in a mundane and not very TV-friendly way... Star Trek has been amazingly accurate about it's predictions of the future. O_o I like the Scott Adams take on that. He predicted (in the 1990s) that the future would *not* be like Star Trek, because human reproduction depends on genuine relationships being cheaper/easier than artificial ones. If you could go onto the holodeck and create yourself the perfect (wo)man of your dreams, why would you ever date a real one? The holodeck would be humanity's last invention. When's the last time you saw somebody typing commands to a computer on Star Trek? 1986, when I last saw Star Trek IV. You actually watched it? I got pretty much bored with the series before even finishing TNG. (I'm not 100% sure, but I think I watched every TOS episode.) The Star Trek universe also predicts that money will be obsolete. How's that prediction working out? And it further predicts that, thanks to the invention of the holodeck and the replicator, humanity will lose all sense of purpose and challenge, and will send ships out to go^H^Hgo to places where nobody's yet been, because the entire human race is *bored out of its petty little brain* with nothing exciting left to do. Yup, that's the whole unpublished backstory right there, sorry for the spoilers! (I got this from Scott Adams too. He seems to know his stuff.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 05:53:45 -0700, Rustom Mody wrote: And if we had hyphen '‐' distinguished from minus '-' then we could have lispish names like call‐with‐current‐continuation properly spelt. And then generations of programmers will thank us for increasing their debugging overtime!! :-) Full Unicode support in a language is, alas, a double-edged sword. While it has advantages, it also has disadvantages. py А = 1 py A = А + 1 py assert A == А Traceback (most recent call last): File stdin, line 1, in module AssertionError While I can see the appeal of certain Unicode symbols, I really wouldn't like to have to deal with code that looks like this: x∫2*y+∬e**3∺z≹(x+1)≽y⋝w If I wanted line-noise, I know where to get Perl :-) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Jean Dubois jeandubois...@gmail.com Wrote in message: Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano: py values = [float(s) for s in data.split()] py print values [1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0] py array_lines = np.array(values) py array_lines = array_lines.reshape(3, 3) py print array_lines [[ 1. 2. 3.] [ 4. 5. 6.] [ 7. 8. 9.]] Dear Steve, Thanks for answering my question but unfortunately now I'm totally confused. Above I see parts from different programs which I can't assemble together to one working program (I really tried hard). Can I tell from your comment I shouldn't use numpy? I also don't see how to get the value an element specified by (row, column) from a numpy_array like array_lines in my original code I don't use numpy, but I thought Steven's description was clear enough. Your problem was not the extraction, but the creation of the array. Use print to prove that to yourself. All I need is a little python-example reading a file with e.g. three lines with three numbers per line and putting those numbers as floats in a 3x3-numpy_array, then selecting an element from that numpy_array using it's row and column-number. If your instructor wanted you to copy examples, he would have given you one. First write some code to split and convert each line into floats. You don't even try that in your original. Then do that in a loop. Now you have all the floats in one list or array. I presume that it's two dimensional. Use print to check. If it's not, you'll have to either post process it with a reshape method, or change the way you accumulate it. I can't help with the latter. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, 25 Mar 2014 05:09:20 -0700, Rustom Mody wrote: Two completely separate questions 1. Symbols outside of US-104-keyboard/ASCII used for python functions/constants 2. Non-linear math notation It goes back not just to the first programming languages but to Turing's paper that what a mathematician can do on 2-d paper can be done on a 1-d 'tape'. IOW conflating 1 and 2 is not even a poor strawman argument -- Its only 1 that anyone is talking about. Not so. Mark Harris said: [quote] But what if python had a math symbols extension so that universal mathematics could be written the way we do it on a black|board, er, I mean white|board? I think that's pretty explicit that he's talking about writing mathematical code the way mathematicians write mathematics. Antoon Pardon referred to borrowing the symbols used in mathematics. But the point is that the symbols come with notation: - (minus) can be prefix unary operator or a infix binary operator. ∑ (summation) is a quaternary operator, it takes four arguments: a variable name, a lower limit, an upper limit, and an expression. To be true to the mathematical notation, we ought to write it the way mathematicians do. The thing is, we can't just create a ∑ function, because it doesn't work the way the summation operator works. The problem is that we would want syntactic support, so we could write something like this: p = 2 ∑(n, 1, 10, n**p) This cannot be an ordinary function, because if it were, the n**p expression would be evaluated before passing the result to the function. We want it to delay evaluation, like a list comp: [n**p for n in range(1, 11)] the expression n**p gets evaluated inside the list comp. That cannot be written as a function either: list_comp(n**p, n, range(1, 11)) Mark's idea of a maths blackboard is not ridiculous. That's what Mathematica does. To enter a sum like the above in Mathematica, you can enter: ESC sum ESC Ctrl+$ n=1 Ctrl+% 10 Ctrl+Space n^p to give you the summation 10 ∑ n**p n=1 Obviously this requires a custom editor. https://reference.wolfram.com/mathematica/tutorial/EnteringTwoDimensionalInput.html But Mathematica is a specialist system for doing mathematics, not a general purpose language like Python. Of course one could *write* a Mathematica-like system in Python, and I expect that Sage may even have something like this (if it doesn't, it could) but one shouldn't hammer the specialised round peg of complex mathematical notation into the square peg of a general purpose programming language. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tuesday, March 25, 2014 7:53:23 PM UTC+5:30, Steven D'Aprano wrote: On Tue, 25 Mar 2014 05:53:45 -0700, Rustom Mody wrote: And if we had hyphen '‐' distinguished from minus '-' then we could have lispish names like call‐with‐current‐continuation properly spelt. And then generations of programmers will thank us for increasing their debugging overtime!! :-) Full Unicode support in a language is, alas, a double-edged sword. While it has advantages, it also has disadvantages. py А = 1 py A = А + 1 py assert A == А Traceback (most recent call last): AssertionError Even with 'good' ol ASCII giving enough trouble between O and 0, 1 and l, we certainly dont want more such headaches! In apps, a serious consideration of unicode entails a cycle of i18n and l10n. The l10n for programming languages is arguably harder -- if python is 'localized' to some (human) language L, maybe all the builtins should be also translated? And whats the use of that without full translation of the docs? Its not a pleasing thought... Something intermediate needs to be found... Some thoughts (quite half cooked): 1. Human -- 'natural' -- languages and math are not in the same category If Cyrillic A gets in Roman probably shouldn't. 2. There needs to be some intermediate binding time -- eg when the system is installed -- when suitable char-tables are set up. Case-in-point: Many folks in haskell-land have wanted to replace the '\' with the 'λ'. This has not worked out so far because λ belongs to the same unicode class as other lower-case letters. So since this is possible: Prelude let λ = 1 Prelude λ 1 Prelude the other more-natural-to-haskell usage is precluded. So these classes need to be changeable and late-bindable. Not as late as runtime but later than build-time. Probably same as the choice of locales on a system While I can see the appeal of certain Unicode symbols, I really wouldn't like to have to deal with code that looks like this: x∫2*y+∬e**3∺z≹(x+1)≽y⋝w If I wanted line-noise, I know where to get Perl :-) Yes... neither Perl nor Cobol is pleasant -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
On Tue, 25 Mar 2014 06:47:23 -0700, Jean Dubois wrote: [...] Thanks for answering my question but unfortunately now I'm totally confused. Above I see parts from different programs which I can't assemble together to one working program (I really tried hard). Can I tell from your comment I shouldn't use numpy? No, you misunderstood me. I never suggested that you avoid numpy. If you read my code, I use numpy. That's the import numpy as np, and then later I refer to np. What I suggested is that you open up the Python interactive interpreter and use it for experimentation. Not that you avoid numpy! You will use numpy inside the interactive interpreter. Do you know how to start the interactive interpreter? You seem to be using Linux, or maybe Mac. Open a console or xterm window, and type python then press Enter, and the interactive interpreter will start. I also don't see how to get the value an element specified by (row, column) from a numpy_array like array_lines in my original code Once you build the array, you get the element the same way you tried (but failed) earlier: print array_lines[1, 1] will print the element at row 1, column 1. The problem you had before was that you had a one dimensional array, not a two dimensional one. All I need is a little python-example reading a file with e.g. three lines with three numbers per line and putting those numbers as floats in a 3x3-numpy_array, then selecting an element from that numpy_array using it's row and column-number. Yes, I'm sure you do. And you will learn much more by writing this code yourself. You were very, very close with your earlier attempt. In English, you had: * import the numpy module * read the file into a list of text lines * store the text lines in a numpy array * try to print a single item from the array but it failed because the list of lines was only one dimensional. I gave you some code that was very similar: * import the numpy module * fake a text file using a string * split the string into a list of substrings * convert each substring into a number (float) * store the numbers in a numpy array * change the size of the array to turn it from 1D to 2D * print the array Can you identify which part of code goes with each English description? That's your first job. Then identify the parts of code you want to take from my example and put it into your example. Good luck, and have fun! -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Jean Dubois wrote:
Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano:
On Tue, 25 Mar 2014 03:26:26 -0700, Jean Dubois wrote:
I'm confused by the behaviour of the following python-script I wrote:
#!/usr/bin/env python
#I first made a data file 'test.dat' with the following content
#1.0 2 3
#4 5 6.0
#7 8 9
import numpy as np
lines=[line.strip() for line in open('test.dat')]
#convert lines-list to numpy-array
array_lines=np.array(lines)
#fetch element at 2nd row, 2nd column:
print array_lines[1, 1]
When running the script I always get the following error: IndexError:
invalid index
Can anyone here explain me what I am doing wrong and how to fix it?
Yes. Inspect the array by printing it, and you'll see that it is a one-
dimensional array, not two, and the entries are strings:
py import numpy as np
py # simulate a text file
... data = 1.0 2 3
... 4 5 6.0
... 7 8 9
py lines=[line.strip() for line in data.split('\n')]
py # convert lines-list to numpy-array
... array_lines = np.array(lines)
py print array_lines
['1.0 2 3' '4 5 6.0' '7 8 9']
The interactive interpreter is your friend! You never need to guess what
the problem is, Python has powerful introspection abilities, one of the
most powerful is also one of the simplest: print. Another powerful tool
in the interactive interpreter is help().
So, what to do about it? Firstly, convert your string read from a file
into numbers, then build your array. Here's one way:
py values = [float(s) for s in data.split()]
py print values
[1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]
py array_lines = np.array(values)
py array_lines = array_lines.reshape(3, 3)
py print array_lines
[[ 1. 2. 3.]
[ 4. 5. 6.]
[ 7. 8. 9.]]
Dear Steve,
Thanks for answering my question but unfortunately now I'm totally
confused.
Above I see parts from different programs which I can't
assemble together to one working program (I really tried hard).
Can I tell from your comment I shouldn't use numpy?
I also don't see how to get the value an element specified by (row,
column) from a numpy_array like array_lines in my original code
All I need is a little python-example reading a file with e.g. three lines
with three numbers per line and putting those numbers as floats in a
3x3-numpy_array, then selecting an element from that numpy_array using
it's row and column-number.
I'll try, too, but be warned that I'm using the same methology as Steven.
Try to replicate every step in the following exploration.
First let's make sure we start with the same data:
$ cat test.dat
1.0 2 3
4 5 6.0
7 8 9
Then fire up the interactve interpreter:
$ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
import numpy
lines = [line.strip() for line in open(test.dat)]
lines
['1.0 2 3', '4 5 6.0', '7 8 9']
As you can see lines is a list of three strings.
Let's break these strings into parts:
cells = [line.split() for line in lines]
cells
[['1.0', '2', '3'], ['4', '5', '6.0'], ['7', '8', '9']]
We now have a list of lists of strings and you can address individual items
with
cells[1][2]
'6.0'
What happens when pass this list of lists of strings to the numpy.array()
constructor?
a = numpy.array(cells)
a
array([['1.0', '2', '3'],
['4', '5', '6.0'],
['7', '8', '9']],
dtype='|S3')
a[1,2]
'6.0'
It sort of works, but the array entries are strings rather than floating
point numbers. Let's fix that:
a = numpy.array(cells, dtype=float)
a
array([[ 1., 2., 3.],
[ 4., 5., 6.],
[ 7., 8., 9.]])
a[1,2]
6.0
OK, now we can put the previous steps into a script:
$ cat tmp.py
import numpy
cells = [line.split() for line in open(test.dat)]
a = numpy.array(cells, dtype=float)
print a[1, 2]
Run it:
$ python tmp.py
6.0
Seems to work. But reading a 2D array from a file really looks like a common
task -- there should be a library function for that:
$ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
import numpy
numpy.loadtxt(test.dat)
array([[ 1., 2., 3.],
[ 4., 5., 6.],
[ 7., 8., 9.]])
--
https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
On 3/25/14 9:42 AM, Dave Angel wrote:
All I need is a little python-example reading a file with e.g. three lines
with three numbers per line and putting those numbers as floats in a
3x3-numpy_array, then selecting an element from that numpy_array using
it's row and column-number.
If your instructor wanted you to copy examples, he would have
given you one.
{ouch}
Give them a toad they'll have warts all day; teach them to eat a toad
they'll never have warts again... or something like that.
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On 3/25/14 7:36 AM, Roy Smith wrote:
(we're on one tiny planet, you know?)
Speak for yourself.
Are others on this list, um, on a different planet? Or, am I the only
one who knows its tiny?
Yes, we're on a tiny planet revolving around a speck of a star, at the
edge of an insignificant galaxy ...
{not that it matters}
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to clear all content in a Tk()
What about this: Put a Frame() inside the root: `frame = Frame(root)`. This frame will be the only immediate child of root. Everything else will be put inside the frame. When you need to clear the root, call `frame.destroy()`. This will destroy `frame` and all its children. You will need to recreate the frame, but not the root. 2014-03-24 17:30 GMT-03:00 eneskri...@gmail.com: I have this program, and since I want to change stuff dynamically, I want to fully clear the root = Tk(), without deleting it. Is there a way to do so? -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Tue, Mar 25, 2014 at 9:05 AM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: On Tue, Mar 25, 2014 at 4:14 PM, Mark H Harris harrismh...@gmail.com wrote: Π¹ = pi That's good! (Although typing Π¹ quicker than pi is majorly pushing it. It don't think that's good. The lower-case letter π² should be used. The upper-case letter is used for a product, although unicode dedicates a separate character for the purpose: ∏³. I often see Americans, especially, confuse upper and lower-case letters in symbols (KM for km, L for l etc). “L” is actually valid, and so is “l”. This happens mainly because humans (and computers) tend to write “1 l” (one liter, one-ell) in a way that makes it harder to distinguish (becoming eleven or ell-ell), especially if you don’t include the space (which is invalid). On Tue, Mar 25, 2014 at 9:23 AM, Chris Angelico ros...@gmail.com wrote: If you can type a capital ∏³, you can type a lower-case π², unless there's something very weird going on. Nitpick time! (because we all love it so much!) Π¹ = U+03A0 GREEK CAPITAL LETTER PI π² = U+03C0 GREEK SMALL LETTER PI ∏³ = U+220F N-ARY PRODUCT “If you can type an N-ARY PRODUCT, you can type a GREEK SMALL LETTER PI, unless there’s something very weird going on.” …like, the user is in the past and is using ISO 8859-7 (instead of a 21st-century encoding, like UTF-8). An encoding which has support for Π¹ and π², but not for ∏³… (of course, this assumes that, if we add those new characters into python, we allow any encoding, somehow.) That’s not too weird, other than the ancient encoding being used. (though that’s a bit less weird on Windows, but that’d be Windows-1253.) Oh: and speaking of fancy Unicode characters that are worthless ~duplicates, spot the difference here: µ μ If you are lucky enough (and, luckiness may involve reading this e-mail in Helvetica (not Neue though) on a Mac), you can clearly see that they are different. If you are using a font that does not differentiate them, you may think they’re the same. If you ask some intelligent software (like `unicodedata.name()` in Python), you’ll quickly find out the first is MICRO SIGN, and the other is GREEK SMALL LETTER MU. Such craziness is what makes Unicode Unicode. -- Chris “Kwpolska” Warrick http://kwpolska.tk PGP: 5EAAEA16 stop html mail | always bottom-post | only UTF-8 makes sense -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On Tuesday, 25 March 2014 10:16:20 UTC-8, rbor...@gmail.com wrote: On Sunday, 23 March 2014 18:22:54 UTC-8, Rhodri James wrote: On Sun, 23 Mar 2014 17:09:09 -, rborol...@gmail.com wrote: Hi Everybody actually i want to run python on web browser. Actually you don't. You want to run Python on a web server, which fortunately is a good deal easier. I downloaded python and installed but i'm not able to run it in browser but it running using command prompt. so i trying to install mod_wsgi 3.4. So i downloaded precompiled version mod_wsgi-3.4.ap22.win32-py2.6 and copied mod_wsgi.so file to C:\wamp\bin\apache\Apache2.2.11\modules after i'm trying to run .\configure on path C:\Documents and Settings\Rahul\Desktop\mod_wsgi-3.4.ap22.win32-py2.6 but it giving me error that .\configure is not recognized as internal or external command. So please suggest me what can i do for that, i'm so beginner to python and installing and configuring modules for apache. The .\configure thing is for Linux installations using autotools; it's not going to work on Windows. I don't run Apache on Windows, so I'm just guessing from the documentation here, but the mod_wsgi Installation on Windows page says to follow the instructions for loading mod_wsgi in the Quick Installation Guide. The Quick Installation Guide page has instructions for editing the Apache config files. No mention of running .\configure -- why are you doing that? Try just editing the config files as the documentation suggests and see if that works. -- Rhodri James *-* Wildebeest Herder to the Masses Thanks for your comment but i also edited httpd.conf file then my wamp not running LoadModule php5_module c:/wamp/bin/php/php5.3.0/php5apache2_2.dll This line i added on line 128 but nothing. Wampserver showing yellow. I'm not getting what happening. I'm doing as per suggested in documentation Thanks And again if i'm removing this line then wampserver works properly -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On Sunday, 23 March 2014 18:22:54 UTC-8, Rhodri James wrote: On Sun, 23 Mar 2014 17:09:09 -, rborol...@gmail.com wrote: Hi Everybody actually i want to run python on web browser. Actually you don't. You want to run Python on a web server, which fortunately is a good deal easier. I downloaded python and installed but i'm not able to run it in browser but it running using command prompt. so i trying to install mod_wsgi 3.4. So i downloaded precompiled version mod_wsgi-3.4.ap22.win32-py2.6 and copied mod_wsgi.so file to C:\wamp\bin\apache\Apache2.2.11\modules after i'm trying to run .\configure on path C:\Documents and Settings\Rahul\Desktop\mod_wsgi-3.4.ap22.win32-py2.6 but it giving me error that .\configure is not recognized as internal or external command. So please suggest me what can i do for that, i'm so beginner to python and installing and configuring modules for apache. The .\configure thing is for Linux installations using autotools; it's not going to work on Windows. I don't run Apache on Windows, so I'm just guessing from the documentation here, but the mod_wsgi Installation on Windows page says to follow the instructions for loading mod_wsgi in the Quick Installation Guide. The Quick Installation Guide page has instructions for editing the Apache config files. No mention of running .\configure -- why are you doing that? Try just editing the config files as the documentation suggests and see if that works. -- Rhodri James *-* Wildebeest Herder to the Masses Thanks for your comment but i also edited httpd.conf file then my wamp not running LoadModule php5_module c:/wamp/bin/php/php5.3.0/php5apache2_2.dll This line i added on line 128 but nothing. Wampserver showing yellow. I'm not getting what happening. I'm doing as per suggested in documentation Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On Sunday, 23 March 2014 13:07:28 UTC-8, tad na wrote: On Sunday, March 23, 2014 12:33:02 PM UTC-5, tad na wrote: On Sunday, March 23, 2014 12:09:09 PM UTC-5, rbor...@gmail.com wrote: Hi Everybody actually i want to run python on web browser. I downloaded python and installed but i'm not able to run it in browser but it running using command prompt. so i trying to install mod_wsgi 3.4. So i downloaded precompiled version mod_wsgi-3.4.ap22.win32-py2.6 and copied mod_wsgi.so file to C:\wamp\bin\apache\Apache2.2.11\modules after i'm trying to run .\configure on path C:\Documents and Settings\Rahul\Desktop\mod_wsgi-3.4.ap22.win32-py2.6 but it giving me error that .\configure is not recognized as internal or external command. So please suggest me what can i do for that, i'm so beginner to python and installing and configuring modules for apache. Thanks Rahul To set up a web browser: 1.open a dos window 2.navigate to dir you want served 3.type python -m SimpleHTTPServer . 4. open browser and type http://localhost:/ It's saying unable to connect to localhost -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On Sunday, 23 March 2014 19:35:19 UTC-8, Chris Angelico wrote: On Mon, Mar 24, 2014 at 2:28 PM, Mark H Harris harrismh...@gmail.com wrote: Anyway, the PSF runs python (the interpreter) from a web server (I can access the python interpreter from my browser from the PSF site). How is that done simply, is possibly what the OP wants to know (me too). That's a much MUCH harder thing to do than running Python code in your web server, because of trust issues. I don't know how it's set up, but there'll be something in there to protect the server against malicious or accidental insanity (spinning with while True: pass, trying to read/write files, trying to execute commands, using up all of RAM with x = []\nwhile True: x.append(1), etc, etc, etc). That's actually a very hard problem to solve, not something where you can just say Here, this is how to run Python via a browser. ChrisA LoadModule wsgi_module modules/mod_wsgi.so This line also i added but then also same problem -- https://mail.python.org/mailman/listinfo/python-list
unicode as valid naming symbols
greetings, I would like to create a lamda as follows: √ = lambda n: sqrt(n) On my keyboard mapping the problem character is alt-v which produces the radical symbol. When trying to set the symbol as a name within the name-space gives a syntax error: from math import sqrt √ = lambda n: sqrt(n) SyntaxError: invalid character in identifier however this works: λ = lambda n: sqrt(n) λ(2) 1.4142135623730951 The question is which unicode(s) are capable of being proper name characters, and which ones are off-limits, and why? marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Op dinsdag 25 maart 2014 17:12:12 UTC+1 schreef Peter Otten:
Jean Dubois wrote:
Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano:
On Tue, 25 Mar 2014 03:26:26 -0700, Jean Dubois wrote:
I'm confused by the behaviour of the following python-script I wrote:
#!/usr/bin/env python
#I first made a data file 'test.dat' with the following content
#1.0 2 3
#4 5 6.0
#7 8 9
import numpy as np
lines=[line.strip() for line in open('test.dat')]
#convert lines-list to numpy-array
array_lines=np.array(lines)
#fetch element at 2nd row, 2nd column:
print array_lines[1, 1]
When running the script I always get the following error: IndexError:
invalid index
Can anyone here explain me what I am doing wrong and how to fix it?
Yes. Inspect the array by printing it, and you'll see that it is a one-
dimensional array, not two, and the entries are strings:
py import numpy as np
py # simulate a text file
... data = 1.0 2 3
... 4 5 6.0
... 7 8 9
py lines=[line.strip() for line in data.split('\n')]
py # convert lines-list to numpy-array
... array_lines = np.array(lines)
py print array_lines
['1.0 2 3' '4 5 6.0' '7 8 9']
The interactive interpreter is your friend! You never need to guess what
the problem is, Python has powerful introspection abilities, one of the
most powerful is also one of the simplest: print. Another powerful tool
in the interactive interpreter is help().
So, what to do about it? Firstly, convert your string read from a file
into numbers, then build your array. Here's one way:
py values = [float(s) for s in data.split()]
py print values
[1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]
py array_lines = np.array(values)
py array_lines = array_lines.reshape(3, 3)
py print array_lines
[[ 1. 2. 3.]
[ 4. 5. 6.]
[ 7. 8. 9.]]
Dear Steve,
Thanks for answering my question but unfortunately now I'm totally
confused.
Above I see parts from different programs which I can't
assemble together to one working program (I really tried hard).
Can I tell from your comment I shouldn't use numpy?
I also don't see how to get the value an element specified by (row,
column) from a numpy_array like array_lines in my original code
All I need is a little python-example reading a file with e.g. three lines
with three numbers per line and putting those numbers as floats in a
3x3-numpy_array, then selecting an element from that numpy_array using
it's row and column-number.
I'll try, too, but be warned that I'm using the same methology as Steven.
Try to replicate every step in the following exploration.
First let's make sure we start with the same data:
$ cat test.dat
1.0 2 3
4 5 6.0
7 8 9
Then fire up the interactve interpreter:
$ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
import numpy
lines = [line.strip() for line in open(test.dat)]
lines
['1.0 2 3', '4 5 6.0', '7 8 9']
As you can see lines is a list of three strings.
Let's break these strings into parts:
cells = [line.split() for line in lines]
cells
[['1.0', '2', '3'], ['4', '5', '6.0'], ['7', '8', '9']]
We now have a list of lists of strings and you can address individual items
with
cells[1][2]
'6.0'
What happens when pass this list of lists of strings to the numpy.array()
constructor?
a = numpy.array(cells)
a
array([['1.0', '2', '3'],
['4', '5', '6.0'],
['7', '8', '9']],
dtype='|S3')
a[1,2]
'6.0'
It sort of works, but the array entries are strings rather than floating
point numbers. Let's fix that:
a = numpy.array(cells, dtype=float)
a
array([[ 1., 2., 3.],
[ 4., 5., 6.],
[ 7., 8., 9.]])
a[1,2]
6.0
OK, now we can put the previous steps into a script:
$ cat tmp.py
import numpy
cells = [line.split() for line in open(test.dat)]
a = numpy.array(cells, dtype=float)
print a[1, 2]
Run it:
$ python tmp.py
6.0
Seems to work. But reading a 2D array from a file really looks like a common
task -- there should be a library function for that:
$ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
import numpy
numpy.loadtxt(test.dat)
array([[ 1., 2., 3.],
[ 4., 5., 6.],
[ 7., 8., 9.]])
Thank you very much Peter for this great lesson, you made a lot of things
clear to me.
sincerely
jean
--
https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
Le mardi 25 mars 2014 19:30:34 UTC+1, Mark H. Harris a écrit :
greetings, I would like to create a lamda as follows:
√ = lambda n: sqrt(n)
On my keyboard mapping the problem character is alt-v which produces
the radical symbol. When trying to set the symbol as a name within the
name-space gives a syntax error:
from math import sqrt
√ = lambda n: sqrt(n)
SyntaxError: invalid character in identifier
however this works:
λ = lambda n: sqrt(n)
λ(2)
1.4142135623730951
The question is which unicode(s) are capable of being proper name
characters, and which ones are off-limits, and why?
marcus
'√'.isidentifier()
False
'λ'.isidentifier()
True
'$'.isidentifier()
False
'啕'.isidentifier()
True
'a'.isidentifier()
True
'啕2z'.isidentifier()
True
print(''.isidentifier.__doc__)
S.isidentifier() - bool
Return True if S is a valid identifier according
to the language definition.
cf unicode.org doc
jmf
--
https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Op dinsdag 25 maart 2014 15:42:13 UTC+1 schreef Dave Angel: Jean Dubois jeandubois...@gmail.com Wrote in message: Op dinsdag 25 maart 2014 12:01:37 UTC+1 schreef Steven D'Aprano: py values = [float(s) for s in data.split()] py print values [1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0] py array_lines = np.array(values) py array_lines = array_lines.reshape(3, 3) py print array_lines [[ 1. 2. 3.] [ 4. 5. 6.] [ 7. 8. 9.]] Dear Steve, Thanks for answering my question but unfortunately now I'm totally confused. Above I see parts from different programs which I can't assemble together to one working program (I really tried hard). Can I tell from your comment I shouldn't use numpy? I also don't see how to get the value an element specified by (row, column) from a numpy_array like array_lines in my original code I don't use numpy, but I thought Steven's description was clear enough. Your problem was not the extraction, but the creation of the array. Use print to prove that to yourself. All I need is a little python-example reading a file with e.g. three lines with three numbers per line and putting those numbers as floats in a 3x3-numpy_array, then selecting an element from that numpy_array using it's row and column-number. If your instructor wanted you to copy examples, he would have given you one. please Dave leave that belittling tone behind, there's no instructor whatsoever involved here. I constructed this example myself as I know very well I have to start with little pieces of code first to be able to master larger problems later. I just wanted to figure this example out first, and as I now learned from Peter's marvellous explanation there _is_ an elegant solution in Python to this kind of problem. So if you are irritated by newbie-questions in the future, just neglect them thanks jean -- https://mail.python.org/mailman/listinfo/python-list
Re: python installation on windows
On 25/03/2014 18:17, rborol...@gmail.com wrote: Would you please use the mailing list https://mail.python.org/mailman/listinfo/python-list or read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing double line spacing and single line paragraphs, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 2014-03-25 18:30, Mark H Harris wrote: greetings, I would like to create a lamda as follows: √ = lambda n: sqrt(n) On my keyboard mapping the problem character is alt-v which produces the radical symbol. When trying to set the symbol as a name within the name-space gives a syntax error: from math import sqrt √ = lambda n: sqrt(n) SyntaxError: invalid character in identifier however this works: λ = lambda n: sqrt(n) λ(2) 1.4142135623730951 The question is which unicode(s) are capable of being proper name characters, and which ones are off-limits, and why? It's explained in PEP 3131. Basically, a name should to start with a letter (this has been extended to include Chinese characters, etc) or an underscore. λ is a classified as Lowercase_Letter. √ is classified as Math_Symbol. -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 3/25/14 1:52 PM, wxjmfa...@gmail.com wrote: '√'.isidentifier() False 'λ'.isidentifier() True S.isidentifier() - bool Return True if S is a valid identifier according to the language definition. cf unicode.org doc Excellent, thanks! marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 3/25/14 2:24 PM, MRAB wrote: It's explained in PEP 3131. Basically, a name should to start with a letter (this has been extended to include Chinese characters, etc) or an underscore. λ is a classified as Lowercase_Letter. √ is classified as Math_Symbol. Thanks much! I'll note that for improvements. Any unicode symbol (that is not a number) should be allowed as an identifier. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode?
On Wed, Mar 26, 2014 at 4:24 AM, Chris “Kwpolska” Warrick kwpol...@gmail.com wrote: “If you can type an N-ARY PRODUCT, you can type a GREEK SMALL LETTER PI, unless there’s something very weird going on.” …like, the user is in the past and is using ISO 8859-7 (instead of a 21st-century encoding, like UTF-8). An encoding which has support for Π¹ and π², but not for ∏³… (of course, this assumes that, if we add those new characters into python, we allow any encoding, somehow.) That’s not too weird, other than the ancient encoding being used. Since we opened by discussing Unicode, anyone who's cheating and using an eight-bit character set is, well, cheating. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re:unicode as valid naming symbols
Mark H Harris harrismh...@gmail.com Wrote in message: greetings, I would like to create a lamda as follows: â = lambda n: sqrt(n) On my keyboard mapping the problem character is alt-v which produces the radical symbol. When trying to set the symbol as a name within the name-space gives a syntax error: from math import sqrt â = lambda n: sqrt(n) SyntaxError: invalid character in identifier however this works: λ = lambda n: sqrt(n) λ(2) 1.4142135623730951 The question is which unicode(s) are capable of being proper name characters, and which ones are off-limits, and why? See the official docs http://docs.python.org/3/reference/lexical_analysis.html#identifiers There's also a method on str that'll tell you: isidentifier (). To see such methods, use dir () As for why, you can get a pretty good idea from the reference above, as it lists 12 unicode categories that can be used. You can also look at pep3131 and at Potsdam ' s site. Both links are on the above page. Letters, marks, connectors, and numbers, but not punctuation. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Jean, be aware there is also python tutor list you might like. This is sometimes a tough crowd here. Don't be discouraged. It can be a badge of honor sometimes -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
Mark H Harris harrismh...@gmail.com: Thanks much! I'll note that for improvements. Any unicode symbol (that is not a number) should be allowed as an identifier. I don't know if that's a good idea, but that's how it is in lisp/scheme. Thus, * and 1+ are normal identifiers in lisp and scheme. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On Tue, Mar 25, 2014 at 1:29 PM, Mark H Harris harrismh...@gmail.com wrote: On 3/25/14 2:24 PM, MRAB wrote: It's explained in PEP 3131. Basically, a name should to start with a letter (this has been extended to include Chinese characters, etc) or an underscore. λ is a classified as Lowercase_Letter. √ is classified as Math_Symbol. Thanks much! I'll note that for improvements. Any unicode symbol (that is not a number) should be allowed as an identifier. √ cannot be used in identifiers for the same reasons that + and ~ cannot: identifiers are intended to be alphanumeric. √ is not currently the name of an operator, but who knows what may happen in the future? Python generally follows Annex 31 of the Unicode standard in this regard: http://www.unicode.org/reports/tr31/ -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On Tue, Mar 25, 2014 at 2:48 PM, Marko Rauhamaa ma...@pacujo.net wrote: I don't know if that's a good idea, but that's how it is in lisp/scheme. Thus, * and 1+ are normal identifiers in lisp and scheme. But parsing Lisp is pretty trivial. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] confusion concerning fetching an element in a 2d-array
Jean Dubois jeandubois...@gmail.com Wrote in message: Op dinsdag 25 maart 2014 15:42:13 UTC+1 schreef Dave Angel: If your instructor wanted you to copy examples, he would have given you one. please Dave leave that belittling tone behind, there's no instructor whatsoever involved here. It wasn't my intention to belittle you; I'm sorry. But we do get a lot of people here asking for homework help, and not saying that's what it is. And when it's homework we do better explaining than just writing the code. In fact you only needed to add a line like data= infile.read () to Steven's original to get a complete working example. I constructed this example myself as I know very well I have to start with little pieces of code first to be able to master larger problems later. I just wanted to figure this example out first, and as I now learned from Peter's marvellous explanation there _is_ an elegant solution in Python to this kind of problem. So if you are irritated by newbie-questions in the future, just neglect them Not irritated, just temporarily misguided. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
Roy Smith wrote: Doors that open automatically as you approach them are now routine. Star Trek doors seem to be a bit smarter, though. Captain Kirk never had to stop in front of a door and wait for it to sluggishly slide open. Also the doors never open when you're just walking past and not intending to go through. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: unicode as valid naming symbols
On 2014-03-25 14:29, Mark H Harris wrote: It's explained in PEP 3131. Basically, a name should to start with a letter (this has been extended to include Chinese characters, etc) or an underscore. λ is a classified as Lowercase_Letter. √ is classified as Math_Symbol. Thanks much! I'll note that for improvements. Any unicode symbol (that is not a number) should be allowed as an identifier. It's not just about number'ness: letter = a number = 2 letter.isidentifier() True number.isidentifier() False (letter + number).isidentifier() True -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
On Tue, Mar 25, 2014 at 4:21 PM, Gregory Ewing greg.ew...@canterbury.ac.nzwrote: Roy Smith wrote: Doors that open automatically as you approach them are now routine. Star Trek doors seem to be a bit smarter, though. Captain Kirk never had to stop in front of a door and wait for it to sluggishly slide open. Also the doors never open when you're just walking past and not intending to go through. https://www.youtube.com/watch?v=JZAkGfJY05k -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
Rustom Mody wrote: ÷ for some reason seems inappropriate (some vague recollection that its an only English; Europeans dont use it??) To me it's something you learn in primary school and then grow out of when you start doing real mathematics. The / is actually a better approximation of what mathematicians use. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
[ANN] pathlib 1.0
Hello, I am announcing the release of pathlib 1.0. This version brings pathlib up to date with the official Python 3.4 release, and also fixes a couple of 2.7-specific issues. Detailed changelog can be found further below. In the future, I expect the standalone (PyPI) version of pathlib to receive little to no updates, except if severe issues are found. New developments and regular bug fixes will happen mostly in the Python standard library, and be publicly available in official Python releases. Overview pathlib offers a set of classes to handle filesystem paths. It offers the following advantages over using string objects: * No more cumbersome use of os and os.path functions. Everything can be done easily through operators, attribute accesses, and method calls. * Embodies the semantics of different path types. For example, comparing Windows paths ignores casing. * Well-defined semantics, eliminating any warts or ambiguities (forward vs. backward slashes, etc.). Requirements Python 3.2 or later is recommended, but pathlib is also usable with Python 2.7. Install --- In Python 3.4, pathlib is now part of the standard library. For Python 3.3 and earlier, ``easy_install pathlib`` or ``pip install pathlib`` should do the trick. Changelog for version 1.0 - - Python issue #20765: Add missing documentation for PurePath.with_name() and PurePath.with_suffix(). - Fix test_mkdir_parents when the working directory has additional bits set (such as the setgid or sticky bits). - Python issue #20111: pathlib.Path.with_suffix() now sanity checks the given suffix. - Python issue #19918: Fix PurePath.relative_to() under Windows. - Python issue #19921: When Path.mkdir() is called with parents=True, any missing parent is created with the default permissions, ignoring the mode argument (mimicking the POSIX mkdir -p command). - Python issue #19887: Improve the Path.resolve() algorithm to support certain symlink chains. - Make pathlib usable under Python 2.7 with unicode pathnames (only pure ASCII, though). - Issue #21: fix TypeError under Python 2.7 when using new division. - Add tox support for easier testing. Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: Time we switched to unicode? (was Explanation of this Python language feature?)
Chris Angelico wrote: But you can't do the same for braces. You'd have to eschew *both* literal-ish notations and use explicit constructors everywhere. Not clean. This could have been dealt with by giving Python 2.7 a from __future__ import braces_mean_sets option or something like that. But I agree that the disruption would not have been worth the benefit. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
