DerbyPy Meetup, Louisville area, this Thursday at 6:30
I've started a meetup for Python in the Louisville, KY area. Come check us out: http://www.meetup.com/derbypy/ *Randy Syring* Husband | Father | Redeemed Sinner /For what does it profit a man to gain the whole world and forfeit his soul? (Mark 8:36 ESV)/ -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: What's the future of perfect Python?
On 8/11/2014 1:15 AM, 13813962782 wrote: Java is belonging to Oracle, C++ is defined by ISO; Python is designed by great Guido van Rossum http://en.wikipedia.org/wiki/Guido_van_Rossum; Python is owned, as in copyright and trademark, by the Python Software Foundation, a US non-profit corporation, with a Board elected by the voting members. Python is defined by the Reference and Library manuals. It was originally designed by Guido, who subsequently gave it to the PSF. At least 95% of current design work is done by other people under the framework Guido established, with his occasional input to make sure Python 'stays on track'. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Monday, August 11, 2014 11:16:25 AM UTC+5:30, Chris Angelico wrote: On Mon, Aug 11, 2014 at 3:23 PM, Rustom Mody wrote: A C programmer asked to swap variables x and y, typically writes something like t = x; x = y; y = t; Fine, since C cant do better. But then he assumes that that much sequentialization is inherent to the problem... Until he sees the python: x,y = y,x The same applies generally to all programmers brought up on imperative style. Uhh, that's still imperative. There is a chronological boundary here: prior to that statement's execution, x and y have certain values, and after it, they have the same values but the other way around. When you're manipulating algebraic statements, moving down the page doesn't correspond to any sort of time change, which is why x = x + 1 has no solutions. Please explain to me how x,y = y,x is materially different from x = x + 1 in that the latter is, in your words, an abomination, but you say the former doesn't have the same problem. I was giving an analogy for a mindset that - is sequencing hungup - is not aware of being hungup until a more abstract solution is presented. The two -- x=x+1 and the swap -- are not related. And yes the swap is imperative but less so than the C because it elides the fact that an implementation of x,y = y,x could be - t=x;x=y;y=t # the original - t=y;y=x=x=t # in the reverse order - push x; push y; pop x; pop y # use stack no temporary - xchng x y # hardware instruction in x86 and perhaps many other plausible ones. The terrible thing about an overspecific presentation is that it blinds one to alternatives And as for your wanting a fully non-imperative version: swap (x, y) = (y, x) -- the only option in Haskell, natural/easy in python, painfully laborious but still possible in C -- pass a struct, return a struct, unpack on return. You think that the '=' sign not standing for math equality is ok. How come? I aver that you (any competent programmer) have worked out/crystallized/created a switch in your brain. In 'programming' state: x=x+1 is not a problem In 'math' state : it is And you have become adroit at flipping from one to the other -- you do it all the time going from rhs to lhs!! I too have that switch as do most practised programmers. We are not talking about us, we are talking about noobs. So my reverse question to you is how do you inculcate this switch in a noob? -- https://mail.python.org/mailman/listinfo/python-list
Re: Template language for random string generation
On Sun, Aug 10, 2014 at 7:22 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Devin Jeanpierre wrote: On Sun, Aug 10, 2014 at 9:31 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I don't think that using a good, but not cryptographically-strong, random number generator to generate passwords is a serious vulnerability. What's your threat model? I've always wanted a password generator that worked on the fly based off of a master password. If the passwords are generated randomly but not cryptographically securely so, then given sufficiently many passwords, the master password might be deduced. o_O So, what you're saying is that you're concerned that if an attacker has all your passwords, they might be able to generate new passwords? No, I meant what I said. I was pretty specific. -- Devin -- https://mail.python.org/mailman/listinfo/python-list
Is print thread safe?
Specifically for Python 2.6 and 2.7, but answers for 3.x appreciated as well. Is print thread safe? That is, if I have two threads that each call print, say: print spam spam spam # thread 1 print eggs eggs eggs # thread 2 I don't care which line prints first, but I do care if the two lines are mixed in together, something like this: spam spaeggs eggs m seggspams Does print perform its own locking to prevent this? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Template language for random string generation
On 11/08/2014 06:06, Paul Wolf wrote: I'm pleased to see that you have answers. In return would you please 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Sun, 10 Aug 2014 23:22:45 -0700, Rustom Mody wrote: You think that the '=' sign not standing for math equality is ok. How come? For the same reason that in the following: [c.upper() for c in some_string if 'a' c 'x'] having the c symbol not stand for the speed of light is okay. Likewise, in the sentence I went to the park today, the symbol I doesn't mean the element iodine. Symbols are context-dependent: the x in one equation is not necessarily the same x in another equation, and the symbol = in one context does not necessarily have the same meaning as in another context. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the future of perfect Python?
On Mon, 11 Aug 2014 13:15:19 +0800, 13813962782 wrote: Just like MANY people, I was one of guys who do very like Python. But there's one thing always puzzled me, could you kindly help give some words about it: Java is belonging to Oracle, C++ is defined by ISO Python is designed by great Guido van Rossum then what is the future of Python( Guido van Rossum, GREAT man, but STILL just one person)? Haven't you heard? Guido has retired. http://legacy.python.org/dev/peps/pep-0401/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Thankfully, all actually user-friendly operating systems (MacOS, TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the bottomless cesspit of package management and/or installers. Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. You mean everyone has to reinvent the proverbial wheel AND worry about dependency collisions? Yeah, that's a heavenly thought. You should get a clue in stead of just fantasizing up assumptions based on ignorance. I've worked with a number of operating systems, a number of dependency management systems, and a number of absences of such systems. I stand by my earlier statements in this thread, Then you seem to have a problem with elementary logical reasoning. Your above statement (about re-inventing the wheel AND worrying about dependency collisions) is totally illogical nonsense. Just one issue: MacOS application have always been far more compact (both on disk and in RAM) than comparable Windows or Unix counterparts. Despite the fact that they where GUI applications since MacOS 1.0. No one has to re-invent any more wheels to develop a MacOS X application than he has to do for a Windows or Linux application. In fact, usually, there are less wheels to re-invent for MacOS X. Next: The self-contained nature of applications is obviously exactly what *eliminates* dependency collisions. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Linux was made by geeks who didn't have a clue of ergonomics for screenworkers and didn't care to get one. I can only repeat what you said earlier: You should get a clue in stead [sic] of just fantasizing up assumptions based on ignorance. I daresay that Linus Torvalds spends more time in front of a computer screen than most 9 to 5 screenworkers. He's a developer, not a usual screenworker. By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Mon, Aug 11, 2014 at 6:55 PM, Steven D'Aprano st...@pearwood.info wrote: On Sun, 10 Aug 2014 23:22:45 -0700, Rustom Mody wrote: You think that the '=' sign not standing for math equality is ok. How come? For the same reason that in the following: [c.upper() for c in some_string if 'a' c 'x'] having the c symbol not stand for the speed of light is okay. Likewise, in the sentence I went to the park today, the symbol I doesn't mean the element iodine. Symbols are context-dependent: the x in one equation is not necessarily the same x in another equation, and the symbol = in one context does not necessarily have the same meaning as in another context. Thanks, you said it better than I would have. That's exactly the sentiment I would have expressed, and while I hate to Me too a post, I'll do it here. +1. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Mon, 11 Aug 2014 11:08:43 +0200, Wolfgang Keller wrote: By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Sincerely, Wolfgang Which is not normally visible unless you go looking for it Also despite the problems it causes there are still an large number of posters that use Google groups probably cant see those headers even if they wished. Common courtesy (or netiquet if you prefer) would be to follow the conventions of the group you are posting to. -- You definitely intend to start living sometime soon. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
Rustom Mody rustompm...@gmail.com: You think that the '=' sign not standing for math equality is ok. How come? Python is a formal language with a well-defined syntax and reasonably well-understood semantics. That's all that matters. Any resemblance to the much more ad-hoc syntax of classical mathematics is almost coincidental. Instead of fighting the crystal-clear status of the = symbol in Python, you should choose a worthier crusade. For example, you could help mathematicians and physicists agree on the meaning of 6 3 ∫ ∫ f(x, y) dy dx 0 2 The mathematicians maintain the expression means x ranges from 0 to 6 and y from 2 to 3. The physicists consider that too confusing in practice and insist it is y that ranges from 0 to 6 and x from x to 3. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Sun, 10 Aug 2014 22:23:18 -0700, Rustom Mody wrote: A C programmer asked to swap variables x and y, typically writes something like t = x; x = y; y = t; Fine, since C cant do better. But then he assumes that that much sequentialization is inherent to the problem... Until he sees the python: x,y = y,x Which is inherently sequential: the semantics of Python guarantee that the right-hand side will be evaluated before being bound to the names on the left-hand side. The same applies generally to all programmers brought up on imperative style. Yeah there are problems that need to address time -- OSes, network protocols, reactive systems like window managers etc But the vast majority of problems that a programmer is likely to solve dont need time. Incorrect. Most problems are time dependent in the sense that you have to do X before you do Y. Print the file, then delete it has a very different effect to delete the file, then print it. Even functional programming has an implicit sense of time: f(g(x)) applies f *after* g, not the other way around. While there are some functions where it doesn't matter what order you call them, in general it does. There has been a huge amount of research into writing fully parallel code, where the order that code is executed is indeterminate. If we could take a general sequential program and parallelize it, we could speed up our programs hugely by throwing more cores or CPUs into the hardware. But in general we can't -- comparatively few tasks are easily, or at all parallelizable. One cannot make an omelet by cooking the eggs first and beating them second, or even at the same time. And even when you can parallelize a series of tasks, it's I think this is why both declarative and functional programming idioms will remain niche (although important niches). Most tasks are inherently imperative to at least some degree, and often a *great* degree. What is wrong is then thinking that all *problems* are sequential rather than seeing that some over-specific sequential *solutions* to non-sequential problems are ok. A mindset exemplified by your hilarious statement: computers have a sense of time Of course they do. Apart from a very few experimental asynchronous CPUs, computers are all based on CPUs with an internal clock signal which synchronizes distinct parts of the circuit with each other. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Mon, Aug 11, 2014 at 7:35 PM, Marko Rauhamaa ma...@pacujo.net wrote: Python is a formal language with a well-defined syntax and reasonably well-understood semantics. That's all that matters. Any resemblance to the much more ad-hoc syntax of classical mathematics is almost coincidental. Well, it's a bit more than coincidence. It's the ELIZA effect: http://www.catb.org/jargon/html/E/ELIZA-effect.html Using notations that some people will be familiar with is better than constructing brand new notations from scratch, even if not everyone can gain that benefit. (Which is an argument in favour of Python's percent-formatting of strings; there are plenty of people out there who'll instantly understand that %d will plop in an integer and %s a string - even some non-programmers know that notation, as it's found in config files, translation data, etc, etc.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano st...@pearwood.info wrote: And even when you can parallelize a series of tasks, it's ... easy for one task to get aborted part way while the rest of the tasks continue on, oblivious to the absence of the rest of that sentence? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano st...@pearwood.info wrote: I think this is why both declarative and functional programming idioms will remain niche (although important niches). Most tasks are inherently imperative to at least some degree, and often a *great* degree. Maybe that's true as a whole, but there are certainly ways in which certain declarative or functional elements can be extremely useful to an otherwise-imperative program. Python's (list etc) comprehensions are broadly functional in style, as are most of the itertools oddments. There's not a lot that's declarative in Python, but (at least in Python 3) the presence of __eq__() in a class disables the default __hash__ implementation, which effectively makes __eq__ a declaration I'm doing custom equality, so I'm unhashable unless I say otherwise. I've sometimes done some extremely declarative coding in places; my MUD client builds its menus by looking for specially-named functions and getting some metadata from them to work out what the menu item name should be. An approximate Python equivalent would be: @filemenu(E_xit) def exit(): prompt(Do you really want to exit?) where the presence of the function is what causes the menu item to exist. In this case, the 'filemenu' decorator is probably imperative code that adds the menu item to the File menu, but if you're reading through a source file that has a bunch of functions like that, you'd have to agree that that's a declarative style of coding. And it's a style that works well for this kind of thing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is print thread safe?
On Python 3, print is thread safe. But Python 2 has broken scenario: print spam, spam, spam # thread 1 print eggs, eggs, eggs # thread 2 In this case, 2 lines are mixed. In your case, spam spam spam and eggs eggs eggs are not mixed. But newline is mixed like: spam spam spameggs eggs eggs eggs eggs eggsspam spam spam eggs eggs eggs spam spam spam On Mon, Aug 11, 2014 at 4:44 PM, Steven D'Aprano st...@pearwood.info wrote: Specifically for Python 2.6 and 2.7, but answers for 3.x appreciated as well. Is print thread safe? That is, if I have two threads that each call print, say: print spam spam spam # thread 1 print eggs eggs eggs # thread 2 I don't care which line prints first, but I do care if the two lines are mixed in together, something like this: spam spaeggs eggs m seggspams Does print perform its own locking to prevent this? -- Steven -- https://mail.python.org/mailman/listinfo/python-list -- INADA Naoki songofaca...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Mon, Aug 11, 2014 at 7:37 PM, alister alister.nospam.w...@ntlworld.com wrote: On Mon, 11 Aug 2014 11:08:43 +0200, Wolfgang Keller wrote: By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Which is not normally visible unless you go looking for it Also despite the problems it causes there are still an large number of posters that use Google groups probably cant see those headers even if they wished. Common courtesy (or netiquet if you prefer) would be to follow the conventions of the group you are posting to. Additionally, the References header is good for at most one level in. Can you see, by looking at my post here, who Alister is quoting? Yes, easily, because his attribution line is part of the text that I've quoted. Can you see who Wolfgang is quoting? No, because there's no attribution line. It's completely impractical to dig through the References header (Alister's post has nineteen message IDs in References, and presumably mine will add a twentieth) to find out who quoted whom three levels ago. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Sun, 10 Aug 2014 21:29:12 -0700, Rustom Mody wrote: On Monday, August 11, 2014 8:30:32 AM UTC+5:30, Steven D'Aprano wrote: You did the same thing in your own course, the only difference being you accepted a different set of primitive functions. But ultimately you have to introduce *some* amount of concreteness, at some level, otherwise we're just engaged in mental masturbation: Q: Write a function to calculate the nth Catalan number. A: Assume that a function Catalan(n) exists and calculates the nth Catalan number. Then the solution is Catalan. You're concocting your own definitions and critiquing/refuting them. No, but I think you are deliberately choosing to ignore my point for the sake of cheap shots. My point is that, at *some* level, you have to actually write code (well duh!) which must be targeted at some concrete environment. Different languages provide different levels of abstraction, but they all have a some concrete set of primitive operations which actually do *something*, and that something is concrete, not abstract. Every function, even in Haskell, has an implementation. Otherwise if you don't need an implementation, you can just declare imagine a function that implements Foo for any Foo, and you're done.[1] Computer science, if might be said, is the search for better and more productive abstractions which provide more useful implementations for concrete tasks. [1] A perfectly reasonable approach, sometimes, for some philosophical questions, including sometimes philosophical questions within the scope of computer science. E.g. if we had a supertask, or an oracle-machine, what class of problems could we solve? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
Chris Angelico ros...@gmail.com: On Mon, Aug 11, 2014 at 7:35 PM, Marko Rauhamaa ma...@pacujo.net wrote: Python is a formal language with a well-defined syntax and reasonably well-understood semantics. That's all that matters. Any resemblance to the much more ad-hoc syntax of classical mathematics is almost coincidental. Well, it's a bit more than coincidence. It's the ELIZA effect: http://www.catb.org/jargon/html/E/ELIZA-effect.html Using notations that some people will be familiar with is better than constructing brand new notations from scratch, even if not everyone can gain that benefit. The main thing is that the definitions must be clear. I must be able to look up the precise description quickly, and in fact, I always have the Python Library Reference in a browser tab or two because I have to review even familiar functionality over and over again. Less often, I also have to review the Python Language Reference. You don't have to like the = sign or the trailing comma of 1-tuples. What matters is that you know how to use them. The second in priority is that the language/module should be faithful to its own principles. An example is the so-called file-like objects in Python. A different one would be the principle that a new indentation level is always introduced by a colon. Yet another specialty of Python is the numerous magic access points that have been named __xyz__. You don't have to like the naming of __init__. It doesn't have to have a precedent in other programming languages. However, it is important that it follows a general, rigorous Python pattern. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Mon, Aug 11, 2014 at 8:46 PM, Marko Rauhamaa ma...@pacujo.net wrote: The main thing is that the definitions must be clear. I must be able to look up the precise description quickly, and in fact, I always have the Python Library Reference in a browser tab or two because I have to review even familiar functionality over and over again. Less often, I also have to review the Python Language Reference. You don't have to like the = sign or the trailing comma of 1-tuples. What matters is that you know how to use them. Fair enough. I'd say that there are two main things, of nearly equal importance: one is clear definitions, as you describe, and the other is memorable definitions (so you don't have to keep going back to the reference for every little thing). The consistency you describe as your second priority is really part of memorability, because you can learn one principle and have it work for everything. Contrast the PHP standard library, where there's very little consistency in naming, so you're constantly going back to the docs - see examples here [1] - I can fully understand that switching from language to language will have me doing this sort of thing (often with very good justification - map() in Python takes func,iter,... but map() in Pike takes iter,func,...; this is because Python's map() takes multiple iterables, while Pike's takes exactly one iterable and will pass any other args through to the function unchanged - which is consistent with a lot of other Pike callback-calling functions), but within a single language, it's more reasonable to expect consistency. There are innumerable facets to the memorability of definitions, though, and consistency's just one of them. The ELIZA effect factors heavily in memorability; if you see a + b in code, you'll expect it to be, in some way, adding a and b. If you know what HTTP means from other places on the internet, you'll have some fairly strong expectations about the functionality of BasicHTTPServer. If you've worked with any of a huge bunch of languages, you'll not at all be surprised that asdf is a string containing those four letters. And that latter is true even though lots of languages have their variations - biggest one being that Python 3's asdf is a string of four Unicode codepoints, while C's asdf is a pointer to a buffer of four bytes (plus the 0, so five really); it's still a string containing four lowercase letters. And that's a Good Thing. ChrisA [1] http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/#standard-library -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
Chris Angelico wrote: On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano st...@pearwood.info wrote: And even when you can parallelize a series of tasks, it's ... easy for one task to get aborted part way while the rest of the tasks continue on, oblivious to the absence of the rest of that sentence? Exactly! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Monday, August 11, 2014 3:58:59 PM UTC+5:30, Steven D'Aprano wrote: On Sun, 10 Aug 2014 21:29:12 -0700, Rustom Mody wrote: On Monday, August 11, 2014 8:30:32 AM UTC+5:30, Steven D'Aprano wrote: You did the same thing in your own course, the only difference being you accepted a different set of primitive functions. But ultimately you have to introduce *some* amount of concreteness, at some level, otherwise we're just engaged in mental masturbation: Q: Write a function to calculate the nth Catalan number. A: Assume that a function Catalan(n) exists and calculates the nth Catalan number. Then the solution is Catalan. You're concocting your own definitions and critiquing/refuting them. No, but I think you are deliberately choosing to ignore my point for the Because I dont understand what you are saying. [See below] My point is that, at *some* level, you have to actually write code (well duh!) which must be targeted at some concrete environment. Different languages provide different levels of abstraction, but they all have a some concrete set of primitive operations which actually do *something*, and that something is concrete, not abstract. Every function, even in Haskell, has an implementation. Otherwise if you don't need an implementation, you can just declare imagine a function that implements Foo for any Foo, and you're done.[1] I guess part of the problem is that evidently you and I use 'concrete' and 'abstract' in almost diametrically opposite ways. In my book, FP is easy and pleasant and smooth because (among other things) FP types are concrete, whereas OOP types are abstract. Here is an FP classic: http://www.nlda-tw.nl/janmartin/vakken/TFIT/Extra%20materiaal/Bird_Wadler.%20Introduction%20to%20Functional%20Programming.1ed.pdf In the section on 'abstract types' (pg 221 chap 8) he briefly explains what is an abstract type and indicates that the whole book only deals with concrete types. This was written in 1988. Across the last 25 years this view has only strengthened at least in the FP circles, viz. that concrete types are all thats needed for the most part whereas abstract types (ADTs) and other OOP fancies are a waste of time, a PITA and not worth the sweat of pursuing them. You are of course free to disagree with this viewpoint -- the majority of programmers do. But now you are turning the tables and saying that the FP types/constructs are more abstract than the conventional ones. I dont argue with this because I dont know how to, other than to say it does not seem to be the dominant view in either the conventional (OOP/imperative) communities or in the FP community. Here is a conversation from reddit: http://www.reddit.com/r/haskell/comments/xgq27/uday_reddy_sharpens_up_referential_transparency/ which should give a sense of the pov. Person 1 | By the way, somebody commented on the StackOverflow page that the | naive functional programmer seems to use syntactic reasoning while the | naive imperative programmer seems to use operational reasoning. Person 2 | Interesting. I have a theory that functional programmers use more | concrete (denotative, indicative, elemental) thought whereas | imperative programmers use more abstract (connotative, analogous) | thought. However, sequential and random thinking styles can also be | very different. On the Meyers-Briggs functional and imperative | programmers seem to differ on both axies of the four main personality | groups. Person 3 | Yup, that is also a quite insightful point. But we also need to keep | in mind the training aspect. Functional programming is taught in a | semi-rigorous way, using the knowledge of set theory and mathematics | that we all know. Imperative programming is taught in an intuitive | way, because there is no well-understood mathematics for it yet. In | fact, let us say that imperative programming is not really taught at | all. Whatever the imperative programmers learn, they learn through | experience. They write programs, see how they behave, and build up a | mental picture of how they work and how to reason about them. It is an | art rather than a science. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On 2014-08-11 03:04, Steven D'Aprano wrote: Rustom Mody wrote: Its when we have variables that are assigned in multiple places that we start seeing mathematical abominations like x = x+1 That's not a mathematical abomination. It's a perfectly reasonable mathematical equation, one with no solutions since the line f(x) = x and the line f(x) = x+1 are parallel. But what does this have to do with programming? Programming *is not* mathematics, and x = x+1 has a different meaning in programming than in mathematics. Perhaps it would help if we wrote it using mathematical notation? Using [x] for subscripts: x[n+1] = x[n] + 1 we have a perfectly good mathematical recursive definition. All it needs is an initial value x[0] and we're good to go. Or a different operator for assignment (to distinguish it more clearly from equality, which it isn't). x - x + 1 x := x + 1 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
In article b3c69a72-5f0c-4e2a-8ef0-91842e12c...@googlegroups.com, Rustom Mody rustompm...@gmail.com wrote: A C programmer asked to swap variables x and y, typically writes something like t = x; x = y; y = t; Fine, since C cant do better. Sure C can do better. x = x ^ y y = y ^ x x = x ^ y Any self-respecting C hacker would write it this way :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
Having it both ways aren't you? On the one hand you say On Monday, August 11, 2014 3:21:35 PM UTC+5:30, Chris Angelico wrote: On Mon, Aug 11, 2014 at 7:35 PM, Marko Rauhamaa wrote: Python is a formal language with a well-defined syntax and reasonably well-understood semantics. That's all that matters. Any resemblance to the much more ad-hoc syntax of classical mathematics is almost coincidental. Well, it's a bit more than coincidence. It's the ELIZA effect: http://www.catb.org/jargon/html/E/ELIZA-effect.html Which describes the Eliza effect as: The tendency of humans to attach associations to terms from prior experience. Then you continue: Using notations that some people will be familiar with is better than constructing brand new notations from scratch, even if not everyone can gain that benefit. (Which is an argument in favour of Python's percent-formatting of strings; there are plenty of people out there who'll instantly understand that %d will plop in an integer and %s a string - even some non-programmers know that notation, as it's found in config files, translation data, etc, etc.) So evidently using notations in the ways they are conventionally used is a good thing. But then when it comes to Steven supporting the violation 500 years* of math conventional usage of '=': On Monday, August 11, 2014 2:45:48 PM UTC+5:30, Chris Angelico wrote: On Mon, Aug 11, 2014 at 6:55 PM, Steven D'Aprano wrote: On Sun, 10 Aug 2014 23:22:45 -0700, Rustom Mody wrote: You think that the '=' sign not standing for math equality is ok. How come? For the same reason that in the following: [c.upper() for c in some_string if 'a' c 'x'] having the c symbol not stand for the speed of light is okay. Likewise, in the sentence I went to the park today, the symbol I doesn't mean the element iodine. Symbols are context-dependent: the x in one equation is not necessarily the same x in another equation, and the symbol = in one context does not necessarily have the same meaning as in another context. you are strongly approving. You really need to decide which side you are on! eg Marko disagrees but is fairly consistent: Whether I like it or not, whether its conventional or not... Quite irrelevant. Its formally defined. I follow the definition. [Browser tabs stay open in case I slip] But you seem to be hopping between: Its easy, its natural and thats why its so and Its the way it is... Take it or leave it * Robert Recorde invented the '=' and introduced algebra to England in 1557 http://en.wikipedia.org/wiki/Robert_Recorde#Publications -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On 2014-08-11 07:55, Roy Smith wrote: A C programmer asked to swap variables x and y, typically writes something like t = x; x = y; y = t; Fine, since C cant do better. Sure C can do better. x = x ^ y y = y ^ x x = x ^ y Any self-respecting C hacker would write it this way :-) Pish, such redundancy...everyone knows a C programmer would write that as x ^= y y ^= x x ^= y :-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Mon, 11 Aug 2014 12:56:59 +0100, Robert Kern wrote: On 2014-08-11 03:04, Steven D'Aprano wrote: Rustom Mody wrote: Its when we have variables that are assigned in multiple places that we start seeing mathematical abominations like x = x+1 That's not a mathematical abomination. It's a perfectly reasonable mathematical equation, one with no solutions since the line f(x) = x and the line f(x) = x+1 are parallel. But what does this have to do with programming? Programming *is not* mathematics, and x = x+1 has a different meaning in programming than in mathematics. Perhaps it would help if we wrote it using mathematical notation? Using [x] for subscripts: x[n+1] = x[n] + 1 we have a perfectly good mathematical recursive definition. All it needs is an initial value x[0] and we're good to go. Or a different operator for assignment (to distinguish it more clearly from equality, which it isn't). x - x + 1 x := x + 1 It already is a different operator from equality which is == perhaps it would have been better if the behaviour of these two operators were reversed (= for equality == for assignment) but i suspect that Idea if even considered was quickly discarded as it would cause major confusion to programmers who work with multiple languages -- Meskimen's Law: There's never time to do it right, but there's always time to do it over. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
alister alister.nospam.w...@ntlworld.com: It already is a different operator from equality which is == perhaps it would have been better if the behaviour of these two operators were reversed (= for equality == for assignment) but i suspect that Idea if even considered was quickly discarded as it would cause major confusion to programmers who work with multiple languages Blame it on FORTRAN: X = X + 1 IF (X .EQ. 100) GOTO 999 BASIC took a no-nonsense approach: 5 LET S = 0 10 MAT INPUT V 20 LET N = NUM 30 IF N = 0 THEN 99 40 FOR I = 1 TO N 45 LET S = S + V(I) 50 NEXT I 60 PRINT S/N 70 GO TO 5 99 END (URL: http://en.wikipedia.org/wiki/BASIC#Examples) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Mon, Aug 11, 2014 at 10:11 PM, Rustom Mody rustompm...@gmail.com wrote: So evidently using notations in the ways they are conventionally used is a good thing. But then when it comes to Steven supporting the violation 500 years* of math conventional usage of '=': Yep. It's not a violation; it's a modification. Since algebra has no concept of chronology and programming does, some notation must be found which captures this concept. Try explaining complex numbers to someone who has only ever used real numbers, and explain why you violate however-many centuries of conventional usage wherein letters are used for variables, but now you pick one of them and make it a constant. It's an abomination! This complex stuff is so utterly wrong compared to real mathematics, and how dare you even support using symbols the same way in both of them! The double horizontal line is associated with equality. Assignment states that the LHS after this point is equal to the RHS before this point, which is a chronologically modified form of enforced equality. It makes good sense to use the double horizontal line for equality. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
Tim Chase python.l...@tim.thechases.com: Pish, such redundancy...everyone knows a C programmer would write that as x ^= y y ^= x x ^= y Aren't you forgetting something? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Mon, Aug 11, 2014 at 10:41 PM, Marko Rauhamaa ma...@pacujo.net wrote: Tim Chase python.l...@tim.thechases.com: Pish, such redundancy...everyone knows a C programmer would write that as x ^= y y ^= x x ^= y Aren't you forgetting something? I don't think he is. Those are augmented assignments, just as Python has (although with slightly different semantics in some places). The semicolons can be omitted in some C REPLs, although they are of course mandatory in regular code. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 11/08/2014 10:08, Wolfgang Keller wrote: By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Sincerely, Wolfgang The references header is conspicious by its absence. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the future of perfect Python?
On 11/08/2014 10:04, Steven D'Aprano wrote: On Mon, 11 Aug 2014 13:15:19 +0800, 13813962782 wrote: Just like MANY people, I was one of guys who do very like Python. But there's one thing always puzzled me, could you kindly help give some words about it: Java is belonging to Oracle, C++ is defined by ISO Python is designed by great Guido van Rossum then what is the future of Python( Guido van Rossum, GREAT man, but STILL just one person)? Haven't you heard? Guido has retired. http://legacy.python.org/dev/peps/pep-0401/ The miserable blighters didn't send a card around for me to sign either. Cheapskates or what? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On 11/08/2014 13:30, Tim Chase wrote: On 2014-08-11 07:55, Roy Smith wrote: A C programmer asked to swap variables x and y, typically writes something like t = x; x = y; y = t; Fine, since C cant do better. Sure C can do better. x = x ^ y y = y ^ x x = x ^ y Any self-respecting C hacker would write it this way :-) Pish, such redundancy...everyone knows a C programmer would write that as x ^= y y ^= x x ^= y :-) -tkc That says the LHS is assigned the RHS rotated by some angle, which I'll assume to be 90 degrees clockwise, yes? Well I don't suppose it really matters for x as it'll still be x when it gets assigned to y, but what would you call the shift on y that gets assigned to x? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On 11/08/2014 13:11, Rustom Mody wrote: But then when it comes to Steven supporting the violation 500 years* of math conventional usage of '=': I have no interest in the maths convention (see, you don't even know the original, correct English, math indeed). Of far more importance in the real world is the Irish navvy convention. Are there any such people lurking here who can give us the required insight? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: attendance system in pybluez
On 08/09/2014 09:07 PM, luofeiyu wrote: in the http://homepages.ius.edu/rwisman/C490/html/PythonandBluetooth.htm *Discovery* That only works for phones if the phones are manually switched to discoverable mode, which is off by default for security reasons. By default they are not going to show up on your discovery scans. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On 11/08/2014 13:30, alister wrote: It already is a different operator from equality which is == perhaps it would have been better if the behaviour of these two operators were reversed (= for equality == for assignment) but i suspect that Idea if even considered was quickly discarded as it would cause major confusion to programmers who work with multiple languages Of course Python can be even more confusing so that for example class NeverEqual(int): ... def __new__(cls,v): ... self = int.__new__(cls,v) ... return self ... def __eq__(self,other): ... return False ... a=NeverEqual(1) a 1 a==1 False a==a False not (a != a) True a!=a False so I think that assignment doesn't always make things equal even chronologically. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Nuitka Release 0.5.4
To me rather more interesting than discussing the relative merits of '=' compared to '==', '=' or ':='. See here http://nuitka.net/posts/nuitka-release-054.html -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Is print thread safe?
INADA Naoki wrote: On Python 3, print is thread safe. But Python 2 has broken scenario: Is this documented somewhere? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 2014-08-06, Wolfgang Keller felip...@gmx.net wrote: Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any packages or installers to use it. For people who have never used such a system it's probably difficult to see the advantages. That's the whole point. The problem is that the ones who decide (well, they pretend to, but actually can't, because they don't know the alternatives) are always people who are not even clueless. Ha! I love it. I presume that's an allusion to that-other-Wolfgang's apocryphal not even wrong comment. :) -- Grant Edwards grant.b.edwardsYow! I want to mail a at bronzed artichoke to gmail.comNicaragua! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 2014-08-11, Wolfgang Keller felip...@gmx.net wrote: [somebody, but we don't know who, wrote]... By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. Your over-confidence in Usenet, mailing list archives, news-to-mail gateways, and various client applications is showing... -- Grant Edwards grant.b.edwardsYow! Can I have an IMPULSE at ITEM instead? gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Linux distros w/o Python in base installation
I just installed Arch Linux for the first time, and was surprosed to find that Python isn't installed as part of a base system. It's also not included in the 'base-devel' package group. It's trivial to install, but I'd still pretty surprised it's not there by default. I guess I've spent too much time with Gentoo, Debian, and RedHat derivitives which require Python be installed. I've probably used at least a dozen Linux distros over the years, and this is the first time I've noticed that Python wasn't installed by default. Just for the sake of curiosity, are there any other significant desktop/server Linux distros that don't come out of the box with Python? -- Grant Edwards grant.b.edwardsYow! If I am elected no one at will ever have to do their gmail.comlaundry again! -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux distros w/o Python in base installation
On Mon, Aug 11, 2014 at 11:53 AM, Grant Edwards invalid@invalid.invalid wrote: I just installed Arch Linux for the first time, and was surprosed to find that Python isn't installed as part of a base system. It's also not included in the 'base-devel' package group. It's trivial to install, but I'd still pretty surprised it's not there by default. I guess I've spent too much time with Gentoo, Debian, and RedHat derivitives which require Python be installed. I've probably used at least a dozen Linux distros over the years, and this is the first time I've noticed that Python wasn't installed by default. Just for the sake of curiosity, are there any other significant desktop/server Linux distros that don't come out of the box with Python? It would seem that such distros are opting to not be LSB-compliant?: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Languages/LSB-Languages/pylocation.html Cheers, Chris -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux distros w/o Python in base installation
On 2014-08-11, Chris Rebert c...@rebertia.com wrote: On Mon, Aug 11, 2014 at 11:53 AM, Grant Edwards invalid@invalid.invalid wrote: I just installed Arch Linux for the first time, and was surprosed to find that Python isn't installed as part of a base system. It's also not included in the 'base-devel' package group. It's trivial to install, but I'd still pretty surprised it's not there by default. I guess I've spent too much time with Gentoo, Debian, and RedHat derivitives which require Python be installed. I've probably used at least a dozen Linux distros over the years, and this is the first time I've noticed that Python wasn't installed by default. Just for the sake of curiosity, are there any other significant desktop/server Linux distros that don't come out of the box with Python? It would seem that such distros are opting to not be LSB-compliant?: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Languages/LSB-Languages/pylocation.html Apparently. Perhaps theres an enable LSB compliance option somewhere in the Arch install docs, but I didn't see it... -- Grant Edwards grant.b.edwardsYow! Somewhere in Tenafly, at New Jersey, a chiropractor gmail.comis viewing Leave it to Beaver! -- https://mail.python.org/mailman/listinfo/python-list
Python Object Systems
(Cross-posted from http://www.reddit.com/r/Python/comments/2d9f7i/survey_of_python_object_systems/) Hello, has anyone created a survey of Python Object Systems? The two I am aware of are: - elk https://github.com/frasertweedale/elk - Traits http://code.enthought.com/projects/traits/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Object Systems
On Mon, Aug 11, 2014 at 3:26 PM, thequietcen...@gmail.com wrote: has anyone created a survey of Python Object Systems? For the uninitiated, can you back up a step and define what you mean by an object system? The term seems kind of broad for Google ( number of hits for CLOS, etc), and Wikipedia just directs to a page on object-oriented programming. Thx, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Object Systems
On Monday, August 11, 2014 4:37:29 PM UTC-4, Skip Montanaro wrote: On Mon, Aug 11, 2014 at 3:26 PM, thequietcen...@gmail.com wrote: has anyone created a survey of Python Object Systems? For the uninitiated, can you back up a step and define what you mean by an object system? I mean a system by which one creates and manages Python objects. For instance, Python ships with an object system as documented here: https://docs.python.org/2/tutorial/classes.html However, some developers have found the need to add features to the standard Python object system (e.g. delegation, typing, etc), thus offering a new object system. So far, the following object systems have been found: * elk https://github.com/frasertweedale/elk * Traits http://code.enthought.com/projects/traits/ * yuppy https://github.com/kuujo/yuppy -- Terrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Object Systems
Skip Montanaro s...@pobox.com: On Mon, Aug 11, 2014 at 3:26 PM, thequietcen...@gmail.com wrote: has anyone created a survey of Python Object Systems? For the uninitiated, can you back up a step and define what you mean by an object system? Elk and Traits implement a C++-style object model on top of Python. The systems enforce member access, type constraints etc and result in ugly code that barely looks like Python. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Object Systems
On Monday, August 11, 2014 5:09:35 PM UTC-4, Marko Rauhamaa wrote: Elk and Traits implement a C++-style object model on top of Python. The systems enforce member access, type constraints etc and result in ugly code that barely looks like Python. I personally get tired of manually assigning attributes in a __init__() method. So at the bare minimum something like Atom will do if nothing else: https://github.com/nucleic/atom And I imagine yuppy would make you upchuck as well: https://github.com/kuujo/yuppy -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux distros w/o Python in base installation
In article lsb84u$21c$1...@reader1.panix.com, Grant Edwards invalid@invalid.invalid wrote: Apparently. Perhaps theres an enable LSB compliance option somewhere in the Arch install docs, but I didn't see it... Also beware that, unlike most other distributions and contrary to recommended practice, Arch has chosen to make Python 3 its default, that is, when everything is installed, `python` invokes `python3`, rather than `python2`. So you may need to change shebang lines in scripts, etc. https://wiki.archlinux.org/index.php/python -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Object Systems
On 11/08/2014 22:26, thequietcen...@gmail.com wrote: On Monday, August 11, 2014 5:09:35 PM UTC-4, Marko Rauhamaa wrote: Elk and Traits implement a C++-style object model on top of Python. The systems enforce member access, type constraints etc and result in ugly code that barely looks like Python. I personally get tired of manually assigning attributes in a __init__() method. So at the bare minimum something like Atom will do if nothing else: https://github.com/nucleic/atom And I imagine yuppy would make you upchuck as well: https://github.com/kuujo/yuppy Would you please read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the double line spacing and single line paragraphs above, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Object Systems
thequietcen...@gmail.com: I personally get tired of manually assigning attributes in a __init__() method. It's not all that bad. Just do it. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On 11/08/2014 13:30, alister wrote: It already is a different operator from equality which is == Mathematicians use '=' for name binding all the time, with and without 'let': Let u = x + y, v = x - y. Then ... . However, name binding itself is a mental operation, not a mathematical one. Mathematicians sometimes differentiate conditionally true expressions from necessarily true expressions (tautologies, 'identically true') by using triple bars for the latter. In algebra, (a+b)(a-b) triple bar equal a*a-b*b. I think the sense of the extra bar is 'really equal, not just contingently equal). Mathematicians sometimes use ':=' for definitions and sometimes decorate '=' in various other ways. Unicode has most of them. So mathematicians do not always use plain '=' for various ideas of sameness. perhaps it would have been better if the behaviour of these two operators were reversed (= for equality == for assignment) but i suspect that Idea if even considered was quickly discarded as it would cause major confusion to programmers who work with multiple languages. Given that assignment occurs more often than equality testing, it makes sense to use the shorter coding for assignment. This principle operates in natural language (English at least) and in various codings from Morse to Huffman. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Keep one GUI always on TOP while python code is running
On 2014-08-07, Jaydeep Patil patil.jay2...@gmail.com wrote: I have one query. I have did some programming which copies and paste data using system clipboard. I need to keep one GUI always on top till my python code is running. If you mean keep it on top while it is running, the answer is probably yes, but how to do it depends on the OS, windowing syste, and tookit in use. However, doing so is pure evil and will cause users to wish bad things upon you and all your family and descendants. If you want to make some particular dialog the only one from your app that can be used, that's fine, but don't try to override the user's desire to put other applications on top of yours or to even control the ordering of windows within your app. Thinking your app is so important that it can take over the entire desktop and needs to control what window is on top is just plain bad [not that it's unusual for windows apps]. -- Grant Edwards grant.b.edwardsYow! !! I am having fun!!! at gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Keep one GUI always on TOP while python code is running
On 2014-08-08, Chris Angelico ros...@gmail.com wrote: On Fri, Aug 8, 2014 at 11:58 PM, Steven D'Aprano Why should that disable access to everything else? Most full screen games let you alt-tab away from them (preferably auto-pausing the game). If a game goes system modal on me, I would not be happy. * my application is SO SPECIAL that it deserves to take over the entire GUI Just Because I Can. And that one is definitely not a reason, as I'm sure you agree :) But, AFAICT, that's the only reason behind the behavior for a lot of Windows apps. Authors of X apps don't seem to suffer from such delusions of grandeur (or maybe it's just too hard under under X). My opinion is that people with valid reasons to use a system-modal window don't need to ask how. IOW asking how to do it is pimae-facie evidence that you should not be doing it. -- Grant Edwards grant.b.edwardsYow! PIZZA!! at gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Is print thread safe?
On 12Aug2014 02:07, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: INADA Naoki wrote: On Python 3, print is thread safe. But Python 2 has broken scenario: Is this documented somewhere? In python/2.7.6/reference/simple_stmts.html#index-22, print is described in terms of a write for each object, and a write for the separators. There is no mention of locking. On that basis, I would find the interleaving described normal and expected. And certainly not broken. Just use a lock! And rebind print! Or use the logging system! Cheers, Cameron Simpson c...@zip.com.au Wow! Yet another place that I've been quoted... - Andy Beals ba...@cinnamon.com -- https://mail.python.org/mailman/listinfo/python-list
Re: converting ISO8601 date and time string representations to datetime
On 31/07/2014 10:11, Wolfgang Maier wrote: Hi, I'm trying to convert ISO8601-compliant strings representing dates or dates and times into datetime.datetime objects. I tried using the strptime method, but the problem here is that I can only specify one format argument, which can be used to parse either a full date/time string or just a date string, but not both. While I could just try parsing with one format, then catch the ValueError in case it fails and try another format, it feels like there should be a more elegant way to do this. I do know about the dateutil package, but I'd prefer to stick to the stdlib for this. Any suggestions ? Wolfgang If you're not sorted via stdlib how about http://crsmithdev.com/arrow/ ? Haven't tried it myself as I've only just come across it. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: how to write file into my android phone?
On 2014-08-10, Marko Rauhamaa ma...@pacujo.net wrote: Christian Gollwitzer aurio...@gmx.de: Am 10.08.14 11:39, schrieb Steven D'Aprano: Android phones don't mount as storage devices? Oh well, that's Android crossed off my list. Not any longer. They used to, but the support for mass storage was dropped in favour of MTP I don't see anything inherently wrong with an open protocol like MTP. to allow concurrent access from both the computer and the phone. I don't know MTP at all, but MTP allows no parallelism; unlike USB mass storage, MTP has been built to only allow a single operation at a time (for example, read, write or delete operation), while no other operation can be executed until the previous operation is complete. URL: http://en.wikipedia.org/wiki/Media_Transfer_Protocol#Drawbacks That's the within MTP protocol itself, and that's not the prallel access problem which MTP was intended to address. What MTP allows is parallel access between the MTP protocol server in the phone and the rest of the phone (OS and apps). In order to mount a partition as a USB mass storage device, it has to first be unmounted by the Android system. That's OK for an SD card that doesn't contain anything important required by the Android system, but it means that you can't mount the system partition without shutting down the phone completely. For phones that don't have an SD card, there is nothing _but_ the system partition, and to mount it as a USB storage device you would have to completely shut down the phone. People don't like that. They want to keep the phone on while their doing whatever with their MP3 files and JPEG files and whatnot. The only practical way to do that is to define a file transfer protocol that doesn't require the entire parition be unmounted by the phone. Hence MTP. It's something Microsoft came up with, so it of course has their usual level of broken-as-designed about it, but in general it works fairly well. For Linux systems there's a user-space MTP filesystem implementation that has always worked fine for me. So in practice, it works just like as somewhat slow USB mass storage device. -- Grant Edwards grant.b.edwardsYow! Now I understand the at meaning of THE MOD SQUAD! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: converting ISO8601 date and time string representations to datetime
On 06/08/2014 20:05, Skip Montanaro wrote:
On Wed, Aug 6, 2014 at 1:31 PM, Joel Goldstick joel.goldst...@gmail.com wrote:
Among other features it lists this: Gaps in functionality: ISO-8601
parsing, timespans, humanization
What is humanization?
Skip
Presumably as in https://pypi.python.org/pypi/humanize
The page states This modest package contains various common
humanization utilities, like turning a number into a fuzzy human
readable duration ('3 minutes ago') or into a human readable size or
throughput. It works with python 2.7 and 3.3 and is localized
to Russian, French, and Korean.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Object Systems
On 14-08-11 04:26 PM, thequietcen...@gmail.com wrote: ... Hello, has anyone created a survey of Python Object Systems? The two I am aware of are: - elk https://github.com/frasertweedale/elk - Traits http://code.enthought.com/projects/traits/ Here's the ones from my talk at Pycon 2005 (http://www.vrplumber.com/programming/descriptors-pycon2005.pdf): OpenGLContext/PyVRML97 http://bazaar.launchpad.net/~mcfletch/pyvrml97/trunk/files Observable, auto-coercing data properties w/ Numeric/numpy array support, defaults BasicProperty (now largely abandoned): http://bazaar.launchpad.net/~mcfletch/basicproperty/trunk/files Again, observable auto-coercing typed properties, defaults, introspection Zope2 FieldProperty, DublinCore, Validation, Observability PEAK Defaults, delegation, implicit feature loading Traits Delegation, typing, validation, defaults, Observability, introspection PyObjc, ctypes, JythonC, IronPython Function-like things with lots of metadata There's also a listing of the other tasks for which descriptors/object systems were expected to show up at the time, if you look for Python + that key-word you'll likely find a few dozen more object systems out there. You'll also likely find about a thousand metaclasses these days. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get the ordinal number in list
On Tue, Aug 12, 2014 at 12:32 AM, Robin Becker ro...@reportlab.com wrote: Of course Python can be even more confusing so that for example class NeverEqual(int): ... def __new__(cls,v): ... self = int.__new__(cls,v) ... return self ... def __eq__(self,other): ... return False ... a=NeverEqual(1) a 1 a==1 False a==a False not (a != a) True a!=a False so I think that assignment doesn't always make things equal even chronologically. Sure, but at this point you're fiddling with the definition of equality, and Python has never stopped you from shooting yourself in the foot :) There are less contrived examples, too, like those involving floating-point round-off, which basically prove that Python's equality comparison is not the same as mathematical equality; but that doesn't stop people from comprehending that 1 + 3 == 2 + 2 in Python based on their knowledge of mathematics. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux distros w/o Python in base installation
On Tue, Aug 12, 2014 at 7:36 AM, Ned Deily n...@acm.org wrote: In article lsb84u$21c$1...@reader1.panix.com, Grant Edwards invalid@invalid.invalid wrote: Apparently. Perhaps theres an enable LSB compliance option somewhere in the Arch install docs, but I didn't see it... Also beware that, unlike most other distributions and contrary to recommended practice, Arch has chosen to make Python 3 its default, that is, when everything is installed, `python` invokes `python3`, rather than `python2`. So you may need to change shebang lines in scripts, etc. https://wiki.archlinux.org/index.php/python Well, it only *became* contrary to recommended practice in response to Arch doing it and everyone seeing the issues it caused :) Personally, I'm glad they did. Lets those of us who follow slower distros (I'm running Debian) get the benefit of someone else's hindsight. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is print thread safe?
Cameron Simpson wrote: On 12Aug2014 02:07, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: INADA Naoki wrote: On Python 3, print is thread safe. But Python 2 has broken scenario: Is this documented somewhere? In python/2.7.6/reference/simple_stmts.html#index-22, print is described in terms of a write for each object, and a write for the separators. There is no mention of locking. Ah, thanks! On that basis, I would find the interleaving described normal and expected. And certainly not broken. I personally didn't describe it as broken, but it is, despite the documentation. I just ran a couple of trials where I collected the output of sys.stdout while 50 threads blasted Spam ABCD EFGH (plus the implicit newline) to stdout as fast as possible using print. The result was that out of 248165 lines[1], 595 were mangled. Many of the mangled lines were the expected simple run-ons: Spam ABCD EFGHSpam ABCD EFGH\n\n which makes sense given the documentation, but there were lots of anomalies. Mysterious spaces appearing in the strings: Spam ABCD EFGH Spam ABCD EFGH\n\n Spam ABCD EFGH Spam ABCD EFGH\n Spam ABCD EFGH\n occasional collisions mid-string: Spam ABSpam ABCD EFGH\nCD EFGH\n letters disappearing: Spam AB\nD EFGH\n and at least one utterly perplexing (to me) block of ASCII NULs appearing in the middle of the output: \x00\x00\x00...\x00\x00\n This is with Python 2.7.2 on Linux. Just use a lock! And rebind print! Or use the logging system! Personally, I believe that print ought to do its own locking. And print is a statement, although in this case there's no need to support anything older than 2.6, so something like this ought to work: from __future__ import print_function _print = print _rlock = threading.RLock() def print(*args, **kwargs): with _rlock: _print(*args, **kwargs) Sadly, using print as a function alone isn't enough to fix this problem, but in my quick tests, using locking as above does fix it, and with no appreciable slowdown. [1] Even the number of lines of output demonstrates a bug. I had fifty threads printing 5000 times each, which makes 25 lines, not 248165. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Is print thread safe?
On Tue, Aug 12, 2014 at 9:56 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: from __future__ import print_function _print = print _rlock = threading.RLock() def print(*args, **kwargs): with _rlock: _print(*args, **kwargs) You're conflating print and stdout here. Do you know which one is the cause of your problems? Alternatively, can you be certain that you never use either without the other? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
Wolfgang Keller wrote: By the way, you keep replying to people, and quoting them, but deleting their name. Please leave the attribution in place, so we know who you are replying to. That's what the References:-Header is there for. The References header is for the benefit of news and mail clients, not human readers. Giving attribution in the body of your text is for the benefit of people reading your reply, and I maintain that people are far more important than your news or mail client. It is rude to deliberately refuse to give attributes: - you're saying that the person you are replying to doesn't deserve to have their identity acknowledged even in passing; - you're saying that you expect all of your readers to spend significant time and effort to follow the machine references in the headers if they want to understand who you are talking to, just to save you the one-off cost of turning on the phrase used when replying, which every mail and news client I know of supports (including Sylpheed); - you are saying that anyone reading this forum via unthreaded web archives don't matter; - and anyone who (for one reason or another) is missing some of the referenced posts, possibly because they have expired, or were never delivered in the first place. So please stop being rude, and follow the convention of both email and usenet (as well as broader society) to give attribution to those you quote. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python])
On 2014-08-12 10:11, Steven D'Aprano wrote: It is rude to deliberately refuse to give attributes While I find this true for first-level attribution, I feel far less obligation to attribute additional levels (and the verbosity they entail). If the reader is really that interested in who said what, then they can go back to previous posts to disinter that information. I find that On 2013-12-14 Ian Paul Freely wrote: On 2014-12-11 Xavier Onasis wrote: On 2014-12-10 Pat McCann wrote: On 2014-12-09 Mike Easter wrote: Lunch for Mary's birthday? How's Wednesday? Wed is good, what time? Earlier is better for me. 11:30? How about at that little Greek place on 4th Street? could just credit Ian and snip out the other attributions for the sake of quoting just the parts that I find matter. On 2013-12-14 Ian Paul Freely wrote: Lunch for Mary's birthday? How's Wednesday? Wed is good, what time? Earlier is better for me. 11:30? How about at that little Greek place on 4th Street? If I really care about who was associated with more historical comments, I'll pull up my message history and read the details. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python])
On Mon, 11 Aug 2014 19:27:25 -0500, Tim Chase wrote: On 2014-08-12 10:11, Steven D'Aprano wrote: It is rude to deliberately refuse to give attributes While I find this true for first-level attribution, I feel far less obligation to attribute additional levels (and the verbosity they entail). If the reader is really that interested in who said what, then they can go back to previous posts to disinter that information. I cannot disagree with that. I consider that the first-level attribution MUST be given, second-level SHOULD be given, and third- and subsequent levels MAY be given, where MUST/SHOULD/MAY have their conventional meanings from RFC 2119. https://www.ietf.org/rfc/rfc2119.txt With one proviso: if you respond *directly* to something quoted at the Nth-level, for any N, (as opposed to merely leaving it in to establish context), then you MUST given an attribution. Even if that attribution is just Sorry, I don't know who said this, you ought to make an honest effort to give credit to those you quote directly. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python])
On Tue, Aug 12, 2014 at 12:07 PM, Steven D'Aprano st...@pearwood.info wrote: I cannot disagree with that. I consider that the first-level attribution MUST be given, second-level SHOULD be given, and third- and subsequent levels MAY be given, where MUST/SHOULD/MAY have their conventional meanings from RFC 2119. https://www.ietf.org/rfc/rfc2119.txt That's fair. It's also very easy to give first-level attribution (just set your client up properly and that's that), while giving second-level means carefully retaining it from upstream. If it's easy (if you're quoting the beginning of the quote), then it's still of value, but it's not as important as first-level. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python])
On 2014-08-12 02:07, Steven D'Aprano wrote: It is rude to deliberately refuse to give attributes While I find this true for first-level attribution, I feel far less obligation to attribute additional levels (and the verbosity they entail). I cannot disagree with that. I consider that the first-level attribution MUST be given, second-level SHOULD be given, and third- and subsequent levels MAY be given With one proviso: if you respond *directly* to something quoted at the Nth-level, for any N, (as opposed to merely leaving it in to establish context), then you MUST given an attribution. For these case, I tend to do it interlinearly with my response, e.g. while you have some good points, I still lean towards Terry's recommendation to frobniculate the hammerjammer rather than have a long list of attributions at the top of the email. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux distros w/o Python in base installation
On 2014-08-11, Chris Angelico ros...@gmail.com wrote: On Tue, Aug 12, 2014 at 7:36 AM, Ned Deily n...@acm.org wrote: In article lsb84u$21c$1...@reader1.panix.com, Grant Edwards invalid@invalid.invalid wrote: Apparently. Perhaps theres an enable LSB compliance option somewhere in the Arch install docs, but I didn't see it... Also beware that, unlike most other distributions and contrary to recommended practice, Arch has chosen to make Python 3 its default, that is, when everything is installed, `python` invokes `python3`, rather than `python2`. So you may need to change shebang lines in scripts, etc. https://wiki.archlinux.org/index.php/python I noticed that when I told it to install python it wanted to install 3.4 before I told it no. Well, it only *became* contrary to recommended practice in response to Arch doing it and everyone seeing the issues it caused :) Personally, I'm glad they did. Lets those of us who follow slower distros (I'm running Debian) get the benefit of someone else's hindsight. At the moment, I only have python2 installed and have manually set up symlinks so that typing python does what the rest of the world (including me) expects. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Linux distros w/o Python in base installation
On Tuesday, August 12, 2014 12:23:57 AM UTC+5:30, Grant Edwards wrote:
I just installed Arch Linux for the first time, and was surprosed to
find that Python isn't installed as part of a base system. It's
also not included in the 'base-devel' package group. It's trivial to
install, but I'd still pretty surprised it's not there by default. I
guess I've spent too much time with Gentoo, Debian, and RedHat
derivitives which require Python be installed.
I've probably used at least a dozen Linux distros over the years, and
this is the first time I've noticed that Python wasn't installed by
default.
Just for the sake of curiosity, are there any other significant
desktop/server Linux distros that don't come out of the box with
Python?
I see on my system (debian Jessie aka 'testing') these packages installed:
lsb,
lsb-{base,core,cxx,desktop,graphics,languages,
multimedia,printing,release,security}
Dont remember the details but I think I had to install one/some maybe
(just lsb?) and that installed all the others.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is print thread safe?
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: Personally, I believe that print ought to do its own locking. And print is a statement, although in this case there's no need to support anything older than 2.6, so something like this ought to work: from __future__ import print_function _print = print _rlock = threading.RLock() def print(*args, **kwargs): with _rlock: _print(*args, **kwargs) Could this cause a deadlock if print were used in signal handlers? Marko -- https://mail.python.org/mailman/listinfo/python-list
[issue21514] update json module docs in light of RFC 7159 ECMA-404
Raymond Hettinger added the comment: Soonish. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21514 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Matej Cepl added the comment: Well, I hoped to get first some comments on the code itself (and especially the test). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
Changes by Christian Heimes li...@cheimes.de: -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22181 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21514] update json module docs in light of RFC 7159 ECMA-404
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: needs patch - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21514 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19055] Clarify docs for re module: why * does not match as many repetitions as possible.
Akira Li added the comment: tl;dr: added patch that clarifies Python re behavior. Please, review. --- The documented behavior is not clear: why (a|ab)* is not equivalent to (a|ab)(a|ab) for aba if the docs say as many repetitions as are possible? And it is not obvious (it is not the only possible behavior) e.g., POSIX [1] expects the longest match, PCRE [2] group may be atomic (/possesive quantifiers), or there is ungreedy repetition: $ echo abac | grep -o '\(a\|ab\)* # Basic Regular Expression aba $ echo abac | grep -Eo '(a|ab)*' # Extended Regular Expression aba $ echo abac | grep -Po '(a|ab)*' # PCRE (like Python regexes) a a $ echo abac | grep -Po '(a|ab)(a|ab)' # PCRE (two repeats) aba $ echo abac | grep -Po '(a|ab)*c' # PCRE (re-eval to match the rest) abac $ echo abAc | grep -iPo '(a|ab)*+c' # PCRE (possessive quantifiers) Ac $ echo abac | grep -Po '(a|ab)*?' # PCRE (ungreedy, zero repeats) # matches nothing where BREs, EREs are defined in [1] that says: If the pattern permits a variable number of matching characters and thus there is more than one such sequence starting at that point, *the longest such sequence is matched*. and: Consistent with the whole match being the longest of the leftmost matches, each subpattern, from left to right, *shall match the longest possible string.* Python regexes work like PCRE [2] that says: The matching process tries each alternative in turn, from left to right, and *the first one that succeeds is used*. If the alternatives are within a subpattern (defined below), succeeds means matching the rest of the main pattern as well as the alternative in the subpattern. It explains why (a|ab)* matches only a in aba (the first one that succeeds) and why at the same time (a|ab)*c matches abac: (a|ab) may match ab in the latter case because the main pattern would fail otherwise i.e., the advanced definition of succeeds is used: succeeds means matching the rest of the main pattern Python docs [3] are similar but do not contain the advanced succeeds definition: REs separated by ``'|'`` are tried from left to right. When one pattern completely matches, that branch is accepted. This means that once ``A`` matches, ``B`` will not be tested further, even if it would produce a longer overall match. In other words, the ``'|'`` operator is never greedy. It explains why (a|ab) matches a in aba. '*' behavior [2]: By default, the quantifiers are greedy, that is, they match as much as possible (up to the maximum number of permitted times), without causing the rest of the pattern to fail. and again Python docs [3] are similar: ``'*'`` Causes the resulting RE to match 0 or more repetitions of the preceding RE, as many repetitions as are possible. It implies that (a|ab)* should be equivalent to (a|ab)(a|ab) to match aba -- TWO REPETITIONS ARE MORE THAN ONE: as many repetitions as are possible. But it matches only 'a' i.e., it works as (a|ab) -- only one repetition instead of two. In reality, (a|ab)* along works like a*. I've uploaded a documentation patch that makes Python documentation for '|' more similar to PCRE and clarifies '*' definition as R. David Murray suggested in msg198126. Please, review. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html [2] http://man7.org/linux/man-pages/man3/pcrepattern.3.html [3] http://hg.python.org/cpython/file/18a311479e8b/Doc/library/re.rst -- components: -Regular Expressions keywords: +patch nosy: +akira title: Regular expressions: * does not match as many repetitions as possible. - Clarify docs for re module: why * does not match as many repetitions as possible. versions: +Python 3.5 -Python 2.7, Python 3.3 Added file: http://bugs.python.org/file36340/re-docs-repetitions.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19055] Clarify docs for re module: why * does not match as many repetitions as possible.
Changes by Akira Li 4kir4...@gmail.com: Removed file: http://bugs.python.org/file36340/re-docs-repetitions.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19055] Clarify docs for re module: why * does not match as many repetitions as possible.
Changes by Akira Li 4kir4...@gmail.com: Added file: http://bugs.python.org/file36341/re-docs-repetitions.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19055 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] Add xz support to shutil
Akira Li added the comment: sphinx generates warning for the current docs introduced by this issue: WARNING: Explicit markup ends without a blank line; unexpected unindent. I've uploaded a documentation patch that fixes it. -- nosy: +akira Added file: http://bugs.python.org/file36342/docs-fix-sphinx-warning.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Matej Cepl added the comment: This is a patch with tests working for the tip of cpython. -- hgrepos: +267 Added file: http://bugs.python.org/file36343/fix-issue19494-py35.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Changes by Matej Cepl mc...@redhat.com: -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Changes by Matej Cepl mc...@redhat.com: Added file: http://bugs.python.org/file36344/fix-issue19494-py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Matej Cepl added the comment: Mercurial seems to be incredibly slow to clone, for anybody who is willing to deal with git, my real repo is http://luther.ceplovi.cz/git/cpython.git/ (branches basicAuth19494 and basicAuth19494_py3k). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22182] distutils.file_util.move_file unpacks wrongly an exception
New submission from Claudiu Popa: Hi. When os.rename fails inside distutils.file_util.move_file, the exception is unpacked using ``(num, msg) = e``. While this was valid in Python 2, in Python 3 it should be ``e.args``. The attached patched fixes this. -- components: Distutils files: distutils_unpacking_exception.patch keywords: patch messages: 225184 nosy: Claudiu.Popa, dstufft, eric.araujo priority: normal severity: normal status: open title: distutils.file_util.move_file unpacks wrongly an exception type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file36345/distutils_unpacking_exception.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22182 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22182] distutils.file_util.move_file unpacks wrongly an exception
Claudiu Popa added the comment: Mm, it seems there's another instance of unpacking later on, when os.unlink fails. Here's the updated patch. -- Added file: http://bugs.python.org/file36346/issue22182.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22182 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22118] urljoin fails with messy relative URLs
Demian Brecht added the comment: Uploaded new patch. Removed support for RFC1808-specific behaviour. Extracted non-compliant tests into comment blocks indicating the behaviour is no longer supported. -- Added file: http://bugs.python.org/file36347/issue22118_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22118] urljoin fails with messy relative URLs
Mike Lissner added the comment: Just hopping in here to say that the work going down here is beautiful. I've filed a lot of bugs. This one's not particularly difficult, but damn, I appreciate the speed and quality going into fixing it. Glad to see the Python language is a happy place with fast, quality fixes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22183] datetime.timezone methods require datetime object
New submission from Patrick Westerhoff: I’ve noticed that the methods in `datetime.timezone` all require a datetime object (or explicitely `None`) as its parameter or they will raise an exception. The datetime object however is never required for the implementation of the method, so it seems to me like an unnecessary requirement, given that timezone objects are completely independent of datetime objects. For example `timezone.utcoffset` is implemented like this: def utcoffset(self, dt): if isinstance(dt, datetime) or dt is None: return self._offset raise TypeError(utcoffset() argument must be a datetime instance or None) I don’t really understand this requirement and if there isn’t an actual reason for it (if there is, it should be documented somewhere), I’d suggest to remove this requirement completely. For backwards compatibility, the parameter could simply default to `None`. -- components: Library (Lib) messages: 225188 nosy: poke priority: normal severity: normal status: open title: datetime.timezone methods require datetime object type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22183 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22183] datetime.timezone methods require datetime object
R. David Murray added the comment: A timezone is a particular implementation of the general tzinfo API, and in the general case the datetime argument *is* required. This is already documented (ie: that timezone is a concrete implementation of tzinfo, and that the tzinfo API requires the datetime). -- nosy: +belopolsky, r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22183 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22118] urljoin fails with messy relative URLs
Demian Brecht added the comment: Thanks Mike, it's always nice to get positive feedback :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22183] datetime.timezone methods require datetime object
Alexander Belopolsky added the comment: As David explained, utcoffset() method signature is dictated by the base class. This is not a bug. -- resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22183 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
R. David Murray added the comment: This patch looks like a feature addition rather than the discussed optimization of always sending auth on the first request. As such it could only go into 3.5. I'm also adding Nick Coghlan to nosy, for his opinion on whether or not this optimization/bug-fix-for-issue-caused-by-greater-3rd-party-security-conciousness is something that we do indeed want to be considering for 2.7 in any case. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] Add xz support to shutil
Berker Peksag added the comment: Fixed. Thanks for the patch, Akira. http://hg.python.org/cpython/rev/7fcfb634ccca -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22083] Refactor PyShell's breakpoint related methods
Saimadhav Heblikar added the comment: This patch does two things 1. Refactor pyshell-breakpoint-refactor.diff to reflect changes in pyshell-breakpoint-refactor.diff As in pyshell-breakpoint-refactor.diff, the set/clear(_here) breakpoint methods are refactored into logical methods. 2. If the filename is not set, text.bell() is replaced with a dialog to prompt the user to save the file. -- Added file: http://bugs.python.org/file36348/pyshell-breakpoint-refactor-v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22083 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14105] Breakpoints in debug lost if line is inserted; IDLE
Saimadhav Heblikar added the comment: While working on issue22083, I noticed a few redundant comments. This patch removes them. -- keywords: +patch Added file: http://bugs.python.org/file36349/remove-pyshell-comment.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14105 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
Matej Cepl added the comment: This patch looks like a feature addition rather than the discussed optimization of always sending auth on the first request. As such it could only go into 3.5. ??? I was trying hard not to break current API, so I have created a new handler to be on the safe side, exactly in order to make it more palatable for 2.7.*. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
R. David Murray added the comment: But that introduces a new element of the API, which is an API change. I thought the plan was to change the existing code to always send the auth when it was available. Why would that change the API? (Maybe it does...I haven't looked into this issue in any depth.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
