[issue26188] Provide more helpful error message when `await` is called inside non-`async` method

[SilentGhost]

Changes by SilentGhost :


--
components: +asyncio
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov

___
Python tracker 

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

[issue26188] Provide more helpful error message when `await` is called inside non-`async` method

[aditya gupta]

Changes by aditya gupta :


--
nosy: +aditya gupta

___
Python tracker 

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

[issue26190] GC memory leak using weak and cyclic references

[Maximilian Köhl]

New submission from Maximilian Köhl:

In the attached code the object initially bind to `a` is never garbage 
collected although there are no references left. The finalizer of `b` is 
executed and the weak reference to it becomes dead however the garbage 
collector does not free the object itself and it could be resurrected with 
`gc.get_objects()`.

Output:
gc: collecting generation 2...
gc: objects in each generation: 27 0 5795
gc: collectable 
gc: collectable 
finalize: b <__main__.A object at 0x7f158796acc0>
gc: done, 3 unreachable, 0 uncollectable, 0.0005s elapsed
gc: collecting generation 2...
gc: objects in each generation: 1 0 5812
gc: done, 0.0005s elapsed
gc: collecting generation 2...
gc: objects in each generation: 1 0 5812
gc: done, 0.0005s elapsed
[...]

--
components: Interpreter Core
files: gc_test_code.py
messages: 258886
nosy: koehlma
priority: normal
severity: normal
status: open
title: GC memory leak using weak and cyclic references
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file41704/gc_test_code.py

___
Python tracker 

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

[issue26195] Windows frozen .exe multiprocessing.Queue access is denied exception

[Alex Robinson]

New submission from Alex Robinson:

A pyinstaller 3.0 frozen .exe Python 2.7.10 program under Windows 7 that uses a 
multiprocessing.Queue to send things to a multiprocessing.Process leads to the 
process getting access-is-denied exceptions on every q.get() call.

And, when the program can't exit. Or leaves a dangling process for every 
Process.

An unsatisfying fix for this is to put the following code somewhere in the 
program:

"""
Do what must be done to make multiprocessing work in .exe files.

This involves monkey patching multiprocessing.forking under Windows
so when the a program using a multiprocessing.Process exits,
there won't be processes left running.

Hint from   
http://stackoverflow.com/questions/33764448/pathos-multiprocessing-pipe-and-queue-on-windows

.   The bottom line is we get "access is denied" when trying
.   to get from the multiprocessing.Queue when we're an .exe file.

.   So, in multiprocessing.forking.duplicate(),
.   we change 'inheritable' to default to True
.   from the normal code's False.

"""

import  sys
import  multiprocessing
import  multiprocessing.forking


#
#
#
#
def duplicate(handle, target_process = None, inheritable = True) :
return(multiprocessing.forking.kludge_to_fix_dangling_processes(handle, 
target_process, inheritable))

if  (not hasattr(multiprocessing.forking, 'kludge_to_fix_dangling_processes')) 
and (sys.platform == 'win32') :
multiprocessing.forking.kludge_to_fix_dangling_processes= 
multiprocessing.forking.duplicate
multiprocessing.forking.duplicate   = duplicate

--
components: Library (Lib)
messages: 258895
nosy: alex_python_org
priority: normal
severity: normal
status: open
title: Windows frozen .exe multiprocessing.Queue access is denied exception
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

[issue25296] Simple End-of-life guide covering all unsupported versions

[Berker Peksag]

Changes by Berker Peksag :


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

[issue26190] GC memory leak using weak and cyclic references

[Maximilian Köhl]

Changes by Maximilian Köhl :


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

[issue26192] python3 k1om dissociation permanence: libffi

[ƦOB COASTN]

New submission from ƦOB COASTN:

initial patch attached for Python-3.4.4
This patch requires rework.

I am willing to implement the __MIC__ or __KNC__ into a new patch if this is in 
fact the route forward that seems optimal.

Thanks,
Rob


> Enabling the build system for Intel MIC k1om is non-trivial using
> Python-3.4.4
> Using Python2 for the k1om is very popular, but I require Python3
> support on k1om.
>
> The first requirement to complete this build involved the download and
> extraction of pre-built MPSS RPM's.
> Then built required host python bins using GCC.
> Lastly, build MIC bins using ICC.
> The exacts are appended to the end of this message.
>
> I would like to discuss a few change requirements that trial and error
> has revealed.
>
> 1.) libffi requires the University OF Cantabria patch because the k1om
> is not binary compatible with x86_64. [attached]
>
> These libffi changes could be implemented using the __MIC__ or __KNC__
> macros.
> *see https://software.intel.com/en-us/node/514528

--
files: 0001-k1om-libffi.patch
keywords: patch
messages: 25
nosy: ƦOB COASTN
priority: normal
severity: normal
status: open
title: python3 k1om dissociation permanence: libffi
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41705/0001-k1om-libffi.patch

___
Python tracker 

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

[issue26191] pip on Windows doesn't honor Case

[Donald Stufft]

Donald Stufft added the comment:

