[ANN] pyspread 0.3.1
== pyspread 0.3.1 == Pyspread 0.3.1 is released. This is a bugfix release that removes an annoying warning on the console. About pyspread == Pyspread is a non-traditional spreadsheet application that is based on and written in the programming language Python. The goal of pyspread is to be the most pythonic spreadsheet application. Pyspread is free software. It is released under the GPL v3. Project website: http://manns.github.com/pyspread/ Download page: https://pypi.python.org/pypi/pyspread What is new in 0.3.1 + Bugfix + Updated German localization + Updated Ukrainian localization Enjoy Martin -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Save/restore breakpoints between pdb runs
Ed Blackman e...@edgewood.to writes:
I've recently started using Python for my job (as opposed to writing
smallish scripts for personal use), and so have needed to debug quite
a bit more.
I've been using pdb mainly via 'python -m pdb script args'. Perhaps
it's my Java background, but even when I have permissions to change
the source, I find editing source to insert 'import pdb;
pdb.set_trace()' unnatural. The consequence is that I have to
recreate my breakpoints when I have to exit pdb.
I've written the following code, which I load from .pdbrc with
'execfile(os.path.expanduser('~/.pydb.py'))'
This approach does not seem very robust to me:
pdb resolves all breakpoints to lines (in source files) - and
any modification to the source may change the lines.
As a consequence, your breakpoints may no longer be at the
places where you expect them.
A long time ago, I have developped dm.pdb - a slight
extension/improvement over pdb. One of the extensions
has been to make it possible to set breakpoints from outside
the debugger -- without too many surprises. It looks somehow like that:
from dm.pdb import Pdb; D = Pdb()
...
from ... import f
from ... import g
from ... import C
...
D.do_break(f) # set breakpoint on f
D.do_break(g) # set breakpoint on g
D.do_breack(C.m) # set breakpoint on method m of class C
...
D.run(...)
It is more robust than breakpoints on line numbers - but, of course,
it cannot be automated but must be targeted to individual programs.
In addition, the robustness is limited to breakpoints on
executable objects; setting breakpoints on line numbers is possible, too --
but has the same problem with moving lines.
In the meantime, pdb itself may support this form of external
control (maybe even better then dm.pdb).
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On Sat, Jul 12, 2014 at 3:07 PM, Alan Bawden
a...@scooby-doo.csail.mit.edu wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
But perhaps we only care about changes in value, not type. NAN or no NAN,
list equality works fine:
py data = [1.0, 2.0, float('nan'), 4.0]
py old = data[:]
py old == data # No changes made yet, should return True
True
You lost me right here. If list equality is determined by comparing
lists element-by-element, and the second element of old is _not_ equal
to the second element of data, then why should old and data be equal?
In fact, I find myself puzzled about exactly how list equality is
actually defined.
In the Python 3 docs, it's made a bit clearer, at least as regards the
'in' and 'not in' operators: it's an identity check followed by an
equality check - x is y or x == y. The same comparison is done for
equality, although it's not strictly described there (at least, I
couldn't find it). There are a lot of these sorts of corner cases that
aren't made really clear in the docs, because the verbosity would be
more of a problem than the omission - I consider them to be like The
land continues to burn on Obsidian Fireheart [1] or the reminder text
on Madness [2]; if you go to the Magic: The Gathering Comprehensive
Rulebook, you can find the exact code-accurate details on how either
one works, but that takes several pages of verbiage, and it's much
better to just say you may cast it for its madness cost instead of
putting it into your graveyard.
For the most part, the identity check is a pure optimization. Most
Python objects compare equal to themselves. It only VERY occasionally
matters (like when there's a NaN in your list), and for those cases,
you have the interactive interpreter to try things at.
ChrisA
[1] http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=192224
[2] eg http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=118892
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
Hallöchen! Alan Bawden writes: [...] You lost me right here. If list equality is determined by comparing lists element-by-element, and the second element of old is _not_ equal to the second element of data, then why should old and data be equal? I think Python first tests for identity, and falls back to equality (or the other way round). This behaviour is questionable in my opinion. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
Hallöchen! Torsten Bronger writes: Alan Bawden writes: [...] You lost me right here. If list equality is determined by comparing lists element-by-element, and the second element of old is _not_ equal to the second element of data, then why should old and data be equal? I think Python first tests for identity, and falls back to equality (or the other way round). This behaviour is questionable in my opinion. See also https://mail.python.org/pipermail/python-bugs-list/2006-August/035010.html Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Error after sympy lambdify function update using vector() dot.class
On Sat, Jul 12, 2014 at 3:33 AM, Niklas Troedsson niklastroeds...@yahoo.com.dmarc.invalid wrote: I am new to the forum and programming Python. Recently I updated both Canopy and its packages, I am now using Canopy 1.4.1.1975 and sympy 0.7.5-1. This is a general Python list, not Canopy or Sympy specific. If you don't get a useful response here, you may want to try looking for their mailing lists; Canopy appears to be (sorry, I'm not familiar with it) an Enthought package, so you could ask Enthought for support; and Sympy doubtless has its own lists, which you could find with a Google search. I suspect that what you're asking about may be sufficiently specialized that you'll get better responses there. But you might get a response here. Never know! We do have some pretty awesome experts on python-list. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On 07/11/2014 10:07 PM, Alan Bawden wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
But perhaps we only care about changes in value, not type. NAN or no NAN,
list equality works fine:
py data = [1.0, 2.0, float('nan'), 4.0]
py old = data[:]
py old == data # No changes made yet, should return True
True
You lost me right here. If list equality is determined by comparing
lists element-by-element, and the second element of old is _not_ equal
to the second element of data, then why should old and data be equal?
In fact, I find myself puzzled about exactly how list equality is
actually defined. Consider:
a = float('nan')
x = [1, a, 9]
y = [1, a, 9.0]
x == y
True
So is there some equality predicate where corresponding elements of x
and y are equal?
map(operator.eq, x, y)
[True, False, True]
It's not ==.
map(operator.is_, x, y)
[True, True, False]
And it's not is.
class list:
def __eq__(self, other):
if len(self) != len(other):
return False
for this, that in zip(self, other):
if this is that or this == that:
continue
break
else:
return True
return False
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On Sat, Jul 12, 2014 at 4:11 PM, Ethan Furman et...@stoneleaf.us wrote: class list: def __eq__(self, other): if len(self) != len(other): return False for this, that in zip(self, other): if this is that or this == that: continue break else: return True return False Seems a little elaborate. Why not just return straight from the loop, instead of breaking and using else? :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
Chris Angelico ros...@gmail.com: On Sat, Jul 12, 2014 at 4:11 PM, Ethan Furman et...@stoneleaf.us wrote: class list: def __eq__(self, other): if len(self) != len(other): return False for this, that in zip(self, other): if this is that or this == that: continue break else: return True return False Seems a little elaborate. Why not just return straight from the loop, instead of breaking and using else? :) But look at that keyword density! That single function demonstrates 80% of Python syntax making it a great educational tool. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On 07/11/2014 11:39 PM, Chris Angelico wrote: On Sat, Jul 12, 2014 at 4:11 PM, Ethan Furman et...@stoneleaf.us wrote: class list: def __eq__(self, other): if len(self) != len(other): return False for this, that in zip(self, other): if this is that or this == that: continue break else: return True return False Seems a little elaborate. Why not just return straight from the loop, instead of breaking and using else? :) Because I'm tired, and it seemed like a good excuse to show else with for, and because I'm tired. :) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On Sat, Jul 12, 2014 at 4:53 PM, Ethan Furman et...@stoneleaf.us wrote: Because I'm tired, and it seemed like a good excuse to show else with for, and because I'm tired. :) Excellent justification. I withdraw the criticism. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
We are looking for talented and motivated PYTHON Developers for our office in Bandung, West Java.
http://www.voxteneo.com/jobs/#job-indonesia *PYTHON Developers #12* We are looking for talented and motivated PYTHON Developers for our office in Bandung, West Java. We offer a permanent contract with a competitive salary package You will join our team to take charge of analysis and development of ambitious projects within a growing company You will be part of a skilled, dynamic team in a friendly environment As developer, you will translate companies’ needs into functional specifications and develop new applications. Skills Mini. 2 year of significant software development experience Must have delivered production level code (Python) in a commercial environment Excellent analytical and decision making skills Server-side Python coding, both in Django and straight WSGI Client-side development with HTML, JS/JQuery, and CSS SQL database design and coding Experience with AWS Degree in Computer Science a plus http://www.voxteneo.com/jobs/#job-indonesia -- View this message in context: http://python.6.x6.nabble.com/We-are-looking-for-talented-and-motivated-PYTHON-Developers-for-our-office-in-Bandung-West-Java-tp5063819.html Sent from the Python - python-list mailing list archive at Nabble.com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On Sat, 12 Jul 2014 01:07:28 -0400, Alan Bawden wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
But perhaps we only care about changes in value, not type. NAN or no
NAN, list equality works fine:
py data = [1.0, 2.0, float('nan'), 4.0]
py old = data[:]
py old == data # No changes made yet, should return True True
You lost me right here. If list equality is determined by comparing
lists element-by-element, and the second element of old is _not_ equal
to the second element of data, then why should old and data be equal?
Because practicality beats purity.
Outside of the specialist areas of IEEE-754 floating point NANs, and SQL
NUL, it is a basic property of *nearly everything* that x equals itself,
for any x. This property is called reflexivity, and is considered by
some (although not me) to be absolutely fundamental, never to be violated
under any circumstances.
(To be clear, I'm talking about reflexivity of *equality* specifically,
not of every operator. We wouldn't expect x x, for example -- the
greater than operator is not reflexive.)
While IEEE-754, and SQL, have good reasons for violating the reflexivity
of equals, that upsets a lot of people. Given:
data = [1.0, 2.0, 3.0]
data == data
it would be surprising, and annoying, more often than useful if the
equality test returned False. Replace any of the floats with a NAN, and
the same surprise and annoyance applies.
In the case of Python, lists and other builtin containers partially
violate the specialist rules of IEEE-754 NAN handling, by using is
identity test as a shortcut for equality. Effectively, they assume that
equality is always reflexive. This was introduced as an optimization,
since == can be quite expensive in Python, whereas is requires only a
fast pointer comparison and is very cheap.
I support this optimization, even if it violates the non-reflexivity of
NANs. NANs are specialised values, and outside of the narrow confines of
IEEE-754 arithmetic, their non-reflexivity is more of a nuisance than
anything else.
(Some would argue that *even within* IEEE-754 arithmetic, non-reflexivity
is a nuisance. For now, I prefer to remain neutral in that argument.)
In fact, I find myself puzzled about exactly how list equality is
actually defined.
You'd have to check the C source code, but I would expect something like
this (only written in C):
class list:
def __eq__(self, other):
if self is other:
return True
elif isinstance(other, list):
if len(self) != len(other):
return False
for a, b in zip(self, other):
if not (a is b or a == b):
return False
return True
else:
return NotImplemented # Let other decide.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
[ANN] pyspread 0.3.1
== pyspread 0.3.1 == Pyspread 0.3.1 is released. This is a bugfix release that removes an annoying warning on the console. About pyspread == Pyspread is a non-traditional spreadsheet application that is based on and written in the programming language Python. The goal of pyspread is to be the most pythonic spreadsheet application. Pyspread is free software. It is released under the GPL v3. Project website: http://manns.github.com/pyspread/ Download page: https://pypi.python.org/pypi/pyspread What is new in 0.3.1 + Bugfix + Updated German localization + Updated Ukrainian localization Enjoy Martin -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On 09.07.2014 11:17, Steven D'Aprano wrote: People are already having problems, just listen to Anders. He's (apparently) not doing NAN-aware computations on his data, he just wants to be able to do something like this_list_of_floats == that_list_of_floats This is a horrible example. There's no pretty way of saying this: Comparing floats using equals operators has always and will always be an incredibly dumb idea. The same applies obviously to containers containing floats. I also agree with Chris that I think an additional operator will make things worse than better. It'll add confusion with no tangible benefit. The current operators might have the deficiency that they're not relexive, but then again: Why should == be always reflexive while the other operators aren't? Why should I be able to assume that x == x - True but not when x x - False If you're arguing from a mathematical/logical standpoint then if you want the former you'll also have to want the latter. Cheers, Johannes -- Wo hattest Du das Beben nochmal GENAU vorhergesagt? Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa hidbv3$om2$1...@speranza.aioe.org -- https://mail.python.org/mailman/listinfo/python-list
Rest WebService Testing using Python
Hi folks, This is Neeraj , I want to develop some standalone python Scripts to Test Rest Webservices i.e. WADL services with endpoints. Particularly I need A script for logging in would pass the xml to the rest api with variables for all the payload fields python So Can Anyone please provide me some sample scripts or tutorials or package that can help me in above Scenario for automating the Rest WebService Testing for me I am new to python.So please bear with me..:) Thanks in advance -- https://mail.python.org/mailman/listinfo/python-list
Re: Rest WebService Testing using Python
In article bbdb1f48-9fe8-43af-a765-de5894d38...@googlegroups.com, neeraj.bakht...@gmail.com wrote: Hi folks, This is Neeraj , I want to develop some standalone python Scripts to Test Rest Webservices i.e. WADL services with endpoints. Particularly I need A script for logging in would pass the xml to the rest api with variables for all the payload fields python So Can Anyone please provide me some sample scripts or tutorials or package that can help me in above Scenario for automating the Rest WebService Testing for me I am new to python.So please bear with me..:) Thanks in advance The question you are asking is broad, so I can only make some general suggestions. You've really got two needs here. One is you need some kind of test framework, the other is that you need some way to talk to an HTTP server. Let's attack those one at a time. Test framework. Testing is all about writing down a list of things you believe to be true, and then exercising the code to verify that they are indeed true. When I do X, I expect Y to happen. If it does, the test passes. If not, the test fails. Generally you write a large number of these tests, and run them all. A lot of this is boilerplate. You need some way to organize all the individual tests. Run them (or perhaps run subsets of them). Record which ones passed or not. Set up the right environment for each test to run, and possibly clean up after each one. The idea of a test framework is that it takes care of most of this for you automatically, letting you concentrate on the test logic. There's a couple of choices for test frameworks. The standard one that comes packaged with Python is unittest (https://docs.python.org/2/library/unittest.html). I used to use it a lot, but I've come to regard it as somewhat klunky. Still, it's the standard. If you've used JUnit, it has the advantage that it will feel very familiar. A newer alternative is nose (https://nose.readthedocs.org/), which is what I mostly use now. Nose simplifies some things, but sometimes can be a bit difficult to understand (the docs can be a bit obtuse in places). The big advantage of nose is it has some very powerful tools for running tests in parallel. If you have a lot of tests that are I/O bound, this can seriously reduce the time to run your test suite. There's also doctest (https://docs.python.org/2/library/doctest.html), but for the kind of testing you want to do, it's probably not the right tool. I include it only for completeness. OK, so now, how to talk to your HTTP service. That's easy. You want to use requests (http://docs.python-requests.org). If your web service involves persisting state on the client side with cookies, you'll want to explore requests' session functionality. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On Sat, 12 Jul 2014 13:54:07 +0200, Johannes Bauer wrote: On 09.07.2014 11:17, Steven D'Aprano wrote: People are already having problems, just listen to Anders. He's (apparently) not doing NAN-aware computations on his data, he just wants to be able to do something like this_list_of_floats == that_list_of_floats This is a horrible example. There's no pretty way of saying this: Comparing floats using equals operators has always and will always be an incredibly dumb idea. The same applies obviously to containers containing floats. That's a myth. It simply is not true that you should never compare floats with the equals operator, it comes from the dark ages of numeric computing prior to IEEE-754. If you said, for many purposes, one should not compare floats for equality, but should use some sort of fuzzy comparison instead then I would agree with you. But your insistence that equality always is wrong takes it out of good advice into the realm of superstition. Quoting Professor William Kahan from the foreword to the Apple Numerics Manual, second edition: [B]ecause so many computers in the 1960s and 1970's possessed so many different arithmetic anomalies, computational lore has become encumbered with a vast body of superstition purporting to cope with them. One such superstitious rule is *Never* ask whether floating-point numbers are exactly equal. That was written in 1987, just two years after the introduction of the IEEE-754 standard. It is heart-breaking that 26 years later this bogus rule is still being treated as gospel. Bruce Dawson has written an awesome series of blog posts dealing with floating point issues. In this post: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ he discusses some of the issues with comparing two C floats or doubles for equality. If you read the entire post, he emphasises how hard it is to compare floats, and gives three methods: - test whether they differ by an absolute error - test whether they differ by a relative error - test whether they differ by a certain number of Units In Last Place (one method he misses is the one used by Python unittest module, which rounds the values before comparing them) and describes some of the weaknesses of each. In a reply to a comment, he warns about using == to compare a float (single precision) and a double. But if you keep reading all the way down to this comment: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/#comment-9989 he says: [T]he default equality comparison absolutely should be true equality. To do otherwise risks madness. I have a post almost ready that uses exact floating-point comparisons to validate math, thus proving that exact comparisons are valid. [...] So, standard fuzzy comparison functions would be nice, but the default should remain exact comparisons. There's one obvious use-case for exact comparison: Has this value changed to some other value? old = x x = function(x) if x != old: print changed! is fine. Changing the inequality to some fuzzy comparison is bogus, because that means that *some changes will not be detected*. I also agree with Chris that I think an additional operator will make things worse than better. It'll add confusion with no tangible benefit. The current operators might have the deficiency that they're not relexive, but then again: Why should == be always reflexive while the other operators aren't? You're not going to hear me arguing that the non-reflexivity of NANs and SQL NULL is a bad idea, although some very smart people have: http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ Mathematical equality is reflexive. It is fundamental to the nature of numbers and equality that a number is always equal to itself. To the degree that floats are supposed to model real numbers, they should obey the same laws of real numbers. However, they already fail to obey them, so the failure of reflexivity is just one more problem that makes floating point such a hard problem. Compared to floating point arithmetic, calculus is easy. Why should I be able to assume that x == x - True but not when x x - False Because not all types are ordered: py x = 1+3j py x x Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() complex() -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On Sun, Jul 13, 2014 at 2:35 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: You're not going to hear me arguing that the non-reflexivity of NANs and SQL NULL is a bad idea, although some very smart people have: http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ Mathematical equality is reflexive. It is fundamental to the nature of numbers and equality that a number is always equal to itself. To the degree that floats are supposed to model real numbers, they should obey the same laws of real numbers. However, they already fail to obey them, so the failure of reflexivity is just one more problem that makes floating point such a hard problem. Compared to floating point arithmetic, calculus is easy. And there are plenty of other laws of real numbers that floats violate (or, let's be generous, approximate to rather than following perfectly). For instance, adding two positive (non-zero) numbers should result in a number which is greater than either, but thanks to rounding, that's not always true. (Not to mention that infinity isn't a number, but it is a floating-point value.) The problem is not equality comparisons, the problem is the expectation that the rules of reals apply to floats. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Steve Hayes hayes...@telkomsa.net on Sun, 01 Jun 2014 05:05:05 +0200 typed in comp.lang.python the following: On Sat, 31 May 2014 15:44:46 +0300, Marko Rauhamaa ma...@pacujo.net wrote: Steve Hayes hayes...@telkomsa.net: I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm installing now. Even if I could *find* a book that deals with Python 3.x, couldn't afford to but yet another Python book. Unfortunately, in the computer field, if there's a book written on a topic, it will most likely be out of date. In the 1990's, I used to buy computer books on various topics. I don't think I have bought one for ten years. Either it is online or it doesn't exist. There's enough Python material online to become a pro in it: I hate reading stuff online, and find it diffucult to learn anything with that method. I use MS Word 97 in preference to Libre Office wor Word 2010 (both of which I have) because I have a book on the first, but not on the others. I can't read online books in the bath or in bed. Hear, hear! -- pyotr filipivich The fears of one class of men are not the measure of the rights of another. -- George Bancroft -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On 12.07.2014 18:35, Steven D'Aprano wrote: If you said, for many purposes, one should not compare floats for equality, but should use some sort of fuzzy comparison instead then I would agree with you. But your insistence that equality always is wrong takes it out of good advice into the realm of superstition. Bullshit. Comparing floats by their representation is *generally* a bad idea because of portability issues. You don't know if IEEE754 is used to represent floats on the systems that your code is used on. You're hairsplitting: when I'd have said in 99.9% of cases you'd agree with me but since I said always you disagree. Don't lawyer out. Comparing binary representation of floats is a crappy idea. Even more so in the age of cloud computing where your code is executed on who knows which architecture where the exact same high level interpretation might lead to vastly different results. Not to mention high performance computing, where specialized FPUs can numerously be found which don't give a shit about IEEE754. Another thing why it's good to NEVER compare floats with regards to their binary representation: Do you exactly know how your FPU is configured by your operating system. Do you know that your FPUs on a multiprocessor system are configured all identically with regards to 754? Rounding modes, etc? Just don't fall in the pit. Don't compare floats via equals. when x x - False Because not all types are ordered: py x = 1+3j py x x Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() complex() Oh, so then you also don't want refelexivity of equals, I think. Because, obviously, not all types support comparison for equality: #!/usr/bin/python3 class Yeah(object): def __eq__(self, other): raise TypeError(Booya) Yeah() == Yeah() You cherrypick your logic and hairsplit in your reasoning. It's not consistent. Cheers, Johannes -- Wo hattest Du das Beben nochmal GENAU vorhergesagt? Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa hidbv3$om2$1...@speranza.aioe.org -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, May 28, 2014 at 12:23 PM, Larry Martell larry.mart...@gmail.com wrote: Somthing I came across in my travels through the ether: https://medium.com/@deliciousrobots/5d2ad703365d/ Hey kids, maybe if we all chant this enough times, we can make it true! Wouldn't that be fun? -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
In article mailman.11777.1405184093.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: And there are plenty of other laws of real numbers that floats violate (or, let's be generous, approximate to rather than following perfectly). For instance, adding two positive (non-zero) numbers should result in a number which is greater than either, but thanks to rounding, that's not always true. Not to mention that whole sum of all the positive integers thing :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On Sun, Jul 13, 2014 at 4:14 AM, Johannes Bauer dfnsonfsdu...@gmx.de wrote: Bullshit. Comparing floats by their representation is *generally* a bad idea because of portability issues. You don't know if IEEE754 is used to represent floats on the systems that your code is used on. No, you don't, but I think you can safely assume that 1.0 == 1.0 on any system that Python runs on. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
In article mailman.11779.1405206078.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Sun, Jul 13, 2014 at 4:14 AM, Johannes Bauer dfnsonfsdu...@gmx.de wrote: Bullshit. Comparing floats by their representation is *generally* a bad idea because of portability issues. You don't know if IEEE754 is used to represent floats on the systems that your code is used on. No, you don't, but I think you can safely assume that 1.0 == 1.0 on any system that Python runs on. ChrisA But, you can still have: print x 1.0 print y 1.0 print x == y False which, I know, isn't really what you were talking about, but it is part of the general confusion of using floats. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On Sun, Jul 13, 2014 at 9:06 AM, Roy Smith r...@panix.com wrote: But, you can still have: print x 1.0 print y 1.0 print x == y False which, I know, isn't really what you were talking about, but it is part of the general confusion of using floats. This is partly because of the oh-so-handy magic of Python's float reprs, rounding them off. Can you do the same trick in Python 3, where the repr rules changed? If so, I would say this is a potential flaw in the display, although not really a serious one. But in terms of the OP's complaint, this is still fine, as the state must have changed for it to be unequal. If you care about equality differences and NOT about the above change, well, I think I've found your solution: instead of x == y, you should use repr(x) == repr(y) :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
codingbat question broken?
I'm working on the following problem set from codingbat.com http://codingbat.com/prob/p107863 Given 3 int values, a b c, return their sum. However, if one of the values is 13 then it does not count towards the sum and values to its right do not count. So for example, if b is 13, then both b and c do not count. lucky_sum(1, 2, 3) → 6 lucky_sum(1, 2, 13) → 3 lucky_sum(1, 13, 3) → 1 The solution I came up with was - def lucky_sum(a, b, c): t = 0 for ints in (a, b, c): if a == 13: t = b + c elif b == 13: t = a elif c == 13: t = a + b else: t = a + b + c return t However the following tests fail lucky_sum(13, 2, 3) → 05X lucky_sum(13, 2, 13) → 015Xlucky_sum(13, 13, 2) → 015X Can anyone show me an example where all test are success? -- https://mail.python.org/mailman/listinfo/python-list
Re: codingbat question broken?
On Sun, Jul 13, 2014 at 12:05 PM, Rodrick Brown rodrick.br...@gmail.com wrote: Can anyone show me an example where all test are success? No, because that's asking for the answer :) What you need to do is look at the failing test cases, and figure out why your function is giving the wrong result. Do you see what's true of all the failing cases and is not true of any others? That might give you a clue as to what's wrong. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: codingbat question broken?
This runs on 2.7 or 3.4, unmodified (other than the #!):
#!/usr/local/cpython-2.7/bin/python
#!/usr/local/cpython-3.4/bin/python
def lucky_sum(*list_):
lucky_total = 0
for element in list_:
if element == 13:
break
lucky_total += element
return lucky_total
if __name__ == '__main__':
print('starting tests')
assert lucky_sum(1, 2, 3) == 6
assert lucky_sum(1, 2, 13) == 3
assert lucky_sum(1, 13, 3) == 1
print('ending tests')
On Sat, Jul 12, 2014 at 7:05 PM, Rodrick Brown rodrick.br...@gmail.com
wrote:
I'm working on the following problem set from codingbat.com
http://codingbat.com/prob/p107863
Given 3 int values, a b c, return their sum. However, if one of the values
is 13 then it does not count towards the sum and values to its right do not
count. So for example, if b is 13, then both b and c do not count.
lucky_sum(1, 2, 3) → 6
lucky_sum(1, 2, 13) → 3
lucky_sum(1, 13, 3) → 1
The solution I came up with was -
def lucky_sum(a, b, c):
t = 0
for ints in (a, b, c):
if a == 13:
t = b + c
elif b == 13:
t = a
elif c == 13:
t = a + b
else:
t = a + b + c
return t
However the following tests fail
lucky_sum(13, 2, 3) → 05X lucky_sum(13, 2, 13) → 015Xlucky_sum(13,
13, 2) → 015X
Can anyone show me an example where all test are success?
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: codingbat question broken?
On Sat, Jul 12, 2014 at 8:05 PM, Rodrick Brown rodrick.br...@gmail.com wrote: if a == 13: t = b + c This looks incorrect. So no, I don't think the problem is with codingbat. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
On Sat, 12 Jul 2014 20:14:32 +0200, Johannes Bauer wrote: On 12.07.2014 18:35, Steven D'Aprano wrote: If you said, for many purposes, one should not compare floats for equality, but should use some sort of fuzzy comparison instead then I would agree with you. But your insistence that equality always is wrong takes it out of good advice into the realm of superstition. Bullshit. Comparing floats by their representation is *generally* a bad idea because of portability issues. You don't know if IEEE754 is used to represent floats on the systems that your code is used on. How many systems do you know of are there that support Python but don't support IEEE-754? Here's a thread from 2008 which discusses this: https://mail.python.org/pipermail/python-dev/2008-February/076680.html If you're running my code on an implementation of Python without IEEE-754 floats, then I'm quite happy to say Sorry guys, that's not my problem, you're on your own. And if you're running an implementation of Python where 1.0 != 1.0, well, your system is so broken that there is no hope for it. None what so ever. You're hairsplitting: when I'd have said in 99.9% of cases you'd agree with me I never said that. I would not put a percentage to it, because it depends on the context and what you are trying to do. For some uses, exact equality is the right solution. For others, an absolute epsilon comparison is better. For yet others still, a relative error, or a ULP comparison, are better solutions. There's no way of putting a percentage to those. You have to understand what you are doing, and not just mindlessly follow some superstition. When you mindlessly follow superstition, you end up with bogus warnings like this: https://gcc.gnu.org/ml/gcc/2001-08/msg00853.html but since I said always you disagree. Don't lawyer out. Comparing binary representation of floats is a crappy idea. Yes. And *not* comparing floats with == is a crappy idea too. *EVERY* method of comparing two floats to see if they are the same can break under some circumstances. Everything about floats is crappy, except that avoiding floats completely is *worse*. Nevertheless, floats are not magically cursed. They are deterministic, for any fixed combination of CPU (or FPU) + machine code, and if you understand how floats work, then you can understand when to use exact equality and when not to: http://randomascii.wordpress.com/2012/06/26/doubles-are-not-floats-so- dont-compare-them/ Using any sort of fuzzy comparison means that you lose transitivity: if x == y and y == z then x == z This holds for any sane floating point system, but it doesn't hold with fuzzy comparisons. By default, APL uses fuzzy comparisons instead of exact equality. Out of the thousands of programming languages ever designed, APL is unique, or at most one of a tiny handful of languages, which eschews exact float equality. Why do you think that is? The idea of tolerant comparisons and fuzzy functions is a fundamental design feature of APL: http://www.jsoftware.com/papers/satn23.htm nevertheless even in APL there are uses for setting the tolerance to zero (i.e. to get exact equality). Robert Bernecky gives one such example, and writes In such a search exact comparison is absolutely necessary. [Aside: I note that despite providing fuzzy comparison functions, and a system variable that controls the amount of fuzz, APL merely pushes the decision of how much fuzz is appropriate onto the user: In general, ⎕ct should be chosen to be the smallest value which is large enough to mask common arithmetic errors. And what about uncommon arithmetic errors, I wonder? But I digress.] Even more so in the age of cloud computing where your code is executed on who knows which architecture where the exact same high level interpretation might lead to vastly different results. If so, then that is a bug in the cloud computing platform. Not my problem. Complain to the provider. Not to mention high performance computing, where specialized FPUs can numerously be found which don't give a shit about IEEE754. Why should I support such broken platforms? If I run Python code on some horrible platform which only checks the first 8 characters of a string for equality for performance reasons: if monumentless == monumental: print Your Python is broken we'd all agree that the implementation was broken. Failure to meet at least the semantics of CPython floats is likewise broken. Another thing why it's good to NEVER compare floats with regards to their binary representation: Do you exactly know how your FPU is configured by your operating system. Do you know that your FPUs on a multiprocessor system are configured all identically with regards to 754? Rounding modes, etc? Just don't fall in the pit. Don't compare floats via equals. And this is why that advise is purest superstition. If you don't compare floats via equals, what are you supposed
[issue21922] PyLong: use GMP
Changes by Case Van Horsen cas...@gmail.com: -- nosy: +casevh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21922 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21955] ceval.c: implement fast path for integers with a single digit
Serhiy Storchaka added the comment: Let's try. As I understand, issue10044 was rejected because it complicates the code too much. May be new attempt will be more successful. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11077] Tkinter is not thread safe
Serhiy Storchaka added the comment: I can't reproduce the bug on 2.7.8+, but on 2.7.3 I sometimes got messages like Exception in thread Thread-26 (most likely raised during interpreter shutdown): or: File /usr/lib/python2.7/lib-tk/Tkinter.py, line 2204, in create_line File /usr/lib/python2.7/lib-tk/Tkinter.py, line 2184, in _create type 'exceptions.TypeError': 'NoneType' object is not callable This points to shutdown issue. When TkinterCrash2.py call quit(), other threads are still work. And when modules (including Tkinter and __main__) are cleaned, they try to call global functions which are set to None. After fixing TkinterCrash2.py to not invoke any code during shutdown, error messages on 2.7.3 gone. I don't see any bugs in Tkinter exposed by this script, only a bug in the script itself. Here is a script with quick and dirty fix. This solution is not perfect, there is small chance of race conditions (happened once in about 500 runs). Correct solution should be more complicated. If there no other errors in TkinterCrash2-2.py, this issue can be closed. -- Added file: http://bugs.python.org/file35927/TkinterCrash2-2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21922] PyLong: use GMP
Mark Dickinson added the comment: ... and if there's one person who's *very* well placed to comment on the ease or difficulty of keeping up with GMP/MPIR (especially on Windows), it's Case Van Horsen, who I notice has recently added himself to the nosy. @casevh: any comments? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21922 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
Landry Breuil added the comment: Seems something in between fixed it, because it works with 3.4.1. Can test 3.3 if needed. mikey:/usr/obj/tmpfs/ports/Python-3.4.1/Python-3.4.1/ $LD_LIBRARY_PATH=. ./Modules/_testembed --- Pass 0 --- interp 0xac003e00, thread state 0xb4380f80: id(modules) = 2813069072 interp 0xa84b8480, thread state 0xa897cd00: id(modules) = 2840181576 interp 0xa84b8dc0, thread state 0xb1a0b700: id(modules) = 2840181696 interp 0xb1efb540, thread state 0xaec09880: id(modules) = 2929755640 interp 0xac003e00, thread state 0xb4380f80: id(modules) = 2813069072 --- Pass 1 --- interp 0xab4f1780, thread state 0xaec09000: id(modules) = 2813071072 interp 0xac0035c0, thread state 0xaae20080: id(modules) = 2981253808 interp 0xb2bd6e00, thread state 0xaac10a00: id(modules) = 2981254728 interp 0xab4f1880, thread state 0xb0f31d00: id(modules) = 2862169464 interp 0xab4f1780, thread state 0xaec09000: id(modules) = 2813071072 --- Pass 2 --- interp 0xb3731e00, thread state 0xb3a6be00: id(modules) = 2812938720 interp 0xa8842e40, thread state 0xaac10c80: id(modules) = 2981325640 interp 0xab4f1500, thread state 0xaec09a80: id(modules) = 2981325160 interp 0xb3731b00, thread state 0xaec06580: id(modules) = 3039539968 interp 0xb3731e00, thread state 0xb3a6be00: id(modules) = 2812938720 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12588 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21932] os.read() must use Py_ssize_t for the size parameter
Serhiy Storchaka added the comment: Failed on 32-bit: == ERROR: test_large_read (test.test_os.FileTests) -- Traceback (most recent call last): File /home/serhiy/py/cpython/Lib/test/support/__init__.py, line 1592, in wrapper return f(self, maxsize) File /home/serhiy/py/cpython/Lib/test/test_os.py, line 136, in test_large_read data = os.read(fp.fileno(), size) OverflowError: Python int too large to convert to C ssize_t -- Re-add the @unittest.skipUnless(INT_MAX PY_SSIZE_T_MAX, needs INT_MAX PY_SSIZE_T_MAX) decorator (between cpython_only and bigmemtest). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21955] ceval.c: implement fast path for integers with a single digit
STINNER Victor added the comment: I'm not interested to work on this issue right now. If anyone is interested, please go ahead! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21955] ceval.c: implement fast path for integers with a single digit
STINNER Victor added the comment: Serhiy Storchaka added the comment: Let's try. As I understand, issue10044 was rejected because it complicates the code too much. May be new attempt will be more successful. I read that Mark rejected the issue #10044 because it introduces an undefined behaviour. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21932] os.read() must use Py_ssize_t for the size parameter
Roundup Robot added the comment: New changeset 880e2cdac8b1 by Victor Stinner in branch 'default': Issue #21932: Skip test_os.test_large_read() on 32-bit system http://hg.python.org/cpython/rev/880e2cdac8b1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21932] os.read() must use Py_ssize_t for the size parameter
STINNER Victor added the comment: Re-add the @unittest.skipUnless(INT_MAX PY_SSIZE_T_MAX, needs INT_MAX PY_SSIZE_T_MAX) decorator (between cpython_only and bigmemtest). Oh, I removed it because I thought that it was useless. I didn't understand the purpose of the test. I added a comment. Thanks for the report. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21965] Add support for Memory BIO to _ssl
New submission from Geert Jansen: The attached patch adds a _MemoryBIO type to _ssl, and a _wrap_bio() method to _SSLContext. The patch also includes tests. For now I kept _wrap_bio() and _MemoryBIO semi-private. The reason is that it returns an _SSLSocket instead of an SSLSocket and this type has not been exposed before as part of the public API. Changing the result of _wrap_bio to return an SSLSocket is not appropriate IMHO because it should not inherit from socket.socket which would waste a file descriptor and None of the IO methods are relevant. The patch works for me and gives no errors with --with-pydebug. I've also used it in an experimental branch of Gruvi and all the tests pass there too. -- files: ssl-memory-bio.patch keywords: patch messages: 222833 nosy: geertj priority: normal severity: normal status: open title: Add support for Memory BIO to _ssl type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file35928/ssl-memory-bio.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21965 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21084] IDLE can't deal with characters above the range (U+0000-U+FFFF)
Serhiy Storchaka added the comment: Yes, this is very similar to issue13153. Both these issues can have same solution or can have different solutions. This issue relates to more realistic situation and therefore is more important. Here is simple and almost working solution for this issue. Unfortunately it works incorrectly when astral characters are encountered in raw string literals. More mature solution should parse sources and convert raw string literals containing astral characters to non-raw string literals. But this will not work with invalid Python files and non-Python files. I afraid this issue has not perfect solution. The question is which imperfect solution and compromise we will decided enough acceptable. -- assignee: - serhiy.storchaka components: +Tkinter, Unicode keywords: +patch nosy: +haypo versions: +Python 2.7, Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file35929/idle_fix_non_bmp.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21084 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21961] Add What's New for Idle.
Serhiy Storchaka added the comment: Isn't IDLE-specific What's New file was merged in general What's New file few years ago? -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21961 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21932] os.read() must use Py_ssize_t for the size parameter
Serhiy Storchaka added the comment: Thank you for fixing os.read(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21951] tcl test change crashes AIX
Changes by Serhiy Storchaka storch...@gmail.com: -- priority: normal - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21951] tcl test change crashes AIX
Serhiy Storchaka added the comment: Is it crashes when comment out check((), '')? Is it crashes when comment out two previous checks (for inf and -inf)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16494] Add a method on importlib.SourceLoader for creating bytecode file format/container
Changes by Brett Cannon br...@python.org: -- assignee: - brett.cannon versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15600] expose the finder details used by the FileFinder path hook
Mark Lawrence added the comment: @Eric do you wish to take this any further? I'm only asking as Brett's questions in msg185283 are currently unanswered. -- nosy: +BreamoreBoy status: pending - open versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15600 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7979] connect_ex returns 103 often
Mark Lawrence added the comment: As the resolution is already set to out of date I believe this can be closed. -- nosy: +BreamoreBoy status: pending - open versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7979 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
Mark Lawrence added the comment: Accidentally set to pending? -- nosy: +BreamoreBoy status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19954] test_tk floating point exception on my gentoo box with tk 8.6.1
Mark Lawrence added the comment: I think this was meant to be closed rather than moved to pending see msg210788. -- nosy: +BreamoreBoy status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19954 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20026] sqlite: handle correctly invalid isolation_level
Mark Lawrence added the comment: Accidentally set to pending? -- nosy: +BreamoreBoy status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20026 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18228] AIX locale parsing failure
Mark Lawrence added the comment: Presumably this can be closed as fixed. -- nosy: +BreamoreBoy status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18228 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2008] cookielib lacks FileCookieJar class for Safari
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: -berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2008 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9325] Add an option to pdb/trace/profile to run library module as a script
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: -berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9325 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19076] Pdb.do_break calls error with obsolete file kwarg
Roundup Robot added the comment: New changeset afa9c0e24a71 by Berker Peksag in branch '3.4': Issue #19076: Don't pass the redundant 'file' argument to self.error(). http://hg.python.org/cpython/rev/afa9c0e24a71 New changeset d891ad8aeb80 by Berker Peksag in branch 'default': Issue #19076: Merge with 3.4. http://hg.python.org/cpython/rev/d891ad8aeb80 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19076] Pdb.do_break calls error with obsolete file kwarg
Berker Peksag added the comment: Thanks for the report, Michael. -- assignee: - berker.peksag components: -Extension Modules nosy: +r.david.murray resolution: - fixed stage: needs patch - resolved status: open - closed type: - behavior versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21932] os.read() must use Py_ssize_t for the size parameter
STINNER Victor added the comment: Serhiy Storchaka added the comment: Thank you for fixing os.read(). You're welcome, thanks for your help with the test. I hope that it would help you to implement FileIO in Python. FYI I saw EINVAL errors on test_large_read() on some buildbots, Mac OS X and FreeBSD if I remember correctly, when I forgot the bigmem decorator. And FreeBSD kills the process if there is not enough memory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21932 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21914] Create unit tests for Turtle guionly
Lita Cho added the comment: Make some changes to patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20026] sqlite: handle correctly invalid isolation_level
STINNER Victor added the comment: The patch has been commited, the issue can be closed. Yes pending was a mistake. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20026 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21914] Create unit tests for Turtle guionly
Lita Cho added the comment: Trying to attach a file again. I seem to be having trouble attaching it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21914] Create unit tests for Turtle guionly
Changes by Lita Cho lita@gmail.com: Added file: http://bugs.python.org/file35930/test_turtle_guionly_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
New submission from Alexander Belopolsky: When invoked with -q option, python3 prints no banner: $ python3 -q However, code.InteractiveConsole does not implement this feature: $ python3 -mcode -q Python 3.4.1 (default, May 19 2014, 13:10:29) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin Type help, copyright, credits or license for more information. (InteractiveConsole) -- keywords: easy messages: 222850 nosy: belopolsky priority: normal severity: normal status: open title: InteractiveConsole does not support -q option type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21922] PyLong: use GMP
Case Van Horsen added the comment: Disclaimer: as Mark alluded to, I maintain gmpy2. Some comments on MPIR/GMP: For all practical purposes, building GMP on Windows requires some version of the mingw compiler toolchain. None of the performance gains of custom assembly code is available if GMP is build with the VS compiler. When compiled with mingw, GMP supports CPU detection to automatically use code optimized for the specific instruction set. This level of optimization may not be needed for Python, though. The MPIR fork of GMP can be built with VS. Assembly code is supported via the YASM assembler plugin. Only a single instruction set is supported by the lib/dll. gmpy2 currently uses MPIR. I've had no issues with its stability. The mpz type has a maximum precision. IIRC, the maximum length is 2^31 bits on a 32-bit platform and 2^37 on a 64-bit platform. The mpn interface may or may not have the same restrictions. This might impact code that runs correctly, but slowly, with Python's normal PyLong implementation. GMP does not handle out-of-memory situations gracefully. When GMP encounters a memory allocation failure (exceeding the limits above or when running our of scratch space), it will just abort. It is easy in gmpy2 to trigger an abort that will crash the Python interpreter. My main concern is tightly linking the Python interpreter to a specific version of GMP (i.e. whatever version is used for the Windows builds or the version provided by the distribution). As long as gmpy2 can continue to use another version of GMP, it shouldn't matter to me. GMP and MPIR are both licensed under LGPL v3+ (not v2+). I'll reserve any further licensing discussions for python-dev. I'll try to test the patch this weekend and that should answer some of my questions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21922 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21967] Interpreter crash upon accessing frame.f_restricted of a frame from a dead thread
New submission from Anselm Kruis: If you store a reference to a frame from a dead thread and then access frame.f_restricted python eventually crashed. I didn't investigate this bug in depth. Here is my preliminary explanation. The access of frame.f_restricted causes a call of PyFrame_IsRestricted(f). PyFrame_IsRestricted is a macro and expands to ((f)-f_builtins != (f)-f_tstate-interp-builtins) Now, if the thread that created f is already dead, the f_tstate points to an invalid structure. Depending on the content of the memory the access of f_tstate-interp causes an access violation. I use a Win32 debug build to reliable reproduce the issue. -- components: Interpreter Core files: crash_on_f_restricted.py messages: 222852 nosy: anselm.kruis priority: normal severity: normal status: open title: Interpreter crash upon accessing frame.f_restricted of a frame from a dead thread type: crash versions: Python 2.7 Added file: http://bugs.python.org/file35931/crash_on_f_restricted.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21967 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21931] Nonsense errors reported by msilib.FCICreate for bad argument
Ezio Melotti added the comment: Do you want to propose a patch? -- components: +Windows nosy: +ezio.melotti, loewis, steve.dower, tim.golden, zach.ware stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
Mark Lawrence added the comment: ntpath.join() was fixed in issue19456 so I think all we need here is a commit review of the attached documentation patch. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15414 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21965] Add support for Memory BIO to _ssl
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21965 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1669539] Improve Windows os.path.join (ntpath.join) smart joining
Mark Lawrence added the comment: I've asked for a commit review on issue 15414 so can we close this? -- nosy: +BreamoreBoy status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1669539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15414 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1669539] Improve Windows os.path.join (ntpath.join) smart joining
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1669539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15849] PEP 3121, 384 Refactoring applied to xx module
Alexander Belopolsky added the comment: I added documentation to the components list because this in the main purpose of this module - to serve as a template for extension module writers. -- assignee: - docs@python components: +Documentation nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15849] PEP 3121, 384 Refactoring applied to xx module
Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21928] Incorrect reference to partial() in functools.wraps documentation
Ezio Melotti added the comment: The docstring is correct, as this is how wraps is implemented (see Lib/functools.py#l73). partial(update_wrapper, wrapped=wrapped, assigned=assigned, updated=updated) will return a partial version of update_wrapper() where only the wrapper argument is missing. The missing argument is the function decorated with wraps(). For example, this code: def my_decorator(f): @wraps(f) def wrapper(*args, **kwds): return f(*args, **kwds) return wrapper is equivalent to: def my_decorator(f): def wrapper(*args, **kwds): return f(*args, **kwds) wrapper = wraps(f)(wrapper) return wrapper Here wraps(f) creates a partial version of update_wrapper, with only the wrapped argument (i.e. f) set. When the partial object returned by wrap(f) gets called, the missing wrapper argument is received, thus making wraps(f)(wrapper) equivalent to: def my_decorator(f): def wrapper(*args, **kwds): return f(*args, **kwds) wrapper = update_wrapper(wrapper, f) return wrapper That said, I agree that the sentence you quoted is not too clear/intuitive, but the following example is quite clear, so I'm not sure it's worth to removing/rephrasing the first part. Maybe it could say something like This is a convenience function for invoking update_wrapper() (by using partial(update_wrapper, wrapped=wrapped, assigned=assigned, updated=updated)) as a function decorator when defining a wrapper function. instead? -- nosy: +ezio.melotti, r.david.murray, rhettinger, terry.reedy status: open - pending type: - enhancement versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21928 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21934] OpenBSD has no /dev/full device
Ezio Melotti added the comment: If it's not needed in other places, I think the proposed patch might be OK (assuming it works fine on other platforms). -- nosy: +ezio.melotti stage: - patch review versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21941] Clean up turtle TPen class
Ezio Melotti added the comment: While TPen doesn't seem to be documented, it's not prefixed by a '_', so there might people using it and relying on these methods. -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21941 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21946] 'python -u' yields trailing carriage return '\r' (Python2 for Windows)
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21946 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15849] PEP 3121, 384 Refactoring applied to xx module
Stefan Krah added the comment: I think we should perhaps leave the xxmodule as an example for static types and create another pep-384 version that mentions *potential* performance traps. Of course many modules won't suffer from this, but first-time extension writers tend to paste from the examples and should know the alternatives if they happen to write a performance sensitive application. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15849] PEP 3121, 384 Refactoring applied to xx module
Alexander Belopolsky added the comment: create another pep-384 version +1 - and with a more descriptive name than xxmodule.c Suggestions: * pep384module.c * pep384demo.c * pep384.c * abidemo.c -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Anton Barkovsky added the comment: Here's a patch. -- keywords: +patch nosy: +anton.barkovsky Added file: http://bugs.python.org/file35932/code.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Alexander Belopolsky added the comment: That was quick! (Well - I knew it would not be hard.) I have two questions: 1. How should python3 -q -mcode behave? 2. If we add this patch, should we also attempt to emulate other command line options (-V, -h, etc.)? -- assignee: - belopolsky nosy: +benjamin.peterson stage: - commit review versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- components: +Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14050] Tutorial, list.sort() and items comparability
R. David Murray added the comment: Unless I'm misremembering, it is exactly __lt__ (or __gt__, if __lt__ returns NotImplemented) that sorting depends on. Since I'm sure there is code out there that depends on this fact, I wonder if it should be part of the language definition. Also, the comparison documentation (https://docs.python.org/3/reference/expressions.html#comparisons) speaks about total ordering as being the requirement, which has a specific mathematical meaning (which sets, for example, do not satisfy, even though they have a __lt__ method). Whether or not the distinction is worth explaining in the tutorial is a open question. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14050 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7979] connect_ex returns 103 often
Changes by Ned Deily n...@acm.org: -- stage: test needed - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7979 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
R. David Murray added the comment: Whether or not other options are emulated, unimplemented ones should probably be rejected. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Anton Barkovsky added the comment: 1. How should python3 -q -mcode behave? I've only now found out about sys.flags. I think we should check for -q both before -m and after, because why not? 2. If we add this patch, should we also attempt to emulate other command line options (-V, -h, etc.)? As I see it, the module is only concerned with REPL functionality, making these options a bit out of scope. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Alexander Belopolsky added the comment: In order to implement reasonable rejection behavior, we probably need to add some support for -h. $ python3 -z Unknown option: -z usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. I don't think we should condition acceptance of this patch on extra features. AFAICT, the main use of the code module is in embedded situations and the if __name__ == __main__ behavior is mostly there for demonstration purposes. On the other hand, something like $ python3 -mcode -z Unknown option: -z usage: python3 -mcode [-q] is not hard to implement. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7976] warnings should provide a public API for accessing its option parsing code
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7976 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Anton Barkovsky added the comment: Here's a patch that checks both sys.flags and sys.argv and uses argparse. -- Added file: http://bugs.python.org/file35933/code_flags_argparse.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Alexander Belopolsky added the comment: I think we should check for -q both before -m and after, because why not? If we check for sys.flags.quiet, wouldn't it be surprising to have $ python3 -mcode -q import sys; sys.flags.quiet 0 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Anton Barkovsky added the comment: That's not a very likely scenario and I think the distinction between arguments that are passed to the script and interpreter flags is fairly obvious. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Alexander Belopolsky added the comment: A nitpick: banner=banner in + interact(banner=banner) is redundant. + interact(banner) would work and is just as clear. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21966] InteractiveConsole does not support -q option
Anton Barkovsky added the comment: Yeah, my love for keyword arguments is a bit too big sometimes. -- Added file: http://bugs.python.org/file35934/code_flags_argparse_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21934] OpenBSD has no /dev/full device
Mark Lawrence added the comment: The patch is against test_file2k.py which I can't find in my default cpython setup. If this was removed from (say) Python 3.0 how do I check for that? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6895] locale._parse_localename fails when localename does not contain encoding information
Mark Lawrence added the comment: I agree with the sentiment expressed in msg218513 and would close this as out of date. -- nosy: +BreamoreBoy status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6895 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21934] OpenBSD has no /dev/full device
Ezio Melotti added the comment: I tried to grep on 3.x for this test but it looks like it's been removed there, so this issue only affects 2.7. -- versions: -Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21961] Add What's New for Idle.
Terry J. Reedy added the comment: The Python x.y docs describe the Python x.y language and stdlib, minus Idle (and turtledemo). The Python x.(y+1) What's New describes the delta between Python x.y and x.(y+1) in a user friendly and relevant way. The Idle model of What's New type changes in every release does not fit the general model. For one thing, instead of all new non-bugfix changes appearing in .0 releases, there will be very few if any really new changes in x.(y+1).0. Almost all changes will have already appeared in some x.y.(z0) release. Whatever is supposed to be the situation with Idle news is not working right and would not be sufficient even it did. What's New in 2.7 has this (and only this) about Idle: --- PEP 434: IDLE Enhancement Exception for All Branches PEP 434 describes a general exemption for changes made to the IDLE ... For details of any IDLE changes, refer to the NEWS file for the specific release. -- As near as I can tell, the general NEWS file is not easily accessible. So I think that should say 'Idle NEWS file , accessible through Help / About Idle'. However, the 2.7 Idle news.txt file has not been updated since 2.7.5. Last year I suggested that Idle NEWS entries should begin in the idlelib file and be transferred to Misc/NEWS upon release. This was vetoed, and it was claimed that the transfer should and would happen the other way. It is not. What's New 3.4 has only this about Idle: Running IDLE with the -n flag (no subprocess) is deprecated. However, the feature will not be removed until issue 18823 is resolved. For 3.4.1, nothing was added to Idle NEWS. Nothing was added after 3.3.0 either. The update on release is not happening. Even if Idle news.txt were properly updated, it would not serve the purposes served by What's New and even the html changelog version of Misc/NEWS. The entries are disorganized, unfiltered, duplicated, tied to specific patches rather than user topics, begin with *unlinked* issue numbers, and say too little for the user. Unfiltered: most of the recent Idle news entries are about unittest and human test additions. Here is what I might put in a What's New document to cover them all. --- Idle tests: An automated unittest suite was started in May 2013. Users can run it with python -m test -ugui test_idle. Adding -v will display the test classes and methods. A human-operated test suite was started in May 2014. Uses can run it with python -m idlelib.test_idle.htest. Report problems to the idle-dev mailing list. --- There are other items that are also not relevant to normal users. Duplication: if 3.4 news.txt were properly updated release by release, then the items listed for 3.5.0 would be the cumulative list added for 3.4.1 through 3.4.final, plus any 3.5-only user-relevant items that get added (there are none now). This issue is about adding something that does not exist: an Idle specific file accessible from the idle help menu that it updated as needed with the occasional non-obvious user-relevant changes, especially those that users *need* to read. An example of the latter is moving the the setting for the formatparagraph extension from config-main to confix-extensions (#20577). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21961 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5248] Adding T_SIZET to structmember.h
Mark Lawrence added the comment: msg81942 states structmember.h lacks a 'T_SIZET' define in order to properly support struct fields of type 'size_t' within PyMemberDef. As we have managed without this feature for the last five years do we really need it now? What do we gain by implementing this? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5248 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21964] inconsistency in list-generator comprehension with yield(-from)
Ezio Melotti added the comment: There seem to be two issues here: list comprehension with yield(-from) would return a generator. This is somewhat surprising, and I'm not sure it's expected/documented. The example you provided seems to behave reasonably, so I don't think we should change the behavior (unless there is some actual bug in similar example). If anything, we could document this, but I'm not sure if it's worth doing it and where could be added. generator comprehension would yield some None in the middle of the expected values. This also seems expected, and the behavior is consistent with the equivalent generator function. -- nosy: +ezio.melotti, gcewing, ncoghlan versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
