[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

[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

[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

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

[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

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

Anders Rundgren added the comment:

You are right. Pardon me for erring :-(

Thanks for the quick response BTW!

Anders

--

___
Python tracker 

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

[issue26194] Undefined behavior for deque.insert() when len(d) == maxlen

[Raymond Hettinger]

New submission from Raymond Hettinger:

The behavior of deque.insert() in a bounded deque is a bit odd:

>>> from collections import deque
>>> d = deque(range(20), maxlen=10)
>>> d
deque([10, 11, 12, 13, 14, 15, 16, 17, 18, 19], maxlen=10)
>>> d.insert(3, 'New')
>>> d
deque([19, 10, 11, 'New', 13, 14, 15, 16, 17, 18], maxlen=10)
#   ^   ^^--- The 12 got replaced
#   |   \--- The elements before the insertion point got rotated
#   \--- The final element got rotated to first position

With append/appendleft/extend/extendleft, the intended and useful behavior for 
maxlen is to pop from the opposite end.  But for deque.insert(), the best and 
most useful behavior invariants are less obvious.

Ideally, the effect of d.insert(0, item) would be the same as 
d.appendleft(item), and the effect of d.insert(len(d), item) would be the same 
as d.append(item).  

Also, d.insert(i, newitem) should have the post-condition:

  assert d[i] == newitem if i < len(d) else d[-1] == newitem

Having decided where to put the newitem, the question turns to deciding which 
element should be popped-off to maintain the size invariant.

I'm thinking that it should always be the rightmost element that gets popped, 
so that items before the inserted element never get moved.  This matches what 
insert() does for unbounded deques, making it the least surprising choice.

--
assignee: rhettinger
components: Extension Modules
messages: 258893
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Undefined behavior for deque.insert() when len(d) == maxlen
type: behavior
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

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

[Katie McLaughlin]

Katie McLaughlin added the comment:

Hello!

I recently saw an announcement[0] about the adding of the lifecycle status 
right at the top of the devguide[1]. I believe this was added as part of Issue 
26165[2]

Given this, can this issue be marked as Resolved?

0 - https://twitter.com/gvanrossum/status/690227337015590912
1 - https://docs.python.org/devguide/#status-of-python-branches
2 - https://bugs.python.org/issue26165

--
nosy: +Katie McLaughlin

___
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

[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