[issue24127] Fatal error in launcher: Job information querying failed

[Henrik Heimbuerger]

Henrik Heimbuerger added the comment:

Great, thanks for letting us know, Dan!

--

___
Python tracker 

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

[issue23642] Interaction of ModuleSpec and C Extension Modules

[Petr Viktorin]

Petr Viktorin added the comment:

ping; this issue can be closed.

--

___
Python tracker 

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

[issue24458] Documentation for PEP 489

[Petr Viktorin]

New submission from Petr Viktorin:

Hello,
Here is a patch documenting PEP 489.

I don't feel comfortable rewriting the tutorial [0] yet: before the issue with 
callbacks/module state [1] is solved, which is 3.6 material, multi-phase init 
is not suitable for all modules.
So everything in PEP 489 is described in reference-style documentation.


[0] https://docs.python.org/3/extending/extending.html
[1] https://www.python.org/dev/peps/pep-0489/#module-state-and-c-level-callbacks

--
assignee: docs@python
components: Documentation
files: pep489-docs.patch
keywords: patch
messages: 245419
nosy: brett.cannon, docs@python, encukou, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Documentation for PEP 489
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39715/pep489-docs.patch

___
Python tracker 

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

[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD

[Ed Maste]

Ed Maste added the comment:

I believe the 0-based vs 1-based history is only one of a few different 
inconsistencies between libedit and readline. Workarounds will be necessary 
until a fixed libedit is deployed on all operating systems / distros of 
interest, but yes I agree that eventually they should not be needed.

--

___
Python tracker 

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

[issue23883] __all__ lists are incomplete

[Jacek Kołodziej]

Jacek Kołodziej added the comment:

Hi! This is my first attempt at contributing so as always, feedback will be 
well appreciated. :)

I meant to start small so I took a shot with csv module. In test, initial 
expected set contains QUOTE_* because they don't provide __module__ attribute, 
and __doc/version__ because they are already in csv.__all__ (should they?).

I've made a few PEP8-related fixes just around code I've touched (so they 
aren't completely unrelated). Is that ok?

--
nosy: +Unit03
Added file: http://bugs.python.org/file39716/Issue23883_csv_all.patch

___
Python tracker 

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

[issue24457] audioop.lin2adpcm Buffer Over-read

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue24456] audioop.adpcm2lin Buffer Over-read

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue23883] __all__ lists are incomplete

[Jacek Kołodziej]

Changes by Jacek Kołodziej :


Removed file: http://bugs.python.org/file39716/Issue23883_csv_all.patch

___
Python tracker 

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

[issue23883] __all__ lists are incomplete

[Jacek Kołodziej]

Changes by Jacek Kołodziej :


Added file: http://bugs.python.org/file39717/Issue23883_csv_all.patch

___
Python tracker 

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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

[Antony Lee]

New submission from Antony Lee:

The man page doesn't mention PYTHONFAULTHANDER in the list of environment 
variables (I haven't thoroughly checked that everyone else is there, either).  
I would also suggest reordering the environment variables in alphabetical order.

--
assignee: docs@python
components: Documentation
messages: 245422
nosy: Antony.Lee, docs@python
priority: normal
severity: normal
status: open
title: Mention PYTHONFAULTHANDLER in the man page
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

[issue24429] msvcrt error when embedded

[erik flister]

erik flister added the comment:

thanks a lot for the detailed info steve, very clearly stated!

> Yeah, geos_c.dll really should have exported its own free() function. 
> find_library('c') is probably the wrong approach here - if geos_c.dll is 
> being rebuilt with different CRTs at all then the free() function should be 
> added to it, and if it's truly legacy and is no longer being rebuilt then the 
> version of the CRT it uses should be loaded explicitly. It isn't 
> automatically getting the same version as whatever version of Python is 
> running, that's for sure.

well, shapely's installation instructions from windows are to use chris 
gohlke's prebuilt binaries from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/

i assume he's coordinating the crt versions?  apparently a lot of people use 
these.

i'm not clear on why gohlke's stuff is necessary, and why pypi/pip/distutils is 
not adequate -- shapely is the only library i've run into that needed gohlke's 
binaries.  of course, i didn't try to install numpy/scipy manually, the 
internet said that this is hard on windows, and to just use something like 
winpython/pythonxy.  are these problems all related to this crt issue?

--

___
Python tracker 

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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

[STINNER Victor]

STINNER Victor added the comment:

PYTHONASYNCIODEBUG and PYTHONTRACEMALLOC are also missing.

I didn't know that Python has a manual page :-) (Misc/python.man)

Note: I added these 3 environment variables ;-)

--
nosy: +haypo

___
Python tracker 

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

[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)

[STINNER Victor]

STINNER Victor added the comment:

The issue looks to be fixed on Python 3.4, 3.5 and 3.6. I checked quickly 
buildbots. I close the issue.

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

[issue23187] Segmentation fault, possibly asyncio related

[STINNER Victor]

STINNER Victor added the comment:

I'm sorry, but even if it's a real bug, we don't have enough information nor 
any scenario to reproduce the bug, so it's not possible to investigate the bug. 
I close the issue.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 

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

[issue24429] msvcrt error when embedded

[Steve Dower]

Steve Dower added the comment:

> i assume he's coordinating the crt versions?  apparently a lot of people use 
> these.

So do I :)  He's definitely got access to the correct compiler versions, so I'm 
sure he's using them (via distutils/setuptools, which will always try to use 
the correct one).

> i'm not clear on why gohlke's stuff is necessary, and why pypi/pip/distutils 
> is not adequate

