[issue26993] Copy idlelib *.py files with new names

[Terry J. Reedy]

Terry J. Reedy added the comment:

In response to 1.  I considered copying idlelib as a whole as a serious 
possibility, meant to include it as an alternative, and am willing to 
reconsider my choice.  I specifically thought of something like idlelib3 or 
idlelib/idle3, but not _idlelib,  A complete copy in a new directory would be, 
as you say, a cleaner separation but it seemed like it would make import 
changes and startup more complicated.  It is also not obviously covered by PEP 
434 -- unless you say so.

For users, making idle2 the copy would immediately break current external 
imports.  Making idle3 the copy would break new external imports sometime in 
the future.  But using _idlelib would warn of that possibility.

For importat, IDLE itself uses uses all of 'from idlelib import module', 'from 
idlelib.module import callable', 'from idlelib.idle_test.htest import run', and 
unittest.main('idlelib.idle_test.test_module' (but no relative imports).  A new 
directory would greatly increase the number of changes and mean changing 
'idlelib' to 'something' now and 'something' back to 'idlelib' in the future.

I thought of using relative imports, but I have not used them and have read 
that they are limited, tricky, and discouraged.  I just did some experiments 
and it seems that they do not work when a file is run as __main__ instead of 
imported.  (Whatever the limitation, it is not obvious to me from the doc.)

I agree with 2. and 3. and will response to 4. in another message.

--

___
Python tracker 

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

[issue26857] gethostbyname_r() is broken on android

[Xavier de Gaye]

Xavier de Gaye added the comment:

gethostbyaddr_r() is implemented now on Android 6.0 (API 23). The attached 
patch has been tested on the android-21-x86 emulator (API 21) and 
android-23-x86 emulator (API 23). No new NDK has been released at Android 5.1 
(API 22) so there is no need to test the patch for this release.

--
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file42809/socketmodule_2.patch

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

[Martin Panter]

Martin Panter added the comment:

Patches: I’m not sure, but maybe it would help the Reitveld review system if 
the src/ directory in them was eliminated (e.g. src/Python-3.5.1 vs just 
Python-3.5.1). Also, if you are using Gnu diff, maybe you can try the -N 
(--new-file) option to include aixutil.py in the diff, and -x (--exclude) 
__pycache__ to avoid that directory.

Personally, I would find patches a lot easier to handle than a tar file, 
especially if I cannot figure out which bits of the tar file are original code 
and which are changed code.

It seems you want to CDLL() to accept names using the Linux/BSD libFOO.so.N 
convention, but load an AIX library with a related name. This sounds like a bad 
design to me, for multiple reasons. I would like to hear other people’s 
opinions before going in that direction.

This is my understanding of the CDLL() calls currently needed to load the Open 
SSL library on various platforms:

openssl 1.0.2.g-3 package on Arch Linux: CDLL("libcrypto.so.1.0.0")
Windows: CDLL("libeay32.dll")
OS X (Darwin): CDLL("libcrypto.1.0.0.dylib")
FreeBSD: CDLL("libcrypto.so.8")
AIX: CDLL("libcrypto.a(libcrypto.so.1.0.0)", DEFAULT_MODE | RTLD_MEMBER)

--

___
Python tracker 

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

[issue26993] Copy idlelib *.py files with new names

[Nick Coghlan]

Nick Coghlan added the comment:

Terry, have you considered also doing a top level idlelib -> _idlelib rename in 
addition to the file level name changes?

My rationale for suggesting that:

1. The idle2 vs idle3 distinction will be clear at a glance (as they'll be in 
different directories)
2. The package level rename handles bifurcation of files that aren't themselves 
being renamed
3. You can subsequently iterate on the internal APIs without worrying about 
third party breakage
4. You set the stage for eventually moving IDLE to being an independently 
versioned implicitly pip-installed component (perhaps with an 
"ensure_default_ide" module akin to "ensurepip")

In relation to that last point, while I think it's important for CPython to 
come with a default IDE, I *don't* think it's important for the Python standard 
library to provide a default IDE-building toolkit (and, indeed, Linux distros 
tend to separate out not only IDLE, but also Tcl/Tk support in general, from 
the default Python installation).

--

___
Python tracker 

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

[issue26977] Unnecessary line in statistics.pvariance

[Roundup Robot]

Roundup Robot added the comment:

New changeset 87130512ef34 by Steven D'Aprano in branch '3.5':
NEWS message for issue #26977.
https://hg.python.org/cpython/rev/87130512ef34

New changeset 39faad3cd626 by Steven D'Aprano in branch 'default':
Merge NEWS update from 3.5 for issue #26977.
https://hg.python.org/cpython/rev/39faad3cd626

--

___
Python tracker 

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

[issue26996] Add secrets module as per PEP 506.

[Steven D'Aprano]

Changes by Steven D'Aprano :


--
resolution:  -> fixed
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

[issue26996] Add secrets module as per PEP 506.

[Steven D'Aprano]

New submission from Steven D'Aprano:

(This is already done, but I should have added a ticket before committing the 
new module.)

See PEP-0506.

--
assignee: steven.daprano
components: Library (Lib)
messages: 265288
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Add secrets module as per PEP 506.
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

[issue26977] Unnecessary line in statistics.pvariance

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6f27dbc55f10 by Steven D'Aprano in branch '3.5':
Issue 26977, remove unneeded line in pvariance (duplicate call to _ss).
https://hg.python.org/cpython/rev/6f27dbc55f10

New changeset 3c75707045f5 by Steven D'Aprano in branch 'default':
Branch merge for issue 26977
https://hg.python.org/cpython/rev/3c75707045f5

--

___
Python tracker 

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

[issue24194] tokenize yield an ERRORTOKEN if an identifier uses Other_ID_Start or Other_ID_Continue

[Meador Inge]

Meador Inge added the comment:

Attached is a first cut patch for this.  (CC'd haypo as a unicode expert).

--
assignee:  -> meador.inge
keywords: +patch
nosy: +haypo, meador.inge
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42808/issue24194-v0.patch

___
Python tracker 

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

[issue26647] ceval: use Wordcode, 16-bit bytecode

[Demur Rumed]

Demur Rumed added the comment:

I've been waiting on storchaka to finish code reviewing peephole based on his 
statement of 'Reviewing peephole.c still is not completed.' before uploading a 
patch which addresses the issues raised since

--

___
Python tracker 

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

[issue26994] unexpected behavior for booleans in argparse

[R. David Murray]

R. David Murray added the comment:

Yes, it is an unitended consequence of the fact that argparse types are 
arbitrary single argument functions (that take an arbitrary string as the 
argument and convert it), and bool is a single argument function.  
Unfortunately we're stuck with it now.  The correct answer, of course, is to 
write your own bool type converter if you need one.

It is possible there should be a documentation mention that bool is not 
approprate as a type function, since int and float, for example, are explicitly 
mentioned.  If you want to submit a patch to that end I'll reopen the issue.

--

___
Python tracker 

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

[issue21099] Switch applicable importlib tests to use PEP 451 API

[Brett Cannon]

Brett Cannon added the comment:

I'll try to get to it today or tomorrow.

--

___
Python tracker 

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

[issue21099] Switch applicable importlib tests to use PEP 451 API

[Eric Snow]

Eric Snow added the comment:

Could I get a quick review on this.  There shouldn't be anything surprising or 
controversial here.  I'm pretty confident about the patch and it's pretty 
low-impact so if I don't hear back in the next day or two I'll merge it.

Note: the posted patch does not apply cleanly but the difference is cosmetic.

--

___
Python tracker 

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

[issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux

[Michael Felt]

Michael Felt added the comment:

In https://bugs.python.org/issue26439 I have been working on this for AIX - as 
the default behavior was to depend on two things:
a) ldconfig -p (which generally does not exist on AIX, and I doubt it will know 
about the non-gnu libraries
b) that the objects are files rather than members of an archive

For python cdll() to work (as find_library generally did not) - the work-around 
was to extract archive members into standard directories and/or hard-code 
unique AIX names. But again, always as files, as CDLL did not modify the 
dlopen() mode to permit loading a shared library from an archive.

re: this issue and behavioral differences between find_library and cdll() 
(rather dlopen()) searches - a linker is different from a dlopen. When 
compiling an argument such as -lc -- on AIX -- tells the linker to look in 
libc.a for any member (of the right size) that satisfies an unknown symbol. 
That archive (base) and member (member) name is remembered in the "loader 
section" during linking. Note that static members have no loader section of 
their own, nor do they add one to the object (program or shared library) being 
linked.
As a compatibility feature - when a member is not found in an archive the AIX 
rtl (run-time-linker) also looks for a file named libFOO.so (e.g., libc.so) - 
this grace behavior is why CDLL() has worked somewhat using default behavior in 
Lib/ctypes.

As to LD_LIBRARY_PATH and LIBPATH. In AIX terms, these are environment 
variables to supplement the library search path - only when no PATH information 
is provided (i.e., cdll("./libc.so") will only look in the current directory of 
the process, and only for the file libc.so)
The default search path is a list of the directories used to link the 
executable (e.g., python). For me that list is: 
***Import File Strings***
INDEX  PATH  BASEMEMBER
0  /usr/vac/lib:/usr/lib:/lib

In other words, python, by default, is only going to look in very standard 
locations - even though it knows it's prefix is not /usr.

There are two solutions - and I will make changes as appropriate.
a) automate setting an environment variable if it is not already set to 
something like 
 _os.environ['LIBPATH'] = "%s/lib" % _sys.prefix
and not something "arbitrary" such as /usr/local/lib
b) modify the LDFLAGS when packaging to include
-L${prefix}/lib which will have the effect of changing the default search path 
via -W,-blibpath=/usr/vac/lib:/usr/lib:/lib:${prefix}/lib


In any case, in my patch for AIX in ctypes the two will work identical (cdll() 
even calls aix.find_library() to simplify portability between GNU/posix 
environments that expect or support only filenames to work with AIX archive 
packaging.

My apologies for the wall of text. This is not a simple subject.

--
nosy: +Michael.Felt

___
Python tracker 

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

[issue19711] add test for changed portions after reloading a namespace package

[Eric Snow]

Eric Snow added the comment:

I've gone ahead and pushed the patch.

--
resolution:  -> fixed
stage: test needed -> 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

[issue19711] add test for changed portions after reloading a namespace package

[Roundup Robot]

Roundup Robot added the comment:

New changeset c22ec7a45114 by Eric Snow in branch 'default':
Fixes #19711: Add tests for reloading namespace packages.
https://hg.python.org/cpython/rev/c22ec7a45114

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

[aixtools]

aixtools added the comment:

On 5/8/2016 8:29 AM, Martin Panter wrote:
> Martin Panter added the comment:
>
> Your new patch calls find_library() internally in CDLL(); why?
Because arguments that work for GNU (aka Linux, even though internally 
it is called "posix") will not work for AIX.
> My understanding is CDLL() is a fairly lightweight wrapper around the 
> dlopen() call.
For AIX, the dlopen() call is a front-end for the function 
initAndLoad(). I have not looked in depth at Module/_ctypes (only 
recently found it) and I do not know how much work is being done there 
for the different platforms.
> On Linux, you either pass a full library file name, or an SO-name.
Same for AIX: a full-path library name, relative-path library name, or a 
library name and the library search path (with optional additional 
directories provided via environment variables (LIBPATH or 
LD_LIBRARY_PATH - when it is a FILE, or an archive(member_name) (with 
archive part being full or relative, or stem) and RTLD_MEMBER ORed into 
the mode argument.
> Both these strings can be discovered for compiled objects using e.g.:
Likewise for AIX: - example: an executable - notice how many are named 
shr.o: how is cdll("shr.o") suppossed to know it is libc, or is it libcrypt?

root@x064:[/usr/lib]ldd /usr/sbin/sshd
/usr/sbin/sshd needs:
  /usr/lib/libc.a(shr.o)
  /usr/lib/libcrypto.a(libcrypto.so.1.0.0)
  /usr/lib/libz.a(libz.so.1)
  /usr/lib/libpam.a(shr.o)
  /usr/lib/libdl.a(shr.o)
  /unix
  /usr/lib/libcrypt.a(shr.o)
  /usr/lib/libpthreads.a(shr_xpg5.o)
  /usr/lib/libpthreads.a(shr_comm.o)

Or a file:
./perl-5.14.4/lib/5.14.4/aix-thread-multi-64int/auto/B/B.so needs:
  /usr/lib/libpthreads.a(shr_xpg5.o)
  /usr/lib/libc.a(shr.o)
  /unix
  /usr/lib/libpthreads.a(shr_comm.o)
  /usr/lib/libcrypt.a(shr.o)

Again, cdll("shr.o") is not going to find the correct archive.
> $ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so
>   linux-vdso.so.1 (0x7fff567fe000)
>   libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x7f598474c000)
>   libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x7f59842d4000)
>   . . .
>
> So in Python, the SO-name or full path can be used, but not the compile-time 
> name, unless you first pass it through find_library():

 CDLL("libcrypto.so.1.0.0")  # soname
> 
 CDLL("/usr/lib/libcrypto.so.1.0.0")  # Full path
> 
 CDLL("crypto")  # Compile-time name
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
>  self._handle = _dlopen(self._name, mode)
> OSError: crypto: cannot open shared object file: No such file or directory
 find_library("crypto")  # Some people pass the result of this to CDLL()
> 'libcrypto.so.1.0.0'
Thank you for the explanation of what should be used when. Maybe I 
worked too hard for the current result: (note - 64-bit this time! and 
new member names, even for libc.so)

michael@x071:[/usr/lib]python -m ctypes.util
None
libc.a(shr_64.o)
None
aix.find_library("libiconv.so") libiconv.a(shr4_64.o)
aix.find_library("libintl.so") libintl.a(libintl.so.1)
aix.find_library("libintl.so.1") libintl.a(libintl.so.1)
aix.find_library("libintl.so.2") None :: should be None!
aix.find_library("libintl.so.8") None



libcrypt.a(shr_64.o)

Back to Why though.

Ease of use, and portability with existing convention. My experience 
with just two python packages I wanted to port is that cdll("libFOO.so") 
is what is used, and works on GNU. I wanted that to work ASIS. I also 
noticed that sometimes code was explicit about the version (sometimes 
the latest was not right, and the code complained). So, since "short" 
names are preferred, and are portable - those are what programmers tend 
to use. Full-path-names imply an assumption.

dlopen() is not going to know that libc.so is actually libc.a(shr.o) - 
so I call find_library() for portability aka Ease of Use. While it may 
be slightly less performance I am hoping (assuming) cdll("foo") is not 
the most central part of any application - and the overhead is acceptable.

And thanks for the question. It is simple enough to remove now, should 
it be considered a sin.

> --
>
> ___
> Python tracker 
> 
> ___

--
nosy: +aixto...@gmail.com

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Yury Selivanov]

Yury Selivanov added the comment:

> If I understood it correctly, get_event_loop() would never return "default" 
> event loop (in terms of current implementation) for a running task, because 
> it always be overridden with "running" event loop. If it's so, are you sure 
> it won't raise any problems with backward compatibility?

I think this is extremely unlikely.  I hope that there is not much code out 
there that relies on this behaviour.  But you have a point.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

Ilya Kulakov added the comment:

Yury, 

> `get_event_loop()` will then try to use the `running_loop` object first, and 
> if nothing is there, fall back to its current implementation.

Do you think hiding "default" event loop completly from a currently executing 
coroutine is safe?

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

Ilya Kulakov added the comment:

Yury,

> Not sure I understand the question.

If I understood it correctly, get_event_loop() would never return "default" 
event loop (in terms of current implementation) for a running task, because it 
always be overridden with "running" event loop. If it's so, are you sure it 
won't raise any problems with backward compatibility?

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Yury Selivanov]

Yury Selivanov added the comment:

> Do you think hiding "default" event loop completly from a currently executing 
> coroutine is safe?

Not sure I understand the question.  Anyways, let's see what Guido thinks about 
this all.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Yury Selivanov]

