[issue27721] distutils strtobool returns 0 and 1 rather than False and True

[Raymond Hettinger]

Raymond Hettinger added the comment:

Sorry Joseph, I concur that with Ned that we're best off leaving this alone 
(risk of breaking doctests with the changing repr, risk of fooling an overly 
specific type test, etc).  The code is not incorrect and does correspond with 
its docstring which claims 1 for true and 2 for false.

The sentiment is appreciated, but in general, the time to get APIs perfect is 
when it is initially released.  Afterwards, we really only want to make 
implementation improvements or API extensions until the API is flat-out broken 
or has major usability problems (even then, it always causes consternation to 
change the API).

--
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue27558] SystemError with bare `raise` in threading or multiprocessing

[Xiang Zhang]

Xiang Zhang added the comment:

Ping. Mind to merge?

--

___
Python tracker 

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

[issue27721] distutils strtobool returns 0 and 1 rather than False and True

[SilentGhost]

Changes by SilentGhost :


--
resolution: not a bug -> wont fix
stage: patch review -> resolved

___
Python tracker 

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

[issue27719] Misleading note about "args" attribute in "User-defined Exceptions" section of tutorial

[Raymond Hettinger]

Raymond Hettinger added the comment:

Thanks for noticing this.  It looks like this particular example is now 
pointless and should be removed.  The subsequent examples do a much better job 
of showing typical practices.

--
nosy: +rhettinger
Added file: http://bugs.python.org/file44075/exc_doc.diff

___
Python tracker 

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

[issue27719] Misleading note about "args" attribute in "User-defined Exceptions" section of tutorial

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: docs@python -> rhettinger

___
Python tracker 

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

[issue27558] SystemError with bare `raise` in threading or multiprocessing

[Raymond Hettinger]

Raymond Hettinger added the comment:

Davin, would you like to finish this one (NEWS and ACKS entries) and get it 
committed?

--
assignee:  -> davin
nosy: +rhettinger

___
Python tracker 

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

[issue10721] Remove HTTP 0.9 server support

[Raymond Hettinger]

Raymond Hettinger added the comment:

There is so very little code in support of HTTP/0.9 that I don't think we get 
any benefit from removing it.  So why bother with the churn?  It is cleaner to 
just leave it place.

--
nosy: +rhettinger

___
Python tracker 

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

[issue27574] Faster parsing keyword arguments

[Raymond Hettinger]

Raymond Hettinger added the comment:

Normally, LGTM is an almost useless comment, but the patch does in fact look 
good to me.  I like how compact and straight-forward the changes are to the 
individual parsing calls.

--
nosy: +rhettinger

___
Python tracker 

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

[issue27720] decimal.Context.to_eng_string wrong docstring

[Antti Haapala]

Antti Haapala added the comment:

Raymond: your doc patch is not quite right. Decimal('123e1') is converted to 
Decimal('1.23e3') internally already; so that str(d) will print 1.23e3, 
scientific notation of that number is '1.23e3' and engineering notation is 
'1.23e3', thus not a good example. A better example would be  Also, the 
engineering notation is a string, not a Decimal instance.

Also, now that I test it, the whole `to_eng_string` seems to be utterly broken, 
same applies to "to_sci_string". They do not print in scientific notation if 
the exponent in the original number was 0:

decimal.Decimal('123456789101214161820222426.0e0').to_eng_string()

And all operations with decimal will now generate numbers with exponent of 0 if 
it is within their precision, so no engineering notation is ever printed, duh.

--

___
Python tracker 

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

[issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data

[Rolf Krahl]

Rolf Krahl added the comment:

Martin,

> _is_textIO(): I’m sorry but I still prefer the TextIOBase check over
> read(0). Each option has a disadvantage, but with TextIOBase, the
> disadvantage only affects text files, not byte files.

Ok, this is a valid argument.

> Maybe another option is to stick with the current checking of the
> “mode” attribute, or are its failings significant for chunked
> encoding?  It seems to me that the most important use cases would be
> reading bytes from a pipe file, custom bytes file object reader,
> generator, etc, but not a text file without a “mode” attribute.

No, this is not significant for chunked encoding.  As I said, I am happy to 
accept any method.

But I would say, it's a fairly save bet that any file-like that has the mode 
attribute is in fact derived from the base classes in the io module.  If this 
assumption holds, then the TextIOBase check will always work in all cases where 
the mode attribute check would.  The inverse is not true.  So I'll use the 
TextIOBase check, hope you agree.

> Checking Content-Length and Transfer-Encoding: I would prefer to
> remove this, unless there is a “good” reason to keep them. I want to
> understand why the three specific checks were added, and what made
> them more special than other potential checks (e.g. the format of
> the Content-Length value, or that the resulting body matches it). If
> the reason is something like “it is too easy for the caller to
> accidentally trigger the problem”, then there may be another way to
> fix it. Or maybe it is a mitigation for a security problem? But at
> the moment, it just seems to me like code being too smart for its
> own good.

Ok, I'll drop them.

> I mentioned a few possible bugs with parsing Transfer-Encoding at
> .
> The format of the Transfer-Encoding value is specified at
>  and
> . In Issue 23498, I
> identified some parts of Python that parse header values like this,
> although it looks like http.cookiejar.split_header_words() may be
> the only one usable for Transfer-Encoding.

I admit, I didn't read all comments on Demian's versions of the patch.  Since 
I'll drop the checks, I guess, these problems are gone now.

> Some of the header field validation was included in Demian’s first
> patch, raising HTTPEncodingError. But I don’t know why he included
> it. Maybe it was more appropriate then; it looks like that patch
> took a different approach than the current encode_chunked=True
> mechanism.

I don't think this is in the current versions of the patch any more.

--

___
Python tracker 

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

[issue27725] Use Py_SIZE(x) instead of x->ob_size

[Raymond Hettinger]

Raymond Hettinger added the comment:

I'm not clear on how non-use of the macro is causing your observed failures or 
whether that is due to a compiler bug.  That said, I don't see any downside to 
using Py_SIZE everywhere it is applicable.

--

___
Python tracker 

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

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

[Antti Haapala]

Antti Haapala added the comment:

Indeed engineering notation is now utterly broken, the engineering notation is 
not printed for pretty much _any *engineering* numbers at all_ in 3.6. 
Engineering numbers mean numbers that could be met in an *engineering* context, 
not cosmological!

--
nosy: +ztane

___
Python tracker 

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

[issue27720] decimal.Context.to_eng_string wrong docstring

[Stefan Krah]

Stefan Krah added the comment:

@Antti The behavior follows this standard:

http://speleotrove.com/decimal/decarith.html


Nothing we can do about it even if we wanted to.

--

___
Python tracker 

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

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

[Stefan Krah]

Stefan Krah added the comment:

@Antti Please think before you write and stop making unfounded allegations.

--

___
Python tracker 

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

[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization

[Nofar Schnider]

Nofar Schnider added the comment:

On it!

--
nosy: +Nofar Schnider

___
Python tracker 

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

[issue27725] Use Py_SIZE(x) instead of x->ob_size

[REIX Tony]

REIX Tony added the comment:

Hi Raymond

I've got several email exchanges with the IBM XLC expert. From his own study of 
my issue, his conclusion is that this kind of Python v2 coding is not 
ANSI-aliasing safe. It seems that there is a standard that requires C code to 
NOT do some kinds of coding so that any C compiler optimizer can do its best.

The issue was not there with XLC v12.1.0.14 and -O2.
It appeared with XLC v13.1.3.2 and -O2 since XLC v13 optimizer is more 
agressive.

About GCC, I've not experimented yet with it for now (will do later today I 
hope), but the impact should be the same according to the optimizer level and 
improvements.

Here is what IBMer Steven said:

"I found the problem.
It is not a problem with the compiler, but a problem with the source 
code/option set.
It is an ansi aliasing violation. I'll try to provide as much detail as I can 
to explain it.

At line 2512 of Objects/longobject.c, we have the following code:

if (sign < 0)
z->ob_size = -(z->ob_size);
return long_normalize(z);

Note that we use z->ob_size to access size, and the type of z is "PyLongObject 
*".
This value is loaded in long_normalization.
After we inline this function call, the compiler moves the load done in 
long_normalization above the if statement (past the store that writes to it), 
which is why we ends up with the wrong sign.

Now the question is why does the compiler think that this is legal ?

In long_normalize, the size is obtained using a macro Py_SIZE(v) (line 47).
This macro expands to:

(((PyVarObject*)(v))->ob_size)

Notice that the pointer is cast to something of type PyVarObject*.
PyVarObject and PyLongObject are not compatible types, and, because ansi 
aliasing is assumed, the compiler believes they do not reference the same 
memory. Therefore it is safe to move.

A simple solution is to use "-qalias=noansi" when compiling. That will work, 
but could also hurt performance.

The other solution is to use either Py_SIZE all of the time to access the 
memory or never.
Do not mix and match. This will require some code changes.
I'll leave it to you to figure out how to handle it, but my guess is that 
Py_SIZE is supposed to always be used.
The comments in "object.h" lines 11-17 include this phrase "they must be 
accessed through special macros and functions only."

--

___
Python tracker 

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

[issue27735] 'module' object has no attribute 'SIGALRM' - singal module

[Ram Vallury]

New submission from Ram Vallury:

'module' object has no attribute 'SIGALRM'

SIGALRM is not identified in windows, python 2.7.
There is no explicit mention of this in documentation as well.

===
$ python
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:32:19) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> def handler(signum, frame):
... print 'Signal handler called with signal', signum
... raise IOError("Couldn't open device!")
...
>>> signal.signal(signal.SIGALRM, handler)
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'SIGALRM'
>>>


