[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see

[Xiang Zhang]

Xiang Zhang added the comment:

Oh, sorry. Upload bot_failure_fix.patch to fix this.

--
Added file: http://bugs.python.org/file44207/bot_failure_fix.patch

___
Python tracker 

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

[issue27842] Order CSV header fields

[Raymond Hettinger]

Raymond Hettinger added the comment:

This looks like a nice improvement.  The patch needs a test and the docs need a 
versionchanged entry.

--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue26907] Add missing getsockopt constants

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> fixed
stage: commit review -> 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

[issue26907] Add missing getsockopt constants

[Roundup Robot]

Roundup Robot added the comment:

New changeset ed5f5d490490 by R David Murray in branch 'default':
#26907: add some missing getsockopt constants.
https://hg.python.org/cpython/rev/ed5f5d490490

--
nosy: +python-dev

___
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

[Martin Panter]

Martin Panter added the comment:

Michael: When posting to the bug tracker, please trim irrelevant parts of old 
messages. It makes it hard to see if you actually added anything new.

> [Me] If your compiler does not support “signed short” bitfields, maybe we 
> just have to accept that ctypes supports it even though the compiler doesn’t, 
> and skip the test.

Proper support for “signed short” according to standard C I guess would mean if 
you define

struct BITS {
signed short M: 1;
} b;
b.M = -1;

then reading back b.M gives -1. However I realized test_bitfields tests 
overflowing values rather than negative values. In any case, I think we have 
established that neither of these cases work with XLC.

I haven’t changed the signed int A–I fields yet. That was part of my patch. I 
was waiting for confirmation about the __xlC__ check, before committing the 
whole thing.

Eric: I proposed to conditionally skip the test; see 
disable-signed-short.patch. Since many other compilers apparently pass the test 
and support signed short, we should probably keep the test.

--

___
Python tracker 

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

[issue27837] Logging Cookbook Improvement

[Niko Yasui]

Niko Yasui added the comment:

I see, I didn't realize that the simpler code would break under certain 
conditions.

While there are definitely simpler examples in other documents, I haven't been 
able to find any indication that there is a simpler way to do multiprocessing 
and logging together, either on StackOverflow or the Python docs, other than by 
stumbling into it accidentally while writing code for this thread. 

Since multiprocessing in Python usually requires some extra work-arounds 
compared to single processing solutions, I searched specifically for 
multiprocessing logging options. I was also not surprised that I needed a 
queue, since multiprocessing is complicated. IMO the docs would be more clear 
if there was either a simpler example with a caveat that it wouldn't work in 
windows, or with a small paragraph saying that after 3.2, using logging as if 
it were on a single process would not cause problems.

Just to clarify, my understanding is that the child loggers on separate 
processes pass records to the main logger, which runs on the original process, 
which then handles the records and writes to a file. In this way there is no 
problem of simultaneously writing to the same file. Is the above correct for 
the code I wrote?

Thanks for your patience with my inexperience. It's been a long time since I've 
spent so much time on learning a new module, and I think improving the docs 
will help other people avoid spending so much time.

--

___
Python tracker 

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

[issue27837] Logging Cookbook Improvement

[Niko Yasui]

Changes by Niko Yasui :


Removed file: http://bugs.python.org/file44198/multi_log_cookbook.py

___
Python tracker 

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

[issue23183] timeit CLI best of 3: undocumented output format

[R. David Murray]

R. David Murray added the comment:

I think the use of "timing loop" is very confusing, since the word 'loop' 
refers to one execution of the statement body in the actual output text.  What 
about calling it a 'timing run'?
 
It looks like whatever we come up with should be applied to 3.5 and 3.6 as well.

--
nosy: +r.david.murray
stage: commit review -> needs patch
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue25916] wave module readframes now returns bytes not str

[R. David Murray]

R. David Murray added the comment:

Thanks SilentGhost.

--
resolution:  -> fixed
stage: commit review -> 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

[issue25916] wave module readframes now returns bytes not str

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7ac8e8568da2 by R David Murray in branch '3.5':
#25916: fix a few 'string of bytes' references.
https://hg.python.org/cpython/rev/7ac8e8568da2

New changeset 089f7d761a9c by R David Murray in branch 'default':
Merge: #25916: fix a few 'string of bytes' references.
https://hg.python.org/cpython/rev/089f7d761a9c

--
nosy: +python-dev

___
Python tracker 

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

[issue24265] IDLE -s and (-, -c command, or -r file) produces error message

[Terry J. Reedy]

Terry J. Reedy added the comment:

I confirmed the bug on Win10 with 3.5 and 3.6.  "python -m idlelibl -s" prints 
a prompt*, runs the file and prints any output, and prints a prompt.  It then 
accepts user input.  When "-c command" is added, it should accept that as user 
input (and perhaps display it on the input line).  But I get the same error 
box.  When clicked away, 'command' executes and a third prompt is displayed.

*Another bug. The startup file should run first, before a prompt, just as it 
does in python, and just as with files run with F5. It would not hurt if 
[Running ] were printed, but not a prompt.  Prompts should mean 'ready to 
accept input'.  Ditto for -c command, unless IDLE is changed to display the 
command after the prompt as if typed in.

Warning comes from ModifiedInterpreter (MI).dispaly_executing_dialog, which is 
called in MI.runcommand if 'self.tkconsole.executing'.  MI.runcommand is used 
for internal startup code and for '-', '-c', and '-r' on the command line, but 
not for user '>>> ' and editor code. 

I confirmed that '-s' + '-' or '-r' give the same warning.  Hence the title 
change.

MI.tkconsole is the PyShell (PS) window instance.  PS.executing is set/reset in 
PS.beginexecuting, PS.endexecuting.  The latter should apparently be called 
someplace it is not now.

--
stage:  -> test needed
title: IDLE produces error message when run with both -s and -c. -> IDLE -s and 
(-, -c command, or -r file) produces error message
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue27809] _PyObject_FastCall(): add support for keyword arguments

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1b241e761f8f by Victor Stinner in branch 'default':
Issue #27809: map_next() uses fast call
https://hg.python.org/cpython/rev/1b241e761f8f

--

___
Python tracker 

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

[issue27809] _PyObject_FastCall(): add support for keyword arguments

[Roundup Robot]

Roundup Robot added the comment:

New changeset 401f59a7020b by Victor Stinner in branch 'default':
PyObject_CallMethodObjArgs() now uses fast call
https://hg.python.org/cpython/rev/401f59a7020b

--

___
Python tracker 

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

[issue27809] _PyObject_FastCall(): add support for keyword arguments

[Roundup Robot]

Roundup Robot added the comment:

New changeset 70f88b097f60 by Victor Stinner in branch 'default':
Issue #27809: map_next() uses fast call
https://hg.python.org/cpython/rev/70f88b097f60

New changeset 0e4f26083bbb by Victor Stinner in branch 'default':
PyObject_CallMethodObjArgs() now uses fast call
https://hg.python.org/cpython/rev/0e4f26083bbb

--

___
Python tracker 

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

[issue27834] test_datetime fails on "x86 Gentoo Non-Debug with X 3.x" buildbot

[STINNER Victor]

STINNER Victor added the comment:

Oh cool, thanks for the quick fix ;-)

--

___
Python tracker 

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

[issue27845] Optimize update_keyword_args() function

[STINNER Victor]

New submission from STINNER Victor:

In the review of my issue #27830 "Add _PyObject_FastCallKeywords(): pass 
keyword arguments as (key, value) pairs", Antoine Pitrou wrote about 
_PyStack_AsDict():

