Re: code review
On Sun, 01 Jul 2012 14:23:36 +1000, Chris Angelico wrote: On Sun, Jul 1, 2012 at 2:17 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Nonsense. Of course parens change the evaluation of the expression. That's what parens are for! The whole point of my example was that it wouldn't. Yes, you can find specially crafted examples where adding parentheses in certain places, but not others, doesn't change the overall evaluation of the expression. So what? IN GENERAL, adding parentheses changes the evaluation of the expression -- that is what they are for. Therefore, IN GENERAL you should expect that adding parentheses will change the result, unless you carefully place them where you know that they will have no effect. Even in C, I can't just do this: 2+3*4 = (2+3)*4 with the expectation that you can stick parentheses around the left-most term without changing the value. The fact that you can do for some expressions is irrelevant. In general, if you don't know the semantics of an expression (including the operator precedence), you cannot just assume that adding parens is harmless. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, Jul 1, 2012 at 4:27 PM, Steven D'Aprano steve+use...@pearwood.info wrote: Yes, you can find specially crafted examples where adding parentheses in certain places, but not others, doesn't change the overall evaluation of the expression. My point was that adding parentheses around the tightest-binding operator is a common, clear, and usually insignificant, way of demonstrating operator precedence. So FOR THAT USE they must not change evaluation of the expression. Obviously if you put them anywhere else, they change evaluation. Nice job knocking down a straw man. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, 01 Jul 2012 13:48:04 +1000, Chris Angelico wrote: On Sun, Jul 1, 2012 at 1:23 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: All the worse for those languages, since they violate the semantics of mathematical notation. Not so. It simply means that booleans are nothing special. In REXX, there are no data types at all, and 1 and 0 are your booleans. In C, boolean and comparison operations return integers, either 1 or 0. This has nothing to do with the presence of a Boolean type or not. It is about syntax, not types. Python didn't have bools until relatively recently but it still had chained comparisons. In Python2.1 and older, boolean and comparison operations return integers, either 1 or 0, precisely the same as C. You can even use chained comparisons for types that don't interpret the operators as comparisons: py class Funny: ... def __init__(self, x): ... self.x = x ... def __lt__(self, other): ... return Funny(self.x + 3*other.x) ... def __str__(self): ... return str(self.x) ... py a = Funny(2) py b = Funny(3) py c = Funny(4) py py print a b c 15 py print (a b) and (b c) 15 Although the interpretation of such may not be useful. Same was true of Python early on, if I understand correctly. It's not shameful. The first public release of Python, 0.9, included chained comparisons. This was even before the language had == for equality tests! steve@runes:~$ ./python0.9.1 print 2 3 4 1 print 2 = 2 = 2 1 print (2 = 2) = 2 0 So no, Python has always included chained comparisons, and yes, it is shameful that a language would force you to unlearn standard notation in favour of a foolish consistency with other operators. Comparisons aren't special because they return bools. They are special because of the way they are used. C treats comparison operators as if they were arithmetic operators, and so the behaviour of a chained comparison is the same as the behaviour as a sequence of arithmetic operators: a foolish consistency. Python treats comparison operators as comparison operators, and gives them behaviour appropriate to comparisons. The fact that so many languages do the wrong thing here, and so few emulate standard mathematical notation, is symptomatic of the lousy state of language design. Pascal might be verbose, but at least it makes it harder to write code that silently does the wrong thing -- it prevents you from writing chained comparisons which do the wrong thing, and forces you to be explicit. C has the worst of both worlds: - it allows the standard concise mathematical notation a x b - but it quietly changes the semantics to something that the user hardly ever wants thus giving the maximum number of bugs with the minimum amount of convenience. The more I learn about C, the less I want to know about C. What sort of crazy language designer thought that having 2 == 2 == 2 return 0 (false) was a good idea? It makes perfect sense though; Not in English-speaking countries with a culture of writing chained comparisons in mathematics and allowing them in natural language: Rock is beaten by Paper, is beaten by Scissors. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, Jul 1, 2012 at 4:54 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Not in English-speaking countries with a culture of writing chained comparisons in mathematics and allowing them in natural language: Rock is beaten by Paper, is beaten by Scissors. I would write that as: Rock is beaten by Paper, and beats Scissors. That's natural language. Unless you put a which in the middle, the grammar of English demands that the subject be common, not a promoted object. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: code review
Evan Driscoll wrote: On 6/30/2012 19:37, Chris Angelico wrote: On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: I know of no programming language that would give a newcomer to Python that expectation. So where is the norm you're referring to? C, SQL, REXX, and many other languages. Some others: Lua, Javascript, Ruby, O'Caml. JFTR: Contrary to popular belief there is no programming language named Javascript. In your second point, you are talking about ECMAScript implementations; one of which is _JavaScript_, Netscape's and later Mozilla.org's ECMAScript implementation. Other implementations include that of Microsoft, JScript. http://PointedEars.de/es-matrix -- PointedEars Please do not Cc: me. / Bitte keine Kopien per E-Mail. -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
Evan Driscoll wrote: On 6/30/2012 23:45, Evan Driscoll wrote: You may also want to put Java in there as well, as is effectively not commutative in that language. (I didn't try C#.) I guess you could actually put Lua and Ruby into the roughly same category as Java too. But things get a little nastier in ==, as 'false == false == false' evaluates as '(false == false) == false' to 'false' in Java and Lua. (Ruby produces a syntax error for this, roughly the Haskell approach.) But we have Javascript: s/Javascript/ECMAScript (implementations)/g 1 1 2 = true false == false == false = false Correct, because 0. 1 1 2 1. (1 1) 2 2. false 2 3. 0 2 4. true and 0. false == false == false 1. (false == false) == false 2. true == false 3. false See also the ECMAScript Language Specification, 5.1 Edition, section 11.9: http://ecma-international.org/ecma-262/5.1/#sec-11.9 -- PointedEars Please do not Cc: me. / Bitte keine Kopien per E-Mail. -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
Chris Angelico ros...@gmail.com writes: On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Thomas Jollans t...@jollybox.de writes: My sole point, really, is that normally, one would expect these two expressions to be equivalent: a b c (a b) c What norm gives you that expectation? That's not how those operators work in mathematical notation. I know of no programming language that would give a newcomer to Python that expectation. So where is the norm you're referring to? C, SQL, REXX, and many other languages. So, languages without strong typing then. In that case, I revise my statement: I know of no programming language with strong typing that would give a newcomer to Python the above expectation. Since Python does have strong typing, norms about operations from weakly-typed languages should not be expected to apply. (Incidentally, PostgreSQL was the SQL implementation I went to, and:: postgres=# SELECT (1 2) 3; ERROR: operator does not exist: boolean integer LINE 1: SELECT (1 2) 3; ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. So not all SQL implementations make the mistake of weak typing.) -- \ “Try adding “as long as you don't breach the terms of service – | `\ according to our sole judgement” to the end of any cloud | _o__) computing pitch.” —Simon Phipps, 2010-12-11 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On 07/01/2012 04:06 AM, Steven D'Aprano wrote: On Sun, 01 Jul 2012 00:05:26 +0200, Thomas Jollans wrote: As soon as you read it as a ternary operator, Well that's your problem. Why are you reading it as a ternary operator? It isn't one. It is a pair of chained binary operator. How can you tell that it is a pair of binary operators, rather than a single ternary operator? 1) There are TWO operators, hence a pair, not a single ternary operator; 2) each operator takes TWO arguments, not three. This is simply wrong. The comparisons are not acting as binary operators. You can't just arbitrarily stick parentheses around parts of expressions and expect the result to remain unchanged. Order of evaluation matters: 2**3**4 != (2**3)**4 Comparisons are no different. You can't just toss in some arbitrary brackets and expect the result to be the same. In the second case, the parentheses explicitly turn the comparison into the equivalent of this: As Chris points out, 2**3**4 == 2**(3**4) For any chain of actual binary operators, it is possible to place brackets around binary sub-expressions such that the meaning of the total expression stays the same. This is true of ALL infix-notated strictly binary operators. This is not true of Python comparison operators. If you're inclined to look at operators in terms of how many arguments they take, then the inescapable conclusion is that a chain of N comparison operators forms one single (N+1)-term operator because it cannot be grouped into binary expressions without rephrasing the expression using and. -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On 07/01/2012 09:28 AM, Ben Finney wrote: Chris Angelico ros...@gmail.com writes: On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Thomas Jollans t...@jollybox.de writes: My sole point, really, is that normally, one would expect these two expressions to be equivalent: a b c (a b) c What norm gives you that expectation? That's not how those operators work in mathematical notation. I know of no programming language that would give a newcomer to Python that expectation. So where is the norm you're referring to? C, SQL, REXX, and many other languages. So, languages without strong typing then. In that case, I revise my statement: I know of no programming language with strong typing that would give a newcomer to Python the above expectation. Since Python does have strong typing, norms about operations from weakly-typed languages should not be expected to apply. (Incidentally, PostgreSQL was the SQL implementation I went to, and:: postgres=# SELECT (1 2) 3; ERROR: operator does not exist: boolean integer LINE 1: SELECT (1 2) 3; ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. So not all SQL implementations make the mistake of weak typing.) I don't have PostgeSQL handy just now - what is the result of (1 2 3) ? I bet it's the same error, which means the two are still equivalent. Look through the part of this thread about languages, and you will see how unique Python is in this regard. You argument about strong typing doesn't really hold: in Python, as in some other languages, bool is an integer type, so it can actually be compared to numbers, so even if Python used the same rules as Java, chaining comparison operators would still be valid syntax (if a little silly in most cases) -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, Jul 1, 2012 at 3:28 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Chris Angelico ros...@gmail.com writes: C, SQL, REXX, and many other languages. So, languages without strong typing then. In that case, I revise my statement: I know of no programming language with strong typing that would give a newcomer to Python the above expectation. OCaml is a language with absurdly strong typing, where a b c is equivalent to (a b) c. Obviously, this only works if c is a boolean, and if a and b are the same type. Otherwise it is a type error. Also, you claimed earlier that the notion of associative is not founded in mathematical notation. It really depends on whose mathematical notation you use -- there's more than one, you know. For example, it's reasonable to expect to be left- or right-associative in a system like Rick Hehner's Unified Algebra: http://www.cs.toronto.edu/~hehner/UA.pdf (although, he himself doesn't specify it as being one or the other, so by default one would assume 'a b c' to be nonsensical.) -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: changes made to my python coded com servers are not taking effect
On Sun, 01 Jul 2012 02:13:23 -0700, Panceisto wrote: I assume the old code keeps running in some process somewhere. How to fix this? stop restart the servers after making the changes -- Smoking is the leading cause of statistics. -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sat, 30 Jun 2012 23:45:25 -0500, Evan Driscoll wrote: On 6/30/2012 19:37, Chris Angelico wrote: On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: I know of no programming language that would give a newcomer to Python that expectation. So where is the norm you're referring to? C, SQL, REXX, and many other languages. Some others: Lua, Javascript, Ruby, O'Caml. In fact, the only language I can find that uses infix notation (i.e. no Lisp) where it's *not* true that a b c is equivalent to (a b) c is Haskell -- and that's because is not associative and a b c is a syntax error. (FWIW this is my favorite approach.) You may also want to put Java in there as well, as is effectively not commutative in that language. (I didn't try C#.) I've been programming in Python for a few years and this is the first time I've seen this. If I had seen that in a program, I'd have assumed it was a bug. Evan You would? I have only been using python for 6 - 12 months but in my past I programmed microcontrollers in assembly. as soon as i saw it i understood it thought great, like a light bulb going on. I suppose I have the advantage that it is only the taint of BASIC (in the home computer era) that I have had to overcome and my programming style has not been unduly influenced by c others. it is easy to write C, or Pascal or even BASIC in python but why bother, why not just use C, Pascal or BASIC in that case? -- I respect faith, but doubt is what gives you an education. -- Wilson Mizner -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On 7/1/2012 2:54 AM, Steven D'Aprano wrote: So no, Python has always included chained comparisons, and yes, it is shameful that a language would force you to unlearn standard notation in favour of a foolish consistency with other operators. Comparisons aren't special because they return bools. They are special because of the way they are used. C treats comparison operators as if they were arithmetic operators, and so the behaviour of a chained comparison is the same as the behaviour as a sequence of arithmetic operators: a foolish consistency. Python treats comparison operators as comparison operators, and gives them behaviour appropriate to comparisons. I considered this a great feature of Python when I first learned it. Reading about how rare it is among programming languages to treat comparisons in the standard way in mathematics reinforces that. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] IPython 0.13 is officially out!
On 2012-07-01 01:55 +0800, Fernando Perez wrote: - ~6 months of work. - 373 pull requests merged. - 742 issues closed (non-pull requests). - contributions from 62 authors. - 1760 commits. - a diff of 114226 lines. Thank you for the hard work. Leo -- http://mail.python.org/mailman/listinfo/python-list
Fwd: Python-list Digest, Vol 106, Issue 1
(a2 + b2 = c2) = (e | P a P b P c) Beschreibt eine Disonanz in Genese. -- Weitergeleitete Nachricht -- Von: python-list-requ...@python.org Datum: 30.06.2012 23:09 Betreff: Python-list Digest, Vol 106, Issue 1 An: python-list@python.org Send Python-list mailing list submissions to python-list@python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-list or, via email, send a message with subject or body 'help' to python-list-requ...@python.org You can reach the person managing the list at python-list-ow...@python.org When replying, please edit your Subject line so it is more specific than Re: Contents of Python-list digest... Today's Topics: 1. Re: code review (Alister) 2. Re: code review (Alister) 3. Re: code review (Thomas Jollans) 4. Re: code review (Alain Ketterlin) 5. Re: code review (Thomas Jollans) 6. Re: tiffany 0.6.1 released (Christian Heimes) 7. Re: code review (Terry Reedy) 8. Re: code review (Martin P. Hellwig) 9. Re: code review (Thomas Jollans) 10. Re: code review (Alain Ketterlin) -- Weitergeleitete Nachricht -- From: Alister alister.w...@ntlworld.com To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 20:25:39 GMT Subject: Re: code review On Sat, 30 Jun 2012 12:29:31 +0200, Peter Otten wrote: Alister wrote: I think I may be on firmer grounds with the next few: isValidPassword can be simplified to def isValidPassword(password: count=len(password) return count= mud.minpass and count= mud.maxpass ( I used count to save finding the length of password twice although it probably makes no difference in this scenario) If you spell it def is_valid_password(password): return mud.minpass = len(password) = mud.maxpass it is even easier to see that you are performing an interval check. I realise that was possible, that is brilliant! it is exactly how you would write it ass a mathematical definition. -- The only real way to look younger is not to be born so soon. -- Charles Schulz, Things I've Had to Learn Over and Over and Over -- Weitergeleitete Nachricht -- From: Alister alister.w...@ntlworld.com To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 20:30:45 GMT Subject: Re: code review On Sat, 30 Jun 2012 21:38:58 +0200, Thomas Jollans wrote: On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote: Peter Otten wrote: If you spell it def is_valid_password(password): return mud.minpass = len(password) = mud.maxpass it is even easier to see that you are performing an interval check. This is probably a tautology around here, but *what* *a* *great* *programming* *language*. Personally, I don't like this feature of the language. I find a ternary operator that uses symbols that can also be binary operators confusing and inconsistent with the way operators usually work/the way terms are usually associated. It has the charm of being something you'd naturally write in the context of non-programming mathematics, at the cost of being very odd indeed in the context of programming in general and Python in particular. Surely this fits perfectly with the lines 1 7 in the zen of python (import this) Beautifull is better than ugly and Readability counts I find that construct both beautiful and readable, if it cannot be used in the languages then that is their loss. -- Removing the straw that broke the camel's back does not necessarily allow the camel to walk again. -- Weitergeleitete Nachricht -- From: Thomas Jollans t...@jollybox.de To: python-list@python.org Cc: Date: Sat, 30 Jun 2012 22:50:43 +0200 Subject: Re: code review On 06/30/2012 10:30 PM, Alister wrote: On Sat, 30 Jun 2012 21:38:58 +0200, Thomas Jollans wrote: On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote: Peter Otten wrote: If you spell it def is_valid_password(password): return mud.minpass = len(password) = mud.maxpass it is even easier to see that you are performing an interval check. This is probably a tautology around here, but *what* *a* *great* *programming* *language*. Personally, I don't like this feature of the language. I find a ternary operator that uses symbols that can also be binary operators confusing and inconsistent with the way operators usually work/the way terms are usually associated. It has the charm of being something you'd naturally write in the context of non-programming mathematics, at the cost of being very odd indeed in the context of programming in general and Python in particular. Surely this fits perfectly with the lines 1 7 in the zen of python (import this) Beautifull is better than ugly and Readability counts I find that construct both beautiful and readable, if it cannot be used in the languages then that is their loss. Are we quoting the Zen now? Contra: In re
Re: how to use tkinter in python3.2?
On 01.07.12 07:25, contro opinion wrote: i have installed tk ,how to use tkinker in python3.2? You must install tk-dev (or whatever it's called on your system) before Python building (don't forget to rerun configure). -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] IPython 0.13 is officially out!
On 01-Jul-2012 13:56, Leo wrote: On 2012-07-01 01:55 +0800, Fernando Perez wrote: - ~6 months of work. - 373 pull requests merged. - 742 issues closed (non-pull requests). - contributions from 62 authors. - 1760 commits. - a diff of 114226 lines. Thank you for the hard work. Leo I have tried to update 0.12 in Ubuntu 12.04 but as of now it can not find 0.13. Any suggestions on how to get it into Ubuntu 12.04 would be appreciated. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: code review
On 7/1/2012 4:54, Alister wrote: On Sat, 30 Jun 2012 23:45:25 -0500, Evan Driscoll wrote: If I had seen that in a program, I'd have assumed it was a bug. You would? I have only been using python for 6 - 12 months but in my past I programmed microcontrollers in assembly. as soon as i saw it i understood it thought great, like a light bulb going on. It's not a matter of I wouldn't have understood what the author was trying to do (with a small caveat), it's a matter of I'd have assumed that the author didn't understand the language semantics. I'm pretty sure it goes contrary to *every other programming language I've ever used* (and a couple that I haven't). I understand why Python does it, and it certainly is nice in that it matches typical mathematical notation, but the surprise quotient is *very* high in the PL world IMO. Evan -- http://mail.python.org/mailman/listinfo/python-list
Re: [ANN] IPython 0.13 is officially out!
On 2012-07-01, Virgil Stokes v...@it.uu.se wrote: I have tried to update 0.12 in Ubuntu 12.04 but as of now it can not find 0.13. Any suggestions on how to get it into Ubuntu 12.04 would be appreciated. Install pip and use it to upgrade ipython: sudo apt-get install python-pip sudo pip install --upgrade ipython Dave Cook -- http://mail.python.org/mailman/listinfo/python-list
when normal parallel computations in CPython will be implemented at last?
hi all, are there any information about upcoming availability of parallel computations in CPython without modules like multiprocessing? I mean something like parallel for loops, or, at least, something without forking with copying huge amounts of RAM each time and possibility to involve unpiclable data (vfork would be ok, but AFAIK it doesn't work with CPython due to GIL). AFAIK in PyPy some progress have been done ( http://morepypy.blogspot.com/2012/06/stm-with-threads.html ) Thank you in advance, D. -- http://mail.python.org/mailman/listinfo/python-list
Re: when normal parallel computations in CPython will be implemented at last?
If something happens with this for CPython, it'll likely come from Pypy developers first. They seem to be interested in doing things in a way that is (or can be made) compatible with CPython. If you want to help them along, they're taking donations to fund the work, or you could donate your own time. Bear in mind that CPython threads fine for I/O-heavy workloads. It's CPU-bound workloads that CPython doesn't thread super well. Last I heard, both Jython and IronPython thread well today, and there's little reason not to try them if you have a (rather rare) application that truly needs Java-like threading. Granted, they don't run C extension modules, but there's quite a bit of portability synergy to be had from coming up with Pure Python alternatives; it's quite feasible to run the same code on CPython 2.x, CPython 3.x, Pypy and Jython. IronPython, sadly, lacks a python standard library. If CPython has trouble with CoW, it's probably because of reference counting, not the GIL. Last I heard, CPython used both reference counting and garbage collection. Also, vfork is a bit of a hack... just plain fork is often a better way to go. On Sun, Jul 1, 2012 at 10:51 AM, dmitrey dmitre...@gmail.com wrote: hi all, are there any information about upcoming availability of parallel computations in CPython without modules like multiprocessing? I mean something like parallel for loops, or, at least, something without forking with copying huge amounts of RAM each time and possibility to involve unpiclable data (vfork would be ok, but AFAIK it doesn't work with CPython due to GIL). AFAIK in PyPy some progress have been done ( http://morepypy.blogspot.com/2012/06/stm-with-threads.html ) -- http://mail.python.org/mailman/listinfo/python-list
Re: when normal parallel computations in CPython will be implemented at last?
On 07/01/2012 07:51 PM, dmitrey wrote: hi all, are there any information about upcoming availability of parallel computations in CPython without modules like multiprocessing? I mean something like parallel for loops, or, at least, something without forking with copying huge amounts of RAM each time and possibility to involve unpiclable data (vfork would be ok, but AFAIK it doesn't work with CPython due to GIL). AFAIK in PyPy some progress have been done ( http://morepypy.blogspot.com/2012/06/stm-with-threads.html ) As far as I can tell, there are no concrete plans to integrate concurrency better, or get rid of the GIL, at the moment. To quote http://wiki.python.org/moin/GlobalInterpreterLock Getting rid of the GIL is an occasional topic on the python-dev mailing list. No one has managed it yet. There are currently no open or accepted PEPs on the subject of concurrency. http://www.python.org/dev/peps/ There is, of course, Stackless Python. http://stackless.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: when normal parallel computations in CPython will be implemented at last?
On 07/01/2012 08:44 PM, Dan Stromberg wrote: IronPython, sadly, lacks a python standard library. Beg pardon? https://github.com/IronLanguages/main/tree/master/External.LCA_RESTRICTED/Languages/IronPython/27/Lib -- http://mail.python.org/mailman/listinfo/python-list
Re: when normal parallel computations in CPython will be implemented at last?
On 7/1/2012 1:53 PM, Thomas Jollans wrote: As far as I can tell, there are no concrete plans to integrate concurrency better, or get rid of the GIL, at the moment. To quote http://wiki.python.org/moin/GlobalInterpreterLock Getting rid of the GIL is an occasional topic on the python-dev mailing list. No one has managed it yet. There's also this, recently written by one of CPython's core devs: http://python-notes.boredomandlaziness.org/en/latest/python3/questions_and_answers.html#but-but-surely-fixing-the-gil-is-more-important-than-fixing-unicode -- CPython 3.3.0a4 | Windows NT 6.1.7601.17803 -- http://mail.python.org/mailman/listinfo/python-list
Re: when normal parallel computations in CPython will be implemented at last?
On Sun, Jul 1, 2012 at 11:58 AM, Thomas Jollans t...@jollybox.de wrote: On 07/01/2012 08:44 PM, Dan Stromberg wrote: IronPython, sadly, lacks a python standard library. Beg pardon? https://github.com/IronLanguages/main/tree/master/External.LCA_RESTRICTED/Languages/IronPython/27/Lib Perhaps things have changed. When I last checked the situation, IronPython came with no standard library, but you could bolt one on that hadn't been tested well - IIRC, just a simple import os gave a traceback. FePy was IronPython with a standard library and some degree of testing, but their emphasis was windows-only. I'd be open to using FePy instead, and I might even call it IronPython, but I'm not in the habit of happily using software that is Windows only. -- http://mail.python.org/mailman/listinfo/python-list
Re: when normal parallel computations in CPython will be implemented at last?
On 07/01/2012 09:28 PM, Dan Stromberg wrote: On Sun, Jul 1, 2012 at 11:58 AM, Thomas Jollans t...@jollybox.de mailto:t...@jollybox.de wrote: On 07/01/2012 08:44 PM, Dan Stromberg wrote: IronPython, sadly, lacks a python standard library. Beg pardon? https://github.com/IronLanguages/main/tree/master/External.LCA_RESTRICTED/Languages/IronPython/27/Lib Perhaps things have changed. When I last checked the situation, IronPython came with no standard library, but you could bolt one on that hadn't been tested well - IIRC, just a simple import os gave a traceback. FePy was IronPython with a standard library and some degree of testing, but their emphasis was windows-only. I'd be open to using FePy instead, and I might even call it IronPython, but I'm not in the habit of happily using software that is Windows only. That must have been quite a while ago? I haven't tested it recently, but I'm fairly sure that IronPython includes a Python standard library which works reasonably well, and it's not Windows-only. (it works with Mono) -- http://mail.python.org/mailman/listinfo/python-list
Re: when normal parallel computations in CPython will be implemented at last?
Thomas Jollans t...@jollybox.de wrote: There is, of course, Stackless Python. http://stackless.com/ Stackless Python doesn't really address the original poster's problem as the GIL still effectively limits Python code running in one thread at a time. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] rri...@csclub.uwaterloo.ca -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, 01 Jul 2012 09:46:56 +0200, Thomas Jollans wrote: I don't have PostgeSQL handy just now - what is the result of (1 2 3) ? I bet it's the same error, which means the two are still equivalent. $ psql misc psql (9.1.4) Type help for help. misc=# select (1 2); ?column? -- t (1 row) misc=# select (1 2 3); ERROR: syntax error at or near LINE 1: select (1 2 3); ^ misc=# -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, 01 Jul 2012 05:18:09 -0400, Devin Jeanpierre wrote: Also, you claimed earlier that the notion of associative is not founded in mathematical notation. It really depends on whose mathematical notation you use -- there's more than one, you know. For example, it's reasonable to expect to be left- or right-associative in a system like Rick Hehner's Unified Algebra: http://www.cs.toronto.edu/~hehner/UA.pdf (although, he himself doesn't specify it as being one or the other, so by default one would assume 'a b c' to be nonsensical.) Sheesh guys. Don't go hunting through the most obscure corners of mathematics for examples of computer scientists who have invented their own maths notation. (Which, by your own admission, is under-specified and therefore incomplete.) Who uses Hehner's Unified Algebra notation? Apart from Hehner, if he even uses it himself. Pick up any standard maths book and you will see chained comparisons used with exactly the meaning that Python gives them. For example, Wolfram MathWorld uses it: http://mathworld.wolfram.com/Inequality.html Chained comparisons in the Python sense may be rare in computer languages, but it is the standard in mathematics and hardly needs to be explained to anyone over the age of twelve. That is a terrible indictment on the state of programming language design. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, 01 Jul 2012 09:35:40 +0200, Thomas Jollans wrote: On 07/01/2012 04:06 AM, Steven D'Aprano wrote: On Sun, 01 Jul 2012 00:05:26 +0200, Thomas Jollans wrote: As soon as you read it as a ternary operator, Well that's your problem. Why are you reading it as a ternary operator? It isn't one. It is a pair of chained binary operator. How can you tell that it is a pair of binary operators, rather than a single ternary operator? 1) There are TWO operators, hence a pair, not a single ternary operator; 2) each operator takes TWO arguments, not three. This is simply wrong. The comparisons are not acting as binary operators. Of course they are. Take this chained comparison: a b == c There are exactly TWO operators. Each one takes TWO arguments. The operator takes a and b as arguments. That's TWO, not three. The == operator takes b and c arguments. Again, that's TWO, not three. If you want to claim that this is a ternary operator, you need to explain: 1) What is the operator in this expression? Is it or == or something else? 2) What double-underscore special method does it call? Where is this mysterious, secret, undocumented method implemented? 3) Why do the Python docs lie that a b == c is exactly equivalent to the short-circuit expression (a b) and (b == c) with b evaluated once? 4) And how do you explain that the compiled byte code actually calls the regular two-argument binary operators instead of your imaginary three- argument ternary operator? py from dis import dis py dis(compile(a b == c, , single)) 1 0 LOAD_NAME0 (a) 3 LOAD_NAME1 (b) 6 DUP_TOP 7 ROT_THREE 8 COMPARE_OP 0 () 11 JUMP_IF_FALSE_OR_POP23 14 LOAD_NAME2 (c) 17 COMPARE_OP 2 (==) 20 JUMP_FORWARD 2 (to 25) 23 ROT_TWO 24 POP_TOP 25 PRINT_EXPR 26 LOAD_CONST 0 (None) 29 RETURN_VALUE -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: changes made to my python coded com servers are not taking effect
On 1/07/2012 7:13 PM, Panceisto wrote: I assume the old code keeps running in some process somewhere. How to fix this? The client of your server still has a reference to the old server. The simplest solution is to restart those clients. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, 01 Jul 2012 05:55:24 -0400, Terry Reedy wrote: On 7/1/2012 2:54 AM, Steven D'Aprano wrote: So no, Python has always included chained comparisons, and yes, it is shameful that a language would force you to unlearn standard notation in favour of a foolish consistency with other operators. Comparisons aren't special because they return bools. They are special because of the way they are used. C treats comparison operators as if they were arithmetic operators, and so the behaviour of a chained comparison is the same as the behaviour as a sequence of arithmetic operators: a foolish consistency. Python treats comparison operators as comparison operators, and gives them behaviour appropriate to comparisons. I considered this a great feature of Python when I first learned it. Reading about how rare it is among programming languages to treat comparisons in the standard way in mathematics reinforces that. Apart from Python, Mathematica, Perl 6, CoffeeScript, Cobra and Clay give chained comparisons the standard meaning. It is, or was, a feature request for Boo, but I can't tell whether it has been implemented or not. C-like semantics are next to useless, except perhaps for obfuscation: http://stackoverflow.com/questions/4089284/why-does-0-5-3-return-true/ And surprising: http://answers.yahoo.com/question/index?qid=20090923172909AA4O9Hx C-like semantics are a clear case of purity of implementation overruling functional usefulness. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, 01 Jul 2012 16:33:15 +1000, Chris Angelico wrote: On Sun, Jul 1, 2012 at 4:27 PM, Steven D'Aprano steve+use...@pearwood.info wrote: Yes, you can find specially crafted examples where adding parentheses in certain places, but not others, doesn't change the overall evaluation of the expression. My point was that adding parentheses around the tightest-binding operator is a common, clear, and usually insignificant, way of demonstrating operator precedence. So FOR THAT USE they must not change evaluation of the expression. Obviously if you put them anywhere else, they change evaluation. Nice job knocking down a straw man. We *really did have* somebody arguing that chained comparisons are Bad because you can't stick parentheses around bits of it without changing the semantics. That was an actual argument, not a straw-man. It's a stupid argument, but don't blame me for pointing out it's stupidity. The author *assumed* that a chain of must be left- associative in the same way that a chain of + operators is left- associative, but it isn't. That's an invalid and unsafe assumption -- even in C-like languages, there are operators which aren't left- associative, e.g. exponentiation ** which is usually right-associative. (For the record, C itself doesn't have an exponentiation operator.) When you make unsafe assumptions about an operator, and get bitten by it, the *correct* conclusion should be that the assumption was wrong, not that the language is wrong. Technically, in Python is left-associative: a b c first evaluates a, not b or c. But it is left-associative under the rules of comparison operator chaining, not arithmetic operator chaining. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, Jul 1, 2012 at 8:41 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sun, 01 Jul 2012 05:18:09 -0400, Devin Jeanpierre wrote: Sheesh guys. Don't go hunting through the most obscure corners of mathematics for examples of computer scientists who have invented their own maths notation. (Which, by your own admission, is under-specified and therefore incomplete.) Who uses Hehner's Unified Algebra notation? Apart from Hehner, if he even uses it himself. I didn't hunt, I was taught it in university. -- Devin (Of course, it shouldn't be hard to guess who the professor was :) -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, Jul 1, 2012 at 9:28 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Technically, in Python is left-associative: a b c first evaluates a, not b or c. But it is left-associative under the rules of comparison operator chaining, not arithmetic operator chaining. Left-associativity is when a b c is equivalent to (a b) c. You're talking about evaluation order, which can be different. For example, hypothetically, (a b) c could evaluate c first, then b, then a. However, Python always evaluates operands left-to-right. A particular case where this comes into play is the ** operator, which is right-associative but still has a left-to-right evaluation order. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Mon, Jul 2, 2012 at 11:28 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sun, 01 Jul 2012 16:33:15 +1000, Chris Angelico wrote: On Sun, Jul 1, 2012 at 4:27 PM, Steven D'Aprano steve+use...@pearwood.info wrote: Yes, you can find specially crafted examples where adding parentheses in certain places, but not others, doesn't change the overall evaluation of the expression. My point was that adding parentheses around the tightest-binding operator is a common, clear, and usually insignificant, way of demonstrating operator precedence. So FOR THAT USE they must not change evaluation of the expression. Obviously if you put them anywhere else, they change evaluation. Nice job knocking down a straw man. We *really did have* somebody arguing that chained comparisons are Bad because you can't stick parentheses around bits of it without changing the semantics. That was an actual argument, not a straw-man. Okay, I take back the straw man accusation, and apologize for it. But you were quoting my text at the time, so I thought you were aiming at my argument - which, not being that, was what led me to think you were answering what you weren't answering. Chained comparisons in the Python sense may be rare in computer languages, but it is the standard in mathematics and hardly needs to be explained to anyone over the age of twelve. That is a terrible indictment on the state of programming language design. I'd say that proves that Python is a good language for expressing mathematics in, then. That's all. Doesn't necessarily mean it's good for any other task (doesn't mean it's bad either of course). Python does not, meanwhile, have inbuilt operators for calculus, nor does it have an equation solver. Do we absolutely need them? Empirically no. Python can be an excellent language without making every bit of mathematical notation executable. There are, I am sure, plenty of cases where it would be nice to go: x = y+2 x*3 = y*4+7 print(x = %d, y = %d,x,y) You can argue that Python ought to have more-different operators for comparison and assignment, but the fact of algebra is that it has neither - the equals sign is more of a declaration of truth. Algebra simply isn't imperative. It's fine (and fits the Eliza principle) to evaluate expressions algebraically, but equations aren't assignment. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: IPython 0.13 is officially out!
On Jul 1, 9:03 pm, Dave Cook davec...@nowhere.net wrote: On 2012-07-01, Virgil Stokes v...@it.uu.se wrote: I have tried to update 0.12 in Ubuntu 12.04 but as of now it can not find 0.13. Any suggestions on how to get it into Ubuntu 12.04 would be appreciated. Install pip and use it to upgrade ipython: sudo apt-get install python-pip sudo pip install --upgrade ipython Dave Cook Would that not cause path-problems if the earlier one were not pip- installed?? Better to remove the earlier one first -- http://mail.python.org/mailman/listinfo/python-list
Re: distutils that supports msvc10 and that can be backfitted into Python 2.6
On 26/06/2012 23:24, KACVINSKY Tom wrote: I have need for a distutils that supports msvc10, and which can be back-fitted into Python 2.6. Is there such a beast? One trick I found was to define an environment variable *VS90COMNTOOLS* that points to the actual VS2010 location: VS90COMNTOOLS=%VS100COMNTOOLS% This is because distutils looks for VS2008 in the registry and falls back to the env. var. above, hence we trick it to detect VS2010 and call `vcvarsall.bat` when compiling extensions: python setup.py build --compiler=msvc Just keep in mind that it is recommended that extension modules be compiled with the same compiler that was used to compile Python which is still VS2008 to this day.. -- http://mail.python.org/mailman/listinfo/python-list
Re: code review
On Sun, 01 Jul 2012 13:41:20 -0400 Dennis Lee Bieber wlfr...@ix.netcom.com wrote: I'd think a true newcomer (to programming) would have NO expectations... And if they'd had any complex math classes may actually consider if 1 x 10: to be the norm [...] +1 I've only ever known Python (well, I've almost forgotten Bash), and when I first needed a range test, I guessed at the above form and was pleasantly surprised that it worked: it seemed too good to be true that Python was smart enough to know I wanted the same x to be an operand in two comparisons at once. John P.S. I know I'm not helping, but I'm starting to feel sorry for the guy who wanted his code reviewed! John -- http://mail.python.org/mailman/listinfo/python-list
[issue3871] cross and native build of python for mingw32 with packaging
Ray Donnelly mingw.andr...@gmail.com added the comment: For me, it's all about being able to build useful software. I like Python a lot, but my goal is and has always been cross compilation of gdb with Python support. To that end, if I have to maintain some out of tree patches for 2.7.3 then so be it. For 3.x things are looking better and I'm hopeful that we'll get everything merged at some point. For anyone who's interested in my almost-final set of patches against the released tarballs for both 2.7.3 and 3.3.0b1 they're at: http://mingw-and-ndk.googlecode.com/files/python-273-and-330b1-patches-WIP.7z AFAIK, the only real change I'll be making is to the build script. Once Matthias has finished merging Roumen's cross compilation work to 3, I'll rebase my 3.3.0b1 patches against that and open an issue for each patch. If mingw cross touches too much of distutils for people's liking then hopefully we can get mac osx cross merged and that'll at least mean that the infrastructure is cross-compilation friendly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15202] followlinks/follow_symlinks/symlinks flags unification
Larry Hastings la...@hastings.org added the comment: storchaka: I can (finally!) spend some time reviewing patches today. Which ones do I look at? I'm guessing just the last two, followlinks-to-follow_symlinks-2.patch and symlinks-to-follow_symlinks-2.patch. But I wanted to confirm before I got knee-deep in it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Ray Donnelly mingw.andr...@gmail.com added the comment: I'm not personally interested in Cygwin (it's too slow for my liking) and I've spent a lot of time patching and building software to avoid forcing people to use it (no offence meant to Cygwin people, I can see the value of it, but IMHO native is always best) . All of my patches target mingw-w64 (and Mac OS X cross); I'll do my best to make sure that the Cygwin port still works though (and also mingw32). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15233] atexit: guarantee order of execution of registered functions?
New submission from Georg Brandl ge...@python.org: Currently, the atexit docs state The order in which the functions are called is not defined in the introduction and all functions registered are called in last in, first out order in the docs of the atexit() function. While the latter is correct, I don't think we should guarantee that behaviour by documenting it. Suggestions? -- assignee: docs@python components: Documentation messages: 164454 nosy: docs@python, georg.brandl, loewis, pitrou priority: normal severity: normal status: open title: atexit: guarantee order of execution of registered functions? versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Martin v. Löwis mar...@v.loewis.de added the comment: There are more checks applied in PyPI than just the refusal to incorporate raw html. I doubt it is possible to perform the exact same check with the rst2html command line. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15110] strange Tracebacks with importlib
Georg Brandl ge...@python.org added the comment: Setting to blocker for b2. -- priority: critical - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15110 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error
Richard Oudkerk shibt...@gmail.com added the comment: Then I doubt this is a bug in Python. If your class does not override __reduce__, __reduce_ex__ or __getstate__/__setstate__, then it is probably one of the attributes of your instance which is causing the problem. You could try to find out which one by trying cPickle.loads(cPickle.dumps(attribute, -1)) for each attribute of an instance of your class to see if it raises an error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15233] atexit: guarantee order of execution of registered functions?
Raymond Hettinger raymond.hettin...@gmail.com added the comment: I believe it should be guaranteed behavior and that code may reasonably want to have a predictable sequence of unwinding behaviors. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error
Senthil Kumaran sent...@uthcode.com added the comment: On Sun, Jul 1, 2012 at 1:16 AM, Richard Oudkerk rep...@bugs.python.org wrote: Then I doubt this is a bug in Python. I guess, you meant, this is NOT a bug in Python. -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15234] avoid runtime library path for extensions found in system directories
New submission from Matthias Klose d...@debian.org: if a runtime library path is passed to build an extension, it always ends up in the .so file. it's not needed, so avoid runtime library path for extensions found in system directories. -- assignee: doko components: Build files: rpath.diff keywords: patch messages: 164460 nosy: doko priority: normal severity: normal status: open title: avoid runtime library path for extensions found in system directories versions: Python 3.3 Added file: http://bugs.python.org/file26222/rpath.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15234 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15235] allow newer berkley db versions
New submission from Matthias Klose d...@debian.org: setup.py still has a version check for berkley db, currently only allowing versions up to 5.1.x. I'm checking in a patch to bump this to allow versions up to 5.3.x. Maybe this version check should be disabled (after 3.3), using berkley db as a backend for the dbm module doesn't rely on any fancy berkley db features. -- assignee: doko components: Build messages: 164461 nosy: doko priority: normal severity: normal status: open title: allow newer berkley db versions versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15235] allow newer berkley db versions
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 7be082d80b8a by doko in branch 'default': - Issue #15235: Allow Berkley DB versions up to 5.3 to build the dbm module. http://hg.python.org/cpython/rev/7be082d80b8a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15174] amd64\python_d.exe -m test fails
Stefan Krah stefan-use...@bytereef.org added the comment: In dbc94178703f it works again. Closing. -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15174 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15202] followlinks/follow_symlinks/symlinks flags unification
Larry Hastings la...@hastings.org added the comment: Bad news: Fearless Leader (Georg) just told me on #python-dev that he's had a change of heart and doesn't want this in 3.3. I've marked the bug 3.4, and there's no rush on doing this work--we can't check it in until the 3.4 branch exists. Sorry, Serhiy :( -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15202] followlinks/follow_symlinks/symlinks flags unification
Larry Hastings la...@hastings.org added the comment: Georg just clarified: we can just change the parameter names for new APIs. It's the deprecation / new parameter stuff we can't do for 3.3. So cut a (much) simpler patch and let's get it in right quick. -- versions: +Python 3.3 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Chris Jerdonek chris.jerdo...@gmail.com added the comment: Thanks. Then perhaps the documentation can be updated to make that clear. Currently, the documentation implies that running the given command is sufficient to catch all errors, which can lead to confusion when warning-free content is not rendered as HTML. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10650] decimal.py: quantize(): excess digits with watchexp=0
Stefan Krah stefan-use...@bytereef.org added the comment: watchexp was available in rescale() from the beginning ... http://svn.python.org/view/sandbox/trunk/decimal/Decimal.py?revision=40721view=markup ... and rescale() was renamed to quantize() in http://svn.python.org/view/sandbox/trunk/decimal/Decimal.py?revision=40909view=markup rescale() was once part of the specification, but had identical semantics to quantize(), which is not specified to allow unlimited rescaling. I suppose the original rescale() in the sandbox had watchexp for convenience, in order to avoid two separate functions. watchexp made it into quantize(), probably because people thought there is a need for unlimited rescaling. This may be true, but I'd really prefer to expose rescale() as the unlimited version then. While it's unusual to just drop an API without deprecation, I think it's OK in this instance: Virtually all decimal code I saw needs to be cleaned up anyway because it uses tons of underscore methods from decimal.py. The only thing that worries me is that there might be code which *really* needs unlimited rescaling. Such code could of course also use a temporary context. So I propose this: Deprecate watchexp and leave it in the Python version for one release. The C version won't have watchexp from the start. After all, PEP-399 allows accelerator modules to implement a subset of the functionality of the Python version -- sometimes PEPs are a wonderful thing :). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15236] SEGFAULT in visit_decref
New submission from Kai Sterker kai.ster...@gmail.com: Since update to Python 2.7.3 (as distributed by Ubuntu 12.04 64bit), I experience occasional crashes in the application I am developing (which uses Python scripting). The crash either happens at the first key press or it does not happen at all. Smells like a race condition to me. I installed the debug version of Python 2.7.3 and compiled my project against that, which gave the attached stack trace. The crash also appears to be easier to reproduce with the debug version, but it still does not occur every time. The application that exhibits the crash can be found here: https://github.com/ksterker/adonthell The Python method executed when the crash happens is this one: def estimate_speed (self, terrain): try: return self.Dic[terrain] except: return 0 Don't think it will be possible to construct a minimum example to demonstrate the issue, but if there is any other information helpful to shed more light on the issue, I'm happy to provide it. Regards, Kai -- files: stacktrace.txt messages: 164468 nosy: Kai.Sterker priority: normal severity: normal status: open title: SEGFAULT in visit_decref type: crash versions: Python 2.7 Added file: http://bugs.python.org/file26223/stacktrace.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15237] Add capsule API to _decimal
New submission from Stefan Krah stefan-use...@bytereef.org: Unfortunately, this won't make it into 3.3. -- The self-review of mpdecimal.c had priority and was extremely time consuming. -- assignee: skrah messages: 164469 nosy: lemburg, mark.dickinson, rhettinger, skrah priority: normal severity: normal stage: needs patch status: open title: Add capsule API to _decimal type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Stefan Krah stefan-use...@bytereef.org added the comment: I've opened #15237 for the capsule API. I didn't add everyone to the nosy list, since I suspect it's not of general interest. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15237] Add capsule API to _decimal
Changes by Larry Hastings la...@hastings.org: -- nosy: +larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15233] atexit: guarantee order of execution of registered functions?
Charles-François Natali neolo...@free.fr added the comment: It is guaranteed by libc's atexit(3), and should also be guaranteed here. -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15233] atexit: guarantee order of execution of registered functions?
Larry Hastings la...@hastings.org added the comment: +1 to guaranteeing the order. -- nosy: +larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Matthias Klose d...@debian.org added the comment: fyi, the cross build changes are now checked in. Checked with an x86_64-linux-gnu to arm-linux-gnueabi cross build. I don't plan to add anything more for the 3.3 release besides bug fixes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15237] Add capsule API to _decimal
Mark Dickinson dicki...@gmail.com added the comment: See issue #7652 for context. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15233] atexit: guarantee order of execution of registered functions?
Antoine Pitrou pit...@free.fr added the comment: I believe it should be guaranteed behavior and that code may reasonably want to have a predictable sequence of unwinding behaviors. Agreed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14902] test_logging failed
Juancarlo Añez apal...@gmail.com added the comment: My local timezone is (VET,VET) == time.tzname, and test_logging fails because time.timezone is off by 30 minutes. I couldn't find the cause for the problem with time.timezone, but logging is not to blame. I'm running the tests on Ubuntu 12.04 AMD64 which handles my time zone correctly throughout. I'm submitting a patch that allows test_logging to pass by not relying on time.timezone. -- keywords: +patch nosy: +apalala Added file: http://bugs.python.org/file26224/test_logging_wo_timezone.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Ray Donnelly mingw.andr...@gmail.com added the comment: Thanks Matthias, I might wait until b2 (or rc1) before I rebase my patches, just because I'm so unfamiliar with Mercurial. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15202] followlinks/follow_symlinks/symlinks flags unification
Serhiy Storchaka storch...@gmail.com added the comment:
Here is an updated patches (with index 3). No aliased parameters, only
new parameters renamed. Some minor errors have fixed.
--
Added file:
http://bugs.python.org/file26225/followlinks-to-follow_symlinks-3.patch
Added file: http://bugs.python.org/file26226/symlinks-to-follow_symlinks-3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15202
___diff -r a1c8302e6b27 Doc/library/os.rst
--- a/Doc/library/os.rstSun Jul 01 12:24:20 2012 +0200
+++ b/Doc/library/os.rstSun Jul 01 15:54:02 2012 +0300
@@ -2211,7 +2211,7 @@
os.rmdir(os.path.join(root, name))
-.. function:: fwalk(top='.', topdown=True, onerror=None, followlinks=False, *,
dir_fd=None)
+.. function:: fwalk(top='.', topdown=True, onerror=None,
follow_symlinks=False, *, dir_fd=None)
.. index::
single: directory; walking
diff -r a1c8302e6b27 Lib/os.py
--- a/Lib/os.py Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/os.py Sun Jul 01 15:54:02 2012 +0300
@@ -424,7 +424,7 @@
if {open, stat} = supports_dir_fd and {listdir, stat} = supports_fd:
-def fwalk(top=., topdown=True, onerror=None, followlinks=False, *,
dir_fd=None):
+def fwalk(top=., topdown=True, onerror=None, follow_symlinks=False, *,
dir_fd=None):
Directory tree generator.
This behaves exactly like walk(), except that it yields a 4-tuple
@@ -435,7 +435,7 @@
and `dirfd` is a file descriptor referring to the directory `dirpath`.
The advantage of fwalk() over walk() is that it's safe against symlink
-races (when followlinks is False).
+races (when follow_symlinks is False).
If dir_fd is not None, it should be a file descriptor open to a
directory,
and top should be relative; top will then be relative to that
directory.
@@ -462,13 +462,13 @@
orig_st = stat(top, follow_symlinks=False, dir_fd=dir_fd)
topfd = open(top, O_RDONLY, dir_fd=dir_fd)
try:
-if (followlinks or (st.S_ISDIR(orig_st.st_mode) and
-path.samestat(orig_st, stat(topfd:
-yield from _fwalk(topfd, top, topdown, onerror, followlinks)
+if (follow_symlinks or (st.S_ISDIR(orig_st.st_mode) and
+path.samestat(orig_st, stat(topfd:
+yield from _fwalk(topfd, top, topdown, onerror,
follow_symlinks)
finally:
close(topfd)
-def _fwalk(topfd, toppath, topdown, onerror, followlinks):
+def _fwalk(topfd, toppath, topdown, onerror, follow_symlinks):
# Note: This uses O(depth of the directory tree) file descriptors: if
# necessary, it can be adapted to only require O(1) FDs, see issue
# #13734.
@@ -499,16 +499,16 @@
for name in dirs:
try:
-orig_st = stat(name, dir_fd=topfd, follow_symlinks=followlinks)
+orig_st = stat(name, dir_fd=topfd,
follow_symlinks=follow_symlinks)
dirfd = open(name, O_RDONLY, dir_fd=topfd)
except error as err:
if onerror is not None:
onerror(err)
return
try:
-if followlinks or path.samestat(orig_st, stat(dirfd)):
+if follow_symlinks or path.samestat(orig_st, stat(dirfd)):
dirpath = path.join(toppath, name)
-yield from _fwalk(dirfd, dirpath, topdown, onerror,
followlinks)
+yield from _fwalk(dirfd, dirpath, topdown, onerror,
follow_symlinks)
finally:
close(dirfd)
diff -r a1c8302e6b27 Lib/test/test_os.py
--- a/Lib/test/test_os.py Sun Jul 01 12:24:20 2012 +0200
+++ b/Lib/test/test_os.py Sun Jul 01 15:54:02 2012 +0300
@@ -745,10 +745,11 @@
compare with walk() results.
-for topdown, followlinks in itertools.product((True, False), repeat=2):
-d = {'topdown': topdown, 'followlinks': followlinks}
-walk_kwargs.update(d)
-fwalk_kwargs.update(d)
+walk_kwargs = walk_kwargs.copy()
+fwalk_kwargs = fwalk_kwargs.copy()
+for topdown, follow_symlinks in itertools.product((True, False),
repeat=2):
+walk_kwargs.update(topdown=topdown, followlinks=follow_symlinks)
+fwalk_kwargs.update(topdown=topdown,
follow_symlinks=follow_symlinks)
expected = {}
for root, dirs, files in os.walk(**walk_kwargs):
@@ -774,8 +775,8 @@
def test_yields_correct_dir_fd(self):
# check returned file descriptors
-for topdown, followlinks in itertools.product((True, False), repeat=2):
-args = support.TESTFN, topdown, None, followlinks
+for topdown, follow_symlinks in itertools.product((True,
[issue15202] followlinks/follow_symlinks/symlinks flags unification
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file26194/followlinks-to-follow_symlinks-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15202] followlinks/follow_symlinks/symlinks flags unification
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file26195/symlinks-to-follow_symlinks-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15235] allow newer berkley db versions
Jesús Cea Avión j...@jcea.es added the comment: Mattias, the tracker indicates that PDF doesn't have your contributor agreement. Could you possibly send one?. http://www.python.org/psf/contrib/contrib-form/ -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15235] allow newer berkley db versions
Jesús Cea Avión j...@jcea.es added the comment: PDF = PSF (Python software Foundation) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15236] SEGFAULT in visit_decref
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15235] allow newer berkley db versions
Matthias Klose d...@debian.org added the comment: hmm, that was submitted years ago ... (can we move this off line?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15237] Add capsule API to _decimal
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset b449118653fe by Antoine Pitrou in branch 'default': some new tést (issue #2771) http://hg.python.org/test/rev/b449118653fe -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15238] shutil.copystat should copy Linux extended attributes
New submission from Larry Hastings la...@hastings.org: 3.3 adds the *xattr() extended attribute functions on Linux. shutil implements a new internal function(_copyxattr) which copies these extended attributes. However, it's only used in shutil.copy2(). I assert that shutil.copystat() should also preserve this metadata. (Which, having subsumed this functionality, means that shutil.copy2() would no longer need to explicitly call it.) Also: it might be worth considering taking the same approach _copyxattr uses for the other conditional functionality (see def lookup inside copystat). Computing platform support at import time instead of runtime looks cleaner. Georg, how much of this (if any) do you consider a 3.3 bugfix? -- assignee: larry messages: 164483 nosy: georg.brandl, larry, storchaka priority: normal severity: normal stage: needs patch status: open title: shutil.copystat should copy Linux extended attributes type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15238] shutil.copystat should copy Linux extended attributes
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +hynek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15206] uuid module falls back to unsuitable RNG
Christian Heimes li...@cheimes.de added the comment: The rest of the module uses bar excepts. I could change the signature if you insist. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15236] SEGFAULT in visit_decref
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: This programs embeds a Python interpreter and uses the C API extensively. I tried to compile it, but could not make it use Python 2.7. Your stracktrace suggests a buffer overflow, or reuse of a freed object: ob_refcnt = 8462385097079783424, ob_type = 0x72746e6f633a3a74 contains the ascii of input::contr. Probably a input::control_event* which is the raised event. I suspect that the memory corruption has always occurred, but with 2.7.3 a garbage collection happens in the middle of an event callback. Could you add some gc.collect() here and there, and see if other versions Of Python crash as well? -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13700] imaplib.IMAP4.authenticate authobject does not work correctly in python3
Erno Tukia erno.tu...@iki.fi added the comment: Here's the updated patch. Tests now works. PLAIN works for me, that's only I can test against live system. test_login_cram_md5 test had extra \r\n in _send_tagged. diff imaplib_authenticate.patch imaplib_authenticate_v2.patch + self._send_tagged(tag, 'OK', 'CRAM-MD5 successful\r\n') --- + self._send_tagged(tag, 'OK', 'CRAM-MD5 successful') -- Added file: http://bugs.python.org/file26227/imaplib_authenticate_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Daniel Lenski dlen...@gmail.com added the comment: Richard, I think the problem with this is that it spreads the non-portable or OS-dependent parts of the code over several places rather than concentrating them all in one place. After close_without_unlink(), what would happen when the context manager exits or when the object is garbage collected? Would it then get unlinked? My preference would be to specify the behavior of close/__exit__/GC operations at the time of the NamedTemporaryFile creation, so that the rest of the code can be left unchanged. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error
Ian Bell ian.h.b...@gmail.com added the comment: I have repaired my class so that it pickles properly, but that does not resolve the issue that if you send a non-picklable object through a pipe, it should raise an error, rather than hang. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15239] Abandoned Tools/unicode/mkstringprep.py
New submission from Serhiy Storchaka storch...@gmail.com: It seems that Tools/unicode/mkstringprep.py has not been used for many years. Now it is not valid Python3 code nor Python2 code. The proposed patch fixes all porting errors. Apparently, Lib/stringprep.py would have regenerated. Tools/unicode/mkstringprep.py output is a bit different from Lib/stringprep.py (in b3_exceptions). -- components: Demos and Tools, Unicode messages: 164489 nosy: ezio.melotti, storchaka priority: normal severity: normal status: open title: Abandoned Tools/unicode/mkstringprep.py versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15239] Abandoned Tools/unicode/mkstringprep.py
Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file26228/mkstringprep.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15239] Abandoned Tools/unicode/mkstringprep.py
Martin v. Löwis mar...@v.loewis.de added the comment: Indeed, the code hasn't been run, and really shouldn't have to. If it produces different output today, we should investigate why. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error
Richard Oudkerk shibt...@gmail.com added the comment: I have repaired my class so that it pickles properly, but that does not resolve the issue that if you send a non-picklable object through a pipe, it should raise an error, rather than hang. What do you mean by hang? Do you mean that send() succeeds and recv() raises an error. That might cause your *program* to hang, but send() itself should not hang. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15206] uuid module falls back to unsuitable RNG
Antoine Pitrou pit...@free.fr added the comment: The rest of the module uses bar excepts. It was probably written in prehistoric times :) The other excepts can be converted later, if the module gets other changes. I don't think it is a deliberate style choice (it would be particularly distasteful :-)). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15232] email.generator.Generator doesn't mangle From lines in MIME preamble
Petri Lehtinen pe...@digip.org added the comment: Hi and thanks for the report. It seems that this is a bug in email.generator.Generator, as it fails to mangle From lines in the MIME preamble (after the headers, before the first --Boundary... line). -- components: +Library (Lib) nosy: +petri.lehtinen stage: - needs patch title: maildir parsing can split up messages with 'From ' at the start of a line - email.generator.Generator doesn't mangle From lines in MIME preamble type: - behavior versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15236] SEGFAULT in visit_decref
Kai Sterker kai.ster...@gmail.com added the comment: To compile against a python version that is not system-default, configure with PYTHON=/usr/bin/python2.7 ../adonthell/configure --with-py-cflags=-I/usr/include/python2.7 --with-py-libs=-lpython2.7 Regardless of that, your hints are proving useful. I compiled with 2.6.8 and was not able to reproduce the issue. However, with a gc.collect() call added to estimate_speed, it will again happen sometimes. So it does not seem to be specific to Python 2.7.3 (and is probably not even a problem with Python at all). Could this be triggered by a missing Py_INCREF somewhere? Or would you suspect something totally unrelated? (But then I would expect other random crashes, too.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Richard Oudkerk shibt...@gmail.com added the comment: The webpage http://msdn.microsoft.com/en-us/library/aa273350(v=vs.60).aspx describes the sopen() function which is like open() but has an extra shflag parameter for specifying the sharing allowed. If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW and SH_DENYNO were exposed in the os module, then maybe tempfile could use os.sopen() on Windows instead of os.open() to allow the file to be reopened without closing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Antoine Pitrou pit...@free.fr added the comment: If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW and SH_DENYNO were exposed in the os module, then maybe tempfile could use os.sopen() on Windows instead of os.open() to allow the file to be reopened without closing. Sounds like a good way forward. -- components: +Windows stage: - needs patch versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Tim Golden m...@timgolden.me.uk added the comment: On 01/07/2012 21:37, Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW and SH_DENYNO were exposed in the os module, then maybe tempfile could use os.sopen() on Windows instead of os.open() to allow the file to be reopened without closing. Sounds like a good way forward. Agreed. Richard: do you have time to put something together? I'm happy to try if you don't. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12605] Enhancements to gdb 7 debugging hooks
Changes by Antoine Pitrou pit...@free.fr: -- priority: release blocker - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12605 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset b4af3925bda6 by Antoine Pitrou in branch 'default': some new tést (issue #2771) http://hg.python.org/test/rev/b4af3925bda6 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 3e4513003ded by Antoine Pitrou in branch 'default': some new tést (issue #2771) http://hg.python.org/test/rev/3e4513003ded New changeset b449118653fe by Antoine Pitrou in branch 'default': some new tést (issue #2771) http://hg.python.org/test/rev/b449118653fe New changeset 99fbc7dfb076 by Antoine Pitrou in branch 'default': some new tést (issue #2771) http://hg.python.org/test/rev/99fbc7dfb076 New changeset b4af3925bda6 by Antoine Pitrou in branch 'default': some new tést (issue #2771) http://hg.python.org/test/rev/b4af3925bda6 New changeset 76da38684c9d by Antoine Pitrou in branch 'default': some other test (issue #2771) http://hg.python.org/test/rev/76da38684c9d -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15236] SEGFAULT in visit_decref
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Yes, some INCREF may be missing. The issue may be with the callback mechanism; these are usually difficult to get right. Actually by pure luck I found suspect code that may be the cause of this crash: in src/event/listener_python.cc, the Args tuple is first allocated, but item #1 is not set. It's a bit wrong (try to print it!) but if does not leak outside, it won't probably crash here; gc traverse function luckily skips NULL pointers. BUT in raise_event(), this Args[1] is set to an event object, which is DECREF'd afterwards. The pointer now points to invalid memory, and next gc.collect() will crash... I also found other issues with reference counting here and there (ex: in src/python/python.cc, PyTuple_SET_ITEM (new_tuple, i, Py_None) steals one reference to Py_None each time!) There are many bugs in this application to fix before we can impute CPython. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15212] Rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT in compiler module
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 55130516d1d2 by Antoine Pitrou in branch '2.7': Issue #15212: fix typo in compiler module (rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT). http://hg.python.org/cpython/rev/55130516d1d2 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15212] Rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT in compiler module
Antoine Pitrou pit...@free.fr added the comment: Thank you, fixed now. -- nosy: +pitrou resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Richard Oudkerk shibt...@gmail.com added the comment: Agreed. Richard: do you have time to put something together? I'm happy to try if you don't. I'm looking into it. Unfortunately, it seems that you need to use non-default flags when reopening a shared file. Eg, if the file is currently opened with SH_DENYNO and O_TEMPORARY, then you must reopen it using SH_DENYNO and O_TEMPORARY. However, I have an initial implementation of os.sopen() which makes the following work: import os, tempfile FNAME = foo.txt DATA = hello bob def opener(name, flag, mode=0o777): return os.sopen(name, flag | os.O_TEMPORARY, os.SH_DENYNO, mode) with open(FNAME, w, opener=opener) as f: f.write(DATA) f.flush() with open(FNAME, r, opener=opener) as f: assert f.read() == DATA assert not os.path.exists(FNAME) BTW, Maybe it would be better to add a keyword-only shareflag argument to os.open() rather than add os.sopen(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
