[issue13826] Having a shlex example in the subprocess.Popen docs is confusing

[Tim Smith]

Change by Tim Smith :


--
keywords: +patch
pull_requests: +17812
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18438

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

[issue33725] Python crashes on macOS after fork with no exec

[Tim Smith]

Change by Tim Smith :


--
nosy: +tdsmith

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

[issue31521] segfault in PyBytes_AsString

[Tim Smith]

New submission from Tim Smith:

$ python -V
Python 3.6.2

This crash appears to be specific to having files with some ill-encoded 
filenames. After renaming the offending files to remove the non-ASCII 
characters, the process could complete without crashing.

$ beet import /share/Music/Berliner\ Philharmoniker\;\ Herbert\ von\ Karajan
/share/Music/Berliner Philharmoniker; Herbert von Karajan/Tristan und Isolde; 
Tannhuser; Die Meistersinger von Nrnberg (5 items)
Correcting tags from:   
   
Berliner Philharmoniker; Herbert von Karajan - Tristan und Isolde; 
Tannhäuser; Die Meistersinger von Nürnberg
  
To: 
   
Richard Wagner; Berliner Philharmoniker; Herbert von Karajan - Tristan und 
Isolde / Tannhäuser / Die Meistersinger von Nürnberg
URL:
   
https://musicbrainz.org/release/7d2cbceb-7981-4eb4-a264-0dae5b6cba55
 
(Similarity: 92.9%) (artist, year, tracks) (CD, 1994, DE, Deutsche Grammophon)  
   
 * Tannhäuser und der Sängerkrieg auf Wartburg - Ouvertüre  -> 
Tannhäuser und der Sängerkrieg auf Wartburg: Overtüre (title)
 * Tannhäuser und der Sängerkrieg auf Wartburg - Bacchanale (Venusberg) -> 
Tannhäuser und der Sängerkrieg auf Wartburg: Bacchanale (Venusberg)
 * Die Meistersinger von Nürnberg - Vorspiel zum 3. Aufzug  -> Die 
Meistersinger von Nürnberg: Vorspiel zum 3. Aufzug
 * Tristan und Isolde - Vorspiel-> 
Tristan und Isolde: Vorspiel

 * Tristan und Isolde - Isoldes Liebestod   -> 
Tristan und Isolde: Isoldes Liebstod (title)

[A]pply, More candidates, Skip, Use as-is, as Tracks, Group albums, 
   
Enter search, enter Id, aBort, Print tracks, eDit, edit Candidates? 
   
[1]22921 segmentation fault (core dumped)  beet import 
/share/Music/Berliner\ Philharmoniker\;\ Herbert\ von\ Karajan


Please find full output of `coredumpctl info` in the attached file.