If you're trying to use PyCrypto then you need to install PyCrypto, crypto is a 
different package. Try ``pip install PyCrypto``.

--
nosy: +dstufft

___
Python tracker 

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

[issue26191] pip on Windows doesn't honor Case

[Anders Rundgren]

New submission from Anders Rundgren:

pip install Crypto

Terminates correctly and the package is there as well.
Unfortunately the directory is named "crypto" rather than "Crypto" so when I 
perform

>>>import Crypto

the interpreter fails.

>>>import crypto 

seems to work but is incompatible over platforms.

If this is a problem with pycrypto or pip is beyond my knowledge of python.

--
components: Installation
messages: 258887
nosy: anders.rundgren@gmail.com
priority: normal
severity: normal
status: open
title: pip on Windows doesn't honor Case
type: compile error
versions: Python 3.5

___
Python tracker 

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

[issue26192] python3 k1om dissociation permanence: libffi

[SilentGhost]

Changes by SilentGhost :


--
components: +Extension Modules
nosy: +doko
versions:  -Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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

[issue26193] python3 k1om dissociation permanence: readelf

[ƦOB COASTN]

New submission from ƦOB COASTN:

> 2.) ./configure script halts during failure to locate readelf for the host.
>
> I simply commented out these lines in the ./configure file:
>  #if test "$cross_compiling" = yes; then
> #case "$READELF" in
> #readelf|:)
> #as_fn_error $? "readelf for the host is required for cross
> builds" "$LINENO" 5
> #;;
> #esac
> #fi
>
> Ideally, ./configure would support ICC and k1om.
> Am I missing something in the configure/make commands below?
> Is it possible to bypass the readelf requirement when cross-compiling for
> k1om?
>
> Additionally, are any of the command line parameters below unnecessary?
> PKG_CONFIG_LIBDIR
> PKG_CONFIG_PATH
> PYTHON_FOR_BUILD
> _PYTHON_HOST_PLATFORM
> HOSTPGEN
> HOSTARCH
> BUILDARCH
>
>
> Thanks,
> Rob
>
>
>
>
> #copy/unpack the k1om bins tarball
> cd /home/
> wget mpss-3.4.6-k1om.tar
> tar xvf mpss-3.4.6-k1om.tar
> cd /home/mpss-3.4.6/k1om/
> for rpm in *.rpm; do rpm2cpio $rpm | cpio -idm; done
>
> #vars
> PythonVersion=Python-3.4.4
> k1om_rpm=/home/mpss-3.4.6/k1om/
> INSTALLPREFIX=/home/Python/release/$PythonVersion-mic
> SRC=/home/Python/$PythonVersion
>
> echo "Compiling host Python"
> cd $SRC && make distclean
> cd $SRC && ./configure
> cd $SRC && make python Parser/pgen
> rm -f $SRC/hostpython
> mv $SRC/python $SRC/hostpython
> rm -f $SRC/Parser/hostpgen
> mv $SRC/Parser/pgen $SRC/Parser/hostpgen
> cd $SRC && make distclean
>
> echo "Configuring Python for MIC..."
> cd $SRC && CONFIG_SITE=config.site \
> ./configure \
> CC="icc -mmic" \
> CFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \
> CXX="icpc -mmic" \
> CPPFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \
> PKG_CONFIG_LIBDIR="$k1om_rpm/usr/lib64/pkgconfig" \
> PKG_CONFIG_PATH="$k1om_rpm/usr/lib64/pkgconfig" \
> --host=x86_64-k1om-linux \
> --build=x86_64-linux-gnu \
> --with-cxx-main="icpc -mmic" \
> --disable-ipv6
> echo "done"
>
> echo "Compiling Python for MIC..."
> cd $SRC && make \
> PYTHON_FOR_BUILD=./hostpython \
> _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \
> HOSTPGEN=./Parser/hostpgen \
> HOSTARCH=x86_64-k1om-linux \
> BUILDARCH=x86_64-linux-gnu \
> EXTRA_CFLAGS="-fp-model precise -shared -fPIC" \
> LDFLAGS="-L$k1om_rpm/lib64 -L$k1om_rpm/usr/lib64"
> echo "done"
>
> echo "Installing Python for MIC"
> mkdir -p $INSTALLPREFIX
> cd $SRC && make install \
> PYTHON_FOR_BUILD=./hostpython \
> _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \
> prefix=$INSTALLPREFIX
> echo "done"

--
components: Cross-Build
messages: 258889
nosy: ƦOB COASTN
priority: normal
severity: normal
status: open
title: python3 k1om dissociation permanence: readelf
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4, 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

[issue26191] pip on Windows doesn't honor Case

[SilentGhost]

SilentGhost added the comment:

Assuming that you're talking about https://pypi.python.org/pypi/crypto/ - it is 
unfortunate that pip is so lax with capitalisation rules when installing a 
package, but as far as I can see there isn't a "Crypto" package anywhere and 
you're never encouraged to use such a capitalisation in their docs.

Feel free to submit an issue on pip tracker, but this doesn't at all seem 
suitable for this one.

--
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

___
Python tracker 

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