"It's a pity that you're doing two dict lookups per keyword argument.
Another strategy would be to check that `PyDict_Size() == nk` at the end, and 
if not, try to find the duplicate keyword."

https://bugs.python.org/review/27830/diff/18203/Objects/abstract.c#newcode2326_Objects/abstract.c:2326


In fact, I simply copied code from update_keyword_args(), helper function used 
by do_call() and ext_do_call() in Python/ceval.c.

This function is quite old, the last major change was made in 2001:
---
changeset:   15711:2481b5fe86d6
branch:  legacy-trunk
user:Jeremy Hylton 
date:Wed Jan 03 23:52:36 2001 +
files:   Python/ceval.c
description:
Revised implementation of CALL_FUNCTION and friends.
More revision still needed.

(...)
---


But this change just moved code. It looks like the real code was in fact added 
by this change made in 2000:
---
changeset:   12082:603db0d0aed1
branch:  legacy-trunk
user:Jeremy Hylton 
date:Tue Mar 28 23:49:17 2000 +
files:   Grammar/Grammar Include/opcode.h Lib/dis.py Misc/ACKS 
Python/ceval.c Python/compile.c Python/graminit.c
description:
slightly modified version of Greg Ewing's extended call syntax patch

executive summary:
Instead of typing 'apply(f, args, kwargs)' you can type 'f(*arg, **kwargs)'.
Some file-by-file details follow.

(...)
---

--
messages: 273518
nosy: haypo
priority: normal
severity: normal
status: open
title: Optimize update_keyword_args() function
type: performance
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

[issue27841] Use fast call in method_call() and slot_tp_new()

[STINNER Victor]

STINNER Victor added the comment:

Stefan Behnel added the comment:
> If you care so much about C stack space, you could also try to create two or 
> three entry point functions that keep (say) a 4, 8 and 16 items array on the 
> stack respectively, (...)

I should compute statistics, but I'm quite sure that most function
calls take 5 or less parameters. I don't think that allocating 5
PyObject* uses too much C stack, what do you think?

I don't think that using the heap memory for more parameters will
"kill" performances. Python 3.5 already does the same, a tuple is
allocated in the heap memory ;-) It just that I want to optimize the
common case.

--

___
Python tracker 

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

[issue27821] IDLE custom keymaps don't work anymore (Windows, Python 3.6.0a3)

[Terry J. Reedy]

Terry J. Reedy added the comment:

I can't make any sense of this report.

In configdialog.py, the DynOptionMenu self.optMenuKeysCuston is set in 
LoadKeyConfig (line 1066) by
itemList = idleConf.GetSectionList('user', 'keys')
itemList.sort()
if not itemList:
self.radioKeysCustom.config(state=DISABLED)
self.customKeys.set('- no custom keys -')
else:
self.optMenuKeysCustom.SetMenu(itemList, itemList[0])

or the same without the 'if' clause.  This code was not changed by the patch.  
Nor was config.IdleConf.GetSectionList.  So there should be no way for anything 
to appear on that menu unless in the user keys file.

To test Veky2 as posted, I added it to my user keys files.  I opened a IDLE 
fresh and brought up the config dialog.  Veky2 was on the list and when I 
selected it and closed the dialog, there was no problem.  I tested and the 
Veky2 definition of <> as  worked.  (I just added 
that to Terry.)  When I opened the dialog again, Veky2 was still there, 
selected.

In the absence of a failing test case or of any idea how the code could produce 
the behavior you report, there is not much I can do.

--

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

As far as I can tell, the buildbots are happy now.  Closing.  Please open new 
issues if missed anything.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue27834] test_datetime fails on "x86 Gentoo Non-Debug with X 3.x" buildbot

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The build succeeded.

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%203.x/builds/1292

Closing. Thanks for the report, Victor.

--
resolution:  -> fixed
stage: needs patch -> 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

[issue27643] test_ctypes fails on AIX with xlc

[Eric N. Vander Weele]

Eric N. Vander Weele added the comment:

I am able to replicate what Michael has provided (i.e., xlc does not support 
signed short).  Sorry for the confusion: I overlooked that the compiler is 
emitting the error with may patch and assuming 'unsigned'.

So it seems like there are two things to address: (1) The bit fields should be 
explicitly marked as 'signed', since that appears to be the desired intent.  
(2) What to do about the test case.

It seems like we all agree on (1).  For (2), is this something that should be 
stubbed out on AIX/xlc, resolved by xlc for supporting implementation-defined 
(short) bit-fields, or remove the short members in the struct since C99 
(6.7.2.1) allows "a qualified or unqualified version of _Bool, signed int, 
unsigned int, or some other implementation-defined type"; thus removing the 
ambiguity for implementation-defined behavior?

--

___
Python tracker 

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

[issue27598] Add Collection to collections.abc and typing

[Ivan Levkivskyi]

Ivan Levkivskyi added the comment:

Guido, thank you for committing! There are also some other omissions in docs, 
Type[C], @overload, there is #26141 to track this. I will submit a patch later. 
Until 3.6beta1 I would like to focus on PEP 526.

--

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

On 23-Aug-16 21:23, Michael Felt wrote:
> Michael Felt added the comment:
>
> Using:
>
> root@x064:[/data/prj/aixtools/python/tests]cat -n bits.c
>1   struct BITS {
>2  signed int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9;
>3  signed short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7;
>4  signed char T: 1, U: 2, V: 3;
>5  unsigned char W: 1, X: 2, Y: 3;
>6  signed long J: 1, K: 2, L: 3;
>7   };
>
> Using:
>
> root@x064:[/data/prj/aixtools/python/tests]xlc -qversion
> IBM XL C/C++ for AIX, V11.1 (5724-X13)
> Version: 11.01..0020
>
> I get:
>
> root@x064:[/data/prj/aixtools/python/tests]xlc -c bits.c
> "bits.c", line 3.5: 1506-159 (E) Bit field type specified for M is not
> valid. Type unsigned assumed.
> "bits.c", line 3.5: 1506-159 (E) Bit field type specified for N is not
> valid. Type unsigned assumed.
> "bits.c", line 3.5: 1506-159 (E) Bit field type specified for O is not
> valid. Type unsigned assumed.
> "bits.c", line 3.5: 1506-159 (E) Bit field type specified for P is not
> valid. Type unsigned assumed.
> "bits.c", line 3.5: 1506-159 (E) Bit field type specified for Q is not
> valid. Type unsigned assumed.
> "bits.c", line 3.5: 1506-159 (E) Bit field type specified for R is not
> valid. Type unsigned assumed.
> "bits.c", line 3.5: 1506-159 (E) Bit field type specified for S is not
> valid. Type unsigned assumed.
> "bits.c", line 4.5: 1506-159 (E) Bit field type specified for T is not
> valid. Type unsigned assumed.
> "bits.c", line 4.5: 1506-159 (E) Bit field type specified for U is not
> valid. Type unsigned assumed.
> "bits.c", line 4.5: 1506-159 (E) Bit field type specified for V is not
> valid. Type unsigned assumed.
p.s. I guess we can assume, better infer, this message does not mean 
"unsigned whatever" but unsigned (unspoken int)
> "bits.c", line 5.5: 1506-159 (E) Bit field type specified for W is not
> valid. Type unsigned assumed.
> "bits.c", line 5.5: 1506-159 (E) Bit field type specified for X is not
> valid. Type unsigned assumed.
> "bits.c", line 5.5: 1506-159 (E) Bit field type specified for Y is not
> valid. Type unsigned assumed.
>
> On 23-Aug-16 01:06, Martin Panter wrote:
>> Martin Panter added the comment:
>>
>> Now I am confused. In  we have
>>
>> [Me] If your compiler does not support “signed short” bitfields, maybe we 
>> just have to accept that ctypes supports it even though the compiler 
>> doesn’t, and skip the test.
> As the test also fails for A..I when not specified as signed int, if you
> have not already "changed" that (I forget in the time passed), then that
> should, at least be specified for the A..I BITS definition.
>
> I do not understand what you mean by "supports" - yes, it can be
> assigned, but the result you get when "querying" the bit depends on how
> you query it. Is that "support" when conflicting values are returned?
> Don't mind my not understanding - If skipping "solves" it, then yes,
> skip the test.
>
>> [Michael] Looks like this may be the approach: as signed int, signed short 
>> give the same message - it seems that xlc (and maybe Sun C) does not accept 
>> "short" as a bitfield type.
>>
>> Apparently XLC doesn’t accept signed short bitfields for Michael, but does 
>> for Eric. What’s going on? Maybe different versions?
>>
>> --
>>
>> ___
>> Python tracker 
>> 
>> ___
> --
>
> ___
> Python tracker 
> 
> ___