Stack trace of thread 22932:
#0  0x7fd216e23514 PyBytes_AsString (libpython3.6m.so.1.0)
#1  0x7fd206dfc904 n/a (_gi.cpython-36m-x86_64-linux-gnu.so)
#2  0x7fd206dfd196 n/a (_gi.cpython-36m-x86_64-linux-gnu.so)
#3  0x7fd206dfc25f n/a (_gi.cpython-36m-x86_64-linux-gnu.so)
#4  0x7fd206ddfddf n/a (_gi.cpython-36m-x86_64-linux-gnu.so)
#5  0x7fd206de01fb n/a (_gi.cpython-36m-x86_64-linux-gnu.so)
#6  0x7fd216e4d974 _PyCFunction_FastCallDict 
(libpython3.6m.so.1.0)
#7  0x7fd216e4b82a n/a (libpython3.6m.so.1.0)
#8  0x7fd216de92ea _PyEval_EvalFrameDefault 
(libpython3.6m.so.1.0)
#9  0x7fd216e4b34a n/a (libpython3.6m.so.1.0)
#10 0x7fd216e4b8ee n/a (libpython3.6m.so.1.0)
#11 0x7fd216de92ea _PyEval_EvalFrameDefault 
(libpython3.6m.so.1.0)
#12 0x7fd216e4b34a n/a (libpython3.6m.so.1.0)
#13 0x7fd216e4b8ee n/a (libpython3.6m.so.1.0)
#14 0x7fd216de92ea _PyEval_EvalFrameDefault 
(libpython3.6m.so.1.0)
#15 0x7fd216e4b34a n/a (libpython3.6m.so.1.0)
#16 0x7fd216e4b8ee n/a (libpython3.6m.so.1.0)
#17 0x7fd216de92ea _PyEval_EvalFrameDefault 
(libpython3.6m.so.1.0)
#18 0x7fd216e4a48d n/a (libpython3.6m.so.1.0)
#19 0x7fd216e4b571 n/a (libpython3.6m.so.1.0)
#20 0x7fd216e4b8ee n/a (libpython3.6m.so.1.0)
#21 0x7fd216de92ea _PyEval_EvalFrameDefault 
(libpython3.6m.so.1.0)
#22 0x7fd216e4adba _PyFunction_FastCallDict 
(libpython3.6m.so.1.0)
#23 0x7fd216e0edce _PyObject_FastCallDict 
(libpython3.6m.so.1.0)
#24 0x7fd216e0f9d1 _PyObject_Call_Prepend 
(libpython3.6m.so.1.0)
#25 0x7fd216e0fabb PyObject_Call (libpython3.6m.so.1.0)
#26 0x7fd216dea891 _PyEval_EvalFrameDefault 
(libpython3.6m.so.1.0)
#27 0x7fd216e4a48d n/a (libpython3.6m.so.1.0)

[issue31521] segfault in PyBytes_AsString

[Tim Smith]

Tim Smith added the comment:

I forgot to mention, this is Arch Linux python package:

Version : 3.6.2-1
Packager: Felix Yan 
Build Date  : Wed 19 Jul 2017 01:54:34 PM MDT

I had the files on a vfat filesystem, but copied them to ext4 with the exact 
same results.

--

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

[issue32616] Significant performance problems with Python 2.7 built with clang 3.x or 4.x

[Tim Smith]

Change by Tim Smith :


--
nosy: +tdsmith

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

[issue15267] tempfile.TemporaryFile and httplib incompatibility

[Tim Smith]

New submission from Tim Smith :

In httplib.py, there is this code to try to get the body length:

def _set_content_length(self, body):
# Set the content-length based on the body.
thelen = None
try:
thelen = str(len(body))
except TypeError, te:
# If this is a file-like object, try to
# fstat its file descriptor
try:
thelen = str(os.fstat(body.fileno()).st_size)
except (AttributeError, OSError):
# Don't send a length if this failed
if self.debuglevel > 0: print "Cannot stat!!"

However, if the body is a temporary file created by tempfile.TemporaryFile(), 
the len(body) in the first try throws an AttributeError, not a TypeError, on 
Windows and so it is not caught and unhappiness ensues. It is fine on 
Macintosh, and I would presume also on Linux.

Windows behaves different because on the other systems, TemporaryFile() returns 
an actual file object, and len() on a file throws TypeError. On Windows, 
TemporaryFile() returns an object that wraps the underlying file, and calling 
len() on that objects invokes this from tempfile.py (around line 371):

def __getattr__(self, name):
# Attribute lookups are delegated to the underlying file
# and cached for non-numeric results
# (i.e. methods are cached, closed and friends are not)
file = self.__dict__['file']
a = getattr(file, name)
if not issubclass(type(a), type(0)):
setattr(self, name, a)
return a

Since the underlying file does not have a __len__ method, the getattr fails and 
throws AttributeError.

I'm sorry I'm not submitting a patch, but I do not know enough about the design 
of these two libraries to know whether the correct fix is for httplib to be 
more broad in the exceptions that cause it to check for a file when len() 
fails, or if the object returned by TemporaryFile() should be more closely 
mimicking a true file object and so should be made to throw TypeError when 
someone tries to use len() on it.

--
components: Windows
messages: 164764
nosy: tzs
priority: normal
severity: normal
status: open
title: tempfile.TemporaryFile and httplib incompatibility
type: behavior
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue15267>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15267] tempfile.TemporaryFile and httplib incompatibility

