[Python-Dev] Last-minute request: please backport bpo-33329 fix to 3.4 and 3.5

2019-03-01 Thread Larry Hastings 


This bug in bpo-33329:

   https://bugs.python.org/issue33329

was fixed for 3.6+, but it also affects 3.4 and 3.5.  The bug is that 
with newer versions of glibc--which I'm pretty sure has shipped on all 
major Linux distros by now--the test suite may send signals that are 
invalid somehow.  As a result the test suite... blocks forever?  I 
think?  Anyway the observed resulting behavior is that there are three 
regression tests in each branch that seemingly never complete.  I 
started the 3.4 regression test suite /nine hours ago/ and it still 
claims to be running--and the 3.5 test suite isn't far behind.  
Technically, no, it's not a security bug.  But I simply can't ship 3.4 
and 3.5 in this sorry state.


Obviously it'd be best if the folks involved with the original PRs 
(Antoine?) took over.  I'm sending this to a wider audience just because 
I'd hoped to tag the next RCs for 3.4 and 3.5 this weekend, and the 
original participants in this fix may not be available, and I'm hoping I 
won't have to slip the schedule.



Thanks for your time,


//arry/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compile-time resolution of packages [Was: Another update for PEP 394...]

2019-03-01 Thread Barry Warsaw 
On Mar 1, 2019, at 02:41, Petr Viktorin  wrote:

> Currently, in RHEL/Fedora:
> - "sudo pip" installs to /usr/local/, RPM packages install to /usr/
> - with "-I", the interpreter does not look into /usr/local/.
> AFAIK, Debian/Ubuntu have something very similar, and were first to do it.

Debuntu’s pip installs to the user path by default, and you have to do 
something explicit to install into the system Python.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2019-03-01 Thread Python tracker 

ACTIVITY SUMMARY (2019-02-22 - 2019-03-01)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7012 (+13)
  closed 40898 (+64)
  total  47910 (+77)

Open issues with patches: 2791 


Issues opened (44)
==

#35459: Use PyDict_GetItemWithError() instead of PyDict_GetItem()
https://bugs.python.org/issue35459  reopened by vstinner

#35931: pdb: "debug print(" crashes with SyntaxError
https://bugs.python.org/issue35931  reopened by blueyed

#36084: Threading: add builtin TID attribute to Thread objects
https://bugs.python.org/issue36084  opened by jaketesler

#36085: Enable better DLL resolution
https://bugs.python.org/issue36085  opened by steve.dower

#36086: Split IDLE into separate feature in Windows installer
https://bugs.python.org/issue36086  opened by kimsey0

#36091: clean up async generator from types module
https://bugs.python.org/issue36091  opened by scotchka

#36092: unittest.mock's patch.object and patch.dict are not supported 
https://bugs.python.org/issue36092  opened by xtreak

#36093: UnicodeEncodeError raise from smtplib.verify() method
https://bugs.python.org/issue36093  opened by Windson Yang

#36094: When using an SMTP SSL connection,, get ValueError.
https://bugs.python.org/issue36094  opened by tyrone-zhao

#36095: Better NaN sorting.
https://bugs.python.org/issue36095  opened by brandtbucher

#36097: Use only public C-API in _xxsubinterpreters module.
https://bugs.python.org/issue36097  opened by eric.snow

#36098: asyncio: ssl client-server with "slow" read
https://bugs.python.org/issue36098  opened by MultiSosnooley

#36099: Clarify the difference between mu and xbar in the statistics d
https://bugs.python.org/issue36099  opened by steven.daprano

#36100: Document the differences between str.isdigit, isdecimal and is
https://bugs.python.org/issue36100  opened by StyXman

#36103: Increase shutil.COPY_BUFSIZE
https://bugs.python.org/issue36103  opened by inada.naoki

#36107: aarch64 python3 buffer overflow with stack protector on rpi3 (
https://bugs.python.org/issue36107  opened by Natanael Copa

#36108: Avoid failing the build on race condition in clean
https://bugs.python.org/issue36108  opened by steve.dower

#36114: test_multiprocessing_spawn changes the execution environment
https://bugs.python.org/issue36114  opened by pablogsal