It's not necessarily easy to get exactly the right compiler, and since Python 
generally relies on old and outdated ones (because 2.7 lives forever and cannot 
change) people often need multiple versions installed at the same time.

pip+wheel is adequate once library developers publish wheels (or republish 
Gohlke's wheel of their library). pip+distutils is very fiddly.

> shapely is the only library i've run into that needed gohlke's binaries.  of 
> course, i didn't try to install numpy/scipy manually, the internet said that 
> this is hard on windows, and to just use something like winpython/pythonxy.  
> are these problems all related to this crt issue?

numpy and scipy are due to requiring a Fortran compiler. The Intel compiler is 
compatible with MSVC, but does not have a Free(tm) license, while gfortran 
(gcc) does and is not strictly compatible with MSVC (there are some MinGW forks 
that are very close though).

So in effect, yes, the fact that the CRT has to match in every pre-built binary 
is the problem (less of a problem on Linux because nobody ever imagines that 
the C runtime might be compatible, and so everyone needs a compiler all the 
time - therefore, compiling is easier than distribution, whereas on Windows 
distribution is easier than compiling ).

--

___
Python tracker 

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

[issue23883] __all__ lists are incomplete

[Martin Panter]

Martin Panter added the comment:

Reviews of the patches waiting here:

tarfile, calendar (Joel): Look mainly good; I added minor suggestions about the 
test cases to Reitveld.

fileinput (Mauro): Looks pretty good; one minor comment on Rietveld.

csv (Jacek): Pretty good; couple minor suggestions. In a perfect world, I don’t 
think __doc/version__ should be there, but since they are already there it is 
probably safer to leave them. In general, I think style fixes in related code 
are okay; although in this case I have no problem with the original single 
blank lines.

There is nothing seriously wrong with the patches so far. They could be 
committed, perhaps with a few of the tweaks I suggested.

Summary of other things mentioned here left to do:

* Common test.support helper function
* gettext: Module fixed, but no changes to test suite
* Remaining modules from Serhiy’s list: cgi, configparser, doctest, enum, 
ftplib, http.cookies, logging, mailbox, mimetypes, optparse, pickletools, 
plistlib, pydoc, smtpd, subprocess, threading, tkinter.ttk, tokenize, wave, 
xml.etree.ElementTree.

One outstanding question is what to do about module-level constants that are 
only briefly mentioned in the documentation. IMO they should be included in 
__all__. Examples: http.client statuses 
, 
tarfile member types 
, 
calendar weekdays 
. 
Precedent of similar constants that are already included, in native Python 
modules: io SEEK_ constants; lzma FORMAT_, CHECK_, PRESET_ etc.

--

___
Python tracker 

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

[issue24421] Race condition compiling Modules/_math.c

[Martin Panter]

Martin Panter added the comment:

I think this may have been introduced when _math.c was added as a source file 
of the “cmath” module in r76978 (Issue 7518). In /setup.py:585 there are two 
distutils.core.Extension objects, both mentioning _math.c. In the 
build_ext._build_extensions_parallel() method at 
/Lib/distutils/command/build_ext.py:449, it appears to be invoking 
build_extension() in two concurrent threads, once for each module, including 
math and cmath.

I don’t know how this code is meant to work, but it looks like either the 
“build_ext” class should not be creating the same object file in two different 
threads, or /setup.py should not be giving it the same _math.c file for two 
different modules.

--
components: +Distutils
nosy: +dstufft, eric.araujo
versions: +Python 2.7, 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

[issue7518] Some functions in pymath.c should be moved elsewhere.

[Martin Panter]

Martin Panter added the comment:

I suspect the change here causes _math.c to be compiled to the same object file 
twice, and there is a race condition when the compilations are concurrent. See 
Issue 24421.

--
nosy: +vadmium

___
Python tracker 

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

[issue24460] urlencode() of dictionary not as expected

[David Rueter]

New submission from David Rueter:

In Python 3.4 I would like to serialize a dictionary into a URL-encoded string.

Given a dictionary like this: 

>>> thisDict = {'SomeVar1': [b'abc'], 'SomeVar2': [b'def'], 'SomeVar3': 
>>> [b'ghi']}

I would like to be able to return this string:

SomeVar1=abc&SomeVar2=def&SomeVar3=ghi

I thought that urllib.parse.urlencode would work for me, but it does not:

>>> print(urllib.parse.urlencode(thisDict))

SomeVar1=%5Bb%27abc%27%5D&SomeVar2=%5Bb%27def%27%5D&SomeVar3=%5Bb%27ghi%27%5D

In other words, urlencode on the dictionary is performing a URL encode on the 
string that is returned when the dictionary is cast to a string...and is 
including the square brackets (escaped) and the byte literal "b" indicator.

{'SomeVar1': [b'abc'], 'SomeVar2': [b'def'], 'SomeVar3': [b'ghi']}

I can obtain the desired string with this:

>>> '&'.join("{!s}={!s}".format(key,urllib.parse.quote_plus(str(val[0],'utf-8')))
>>>  for (key,val) in thisDict.items())

Is the behavior of urllib.parse.urlencode() on a dictionary intentional?  When 
would the current behavior ever be useful?

Would it make sense to change the behavior of urllib.parse.urlencode such that 
it works as described above?

--
components: Library (Lib)
messages: 245431
nosy: drue...@assyst.com
priority: normal
severity: normal
status: open
title: urlencode() of dictionary not as expected
type: behavior
versions: Python 3.4

___
Python tracker 

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