[Tim Smith]

Tim Smith  added the comment:

Here is a program that demonstrates the problem:

import httplib
import tempfile

f = tempfile.TemporaryFile()
f.write("Hello, Temporary File!")
f.seek(0)

c = httplib.HTTPConnection('bugs.python.org')
c.request('POST', '/', f, {'Content-type' : 'application/octet-stream'})

r = c.getresponse()
print r.status, r.reason

The expected output is "200 OK", and that's what happens on Mac and almost 
certainly on Linux. On Windows, this is the result:

Traceback (most recent call last):
  File "bad.py", line 9, in 
c.request('POST', '/', f, {'Content-type' : 'application/octet
  File "C:\Python27\lib\httplib.py", line 958, in request
self._send_request(method, url, body, headers)
  File "C:\Python27\lib\httplib.py", line 989, in _send_request
self._set_content_length(body)
  File "C:\Python27\lib\httplib.py", line 964, in _set_content_len
thelen = str(len(body))
  File "C:\Python27\lib\tempfile.py", line 383, in __getattr__
a = getattr(file, name)
AttributeError: 'file' object has no attribute '__len__'

Changing the lines:

f = tempfile.TemporaryFile()
f.write("Hello, Temporary File!")
f.seek(0)

to:

f = open("temp.file", "w+")
f.write("Hello, Less Temporary File!")
f.seek(0)

makes it work on Windows.

--

___
Python tracker 
<http://bugs.python.org/issue15267>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22269] Resolve distutils option conflicts with priorities

[Tim Smith]

Changes by Tim Smith :


--
nosy: +tdsmith

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Tim Smith]

New submission from Tim Smith:

Homebrew, the OS X package manager, distributes python3 as a framework build. 
We like to be able to control the shebang that gets written to scripts 
installed with pip. [1]

The path we prefer for invoking the python3 interpreter is like 
/usr/local/opt/python3/bin/python3.4, which is symlinked to the framework stub 
launcher at 
/usr/local/Cellar/python3/3.4.1_1/Frameworks/Python.framework/Versions/3.4/bin/python3.4.
 For Python 2.x, we discovered that assigning 
"/usr/local/opt/python/bin/python2.7" to sys.executable in sitecustomize.py 
resulted in correct shebangs for scripts installed by pip. The same approach 
doesn't work with Python 3.

A very helpful conversation with Vinay Sajip [2] led us to consider how the 
python3 stub launcher sets __PYVENV_LAUNCHER__, which distlib uses in 
preference to sys.executable to discover the intended interpreter when pip 
writes shebangs.

Roughly, __PYVENV_LAUNCHER__ is set from argv[0], so it mimics the invocation 
of the stub, except that symlinks in the directory component of the path to the 
identified interpreter are resolved to a "real" path. For us, this means that 
__PYVENV_LAUNCHER__ (and therefore the shebangs of installed scripts) always 
points to the Cellar path, not the preferred opt path, even when python is 
invoked via the opt path.

Avoiding this symlink resolution would allow us to control pip's shebang (which 
sets the shebangs of all pip-installed scripts) by controlling the way we 
invoke python3 when we use ensurepip during installation.

Building python3 with the attached diff removes the symlink resolution.

[1]  This is important to Homebrew because packages are physically installed to 
versioned prefixes, like /usr/local/Cellar/python3/3.4.1_1/. References to 
these real paths are fragile and break when the version number changes or when 
the revision number ("_1") changes, when can happen when e.g. openssl is 
released and Python needs to be recompiled against the new library. To avoid 
this breakage, Homebrew maintains a version-independent symlink to each 
package, like /usr/local/opt/python3, which points to the 
.../Cellar/python3/3.4.1_1/ location.

[2] https://github.com/pypa/pip/issues/2031

--
assignee: ronaldoussoren
components: Macintosh
files: dont-realpath-venv-dirname.diff
keywords: patch
messages: 227505
nosy: ned.deily, ronaldoussoren, tdsmith, vinay.sajip
priority: normal
severity: normal
status: open
title: Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36718/dont-realpath-venv-dirname.diff

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Tim Smith]