Yury Selivanov added the comment:

>> I now think that we don't need a new function for getting the currently 
>> running event loop.

> May I ask you to elaborate on this?

In my last message I propose to modify 'get_event_loop' to return the running 
loop reliably.  To me this is to me the most important thing -- this will make 
things like Task.current more reliable.

Adding another function (get_running_loop) won't change much. It would have a 
slightly different behaviour, but likely it won't be used anywhere in asyncio, 
or other libraries.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

Ilya Kulakov added the comment:

Yury,

> I now think that we don't need a new function for getting the currently 
> running event loop.

May I ask you to elaborate on this? Asynchronous API I'm aware of (including  
other languages) typically allows to get "main" (which in asyncio is lazily 
created for main thread only), and "current". Sometimes there is also a 
convenient "global" which can be used when you want to do some async work 
outside. E.g. take a look at public API of Apple's Grand Central Dispatch, 
specifically `dispatch_get_current_queue`.

Even Python's thread module allows to get "current_thread" instead of passing 
it into run callback and requiring a user to carry it around by hand.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

Ilya Kulakov added the comment:

> TBH, I don't fully understand Ilya's case with threads, synchronous 
> coroutines, possible deadlocks etc.

I feel sorry for sharing that example. It didn't help and made my points 
regarding original issue unclear, hidden behind example's complexity.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Yury Selivanov]

