[issue29274] Change “tests cases” → “test cases”

New submission from Martin Panter: The “unittest” documentation has “tests cases” written a few times. This doesn’t seem right to me, but I thought I should get a second opinion in case I missed something. -- assignee: docs@python components: Documentation files: tests-cases.patch

[issue1621] Do not assume signed integer overflow behavior

Roundup Robot added the comment: New changeset dd2c7d497878 by Martin Panter in branch '3.5': Issues #1621, #29145: Test for str.join() overflow https://hg.python.org/cpython/rev/dd2c7d497878 New changeset eb6eafafdb44 by Martin Panter in branch 'default': Issue #1621: Overflow should not be

[issue29145] failing overflow checks in replace_*

Roundup Robot added the comment: New changeset dd2c7d497878 by Martin Panter in branch '3.5': Issues #1621, #29145: Test for str.join() overflow https://hg.python.org/cpython/rev/dd2c7d497878 New changeset 0c6ea411af17 by Martin Panter in branch 'default': Issue #29145: Merge test from 3.6

[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset 80fc40a9ae47 by Martin Panter in branch '3.5': Issue #22980: Skip a sysconfig test if _ctypes is not available. https://hg.python.org/cpython/rev/80fc40a9ae47 -- ___ Python tracker

[issue29273] test___all__ alters utf8 locale setting

New submission from Martin Panter: On a Linux computer I have LANG=en_US.utf8 set. Python 3 initializes the locale with this setting (see revision 43e32b2b4004): >>> locale.setlocale(locale.LC_CTYPE) # Get setting initialized by Python 'en_US.utf8' In Lib/test/test___all__.py, there is a

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

INADA Naoki added the comment: 1. _PyCFunction_FastCallKeywords() calls _PyStack_AsDict(), then calls _PyCFunction_FastCallDict(). 2. _PyCFunction_FastCallDict() calls _Py_FastCall_FromArgs() when METH_FASTCALL. 3. _Py_FastCall_FromArgs() calls _PyStack_UnpackDict(), then calls fastcall(). Can

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

Larry Hastings added the comment: Could one of you recent tagees (Terry, Zach) review the patch? Hoping to tag 3.5.3 final in less than 48 hours, and I want to cherry-pick the fix for this...! -- ___ Python tracker

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Larry Hastings added the comment: Hoping to tag in less than 48 hours...! -- ___ Python tracker ___ ___

[issue29062] hashlib documentation link error

Martin Panter added the comment: Looks like Doc/tools/susp-ignored.csv needs updating: $ make -C Doc/ suspicious [. . .] writing output... [ 49%] library/hashlib WARNING: [library/hashlib:502] ":vatrogasac" found in ">>> cookie = b'user:vatrogasac'"

[issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions

INADA Naoki added the comment: Maybe, we should do * Make clinic use more METH_FASTCALL * Use clinic more in builtin methods before trying this optimization. -- ___ Python tracker

[issue23407] os.walk always follows Windows junctions

Craig Holmquist added the comment: FWIW, the only name-surrogate tags in the user-mode SDK headers (specifically winnt.h) are IO_REPARSE_TAG_MOUNT_POINT and IO_REPARSE_TAG_SYMLINK, as of at least the Windows 8.1 SDK. -- ___ Python tracker

[issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions

INADA Naoki added the comment: This is proof of concept patch to support LOAD_METHOD & CALL_METHOD for METH_FASTCALL methods. (This patch should be applied after fastcall.patch) $ ./python -m perf timeit --compare-to `pwd`/python-fastcall -s "d = b''" -- "d.decode()" python-fastcall:

[issue29271] Task.current_task(None) returns unexpected result

INADA Naoki added the comment: LGTM -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue26296] colorsys rgb_to_hls algorithm error

Bryan B added the comment: Well, the other issue was resolved by updating Python on my computer to 3.6 ;) Setting up the entire Python build and test environment for an issue this small seems a little excessive, especially for a module that seems seldomly used. I'm gonna have to be that guy

[issue29270] super call in ctypes sub-class fails in 3.6

Changes by Eryk Sun : -- stage: -> patch review ___ Python tracker ___ ___

[issue29270] super call in ctypes sub-class fails in 3.6

Eryk Sun added the comment: Here's a patch that deletes __classcell__ from the dict before calling type_new. -- keywords: +patch Added file: http://bugs.python.org/file46285/issue_29270_01.patch ___ Python tracker

[issue26296] colorys rgb_to_hls algorithm error

Bryan B added the comment: Adding myself to this since I'm going to fix another hiccup in this file and I might as well clean this up too. -- nosy: +aarqon ___ Python tracker

[issue29272] test_logging hangs if /etc/hosts only aliases "localhost" to ::1

New submission from Brian Vandenberg: On some of the linux boxes on our (air-gapped, if that matters) network it looks like some of them were mis-configured and their /etc/hosts file looks something like this: $ cat /etc/hosts 127.0.0.1 snoopy.the.internal.domain snoopy localhost4

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: > Slower (63): > - unpickle_pure_python: 671 us +- 16 us -> 952 us +- 9 us: 1.42x slower (+42%) > ... This benchmark was run with LTO+PGO. It seems like PGO produced less efficient machine code with the patch. Maybe a missed optimization. Oh, I just realized

[issue29270] super call in ctypes sub-class fails in 3.6

Eryk Sun added the comment: In 3.6, type_new in Objects/typeobject.c sets the __classcell__ in the dict if it's a cell object. It happens that CreateSwappedType in Modules/_ctypes/_ctypes.c re-uses the dict to create the swapped type (e.g. big endian), which in turn updates the __classcell__.

[issue18235] _sysconfigdata.py wrong on AIX installations

Michael Felt added the comment: I did not go through a whole build process. Changing: if _PYTHON_BUILD: vars['BLDSHARED'] = vars['LDSHARED'] to if _PYTHON_BUILD: vars['LDSHARED'] = vars['BLDSHARED'] is not going to help if both variables are wrong in

[issue29271] Task.current_task(None) returns unexpected result

Lele Gaifax added the comment: Yay, Yury is too fast!! :-) -- ___ Python tracker ___ ___ Python-bugs-list