--

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

Using:

root@x064:[/data/prj/aixtools/python/tests]cat -n bits.c
  1   struct BITS {
  2  signed int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9;
  3  signed short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7;
  4  signed char T: 1, U: 2, V: 3;
  5  unsigned char W: 1, X: 2, Y: 3;
  6  signed long J: 1, K: 2, L: 3;
  7   };

Using:

root@x064:[/data/prj/aixtools/python/tests]xlc -qversion
IBM XL C/C++ for AIX, V11.1 (5724-X13)
Version: 11.01..0020

I get:

root@x064:[/data/prj/aixtools/python/tests]xlc -c bits.c
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for M is not 
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for N is not 
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for O is not 
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for P is not 
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for Q is not 
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for R is not 
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for S is not 
valid. Type unsigned assumed.
"bits.c", line 4.5: 1506-159 (E) Bit field type specified for T is not 
valid. Type unsigned assumed.
"bits.c", line 4.5: 1506-159 (E) Bit field type specified for U is not 
valid. Type unsigned assumed.
"bits.c", line 4.5: 1506-159 (E) Bit field type specified for V is not 
valid. Type unsigned assumed.
"bits.c", line 5.5: 1506-159 (E) Bit field type specified for W is not 
valid. Type unsigned assumed.
"bits.c", line 5.5: 1506-159 (E) Bit field type specified for X is not 
valid. Type unsigned assumed.
"bits.c", line 5.5: 1506-159 (E) Bit field type specified for Y is not 
valid. Type unsigned assumed.

On 23-Aug-16 01:06, Martin Panter wrote:
> Martin Panter added the comment:
>
> Now I am confused. In  we have
>
> [Me] If your compiler does not support “signed short” bitfields, maybe we 
> just have to accept that ctypes supports it even though the compiler doesn’t, 
> and skip the test.
As the test also fails for A..I when not specified as signed int, if you 
have not already "changed" that (I forget in the time passed), then that 
should, at least be specified for the A..I BITS definition.

I do not understand what you mean by "supports" - yes, it can be 
assigned, but the result you get when "querying" the bit depends on how 
you query it. Is that "support" when conflicting values are returned? 
Don't mind my not understanding - If skipping "solves" it, then yes, 
skip the test.

>
> [Michael] Looks like this may be the approach: as signed int, signed short 
> give the same message - it seems that xlc (and maybe Sun C) does not accept 
> "short" as a bitfield type.
>
> Apparently XLC doesn’t accept signed short bitfields for Michael, but does 
> for Eric. What’s going on? Maybe different versions?
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue26040] Improve coverage and rigour of test.test_math

[Mark Dickinson]

Mark Dickinson added the comment:

Reverted in https://hg.python.org/cpython/rev/4389aa3507c5

--

___
Python tracker 

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

[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see

[R. David Murray]

R. David Murray added the comment:

This is causing a test failure on the windows 8 bot.  Can you fix it Xiang?  
Otherwise I'll have to revert.

http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/870

==
ERROR: test_islink (test.test_posixpath.PosixPathTest)
--
Traceback (most recent call last):
  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_posixpath.py", line 
110, in test_islink
os.symlink(test_support.TESTFN + "1", test_support.TESTFN + "2")
AttributeError: 'module' object has no attribute 'symlink'

==
ERROR: test_ismount_symlinks (test.test_posixpath.PosixPathTest)
--
Traceback (most recent call last):
  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_posixpath.py", line 
221, in test_ismount_symlinks
os.unlink(ABSTFN)
WindowsError: [Error 2] The system cannot find the file specified: 
'D:\\buildarea\\2.7.bolen-windows8\\build\\build\\test_python_2024/@test_2024_tmp'

--

--
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 

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

[issue26040] Improve coverage and rigour of test.test_math

[Mark Dickinson]

Mark Dickinson added the comment:

Thanks, Ned. (And apologies.) The test_math tests are too strict in this case, 
which is one of the issues that Jeff's full patch fixes. It looks like my 
strategy of applying the patch in two pieces isn't going to work.

I'll revert the change for now, and have another go at this tomorrow.

--

___
Python tracker 

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

[issue27834] test_datetime fails on "x86 Gentoo Non-Debug with X 3.x" buildbot

[Roundup Robot]

Roundup Robot added the comment:

New changeset a13c51bde2b4 by Alexander Belopolsky in branch 'default':
Issue #27834: Avoid overflow error in ZoneInfo.invert().
https://hg.python.org/cpython/rev/a13c51bde2b4

--
nosy: +python-dev

___
Python tracker 

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt added the comment:

patch to include RTLD_MEMBER in Modules/_ctypes and also "document", or not 
document, RTLD_NOW

--
Added file: 
http://bugs.python.org/file44206/Python3.6.Modules._ctypes.160823.patch

___
Python tracker 

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

[issue27834] test_datetime fails on "x86 Gentoo Non-Debug with X 3.x" buildbot

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

This is related to issue 24773.

--
assignee:  -> belopolsky
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt added the comment:

New patch (diff) - that I hope address the comments made in the previous 
submission

--
Added file: http://bugs.python.org/file44205/Python3.6.Lib.ctypes.160823.patch

___
Python tracker 

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

[issue27836] VCRUNTIME140.DLL not found

[Zachary Ware]

Changes by Zachary Ware :


--
stage:  -> resolved

___
Python tracker 

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

[issue27836] VCRUNTIME140.DLL not found

[Steve Dower]

Changes by Steve Dower :


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

[issue27787] Avoid test_main() in test_httplib; gc.collect() dangling threads

[Roundup Robot]

Roundup Robot added the comment:

New changeset 31e4495a34ce by Terry Jan Reedy in branch 'default':
Issue #27787: No longer call deleted test_main().
https://hg.python.org/cpython/rev/31e4495a34ce

--

___
Python tracker 

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

[issue27831] Python 3.4.5 leaks memory when attempting to load non-existent file

[koobs]

Changes by koobs :


--
nosy: +koobs
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue27831] Python 3.4.5 leaks memory when attempting to load non-existent file

[geeknik]

geeknik added the comment:

Sure, 3.5 and/or 3.6 has memory leaks during compilation:
https://bugs.python.org/issue27780

And I just compiled 3.5.2 and running that version of python against a 
non-existent file returns this from LeakSanitizer:

ASAN_SYMBOLIZER_PATH=/usr/lib/llvm-3.5/bin/llvm-symbolizer 
ASAN_OPTIONS=symbolizer=1 ./python garbage
./python: can't open file 'garbage': [Errno 2] No such file or directory