#36116: test_multiprocessing_spawn fails on AMD64 Windows8 3.x
https://bugs.python.org/issue36116  opened by pablogsal

#36121: csv: Non global alternative to csv.field_size_limit
https://bugs.python.org/issue36121  opened by Carlos Ramos

#36124: Provide convenient C API for storing per-interpreter state
https://bugs.python.org/issue36124  opened by ncoghlan

#36127: Argument Clinic: inline parsing code for functions with keywor
https://bugs.python.org/issue36127  opened by serhiy.storchaka

#36128: ResourceReader for FileLoader inconsistently handles path sepa
https://bugs.python.org/issue36128  opened by indygreg

#36129: io documentation unclear about flush() and close() semantics f
https://bugs.python.org/issue36129  opened by indygreg

#36130: Pdb(skip=[...]) + module without __name__ => TypeError
https://bugs.python.org/issue36130  opened by Anthony Sottile

#36132: Python cannot access hci_channel field in sockaddr_hci
https://bugs.python.org/issue36132  opened by bsder

#36133: ThreadPoolExecutor and ProcessPoolExecutor, dynamic worker cou
https://bugs.python.org/issue36133  opened by Fabian Dill

#36136: Windows: python._pth sets isolated mode late during Python ini
https://bugs.python.org/issue36136  opened by vstinner

#36137: SSL verification fails for some sites inside windows docker co
https://bugs.python.org/issue36137  opened by Mika Fischer

#36138: Improve documentation about converting datetime.timedelta to s
https://bugs.python.org/issue36138  opened by p-ganssle

#36139: release GIL on mmap dealloc
https://bugs.python.org/issue36139  opened by davide.rizzo

#36140: An incorrect check in _msi.c's msidb_getsummaryinformation()
https://bugs.python.org/issue36140  opened by ZackerySpytz

#36141: configure: error: could not find pthreads on your system durin
https://bugs.python.org/issue36141  opened by muhzi

#36142: Add a new _PyPreConfig step to Python initialization to setup 
https://bugs.python.org/issue36142  opened by vstinner

#36143: Auto-generate Lib/keyword.py
https://bugs.python.org/issue36143  opened by gvanrossum

#36144: Dictionary addition.
https://bugs.python.org/issue36144  opened by brandtbucher

#36145: android arm cross compilation fails, config issue
https://bugs.python.org/issue36145  opened by muhzi

#36147: [2.7] Coverity scan: Modules/_ctypes/cfield.c , Variable "resu
https://bugs.python.org/issue36147  opened by cstratak

#36149: use of uninitialised memory in cPickle.
https://bugs.python.org/issue36149  opened by twouters

#36153: Freeze support documentation i

[Python-Dev] Update from the Python Steering Council about CPython Development

2019-03-01 Thread Carol Willing 
The Python Steering Council is pleased to provide an update to the Python 
community about Steering Council activity and CPython development. We've 
created a GitHub repo for Steering Council updates and helpful documents: 
https://github.com/python/steering-council

Here's the latest update written after our meeting on February 26th:
https://github.com/python/steering-council/blob/master/updates/2019-02-26_steering-council-update.md
 
(https://link.getmailspring.com/link/2aacf155-36b1-4d80-a2c1-a948561c4...@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Fpython%2Fsteering-council%2Fblob%2Fmaster%2Fupdates%2F2019-02-26_steering-council-update.md&recipient=cHl0aG9uLWRldkBweXRob24ub3Jn)
We'll be posting updates after each steering council meeting which will be 
roughly twice a month.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] before I open an issue re: posix.stat and/or os.stat

2019-03-01 Thread Michael Felt 
Shortening the original mail to something shorter.

The reason I am starting here, in -dev, rather than as an issue directly, is 
because I would like some direction/recommendation from concerned individuals 
before I take a "outsider" approach. Too often I have learned that I guessed 
wrong how the Python community "sees the world".
> On 2/21/2019 11:26 AM, Michael wrote:
> It seems so - however, Is there something such as PyUnsignedLong and is
> that large enough for a "long long"? and if it exists, would that make
> the value positive (for the first test).
> 
> posix.major and os.major will need to mask away the MSB and
> posix.makedev and os.makedev will need to add it back.
> 
> OR - do I need to make the PyStat values "the same" in both 32-bit and
> 64-bit?
I think I already have the answer to this - follow the platform (as far as size 
goes).