--
components: Windows
messages: 272420
nosy: paul.moore, rvallury, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 'module' object has no attribute 'SIGALRM' - singal module
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue27725] Use Py_SIZE(x) instead of x->ob_size

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
nosy: +loewis, tim.peters

___
Python tracker 

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

[issue27725] Use Py_SIZE(x) instead of x->ob_size

[Stefan Krah]

Stefan Krah added the comment:

In 2.7 we use -fno-strict-aliasing and -fwrapv for gcc. I think it is probably 
required to use the equivalent options for xlc.

These are examples of things that have been cleaned up in 3.x. 2.7 actually 
relies on these options.

--

___
Python tracker 

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

[issue12345] Add math.tau

[Nofar Schnider]

Nofar Schnider added the comment:

I agree with Raymond.
In my opinion, it doesn't seem like there is a need to add such a constant.
I know many of my previous and current colleagues would not use it (why should 
them if they can just write "2 * math.pi" ?)
It seems that the efforts to spread the word that Pi is wrong and Tau is right 
haven't "bear fruits". For now I don't think we should make such a strong stand 
in adding it.
If we do add new constants they should be of calculations that are harder and 
might ruin the code's visibility.
 
https://www.explainxkcd.com/wiki/images/0/08/pi_vs_tau.png

--
nosy: +Nofar Schnider

___
Python tracker 

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

[issue27736] repeated Py_Initialize/PyRun_SimpleString/Py_Finalize segfaults

[Simon McVittie]

New submission from Simon McVittie:

dbus-python has a regression test for 
https://bugs.freedesktop.org/show_bug.cgi?id=23831 which repeatedly initializes 
the interpreter, imports dbus and finalizes the interpreter. This test passes 
in Python up to 3.5, but is failing under Python 3.6 nightly builds on 
Travis-CI, and in Python 3.6.0a3 (package version 3.6.0~a3-1) on Debian.

I've been able to reproduce the crash without anything specific to dbus with 
this C code:

#include 

#include 

int main(void)
{
int i;

puts("1..1");

for (i = 0; i < 100; ++i) {
Py_Initialize();
if (PyRun_SimpleString("\n") != 0) {
puts("not ok 1 - there was an exception");
return 1;
}
Py_Finalize();
}

puts("ok 1 - was able to loop 100 times");

return 0;
}

It appears the crash is reliably in the 10th repeat:

Program received signal SIGSEGV, Segmentation fault.
0x7783a4bb in type_dealloc (type=0x77d8ad80 )
at ../Objects/typeobject.c:3032
3032../Objects/typeobject.c: No such file or directory.
(gdb) bt
#0  0x7783a4bb in type_dealloc (type=0x77d8ad80 )
at ../Objects/typeobject.c:3032
#1  0x77817a1b in insertdict (value=, hash=, 
key=, mp=) at ../Objects/dictobject.c:806
#2  PyDict_SetItem (
op=op@entry={'open': None, 'O_DIRECT': None, 'chdir': None, 'O_ACCMODE': 
None, '__package__': None, 'WCOREDUMP': None, 'setgroups': None, 'O_CREAT': 
None, 'O_CLOEXEC': None, 'chown': None, 'sched_getscheduler': None, 
'RTLD_NODELETE': None, 'terminal_size': None, 'EX_IOERR': None, 
'sched_setaffinity': None, 'XATTR_SIZE_MAX': None, 'fstat': None, 
'sched_rr_get_interval': None, 'O_LARGEFILE': None, 'times_result': None, 
'get_inheritable': None, 'WIFEXITED': None, 'ST_NODEV': None, 'forkpty': None, 
'ctermid': None, 'O_RSYNC': None, 'SCHED_FIFO': None, 'stat': None, 'replace': 
None, 'EX_NOINPUT': None, 'WUNTRACED': None, 'set_blocking': None, 
'_have_functions': None, 'unsetenv': None, 'setresgid': None, 'fchown': None, 
'getgrouplist': None, 'openpty': None, 'lockf': None, 'chroot': None, 'readv': 
None, 'EX_NOHOST': None, 'error': None, 'WEXITSTATUS': None, 'WIFSIGNALED': 
None, 'WNOHANG': None, 'POSIX_FADV_WILLNEED': None, 'SEEK_HOLE': None, 'dup': 
None, 'POSIX_FADV_NOREUSE': None, 'ki
 ll': None, 'statvfs_result': None, 'WIFCON...(truncated), 
key='DirEntry', value=value@entry=None) at ../Objects/dictobject.c:1228
#3  0x7782659c in _PyModule_ClearDict (
d={'open': None, 'O_DIRECT': None, 'chdir': None, 'O_ACCMODE': None, 
'__package__': None, 'WCOREDUMP': None, 'setgroups': None, 'O_CREAT': None, 
'O_CLOEXEC': None, 'chown': None, 'sched_getscheduler': None, 'RTLD_NODELETE': 
None, 'terminal_size': None, 'EX_IOERR': None, 'sched_setaffinity': None, 
'XATTR_SIZE_MAX': None, 'fstat': None, 'sched_rr_get_interval': None, 
'O_LARGEFILE': None, 'times_result': None, 'get_inheritable': None, 
'WIFEXITED': None, 'ST_NODEV': None, 'forkpty': None, 'ctermid': None, 
'O_RSYNC': None, 'SCHED_FIFO': None, 'stat': None, 'replace': None, 
'EX_NOINPUT': None, 'WUNTRACED': None, 'set_blocking': None, '_have_functions': 
None, 'unsetenv': None, 'setresgid': None, 'fchown': None, 'getgrouplist': 
None, 'openpty': None, 'lockf': None, 'chroot': None, 'readv': None, 
'EX_NOHOST': None, 'error': None, 'WEXITSTATUS': None, 'WIFSIGNALED': None, 
'WNOHANG': None, 'POSIX_FADV_WILLNEED': None, 'SEEK_HOLE': None, 'dup': None, 
'POSIX_FADV_NOREUSE': None, 'kill': None,
  'statvfs_result': None, 'WIFCON...(truncated))
at ../Objects/moduleobject.c:593
#4  0x7782672e in _PyModule_Clear (m=m@entry=)
at ../Objects/moduleobject.c:544
#5  0x778d5874 in PyImport_Cleanup () at ../Python/import.c:452
#6  0x778e3a38 in Py_FinalizeEx () at ../Python/pylifecycle.c:588
#7  0x00400795 in main () at 
/home/smcv/src/dbus-python/test/import-repeatedly.c:19
(gdb) frame 7
#7  0x00400795 in main () at 
/home/smcv/src/dbus-python/test/import-repeatedly.c:19
19  Py_Finalize();
(gdb) p i
$1 = 10

--
components: Interpreter Core
messages: 272423
nosy: smcv
priority: normal
severity: normal
status: open
title: repeated Py_Initialize/PyRun_SimpleString/Py_Finalize segfaults
type: crash
versions: Python 3.6

___
Python tracker 

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

[issue27736] repeated Py_Initialize/PyRun_SimpleString/Py_Finalize segfaults

[Simon McVittie]

Simon McVittie added the comment:

This might be a duplicate of https://bugs.python.org/issue24853 but there 
wasn't enough detail on that bug for me to be sure.

--

___
Python tracker 

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

[issue24853] Py_Finalize doesn't clean up PyImport_Inittab

[Simon McVittie]

Simon McVittie added the comment:

http://bugs.python.org/issue27736 might be related, or even a duplicate of this.

--
nosy: +smcv

___
Python tracker 

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

[issue27735] 'module' object has no attribute 'SIGALRM' - singal module

[Ronald Oussoren]

Ronald Oussoren added the comment:

The documentation for the "SIG*" constants says:

"""
Note that not all systems define the same set of signal names; only those names 
defined by the system are defined by this module.
"""

--
nosy: +ronaldoussoren

___
Python tracker 

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

[issue27729] Provide a better error message when the file path is too long on Windows

[Eryk Sun]

Eryk Sun added the comment:

The NT runtime API RtlDosPathNameToRelativeNtPathName_U_WithStatus returns an 
informative error code, STATUS_NAME_TOO_LONG (0xC106). This gets translated 
to the less information but still useful Windows code ERROR_PATH_NOT_FOUND 
(0x0003). The CRT error table reduces this to ENOENT, so it's not readily 
distinguishable from ERROR_FILE_NOT_FOUND (0x0002).

The associated Windows error is still available via GetLastError when wopen 
returns:

ucrtbase!wopen+0x22:
7ffb`222b5702 c3  ret
0:000> ?? @$teb->LastErrorValue
unsigned long 3

Currently io.FileIO calls PyErr_SetFromErrnoWithFilenameObjects. It could check 
for ERROR_PATH_NOT_FOUND when errno is ENOENT. In this case it could use a 
custom error message such as "No such path or path exceeds the maximum allowed 
length".

--
nosy: +eryksun

___
Python tracker 

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

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

[Antti Haapala]

Antti Haapala added the comment:

Ok, after reading the "spec" it seems that the engineering exponent is indeed 
printed for positive exponents *if* the precision of the number is less than 
the digits of the exponent, which I didn't realize that I should be testing. 

However the *precision* of decimals is meaningless anyhow. Add a very precisely 
measured '0e0' to any number and the sum also has exponent of 0, and is thus 
never displayed in exponential notation.

--

___
Python tracker 

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

[issue27725] Use Py_SIZE(x) instead of x->ob_size

[REIX Tony]

REIX Tony added the comment:

Thanks a lot Stefan, that should completely explain my issues.

-fno-strict-aliasing -fwrapv for gcc

So, that means that you would get better performance if you applied on Python 
v2.7 what Python v3.5 did about Py_SIZE(x) .
However, there are probably other places where the aliasing issue still appears 
in v2.7 .

Hummm I'll use -qalias=noansi with XLC and see what happens.

--

___
Python tracker 

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

[issue27720] decimal.Context.to_eng_string wrong docstring

[Antti Haapala]

Antti Haapala added the comment:

@Stefan after reading the bad standard I agree that it follows the standard, as 
unfortunate as it is.

However, that part is then also wrong in Raymond's documentation patch. It 
should be something like: the exponent is adjusted to a multiple of 3 if *any* 
exponent is to be shown, and exponent is shown only if the exponent is larger 
than there are significant figures in the number, or if it is less than or 
equal to -6, or something alike.

Or perhaps it should say "This is not the notation you are looking for."

--

___
Python tracker 

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

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

[Stefan Krah]

Stefan Krah added the comment:

On Thu, Aug 11, 2016 at 09:17:10AM +, Antti Haapala wrote:
> However the *precision* of decimals is meaningless anyhow. Add a very 
> precisely measured '0e0' to any number and the sum also has exponent of 0, 
> and is thus never displayed in exponential notation.

It is not meaningless and actually one of the most important features of 
decimal:

>>> x = Decimal("3.6")
>>> y = Decimal("0.00") # number "measured" with ridiculous 
>>> precision
>>> x.to_eng_string()
'3.6'
>>> (x + y).to_eng_string()
'3.60'

>>> x = Decimal("3.6")
>>> y = Decimal("0e-7") # perhaps more realistic
>>> (x + y).to_eng_string()
'3.600'

If you have confidence in your measurement, you have to let decimal know
by actually spelling it out.

--

___
Python tracker 

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

[issue27725] Use Py_SIZE(x) instead of x->ob_size

[Stefan Krah]

Stefan Krah added the comment:

On Thu, Aug 11, 2016 at 09:29:44AM +, REIX Tony wrote:
> -fno-strict-aliasing -fwrapv for gcc
> 
> So, that means that you would get better performance if you applied on Python 
> v2.7 what Python v3.5 did about Py_SIZE(x) .
> However, there are probably other places where the aliasing issue still 
> appears in v2.7 .

I doubt that you'll see any measurable performance difference. The main
inefficiencies in Python aren't that low-level: They are in the interpreter
loop.

> Hummm I'll use -qalias=noansi with XLC and see what happens.

Yes, and also use -fwrapv or similar.  Otherwise you might get other issues
that are hard to track down.

--

___
Python tracker 

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

[issue27720] decimal.Context.to_eng_string wrong docstring

[Stefan Krah]

Stefan Krah added the comment:

> after reading the bad standard ...

Make sure not to buy a Power 6 processor and not to use IEEE 754-2008, because 
that's essentially what you'll get.

IEEE doesn't specify engineering notation though.

--

___
Python tracker 

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

[issue27506] make bytes/bytearray delete a keyword argument

[Martin Panter]

Martin Panter added the comment:

Serhiy, you assigned this to yourself. What do you think of my patch?

--

___
Python tracker 

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

[issue26578] Bad BaseHTTPRequestHandler response when using HTTP/0.9

[Martin Panter]

Changes by Martin Panter :


--
dependencies: +Remove HTTP 0.9 server support

___
Python tracker 

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

[issue10721] Remove HTTP 0.9 server support

[Martin Panter]

Martin Panter added the comment:

There are a few small benefits from removing it, but I am not too fussed if we 
decide to leave it.

* If we keep it, should we fix it so that it doesn’t deadlock? Otherwise, we 
carry around buggy and untested code that claims to be a HTTP 0.9 server but 
isn’t. Keeping it as it is doesn’t feel “clean” to me.

* Easy way to resolve bug reports like Issue 26578.

* Potentially slightly easier to maintain the rest of the code in the future.

If we do keep it, I would like to add comments clarifying that it does not 
implement the real HTTP 0.9 protocol.

--

___
Python tracker 

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

[issue27558] SystemError with bare `raise` in threading or multiprocessing

[Berker Peksag]

Berker Peksag added the comment:

Raymond, please stop hijacking issues. This doesn't have anything to do with 
multiprocessing and there are already four core developers in the nosy list. If 
you really want to assign it to someone else, please at least wait for a month 
or ask if they have time to commit the patch first. Unless I'm missing 
something, this doesn't look like a release blocker to me and definitely 
doesn't look like some 6 years old ancient issue (the first message was posted 
three weeks ago) so there is no urgency here.

--

___
Python tracker 

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

[issue16764] Make zlib accept keyword-arguments

[Martin Panter]

Martin Panter added the comment:

Xiang’s patch looks okay from a correctness point of view

--

___
Python tracker 

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

[issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data

[Rolf Krahl]

Rolf Krahl added the comment:

Ok, here comes the next version of the patch.  I made the changes discussed in 
the last post and addressed the review comments.  Looks like we are converging 
towards a final version.

--
Added file: http://bugs.python.org/file44076/issue12319_11.patch

___
Python tracker 

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

[issue27364] Deprecate invalid unicode escape sequences

[Martin Panter]

Martin Panter added the comment:

I am trying out your patch at the moment. There are plenty of test suite 
failures; I ran the test suite with approximately the following:

./python -bWerror -m test -Wr -j0 -u network -x 
test_{mailbox,shelve,faulthandler,multiprocessing_main_handling,venv,warnings}

Importing modules sometimes fails or generates the warning, but this goes away 
if the file is not out of date. E.g. run “touch Lib/test/test_codecs.py”, and 
then make sure you next import that module with -Wall or -Werror enabled.

374 tests OK.
10 tests failed:
test___all__ test_ast test_codecs test_doctest test_fstring
test_idle test_strlit test_trace test_unicode
test_zipimport_support

I started pasting some of the failures here, but gave up as more and more 
failed. Let me know if you want the full details.

==
ERROR: test_coverage (test.test_trace.TestCoverage)
--
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_trace.py", line 312, 
in test_coverage
self._coverage(tracer)
  File "/media/disk/home/proj/python/cpython/Lib/test/test_trace.py", line 307, 
in _coverage
r.write_results(show_missing=True, summary=True, coverdir=TESTFN)
  File "/media/disk/home/proj/python/cpython/Lib/trace.py", line 284, in 
write_results
lnotab = _find_executable_linenos(filename)
  File "/media/disk/home/proj/python/cpython/Lib/trace.py", line 403, in 
_find_executable_linenos
code = compile(prog, filename, "exec")
DeprecationWarning: invalid escape sequence 'w'
**
File "/media/disk/home/proj/python/cpython/Lib/test/test_doctest.py", line 288, 
in test.test_doctest.test_DocTest
Failed example:
docstring = '''
>>> print(12)
12

Non-example text.

>>> print('another\example')
another
example
'''
Exception raised:
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/doctest.py", line 1330, in 
__run
compileflags, 1), test.globs)
DeprecationWarning: invalid escape sequence 'e'
**
[Many subsequent NameError exceptions from test_doctest]
**
File "/tmp/tmphzbypj98/test_zip.zip/test_zipped_doctest.py", line 288, in 
test_zipped_doctest.test_DocTest
Failed example:
docstring = '''
>>> print(12)
12

Non-example text.

>>> print('another\example')
another
example
'''
Exception raised:
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/doctest.py", line 1330, in 
__run
compileflags, 1), test.globs)
DeprecationWarning: invalid escape sequence 'e'
**
[More failures]

==
FAIL: test_all (test.test___all__.AllTest)
--
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test___all__.py", line 
105, in test_all
self.check_all(modname)
  File "/media/disk/home/proj/python/cpython/Lib/test/test___all__.py", line 
28, in check_all
raise FailedImport(modname)
  File "/media/disk/home/proj/python/cpython/Lib/contextlib.py", line 89, in 
__exit__
next(self.gen)
  File "/media/disk/home/proj/python/cpython/Lib/test/support/__init__.py", 
line 1130, in _filterwarnings
raise AssertionError("unhandled warning %s" % reraise[0])
AssertionError: unhandled warning {message : DeprecationWarning("invalid escape 
sequence '('",), category : 'DeprecationWarning', filename : 
'/media/disk/home/proj/python/cpython/Lib/importlib/_bootstrap.py', lineno : 
222, line : None}

==
ERROR: test_escape_order (test.test_fstring.TestCase) (str='f\'{"a"\\!r}\'')
--
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_fstring.py", line 
20, in assertAllRaise
eval(str)
DeprecationWarning: invalid escape sequence '!'

==
ERROR: test_escape (test.test_codecs.EscapeDecodeTest)
--
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_codecs.py", line 
1218, in test_escape
decode(b"\\" + b)
OverflowError: character argument not in range(0x11)

==
ERROR: test_escape_decode (test.test_codecs.Un

[issue27502] Python -m Module Vulnerable to Buffer Over Flow.

[Stefan Krah]

Stefan Krah added the comment:

Your "buffer overflow" png shows the regular "414 request-uri too large" 
traceback.

A traceback is not a crash (I wonder if we need an faq for this).

--
nosy: +skrah
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue27364] Deprecate invalid unicode escape sequences

[Emanuel Barry]

Emanuel Barry added the comment:

Hmm, that's odd, I recall some of the failures from testing, and thought I 
fixed them. Some of these are brand new, though, so thanks! I'll run and fix 
the tests (and modules as well); should likely have a patch by the weekend :)

--

___
Python tracker 

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

[issue12319] [http.client] HTTPConnection.request not support "chunked" Transfer-Encoding to send data

[Martin Panter]

Martin Panter added the comment:

I am pretty happy with the latest patch. I left one comment. I will try to give 
it a more thorough review and actually test it out at some point, but I don’t 
anticipate any major problems.

--

___
Python tracker 

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

[issue15495] enable type truncation warnings for gcc builds

[Martin Panter]

Martin Panter added the comment:

Issue 23545 has a patch with some comments from me about adding other warnings 
via “autoconf foo”, so you could copy from that if you want.

The few warnings that I glanced at do not look troublesome. But maybe it is 
worth working around them to see other warnings; I dunno. Adding explicit casts 
can sometimes hide other bugs. Anyway, here is a random selection of some 
warnings:

Modules/sha256module.c:198:44: warning: conversion to ‘SHA_INT32 {aka unsigned 
int}’ from ‘long unsigned int’ may alter its value [-Wconversion]
 RND(S[0],S[1],S[2],S[3],S[4],S[5],S[6],S[7],48,0x19a4c116);
^
Modules/sha256module.c:145:11: note: in definition of macro ‘RND’
  t0 = h + Sigma1(e) + Ch(e, f, g) + ki + W[i];   \
   ^
Modules/resource.c:19:60: warning: conversion to ‘double’ from ‘__suseconds_t 
{aka long int}’ may alter its value [-Wconversion]
 #define doubletime(TV) ((double)(TV).tv_sec + (TV).tv_usec * 0.01)
^
./Include/tupleobject.h:62:75: note: in definition of macro ‘PyTuple_SET_ITEM’
 #define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i] = v)
   ^
Modules/resource.c:82:5: note: in expansion of macro ‘PyStructSequence_SET_ITEM’
 PyStructSequence_SET_ITEM(result, 0,
 ^
Modules/resource.c:83:40: note: in expansion of macro ‘doubletime’
 PyFloat_FromDouble(doubletime(ru.ru_utime)));
^~
Modules/cjkcodecs/cjkcodecs.h:155:27: warning: conversion to ‘unsigned char’ 
from ‘int’ may alter its value [-Wconversion]
 do { ((*outbuf)[1]) = (c); } while (0)
   ^
Modules/cjkcodecs/_codecs_kr.c:58:13: note: in expansion of macro ‘OUTBYTE2’
 OUTBYTE2((code & 0xFF) | 0x80);
 ^~~~
Modules/_ctypes/cfield.c:439:15: warning: conversion to ‘short int’ from ‘int’ 
may alter its value [-Wconversion]
 v >>= (sizeof(v)*8 - NUM_BITS(size));   \
   ^
Modules/_ctypes/cfield.c:594:5: note: in expansion of macro ‘GET_BITFIELD’
 GET_BITFIELD(val, size);
 ^~~~

--
nosy: +martin.panter

___
Python tracker 

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

[issue23545] Turn on extra warnings on GCC

[Martin Panter]

Martin Panter added the comment:

The proposed options add exactly one warning for me (ignoring warnings from 
libffi). How would you work around this:

./Include/pymem.h:136:18: warning: comparison is always false due to limited 
range of data type [-Wtype-limits]
   ( ((size_t)(n) > PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
  ^
/media/disk/home/proj/python/cpython/Modules/_ssl.c:4435:22: note: in expansion 
of macro ‘PyMem_New’
 _ssl_locks = PyMem_New(PyThread_type_lock, _ssl_locks_count);
  ^

--

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[R. David Murray]

R. David Murray added the comment:

Are you executing this once and worrying about the data structures that are not 
deallocated on finalize?  If so, see issue 228040 for background.  If you are 
executing it in a loop and seeing a continuing leak, then that we will want to 
address.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue27735] 'module' object has no attribute 'SIGALRM' - singal module

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue27730] Update shutil to work with max file path length on Windows

[Steve Dower]

Steve Dower added the comment:

I thought I'd tested GetFullPathNameW and seen the limit kick in at 260, but if 
that's not actually the case (across all platforms we support) then yes, let's 
use that.

When I reread the documentation yesterday it didn't guarantee the result would 
include the prefix, whereas GetFinalPathByHandle does. Again, if the 
documentation is incorrect here, then we should use the simpler function.

The fact that I described the normalization process inadequately shows why we 
really need to be careful trying to emulate it.

--

___
Python tracker 

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

[issue27737] email.header.Header.encode() crashes with IndexError on spaces only value

[SilentGhost]

Changes by SilentGhost :


--
nosy: +barry, r.david.murray
stage:  -> needs patch
type:  -> behavior
versions:  -Python 3.2, Python 3.3

___
Python tracker 

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

[issue27737] email.header.Header.encode() crashes with IndexError on spaces only value

[Tim Graham]

New submission from Tim Graham:

Python 2.7:
>>> from email.header import Header
>>> Header(' ').encode()
''

Python 3.2+ (I didn't check older versions of Python 3):
>>> Header(' ').encode()
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/tim/code/cpython/Lib/email/header.py", line 391, in encode
value = formatter._str(linesep)
  File "/home/tim/code/cpython/Lib/email/header.py", line 427, in _str
self.newline()
  File "/home/tim/code/cpython/Lib/email/header.py", line 439, in newline
self._lines[-1] += str(self._current_line)
IndexError: list index out of range

(Originally reported at https://code.djangoproject.com/ticket/27051)

--
components: Library (Lib)
files: whitespace-header-test.diff
keywords: patch
messages: 272447
nosy: Tim.Graham
priority: normal
severity: normal
status: open
title: email.header.Header.encode() crashes with IndexError on spaces only value
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44077/whitespace-header-test.diff

___
Python tracker 

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

[issue24773] Implement PEP 495 (Local Time Disambiguation)

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> Any news on the remaining failures for year 2037?

Yes, the problem was tracked to a bug [1] in zic.  If the buildbots get regular 
updates, the problem will go away with the next tzdata release.  Meanwhile, 
I'll try to figure out a way to suppress the error.

[1]: 
https://github.com/eggert/tz/commit/081c50f30308b589e7e296f485135d03cf046cb1

--

___
Python tracker 

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

[issue24773] Implement PEP 495 (Local Time Disambiguation)

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> Can the size of the tests be reduced, [...]?

Yes, the long test walks the zoneinfo tree and runs on every tzfile including 
the aliases.  I am going to change that to parsing the zone.tab file for the 
list of zone names.  This should shorten the time at least 2x.

--

___
Python tracker 

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

[issue27734] Memory leaks at Python35-32

[Zachary Ware]

Zachary Ware added the comment:

Please don't remove yourself from the nosy list, we need your input to figure 
out exactly what may need to be fixed.

--
nosy: +Филипп Пономарев

___
Python tracker 

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

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt added the comment:

Had some flooding (leaking pipes, rather values) issues to fix. Will 
look at this asap.

On 04-Aug-16 10:58, Martin Panter wrote:
> Martin Panter added the comment:
>
> Okay, so to be clear, I am assuming XLC supports all of the following fields, 
> and uses unsigned bit fields by default:
>
> struct UNSIGNED_BITS {
>  unsigned int AU: 1;
>  int A: 1; /* Equivalent to unsigned int */
>  signed int AS: 1;
>  unsigned short MU: 1;
>  short M: 1; /* Equivalent to unsigned short; triggers warning */
> };
>
> and that it cannot compile the following:
>
> struct SIGNED_BITS {
>  signed short MS: 1; /* Not supported */
> };
>
> Attached is what I think a patch to resolve this would look like. However it 
> needs a line in Modules/_ctypes/_ctypes_test.c completed to detect the 
> compiler:
>
> #ifndef /* Something to identify XLC */
>
> Can you figure out a way to test for XLC (but not GCC, which the AIX buildbot 
> uses), and then try my patch out? Hopefully you see no more compiler 
> warnings, test_ints() should now pass, and test_shorts() should be skipped.
>
> --
> keywords: +patch
> Added file: http://bugs.python.org/file44005/disable-signed-short.patch
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue24773] Implement PEP 495 (Local Time Disambiguation)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 05120447f2c6 by Alexander Belopolsky in branch 'default':
Issue #24773: Fix and speed-up ZoneInfoCompleteTest.
https://hg.python.org/cpython/rev/05120447f2c6

--

___
Python tracker 

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

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

[Michael Felt]

Michael Felt added the comment:

On 02-Aug-16 15:34, Martin Panter wrote:
> Martin Panter added the comment:
>
> For 2.7, adding the automatic RTLD_MEMBER mode does not seem like a bug fix 
> to me. Currently, I understand this code could load two separate libraries:
>
> file = CDLL("libcrypto.a(libcrypto.so.1.0.0)")
Noone (in their right mind, imho) would install, or extract the archive 
member libcrypto.so.1.0.0and then rename it 
/usr/lib/libcrypto.a(libcrypto.so.1.0.0)

FYI - I did test this case, and as a file, without 0x00040 (aka 
RLTD_MEMBER) or'd into the mode.
> member = CDLL("libcrypto.a(libcrypto.so.1.0.0)", DEFAULT_MODE | 0x0004)
>
> With your proposed change, the first line will do the same as the second 
> line, and Python will no longer provide a way to load a file named like in 
> the first operation. Maybe this is okay for the next version of Python 3 
> (because it is only breaking a rare corner case), but my view is it is not 
> worth changing 2.7.
Right now it is broken in AIX - it is impossible to use the native 
archive(member) support. Direct loading of .so files, if I recall 
correctly, was to provide linux affinity (remember the L in AIX 5L).

I believe python2 has some years to go, and basically, you ask anyone 
using python on AIX to go through all kinds of loops. This hurts python 
acceptance on AIX - too much work to get it working and keep it working.

I have been providing AIX support for over 20 years - NEVER have I seen 
anyone name a shared library libxxx.a(libxxx.so). What I have seen is 
that people extract archive members from a .a archive into the same 
directory - but when the archive gets updated most forget to extract the 
members again.

In yet another case I have seen a case where they copied everything to a 
new directory and do a chroot() to get the .so files they want - because 
it is impossible to load from a .a file.

Yes, when I first started back in February and March: a) knew next to 
nothing about python; b) was trying to solve it in ways I would like it 
be (mainly more flexible aka smarter re: the argument to find_library().

However, I do believe what I have here does what is done for other 
platforms (e.g., darwin needs a different name ending, just not a 
different mode to go with it) - will "fix" all "performance" related 
issues for AIX re: calling ldconfig (which is only available in 
extremely rare situations - again I have never seen it - because, by 
default, even gcc is using AIX ld, not GNU ld)

I hope saying "please" helps. Without it, the AIX implementation is 
non-existant. The linux code is called for AIX because that is the last 
else: block, not because the code is specific to "posix".

so - PLEASE - pretty please!

Michael

p.s. And I shall look at the mercurial pages - and I hope have it working.
>
> --
> nosy: +martin.panter
> title: ctypes and AIX - also for 2.7.X (and later) -> ctypes library loading 
> and AIX - also for 2.7.X (and later)
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue21018] [patch] added missing documentation about escaping characters for configparser

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue27738] odd behavior in creating list of lambda expressions

[Emanuel Barry]

Emanuel Barry added the comment:

This is due to the fact that Python evaluates the variable 'n' when the 
function is called, not when it is created. As such, the variable holds the 
latest value for all functions, and they exhibit identical behaviour.

Workaround:

...
f = lambda x, n=n: sin(n*x)
...

And this should work as you expect. More information is available at 
https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result

--
nosy: +ebarry
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7

___
Python tracker 

___
___
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

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue27738] odd behavior in creating list of lambda expressions

[John Sahr]

New submission from John Sahr:

The following produces unexpected behavior.
I think that it should produce a list of six different lambda expressions,
but after creation, all six lambda expressions produce the same output.
It's possible that I'm missing something about Python.

# begin example ###
from math import *

mm = []

for n in range(6):
f = lambda x: sin(n*x)
print f, f(1.0)
mm.append(f)

print '***'

for m in mm:
print m, m(1.0)
## end example 

--
messages: 272454
nosy: John Sahr
priority: normal
severity: normal
status: open
title: odd behavior in creating list of lambda expressions
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue12345] Add math.tau

[Guido van Rossum]

Guido van Rossum added the comment:

It's okay if Python occasionally shows its lighter side in unexpected places. 
Think of the delight of future (junior) high schoolers who discover that Python 
participates in the tau debate. :-)

Also, I think this video by Vi Hart should be linked to from the docs for this 
constant: https://www.youtube.com/watch?v=jG7vhMMXagQ

--

___
Python tracker 

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

[issue27720] decimal.Context.to_eng_string wrong docstring

[Evelyn Mitchell]

Evelyn Mitchell added the comment:

Thank you Raymond for a detailed patch update. 

I will mention that matlab does not support this conversion [1]. R doesn't 
support engineering notation, either.

It may be that this conversion isn't expected to be part of the standard 
library, and people are more likely to write their own. [2]

The rationale for engineering notation is that it corresponds to SI units of 
measure.

[1] https://www.mathworks.com/matlabcentral/newsreader/view_thread/22843
[2] 
http://stackoverflow.com/questions/8262302/python-fixed-exponent-in-scientific-notation

--

___
Python tracker 

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

[issue27725] Use Py_SIZE(x) instead of x->ob_size

[REIX Tony]

REIX Tony added the comment:

With XLC v13 -O2, using -qalias=noansi for building Objects/longobject.o only 
and not for all the other .o files did fix the 10 more failed tests I see with 
-O2 compared to -O0 (7-8 failed tests).
So, ANSI-aliasing in Objects/longobject.c is the issue.

About -fwrapv , I have to find an equivalent for XLC.

I've given a first try with GCC 4.8.4 . I've got about 44 failed tests compared 
to 7-8 with XLC. To be improved.

--

___
Python tracker 

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

[issue27739] add math.sign/signum

[Ankur Dedania]

New submission from Ankur Dedania:

Add a new function to the math module sign/signum 
https://en.wikipedia.org/wiki/Sign_function

--
messages: 272459
nosy: AnkurDedania
priority: normal
severity: normal
status: open
title: add math.sign/signum
type: enhancement
versions: Python 3.6

___
Python tracker 

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

[issue27739] add math.sign/signum

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See math.copysign().

https://docs.python.org/3/library/math.html#math.copysign

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue27739] add math.sign/signum

[Ankur Dedania]

Ankur Dedania added the comment:

sign/signum isn't the same as copysign, and doesn't support complex numbers

--

___
Python tracker 

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

[issue27739] add math.sign/signum

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

sgn(x) is the same as copysign(1.0, x).

The math module doesn't support complex numbers and shouldn't.

--

___
Python tracker 

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

[issue27719] Misleading note about "args" attribute in "User-defined Exceptions" section of tutorial

[Ben Hoyt]

Ben Hoyt added the comment:

Removing that whole example sounds good to me, thanks.

--

___
Python tracker 

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

[issue27739] add math.sign/signum

[Steven D'Aprano]

Steven D'Aprano added the comment:

If this is added, should this signum function be the two value version that 
returns 1 for zero, or the three value version that returns 0? Should it 
distinguish between signed zeroes +0.0 and -0.0? What should it do for NANs 
(raise, return a NAN, copy the sign bit from the NAN)?

The argument for adding this will be slightly stronger if other languages have 
this, and especially if it is part of the standard C maths library.

In any case, there's only a few more days until the 3.6 feature freeze, so 
unless you have an implementation and tests ready to go, the earliest it could 
be added will be 3.7.

Serhiy: if this gets added, then it would make sense to add cmath.signum to 
handle complex numbers.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue12345] Add math.tau

[Vedran Čačić]

Vedran Čačić added the comment:

Guido once again shows he is not a mathematicians (honestly, most of the 
"arguments" for tau are plain nonsense), but he is a fantastic popularizer. I 
(and most of the other professional mathematicians) will love Python a tiny bit 
less, but a horde of people will love it more, and it's a fine tradeoff. :-)

--
nosy: +veky

___
Python tracker 

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

[issue27739] add math.sign/signum

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

copysign() is part of the standard C maths library (that is why it was added to 
the math module).

sgn/sign/signum was used in old languages that didn't have copysign() (Basic, 
Pascal, etc).

--

___
Python tracker 

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

[issue12345] Add math.tau

[Tim Peters]

Tim Peters added the comment:

For those insisting that tau is somehow unnatural, just consider that the 
volume of a sphere with radius r is 2*tau/3*r**3 - the formula using pi instead 
is just plain impossible to remember ;-)

--

___
Python tracker 

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

[issue12345] Add math.tau

[Evelyn Mitchell]

Changes by Evelyn Mitchell :


--
nosy:  -Evelyn Mitchell

___
Python tracker 

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

[issue27740] Fix doc of Py_CompileStringExFlags

[Xiang Zhang]

New submission from Xiang Zhang:

I think the doc of Py_CompileStringExFlags has two flaws:

1. Py_CompileStringExFlags should be replaced by Py_CompileStringObject from 
the context. Py_CompileStringExFlags in the context is meaningless.

2. *filename* is a byte string that should be decoded but not decoded from. It 
is ... = decode(filename) but not filename = decode(...).

--
assignee: docs@python
components: Documentation
files: Py_CompileStringExFlags_doc.patch
keywords: patch
messages: 272468
nosy: docs@python, xiang.zhang
priority: normal
severity: normal
status: open
title: Fix doc of Py_CompileStringExFlags
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44078/Py_CompileStringExFlags_doc.patch

___
Python tracker 

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

[issue12345] Add math.tau

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le 11/08/2016 20:07, Tim Peters a écrit :
> 
> For those insisting that tau is somehow unnatural, just consider
> that the volume of a sphere with radius r is 2*tau/3*r**3 - the formula using
> pi instead is just plain impossible to remember ;-)

Thank you, I'm totally convinced now :-)

--

___
Python tracker 

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

[issue12345] Add math.tau

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

In general, the volume, in n-dimensional Euclidean space, of the unit n-ball, 
is given by

V_n = pi**(n/2) / gamma(n/2+1)

or

V_n = (tau/2)**(n/2) / gamma(n/2+1)

--

___
Python tracker 

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

[issue12345] Add math.tau

[Aaron Meurer]

Changes by Aaron Meurer :


--
nosy: +Aaron.Meurer

___
Python tracker 

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

[issue27539] negative Fraction ** negative int not normalized

[Vedran Čačić]

Vedran Čačić added the comment:

Here is the code for the patch:

84c84
< def __new__(cls, numerator=0, denominator=None, _normalize=True):
---
> def __new__(cls, numerator=0, denominator=None, *, _normalize=True):
459,466c459,466
< if power >= 0:
< return Fraction(a._numerator ** power,
< a._denominator ** power,
< _normalize=False)
< else:
< return Fraction(a._denominator ** -power,
< a._numerator ** -power,
< _normalize=False)
---
> num = a._numerator
> den = a._denominator
> if power < 0:
> num, den, power = den, num, -power
> if den < 0:
> num = -num
> den = -den
> return Fraction(num ** power, den ** power, _normalize=False)

I tried to add the test to test_fractions.py, but unfortunately unittest 
reports 3 unrelated failures due to mismatch in error messages (why does it 
check exact messages of exceptions anyway?). But it should just be adding

self.assertTypedEquals(F(-1, 2), F(-2) ** -1)

after line 408.

_Please_, can this go in before 15th?

--

___
Python tracker 

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

[issue12345] Add math.tau

[Antoine Pitrou]

Antoine Pitrou added the comment:

The patch needs a documentation update, by the way.

--

___
Python tracker 

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

[issue12345] Add math.tau

[Aaron Meurer]

Aaron Meurer added the comment:

If this is implemented, it would be (as far as I can tell) the only thing in 
the math module that isn't also implemented in any of the standard external 
math libraries. None of numpy, scipy, sympy, or mpmath implement tau (if I'm 
missing one that others think is equally important to the ecosystem, let me 
know).

--

___
Python tracker 

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

[issue11566] hypot define in pyconfig.h clashes with g++'s cmath

[Kay Hayen]

Kay Hayen added the comment:

This also affects Python2.7.12 on Windows with latest MinGW. I think something 
similar needs to be added for GCC version check:

/* VS 2010 and above already defines hypot as _hypot */
#if _MSC_VER < 1600
#define hypot _hypot
#endif

Not sure which gcc version first had that, but 6.1 definitely does.

Yours,
Kay

--
nosy: +Kay.Hayen

___
Python tracker 

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

[issue27741] datetime.datetime.strptime functionality description incorrect

[Nicholas Colclasure]

New submission from Nicholas Colclasure:

The datetime.datetime.strptime documentation states that it is equivalent to 
datetime(*(time.strptime(date_string, format)[0:6])), but the time.struct_time 
returned by time.strptime does not include microseconds, implying that 
datetime's strptime would also not include microseconds, but testing of the 
functions shows that it does include them.

Removing the false statement of equivalence would be enough to remove this bug 
from the documentation.

--
assignee: docs@python
components: Documentation
messages: 272474
nosy: Valectar, docs@python
priority: normal
severity: normal
status: open
title: datetime.datetime.strptime functionality description incorrect
type: behavior
versions: Python 3.5

___
Python tracker 

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

[issue12345] Add math.tau

[Aaron Meurer]

Aaron Meurer added the comment:

I also wonder, if math will be gaining constants that no one uses like tau, if 
it will also gain constants that people actually do use (currently math just 
has pi, e, inf, and nan). [i for i in dir(numpy) if isinstance(getattr(numpy, 
i), float)] reveals euler_gamma as one example. 
https://docs.scipy.org/doc/scipy/reference/constants.html lists a bunch more. 

And if we're adding derived constants, why not loge2, another derived 
constants, used way more often than tau?

In case you can't tell, I'm opposed to adding tau, although fwiw I do think it 
would be nice to add some of the other constants I mentioned above like 
euler_gamma to math, and in general, I support adding more stuff to math (but 
only generally useful stuff, obviously; there's no need to port all of 
scipy.special, for instance).

As an aside, a technical note on the patch: for consistency, it should also be 
added to the cmath library (pardon me if I misread the patch and that's already 
happening).

--

___
Python tracker 

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

[issue27739] add math.sign/signum

[R. David Murray]

R. David Murray added the comment:

This has been previously discussed and rejected, in issue 829370.

--
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> math.signum(int)

___
Python tracker 

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

[issue12345] Add math.tau

[Stefan Krah]

Stefan Krah added the comment:

Aaron, I may be wrong, but I understood this to be something like:

>>> from __future__ import barry_as_FLUFL
>>> 3 <> 10
True


I *do* hope sympy supports that! :-)

--
nosy: +skrah

___
Python tracker 

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

[issue27128] Add _PyObject_FastCall()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Do you suggest to not add these 2 new functions?

Yes, I suggest to not add them. The API for calling is already too large. 
Internally we can directly use _PyObject_FastCall(), and third party code 
should get benefit from optimized PyObject_CallFunctionObjArgs().

> > Can existing function PyObject_Call() be optimized to achieve a
> > comparable benefit?
> Sorry, I don't understand. This function requires a tuple. The whole
> purpose of my patch is to avoid temporary tuples.

Sorry, I meant PyObject_CallFunctionObjArgs() and like.

> Keyword arguments are optional. Having support for them cost nothing when
> they are not used.

My point is that if keyword arguments are used, this is not a fast call, and 
should use old calling protocol. The overhead of creating a tuple for args is 
dwarfen by the overhead of creating a dict for kwargs and parsing it.

> I really want to have a "pystack" API. In this patch, the new file looks
> useless, but in the full patch there are many functions including a few
> complex functions. I prefer to add the file now and complete it later.

But for now there is no a "pystack" API. What do you want to add? Can it be 
added with prefixes PyDict_, PyArg_ or PyEval_? On other side, other code can 
get a benefit from using _PyTuple_FromArray().

Here is alternative simplified patch.

1) _PyStack_AsTuple() is renamed to _PyTuple_FromArray() (-2 new files).
2) Optimized PyObject_CallFunctionObjArgs(), PyObject_CallMethodObjArgs() and 
_PyObject_CallMethodIdObjArgs().
3) Removed PyObject_CallNoArg() and PyObject_CallArg1(). Invocations are 
replaced by PyObject_CallFunctionObjArgs().
4) Removed support of keyword arguments in _PyObject_FastCall() (saved about 
20 lines and few runtime checks in _PyCFunction_FastCall).
5) Reverted changes in Objects/descrobject.c. They added a regression in 
namedtuple attributes access.

--
Added file: http://bugs.python.org/file44079/fast_call_alt.patch

___
Python tracker 

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

[issue16764] Make zlib accept keyword-arguments

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Xiang Zhang, could you please provide results of benchmarking zlib.decompress 
and decompressobj.decompress in simplest case with and without the patch? 
PyArg_ParseTupleAndKeywords can be slower than PyArg_ParseTuple even for 
positional arguments, and we should know how much.

--

___
Python tracker 

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

[issue23545] Turn on extra warnings on GCC

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Just add -Wno-type-limits.

--

___
Python tracker 

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

[issue27506] make bytes/bytearray delete a keyword argument

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

PyArg_ParseTupleAndKeywords can be slower than PyArg_ParseTuple even for 
positional arguments. We need benchmarking results (especially after committing 
a patch for issue27574).

What is the purpose of adding support of the delete argument as keyword 
arguments? It looks to me, that the only purpose is allowing to specify the 
delete argument without specifying the table argument. There are two 
alternative ways to achieve this: make translate() accepting some special value 
(e.g. None) as the default value for the first argument:

b'hello'.translate(None, b'l')

or make translate() accepting the delete argument as keyword argument:

b'hello'.translate(delete=b'l')

The patch does both things, but only one is needed. If add the support of the 
delete argument as keyword argument, I would prefer to not add the support of 
None as the first argument, but would specify its default value as 
bytes(range(256)):

table: object(c_default="NULL") = bytes(range(256))
/
delete as deletechars: object(c_default="NULL") = b''

I don't know why optional group was used here, the function could be 
implemented without it.

--

___
Python tracker 

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

[issue12345] Add math.tau

[Emanuel Barry]

Emanuel Barry added the comment:

I think that whether or not something is trivial doesn't really correlate to 
whether or not it has its place in the language. After all, `math.pi` is 
3.1416, and most people using pi will not worry about more than 4 decimal 
digits. Those who do are presumably using something better than floating-point 
arithmetic to begin with ;)

For yet another colour to paint this tiny bikeshed, maybe we could put new 
constants in something like `math.constants`, with aliases to existing ones. Of 
course, I don't mean to point out how ridiculously disproportioned this 
discussion is, but...

--
nosy: +ebarry

___
Python tracker 

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

[issue12345] Add math.tau

[Guido van Rossum]

Guido van Rossum added the comment:

Let those other libraries follow.

--

___
Python tracker 

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

[issue12345] Add math.tau

[Aaron Meurer]

Aaron Meurer added the comment:

Emanuel Barry, that is both untrue and irrelevant (sorry to be blunt, but 
that's a total straw man on my and I believe other's argument). The fact that 
the only mathematical constants in math are pi and e (nan and inf aren't really 
"mathematical" constants) *does* indicate to me that only the really important 
ones are included. 

GvR, are you also in favor of adding more math constants/functions to the math 
module? I do see the value of Easter eggs in the language, but two real 
constants and one Easter egg constant seems weirder than ten real constants and 
one Easter egg constant. I'm +1/(2*pi) (because I still think tau in general is 
stupid) to add it if it also means the math module can be expanded. And before 
you ask, yes, I'll be happy to contribute once things move to GitHub.

--

___
Python tracker 

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

[issue27506] make bytes/bytearray delete a keyword argument

[Martin Panter]

Martin Panter added the comment:

I agree it would be worth checking for a slowdown.

As well as giving the option of omitting the table argument, it would make call 
sites easier to read. It would avoid suggesting that the first argument is 
translated to the second, like maketrans().

data = data.translate(YENC_TABLE, delete=b"\r\n")

Translate() already accepts None as the first argument; this is not new:

>>> b"hello".translate(None, b"l")
b'heo'

I guess the optional group was used as a way of making the second argument 
optional without a specific default value.

--

___
Python tracker 

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

[issue12345] Add math.tau

[Guido van Rossum]

Guido van Rossum added the comment:

FWIW I don't plan to have more constants there, at the current rate we'll
be fine for centuries. :-)

What worries me more is proposals to add Python functions to math...

--Guido (mobile)

--

___
Python tracker 

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

[issue27181] Add geometric mean to `statistics` module

[Martin Panter]

Martin Panter added the comment:

Tests fail on a Power PC buildbot:

http://buildbot.python.org/all/builders/PPC64LE%20Fedora%203.x/builds/1476/steps/test/logs/stdio
==
FAIL: testExactPowers (test.test_statistics.Test_Nth_Root) (i=29, n=11)
--
Traceback (most recent call last):
  File 
"/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/test/test_statistics.py",
 line 1216, in testExactPowers
self.assertEqual(self.nroot(x, n), i)
AssertionError: 29.004 != 29

==
FAIL: testExactPowersNegatives (test.test_statistics.Test_Nth_Root) (i=-29, 
n=11)
--
Traceback (most recent call last):
  File 
"/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/test/test_statistics.py",
 line 1228, in testExactPowersNegatives
self.assertEqual(self.nroot(x, n), i)
AssertionError: -29.004 != -29

--
nosy: +martin.panter

___
Python tracker 

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

[issue24773] Implement PEP 495 (Local Time Disambiguation)

[Martin Panter]

Martin Panter added the comment:

Both parts of your commit seem to have helped. However I found two failures 
still happening, and one new failure:

1. Casablanca and El_Aaiun still failing since the original commit:
http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x/builds/1318/steps/test/logs/stdio
==
FAIL: test_system_transitions 
(test.datetimetester.ZoneInfoTest[Africa/El_Aaiun])
--
Traceback (most recent call last):
  File 
"/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/test/datetimetester.py",
 line 4781, in test_system_transitions
self.assertEquivDatetimes(sdt, tzdt)
  File 
"/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/test/datetimetester.py",
 line 4706, in assertEquivDatetimes
(b.replace(tzinfo=None), b.fold, id(b.tzinfo)))
AssertionError: Tuples differ: (datetime.datetime(2037, 10, 10, 3, 0), 0, 
271733936) != (datetime.datetime(2037, 10, 10, 2, 0, fold=1), 1, 271733936)

First differing element 0:
datetime.datetime(2037, 10, 10, 3, 0)
datetime.datetime(2037, 10, 10, 2, 0, fold=1)

- (datetime.datetime(2037, 10, 10, 3, 0), 0, 271733936)
?  ^  ^

+ (datetime.datetime(2037, 10, 10, 2, 0, fold=1), 1, 271733936)
?  ^      ^

2. The two Gentoo buildbots started failing at some point _after_ the original 
commit. The corresponding commit (b04560c3ce69) is not relevant to datetime.
http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%203.x/builds/1219/steps/test/logs/stdio
==
ERROR: test_folds (test.datetimetester.ZoneInfoTest[Asia/Qyzylorda])
--
Traceback (most recent call last):
  File 
"/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", 
line 4694, in setUp
self.tz = ZoneInfo.fromname(self.zonename)
  File 
"/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", 
line 4527, in fromname
return cls.fromfile(f)
  File 
"/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", 
line 4519, in fromfile
self = cls(ut, ti)
  File 
"/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", 
line 4472, in __init__
self.lt = self.invert(ut, ti)
  File 
"/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", 
line 4482, in invert
lt[0][i] += ti[i-1][0] // SEC
OverflowError: Python int too large to convert to C long

3. It looks like removing the sizeof_time_t skip re-introduced a year 2037 
failure for Cairo, although many other tests (e.g. New_York) that were skipped 
are now passing:
http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%203.x/builds/1228/steps/test/logs/stdio
==
FAIL: test_system_transitions (test.datetimetester.ZoneInfoTest[Africa/Cairo])
--
Traceback (most recent call last):
  File 
"/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", 
line 4781, in test_system_transitions
self.assertEquivDatetimes(sdt, tzdt)
  File 
"/buildbot/buildarea/3.x.ware-gentoo-x86/build/Lib/test/datetimetester.py", 
line 4706, in assertEquivDatetimes
(b.replace(tzinfo=None), b.fold, id(b.tzinfo)))
AssertionError: Tuples differ: (datetime.datetime(2037, 10, 9, 0, 0), 0, 
137328448) != (datetime.datetime(2037, 10, 8, 23, 0, fold=1), 1, 137328448)

First differing element 0:
datetime.datetime(2037, 10, 9, 0, 0)
datetime.datetime(2037, 10, 8, 23, 0, fold=1)

- (datetime.datetime(2037, 10, 9, 0, 0), 0, 137328448)
?  ^ ^   ^

+ (datetime.datetime(2037, 10, 8, 23, 0, fold=1), 1, 137328448)
?  ^ ^^   ^

--

___
Python tracker 

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

[issue25825] AIX shared library extension modules installation broken

[Martin Panter]

Martin Panter added the comment:

Patch1 looks fine to me, though I will have to rely on you people to verify 
that it does what it’s supposed to. Do you want me to commit it straight away, 
or wait for your follow-up patch?

--

___
Python tracker 

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

[issue16764] Make zlib accept keyword-arguments

[Xiang Zhang]

Xiang Zhang added the comment:

OK. Simplest test with positional arguments.

Without patch:

./python -m timeit -s 'import zlib; a = 
zlib.compress(b"abcdefghijklmnopqrstuvwxyz")' 'zlib.decompress(a, 15, 16384)'
100 loops, best of 3: 0.841 usec per loop

./python -m timeit -s 'import zlib; a = 
zlib.compress(b"abcdefghijklmnopqrstuvwxyz"); do = zlib.decompressobj()' 
'do.decompress(a, 100)'
1 loops, best of 3: 16 usec per loop

With patch:

./python -m timeit -s 'import zlib; a = 
zlib.compress(b"abcdefghijklmnopqrstuvwxyz")' 'zlib.decompress(a, 15, 16384)'
100 loops, best of 3: 0.843 usec per loop

./python -m timeit -s 'import zlib; a = 
zlib.compress(b"abcdefghijklmnopqrstuvwxyz"); do = zlib.decompressobj()' 
'do.decompress(a, 100)'
1 loops, best of 3: 16.1 usec per loop

But, with keyword specified, there is a degrade.

./python -m timeit -s 'import zlib; a = 
zlib.compress(b"abcdefghijklmnopqrstuvwxyz")' 'zlib.decompress(a, wbits=15, 
bufsize=16384)'
100 loops, best of 3: 1.26 usec per loop

./python -m timeit -s 'import zlib; a = 
zlib.compress(b"abcdefghijklmnopqrstuvwxyz"); do = zlib.decompressobj()' 
'do.decompress(a, max_length=100)'
1 loops, best of 3: 16.8 usec per loop

But with large data, the difference is gone:

./python -m timeit -s 'import zlib; a = 
zlib.compress(b"abcdefghijklmnopqrstuvwxyz"*1)' 'zlib.decompress(a, 15, 
16384)'
1000 loops, best of 3: 252 usec per loop # without patch

 ./python -m timeit -s 'import zlib; a = 
zlib.compress(b"abcdefghijklmnopqrstuvwxyz"*1)' 'zlib.decompress(a, 
wbits=15, bufsize=16384)'
1000 loops, best of 3: 252 usec per loop # with patch

So I think it's OK for this change. There seems no performance degrade to old 
code. And considering that zlib usually does time consuming tasks (I don't 
think it's common to decompress such small data), the small slower down seems 
affordable.

--

___
Python tracker 

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

[issue27614] Race in test_docxmlrpc.py

[Martin Panter]

Martin Panter added the comment:

Thanks for the explanation. It seems a bit strange that the server thread was 
running so slow while the main thread did one thousand polls over at least one 
second. Perhaps there is a blocking DNS call hidden somewhere in it somewhere? 
In any case, I am pretty confident my patch should help, so I will commit it 
unless there are any objections.

--

___
Python tracker 

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

[issue12345] Add math.tau

[Lisa Roach]

Lisa Roach added the comment:

I've updated the test to assert tau is equal to 2*math.pi, as well as updated 
the docs and cmath.

Let me know if I have made any errors!

--
nosy: +lisroach
Added file: http://bugs.python.org/file44080/tau3.diff

___
Python tracker 

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

[issue27348] traceback (and threading) drops exception message

[Martin Panter]

Martin Panter added the comment:

Have you had any luck reviewing this Robert?

--

___
Python tracker 

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

[issue12887] Documenting all SO_* constants in socket module

[Martin Panter]

Martin Panter added the comment:

See also Issue 27409, where I am proposing to list the SO_* and other constants 
by name (with associated Python version and whether they are missing on some 
platforms), but without descriptions.

--
nosy: +martin.panter

___
Python tracker 

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