Tim Smith added the comment:

I spoke prematurely; I recently rediscovered that the persistence of 
__PYVENV_LAUNCHER__ poisons the sys.executable of virtualenv interpreters 
launched as a subprocess of another Python interpreter:

$ virtualenv -p python3 test
$ test/bin/python3 -c 'import sys; print(sys.executable)'
/Users/tim/test/bin/python3

$ /usr/local/bin/python3 -c 'import subprocess; 
subprocess.call(["/Users/tim/test/bin/python3", "-c", "import sys; 
print(sys.executable)"])'
/usr/local/bin/python3

$ /usr/local/bin/python3 -c 'import subprocess, os; del 
os.environ["__PYVENV_LAUNCHER__"]; 
subprocess.call(["/Users/tim/test/bin/python3", "-c", "import sys; 
print(sys.executable)"])'
/Users/tim/test/bin/python3

If __PYVENV_LAUNCHER__ can be unset before script execution begins, that seems 
ideal.

--

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Tim Smith]

Tim Smith added the comment:

Since __PYVENV_LAUNCHER__ is consulted in site.py, it seems likely that the 
latest it can be deleted is in site.py. The attached patch does that.

--
Added file: http://bugs.python.org/file46004/delete-venev-launcher.diff

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

[issue26955] Implement equivalent to `pip.locations.distutils_scheme` in distutils

[Tim Smith]

Tim Smith added the comment:

As a Homebrew maintainer I'm happy to consider improving Homebrew's 
configuration if someone can point me to an extant package that uses this 
mechanism.

--
nosy: +tdsmith

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Tim Smith]

Tim Smith added the comment:

I'm attaching an updated patch; it passes tests for me locally with a framework 
build.

--
Added file: http://bugs.python.org/file36885/dont-realpath-venv-dirname.diff-1

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Tim Smith]

Tim Smith added the comment:

Er, because the test has been modified by taking Vinay's suggestion to test 
that the directories are physically identical instead of doing a string 
comparison.

--

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Tim Smith]

Tim Smith added the comment:

We would like to refer to python3 as /usr/local/opt/python3/bin/python3, where 
/usr/local/opt/python3 is a symlink to ../Cellar/python3/3.4.2, and 
/usr/local/Cellar/python3/3.4.2/bin/python3 is a symlink to 
/usr/local/Cellar/python3/3.4.2/Frameworks/Python.framework/Versions/3.4/bin/python3,
 which is the stub launcher for 
/usr/local/Cellar/python3/3.4.2/Frameworks/Python.framework/Versions/3.4/Python.

--

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

[issue22269] Resolve distutils option conflicts with priorities

[Tim Smith]

Tim Smith added the comment:

Ping! Any chance for feedback here? This behavior took me by surprise again 
today. :)

--

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Tim Smith]

Tim Smith added the comment:

Homebrew's interest in this ticket was resolved by the release of pip 6, which 
includes Vinay's change to distlib to use sys.executable instead of 
__PYVENV_LAUNCHER__. Many thanks!

I'm not marking this fixed in case it is useful to leave this open to discuss 
unsetting __PYVENV_LAUNCHER__.

--

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

[issue15590] --libs is inconsistent for python-config --libs and pkgconfig python --libs

[Tim Smith]

Tim Smith added the comment:

On Darwin, it would be nice if LINKFORMODULE used "-undefined dynamic_lookup" 
instead of explicitly linking to a framework binary. Modules with explicit 
links to a framework cause segfaults when they are imported from a different, 
but compatible, framework interpreter -- i.e., building against the system 
Python 2.7 but importing from a user-installed Python 2.7 causes an immediate 
crash.

I'm a maintainer of Homebrew, a package manager for OS X, and I spend a lot of 
time tracking down and eliminating errant explicit framework links because they 
make packaging binaries much harder for us and cause crashes for users.

--
nosy: +tdsmith

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

[issue24534] disable executing code in .pth files

[Tim Smith]

Tim Smith added the comment:

In Homebrew we occasionally use .pth files to call site.addsitedir. This is 
useful when we want to add a directory to sys.path that contains .pth files 
that also need to be processed (for example, when adding a directory to 
sys.path that contains namespace packages). It would be helpful to retain a 
mechanism for adding site dirs from a .pth file.

Homebrew also writes temporary probe .pths containing "import site; 
site.homebrew_was_here = True" in order to check whether .pth files are 
processed in a particular path, though we could equivalently write a temporary 
path to a .pth file and verify that it ends up in sys.path.

Finally, Homebrew asks users to write .pth files with imports in some places 
where we could use usercustomize instead.

--
nosy: +tdsmith

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

[issue24627] Import bsddb result in error on OS X (Python 2.7.10)

[Tim Smith]

Tim Smith added the comment:

Hi; I'm a Homebrew maintainer. Please open an issue at 
https://github.com/Homebrew/homebrew.

--
nosy: +tdsmith

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

[issue25136] Python doesn't find Xcode 7 stub libraries

[Tim Smith]

New submission from Tim Smith:

In Xcode 7, Apple is replacing many of the .dylibs in SDKROOT with textual 
stubs. [1] These files exist on disk with filenames like:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libz.tbd

They are short YAML documents that look like this: [2]

The same linker invocation that has always worked will continue to work with 
Xcode 7 (i.e. you still pass `-lz` to the linker), but this disrupts the checks 
that cpython's setup.py uses to determine if it can build extension modules. 
The dylibs physically exist on disk in /usr/lib, but since we've set -isysroot 
to the appropriate SDKROOT in CPPFLAGS, distutils searches for the dylibs in 
the sysroot path, and does not find them (since they have been replaced with 
.tbd stubs). Since distutils cannot find the libraries, setup.py declines to 
attempt to build any of the extension modules that depend on libraries in the 
OS X SDK, even though it would have succeeded if it had tried. Several Homebrew 
users have reported this while trialling Xcode 7 [3].

distutils should treat the .tbd files as a "real" library so that 
compiler.find_library_file succeeds and setup.py will proceed to attempt to 
build the extension modules.

The attached diff applies against the 3.5.0 release and allows extension 
modules to be built against Xcode 7 without installing the Command-Line Tools 
package.

If anyone is experiencing this issue, a workaround is to install the Xcode 
Command Line Tools package with `xcode-select --install` (which, among other 
things, installs headers to /usr/include), ensure the CLT is active with 
`xcode-select -s /Library/Developer/CommandLineTools`, and do not include 
`-isysroot` in CPPFLAGS when building python.

[1]: https://forums.developer.apple.com/thread/4572
[2]: https://gist.github.com/474233e561e28e1a8866
[3]: https://github.com/Homebrew/homebrew/issues/41085

--
components: Build, Distutils, Macintosh
files: xcode-stubs.diff
keywords: patch
messages: 250813
nosy: dstufft, eric.araujo, ned.deily, ronaldoussoren, tdsmith
priority: normal
severity: normal
status: open
title: Python doesn't find Xcode 7 stub libraries
type: compile error
Added file: http://bugs.python.org/file40478/xcode-stubs.diff

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

[issue25136] Python doesn't find Xcode 7 stub libraries

[Tim Smith]

Changes by Tim Smith :


Added file: http://bugs.python.org/file40479/xcode-stubs-2.7.patch

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

[issue25572] _ssl doesn't build on OSX 10.11

[Tim Smith]

Changes by Tim Smith :


--
nosy: +tdsmith

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

[issue24844] Python 3.5rc1 compilation error with Apple clang 4.2 included with Xcode 4

[Tim Smith]

Changes by Tim Smith :


--
nosy: +tdsmith

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

[issue27806] 2.7 32-bit builds fail on future releases of OS X due to dependency on deleted header file

[Tim Smith]

Changes by Tim Smith :


--
nosy: +tdsmith

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

[issue19398] test_trace fails with -S

[Tim Smith]

Changes by Tim Smith :


--
nosy: +tdsmith
versions: +Python 2.7

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