=
==5338==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 657546 byte(s) in 584 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12

Direct leak of 43896 byte(s) in 63 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4de339 in PyMem_RawMalloc /root/python-3.5.2/Objects/obmalloc.c:293:12
#2 0x4de339 in _PyObject_Alloc /root/python-3.5.2/Objects/obmalloc.c:1376

Direct leak of 42520 byte(s) in 31 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12
#2 0x7e39df in _PyEval_EvalCodeWithName 
/root/python-3.5.2/Python/ceval.c:4018:14

Direct leak of 28160 byte(s) in 7 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12
#2 0x6535ab in set_add_entry /root/python-3.5.2/Objects/setobject.c:313:12

Direct leak of 3584 byte(s) in 15 object(s) allocated from:
#0 0x4bd79e in realloc (/root/python-3.5.2/python+0x4bd79e)
#1 0x4db6aa in PyMem_Realloc /root/python-3.5.2/Objects/obmalloc.c:343:12

Direct leak of 3584 byte(s) in 16 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12
#2 0x682a09 in type_call /root/python-3.5.2/Objects/typeobject.c:890:11

Direct leak of 448 byte(s) in 2 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12
#2 0x88e289 in _Py_InitializeEx_Private 
/root/python-3.5.2/Python/pylifecycle.c:377:14
#3 0x4e553f in Py_Main /root/python-3.5.2/Modules/main.c:669:5
#4 0x4dae5e in main /root/python-3.5.2/./Programs/python.c:65:11

Direct leak of 264 byte(s) in 2 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12
#2 0x4e553f in Py_Main /root/python-3.5.2/Modules/main.c:669:5
#3 0x4dae5e in main /root/python-3.5.2/./Programs/python.c:65:11

Direct leak of 96 byte(s) in 3 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db387 in PyMem_RawMalloc /root/python-3.5.2/Objects/obmalloc.c:293:12

Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12
#2 0x4e5942 in Py_Main /root/python-3.5.2/Modules/main.c:693:5
#3 0x4dae5e in main /root/python-3.5.2/./Programs/python.c:65:11

Indirect leak of 124748 byte(s) in 133 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4de339 in PyMem_RawMalloc /root/python-3.5.2/Objects/obmalloc.c:293:12
#2 0x4de339 in _PyObject_Alloc /root/python-3.5.2/Objects/obmalloc.c:1376

Indirect leak of 6016 byte(s) in 47 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12
#2 0x682a09 in type_call /root/python-3.5.2/Objects/typeobject.c:890:11

Indirect leak of 2912 byte(s) in 7 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12

Indirect leak of 640 byte(s) in 5 object(s) allocated from:
#0 0x4bd4ab in malloc (/root/python-3.5.2/python+0x4bd4ab)
#1 0x4db577 in PyMem_Malloc /root/python-3.5.2/Objects/obmalloc.c:325:12
#2 0x68dea1 in tp_new_wrapper 
/root/python-3.5.2/Objects/typeobject.c:5595:11

SUMMARY: AddressSanitizer: 914422 byte(s) leaked in 916 allocation(s).

--

___
Python tracker 

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

[issue27598] Add Collection to collections.abc and typing

[Guido van Rossum]

Guido van Rossum added the comment:

changeset:   102867:355fa8bd8d9d
branch:  3.5
parent:  102860:e3466a556d81
user:Guido van Rossum 
date:Tue Aug 23 11:01:50 2016 -0700
summary: A new version of typing.py from https://github.com/python/typing.

changeset:   102868:013bb690c24a
tag: tip
parent:  102866:acd9a465b373
parent:  102867:355fa8bd8d9d
user:Guido van Rossum 
date:Tue Aug 23 11:06:30 2016 -0700
summary: A new version of typing.py from https://github.com/python/typing. 
(Merge 3.5->3.6)

--
resolution:  -> fixed
status: open -> closed
type:  -> enhancement

___
Python tracker 

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

[issue27598] Add Collection to collections.abc and typing

[Guido van Rossum]

Guido van Rossum added the comment:

Actually there's one TODO left: the docs for typing (at least in 3.6)
should mention Collection.

--

___
Python tracker 

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

[issue27598] Add Collection to collections.abc and typing

[Guido van Rossum]

Changes by Guido van Rossum :


--
stage: test needed -> resolved

___
Python tracker 

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

[issue27831] Python 3.4.5 leaks memory when attempting to load non-existent file

[R. David Murray]

R. David Murray added the comment:

I'm not saying there isn't a leak, rather I'm trying to understand what you are 
reporting, without any understanding of ASN.  So I'm going to leave this to 
others to evaluate.

Also, do you see the same thing in 3.5 or 3.6?  We aren't patching 3.4 anymore 
(except for security issues).

--

___
Python tracker 

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

[issue27831] Python 3.4.5 leaks memory when attempting to load non-existent file

[geeknik]

geeknik added the comment:

Interesting that only Python exhibits this "leaky" behavior that generates a 
LeakSanitizer error. I don't see similar behavior in Perl, Ruby or PHP. Running 
a non-ASAN build under Valgrind reports that a leak is still occurring: 

LEAK SUMMARY:
==15496==definitely lost: 0 bytes in 0 blocks
==15496==indirectly lost: 0 bytes in 0 blocks
==15496==  possibly lost: 19,784 bytes in 34 blocks
==15496==still reachable: 879,399 bytes in 862 blocks
==15496== suppressed: 0 bytes in 0 blocks
==15496==
==15496== ERROR SUMMARY: 98 errors from 40 contexts (suppressed: 0 from 0)

>From the Valgrind manual:
"possibly lost" means your program is leaking memory, unless you're doing 
unusual things with pointers that could cause them to point into the middle of 
an allocated block;

--

___
Python tracker 

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

[issue27841] Use fast call in method_call() and slot_tp_new()

[Stefan Behnel]

Stefan Behnel added the comment:

If you care so much about C stack space, you could also try to create two or 
three entry point functions that keep (say) a 4, 8 and 16 items array on the 
stack respectively, and then pass the pointer (and the overall length if you 
need it) of that array on into a single function that copies the argument 
pointers into it and calls the Python function. As long as they are all really 
simple static functions that end with tail calls (i.e. with "return 
other_function()"), the C compiler should always be able to inline the entry 
points into their caller and not waste any additional C stack space for calling 
them.

--

___
Python tracker 

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

[issue27598] Add Collection to collections.abc and typing

[Guido van Rossum]

Guido van Rossum added the comment:

I'll keep this open until I've also merged typing.py.

--

___
Python tracker 

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

[issue27598] Add Collection to collections.abc and typing

[Roundup Robot]

Roundup Robot added the comment:

New changeset acd9a465b373 by Guido van Rossum in branch 'default':
Issue 27598: Add Collections to collections.abc.
https://hg.python.org/cpython/rev/acd9a465b373

--
nosy: +python-dev

___
Python tracker 

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

[issue26040] Improve coverage and rigour of test.test_math

[Ned Deily]

Ned Deily added the comment:

Mark, many buildbots are unhappy.  For example:

==
FAIL: test_testfile (test.test_math.MathTests)
--
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_math.py", 
line 1106, in test_testfile
self.ftest("%s:%s(%r)" % (id, fn, ar), result, er)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_math.py", 
line 194, in ftest
(name, value, expected))
AssertionError: cosh0063:cosh(709.7827) returned 8.988349783319008e+307, 
expected 8.988349783319007e+307

--
nosy: +ned.deily

___
Python tracker 

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

[issue26040] Improve coverage and rigour of test.test_math

[koobs]

Changes by koobs :