Yury Selivanov added the comment:

> Yury, what do you think of this yourself? Maybe you can explain it better
than Ilya?

TBH, I don't fully understand Ilya's case with threads, synchronous coroutines, 
possible deadlocks etc.  So I'll just explain what I would want out of this.

I don't like a few aspects of the current design of 'get_event_loop'.  Mainly 
because it creates an event loop implicitly, or it can just fail with a 
RuntimeError under some conditions.  When one has a few event loops, implicitly 
called 'get_event_loop' from Future and other asyncio functions won't work 
correctly.  IMO, this is something that we at least should try to fix (even 
though it's not an idiomatic use case for asyncio).

I now think that we don't need a new function for getting the currently running 
event loop.  Instead we can try to improve the `get_event_loop()` function a 
little.

The core idea is to add a thread-local object `running_loop`, which will point 
to the currently running event loop in the current thread.  And `Loop._run` 
method will set/reset a reference to the loop to `running_loop`.

`get_event_loop()` will then try to use the `running_loop` object first, and if 
nothing is there, fall back to its current implementation.

Now, this is a point where everything becomes complicated. To quote 
myself,--"Yes, the patch part is easy",--I don't think it is that easy anymore 
;)

Currently, event loops are decoupled from policies.  This means that we can't 
make loops to use some hidden shared thread-local object (`running_loop`) that 
policies and loops will work with.  There has to be another new public policy 
APIs that loops will use, for instance: 'set_running_event_loop()'.  This won't 
be the first case of event loop policy APIs being called from event loops -- 
another example is the `get_child_watcher` method.

