ANN: Rainbowstream: smart and nice Twitter client on terminal
Rainbow Stream v0.2.5 is now available. Homepage: http://www.rainbowstream.org/ Github: https://github.com/DTVD/rainbowstream Pypi: https://pypi.python.org/pypi Documents:http://rainbowstream.readthedocs.org/en/latest/ Rainbow Stream is a smart and nice Twitter client on terminal. It has colourful stream, interactive commands and beautiful built-in themes. It even can display an image directly on terminal. License: MIT Author: Vu Nhat Minh * Twitter: @dtvd88 * Mail: nhatminh...@gmail.com PA HREF=http://www.rainbowstream.org/;Rainbow Stream 0.2.5/A - A smart and nice Twitter client on terminal. (08-07-2014) -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: error handling when opening files
Alex Burke alexjeffbu...@gmail.com:
While reading up on a previous thread 'open() and EOFError' I saw the
following (with minor changes to help make my question clearer) block
suggested as a canonical way to open files and do something:
try:
f = open(path)
except IOError:
handle_error()
else:
with f:
do_stuff()
This somewhat surprised me because I'd always written such a block
something more as follows:
try:
with open(path) as f:
do_stuff()
except IOError:
handle_error('file never opened')
except ApplicationError:
handle_error('doing something with the content went wrong')
Aside from the pythonic but less widely known else clause of the
try/except in the first form, what else is different? What nuances am
I missing?
Your version catches IOError for do_stuff() as well as open(). You
usually want to guard each statement with try-except so you can log and
pinpoint the error better.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
PyPy-STM: first interesting release
A GIL-less Python? See http://morepypy.blogspot.co.uk/2014/07/pypy-stm-first-interesting-release.html -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Tue, 08 Jul 2014 11:22:25 +1000, Ben Finney wrote:
A group of (a particular amount of) U+0020 characters is visually
indistinguishable from a U+0009 character, when the default semantics
are applied to each.
Hmmm. I'm not sure there actually *is* such a thing as default
semantics for tabs. If you look at a tab character in a font, it
probably looks like a single space, but that depends on the font
designer. But if you look at it in a text editor, it will probably look
like eight spaces, unless it looks like four, or some other number, and
if you look at it in a word processor, it will probably look like a jump
to the next tab stop command. In a spreadsheet application, it will be a
cell separator and consequently doesn't look like anything at all. I
don't think any of those things count as default semantics.
The point being, tabs are *control characters*, like newlines and
carriage returns and form feeds, not regular characters like spaces and
A or λ. Since indent is an *instruction* rather than a character,
it is best handled with a control character.
In any case, if we limit ourselves to text editors, only a specific
number of spaces will be visually indistinguishable from a tab, where the
number depends on which column you start with:
x x # Tab
x x # Seven spaces
x x# Six spaces
xx # Eight spaces
Even in a proportional font, the last two should be distinguishable from
the first two. Admittedly, that does leave the case where N spaces (for
some 1 = N = 8) looks like a tab. That's a probably, but it's not the
only one:
* End of line is a problem. I know of *at least* the following seven
conventions for end-of-line:
- ASCII line feed, \n (Unix etc.)
- ASCII carriage return, \r (Acorn, ZX Spectrum, Apple, etc.)
- ASCII \r\n (CP/M, DOS, Windows, Symbian, Palm, etc.)
- ASCII \n\r (RISC OS)
- ASCII Record Separator, \x1E (QNX)
- EBCDIC New Line, \N{NEXT LINE} in Unicode (IBM mainframes)
- ATASCII \x9B (Atari)
* Form feeds are a problem, since they are invisible, but still get used
(by Vim or Emacs, I forget which) to mark sections of text.
* Issues to do with word-wrapping and hyphenation, or lack thereof, are a
problem.
* Encoding issues are a problem.
* There are other invisible characters than spaces (non-breaking space,
em-space, en-space, thin space).
The solution is to use a smarter editor. For example, an editor might
draw a horizontal rule to show a form feed on a line of its own, or
highlight unexpected carriage return characters with ^M, or display tabs
in a different colour from spaces, or overlay it with a \x09 glyph. Or an
editor might be smart enough to automatically do what the current
paragraph or block does: if the block is already indented with tabs,
pressing tab inserts a tab, but if it is indented with spaces, pressing
tab inserts spaces.
Isn't this why you recommend people use a programmer's editor rather than
Notepad? A good editor should handle these things for you automatically,
or at least with a minimum amount of manual effort.
The former is a control character, which has specific semantics
associated with it; the latter is a printable character, which is
usually printed and interpreted as itself (although in this particular
case, the printed representation is hard to see on most output
devices).
And those specific semantics make the display of those characters easily
confused. That is why it's generally a bad idea to use U+0009 in text
edited by humans.
I disagree. Using tabs is no more a bad idea than using a formfeed, or
having support for multiple encodings.
This mailing list doesn't seem to mind that lines beginning with ASCII
SPC characters are semantically different from lines beginning with
ASCII LF characters, although many detractors of Python seem unduly
fixated on it.
The salient difference being that U+000A LINE FEED is easily visually
distinguished from a short sequence of U+0020 SPACE characters. This
avoids the confusion, and makes use of both together unproblematic.
True, but that's *only* because your editor chooses to follow the
convention display a LINE FEED by starting a new line rather than by
the convention display the (invisible or zero-width) glyph of the LINE
FEED. If editors were to standardise on the convention display a
HORIZONTAL TAB character as visibly distinct from a sequence of
spaces (e.g. by shading the background a different colour, or overlying
it with an arrow) then we would not be having this discussion.
In other words, it is the choice of editors to be *insufficiently smart*
about tabs that causes the problem. There is a vicious circle here:
* editors don't handle tabs correctly
* which leads to (some) people believing that tabs are bad and should
be avoided
* which leads to editors failing to handle tabs correctly, because tabs
are bad and should be avoided.
A pity really.
Re: open() and EOFError
On Mon, 07 Jul 2014 14:49:56 -0400, Terry Reedy wrote: Avoid EOFError. Much better, I think, is the somewhat customary s = input(Enter something, or hit return to exit) if not s: sys.exit() else: process s Under many circumstances, I would do exactly that. But sometimes an empty string is valid data, not a signal for special processing (whether exiting the application, or something else). -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: error handling when opening files
On Tue, 08 Jul 2014 01:49:58 +0200, Alex Burke wrote:
Hi there,
While reading up on a previous thread 'open() and EOFError' I saw the
following (with minor changes to help make my question clearer) block
suggested as a canonical way to open files and do something:
Emphasis on a canonical way, out of many canonical ways ;-)
try:
f = open(path)
except IOError:
handle_error()
else:
with f:
do_stuff()
I wrote it that way to show that there is no need to fall back on the old-
fashioned try...except...finally idiom that was used before the with
statement and context managers. In practice, I would usually do what you
do:
This somewhat surprised me because I'd always written such a block
something more as follows:
try:
with open(path) as f:
do_stuff()
except IOError:
handle_error('file never opened')
except ApplicationError:
handle_error('doing something with the content went wrong')
assuming that open() and do_stuff() don't raise the same exceptions. If
they do raise the same exceptions, and it is important to distinguish
IOError raised by open() from IOError raised by do_stuff, then you cannot
use this idiom.
Aside from the pythonic but less widely known else clause of the
try/except in the first form, what else is different? What nuances am I
missing?
The reason I preferred the second was in addition to catching the
IOError when attempting the open() if the file does not exist I thought
I was accounting for the possibility en error occurs while reading data
out of the file. That and to handle if do_stuff() was actually calling
readline() or such on the file which I thought was possible source of
issues.
Correct. But now imagine you're happily reading through the file,
processing line after line, and halfway through the file read() fails
because it's on a network share and somebody just tripped over the cable.
Your script now *lies to you* and says the file was never opened.
If you care about accurate error messages, you should be more careful
about conflating two different errors (that is, catching too much in a
single try...except block).
I am wondering if this is also related to some misunderstanding around
the file context manager - on exit of the with() block a close is
arranged, but if that close() is called in an error situation I was
under the impression that the error would be raised again outside it.
In general, context managers may choose whether or not to re-raise
exceptions. Some exceptions are not errors and may be swallowed silently.
However, file objects will re-raise the error.
Interestingly, did you know that even *closing* a file can fail?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: PyPy-STM: first interesting release
On Tue, 08 Jul 2014 09:48:08 +0100, Mark Lawrence wrote: A GIL-less Python? See http://morepypy.blogspot.co.uk/2014/07/pypy-stm-first-interesting- release.html Both Jython and IronPython are GIL-less, and have been forever. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Tue, Jul 8, 2014 at 6:48 PM, Steven D'Aprano st...@pearwood.info wrote: If editors were to standardise on the convention display a HORIZONTAL TAB character as visibly distinct from a sequence of spaces (e.g. by shading the background a different colour, or overlying it with an arrow) DeScribe Word Processor has (had? it hasn't been developed in about a decade... but it still runs just fine) a whole lot of visual guides for metacharacters, which can be turned on or off. Normally, we prefer not to have a little dot to mark every 0x20 space, but you can have 'em if you want 'em; tabs get shown as diamonds; paragraph markers as pilcrows; line breaks as a small circle; and so on. (The difference between a paragraph and a line break isn't a normal one in most text editors, so I'd be looking at representing U+000A newlines with a pilcrow, probably.) Obviously you need a means of distinguishing the end-of-line marker from an actual character, since PILCROW SIGN is a perfectly acceptable character; but if the metacharacters are shown in, say, a pale blue, rather than the usual black text, it'd be easy enough. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Steven D'Aprano st...@pearwood.info: * editors don't handle tabs correctly But you said yourself: I'm not sure there actually *is* such a thing as default semantics for tabs. What is correct handling of ASCII TAB characters in a text file? The unix tradition is to let the TTY interpret the TABs. Utilities such as ed, cat, diff or gcc don't interpret or process TABs in any way but simply output them together with the rest of the text. And the TTY tradition is to have TAB stops at every 8 columns (by default). So this question has little to do with text editors except in that your editor should display your program roughly the same way as lpr prints it out. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Tue, Jul 8, 2014 at 7:09 PM, Marko Rauhamaa ma...@pacujo.net wrote: The unix tradition is to let the TTY interpret the TABs. Utilities such as ed, cat, diff or gcc don't interpret or process TABs in any way but simply output them together with the rest of the text. Not quite; tools like diff that put a character at the beginning of the line are likely to be tab-aware, and gcc is certainly going to comprehend them (at least to the extent of treating them as whitespace). And I think less takes notice of them, too, so it's only the very simplest tools like cat that actually ignore them or treat them as single characters (or even bytes). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On Tue, Jul 8, 2014 at 7:03 PM, Steven D'Aprano st...@pearwood.info wrote: On Mon, 07 Jul 2014 14:49:56 -0400, Terry Reedy wrote: Avoid EOFError. Much better, I think, is the somewhat customary s = input(Enter something, or hit return to exit) if not s: sys.exit() else: process s Under many circumstances, I would do exactly that. But sometimes an empty string is valid data, not a signal for special processing (whether exiting the application, or something else). Or you want to have two different signals: empty string means use the default, and something else means exit the application now please. Very common. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: error handling when opening files
On Tue, Jul 8, 2014 at 7:00 PM, Steven D'Aprano st...@pearwood.info wrote: Interestingly, did you know that even *closing* a file can fail? I know that can happen with SSL sockets (which can require writing and reading). Can't think of any situations on normal file systems where that's true, unless the actual failure is in the flushing of buffers; technically, that's not a failure of closing, but it could be a failure that's detected on close(). Is that what you're thinking of? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
generic _ssl error
I have the following from some production machines when trying to clone / pull etc etc using mercurial on ubuntu 10.04 hg clone https://myhost/myrepos abort: error: _ssl.c:480: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm I believe that _ssl.c must be the _ssl.so module which presumably is being used by the hg command. The system python which mercurial uses is Python 2.7.2 (default, Sep 20 2011, 16:38:53) Could this error be the result of upgrading the openssl to fix heartbleed and not upgrading the system python? On other servers I am able to clone etc etc without issue, but those are almost all 12.04 machines and were fully updated at the time of heartbleed. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Chris Angelico ros...@gmail.com:
Not quite; tools like diff that put a character at the beginning of
the line are likely to be tab-aware,
No, just tried it again: diff outputs tabs as tabs.
$ diff abc def
1,2c1,2
abc
abc
---
def
def
where line 1 begins with a tab and line 2 begins with 8 spaces in each
file.
and gcc is certainly going to comprehend them
$ gcc -c test.c
test.c:1:2: error: expected identifier or ‘(’ at end of input
where test.c contains
TAB(LF
IOW, gcc reports that the open parenthesis is in column 2.
(at least to the extent of treating them as whitespace).
Sure, but that doesn't concern the tab stops in any way.
And I think less takes notice of them, too,
How?
so it's only the very simplest tools like cat that actually ignore
them or treat them as single characters (or even bytes).
They all seem to be simple. At least Python is:
$ python3 -c 'print ('
File string, line 1
print(
^
SyntaxError: unexpected EOF while parsing
where the caret is pointing at the wrong visual column.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Tue, Jul 8, 2014 at 9:13 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
Not quite; tools like diff that put a character at the beginning of
the line are likely to be tab-aware,
No, just tried it again: diff outputs tabs as tabs.
$ diff abc def
1,2c1,2
abc
abc
---
def
def
where line 1 begins with a tab and line 2 begins with 8 spaces in each
file.
Check out its -t and -T options; diff is definitely tab-aware.
and gcc is certainly going to comprehend them
$ gcc -c test.c
test.c:1:2: error: expected identifier or ‘(’ at end of input
where test.c contains
TAB(LF
IOW, gcc reports that the open parenthesis is in column 2.
It's easier to number the positions that way, in the same way that you
would number lines - by how many times you have to hit down or right
arrow to get there. In my MUD client, I measure text positions in
characters (within a line; a particular position is identified by
(line, char), because lines are generally far more important than
overall positions), even when tabs are involved; a tab simply counts
as one character, even though it displays as up to eight times the
width. Actually, I'm currently contemplating a reworking of how that's
all mapped out, which would mean that *any* character is allowed to
take up *any* width, including zero, in which case the only
significance is that a tab takes up a variable width depending on
where it is in the line (which is already coped with).
And I think less takes notice of them, too,
How?
Shrink your terminal down to some weird width like 45, create a file
with long lines including tabs, 'less' the file, and use the right
arrow key to scroll horizontally. It takes note of tabs and renders
them properly.
so it's only the very simplest tools like cat that actually ignore
them or treat them as single characters (or even bytes).
They all seem to be simple. At least Python is:
$ python3 -c 'print ('
File string, line 1
print(
^
SyntaxError: unexpected EOF while parsing
where the caret is pointing at the wrong visual column.
If someone cares enough to write a patch, I'm sure the traceback
renderer could be improved. But how many people actually use tabs
inside code like that?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On 2014-07-07, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Terry Reedy wrote: Avoid EOFError. Much better, I think, is the somewhat customary s = input(Enter something, or hit return to exit) if not s: sys.exit() else: process s I beg to differ -- on Unix, Ctrl-D *is* the customary way to exit from something that's reading from stdin. Indeed. Ctrl-D is _the_ canonical way to tell a program that's reading stdin that your're done. I've never run across hit return to exit. In any case, you need to be able to handle EOF gracefully if the user uses it. -- Grant Edwards grant.b.edwardsYow! Nipples, dimples, at knuckles, NICKLES, gmail.comwrinkles, pimples!! -- https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On 7/7/2014 7:10 PM, Mark Lawrence wrote: On 07/07/2014 23:09, Gregory Ewing wrote: Marko Rauhamaa wrote: with open(path) as f: ... If the open() call is guarded against exceptions (as it usually should), one must revert to the classic syntax: Hmmm, maybe we could do with a with-except statement: with open(path) as f: ... except IOError: # Catches exceptions in the with-expression only ... Although that would be a bit confusing. I wrap the with inside a try/except, the other file handling parts within another try/except and use the finer grained exceptions from PEP 3151 to write (at least to my eye) cleaner looking code. Somehow I think we'll get agreement on the best way to do this when the cows come home. On Windows it's my experience that EOF from interactive sessions is ignored. Programs keep going as best they can, providing some other means of exit, e.g., an 'exit' command. But maybe that's just the shell. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
NaN comparisons - Call For Anecdotes
Most people don't need to deal with NaN's in Python at all, fortunately. They just don't appear in normal computation, because the interpreter raises an exception instead. It happens in my work I come across them quite a lot. I'm writing software that talks to embedded applications that can contain NaN values for a variety of reasons - never-initialised storage, initialise-to-NaN, hardware failures etc. So when my software reads these values in binary, unpack them using the struct module, and goes to work. And NaN's are no different from any other value, it's something to store, compare, display etc. And that worked fine in my Python 2.4 apps. Then I upgraded to 2.7 and it broke. Because 2.7 goes out of it's way to ensure that NaN's don't compare equal to themselves. I discovered it when a sanity check told me that two functions, to_binary and from_binary, weren't each other's inverse, as they were intended to be. Apparently, bitPattern==to_binary(from_binary(bitPattern)) wasn't true for this particular value of bitPattern. Of course, the bit pattern in question was the binary representation for a floating-point NaN. Panic time! If I can't trust == to return True for (mathematically) equal objects, that means that every single algorithm I had ever written that explicitly or implicitly does .__eq__ or .__ne__ comparison was suspect! That meant I had 3 lines of code to review. Every time there's a comparison, if there was any chance that either value could be a float NaN, I would have to change e.g. if x==y: to if x==y or (isinstance(x, float) and isinstance(y, float) and math.isnan(x) and math.isnan(y)): To make it bearable, I could wrap the pattern up in a function and write if my_equal(x,y): but I would still lose, because the standard library does == and != all over the place without calling my_equal. In the end I came up with this hack: Every time I struct.unpack'd a float, I check if it's a NaN, and if it is, then I replace it with a reference to a single, shared, canonical NaN. That means that container objects that skip __equal__ when comparing an object to itself will work -- e.g. hash keys. It's half a solution, of course: Any further computation with a NaN value will change it to a different NaN object, so I still needed to do explicit NaN-checks in various places. I'm sure there are still NaN-related bugs in my code, but right now it's good enough - I haven't seen NaN-related bugs in a good while. Now, all this bothers me. Not that I had to do some work to get stuff to work in an imperfect world. No, what bothers me is that this behaviour was explicitly and deliberately put in for no good reason. The only reason is standard says so. Not that there's any legal requirement for Python to follow the IEEE-754 standard. Or for that matter, for Python's spelling of IEEE-754 comparisons to be ==. So I make this claim: float.__eq__ implementing IEEE-754 NaN comparison rules creates real problems for developers. And it has never, ever, helped anyone do anything. Never is a strong claim, and easily disproven if false: Simply provide a counterexample. So that is my challenge: If you have a program (a pre-existing and useful one, not something artificial created for this challenge) that benefits from NaN!=NaN and that would fail if x==x for all float objects x, then please come forward and show it, and I'll buy you a beer the next time I'm at PyCon. regards, Anders -- https://mail.python.org/mailman/listinfo/python-list
Naming conventions for functions and methods
Looking for your opinions on how you name your functions and methods. Example: I have a function that hashes a file. I could name this function hash_file() or file_hash(). The 1st naming convention sounds more natural, the 2nd naming convention allows one to group related functions together by the object being acted on. PEP-8 doesn't appear to offer guidance in this area. Thoughts? Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On 7/8/2014 10:19 AM, Grant Edwards wrote: On 2014-07-07, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Terry Reedy wrote: Avoid EOFError. Much better, I think, is the somewhat customary s = input(Enter something, or hit return to exit) if not s: sys.exit() else: process s I beg to differ -- on Unix, Ctrl-D *is* the customary way to exit from something that's reading from stdin. Indeed. Ctrl-D is _the_ canonical way to tell a program that's reading stdin that your're done. Not on Windows. I've never run across hit return to exit. In any case, you need to be able to handle EOF gracefully if the user uses it. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Wed, Jul 9, 2014 at 12:53 AM, Anders J. Munch 2...@jmunch.dk wrote:
In the end I came up with this hack: Every time I struct.unpack'd a
float, I check if it's a NaN, and if it is, then I replace it with a
reference to a single, shared, canonical NaN. That means that
container objects that skip __equal__ when comparing an object to
itself will work -- e.g. hash keys.
Let's take a step back.
No, let's take a step forward.
And let's take a step back again.
(And we're building a military-grade laser!)
Why *should* all NaNs be equal to each other? You said on the other
list that NaN==NaN was equivalent to (2+2)==(1+3), but that assumes
that NaN is a single thing. It's really describing the whole huge
area of stuff that just ain't numbers. Imagine if (x + y) wasn't 4,
but was table. And (a + b) turned out to be cyan. Does table equal
cyan, just because neither of them is a number? Certainly not. Neither
should (inf - inf) be equal to (inf / inf). Both of those expressions
evaluate to something that can't possibly be a number - it can't be
anywhere on the number line, it can't be anywhere on the complex
plane, it simply isn't a number. And they're not the same non-numeric
thing.
For hash keys, float object identity will successfully look them up:
d={}
d[float(nan)]=1
d[float(nan)]=2
x=float(nan)
d[x]=3
d[x]
3
d
{nan: 1, nan: 2, nan: 3}
So I'm not sure where the problems come from. You can iterate over a
dict's keys and look things up with them:
for k,v in d.items():
print(k,v,d[k])
nan 1 1
nan 2 2
nan 3 3
You can do a simple 'is' check as well as your equality check:
if x is y or x == y:
print(They're the same)
But any time you compare floats for equality, you *already* have to
understand what you're doing (because of rounding and such), so I
don't see why the special case on NaN is significant, unless as
mentioned above, you want all NaNs to be equal, which doesn't make
sense.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On 2014-07-08 11:08, Terry Reedy wrote: Indeed. Ctrl-D is _the_ canonical way to tell a program that's reading stdin that your're done. Not on Windows. Okay, EOF is the canonical way to tell a program reading stdin that you're done. It just happens that EOF ^D on *nix-likes and ^Z on Win32. :-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, Jul 8, 2014 at 8:53 AM, Anders J. Munch 2...@jmunch.dk wrote: And that worked fine in my Python 2.4 apps. Then I upgraded to 2.7 and it broke. Because 2.7 goes out of it's way to ensure that NaN's don't compare equal to themselves. As far as I know nothing changed between 2.4 and 2.7 in this regard. Python has always had NaN compare unequal to everything, per the standard. I discovered it when a sanity check told me that two functions, to_binary and from_binary, weren't each other's inverse, as they were intended to be. Apparently, bitPattern==to_binary(from_binary(bitPattern)) wasn't true for this particular value of bitPattern. Of course, the bit pattern in question was the binary representation for a floating-point NaN. Okay, here's your problem: there isn't just one binary representation for NaN. The standard defines any value with all 1's in the exponent and a non-zero significand as NaN (a zero significand would instead be an infinity). Your bit comparison is going to have to be prepared to compare NaNs that don't have the same binary representation. By the way, there are also multiple binary representations for 0. If you compare them as floats, then they'll compare equal to one another, but if you're just comparing binary representations then you'll have issues there as well. Now, all this bothers me. Not that I had to do some work to get stuff to work in an imperfect world. No, what bothers me is that this behaviour was explicitly and deliberately put in for no good reason. The only reason is standard says so. Not that there's any legal requirement for Python to follow the IEEE-754 standard. Or for that matter, for Python's spelling of IEEE-754 comparisons to be ==. Following the standard isn't a good reason itself? It seems to me that one should be expected to provide a strong justification for *deviating* from the standard, not for following it. -- https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase python.l...@tim.thechases.com wrote: On 2014-07-08 11:08, Terry Reedy wrote: Indeed. Ctrl-D is _the_ canonical way to tell a program that's reading stdin that your're done. Not on Windows. Okay, EOF is the canonical way to tell a program reading stdin that you're done. It just happens that EOF ^D on *nix-likes and ^Z on Win32. :-) -tkc I can't think of any Windows-native programs that ask for EOF. Only those which came from POSIX platforms do it. That said, though, Windows doesn't tend to encourage interactive command-line programs at all, so you may as well just follow the Unix convention. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, Jul 8, 2014 at 10:19 AM, Chris Angelico ros...@gmail.com wrote:
For hash keys, float object identity will successfully look them up:
d={}
d[float(nan)]=1
d[float(nan)]=2
x=float(nan)
d[x]=3
d[x]
3
d
{nan: 1, nan: 2, nan: 3}
Neat!
S
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Wed, Jul 9, 2014 at 1:24 AM, Skip Montanaro s...@pobox.com wrote:
On Tue, Jul 8, 2014 at 10:19 AM, Chris Angelico ros...@gmail.com wrote:
For hash keys, float object identity will successfully look them up:
d={}
d[float(nan)]=1
d[float(nan)]=2
x=float(nan)
d[x]=3
d[x]
3
d
{nan: 1, nan: 2, nan: 3}
Neat!
Yeah. It's one of those arguable points; is it a mere optimization
that dict lookup does an identity check before an equality check, or
is it crucial to other invariants (like the iteration one - if you
iterate over items(), it should give exactly the same results as
iterating over keys() and then looking things up)? Obviously it's
better for the dict to use equality checks rather than identity checks
(otherwise, at the very least, you'd have to explicitly intern all
strings used as dict keys - that'd just be ridiculous), but with
objects that don't compare equal to themselves, what should be done?
I think Python's picked a quite reasonable approach.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On 2014-07-09 01:24, Chris Angelico wrote: On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase Okay, EOF is the canonical way to tell a program reading stdin that you're done. It just happens that EOF ^D on *nix-likes and ^Z on Win32. :-) -tkc I can't think of any Windows-native programs that ask for EOF. Only those which came from POSIX platforms do it. That said, though, Windows doesn't tend to encourage interactive command-line programs at all, so you may as well just follow the Unix convention. There was a time in life where I used copy con output.txt on a disturbingly frequent basis. Control+Z ended my file for me. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On Wed, Jul 9, 2014 at 1:46 AM, Tim Chase python.l...@tim.thechases.com wrote: On 2014-07-09 01:24, Chris Angelico wrote: On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase Okay, EOF is the canonical way to tell a program reading stdin that you're done. It just happens that EOF ^D on *nix-likes and ^Z on Win32. :-) -tkc I can't think of any Windows-native programs that ask for EOF. Only those which came from POSIX platforms do it. That said, though, Windows doesn't tend to encourage interactive command-line programs at all, so you may as well just follow the Unix convention. There was a time in life where I used copy con output.txt on a disturbingly frequent basis. Control+Z ended my file for me. Yes, and I've done that with a few programs (sort comes to mind; also Regina Rexx, because it lacked a true interactive interpreter), but not interactive ones. Those programs are filters, so obviously EOF is the way to signal, well, end of file. (Have you ever used COPY CON to create a binary file?) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError)
On 2014-07-09 01:49, Chris Angelico wrote: Have you ever used COPY CON to create a binary file? No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Chris Angelico ros...@gmail.com: Why *should* all NaNs be equal to each other? I appreciate why you can't say NaN is equal to NaN. However, shouldn't the very comparison attempt trigger an arithmetic exception? After all, so does a division by zero. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError)
On Wed, Jul 9, 2014 at 1:57 AM, Tim Chase python.l...@tim.thechases.com wrote: On 2014-07-09 01:49, Chris Angelico wrote: Have you ever used COPY CON to create a binary file? No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS) I never used a DOS version so old it had DEBUG.COM, but I used DEBUG.EXE extensively. It was, for years, the only means I had of building assembly language programs - no C compiler, no proper assembler, nothing. One of my greatest triumphs, at the time, was the development of an absolutely insane (even at the time I knew it was insane) system that let me build an assembly program with line labels in it; it would pipe commands into DEBUG and pipe the output back out, and drive DEBUG's mini-assembler. When it came to a label, it would look at what the prompt said would be the next address, and save it. When the label was used, it would patch in the actual address. And forward references were handled, too - it'd put in a placeholder, and then go and assemble over it afterward. (I'm not sure what happened if the placeholder resulted in the wrong size of jump command being assembled. It was a definite consideration, as conditional jumps had to be relative, but unconditional jumps could be relative (two-byte command) or absolute (three-byte command). Maybe it just always put in a distant target, and patched in a NOP if it didn't need the third byte, or something. I don't remember.) Sadly, there was a period when all my programming was either in BASIC or assembly, and even more sadly, I would write low-level code using DEBUG, save it into the format needed by BLOAD, and then CALL ABSOLUTE the routine from BASIC... in order to, for instance, access the mouse. Life got ever so much better when I moved to OS/2, and started using REXX for most of my work. (And then eventually got a C compiler, albeit a Windows one. Was years and years before I actually got a decent build system for OS/2.) There was a time when, just for the fun of it, I started memorizing a whole lot of 8086 opcodes in hex, just so I could COPY CON PROGRAM.COM and make something actually work. I don't think there was ever any purpose in it at all, but it was fun. I guess that's a purpose... some people play Tetris, some people have girlfriends/boyfriends, and some people learn to write machine code at COPY CON... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Wed, Jul 9, 2014 at 2:16 AM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: Why *should* all NaNs be equal to each other? I appreciate why you can't say NaN is equal to NaN. However, shouldn't the very comparison attempt trigger an arithmetic exception? After all, so does a division by zero. I'd say it would surprise people rather a lot if operations like dict insertion/lookup could trigger arithmetic exceptions. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ^D vs ^Z as EOF and DOS dinosaurs talking (was: open() and EOFError)
On 2014-07-08, Tim Chase python.l...@tim.thechases.com wrote: On 2014-07-09 01:49, Chris Angelico wrote: Have you ever used COPY CON to create a binary file? No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS) Both. -- Jan v/d Broek balgl...@xs4all.nl Geef je over, wy zyn Bassie en Adriaan, weerstand is nutteloos -- https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On 2014-07-09 01:24, Chris Angelico wrote: I can't think of any Windows-native programs that ask for EOF. Only those which came from POSIX platforms do it. That said, though, Windows doesn't tend to encourage interactive command-line programs at all, so you may as well just follow the Unix convention. And within the last 10 minutes doing some work on a Win32 box, I noticed that both the wmic console (standard since at least XP I believe) and Python use EOF to quit (both provide alternate methods of quitting, but EOF is fast easy). -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
On Wed, Jul 9, 2014 at 2:40 AM, Tim Chase python.l...@tim.thechases.com wrote: On 2014-07-09 01:24, Chris Angelico wrote: I can't think of any Windows-native programs that ask for EOF. Only those which came from POSIX platforms do it. That said, though, Windows doesn't tend to encourage interactive command-line programs at all, so you may as well just follow the Unix convention. And within the last 10 minutes doing some work on a Win32 box, I noticed that both the wmic console (standard since at least XP I believe) and Python use EOF to quit (both provide alternate methods of quitting, but EOF is fast easy). Python doesn't count, as it's cross-platform; lots of programs work the same way on all their platforms, and it doesn't say anything about the expectations of native Windows apps. But wmic, that's a better example. Counter-example: Command-line FTP on Windows doesn't react to Ctrl-Z, which annoys me somewhat when I move from one to another. (Not as much as it annoys me by not supporting passive mode, though. I generally have to turn to a web browser to do basic FTP downloads across a VM boundary, and for uploads, I either have to go fetch a better FTP client (like FileZilla), or - as I've often done - whip up a few lines of basic TCP socket file transfer, because I can do that at an interactive interpreter faster than most people can move files any other way.) hrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, 08 Jul 2014 16:53:47 +0200, Anders J. Munch wrote:
Most people don't need to deal with NaN's in Python at all, fortunately.
They just don't appear in normal computation, because the interpreter
raises an exception instead.
It happens in my work I come across them quite a lot. I'm writing
software that talks to embedded applications that can contain NaN values
for a variety of reasons - never-initialised storage, initialise-to-NaN,
hardware failures etc.
So when my software reads these values in binary, unpack them using the
struct module, and goes to work. And NaN's are no different from any
other value, it's something to store, compare, display etc.
And that worked fine in my Python 2.4 apps.
I think you're smoking something funny :-)
[steve@ando ~]$ python2.4
Python 2.4.3 (#1, Jan 9 2013, 06:49:54)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2
Type help, copyright, credits or license for more information.
py NAN = float('NAN')
py NAN == NAN
False
NANs compared unequal in Python 2.4.
[...]
Now, all this bothers me. Not that I had to do some work to get stuff
to work in an imperfect world. No, what bothers me is that this
behaviour was explicitly and deliberately put in for no good reason.
Oh, you've read the IEEE-754 standard, and that's what it says? We're
going to specify this behaviour for NANs just to annoy people perhaps?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Wed, Jul 9, 2014 at 3:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Now, all this bothers me. Not that I had to do some work to get stuff to work in an imperfect world. No, what bothers me is that this behaviour was explicitly and deliberately put in for no good reason. Oh, you've read the IEEE-754 standard, and that's what it says? We're going to specify this behaviour for NANs just to annoy people perhaps? You're confusing IEEE with Adobe. IEEE is pronounced Ai!, but it's Adobe that makes people scream that. http://www.theregister.co.uk/2009/04/30/xee_photoshop_psd_code_rant/ ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, Jul 8, 2014 at 9:53 AM, Anders J. Munch 2...@jmunch.dk wrote: Most people don't need to deal with NaN's in Python at all, fortunately. They just don't appear in normal computation, because the interpreter raises an exception instead. In addition to what others have written, I will add one thing. There are certainly situations where raising an exception is bad. Consider all the people in the scientific computing community doing fancy linear algebra sorts of things, often with missing data. They generally want NaN propagated and not have some long running calculation crash in the middle. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Chris Angelico ros...@gmail.com: I'd say it would surprise people rather a lot if operations like dict insertion/lookup could trigger arithmetic exceptions. :) That wouldn't trigger exceptions. Dict operations do an is test before an == test. In fact, you couldn't even use NaN as a dict key otherwise. Thus, dict operations never test NaN == NaN. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Skip Montanaro s...@pobox.com: In addition to what others have written, I will add one thing. There are certainly situations where raising an exception is bad. Consider all the people in the scientific computing community doing fancy linear algebra sorts of things, often with missing data. They generally want NaN propagated and not have some long running calculation crash in the middle. Do the scientific computers mind: 1 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: division by zero or would they prefer their fancy linear-algebraic computation to just forge on? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
import numpy a1 = numpy.ones(5) a1 array([ 1., 1., 1., 1., 1.]) a0 = numpy.zeros(5) a0 array([ 0., 0., 0., 0., 0.]) a1 / a0 __main__:1: RuntimeWarning: divide by zero encountered in true_divide array([ inf, inf, inf, inf, inf]) nans = numpy.array([float(nan)] * 5) nans array([ nan, nan, nan, nan, nan]) a1 / nans array([ nan, nan, nan, nan, nan]) a1 / a0 * nans array([ nan, nan, nan, nan, nan]) You get a runtime warning (this is in Python 2.7), but the division returns the appropriate value, in this case, infinity. So, yes, they forge on, and NaN taints things just about the way you'd expect. Skip On Tue, Jul 8, 2014 at 12:36 PM, Marko Rauhamaa ma...@pacujo.net wrote: Skip Montanaro s...@pobox.com: In addition to what others have written, I will add one thing. There are certainly situations where raising an exception is bad. Consider all the people in the scientific computing community doing fancy linear algebra sorts of things, often with missing data. They generally want NaN propagated and not have some long running calculation crash in the middle. Do the scientific computers mind: 1 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: division by zero or would they prefer their fancy linear-algebraic computation to just forge on? Marko -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Wed, Jul 9, 2014 at 3:31 AM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: I'd say it would surprise people rather a lot if operations like dict insertion/lookup could trigger arithmetic exceptions. :) That wouldn't trigger exceptions. Dict operations do an is test before an == test. In fact, you couldn't even use NaN as a dict key otherwise. Thus, dict operations never test NaN == NaN. Check out the example I posted early in this thread of a dict with three keys, all of them NaN. And note that hash(float(nan))==0. Now try looking up d[0]. Before it raises KeyError, it has to compare that 0 for equality with each of the nans, because it can't shortcut it based on the hash. In fact, I can prove it thus: class X: def __eq__(self, other): if self is other: print(Comparing against self - I am me!) return True print(Comparing against,other,-,id(other)) return False def __hash__(self): return 0 d[X()] Comparing against nan - 18777952 Comparing against nan - 19624864 Comparing against nan - 18776272 Traceback (most recent call last): File pyshell#20, line 1, in module d[X()] KeyError: __main__.X object at 0x016B40D0 Any lookup of anything with a hash of 0 will do this. 0 itself (as any type of number), another NaN, or anything at all. For the dict to work sanely, these comparisons have to work and be False. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Wed, Jul 9, 2014 at 3:54 AM, Chris Angelico ros...@gmail.com wrote: class X: def __eq__(self, other): if self is other: print(Comparing against self - I am me!) return True print(Comparing against,other,-,id(other)) return False def __hash__(self): return 0 d[X()] Comparing against nan - 18777952 Comparing against nan - 19624864 Comparing against nan - 18776272 Traceback (most recent call last): File pyshell#20, line 1, in module d[X()] KeyError: __main__.X object at 0x016B40D0 Better example: Subclass float, then it can actually *be* a nan. class NoisyFloat(float): def __eq__(self, other): print(Comparing,id(self),against,id(other)) return super().__eq__(other) def __hash__(self): return super().__hash__() d[NoisyFloat(nan)] Comparing 23777152 against 18777952 Comparing 23777152 against 19624864 Comparing 23777152 against 18776272 Traceback (most recent call last): File pyshell#35, line 1, in module d[NoisyFloat(nan)] KeyError: nan That's comparing nan==nan three types with four different nans. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On 07/08/2014 07:53 AM, Anders J. Munch wrote:
Most people don't need to deal with NaN's in Python at all,
fortunately. They just don't appear in normal computation, because the
interpreter raises an exception instead.
What exception? Apparently your claims about NaN in Python are all
wrong -- have you been using a custom interpreter?
Python 2.7.4 (default, Sep 26 2013, 03:20:26)
[GCC 4.7.3] on linux2
Type help, copyright, credits or license for more information.
float('inf') - float('inf')
nan
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, 08 Jul 2014 20:31:25 +0300, Marko Rauhamaa wrote:
Thus, dict operations never test NaN == NaN
You're assuming that there is only one NAN instance. That is not correct:
py a = float('nan')
py b = float('nan')
py a is b
False
py a in {b: None}
False
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, 08 Jul 2014 19:16:53 +0300, Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
Why *should* all NaNs be equal to each other?
I appreciate why you can't say NaN is equal to NaN. However, shouldn't
the very comparison attempt trigger an arithmetic exception?
No. Why should it? It's not an error to check whether two things are
equal.
After all, so does a division by zero.
Um, yes, and multiplying by zero isn't an error. In what way is x == y
related to x/0 ?
But having said that, sometimes it is useful to stop processing as soon
as you reach a NAN. For that, IEEE-754 defines two kinds of NANs, Quiet
NANs and Signalling NANs. Quiet NANs don't trigger a signal when you
perform operations on them. (By default -- I believe you can enable
signals if you wish.) Signalling NANs always trigger a signal, including
when you check them for equality:
py from decimal import Decimal as D
py a = D('nan')
py b = D('snan')
py 1 == a
False
py 1 == b
Traceback (most recent call last):
File stdin, line 1, in module
decimal.InvalidOperation: [class 'decimal.InvalidOperation']
But by default, NANs are quiet. The C99 standard doesn't support
signalling NANs, and Java actually prohibits them.
Aside: The influence of C and Java has crippled IEEE-754 support across
almost all languages and hardware. It's a crying shame the pernicious
influence those two languages have had.
http://grouper.ieee.org/groups/1788/email/pdfmPSi1DgZZf.pdf
Floating point is *hard*, and people who don't understand it insist on
telling those who do that you don't need that feature :-(
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Naming conventions for functions and methods
On 8 July 2014 15:59, pyt...@bdurham.com wrote: Looking for your opinions on how you name your functions and methods. Example: I have a function that hashes a file. I could name this function hash_file() or file_hash(). The 1st naming convention sounds more natural, the 2nd naming convention allows one to group related functions together by the object being acted on. PEP-8 doesn't appear to offer guidance in this area. Thoughts? Malcolm If you want to group related functions together, I would suggest putting them in a module, e.g. 'fileutils'. I'd still go for hashfile for the function name though. -- Arnaud -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Chris Angelico wrote:
Why *should* all NaNs be equal to each other? You said on the other
list that NaN==NaN was equivalent to (2+2)==(1+3), but that assumes
that NaN is a single thing.
I don't actually care if all NaN bitpatterns are in the same equivalence group
or if each bitpattern is its own equivalence group. I just want the ==
equivalence relation to be sound.
For hash keys, float object identity will successfully look them up:
Except you can't expect to rely on object identity in most interesting cases.
x = float('nan')
import struct
y = struct.unpack('f', struct.pack('f', x))[0]
d[x] = found
d[y]
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: nan
and also:
def f(): return float('inf')/float('inf')
f() == f()
False
f() is f()
False
But any time you compare floats for equality, you *already* have to
understand what you're doing (because of rounding and such), so I
don't see why the special case on NaN is significant, unless as
mentioned above, you want all NaNs to be equal, which doesn't make
sense.
Let me conjure up a simple example:
| class Monitor(Thread):
| def run(self):
| old = self.get_current_value()
| while not self.Terminated:
| new = self.get_current_value()
| if new != old:
| print(time.asctime(), changed to, new)
| old = new
| time.sleep(1)
This is a completely generic change detection algorithm, and not a
floating-point algorithm in any way: It will work on strings, lists, sets,
anything that get_current_value returns, including non-NaN floats. You don't
need to know anything about floating-point representation to write or use such
an algorithm, why should you? It works on tuples, sets, lists, serial port
handles, module objects, pretty much anything you can imagine -- except NaN floats.
regards, Anders
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Wed, Jul 9, 2014 at 4:29 AM, Anders J. Munch 2...@jmunch.dk wrote:
Chris Angelico wrote:
For hash keys, float object identity will successfully look them up:
Except you can't expect to rely on object identity in most interesting
cases.
x = float('nan')
import struct
y = struct.unpack('f', struct.pack('f', x))[0]
d[x] = found
d[y]
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: nan
and also:
def f(): return float('inf')/float('inf')
f() == f()
False
f() is f()
False
Neither of those examples is anything to do with object identity. In
the first case, you pack the value and recreate an equivalent of the
same type with the same value. In the second, you independently
construct two floats with the same value. Both times, you have
equivalence (both are NaN), but not identical objects.
Let me conjure up a simple example:
| class Monitor(Thread):
| def run(self):
| old = self.get_current_value()
| while not self.Terminated:
| new = self.get_current_value()
| if new != old:
| print(time.asctime(), changed to, new)
| old = new
| time.sleep(1)
This is a completely generic change detection algorithm, and not a
floating-point algorithm in any way: It will work on strings, lists, sets,
anything that get_current_value returns, including non-NaN floats. You don't
need to know anything about floating-point representation to write or use
such an algorithm, why should you? It works on tuples, sets, lists, serial
port handles, module objects, pretty much anything you can imagine -- except
NaN floats.
You also have to cope with objects that define __eq__ or __ne__. If
you know that you have a monitor like that, then you make sure that
the value is something comparable; there are plenty of reasons to have
to be careful there. (Consider, for instance, what happens if
get_current_value() returns a list. Mutating that list can change
whether or not it's equal to something else.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Ian Kelly wrote: As far as I know nothing changed between 2.4 and 2.7 in this regard. Python has always had NaN compare unequal to everything, per the standard. It might have been platform-specific in 2.4. Okay, here's your problem: there isn't just one binary representation for NaN. I'm fully aware of that. Whether NaN's are one equivalence class or several is not the issue. What matters is the integrity of the equivalence relation. Following the standard isn't a good reason itself? If a standard tells you to jump of a cliff... regards, Anders -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Steven D'Aprano wrote: Oh, you've read the IEEE-754 standard, and that's what it says? We're going to specify this behaviour for NANs just to annoy people perhaps? I was referring to the deliberate choice to enforce IEEE-754 rules in Python. There is no force of law that requires Python to do so. regards, Anders -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Ethan Furman skrev:
What exception? Apparently your claims about NaN in Python are all wrong --
have you been using a custom interpreter?
float('inf') - float('inf')
nan
If you deliberately try to manufacture NaN's, you can. I never said otherwise.
regards, Anders
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Den 14-07-08 19:23, Skip Montanaro skrev: In addition to what others have written, I will add one thing. There are certainly situations where raising an exception is bad. Consider all the people in the scientific computing community doing fancy linear algebra sorts of things, often with missing data. They generally want NaN propagated and not have some long running calculation crash in the middle. NaN!=NaN doesn't cause NaN's to propagate any more or any less. It simply causes a different branch of code to run, quite often the wrong one. regards, Anders -- https://mail.python.org/mailman/listinfo/python-list
Python top learning language
http://www.infoworld.com/d/application-development/python-bumps-java-top-learning-language-245774 -- https://mail.python.org/mailman/listinfo/python-list
Re: Loading modules from files through C++
On Wed, May 21, 2014 at 3:17 AM, Roland Plüss rol...@rptd.ch wrote:
The important part are the last two lines. An important module is
lacking the __builtins__ dictionary member so I had to add it.
Hopefully this works also in Py3 should I switch some time later. But I
guess it should seeing how simple the import now became.
An interesting omission, I'm a little surprised at that. But if your
switch to Py3 is a serious (or even half-serious) possibility, I
recommend tossing a quick comment against that line of code. Check to
see if you actually need it, and if you still do, see if there's a
change there. The module has been renamed (from __builtin__ to
builtins, although the global reference to it is still __builtins__),
so you may need to adjust something there, too. But mainly, see if you
can drop that line of code in Py3.
Furthermore I had to call the string runner with moduleDict both as
global and local dictionary. With that change the virtual script is
properly loaded and working as it should.
This part does make sense, though. Normally, module-level code runs
with the same locals and globals:
locals() is globals()
True
And that doesn't change in Py3, so I would expect that your C++ code
also won't change.
ChrisA
I changed now a couple of things and it looks like the segfault happens
somewhere inside PyErr_Print(). So I've programatically loaded a script
into a new module using load_module and a module created by hand. If now
in this script I've loaded an error is located the crash happens. The
situation thus looks like this. Let's say Script.py is my script. The
call chain would be something like this for example:
someNativeClass.cpp : someFunction()
Script.py : def run()
main.cpp
The error is due to a
if( ! PyArg_ParseTuple( args, , x1, y1, x2, y2 ) ){
return NULL;
}
Thus the PyErr_Print() would have to print in the stack trace two C++
class, one in the someNativeClass and one generated for the loaded
Script.py . It looks like Python 3 expects something from the C++
classes not written in the documentation.
What could a C++ class require to be working being included in a stack
trace like this?
--
Yours sincerely
Plüss Roland
Leader and Head Programmer
- Game: Epsylon ( http://www.indiedb.com/games/epsylon )
- Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
, http://dragengine.rptd.ch/wiki )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )
- As well as various Blender export scripts und game tools
signature.asc
Description: OpenPGP digital signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
I wrote: Steven D'Aprano wrote: Oh, you've read the IEEE-754 standard, and that's what it says? We're going to specify this behaviour for NANs just to annoy people perhaps? I was referring to the deliberate choice to enforce IEEE-754 rules in Python. There is no force of law that requires Python to do so. And just to be clear, I didn't mean python-dev did this to annoy people either. I just meant that the choice made is not supported by any use case, so there's no upside to outweigh the problems it creates. At least I've yet to hear any use case. So far I'm 0 beers in debt. regards, Anders -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On 07/08/2014 12:04 PM, Anders J. Munch wrote:
Ethan Furman skrev:
What exception? Apparently your claims about NaN in Python are all wrong --
have you been using a custom interpreter?
float('inf') - float('inf')
nan
If you deliberately try to manufacture NaN's, you can. I never said otherwise.
What you said is: They just don't appear in normal computation, because the
interpreter raises an exception instead.
I just ran a calculation that created a NaN, the same as 4 - 3 creates a 1, and
no exception was raised.
Do you have an example where one is?
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, Jul 8, 2014 at 1:16 PM, Ethan Furman et...@stoneleaf.us wrote: What you said is: They just don't appear in normal computation, because the interpreter raises an exception instead. I just ran a calculation that created a NaN, the same as 4 - 3 creates a 1, and no exception was raised. Do you have an example where one is? The math module functions raise exceptions instead of returning NaN. -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, Jul 8, 2014 at 12:54 PM, Anders J. Munch 2...@jmunch.dk wrote: Ian Kelly wrote: As far as I know nothing changed between 2.4 and 2.7 in this regard. Python has always had NaN compare unequal to everything, per the standard. It might have been platform-specific in 2.4. I doubt it, but okay, which platform? Okay, here's your problem: there isn't just one binary representation for NaN. I'm fully aware of that. Whether NaN's are one equivalence class or several is not the issue. What matters is the integrity of the equivalence relation. I have some bad news for you. This is on Python 2.7.6: from decimal import Decimal from fractions import Fraction Decimal(2) == 2 True 2 == Fraction(2) True Decimal(2) == Fraction(2) False I'm not sure exactly when this bug was fixed, but it works as expected in 3.4.0. Following the standard isn't a good reason itself? If a standard tells you to jump of a cliff... So I don't know of a good use case for nan != nan in Python (but really I'm not the one to ask), but I do know of use cases in other scenarios. On platforms that don't provide an isnan() function, the only convenient and efficient way to test for nan is by testing reflexivity: x != x. Following the standard means that any algorithm that uses this trick can (in theory) be implemented in Python without changes. -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On 07/08/2014 12:50 PM, Ian Kelly wrote: On Tue, Jul 8, 2014 at 1:16 PM, Ethan Furman et...@stoneleaf.us wrote: What you said is: They just don't appear in normal computation, because the interpreter raises an exception instead. I just ran a calculation that created a NaN, the same as 4 - 3 creates a 1, and no exception was raised. Do you have an example where one is? The math module functions raise exceptions instead of returning NaN. Ah, so if actual numbers go in, either actual numbers come out or an exception is raised -- good to know, and thanks for clarifying. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] == on object tests identity in 3.x
Steven D'Aprano wrote: - Dropping reflexivity preserves the useful property that NANs compare unequal to everything. Please present an example from real life where that turned out useful, and earn yourself a beer! I've only experienced examples to the contrary. - Keeping reflexivity for NANs would have implied some pretty nasty things, e.g. if log(-3) == log(-5), then -3 == -5. log(-3) Traceback (most recent call last): File stdin, line 1, in module ValueError: math domain error You were perhaps referring to the log functions in C and Fortran, not math.log? The tradeoffs are different in those languages, so choices the IEEE-754 committee made with C and Fortran in mind may be less relevant for Python. regards, Anders -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] == on object tests identity in 3.x
On Tue, Jul 8, 2014 at 2:10 PM, Anders J. Munch 2...@jmunch.dk wrote: Steven D'Aprano wrote: - Keeping reflexivity for NANs would have implied some pretty nasty things, e.g. if log(-3) == log(-5), then -3 == -5. log(-3) Traceback (most recent call last): File stdin, line 1, in module ValueError: math domain error You were perhaps referring to the log functions in C and Fortran, not math.log? The tradeoffs are different in those languages, so choices the IEEE-754 committee made with C and Fortran in mind may be less relevant for Python. import ctypes libm = ctypes.cdll.LoadLibrary(libm.so.6) log = libm.log log.argtypes = [ctypes.c_double] log.restype = ctypes.c_double log(-3) nan log(-5) nan log(-3) == log(-5) False -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On 07/08/2014 11:54 AM, Anders J. Munch wrote: If a standard tells you to jump of a cliff... because a bunch of tanks are chasing you down, there's water at the bottom, and not a helicopter in sight... well, jumping off the cliff could easily be your best chance. ;) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] == on object tests identity in 3.x
On Tue, Jul 8, 2014 at 3:53 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Tue, Jul 8, 2014 at 2:10 PM, Anders J. Munch 2...@jmunch.dk wrote: Steven D'Aprano wrote: - Keeping reflexivity for NANs would have implied some pretty nasty things, e.g. if log(-3) == log(-5), then -3 == -5. log(-3) Traceback (most recent call last): File stdin, line 1, in module ValueError: math domain error You were perhaps referring to the log functions in C and Fortran, not math.log? The tradeoffs are different in those languages, so choices the IEEE-754 committee made with C and Fortran in mind may be less relevant for Python. import ctypes libm = ctypes.cdll.LoadLibrary(libm.so.6) log = libm.log log.argtypes = [ctypes.c_double] log.restype = ctypes.c_double log(-3) nan log(-5) nan log(-3) == log(-5) False Also, numpy provides more control over floating-point error handling than straight Python does, and I think (but can't presently test) that numpy.log(-3) will return nan by default. -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, Jul 8, 2014 at 4:03 PM, Ethan Furman et...@stoneleaf.us wrote: On 07/08/2014 11:54 AM, Anders J. Munch wrote: If a standard tells you to jump of a cliff... because a bunch of tanks are chasing you down, there's water at the bottom, and not a helicopter in sight... well, jumping off the cliff could easily be your best chance. ;) Especially if you have a friend with a TARDIS. -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On 08/07/2014 23:07, Ian Kelly wrote: On Tue, Jul 8, 2014 at 4:03 PM, Ethan Furman et...@stoneleaf.us wrote: On 07/08/2014 11:54 AM, Anders J. Munch wrote: If a standard tells you to jump of a cliff... because a bunch of tanks are chasing you down, there's water at the bottom, and not a helicopter in sight... well, jumping off the cliff could easily be your best chance. ;) Especially if you have a friend with a TARDIS. This can lead to unforeseen circumstances though http://en.wikipedia.org/wiki/The_Flipside_of_Dominick_Hide -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PyPy-STM: first interesting release
On 07/08/2014 02:04 AM, Steven D'Aprano wrote: On Tue, 08 Jul 2014 09:48:08 +0100, Mark Lawrence wrote: A GIL-less Python? See http://morepypy.blogspot.co.uk/2014/07/pypy-stm-first-interesting- release.html Both Jython and IronPython are GIL-less, and have been forever. Yeah, but one requires Java, and the other .NET. :/ -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Naming conventions for functions and methods
pyt...@bdurham.com writes: Looking for your opinions on how you name your functions and methods. Example: I have a function that hashes a file. I could name this function hash_file() or file_hash(). I'd prefer just ‘hash’. The function name can be considered an action verb, with its arguments as the objects acted upon. -- \ “Nothing worth saying is inoffensive to everyone. Nothing worth | `\saying will fail to make you enemies. And nothing worth saying | _o__)will not produce a confrontation.” —Johann Hari, 2011 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, 08 Jul 2014 21:02:09 +0200, Anders J. Munch wrote: Steven D'Aprano wrote: Oh, you've read the IEEE-754 standard, and that's what it says? We're going to specify this behaviour for NANs just to annoy people perhaps? I was referring to the deliberate choice to enforce IEEE-754 rules in Python. There is no force of law that requires Python to do so. There's no force of law that requires Python to enforce reflexivity on values where reflexivity does not apply, any more than Python should enforce total order on values which aren't ordered (such as complex numbers, or sets). I'm sorry that you happened to (apparently) have a use-case where you simultaneously have to deal with NANs but not in a numeric context. But from the description of your problem, it seems to me that the obvious solution is not to deal with floats until as late as possible. That is, your current work-flow (if I have understood it correctly) is: * gather unpacked floats from some device, as ints * pack them into floats * process them in some way which requires reflexivity * (maybe) much later perform numeric calculations on them It seems to me that the trivial work-around is: * gather packed floats from some device, as ints * process them *as ints* in some way which requires reflexivity * unpack back into floats * (maybe) much later perform numeric calculations on them Although perhaps I don't understand your use-case. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, 08 Jul 2014 13:50:06 -0600, Ian Kelly wrote: The math module functions raise exceptions instead of returning NaN. That's not the only way that NANs can be constructed. In particular, the OP is collecting NANs from some other device. I don't know how it ends up with NANs, but it does, so he has to deal with them. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] == on object tests identity in 3.x
On Tue, 08 Jul 2014 16:05:45 -0600, Ian Kelly wrote: On Tue, Jul 8, 2014 at 3:53 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Tue, Jul 8, 2014 at 2:10 PM, Anders J. Munch 2...@jmunch.dk wrote: Steven D'Aprano wrote: - Keeping reflexivity for NANs would have implied some pretty nasty things, e.g. if log(-3) == log(-5), then -3 == -5. log(-3) Traceback (most recent call last): File stdin, line 1, in module ValueError: math domain error You were perhaps referring to the log functions in C and Fortran, not math.log? The tradeoffs are different in those languages, so choices the IEEE-754 committee made with C and Fortran in mind may be less relevant for Python. import ctypes libm = ctypes.cdll.LoadLibrary(libm.so.6) log = libm.log log.argtypes = [ctypes.c_double] log.restype = ctypes.c_double log(-3) nan log(-5) nan log(-3) == log(-5) False Also, numpy provides more control over floating-point error handling than straight Python does, and I think (but can't presently test) that numpy.log(-3) will return nan by default. Correct: py numpy.log(-3) nan py if numpy.log(-3) == numpy.log(-5): ... print -3 == -5 ... py -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On Tue, 08 Jul 2014 13:57:30 -0600, Ian Kelly wrote: Decimal(2) == Fraction(2) False I'm not sure exactly when this bug was fixed, but it works as expected in 3.4.0. It isn't a bug, it's a missing feature. The problem is that in Python 2.7, neither Decimal nor Fraction are aware of the other: py Decimal(2).__eq__(Fraction(2)) NotImplemented py Fraction(2).__eq__(Decimal(2)) NotImplemented The obvious, but wrong, solution is to coerce both into floats: py a = Decimal(2.01) py b = Fraction(2) - Fraction(1, 2)**100 py a 2 b # a and b are certainly not equal True py float(a) == float(b) True Some time by Python 3.3, Decimal appears to have become aware of how to compare exactly with Fraction. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: open() and EOFError
In article mailman.11636.1404834458.18130.python-l...@python.org, Tim Chase python.l...@tim.thechases.com wrote: On 2014-07-09 01:24, Chris Angelico wrote: On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase Okay, EOF is the canonical way to tell a program reading stdin that you're done. It just happens that EOF ^D on *nix-likes and ^Z on Win32. :-) -tkc I can't think of any Windows-native programs that ask for EOF. Only those which came from POSIX platforms do it. That said, though, Windows doesn't tend to encourage interactive command-line programs at all, so you may as well just follow the Unix convention. There was a time in life where I used copy con output.txt on a disturbingly frequent basis. Control+Z ended my file for me. -tkc I once knew a guy who linked /dev/tty.c to /dev/tty, then he could do cc /dev/tty.c and type a C program in to the compiler from the terminal. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python top learning language
On Tue, Jul 8, 2014 at 12:19 PM, candide c.cand...@laposte.net wrote: http://www.infoworld.com/d/application-development/python-bumps-java-top-learning-language-245774 As a sort of nano-celebration, here's a blast from Python's past (May, 1997): https://web.archive.org/web/19970501011626/http://www.python.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Steven D'Aprano st...@pearwood.info writes: On Tue, 08 Jul 2014 11:22:25 +1000, Ben Finney wrote: A group of (a particular amount of) U+0020 characters is visually indistinguishable from a U+0009 character, when the default semantics are applied to each. Hmmm. I'm not sure there actually *is* such a thing as default semantics for tabs. It was likely never standardised, but yes, default semantics are long established for the HT (Horizontal Tab) control code in a text stream URL:https://en.wikipedia.org/wiki/Tab_key#Tab_characters. The default semantics are that an HT (Horizontal Tabulation) control code is an instruction to introduce enough horizontal space such that the following character appears at the next multiple-of-8 column. These semantics assume a fixed character width, which is itself a default semantic of the display of computer text; variable-width is a deviation from the default. If you look at a tab character in a font I'm not talking about glyphs (for a control code, there isn't much sense talking about a default glyph), I'm talking about the default semantics of how they affect display. But if you look at it in a text editor, it will probably look like eight spaces, unless it looks like four, or some other number, and if you look at it in a word processor, it will probably look like a jump to the next tab stop command. Right. Programs that conform to the established default semantics for an HT (U+0009) code point will shift to the next tab stop to display the following character. Tab stops themselves are, in fixed-width character layout (which is itself the historical default), spaced apart by multiples of 8 character columns. I don't think any of those things count as default semantics. I hope my position is clearer. The point being, tabs are *control characters*, like newlines and carriage returns and form feeds, not regular characters like spaces and A or λ. Since indent is an *instruction* rather than a character, it is best handled with a control character. Right. And those control codes affect display of the text, and there are default semantics for those codes: what those control codes specifically mean. The HT code has the default display semantic of “display the following character at the next horizontal tab stop”. The solution is to use a smarter editor. The recipient's choice of editor program is not within the control of the author. Furthermore, it's expecting that the recipient will deviate from the default display semantics of the text as received. The author should write the text such that the default semantics are useful, and/or avoid text where the default semantics are undesirable or unreliably implemented. In this case: If the programmer doesn't like U+0009 resulting in text aligned at multiple-of-8 tab stops, or doesn't like the fact that recipients may have tab stops set differently, then I don't care what editor the author uses; they should avoid putting U+0009 into text. That said, a smarter text editor program *can* be a solution for “I don't like the default semantics *as displayed on my computer*”. If a programmer wants to deviate from the defaults, and can convince others on a rational and non-coercive basis to go along with their non-default preferences, they all have my blessing. If they want their preferences to override the default more broadly, they need a better argument than “it just looks better to me”. Isn't this why you recommend people use a programmer's editor rather than Notepad? I don't see how recommending a better editor for the *author* addresses how the *recipient*'s device renders the text. so no, that's not a reason why I recommend the author use a programmer's editor. True, but that's *only* because your editor chooses to follow the convention display a LINE FEED by starting a new line rather than by the convention display the (invisible or zero-width) glyph of the LINE FEED. If editors were to standardise on the convention display a HORIZONTAL TAB character as visibly distinct from a sequence of spaces (e.g. by shading the background a different colour, or overlying it with an arrow) then we would not be having this discussion. If things were different, they'd be different. I'm talking about default display semantics of the U+0009 code as they are. -- \ “I used to be an airline pilot. I got fired because I kept | `\ locking the keys in the plane. They caught me on an 80 foot | _o__)stepladder with a coathanger.” —Steven Wright | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
[OT] Grandma, is that you? [was Re: NaN comparisons - Call For Anecdotes]
On Wed, 09 Jul 2014 00:21:22 +0100, Mark Lawrence wrote: This can lead to unforeseen circumstances though http://en.wikipedia.org/wiki/The_Flipside_of_Dominick_Hide I prefer this one: http://en.wikipedia.org/wiki/Roswell_That_Ends_Well -- https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
On 7/8/2014 8:10 PM, Steven D'Aprano wrote:
There's no force of law that requires Python to enforce reflexivity on
values where reflexivity does not apply,
There are laws of logic that make the lack of reflexivity obnoxious when
putting objects in collections. Python evaded the problem, at least for
some builtins, by contradicting itself and treating nans as equal to
themselves in the context of collections.
In 2.x, 'in' was defined in terms of ==, but
nan=float('nan')
nl = [nan]
nan in nl
True
even though nan != the only member of nl.
In 3.x, 'in' was redefined to include 'is' as well as '=='.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: NaN comparisons - Call For Anecdotes
Ian Kelly wrote: well, jumping off the cliff could easily be your best chance. ;) Especially if you have a friend with a TARDIS. Or you're James Bond, in which case you ski off the cliff and then open your parachute. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: generic _ssl error
Robin Becker ro...@reportlab.com writes: I have the following from some production machines when trying to clone / pull etc etc using mercurial on ubuntu 10.04 hg clone https://myhost/myrepos abort: error: _ssl.c:480: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm I believe that _ssl.c must be the _ssl.so module which presumably is being used by the hg command. The system python which mercurial uses is Python 2.7.2 (default, Sep 20 2011, 16:38:53) Could this error be the result of upgrading the openssl to fix heartbleed and not upgrading the system python? The error message tells you that a message digest algorithm is being used (liklely by the remote site) which is not supported locally. There is a big chance that this means that locally something (related with ssl/message digests - i.e. likely OpenSSL) is too old. I would try to upgrade the OpenSSL installation -- and then see whether the problem goes away. -- https://mail.python.org/mailman/listinfo/python-list
[issue21270] unittest.mock.call object has inherited count method
Kushal Das added the comment: To start with I am overriding count and index method. Do you think this is enough? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21270 ___ ___ 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: IMO you must discuss the GMP license on the python-dev mailing list I think the maintenance implications of having another external dependency would also need discussion on python-dev. -- ___ 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
[issue21922] PyLong: use GMP
Mark Dickinson added the comment: Hmm. Looking back at my previous comments, I should explain my negativity a bit better. 1. Like Victor's issue 1814 work, this is great stuff, and very impressive. 2. I'm really not convinced that it belongs in the Python core. To expand on 2: we already have a simple, highly portable, battle-tested implementation of big integers that's reasonably efficient for normal uses and requires little day-to-day maintenance. We'd be replacing that with something that's a lot more complicated, less thoroughly tested, and *not* significantly more efficient in normal use-cases. Apart from the pain of the transition (and any refactor of this size is bound to involve some pain), I'm particularly worried about future headaches involved in maintaining the external GMP dependency: keeping up with bugfixes, managing the binary builds, etc. I anticipate that that would add quite of a lot of work for the core team in general and those building releases in particular. (And that's another reason that we should have a python-dev discussion, so that those involved in the release process get a chance to weigh in.) To offset that, there needs to be a clear *benefit* to making this change. A couple of specific questions for Hristo Venev: - What's the current status of GMP on Windows? IIUC, one of the motivations for the MPIR unfriendly fork of GMP was better Windows support. Does your patch already build cleanly on Windows? - Whom do you see this change benefiting? Those doing serious large-number stuff on Python (SAGE users, for example) are presumably already using gmpy2 or something similar. - Do you want to initiate the python-dev discussion, or leave that to someone else? [I'm deliberately steering clear of the licensing issues; it needs discussion, but IANAL and I have nothing useful to contribute here.] -- ___ 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
[issue15133] tkinter.BooleanVar.get() behavior and docstring disagree
Serhiy Storchaka added the comment: Here is a patch. 1) getboolean() and BooleanVar.get() now always return bool. Wrapping the result of getboolean() into bool() is not more needed. 2) getboolean() and BooleanVar.get() now works with Tcl_Obj. This makes Tkinter more robust against future Tcl/Tk changes. 3) An exception is raised if an argument to BooleanVar.set() couldn't be considered as boolean value. An argument is converted to canonized 0/1 values. This makes errors to be exposed earlier. Similar changes should be made for getint() and getdouble(). -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file35897/tkinter_getboolean.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15133 ___ ___ 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: Previous python-dev discussions: https://mail.python.org/pipermail/python-dev/2008-November/083315.html https://mail.python.org/pipermail/python-3000/2007-September/010718.html [Regarding the ancient mpz module, which used to be part of Python] https://mail.python.org/pipermail/python-dev/2001-December/018967.html -- ___ 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
[issue21772] platform.uname() not EINTR safe
Stefano Borini added the comment: You can't use subprocess. platform is used during build. subprocess needs select, but select is a compiled module and at that specific time in the build process is not compiled yet. -- nosy: +stefanoborini ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21772 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue21772] platform.uname() not EINTR safe
On 08.07.2014 11:40, Stefano Borini wrote: You can't use subprocess. platform is used during build. subprocess needs select, but select is a compiled module and at that specific time in the build process is not compiled yet. Good point :-) -- Marc-Andre Lemburg eGenix.com ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17153] tarfile extract fails when Unicode in pathname
Lars Gustäbel added the comment: IIRC, tarfile under 2.7 has never been explicitly unicode-safe, support for unicode objects is heterogeneous at best. The obvious work-around is to work exclusively with str objects. What we can't do is to decode the utf-8 pathname from the archive to a unicode object, because we have no way to detect an archive's encoding. We can either emit a warning if the user passes a unicode object to extract() or we implicitly encode the passed unicode object using TarFile.encoding, so that the os.path.join() succeeds. Unfortunately, I am not entirely sure if there was possibly a rationale behind the current behaviour of extract(). This needs more inspection. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17153 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21365] asyncio.Task reference misses the most important fact about it, related info spread around intros and example commentary instead
STINNER Victor added the comment: Hi, I pushed my change to add a new BaseEventLoop.create_task() method. For that, I also updated the documentation: http://hg.python.org/cpython/rev/66f06fbf8a2f I rewrote the documentation of the Task method, and more generally all places describing how to create a Task object. I changed the first sentence to Schedule the execution of a coroutine object to be the most explicit. The documentation will be readable online in a few hours: https://docs.python.org/dev/library/asyncio-task.html#task Thanks for your report. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21365 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17288] cannot jump from a return after setting f_lineno
Xavier de Gaye added the comment: Python 3.5 is still crashing with this test: $ python jump.py jump.py(7)module() - for i in gen(): (Pdb) break 3 Breakpoint 1 at jump.py:3 (Pdb) continue jump.py(3)gen() - yield i (Pdb) step --Return-- jump.py(3)gen()-0 - yield i (Pdb) jump 2 jump.py(2)gen()-0 - for i in range(1): (Pdb) continue Segmentation fault (core dumped) It is true that frame_setlineno() assumes incorrectly that f-f_stacktop is not NULL, but the reason of the crash or of the SystemError: unknown opcode is that PyEval_EvalFrameEx() expects on its invocation f-f_lasti to refer to the index of the last instruction executed and sets (and assumes this instruction does not have argument) 'next_instr' accordingly to the next byte, while by jumping to line 2 we set f-f_lasti to zero and 'SETUP_LOOP', the opcode at this index, has an argument. The attached patch is a slight improvement over the last one. -- type: behavior - crash versions: +Python 3.5 -Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file35898/default_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17288] cannot jump from a return after setting f_lineno
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21938] Py_XDECREF statement in gen_iternext()
New submission from Xavier de Gaye: The Py_XDECREF statement in gen_iternext() at Objects/genobject.c is not needed since val is NULL (may be optimized out by the compiler). Actually, the whole function could be written as: return gen_send_ex(gen, NULL, 0); -- components: Interpreter Core messages: 222556 nosy: xdegaye priority: normal severity: normal status: open title: Py_XDECREF statement in gen_iternext() type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21938 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21937] IDLE interactive window doesn't display unsaved-indicator
Changes by Saimadhav Heblikar saimadhavhebli...@gmail.com: -- nosy: +sahutd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21937 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1610654] cgi.py multipart/form-data
Hynek Schlawack added the comment: I would have long ago if I had any domain knowlege on this topic, but alas…. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21772] platform.uname() not EINTR safe
Stefano Borini added the comment: Wouldn't it make sense to use the same strategy used in the subprocess fix (that is, retry?). See http://hg.python.org/cpython/rev/6e664bcc958d/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21772 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19608] devguide needs pictures
Changes by Ezio Melotti ezio.melo...@gmail.com: -- resolution: - works for me stage: - resolved status: open - closed type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19608 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21927] BOM appears in stdin when using Powershell
Ezio Melotti added the comment: I would argue that adding the BOM is a Powershell issue, and I'm not sure Python should do anything about it. There are probably cases where people expects the BOM to be received by python, so stripping it is probably not an option. As for detecting, it should happen automatically only if sys.stdin.encoding is set to 'utf-8-bom', but, by default, Python 3 uses 'UTF-8'. -- nosy: +lemburg, loewis type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21927 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15759] make suspicious doesn't display instructions in case of failure
Ezio Melotti added the comment: Serhiy, your patch LGTM. Can you apply a similar fix for the linkcheck and doctest target and commit it? FWIW the patch produces a slightly different output (in addition to showing the missing message), but I don't think it's a problem: Without patch: ... build finished with problems, 8 warnings. make: *** [build] Error 1 With patch: ... build finished with problems, 8 warnings. make[1]: *** [build] Error 1 make[1]: Leaving directory `/home/wolf/dev/py/py3k/Doc' Suspicious check complete; ... make: *** [suspicious] Error 1 -- versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15759 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21939] IDLE - Test Percolator
New submission from Saimadhav Heblikar: Attached is a unittest for idlelib.Percolator. 2.7 version will be added once this is OK. -- components: IDLE files: test_percolator-34.diff keywords: patch messages: 222561 nosy: jesstess, sahutd, taleinat, terry.reedy priority: normal severity: normal status: open title: IDLE - Test Percolator versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35899/test_percolator-34.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21270] unittest.mock.call object has inherited count method
Michael Foord added the comment: Those are the only ones I think. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21270 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21940] IDLE - Test WidgetRedirector
New submission from Saimadhav Heblikar: Attached is unittest for idlelib.WidgetRedirector 2.7 version will be uploaded once this is OK. -- components: Extension Modules files: test-widgetredir-34.diff keywords: patch messages: 222563 nosy: jesstess, sahutd, taleinat, terry.reedy priority: normal severity: normal status: open title: IDLE - Test WidgetRedirector versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35900/test-widgetredir-34.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21940 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
