[issue44954] Bug in float.fromhex

2021-08-20 Thread Pedro Gimeno


Pedro Gimeno  added the comment:

> @Pedro Thanks again for the report! Just out of curiosity, how did you manage 
> to find this?

I'm writing a C strtod implementation and I was adding corner cases to the unit 
testing (now published here: 
https://codeberg.org/pgimeno/ACSL/src/branch/master/tests/test-strtod.c). 
Sometimes I get confused by whether to add one or subtract one to the exponent 
as digits are moved, and since I have an interactive Python shell always open 
as a calculator, I used it to make sure that the test I was writing had the 
correct exponent. But the result I got was not the one I expected, and upon 
verification, I soon became convinced that it was a bug, so I dug a bit more 
(at first I didn't notice it only happened if the leading zero was left out) 
and finally submitted the bug.

Thanks for the quick fix, by the way.

--
resolution: fixed -> 
status: closed -> open
type: behavior -> 
versions:  -Python 3.10, Python 3.11

___
Python tracker 
<https://bugs.python.org/issue44954>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44954] Bug in float.fromhex

2021-08-19 Thread Pedro Gimeno


New submission from Pedro Gimeno :

>>> float.fromhex('0x0.8p-1074')
0.0
>>> float.fromhex('0x.8p-1074')
5e-324

One of them is obviously wrong. It's the second one, because:
- The smallest denormal is 0x1p-1074
- Therefore, 0x0.8p-1074 is a tie for rounding purposes.
- The digit in the last place is even because the number is zero, and there is 
a tie, which implies rounding down.

--
components: Library (Lib)
messages: 399909
nosy: pgimeno
priority: normal
severity: normal
status: open
title: Bug in float.fromhex
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44954>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38800] Resume position for UTF-8 codec error handler not working

2019-11-14 Thread Pedro Gimeno


Pedro Gimeno  added the comment:

Python 3.5 from Debian stretch (oldstable). You're right, I can't reproduce it 
in 3.7 from Buster. Sorry for the bogus report.

--

___
Python tracker 
<https://bugs.python.org/issue38800>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38800] Resume position for UTF-8 codec error handler not working

2019-11-14 Thread Pedro Gimeno


Pedro Gimeno  added the comment:

I forgot the quotes in the assertion, it should have been "b'xz'".

--

___
Python tracker 
<https://bugs.python.org/issue38800>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38800] Resume position for UTF-8 codec error handler not working

2019-11-14 Thread Pedro Gimeno


New submission from Pedro Gimeno :

When implementing an error handler, it must return a tuple consisting of a 
substitution string and a position where to resume decoding. In the case of the 
UTF-8 codec, the resume position is ignored, and it always resumes immediately 
after the character that caused the error.

To reproduce, use this code:

import codecs
codecs.register_error('err', lambda err: (b'x', err.end + 1))
assert repr(u'\uDD00yz'.encode('utf8', errors='err')) == b'xz'

The above code fails the assertion because the result is b'xyz'.

It works OK for some other codecs. I have not tried to make an exhaustive list 
of which ones work and which ones don't, therefore this problem might apply to 
others.

--
messages: 356610
nosy: pgimeno
priority: normal
severity: normal
status: open
title: Resume position for UTF-8 codec error handler not working
type: behavior

___
Python tracker 
<https://bugs.python.org/issue38800>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2506] Add mechanism to disable optimizations

2014-06-22 Thread Pedro Gimeno

Pedro Gimeno added the comment:

I consider peephole optimization when no optimization was requested a bug.

Documentation for -O says it Turns on basic optimizations. Peephole 
optimization is a basic optimization, yet it is performed even when no basic 
optimizations were requested.

No need to add a switch. Just don't optimize if not requested.

--
nosy: +pgimeno

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2506
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com