[issue29271] Task.current_task(None) returns unexpected result

Lele Gaifax added the comment: FWIW, the problem afflicts other functions, for example the following script exhibits a similar difference: import asyncio async def coro(): print(asyncio.Task.all_tasks()) print(asyncio.Task.all_tasks(None)) loop = asyncio.get_event_loop()

[issue29270] super call in ctypes sub-class fails in 3.6

Changes by Serhiy Storchaka : -- nosy: +ncoghlan, serhiy.storchaka versions: +Python 3.7 ___ Python tracker ___

[issue29271] Task.current_task(None) returns unexpected result

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___

[issue29265] os.cpu_count is problematic on sparc/solaris

Brian Vandenberg added the comment: > It doesn't cause any real problem with the tests, though. I routinely run > with -j40 on my 2 cpu test box because the test run completes faster that way > due to the way many tests spend time waiting for various things. In my case it did because it

[issue29271] Task.current_task(None) returns unexpected result

Changes by Lele Gaifax : -- nosy: +lelit ___ Python tracker ___ ___ Python-bugs-list

[issue29271] Task.current_task(None) returns unexpected result

Changes by Alberto Berti : -- nosy: +azazel ___ Python tracker ___ ___

[issue29271] Task.current_task(None) returns unexpected result

Changes by Yury Selivanov : -- keywords: +patch nosy: +inada.naoki Added file: http://bugs.python.org/file46284/task.patch ___ Python tracker

[issue29271] Task.current_task(None) returns unexpected result

New submission from Yury Selivanov: Quoting Alberto Berdi from python-tulip mailing list: working with the Python 3.6 asyncio implemented in C, i've got what is for me a strange behavior of the asyncio.Task.current task function. Executing the following test: import asyncio async def

[issue29270] super call in ctypes sub-class fails in 3.6