On 32-bit max(1) == 256 (2^^8) and on 64-bit 65536 (2^^16).

However, I am still puzzeled re: the idiosyncratic MSB addition - that the 
value for 
st.st_dev

on AIX 64-bit has always (as far back as I could look at least) had the MSB set 
so that, as a signed number st.st_dev is always negative. And MSB is not part 
of the major device number. It's just there.

So, it has been a few days since I studied this (waiting for reactions) - but 
is the return suppossed to always be a value returned by the posixmodule.c (if 
so, can strip the MSB bit and make everything positive - even for st.st_dev 
(but that would break under a direct comparision with a C program that does not 
strip the MSB).

Currently, the macros on AIX for 64-bit are broken, so I cannot guess how they 
will decide to implement major() and mkdevice() as far as striping (and adding) 
the MSB when "constructing" the st_dev number from two "regular" major and 
minor numbers.

Parked for now,

Best wishes,

Michael
> 
> Puzzled on what you think is the correct approach.
> 
> Michael
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compile-time resolution of packages [Was: Another update for PEP 394...]

2019-03-01 Thread Petr Viktorin 

On 2/28/19 6:56 PM, Gregory P. Smith wrote:


On Wed, Feb 27, 2019 at 5:12 PM Toshio Kuratomi > wrote:



On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer
mailto:nas-pyt...@arctrix.com>> wrote:

On 2019-02-26, Gregory P. Smith wrote:
 > On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw
mailto:ba...@python.org>> wrote:
 > For an OS distro provided interpreter, being able to restrict
its use to
 > only OS distro provided software would be ideal (so ideal
that people who
 > haven't learned the hard distro maintenance lessons may hate
me for it).

This idea has some definite problems.  I think enforcing it via
convention is about as much as would be good to do.  Anything more
and you make it hard for people who really need to use the vendor
provided interpreter from being able to do so.

Why might someone need to use the distro provided interpreter?

* Vendor provides some python modules in their system packages which
are not installable from pip (possibly even a proprietary extension
module, so not even buildable from source or copyable from the
system location) which the end user needs to use to do something to
their system.
* End user writes a python module which is a plugin to a system tool
which has to be installed into the system python to from which that
system tool runs.  The user then wants to write a script which uses
the system tool with the plugin in order to do something to their
system outside of the system tool (perhaps the system tool is
GUI-driven and the user wants to automate a part of it via the
python module).  They need their script to use the system python so
that they are using the same code as the system tool itself would use.

There's probably other scenarios where the benefits of locking the
user out of the system python outweigh the benefits but these are
the ones that I've run across lately.


Agreed.  The convention approach as someone said RHEL 8 has apparently 
done with an os distro reserved interpreter (yay) is likely good enough 
for most situations.


I'd go a /little/ further than that and suggest such an os distro 
reserved interpreter attempt to prevent installation of packages (ie: 
remove pip/ensurepip/distutils) via any other means than the OS package 
manager (rpms, debs).  Obviously that can't actually prevent someone 
from figuring out how to run getpip or manually installing trees of 
packages within its sys.path, but it acts as a deterrent suggesting that 
this interpreter is not intended for arbitrary software installation.


Currently, in RHEL/Fedora:
- "sudo pip" installs to /usr/local/, RPM packages install to /usr/
- with "-I", the interpreter does not look into /usr/local/.
AFAIK, Debian/Ubuntu have something very similar, and were first to do it.

What remains to tie this together is making "platform-python" always run 
with -I. This is PEP 432's "system-python" use case / design goal.
(The RHEL/Fedora platform-python was initially called system-python. We 
renamed to it so it doesn't clash with the PEP. It's the same use case, 
but we don't want to assign semantics to the name prematurely. 
Cutrrently, system-python is waiting for the larger-scale restructuring, 
and hopefully wider/longer discussion.)


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com