With this new method, `Loop._run` will then look like this:

  def _run(self):
  policy = get_event_loop_policy()
  policy.set_running_event_loop(self)
  try:
 ... # current Loop._run implementation
  finally:
  policy.set_running_event_loop(None)

`policy.set_running_event_loop` call would raise a RuntimeError if it's called 
if another event loop is currently running.

And the `get_event_loop()` function will look like this:

  def get_event_loop():
  policy = get_event_loop_policy()
  loop = policy._get_running_event_loop()
  if loop is not None:
  return loop
  # ... current get_event_loop implementation

So it all boils down to:

1. Adding a new policy API 'set_running_event_loop'.

2. Updating 'get_event_loop' to return the currently running event loop if it's 
available, or else resorting to its current behaviour.

With this change it will be completely safe to use "get_event_loop" from 
running coroutines or just about any code that runs in a context of an event 
loop.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Guido van Rossum]

Guido van Rossum added the comment:

As long as there are still things you find confusing about asyncio's model,
you should probably consider yourself unqualified to start proposing new
features...

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

Ilya Kulakov added the comment:

Yury, we're building our own CPython anyway (and we just updated to 3.5.1). I'd 
be glad to test the patch during the next iteration.

Guido, I think my use case mixes up other things I find confusing about 
asyncio: e.g. inablitity to synchronously perform code written as standalone 
coroutine. It deserves its own task and discussion.

The purpose of this request is that access to a running loop is handy within 
coroutine. It's already there, since coroutine is executed within its context. 
However, instead of "self" library provides API to only access some globally 
default loop.

Python does not require a user to pass self whenever instance methods needs to 
be called. I consider relationship between event loop and awaitables alike.

--

___
Python tracker 

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

[issue26983] float() can return not exact float instance

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Proposed patch makes float() always returning exact float.

--
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file42807/float_exact.patch

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Guido van Rossum]

Guido van Rossum added the comment:

Yury, what do you think of this yourself? Maybe you can explain it better
than Ilya?

--

___
Python tracker 

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

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

Suddha: Someone has to write a currently failing test and a patch that makes it 
pass without breaking anything else.  I cannot currently test this issue and 
therefore cannot currently patch it.  AutoComplete has numerous other issues 
that I can test.  About a month ago, I reviewed the code with an eye to fixing 
them.  I decided what I implied above, which is that I should not do anything 
until I can freely modify the code.  I just filed #26993 to make that possible.

Paul: For testing CPython in general, see https://docs.python.org/devguide/, 
chapter 4 and 5 (and the unittest docs).  For testing IDLE, see test/test_idle 
and idlelib/idle_test, in particular README and htest.py.  The latter is 
specific to IDLE.  If #26993 is approved, we will need LOTS of new tests for 
IDLE, as I want to properly follow the *written* failing test, write patch, 
passing test paradigm.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Yury Selivanov]

Yury Selivanov added the comment:

Ilya, at this point I'd suggest you to craft a very clear and simple to digest 
email to python-ideas describing 'get_running_loop()', how it can be used, your 
case, other cases, etc.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Guido van Rossum]

Guido van Rossum added the comment:

Still no green light. Ilya just seems to want something misguided.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Yury Selivanov]

Yury Selivanov added the comment:

> Yury, could you submit a patch implements this feature?

Yes, the patch part is easy. The hard part is to get a green light from Guido 
on adding the 'get_running_loop()' function...

--

___
Python tracker 

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

[issue26995] Add tests for parsing float and object arguments

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Proposed patch adds tests for direct testing argument parsing C API with format 
units "f", "d", "D" (float, double, complex) and "S", "Y", "U" (PyObject* of 
type bytes, bytearray and str).

--
components: Tests
files: test_getargs_floats_objects.patch
keywords: patch
messages: 265261
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add tests for parsing float and object arguments
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42806/test_getargs_floats_objects.patch

___
Python tracker 

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

[issue26994] unexpected behavior for booleans in argparse

[Nathan Naze]

Nathan Naze added the comment:

I also buy the argument that changing the behavior now would be problematic 
given the existing usages in the wild.

--

___
Python tracker 

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

[issue26994] unexpected behavior for booleans in argparse

[Nathan Naze]

Nathan Naze added the comment:

> It does 'bool(value)', and 'bool("False")' is True, since "False" is a 
> non-empty string.

Yes, I understand this. It's fine to mark as "working as intended", but coming 
from other flag-parsing libraries, I find the behavior unintuitive and do not 
understand the utility of accepting arbitrary strings given the  potential for 
user confusion. We uncovered this behavior debugging a script used internally 
at Google.

--

___
Python tracker 

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

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

[Ilya Kulakov]

Ilya Kulakov added the comment:

Yury, could you submit a patch implements this feature?

--

___
Python tracker 

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

[issue26994] unexpected behavior for booleans in argparse

[R. David Murray]

R. David Murray added the comment:

type=bool doesn't do what you think it does.  It does 'bool(value)', and 
'bool("False")' is True, since "False" is a non-empty string.

See issue 21208 for some further discussion.

--
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Change default behavior of arguments with type bool when 
options are specified

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

Changes by Michael Felt :


Added file: 
http://bugs.python.org/file42805/Python3.Modules._ctypes.160510.patch

___
Python tracker 

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

[issue26994] unexpected behavior for booleans in argparse

[Nathan Naze]

New submission from Nathan Naze:

Setting a boolean type in argparse gives unexpected behavior when setting 
"True", "False", etc.

https://gist.github.com/nanaze/db63e3f63e318408e3223bf1245d9752

Would have expected parsing to fail for unclear input that doesn't neatly map 
to a boolean value.

--
components: Library (Lib)
messages: 265256
nosy: Nathan Naze
priority: normal
severity: normal
status: open
title: unexpected behavior for booleans in argparse
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

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