New submission from Dave Jones: While investigating a bug report in one of my libraries (https://github.com/waveform80/picamera/issues/355) I've come across a behaviour that appears in Python 3.6 but not prior versions. Specifically, calling super() in a sub-class of a ctypes scalar type

[issue16189] config/ld_so_aix not found: old dir name

Changes by Martin Panter : -- title: ld_so_aix not found -> config/ld_so_aix not found: old dir name ___ Python tracker ___

[issue18235] _sysconfigdata.py wrong on AIX installations

Martin Panter added the comment: So are you saying you tried patching Python 2 and/or 3, but did not see any relevant change at all? -- ___ Python tracker

[issue25825] AIX shared library extension modules installation broken: wrong dir names

Changes by Martin Panter : -- title: AIX shared library extension modules installation broken -> AIX shared library extension modules installation broken: wrong dir names ___ Python tracker

[issue29266] test_create_connection_service_name fails if "http" isn't listed in /etc/services

Changes by R. David Murray : -- components: +asyncio nosy: +gvanrossum, yselivanov ___ Python tracker ___

[issue29266] test_create_connection_service_name fails if "http" isn't listed in /etc/services

R. David Murray added the comment: It looks like that test already does so (it expects an OSError when passed the service name 'nonsense'). -- nosy: +r.david.murray ___ Python tracker

[issue29265] os.cpu_count is problematic on sparc/solaris

R. David Murray added the comment: You don't know it, but you are actually reporting a possible sparc/Solaris specific (I think) bug against os.cpu_count. There was some discussion about how cpu_count might be problematic in this regard. It doesn't cause any real problem with the tests,

[issue29269] test_socket failing in solaris

New submission from Brian Vandenberg: I started looking into this failure to see if I could figure out why but it looks like I'd have to spend more time than I have available to figure out the cause. Environment/setup: * air-gapped network (no internet access) * sparc / Solaris 10 * Built

[issue29268] test_spwd fails on solaris using NIS users

New submission from Brian Vandenberg: On all our solaris 10 machines when I run a simple test program it never reports a failure when calling getspnam: #include #include int main( int, char** ) { spwd *asdf = getspnam( "some_user" ); if( NULL == sdf ) { perror(

[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package

Vinay Sajip added the comment: Patch uploaded herewith. -- assignee: -> vinay.sajip stage: -> patch review Added file: http://bugs.python.org/file46283/issue-24875-01.diff ___ Python tracker

[issue29261] Missing venv/scripts/common after "make install"

Roundup Robot added the comment: New changeset 077681e35577 by Vinay Sajip in branch '3.5': Fixes #29261: added venv/scripts/common to LIBSUBDIRS. https://hg.python.org/cpython/rev/077681e35577 New changeset f20b2073dd4a by Vinay Sajip in branch '3.6': Fixes #29261: merged fix from 3.5.

[issue29197] Remove os.path.splitunc()

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue29197] Remove os.path.splitunc()

Roundup Robot added the comment: New changeset 2be38927ea61 by Serhiy Storchaka in branch 'default': Issue #29197: Removed deprecated function ntpath.splitunc(). https://hg.python.org/cpython/rev/2be38927ea61 -- nosy: +python-dev ___ Python tracker

[issue29267] Cannot override some flags in CFLAGS from the command-line

New submission from Brian Vandenberg: Due to issue 29264 I was attempting to override the build default "-std=c99" with: /path/to/configure (...) CFLAGS=-std=gnu99 ... however, the configure script is written like this: CFLAGS_NODIST="$CFLAGS_NODIST -std=c99" This causes it to

[issue29197] Remove os.path.splitunc()

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue29266] test_create_connection_service_name fails if "http" isn't listed in /etc/services

New submission from Brian Vandenberg: One of our solaris machines doesn't have an entry in /etc/services for "http". This is causing test_create_connection_service_name to fail. In my case I can just ignore that particular failure, but as a fix you might consider overtly getting valid

[issue28911] Clarify the behaviour of assert_called_once_with

Lisa Roach added the comment: It took me a little while to wrap my brain around this, but you are definitely right that the documentation is not sufficient, your changes are an improvement. My wonder is, should we change the documentation or be looking at the code itself? I have always

[issue29265] test suite is attempting to spawn 258 child processes to run tests

Changes by Serhiy Storchaka : -- nosy: +haypo ___ Python tracker ___ ___

[issue29265] test suite is attempting to spawn 258 child processes to run tests

Brian Vandenberg added the comment: This is odd. I just went back and re-ran 3.5.1 to see how many cores and it's having the same problem now. So, scratch that last coment. -- ___ Python tracker

[issue29265] test suite is attempting to spawn 258 child processes to run tests

Brian Vandenberg added the comment: I forgot to mention, this wasn't an issue in 3.5.1 though I never did check how many jobs it was using. I ran into other issues building that version and moved to a newer version because at least one of them (logging test race condition) was fixed after

[issue29265] test suite is attempting to spawn 258 child processes to run tests

New submission from Brian Vandenberg: I'm attempting to build python 3.6.0 on sparc/solaris 10. After the initial configure/compile complete I ran "make test" and I see: $ make test running build running build_ext (...) running build_scripts copying and adjusting (...) changing mode of (...)

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