--
nosy: +koobs

___
Python tracker 

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

[issue27843] Spaces in filenames in setuptools

[Eric N. Vander Weele]

Changes by Eric N. Vander Weele :


--
nosy: +ericvw

___
Python tracker 

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

[issue27843] Spaces in filenames in setuptools

[R. David Murray]

R. David Murray added the comment:

setuptools is not part of CPython or the standard library, though it is 
currently distributed with CPython via ensurepip.  You should report this issue 
to the setuptools and/or pip bug tracker.

--
nosy: +dstufft, r.david.murray

___
Python tracker 

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

[issue27844] Python-3.6a4 build messages to stderr (on AIX and xlc compiler)

[Michael Felt]

New submission from Michael Felt:

FYI: Compiler warnings that appear on stderr (skipping any messages sent to 
stdout) - xlc V11 as the reporting compiler.

Two that may need attention are the redefines of _POSIX_C_SOURCE and 
_XOPEN_SOURCE in pyconfig.h

Also surprised by the message:
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]

I do not recall seeing that message in other builds.

Note also: no messages (to stderr) from configure

Details:

+ CPPFLAGS="-I/opt/include -I/opt/buildaix/include" CFLAGS="-I/opt/include 
-qmaxmem=-1 -qarch=pwr4 -O2 -I/opt/buildaix/includes"\
./configure\
--prefix=/opt \
--sysconfdir=/var/python/etc\
--sharedstatedir=/var/python/com\
--localstatedir=/var/python\
--mandir=/usr/share/man\
--infodir=/opt/share/info/python --without-computed-gotos\
> .buildaix/configure.out
+ make > .buildaix/make.out
"Objects/moduleobject.c", line 241.20: 1506-068 (W) Operation between types 
"struct _object*(*)(struct _object*,struct PyModuleDef*)" and "void*" is not 
allowed.
"./pyconfig.h", line 1472.9: 1506-236 (W) Macro name _POSIX_C_SOURCE has been 
redefined.
"./pyconfig.h", line 1472.9: 1506-358 (I) "_POSIX_C_SOURCE" is defined on line 
147 of /usr/include/standards.h.
"./pyconfig.h", line 1494.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been 
redefined.
"./pyconfig.h", line 1494.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 
143 of /usr/include/standards.h.
"./Modules/posixmodule.c", line 5532.11: 1506-131 (W) Explicit dimension 
specification or initializer required for an auto or static array.
"./Modules/xxsubtype.c", line 293.19: 1506-196 (W) Initialization between types 
"void*" and "int(*)(struct _object*)" is not allowed.
nm: libpython3.6m.a: 0654-200 Cannot open the specified file.
nm: A file or directory in the path name does not exist.
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", 
line 392.5: 1506-159 (E) Bit field type specified for M is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", 
line 392.5: 1506-159 (E) Bit field type specified for N is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", 
line 392.5: 1506-159 (E) Bit field type specified for O is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", 
line 392.5: 1506-159 (E) Bit field type specified for P is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", 
line 392.5: 1506-159 (E) Bit field type specified for Q is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", 
line 392.5: 1506-159 (E) Bit field type specified for R is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", 
line 392.5: 1506-159 (E) Bit field type specified for S is not valid. Type 
unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/arraymodule.c", line 
2996.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct 
_object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 
84.22: 1506-196 (W) Initialization between types "void*" and "int(*)(struct 
{...}*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 
85.22: 1506-196 (W) Initialization between types "void*" and "int(*)(struct 
{...}*,int(*)(struct _object*,void*),void*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 
86.22: 1506-196 (W) Initialization between types "void*" and "struct 
_object*(*)(struct {...}*,struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 
87.21: 1506-196 (W) Initialization between types "void*" and "int(*)(struct 
{...}*,const char*,struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 
235.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct 
_object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 
281.21: 1506-196 (W) Initialization between types "void*" and "struct 
_object*(*)(struct _object*,struct PyModuleDef*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 
454.21: 1506-196 (W) Initialization between types "void*" and "struct 
_object*(*)(struct _object*,struct PyModuleDef*)" is not allowed.

[issue27843] Spaces in filenames in setuptools

[Michael Felt]

New submission from Michael Felt:

p.s. - guessing on the component - this is after make install

+ make install DESTDIR=/var/aixtools/aixtools/python/3.6.0.164 > 
.buildaix/install.out
+ mkinstallp.ksh /var/aixtools/aixtools/python/3.6.0.164 > 
.buildaix/mkinstallp.out

+
renamed:./opt/lib/python3.6/site-packages/setuptools/script 
(dev).tmpl:./opt/lib/python3.6/site-packages/setuptools/script_dev_.tmpl
renamed:./opt/lib/python3.6/site-packages/setuptools/command/launcher 
manifest.xml:./opt/lib/python3.6/site-packages/setuptools/command/launcher_manifest.xml
+

My script scans for files with "hard to package" filenames, and I see two in 
site-packages/setuptools

No idea if this is new to Python-3.6, or if it has been around for a long time, 
but it does not seem "handy" to distribute files with " " in the filename.

--
components: Installation
messages: 273490
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Spaces in filenames in setuptools
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

[issue27842] Order CSV header fields

[R. David Murray]

R. David Murray added the comment:

I think this seems reasonable, now that OrderedDict is in C.

--
nosy: +r.david.murray
type:  -> enhancement

___
Python tracker 

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

[issue12029] Catching virtual subclasses in except clauses

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag

___
Python tracker 

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

[issue21085] compile error Python3.3 on Cygwin

[Masayuki Yamamoto]

Masayuki Yamamoto added the comment:

Hello, I'm writer for past patch.
3.4-issue21085-struct_siginfo.patch removes si_band field from struct_siginfo 
if the C siginfo_t doesn't have si_band field.
This modification raises a incompatibility between platforms having 
struct_siginfo.
Now, I wrote another patch that doesn't change fields of struct_siginfo to 
avoid its incompatibility. 
And I built cpython 3.5.2+ on vista cygwin-x86 using this patch.
Murray, would you be able to tell me your idea?
Many thanks.

New patch changes:
If platform has the C siginfo_t structure, but it doesn't have si_band field, 
the struct_siginfo.si_band field is always assigned zero at function return 
value.

--
Added file: http://bugs.python.org/file44204/3.5-issue21085-struct_siginfo.patch

___
Python tracker 

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

[issue27842] Order CSV header fields

[R. David Murray]

Changes by R. David Murray :


--
hgrepos:  -353

___
Python tracker 

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

[issue27842] Order CSV header fields

[Steve Holden]

Steve Holden added the comment:

Sorry, deleted the originally submitted (incorrect) patch file.

--
Added file: http://bugs.python.org/file44203/csv.patch

___
Python tracker 

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

[issue27842] Order CSV header fields

[Steve Holden]

Changes by Steve Holden :


Removed file: http://bugs.python.org/file44202/csv.patch

___
Python tracker 

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

[issue27842] Order CSV header fields

[Steve Holden]

New submission from Steve Holden:

It's sometimes annoying that a csv.DictReader doesn't retain the field ordering 
given in the first line of the file. Sometimes it matters.

This patch converts the reader so that it returns an OrderedDict rather than a 
plain dict, thereby retaining the ordering.

All tests still pass (though I haven't yet added a test to verify that the 
field ordering *is* retained - didn't think it was worth it if the patch won't 
be added, but will happily add that test otherwise).

I have updated the documentation, but was unable in the time available to find 
out how to correctly reference the OrderedDict class so that it was correctly 
hyperlinked.

--
components: Library (Lib)
files: csv.patch
hgrepos: 353
keywords: needs review, patch
messages: 273486
nosy: holdenweb
priority: normal
severity: normal
stage: patch review
status: open
title: Order CSV header fields
versions: Python 3.6
Added file: http://bugs.python.org/file44202/csv.patch

___
Python tracker 

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

[issue27573] code.interact() should print an exit message

[Roundup Robot]

Roundup Robot added the comment:

New changeset c4863530cfd6 by Steven D'Aprano in branch 'default':
Issue #27573 make the exit message configurable.
https://hg.python.org/cpython/rev/c4863530cfd6

--

___
Python tracker 

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

[issue26040] Improve coverage and rigour of test.test_math

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1017215f5492 by Mark Dickinson in branch 'default':
Issue #26040 (part 1): add new testcases to cmath_testcases.txt. Thanks Jeff 
Allen.
https://hg.python.org/cpython/rev/1017215f5492

--
nosy: +python-dev

___
Python tracker 

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

[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see

[R. David Murray]

R. David Murray added the comment:

Thanks, Xiang.

--
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue27837] Logging Cookbook Improvement

[Vinay Sajip]

Vinay Sajip added the comment:

> Since a queue isn't necessary for logging with multiprocessing

IMO a queue with QueueHandler/QueueListener is best practice when working with 
multiprocessing and logging. If you don't use them, things may seem to work 
some of the time but could fail in certain scenarios. For example, 
multiprocessing works differently on different platforms such as POSIX and 
Windows, which can lead to problems with simpler approaches.

There are plenty of simpler examples in the logging tutorial and cookbook, 
which might be worth reviewing first if you are new to logging in Python.

See this post for a discussion on using logging with multiprocessing:

https://plumberjack.blogspot.co.uk/2010/09/using-logging-with-multiprocessing.html

This was the original source of the example in the cookbook.

--

___
Python tracker 

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

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[R. David Murray]

Changes by R. David Murray :


--
hgrepos:  -352

___
Python tracker 

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

[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see

[Roundup Robot]

Roundup Robot added the comment:

New changeset 75111791110b by R David Murray in branch '2.7':
# 2466: ismount now recognizes mount points user can't access.
https://hg.python.org/cpython/rev/75111791110b

--

___
Python tracker 

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

[issue27598] Add Collection to collections.abc and typing

[Guido van Rossum]

Changes by Guido van Rossum :


--
title: Add SizedIterable to collections.abc and typing -> Add Collection to 
collections.abc and typing

___
Python tracker 

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

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[Erik Bray]

Erik Bray added the comment:

FWIW I've created an initial patch for this.  Seems to work fine, but it's a 
bit of a mess and I have a few small implementation concerns.  I'll try to get 
it cleaned up sometime in the next few days and I'll post it.

--

___
Python tracker 

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

[issue27836] VCRUNTIME140.DLL not found

[Chris Wood]

Chris Wood added the comment:

Ah, in that case:

 - I guess the issue would have been that the python 3.5 installation I tried 
(which was 3.5.0a1) had the vcruntime140.dll issue 
 - I've realised that the 3.5* installation puts Python on the beginning of the 
PATH - whereas I was putting the 2.7 directory at the end of the PATH (so when 
I was testing 2.7 my PATH variable was being ignored by the 3.5 one.
 - I assume that the missing vcruntime140.dll was a known bug in 3.5.0a1 and 
was fixed in a subsequent release

I should have probably realised all of this earlier!

--

___
Python tracker 

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

[issue27598] Add SizedIterable to collections.abc and typing

[Guido van Rossum]

Guido van Rossum added the comment:

ReIterable and Collection are different concepts.
- ReIterable just implements __iter__ but promises certain semantics.
- Collection implements __iter__, __contains__ and __len__.

If we had ReIterable I would probably decree that Collection inherits from it 
(practicality beats purity).

But I don't think ReIterable by itself would do much good; apart from a few 
"show-off" hacks, any reasonable ReIterable would also be able to implement 
__contains__ and __len__ easily.

And I would certainly call range() a Collection.

--

___
Python tracker 

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

[issue2613] inconsistency with bare * in parameter list

[Guido van Rossum]

Guido van Rossum added the comment:

I promise you it's not necessary in that example. Leaving out the '*' has the 
same effect as what you intend there.

--

___
Python tracker 

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

[issue27836] VCRUNTIME140.DLL not found

[Steve Dower]

Steve Dower added the comment:

Nothing in Python 2.7 depends on vcruntime140.dll, so you shouldn't be seeing 
that error from there.

My guess is that you have an extension module that requires it, or possibly 
your PATH or PYTHONPATH variables were mixed up.

It sounds like everything is working now? There's nothing actionable in this 
report unfortunately, unless you can reproduce the issue and help us diagnose 
it some more.

--

___
Python tracker 

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

[issue27836] VCRUNTIME140.DLL not found

[Chris Wood]

Chris Wood added the comment:

Apologies, there are typos in my final paragraph - 3.5.11 should just be 3.5, 
and 3.5.12 should be 3.5.2

--

___
Python tracker 

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

[issue27837] Logging Cookbook Improvement

[Niko Yasui]

Niko Yasui added the comment:

Thank you both for the helpful comments.

Vinay, since you want to illustrate a listener process in the multiprocessing 
example, why not include a shorter, simpler example beforehand? This is my 
first time using logging, and it took me multiple hours to figure out what your 
example was doing and which parts were extra. Since a queue isn't necessary for 
logging with multiprocessing, I did my best to write a shorter example to 
introduce the concept before exploring your code with the listener.

What do you think about this addition?

--
keywords: +patch
Added file: http://bugs.python.org/file44201/mp_log_cookbook.patch

___
Python tracker 

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

[issue27363] Complex numbers with negative zero parts do not roundtrip properly

[Vedran Čačić]

Vedran Čačić added the comment:

Since I'm so happy with Fraction being fixed, I'll agree here. :-)

--

___
Python tracker 

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

[issue26040] Improve coverage and rigour of test.test_math

[Mark Dickinson]

Mark Dickinson added the comment:

I finally have some time to look at this. I've double-checked all the new cmath 
testcases against MPFR (via bigfloat), and they all look good. I plan to apply 
this in two stages: (1) apply the new cmath testcases, (2) apply the test_math 
changes, and (1.5) watch for buildbot failures in-between.

--

___
Python tracker 

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

[issue27832] fractions.Fraction with 3 arguments: error passes silently

[Vedran Čačić]

Vedran Čačić added the comment:

Thank you very much! Not only for this fix, but also for restoring my faith in 
Python community. :-)

--

___
Python tracker 

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

[issue27836] VCRUNTIME140.DLL not found

[Chris Wood]

Chris Wood added the comment:

https://www.python.org/downloads/

--

___
Python tracker 

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

[issue27836] VCRUNTIME140.DLL not found

[Steve Dower]

Steve Dower added the comment:

Where did you install Python from?

--

___
Python tracker 

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

[issue2613] inconsistency with bare * in parameter list

[vitorg]

vitorg added the comment:

Here is example where it's necessary, but still raising an error:
>>> def my_method(self, *, **kwargs):
... pass
... 
  File "", line 1
SyntaxError: named arguments must follow bare *

--
nosy: +vitorg

___
Python tracker 

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

[issue27598] Add SizedIterable to collections.abc and typing

[Bar Harel]

Bar Harel added the comment:

I still believe "Reiterable" better demonstrates the concept.

When you request a Reiterable as a function parameter or assert if something is 
a Reiterable the other side knows exactly what you mean.

A "Collection" is way more ambiguous - if you create an object that acts like 
range() but you can cycle over it more than once I wouldn't exactly call it a 
collection. I would though call it a Reiterable and it would be clear for any 
Python programmer familiar with the concept of iterators.

I believe this is a funny case in which the naming is more important than the 
implementation as it will turn into a term or concept that will be further used 
in many places to come.

--
nosy: +bar.harel

___
Python tracker 

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

[issue23229] add inf, nan, infj, nanj to cmath module

[Mark Dickinson]

Changes by Mark Dickinson :


--
stage:  -> commit review
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue27832] fractions.Fraction with 3 arguments: error passes silently

[Mark Dickinson]

Mark Dickinson added the comment:

Fixed.

--
resolution:  -> fixed
stage: patch review -> 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

[issue27832] fractions.Fraction with 3 arguments: error passes silently

[Roundup Robot]

Roundup Robot added the comment:

New changeset ea495a5ded9b by Mark Dickinson in branch 'default':
Issue #27832: Make _normalize parameter to Fraction.__init__ keyword-only.
https://hg.python.org/cpython/rev/ea495a5ded9b

--
nosy: +python-dev

___
Python tracker 

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

[issue27832] fractions.Fraction with 3 arguments: error passes silently

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee:  -> mark.dickinson

___
Python tracker 

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

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[Erik Bray]

Erik Bray added the comment:

The good news about this (in the pthread case) is that it does not need to be 
seen as some workaround for unusual platforms, but rather making the existing 
code more POSIX-compliant (and hence correct).

The Win32 side I'm a little less worried about because the TLS key is 
documented to be a DWORD, and so the existing casting to int should still work 
fine most of the time.  However, the docs for TlsAlloc() 
(https://msdn.microsoft.com/en-us/library/windows/desktop/ms686801(v=vs.85).aspx)
 do state:

> The value of the TLS index should be treated as an opaque value; do not 
> assume that it is an index into a zero-based array.

which again makes #22206 suspect :(

--

___
Python tracker 

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

[issue26040] Improve coverage and rigour of test.test_math

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee:  -> mark.dickinson

___
Python tracker 

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

[issue27841] Use fast call in method_call() and slot_tp_new()

[STINNER Victor]

STINNER Victor added the comment:

> It uses a small buffer allocated on the stack C if the function is called 
> with 4 arguments or less, or it allocates a buffer in the heap memory.

Maybe 4 is too small. On 64 bit, it's just 5*8=40 bytes. Maybe we can use a 
buffer of 10 pointers: 80 bytes? It would optimize calls with up to 9 arguments 
(1 pointer is used for "obj" argument, the "prepended" argument).

--

___
Python tracker 

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

[issue27832] fractions.Fraction with 3 arguments: error passes silently

[Vedran Čačić]

Vedran Čačić added the comment:

As much as Steven's proposal would give me what I want in Py3.6, I must say I'm 
-1 on it. The assumption of every Fraction being reduced to lowest terms is 
really an important invariant that provides numerous opportunities for 
optimization (look at __eq__ for example, second if). I think it would be very 
wrong to have to generalize all the algorithms of Fraction to work correctly 
with non-normalized Fractions.

Furthermore, current (normalized) fractions are Rationals, thus belonging to 
the Python numeric tower. non-normalized fractions are not. Even if we _would_ 
someday have non-normalized fractions in stdlib, they would probably need to be 
named differently. (Currently Decimals are having an opposite problem: the main 
reason why adding decimal literals to Python is hard is because they would 
obviously have to be Reals, thus belonging to numeric tower, while current 
decimal.Decimals do not belong there.:)

[And mediants can be usefully researched if you stay within |Q, too; some of my 
students have done that. Even Wikipedia says (though it doesn't go into 
details):

A way around this, where required, is to specify that both rationals are to 
be represented as fractions in their lowest terms (with c > 0, d > 0). With 
such a restriction, mediant becomes a well-defined binary operation on 
rationals.

from fractions import Fraction
def mediant(p:Fraction, q:Fraction):
return Fraction(p.numerator + q.numerator,
  p.denominator + q.denominator)
]

Now, can we go back to a tiny three-character addition with no disadvantages at 
all (if I'm wrong, please inform me), making Python stdlib a bit better in 
catching accidental mistakes?

--

___
Python tracker 

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

[issue27841] Use fast call in method_call() and slot_tp_new()

[STINNER Victor]

New submission from STINNER Victor:

Attached patch avoids the creation of a temporary tuple in method_call() and 
slot_tp_new() by using the new fast call calling convention.

It uses a small buffer allocated on the stack C if the function is called with 
4 arguments or less, or it allocates a buffer in the heap memory.

The function also avoids INCREF/DECREF: references are borrowed, not strong 
references.

The patch adds a private _PyObject_Call_Preprend() helper function written to 
optimize such way of packing positional arguments, it's like:

   args = (obj,) + args
   func(*args, **kw)

--
files: call_prepend.patch
keywords: patch
messages: 273461
nosy: haypo, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use fast call in method_call() and slot_tp_new()
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44200/call_prepend.patch

___
Python tracker 

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

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[R. David Murray]

R. David Murray added the comment:

I'd say that sounds reasonable, but most likely it will only be someone working 
with one of the impacted platforms who will have the motivation to come up with 
a patch.  Especially since neither of the impacted platforms is current 
formally supported (meaning, we don't yet have anyone on the core team working 
with those platforms).

We have, it seems, arrived at the time that MvL foresaw :)

--
hgrepos: +352
nosy: +r.david.murray
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue27573] code.interact() should print an exit message

[Steven D'Aprano]

Steven D'Aprano added the comment:

On Thu, Aug 18, 2016 at 12:26:56PM +, Armin Rigo wrote:
> ...ah, upon closer inspection, we don't use the ``interact()`` method 
> anyway.  We already copied and tweaked this method: one problem was 
> that it gives no way to run without printing at least one '\n' of 
> banner at the beginning.  Then a more important tweak was made when we 
> added multiline input with `pyrepl` by default.  So feel free to 
> ignore my request.

I think making the exit message configurable is a good idea even if PyPy 
doesn't do it, and it should be an easy few lines, so I'll do it even if 
you don't need it for PyPy.

--

___
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 23-Aug-16 02:01, Martin Panter wrote:
> Martin Panter added the comment:
Thank you for your reply!
>
> I had understood that changing find_library() would only be useful in 
> combination with the automatic RTDL_MEMBER detection.
Adding the RTLD_MEMBER to the mode would be necessary for support of 
native archives. Without it, dlopen() will not work.
If I understand your comments correctly a python programmer could change 
all blocks such as: (please forgive syntax errors, if I make one, I may 
miss a : or the indent might not be straight)

Now:
xxxdl = cdll.LoadLibrary(find_library("xxx"))

Patched:
if sys.platform.startswith("aix"):
 dlname = find_library("xxx")
 if dlname and dlname.endswith(")") and dlname.rfind(".a(") > 0:
 from _ctypes import RTLD_LOCAL, RTLD_GLOBAL
 mode = RTLD_LOCAL | 0x0004
 xxxdl = cdll.LoadLibrary(dlname, mode)
 else if dlname:
 xxxld = cdll.LoadLibrary(dlname)
 else:
 xxxdl = cdll.LoadLibrary(find_library("xxx"))

> If you want to mention lack of support for AIX in the documentation, that is 
> okay by me. If you want to propose an alternative find_library() 
> implementation _without_ affecting the CDLL behaviour, that may be okay too.
I certainly do not want to document lack of support - I would prefer to 
see belated support for AIX. If the code above is all that is acceptable 
for 2.7 then I am still not as happy as I could be - I would rather not 
require all programmers that are still active in Python2 to add a new 
function to replace the default find_library() - as I think rewriting it 
as a private function is more secure than finding and changing every 
call to ctypes.find_library currently in "my" code.
And, of course, the other change would be everywhere where I now import 
ctypes.util would be to import my own function (that would be the only 
place I imports ctypes.
In short, what I hope for is that the "Now:" codeblock above will work asis.
>
> For the libuuid problem, for 2.7 I would suggest adding an explicit call to 
> load libc.a(. . .) or whatever is appropriate.
Again, without also adding the constant 0x0004 adding an explicit 
call to "libc.a(shr.o)" (32-bit mode) or "libc.a(shr_64.o)" is pointless.
And, if you would permit the constant 0x0004 in Lib/uuid.py to make 
those calls work, then why not let it be in Lib/ctypes/__init__.py ?

>
> Personally I don’t have a specific interest in AIX, but I am happy to commit 
> patches for AIX if I think they are sensible. I think I mentioned before in 
> the other bug that your changes seemed okay for the next Python version.
If I recall, I submitted patches but not processed via Mercurial - not 
had the time to learn that.

I see (now) that you have processed them, and set them for review - many 
thanks.

I do not have any specific interest in python. My interest is supporting 
people who want to use python on AIX. And as PEP 373 says Python is 
supported into/until 2020 - it seems reasonable to correct an omission. 
A computer does not care whether the block is "Now:" or "Patched:". But 
I think most python developers would prefer not having to patch all 
their code. Rather, I fear they will say "we cannot/do not support AIX" 
because ... (some politically correct answer to not say AIX support is 
broken).

> The beta deadline for 3.6 is in a few weeks (PEP 494), although after that 
> there is still 3.7.
Again, I submitted something. It probably needs changes. I'll check the 
review. What else is needed for that to be accepted?

If it misses 3.6, then I will have some soul searching to do.
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue27795] Cygwin compile errors

[R. David Murray]

R. David Murray added the comment:

Please deal with specific errors.  As I said there are a number of specific 
reports already, so a generic "it doesn't work" issue is not useful.  If you 
identify a specific issue for which there is not already an open bug report, 
please open a new issue for it with specifics.  Even better if you can suggest 
a solution.

--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue27825] Make the documentation for statistics' data argument clearer.

[Steven D'Aprano]

Changes by Steven D'Aprano :


--
assignee: docs@python -> steven.daprano
nosy: +steven.daprano

___
Python tracker 

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

[issue27840] functools.partial: don't copy keywoard arguments in partial_call()?

[STINNER Victor]

New submission from STINNER Victor:

I justed optimized partial_call() for positional arguments in the change 
c1a698edfa1b to avoid the creation of a temporary tuple when possible.

I noticed that keyword parameters from partial() constructor are always copied. 
Is it mandatory? Can't we avoid copying them?

Example:
---
import functools
hello = functools.partial(print, "Hello World", end='!\n')
hello()
---

hello keyword arguments are {'end'; '!\n'}.

Attached patch avoids copying keyword arguments when the partial objects is not 
called with new keyword arguments.

Tests pass, but I don't know if there is a risk that some strange function 
modify keyword arguments in-place?

--
files: partial_call_kwargs.patch
keywords: patch
messages: 273456
nosy: haypo, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: functools.partial: don't copy keywoard arguments in partial_call()?
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44199/partial_call_kwargs.patch

___
Python tracker 

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

[issue27837] Logging Cookbook Improvement

[Vinay Sajip]

Vinay Sajip added the comment:

I specifically wanted to illustrate a separate listener process - the purpose 
here is not to show what might be the most efficient code, but to show 
communication via a queue between listener process and worker processes. You've 
removed this, which defeats the object of this example (for example, there's no 
QueueListener in your version). So I wouldn't want to implement your proposed 
change in its current form.

Just to clarify, a diff of the cookbook ought to be a diff of the .rst file 
rather than just a changed code example within it - a direct comparison needs 
to be possible in order to see the changes easily in a side-by-side view.

--

___
Python tracker 

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

[issue27832] fractions.Fraction with 3 arguments: error passes silently

[Steven D'Aprano]

Steven D'Aprano added the comment:

At the risk of muddying the waters even further, I'd like to make _normalize a 
public parameter in Python 3.7. There's an interesting operation you can do 
with fractions, the mediant:

https://en.wikipedia.org/wiki/Mediant_%28mathematics%29

http://www.mathteacherctk.com/blog/2011/02/06/mediant-fractions-and-simpsons-paradox/

It's easy to work with mediants provided you have a way to prevent fractions 
from being normalised automatically.

So I'm +1 on making _normalize a keyword-only argument for 3.6 as a first step.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[Erik Bray]

Erik Bray added the comment:

(Of course, maintaining such a list might take some care, but only when 
creating and deleting keys--it wouldn't add any overhead to using them to 
get/set values.)

--

___
Python tracker 

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

[issue27809] _PyObject_FastCall(): add support for keyword arguments

[Roundup Robot]

Roundup Robot added the comment:

New changeset c1a698edfa1b by Victor Stinner in branch 'default':
Issue #27809: partial_call() uses fast call for positional args
https://hg.python.org/cpython/rev/c1a698edfa1b

--

___
Python tracker 

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

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[Erik Bray]

Erik Bray added the comment:

I'm not really sure what "long" has to do with it...

The problem is that the PyThread API uses ints to represent TLS keys, and has 
for about as long as it's existed (maybe what you meant by "long").  But when 
support for native TLS was added (#9786 for pthread, sometime earlier for 
Windows) , the faulty assumption as made in several places that this API (i.e. 
the type of key is "int") should always map perfectly onto native APIs, and it 
doesn't.

There are several places for example where an int key is passed to 
pthread_getspecific and pthread_setspecific 
(http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_getspecific.html).
  On Linux the compiler happens to allow this because pthread_key_t is defined 
as "unsigned int"  So yeah there's an implicit cast, but since it counts up 
from zero it usually works.  Likewise TlsAlloc on Windows expects the key to be 
a DWORD but the compiler will accept an int.

This is really an unsafe assumption though, especially when PyThread_create_key 
casts the key to an int, and later reuses the (possibly not safely cast) key 
with PyThread_delete_key/get_key_value/set_key_value).  This was brought up at 
the time, where MvL wrote:

> In principle, this is really difficult to get right. AFAICT,
pthread_key_t doesn't even have to be an integral type, and even
if it is, it may well become -1. However, we can probably worry
about this when a system comes along where this implementation
breaks.

One possible workaround without changing the existing API would be this:  Each 
native support wrapper should also provide a *safe* mapping between its native 
key types and ints, to support the PyThread API.

For example, the pthread interface could maintain a linked list or an even an 
array of pthread_key_t pointers, and use the int "key" as the index into that 
list.  If I understand correctly this should be basically harmless since the 
same key (and hence key -> native-key mapping) can be shared across threads.

--

___
Python tracker 

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

[issue27795] Cygwin compile errors

[Kaeptm Blaubaer]

Kaeptm Blaubaer added the comment:

If I run cygwin 32 bit and self-compiled 32 bit python or _freeze_importlib on 
a 64 bit computer, I'm getting a Fatal Python error.

--

___
Python tracker 

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

[issue27795] Cygwin compile errors

[Kaeptm Blaubaer]

Kaeptm Blaubaer added the comment:

I can configure only after I have run autoconf and autoheader, then I can 
configure it without args, then when you run make you can see specific errors.

--
resolution: duplicate -> 
status: closed -> open

___
Python tracker 

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