[Michael Felt]

Changes by Michael Felt :


Added file: http://bugs.python.org/file42804/Python3.Lib.ctypes.160510.patch

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

Changes by Michael Felt :


Added file: 
http://bugs.python.org/file42803/Python2.Modules._ctypes.160510.patch

___
Python tracker 

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

[issue24225] Idlelib: changing file names

[Terry J. Reedy]

Terry J. Reedy added the comment:

Alternate proposal is #26993.

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

[issue26993] Copy idlelib *.py files with new names

[Terry J. Reedy]

New submission from Terry J. Reedy:

Proposal: duplicate nearly all of the existing idlelib *.py files, with new 
names.  This would implement the intention of PEP 434 with respect to freely 
changing idlelib APIs.  I view it as a prerequisite for most anticipated 
patches.  A longer than usual explanation follows.

Last August/September, I realized that the way to modernize and improve IDLE, 
while maintaining backward compatibility, would be to add copies of existing 
.py files.  The copies with new names (the idle3 set) could be freely edited  
while existing files (the idle2 set) could be pretty much left alone until 
deleted.  IDLE would temporarily, for a time yet to be decided, have two 
operating modes.  The idle2 mode would only use exiting files and tk widgets.  
The idle3 mode would use new files and ttk widgets.

Renaming and refactoring files, including PEP 8 updates, is needed for bug 
fixing, testing, and feature upgrades, including addition of a single window 
multiple pane design.  However, doing so with existing files would break direct 
imports and subsequent calls (see #24225, for some discussion).  Ttk widgets 
cannot be used on systems with tcl/tk 8.4. (This and related issues was 
discussed with Nick, Ned, and release managers, as well as in #24759, 
especially msg247993 & msg248031, and in #24750).

I originally planned to add new files one or a few at a time.  I did not start 
doing do immediately, before the November-December releases, because I wanted 
to fix some bugs in the existing files before they were bifurcated. I did not 
start doing so after the releases because I could not figure out how to safely 
manage an 'idle3/ttk' mode that mixed a shrinking subset of idle2 files and the 
growing set of new idle3 files.  It seemed like a recipe for introducing bugs.  
I decided instead that the best solution would be to create a complete, tested 
idle3 set all at once, using the following steps.  (Idlelib/idle_test/*.py 
files will be handled similarly, but with differences discussed later.)

0. Decide on the new names.
1. Copy idlelib/*.py files and hg add them.
2. Revise imports in new idle3 files.
3. Test to make sure that the idle3 set works right. 
4. Upload patch for review, and commit.

Possible variation: push after step 1, so that the revisions in step 2 are a 
separate patch instead of being folded into a combined patch.  I do not propose 
that because the new files would be useless until revised.


DETAILS OF CURRENT PLAN:

0. @newnames.txt, https://bugs.python.org/file42678/%40newnames.txt is attached 
to issue #24225.  It lists old name, Sweigart's new name, and my current new 
name.  Bikeshedding names can be done on that issue.

Leaving aside the unused and deprecated 'idlever' and the startup files, all of 
which are omitted from the list, there are currently three short lowercase 
names: 'help', 'rpc', and 'run'.  To reuse these names for the idle3 set, these 
could be renamed, in a preliminary patch, to have a captital letter.  I think 
this should be okay because  'help' specifies that is it subject to change, and 
the other two are extremely unlikely to be used outside of IDLE.  If this were 
done, implementation files could be identified as 'idle2' versus 'idle3' by the 
presence of an uppercase letter in the name.

Serhiy requested on #24225 that renames of existing 3.5 files be backported to 
2.7.  Since I do not anticipate many patches to idle2 files, let alone 
backports to 2.7, I am not sure that this is needed.

Alternatively, I could name the copies help3, rpc3, and run3.

1. Use the name list from step 0 to create copyall.bat, to be run in the 3.5 
repository idlelib directory.  It will have 'copy src dst' for each file and 
end with 'hg add ../idlelib' (or 'cd ..; hg add idlelib') to 'add' them all.  I 
am aware of 'hg copy', but the docs are not clear on whether there is any 
lingering effect after pushing the adds.  The pre-commit merge effect seems 
unneeded as no one else is pushing idlelib commits (except Serhiy ocassionally, 
as part of multifile patches, and he should be reading this ;-).

2. Review Al Sweigart's 'idle_updating_imports.patch' from #24225.  Al ran 
revised unittests, but the coverage is too spotty to adequately test.  So 
review is needed.

The tricky part is that many modules and classes have the same name, such as 
AutoComplete the module and AutoComplete the class.  Module references must be 
changed to the new name; class references must not be touched.  I would use 
IDLE's File in Files (grep) with each module name to find references to check.  
The import in each client module ('import X' versus 'from X import X' 
determines how bare 'X' is used in rest of the module.

If the patch seems correct, or mostly so, perhaps after a few corrections,  
write a script, using the step 0 name list, to replace Al's new names with my 
new names, where they are different.

Apply the patch.  Since Al's patch is a year old, some chunks w

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

[Michael Felt]

Changes by Michael Felt :


Added file: http://bugs.python.org/file42802/Python2.Lib.ctypes.160510.patch

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

Spent more time today, testing - on 3.5.1, 3.4.4 and 2.7.11.

The patches would not apply on both Python2 and Python3, but the new file 
Lib/ctypes/aixutil.py is identical on all three versions.

History of patching (starting from version 3.5.1(.1) is my patched version (as 
are Python-3.4.4.1 and Python-2.7.11.4)

michael@x071:[/data/prj/aixtools/python/python-3.4.4.1]for i in 
../*patches/*patch^Jdo^Jcat $i | patch -p1 ^Jdone
patching file Lib/ctypes/__init__.py
Hunk #1 succeeded at 341 (offset 4 lines).
patching file Lib/ctypes/test/test_loading.py
patching file Lib/ctypes/util.py
Hunk #1 succeeded at 70 (offset -6 lines).
Hunk #2 succeeded at 256 (offset -6 lines).
Hunk #3 succeeded at 275 (offset -6 lines).
patching file Modules/_ctypes/_ctypes.c
Hunk #1 succeeded at 5508 (offset -1 lines).
michael@x071:[/data/prj/aixtools/python/python-3.4.4.1]

But, not with 2.7.11

michael@x071:[/data/prj/aixtools/python/python-2.7.11.4]for i in 
../*patches/*patch^Jdo^Jcat $i | patch -p1 --dry-run^Jdone
patching file Lib/ctypes/__init__.py
Hunk #1 succeeded at 355 (offset 18 lines).
patching file Lib/ctypes/test/test_loading.py
Hunk #1 succeeded at 38 (offset -5 lines).
patching file Lib/ctypes/util.py
Hunk #1 succeeded at 71 (offset -5 lines).
Hunk #2 FAILED at 262.
Hunk #3 FAILED at 274.
2 out of 3 hunks FAILED -- saving rejects to file Lib/ctypes/util.py.rej
patching file Modules/_ctypes/_ctypes.c
Hunk #1 FAILED at 5509.
1 out of 1 hunk FAILED -- saving rejects to file Modules/_ctypes/_ctypes.c.rej

So, I made new patches against 2.7.11 after patching manually.

After the builds:

==
aixtools.python:aixtools.python.man.en_US:2.7.11.4::I:T:N:man pages0::
aixtools.python:aixtools.python.rte:2.7.11.4::I:T:N:built 10-May-2016 1810 
UTC0::
==
root@x064:[/data/prj/aixtools/python/python-2.7.11.4]cd Lib/ctypes
root@x064:[/data/prj/aixtools/python/python-2.7.11.4/Lib/ctypes]../../python 
util.py
None
libc.a(shr.o)
libbz2.a(libbz2.so)
('aix.find_library("libiconv.so")', 'libiconv.a(shr4.o)')
('aix.find_library("libintl.so")', 'libintl.a(libintl.so.1)')
('aix.find_library("libintl.so.1")', 'libintl.a(libintl.so.1)')
('aix.find_library("libintl.so.2")', None, ':: should be None!')
('aix.find_library("libintl.so.8")', None)



libcrypt.a(shr.o)
root@x064:[/data/prj/aixtools/python/python-2.7.11.4/Lib/ctypes]../../python 
test/test_loading.py
libc_name is libc.a(shr.o)
ss..sss
--
Ran 7 tests in 0.189s

OK (skipped=5)

==
aixtools.python:aixtools.python.man.en_US:3.4.4.1::I:T:N:man pages0::
aixtools.python:aixtools.python.rte:3.4.4.1::I:T:N:built 10-May-2016 1812 
UTC0::
==
root@x064:[/data/prj/aixtools/python/python-3.4.4.1]cd Lib/ctypes
root@x064:[/data/prj/aixtools/python/python-3.4.4.1/Lib/ctypes]../../python 
util.py
None
libc.a(shr.o)
libbz2.a(libbz2.so)
aix.find_library("libiconv.so") libiconv.a(shr4.o)
aix.find_library("libintl.so") libintl.a(libintl.so.1)
aix.find_library("libintl.so.1") libintl.a(libintl.so.1)
aix.find_library("libintl.so.2") None :: should be None!
aix.find_library("libintl.so.8") None



libcrypt.a(shr.o)
root@x064:[/data/prj/aixtools/python/python-3.4.4.1/Lib/ctypes]../../python 
test/test_loading.py
libc_name is libc.a(shr.o)
ss..sss
--
Ran 7 tests in 0.323s

OK (skipped=5)

root@x064:[/data/prj/aixtools/python/python-3.5.1.1]installp -d . -L
aixtools.python:aixtools.python.man.en_US:3.5.1.0::I:T:N:man pages0::
aixtools.python:aixtools.python.man.en_US:3.5.1.1::I:T:N:man pages0::
aixtools.python:aixtools.python.rte:3.5.1.0::I:T:N:built 03-Mar-2016 0856 
UTC0::
aixtools.python:aixtools.python.rte:3.5.1.1::I:T:N:built 10-May-2016 1620 
UTC0::

And, with a 64-bit build

root@x064:[/data/prj/aixtools/python/python-3.5.1.1]installp -d . -L
aixtools.python:aixtools.python.man.en_US:3.5.1.0::I:T:N:man pages0::
aixtools.python:aixtools.python.man.en_US:3.5.1.1::I:T:N:man pages0::
aixtools.python:aixtools.python.rte:3.5.1.0::I:T:N:built 03-Mar-2016 0856 
UTC0::
aixtools.python:aixtools.python.rte:3.5.1.1::I:T:N:built 10-May-2016 1620 
UTC0::
root@x064:[/data/prj/aixtools/python/python-3.5.1.1]cd lib/ctypes
ksh: lib/ctypes:  not found.
root@x064:[/data/prj/aixtools/python/python-3.5.1.1]cd Lib/ctypes
root@x064:[/data/prj/aixtools/python/python-3.5.1.1/Lib/ctypes]../../python 
util.py
None
libc.a(shr_64.o)
None
aix.find_library("libiconv.so") libiconv.a(shr4_64.o)
aix.find_library("libintl.so") libintl.a(libintl.so.1)
aix.find_library("libintl.so.1") libintl.a(libintl.so.1)
aix.find_library("libintl.so.2") None :: should be None!
aix.find_library("libintl.so.8") None



libcrypt.a(shr_64.o)
root@x064:[/data/prj/aixtools/python/python-

[issue14209] pkgutil.iter_zipimport_modules ignores the prefix parameter for packages

[Brett Cannon]

Changes by Brett Cannon :


--
assignee:  -> lukasz.langa

___
Python tracker 

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

[issue22247] More incomplete module.__all__ lists

[John Mark Vandenberg]

Changes by John Mark Vandenberg :


--
nosy: +jayvdb

___
Python tracker 

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

[issue26632] __all__ decorator

[John Mark Vandenberg]

Changes by John Mark Vandenberg :


--
nosy: +jayvdb

___
Python tracker 

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

[issue26925] android: test_multiprocessing_main_handling fails

[Berker Peksag]

Changes by Berker Peksag :


--
stage:  -> resolved
superseder:  -> android: test_concurrent_futures fails

___
Python tracker 

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

[issue26944] android: test_posix fails

[Xavier de Gaye]

Xavier de Gaye added the comment:

'id -G' produces the expected result on an android-23-x86 emulator running 
Android 6.0 (API 23).

There is a new error now instead of the one reported at issue #26932:

==
FAIL: test_getgroups (test.test_posix.PosixTester)
--
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_posix.py", line 
816, in test_getgroups
set(posix.getgroups() + [posix.getegid()]))
AssertionError: Items in the second set but not the first:
0


The problem is that posix.getegid() returns 0, and 0 is not in the list printed 
by 'id -G'.

--
nosy: +Chi Hsuan Yen

___
Python tracker 

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

[issue26991] Possible reference leak in MAKE_FUNCTION

[Xiang Zhang]

Xiang Zhang added the comment:

I'm willing to. But I don't know where is the suitable place to put such a test 
and since the reference leak only appears in error case, can compile a function 
with annotations in a loop accomplish the test goal?

--

___
Python tracker 

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

[issue26936] android: test_socket fails

[Xavier de Gaye]

Xavier de Gaye added the comment:

testGetaddrinfo does not fail anymore on an emulator running an android-23-x86, 
i.e. Android 6.0 or API 23.

--

___
Python tracker 

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

[issue26935] android: test_os fails

[Xavier de Gaye]

Xavier de Gaye added the comment:

This is fixed at API 23 (Android 6.0) and test_os runs on an android-23-x86 
emulator without failures.

--

___
Python tracker 

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

[issue26925] android: test_multiprocessing_main_handling fails

[Xavier de Gaye]

Xavier de Gaye added the comment:

Closing as duplicate of #26924.

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

[issue26992] 64-bit Python 2.7.11 hangs in 64-bit Windows 10 - CMD and Git Bash

[R. David Murray]

R. David Murray added the comment:

Is there any way you can attach a debugger to the process and see what it is 
doing or where it is stuck?  Otherwise, unless someone else can reproduce this, 
I don't think there is much we can do with this bug report.

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

[issue26992] 64-bit Python 2.7.11 hangs in 64-bit Windows 10 - CMD and Git Bash

[Sam Taylor]

New submission from Sam Taylor:

We have seen an issue where the 64-bit 2.7.11 Python Interpreter hangs whilst 
trying to run it in either Command Prompt or Git Bash on 64-bit Windows 10.

The issue is intermittent, the interpreter will run sometimes but will often 
hang immediately after typing 'python + ENTER' in either of the terminals.  
There seems to be no pattern when it won't work.

We haven't seen this issue in 64-bit Windows 8.1.

The workaround was to install the 32-bit version of python 2.7.11 on 64-bit 
Windows 10 PC's - the interpreter is completely reliable in this case and 
running 32-bit has no effect on our work.

I haven't found the exact same issue elsewhere on the python bugs forum but 
similar issues point to Windows 10 dropping some functionality which Windows 
8.1 and earlier versions had.

Setting up pseudo terminals does help but is a messy workaround.  Adding and 
removing PYTHONPATH etc from the environment variables doesn't have any effect.

Everything is working fine so this isn't really an issue.  I'm just interested 
if anyone else has experienced this and if they can shed any light onto what 
causes it.

--
components: Interpreter Core, Windows
messages: 265246
nosy: paul.moore, sam.taylor.bs, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 64-bit Python 2.7.11 hangs in 64-bit Windows 10 - CMD and Git Bash
type: crash
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

[issue6338] Error message displayed on stderr when no C compiler is present with ctypes

[Martin Panter]

Martin Panter added the comment:

I presume the problem is that Free BSD’s “type” command outputs the error to 
the shell’s original stderr, rather than the one given on the “type” command 
line. If so, the Python 3 patches for Issue 22636 should avoid it by using 
shutil.which() instead.

However that function does not exist in Python 2, so a different solution needs 
to be found. Probably an improved version of Eric’s patch would be good.

--
dependencies: +avoid using a shell in ctypes.util: replace os.popen with 
subprocess
stage: patch review -> needs patch
versions: +Python 2.7 -Python 2.6

___
Python tracker 

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

[issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess

[Martin Panter]

Changes by Martin Panter :


Added file: http://bugs.python.org/file42800/crle

___
Python tracker 

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

[issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess

[Martin Panter]

Changes by Martin Panter :


Added file: http://bugs.python.org/file42799/ldconfig

___
Python tracker 

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

[issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess

[Martin Panter]

Martin Panter added the comment:

Uploading the fake commands I used for testing.

--
Added file: http://bugs.python.org/file42798/dump

___
Python tracker 

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

[issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess

[Martin Panter]

Martin Panter added the comment:

Here is a possible patch for Python 2. One snag is that ctypes is currently 
supposed to be compatible with Python 2.3, but subprocess was added in 2.4. The 
patch assumes it is okay to lift that compatibility restriction.

The main differences are:

* shutil.which() does not exist in Python 2. In _findLib_gcc() and the Gnu 
version of _get_soname(), I restored the mini shell script that runs “type” to 
check if commands are available. However I pass the library and file names as 
proper arguments, rather than inserting them into the shell syntax.

* subprocess.DEVNULL does not exist. Manually opened os.devnull where necessary.

* There was an extra Popen conversion for the Gnu “ldconfig -p” call. In Python 
3, this was already converted thanks to revision 19d9f0a177de (Issue 11258).

* No context manager support for Popen objects. Instead, use communicate() 
where appropriate, or manually close and wait.

Again, I tested the Python 2 patch on Linux, but with mock platform-specific 
commands to exercise each new Popen() call.

--
Added file: http://bugs.python.org/file42797/ctypes_util_popen-3.py2.patch

___
Python tracker 

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

[issue22636] avoid using a shell in ctypes.util: replace os.popen with subprocess

[Martin Panter]

Martin Panter added the comment:

I merged Victor’s patch with the current code and addressed most of the 
comments:

* restore re.escape()
* single "-l" + name argument
* copy with dict(os.environ)
* redirect GCC stderr=STDOUT
* changed tempfile cleanup to try / finally

I also added a test case.

I kept Victor’s behaviour of not raising OSError when the command is missing. I 
think this should be considered separately, and only changed for 3.6+, if at 
all. The buggy code was added in Issue 4861.

I only have Linux and GCC, but I briefly tested each platform-specific branch 
by hacking the “if” statements and creating mock crle, ldconfig, etc commands, 
so I am somewhat confident that everything is still working.

--
stage: needs patch -> patch review
versions:  -Python 3.4
Added file: http://bugs.python.org/file42796/ctypes_util_popen-3.py3.patch

___
Python tracker 

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

[issue14209] pkgutil.iter_zipimport_modules ignores the prefix parameter for packages

[Nick Coghlan]

Nick Coghlan added the comment:

+1 for just including the fix in the next round of maintenance releases, 
although a test case would be desirable.

--

___
Python tracker 

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

[issue12045] external shell command executed twice in ctypes.util._get_soname

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0b15b5371c07 by Antoine Pitrou in branch '2.7':
Issue #12045: Avoid duplicate execution of command in ctypes.util._get_soname().
https://hg.python.org/cpython/rev/0b15b5371c07

--

___
Python tracker 

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

[issue26991] Possible reference leak in MAKE_FUNCTION

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM. Would be nice to have a test (just compile a function with annotations in 
a loop).

--
components: +Interpreter Core
stage:  -> test needed
type:  -> behavior

___
Python tracker 

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

[issue12045] external shell command executed twice in ctypes.util._get_soname

[Martin Panter]

Martin Panter added the comment:

The same code is in Python 2. It was introduced by Issue 4861 (r68487).

--
nosy: +martin.panter
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

[issue26988] Add AutoNumberedEnum to stdlib

[John Hagen]

John Hagen added the comment:

@Ethan, I hadn't tried to use the aenum AutoNumberEnum that way, but I agree 
with Barry that I like it.  To me that is the ideal case we should shoot for as 
I think it's the best* long term and deviate only if practical concerns prevent 
it.

So I am +1 for empty member assignment and if that is rejected, +1 for = () 
assignment as at least it is a big step forward.  I feel both solutions already 
have some "magic", so would lean toward the one that leads to the least amount 
of boilerplate.

As for the empty assignment, I have played around with something similar before 
and will throw out one con for it: static analyzers get really confused.  
PyCharm, for example, thinks this is has unresolved references in it:

class Color(AutoNumberEnum):
red
green
blue

But the counter point is that if this is in the stdlib, static analyzer authors 
are much more likely to add a special case for it than if in a "non-official" 
third party package (PyCharm example: 
https://youtrack.jetbrains.com/issue/PY-19150).


Another piece of evidence to support inclusion is that Python already provides 
specialized Enum subclasses (like IntEnum).  I've written a lot of Python code 
that uses Enums and haven't personally needed IntEnum yet, but would have used 
an AutoEnum many, many times.

* I am assuming here that a true "enum" keyword is out of the question at this 
point for Python, which would probably be even better.

--

___
Python tracker 

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

[issue26991] Possible reference leak in MAKE_FUNCTION

[Xiang Zhang]

Xiang Zhang added the comment:

Sorry, wrong patch. Attach the right one.

--
Added file: http://bugs.python.org/file42795/make_function_reference_leak.patch

___
Python tracker 

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

[issue26991] Possible reference leak in MAKE_FUNCTION

[Xiang Zhang]

New submission from Xiang Zhang:

*names* is not Py_DECREFed in MAKE_FUNCTION in error case.

--
files: make_function_reference_leak.patch
keywords: patch
messages: 265235
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: Possible reference leak in MAKE_FUNCTION
versions: Python 3.6
Added file: http://bugs.python.org/file42794/make_function_reference_leak.patch

___
Python tracker 

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

[issue23921] Standardize documentation whitespace, formatting

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Addressed Martin's Georg's and my comments, resolved conflicts, stripped 
trailing spaces, backported to 2.7.

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

[issue23921] Standardize documentation whitespace, formatting

[Roundup Robot]

Roundup Robot added the comment:

New changeset be85897e6d58 by Serhiy Storchaka in branch '2.7':
Issue #23921: Standardized documentation whitespace formatting.
https://hg.python.org/cpython/rev/be85897e6d58

--

___
Python tracker 

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

[issue26039] More flexibility in zipfile write interface

[Thomas Kluyver]

Thomas Kluyver added the comment:

Ping? Once this is landed, I intend to make a backport package of it so I can 
start using it before Python 3.6 comes out.

--

___
Python tracker 

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

[issue23921] Standardize documentation whitespace, formatting

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2b492ea961c1 by Serhiy Storchaka in branch '3.5':
Issue #23921: Standardized documentation whitespace formatting.
https://hg.python.org/cpython/rev/2b492ea961c1

New changeset 909099686e6e by Serhiy Storchaka in branch 'default':
Issue #23921: Standardized documentation whitespace formatting.
https://hg.python.org/cpython/rev/909099686e6e

--
nosy: +python-dev

___
Python tracker 

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

[issue4861] fix problems with ctypes.util.find_library

[Martin Panter]

Martin Panter added the comment:

FYI the OSError exceptions added here were never triggered as intended, and 
they are proposed to be removed as part of Issue 25751.

--
nosy: +martin.panter

___
Python tracker 

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

[issue23921] Standardize documentation whitespace, formatting

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee: docs@python -> serhiy.storchaka

___
Python tracker 

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

[issue26960] urllib hangs when closing connection

[Senthil Kumaran]

Senthil Kumaran added the comment:

Thanks for raising this issue, Chris Beaumont.
Fixed in 2.7.x

--
nosy: +orsenthil
type:  -> behavior

___
Python tracker 

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

[issue26960] urllib hangs when closing connection

[Roundup Robot]

Roundup Robot added the comment:

New changeset 3388e249389d by Senthil Kumaran in branch '2.7':
Add NEWS entry for issue26960.
https://hg.python.org/cpython/rev/3388e249389d

--

___
Python tracker 

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

[issue26960] urllib hangs when closing connection

[Roundup Robot]

Roundup Robot added the comment:

New changeset 44d02a5d59fb by Senthil Kumaran in branch '2.7':
Closes issue26960.
https://hg.python.org/cpython/rev/44d02a5d59fb

--
nosy: +python-dev
resolution:  -> fixed
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

[issue16270] urllib hangs when closing connection

[Roundup Robot]

Roundup Robot added the comment:

New changeset 44d02a5d59fb by Senthil Kumaran in branch '2.7':
Closes issue26960.
https://hg.python.org/cpython/rev/44d02a5d59fb

--

___
Python tracker 

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