JGoutin added the comment: Yes, I reported this encoding issue to some of them. But, there is still some problems : - Some libraries are not updated frequently (Or not still maintained), and still use fsencode. - Tests and CI don't see this problem if they don't have a test case for filename

[issue29264] sparc/ffi.c:440 error: 'asm' undeclared

New submission from Brian Vandenberg: When building pythong 3.6.0 on solaris 10/sparc I'm seeing the following error: Modules/_ctypes/libffi/src/sparc/ffi.c:440:8: error: 'asm' undeclared (first use in this function) (...) If I force it to use -std=gnu99 then it seems to compile fine.

[issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista

Segev Finer added the comment: I have read some of https://github.com/rprichard/win32-console-docs and it documents quite a bunch of nastiness with PROC_THREAD_ATTRIBUTE_HANDLE_LIST in Windows Vista/7. Windows is so much fun sometimes :P Essentially console handles in Windows before Windows 8

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: > Strange, I'm unable to reproduce the result on a different computer: > > haypo@smithers$ ./python -m perf compare_to ref.json tp_fastcall.json -v > Median +- std dev: [ref] 20.0 ms +- 0.5 ms -> [tp_fastcall] 20.0 ms +- > 0.6 ms: 1.00x slower (+0%) > Not

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: Strange, I'm unable to reproduce the result on a different computer: haypo@smithers$ ./python -m perf compare_to ref.json tp_fastcall.json -v Median +- std dev: [ref] 20.0 ms +- 0.5 ms -> [tp_fastcall] 20.0 ms +- 0.6 ms: 1.00x slower (+0%) Not significant!

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

STINNER Victor added the comment: Hum, it was long time ago since I worked on Windows. Well, Python has a "mbcs" codec which uses the ANSI code page which exists like "forever". These libraries should be patched to use "mbcs" instead of sys.getfilesystemencoding(). --

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

STINNER Victor added the comment: > Temporary fixing issues with some third party libraries which use C code for > files I/O (With filename as "mbcs" encoded bytes internally). > > Theses libraries generally call > "filename.encode(sys.getfilesystemencoding())" or "os.fsencode(filename)" >

[issue29261] Missing venv/scripts/common after "make install"

Zachary Ware added the comment: LGTM. -- assignee: -> vinay.sajip nosy: +vinay.sajip, zach.ware stage: -> commit review ___ Python tracker ___

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

JGoutin added the comment: Personally, I call "sys._enablelegacywindowsfsencoding()" for only one reason : Temporary fixing issues with some third party libraries which use C code for files I/O (With filename as "mbcs" encoded bytes internally). Theses libraries generally call

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: I ran benchmarks on tp_fastcall.patch. Hum, it seems like there is a performance issue somewhere :-( Almost all benchmarks are much slower with the patch. haypo@speed-python$ python3 -m perf compare_to 2017-01-11_00-07-default-b9404639a18c.json

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: Ok, I pushed a new commit "Add Py_TPFLAGS_HAVE_FASTCALL flag" in my Git branch. (By the way, I'm using the Git branch as a working copy, it can change anytime to get a nice list of commits. If you want reliable changes, use patches attached to this issue.)

[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package

Thomas Nyberg added the comment: Hi Vinay, You should probably upload a patch with the changes you made (however trivial) if you want that version considered. Makes it easier to comment and can then point to it for others to consider. Cheers, Thomas --

[issue29260] Use designated initializers to define PyTypeObject types

Serhiy Storchaka added the comment: There is nothing about this in PEP 7, but I think it would be better to use common subset of C and C++. This would allow to migrate to the subset of C++ in future. It is sad that PEP 7 allows C99 features not compatible with C++. --

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

Serhiy Storchaka added the comment: PyArg_UnpackStack() is declared as in the limited API since 3.3. If you want to add PyArg_UnpackStack() to the limited API, define it as added in 3.7. For compatibility with extensions built with older Pythons you should define new type flag and read

[issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions

Changes by STINNER Victor : -- dependencies: +Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects ___ Python tracker

[issue26110] Speedup method calls 1.2x

STINNER Victor added the comment: I just created the issue #29263: "Implement LOAD_METHOD/CALL_METHOD for C functions". -- ___ Python tracker ___

[issue29263] Implement LOAD_METHOD/CALL_METHOD for C functions

New submission from STINNER Victor: The issue #29259 implements tp_fastcall on method_descriptor (PyMethodDescr_Type). According to http://bugs.python.org/issue26110#msg283093 it would allow to implement LOAD_METHOD and CALL_METHOD for C functions. -- messages: 285414 nosy: haypo,

[issue29260] Use designated initializers to define PyTypeObject types

STINNER Victor added the comment: > Designated initializers already are used in _asynciomodule.c. Oh, I didn't notice. Since I don't recall any bug report on compilation failing on this module, I guess that it's fine to start to use them in more code. > But this is one of C99 features that

[issue29260] Use designated initializers to define PyTypeObject types

Serhiy Storchaka added the comment: Designated initializers already are used in _asynciomodule.c. But this is one of C99 features that are not compatible with C++. Using them makes harder possible using C++ compiler in future. -- ___ Python tracker

[issue29262] Provide a way to check for *real* typing.Union instances

New submission from flying sheep: typing.Union prevents the use of `isinstance` and `issubclass` via a hook. This is presumably to prevent errors that would arise if someone tried to do issubclass(A, Union[A, B]) or isinstance(A(), Union[A, B]), because Union isn’t specified in the PEP to

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: tp_fastcall.patch modifies property_descr_get() to use tp_fastcall if available, or use the cached tuple. Once performances are validated (no regression), the cached tuple as to pass position arguments, should go away. By the way, msg285390 uses the following

[issue29260] Use designated initializers to define PyTypeObject types

STINNER Victor added the comment: > The widespread use of PyType_FromSpec() will supersede this issue. Oh, I didn't know PyType_FromSpec(). It is only used for a very few types in the Python stdlib. -- ___ Python tracker

[issue29260] Use designated initializers to define PyTypeObject types

INADA Naoki added the comment: https://www.python.org/dev/peps/pep-0007/#c-dialect says "designated initializers (especially nice for type declarations)" So I think it's allowed explicitly. To minimize diff, I think we can start using it when adding slot at bottom of type declaration, or

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

STINNER Victor added the comment: Oh, I just noticed that os.environ uses the hardcoded error handler "surrogateescape": it should be replaced with sys.getfilesystemencodeerrors() to support UTF-8 Strict mode. -- ___ Python tracker

[issue26858] android: setting SO_REUSEPORT fails

STINNER Victor added the comment: > The reason why the changes made by issue 28174 fix only partly the problem > should be understood. The change c1c247cf3488 catchs OSError on sock.setsockopt() in asyncio/base_events.py, whereas the test fails while calling sock.getsockopt() in

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: Ok, here is a first patch: tp_fastcall.patch * Add tp_fastcall to PyTypeObject * Add fastcall_wrapper() and use it for tp_call in PyType_Ready() * Modify _PyObject_FastCallDict() and _PyObject_FastCallKeywords() to use tp_fastcall if defined * Modify a lot of

[issue29261] Missing venv/scripts/common after "make install"

New submission from Dave Jones: While attempting to diagnose something (unrelated to this issue) under python 3.6, I used the following steps to clone and build a non-root python installation: $ mkdir py36 $ hg clone https://hg.python.org/cpython $ cd cpython $ hg update 3.6

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: > * If a type only defines tp_fastcall: tp_fastcall is always use (tp_call uses > the wrapper) > > Is tp_call set to the wrapper rather then inheriting? It is set to the wrapper. Defining tp_fastcall should work as defining tp_call: it should override the

[issue26858] android: setting SO_REUSEPORT fails

Xavier de Gaye added the comment: Skipping those tests on Android has already been proposed with the existing patches in this issue. The reason why the changes made by issue 28174 fix only partly the problem should be understood. -- ___ Python

[issue29260] Use designated initializers to define PyTypeObject types

Serhiy Storchaka added the comment: The widespread use of PyType_FromSpec() will supersede this issue. But there is a caveat (issue26979). -- nosy: +serhiy.storchaka ___ Python tracker

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

Serhiy Storchaka added the comment: * If a type only defines tp_fastcall: tp_fastcall is always use (tp_call uses the wrapper) Is tp_call set to the wrapper rather then inheriting? What if tp_call is defined in a superclass? > * If a type defines tp_call and tp_fastcall, PyObject_Call() uses

[issue29260] Use designated initializers to define PyTypeObject types

New submission from STINNER Victor: Currently, PyTypeObject fields are set in order in the C code. Typical example: PyTypeObject PyMethod_Type = { PyVarObject_HEAD_INIT(_Type, 0) "method", sizeof(PyMethodObject), 0, (destructor)method_dealloc, /* tp_dealloc

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

Steve Dower added the comment: Windows doesn't use the fs encoding at all until Python code requests/provides something in bytes. Except for the caching in fsencode/fsdecode, there's no problem setting it once at the start of your program (and it can only be set once - there's no parameter

[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package

Vinay Sajip added the comment: I see why I couldn't reproduce the problem - there's no pip installed in the site-packages of the Pythons I was testing with, so the problem didn't show up. Mark, can you apply the version of EnvBuilder.create that I posted in a message above and see if that

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

Michael Felt added the comment: OOPS: I have a ... above, meant to be a link to a message. I also needed to 'patch' util.py - with 32-bit build with something like this: --- src/python-2.7.13/Lib/ctypes/util.py2016-12-17 20:05:05 + +++ python-2.7.13.0/Lib/ctypes/util.py 2017-01-13

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

Michael Felt added the comment: I would like to say: a) I am happy this is being considered for Python3-3.7 b) I still believe it is a "bug" plain and simple - it (find_library()) cannot work in "normal" situations. Why "IBM" or others never addressed this is beyond me - but - imho - that is

[issue26858] android: setting SO_REUSEPORT fails

STINNER Victor added the comment: IMHO it's ok to skip a few asyncio tests on Android. It's safe if it doesn't touch the code of asyncio itself. It don't really care if the Android version is not checked yet. Moreover, if we really want to check the version, we should check the *runtime*

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

STINNER Victor added the comment: My experience with changing the Python "filesystem encoding" (sys.getfilesystemencoding()) at runtime: it doesn't work. The filesystem encoding must be set as soon as possible and must never change later. As soon as possible: before the first call to

[issue26858] android: setting SO_REUSEPORT fails

Xavier de Gaye added the comment: The changes made in issue #28174 fix the problem for the Android x86 platform and for the armv7 platform at Android API level 24, but the problem is still there on the armv7 platform at Android API level 21.

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: I started to work on FASTCALL, because I dislike the "cached tuple" hack used in some performance critical code, and the hack causes various kinds of tricky but severe issues (can lead to segfault). Thanks to tp_fastcall, it becomes possible to drop the

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

STINNER Victor added the comment: Naoki wants to use FASTCALL for CALL_METHOD: http://bugs.python.org/issue26110#msg283093 tp_fastcall should allow to easily implement it. -- ___ Python tracker

[issue29259] Add tp_fastcall to PyTypeObject: support FASTCALL calling convention for all callable objects

New submission from STINNER Victor: A new FASTCALL calling convention was added to Python 3.6. It allows to avoid the creation of a temporary tuple to pass positional arguments and a temporary dictionary to pass keyword arguments. A new METH_FASTCALL calling convention was added for C

[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package

Mark Haase added the comment: Hey Thomas and Vinay, thanks for looking into this. Although I discovered this problem on my MacOS laptop 6 months ago, today I also reproduced this issue on my Ubuntu desktop. ``` /home/mhaase/Downloads $ mkdir temp /home/mhaase/Downloads $ cd temp

[issue29210] Remove the support of the exclude argument in tarfile.TarFile.add()

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue29210] Remove the support of the exclude argument in tarfile.TarFile.add()

Roundup Robot added the comment: New changeset 4e23948f2df2 by Serhiy Storchaka in branch 'default': Issue #29210: Removed support of deprecated argument "exclude" in https://hg.python.org/cpython/rev/4e23948f2df2 -- nosy: +python-dev ___ Python

[issue29099] sqlite3 timestamp converter cannot handle timezone

Xiang Zhang added the comment: timestamptz-3.patch uses ValueError instead of ProgrammingError and treat suffix Z as UTC timezone. -- Added file: http://bugs.python.org/file46279/timestamptz-3.patch ___ Python tracker

[issue29210] Remove the support of the exclude argument in tarfile.TarFile.add()

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Armin Rigo added the comment: Managed to write a patch in PyPy that seems to pass all tests including the new one, including on Windows. I know think that dd13098a5dc2 should be backed out (i.e. 030e100f048a should be kept). Reference to the PyPy changes:

[issue29213] python -m venv activate.bat has weird mix of line endings

Vinay Sajip added the comment: I've added a patch, can you confirm if it resolves the issue? -- assignee: -> vinay.sajip keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file46278/issue-29213-01.diff ___ Python tracker

  1   2   >