Changes by Jason R. Coombs :
--
keywords: +patch
Added file: http://bugs.python.org/file31676/6d6d68c068ad.diff
___
Python tracker
<http://bugs.python.org/issue18
Changes by Jason R. Coombs :
Added file: http://bugs.python.org/file31677/2b2744cfb08f.diff
___
Python tracker
<http://bugs.python.org/issue18978>
___
___
Python-bug
Changes by Jason R. Coombs :
Added file: http://bugs.python.org/file31678/061eb75339e2.diff
___
Python tracker
<http://bugs.python.org/issue18978>
___
___
Python-bug
Jason R. Coombs added the comment:
I've added tests to capture the new behavior.
--
___
Python tracker
<http://bugs.python.org/issue18978>
___
___
Pytho
Jason R. Coombs added the comment:
oh. My mistake. I didn't realize the error was in 'distutils.fancy_getopt' and
not in the getopt module itself. Indeed, the problem doesn't exist under getopt
itself, so is specific to distutils and fancy_getopt.
>>> from __fut
Jason R. Coombs added the comment:
At PyCon, I took another look at the Python 3.2 changes. Unfortunately, I found
they trigger failures in other aspects of the test suite, so the approach is
not viable as implemented.
I plan to take another look at this at some point, but I've been ut
New submission from Jason R. Coombs :
It appears with the latest changes (cdcc816dea85), ctypes builds as
_ctypes_test.pyd, not _ctypes.pyd. This causes 'import ctypes' to fail with an
ImportError and thus causes tests to fail that depend on test.support (which
imports ctypes)
New submission from Jason R. Coombs :
It appears that sometime between 64b695a6cc3d and cdcc816dea85, the Windows x64
Release build is no longer viable. It crashes when invoking the importer.
--
components: Build, Windows
messages: 160782
nosy: jason.coombs
priority: normal
severity
Jason R. Coombs added the comment:
It seems the Win32 build is okay. Only x64 is affected.
I did a debug build, and it caught the error in errors.c line 60:
Unhandled exception at 0x1e289aeb (python33_d.dll) in python_d.exe: 0xC005:
Access violation reading location 0x00b8
Jason R. Coombs added the comment:
I see now that _ctypes is in fact in the solution, and if I open the solution
in visual studio and build it manually, it gets built. Even if I just build the
solution in visual studio, it gets built.
However, if I run the following command, _ctypes doesn&#
Jason R. Coombs added the comment:
I've discovered a few things:
- _ctypes depends on pythoncore.
- other projects that depend on pythoncore are not built by msbuild.
- If I remove the dependency of _ctypes on pythoncore and then do the build
with msbuild, _ctypes is built and I can i
Jason R. Coombs added the comment:
Kristjan,
I'm trying to apply your most recent patch, but many of the hunks fail. I
tried to find it by time, but failed to do so. Perhaps you know what revision
that patch was against? Thanks.
--
nosy: +jason.c
New submission from Jason R. Coombs :
I have run into an issue where an attempt to call .decode('utf-8') on a Python
string results in the error with the following traceback:
File ...
''.decode('utf-8')
File "env/lib/python2.6/encodings/utf_8
Jason R. Coombs added the comment:
Thanks for the tip Amaury. Following that lead, I see that distribute does
indeed have a sandbox module which attempts to sandbox sys.modules, which can
break the encodings modules. I'm going to address the issue in distribute
first, but I lik
Jason R. Coombs added the comment:
After enabling the eol extension and re-checking out my working copy, I've
applied the patch successfully, but after I do so, I get this error when trying
to open the solution in VS2010:
"One or more projects in the solution were not loaded corre
Jason R. Coombs added the comment:
I agree. There is already an issue regarding the packaging dependencies. It
currently references ctypes, but we can rename it to be more broad.
issue14821
--
Added file: http://bugs.python.org/file25644/smime.p7s
Changes by Jason R. Coombs :
--
title: _ctypes_test fails to build from the command line with VS 2010 ->
_ctypes and other modules not built with msbuild on vs2010 solution
___
Python tracker
<http://bugs.python.org/issu
Jason R. Coombs added the comment:
I'd like to, but Apple hosed my Windows partition when upgrading to OS X Lion.
A minor setback, but I'll be unable to test for a while.
--
___
Python tracker
<http://bugs.python.o
Jason R. Coombs added the comment:
I tested against the latest tip and the issue no longer exists.
--
resolution: -> works for me
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Jason R. Coombs added the comment:
Excellent! The latest tip now builds nicely using msbuild.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Jason R. Coombs added the comment:
I find that on Python 2.7.3 64-bit Windows, the deletion of locale.encodings is
also necessary:
PS C:\Users\jaraco> python
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright"
Jason R. Coombs added the comment:
We're encountering this issue in another application of ours. A scan of the
code doesn't reveal any places where the encodings.* modules are removed, so
I've created a wrapper I intend to apply to our application that might help us
detect w
New submission from Jason R. Coombs :
I found that fileinput.input() requires two EOF characters to stop reading
input on Python 2.7.3 on Windows and Ubuntu:
PS C:\Users\jaraco> python
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on
win32
>>> impo
Jason R. Coombs added the comment:
I observed if I send EOF as the first character, it honors it immediately and
doesn't require a second EOF.
--
___
Python tracker
<http://bugs.python.org/is
Jason R. Coombs added the comment:
FWIW, I encountered the double-EOF behavior when invoking fileinput.input from
a script running non-interactively (except of course for the input() call).
--
___
Python tracker
<http://bugs.python.org/issue15
Changes by Jason R. Coombs :
--
versions: -Python 3.3
___
Python tracker
<http://bugs.python.org/issue6727>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
I don't know what changed in 3.3 to address this issue; likely candidates are
the VS 2010 upgrade or the rewrite of the import machinery. In either case,
best I can tell, 3.3 is no longer impli
Jason R. Coombs added the comment:
It seems that by adding the test to the default branch, the buildbots are now
broken for Unix systems (they're failing the test). I'm going to await the
results from the Windows buildbots, and then skip the tests on the failing
New submission from Jason R. Coombs :
In testing issue6727, I added a test
(http://hg.python.org/cpython/rev/afe67ea94bc6) to the default branch. The test
passes on Windows, but fails on some of the Unix buildbots. Here's a quick
breakdown of where it's passing and failing:
fail:
Jason R. Coombs added the comment:
I've disabled the test on non-Windows systems and created issue15091 to track
the issue.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Jason R. Coombs :
On Unix:
python -c "import os; os.mkdir('bar'); os.symlink('bar', 'foo');
print(os.path.isdir('foo'))"
True
On Windows:
python -c "import os; os.mkdir('bar'); os.symlink('bar', &#
Jason R. Coombs added the comment:
I should point out that some of those failures (e.g. x86 Solaris 11 3.x)
weren't triggered by the change, but many were.
--
___
Python tracker
<http://bugs.python.org/is
Jason R. Coombs added the comment:
The test is already present in test_import but is disabled because it is
currently failing. I should mention that I believe this is a regression with
3.3 over 3.2. It is certainly a regression over 2.7.
--
stage: test needed -> needs pa
Jason R. Coombs added the comment:
I apologize I missed this issue when it arose, so my comments come late.
The reason for inferring the directory status of the targets was so that use of
os.symlink(link, target) would behave much the same on Unix as on Windows for
the most common use cases
Jason R. Coombs added the comment:
Thanks ishimoto for getting to the bottom of this. Thanks pitrou for the links
to the symlink implementation changes.
Yes, this issue as reported was invalid.
--
resolution: -> invalid
status: open ->
Jason R. Coombs added the comment:
Since my last comment, we've been running with a version of the wrapper
(attached) around the main entry point to our application and it has completely
eliminated the error. However, while the wrapper does report when a module
deletion is requested,
Jason R. Coombs added the comment:
I've removed the invocation of the wrapper code in our project, but the issue
has not exhibited itself. This leads me to suspect a few possibilities of
things that have changed since we had the issue in June:
1) Distribute was updated with its fix for
Jason R. Coombs added the comment:
I also ran into this problem. I put together this script to reproduce the issue:
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('app')
parser.add_argument('--config')
parser.add_argument('app_args',
Jason R. Coombs added the comment:
That's entirely reasonable. I thought maybe that was the case.
My instinct is that 100% backward compatibility may not be necessary,
especially if setuptools and pip are in the loop and can assure compatibility
at some level. I'll dig deeper into
Jason R. Coombs added the comment:
Searching through the setuptools code base, there's no code reference to DEBUG
and only one comment referencing DISTUTILS_DEBUG (which I'm suspicious may be a
legacy artifact). In any case, I'm mostly confident that applying the patch as
prese
New submission from Jason R. Coombs:
In https://bitbucket.org/pypa/setuptools/issue/178, Eduard reported an issue
that setuptools fails to install due to files in its structure with spaces in
the filenames. These files have been around for some time (over two years in
Distribute), but are now
Jason R. Coombs added the comment:
The attached script (issue21153.py) replicates the failure in a Unix
environment with the 'rpm' command present.
--
Added file: http://bugs.python.org/file34721/issue21153.py
___
Python trac
Jason R. Coombs added the comment:
I tried using the --install-script hook of the bdist_rpm command to update the
INSTALLED_FILES listing to wrap them in quotes, but that doesn't help:
http://paste.jaraco.com/uNMrQ
I also delved into the RPM docs, which don't provide any guidance
Jason R. Coombs added the comment:
Yes. Exactly.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Jason R. Coombs added the comment:
My last version of the repo script would have worked had I coded it correctly.
The line-by-line substitution was broken, not taking into account the newline
character.
This new script demonstrates that quoting each file works - simply run the
script with
Jason R. Coombs added the comment:
In issue21153, I explored this problem as well, before being aware of this
issue. I had searched for bdist_rpm.
I've since confirmed that the sed approach is viable. For example, the
following works around the issue by overriding the install_script wit
Jason R. Coombs added the comment:
I decided to test my proposition. It seems that simply specifying / for %files
leads to the RPM including parent directories. Here's the output I get when
running my test with the sed workaround:
$ rpm -q -filesbypkg -p dist/issue21153-package-0.
Jason R. Coombs added the comment:
I still disagree. If the preferable place for Python to be installed is not in
the root (and I fervently feel so), then there could be a transitional approach
to move it to the appropriate place, such as creating symbolic links from the
legacy destinations
Jason R. Coombs added the comment:
This issue appears implicated in https://bitbucket.org/pypa/setuptools/issue/201
--
nosy: +jason.coombs
___
Python tracker
<http://bugs.python.org/issue1628
Jason R. Coombs added the comment:
This issue appears implicated in https://bitbucket.org/pypa/setuptools/issue/201
--
nosy: +jason.coombs
___
Python tracker
<http://bugs.python.org/issue17
Jason R. Coombs added the comment:
This issue appears implicated in https://bitbucket.org/pypa/setuptools/issue/201
--
nosy: +jason.coombs
___
Python tracker
<http://bugs.python.org/issue1218
Jason R. Coombs added the comment:
I recently ran into this error again. I was writing this class to provide
backward-compatible context manager support for zipfile.ZipFile on Python 2.6
and 3.1:
class ContextualZipFile(zipfile.ZipFile):
"""
Supplement ZipFile class to
Jason R. Coombs added the comment:
I recently ran into this error again. I was writing this class to provide
backward-compatible context manager support for zipfile.ZipFile on Python 2.6
and 3.1:
class ContextualZipFile(zipfile.ZipFile):
"""
Supplement ZipFile class to
Jason R. Coombs added the comment:
Maybe I should have focused on a more trivial example to demonstrate the place
where my expectation was violated. The use of a real-world example is
distracting from my intended point. Consider instead this abstract example:
class SomeClass(SomeParentClass
Jason R. Coombs added the comment:
Based on the example above, I've created a blog post to publish my
recommendation for overriding these special methods in a way that's safe
regardless of the parent implementation, given the status quo:
http://blog.jaraco.com/2014/05/how-to-safel
Jason R. Coombs added the comment:
Yes. Since Nick's comment , I've been using importlib for all programmatic
imports with great success.
--
resolution: -> invalid
status: pending -> closed
___
Python tracker
<http://bugs.py
Jason R. Coombs added the comment:
For reference, I encountered an issue due to this change and didn't quite
understand what was going on. I distilled the problem down and posted a
question on stack overflow:
http://stackoverflow.com/questions/14300153/why-does-this-datetime-subclass-fa
Jason R. Coombs added the comment:
Aah. Indeed, that's where I should have looked. Thanks for the pointer.
--
___
Python tracker
<http://bugs.python.org/issu
New submission from Jason R. Coombs:
The Python 2.7 docs for datetime state, "The standard library has no tzinfo
instances except for UTC," but if I read issue5094 correctly, Python 2.7 does
not even have a UTC tzinfo instance, and never will. Is there any reason I
shouldn't c
Changes by Jason R. Coombs :
--
resolution: -> fixed
___
Python tracker
<http://bugs.python.org/issue16985>
___
___
Python-bugs-list mailing list
Unsubscri
Jason R. Coombs added the comment:
I just want to say thanks for working on this. I also have needed this
functionality for various needs in the past. To fulfill my needs, I wrote this
implementation:
https://bitbucket.org/jaraco/jaraco.util/src/1ab3e7061f96bc5e179b6b2c46b06d1c20f87129/jaraco
New submission from Jason R. Coombs:
>>> import urllib.parse
>>> urllib.parse.urljoin('foo', [])
'foo'
That should raise a TypeError, not succeed quietly as if an empty string were
passed.
--
components: Library (Lib)
messages: 198418
nosy:
Jason R. Coombs added the comment:
Thanks Vajraski for the patch (especially the tests).
A colleague reminded me of an aphorism by Raymond Hettinger from the recent
PyCon paraphrased: duck typing is superior to isinstance.
Maybe instead consider something like this:
diff -r 7f13d5ecf71f Lib
Jason R. Coombs added the comment:
I don't mind the AttributeError - that's a reasonable exception when passing
invalid types in, and that's in fact the current behavior. The example of
(['a'], []) does bother me though. Those inputs are also seemingly invalid,
though
Jason R. Coombs added the comment:
Vajrasky, you're right. Comparing against type(obj) is an anti-pattern.
isinstance is better. Duck typing is even better (in many cases).
--
___
Python tracker
<http://bugs.python.org/is
New submission from Jason R. Coombs:
On Python 2.7 and 3.3, if the package_data glob happens to match a directory,
it will trigger this error during build:
error: can't copy '/': doesn't exist or not a regular file
It seems that package_data is not very smart about filte
Jason R. Coombs added the comment:
The attached example minimally replicates the issue.
--
Added file: http://bugs.python.org/file32210/example.zip
___
Python tracker
<http://bugs.python.org/issue19
Changes by Jason R. Coombs :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19286>
___
___
Python-bugs-list
Jason R. Coombs added the comment:
Indeed, the issue as reported is invalid.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Jason R. Coombs:
Following from issue7457, in which a single feature was identified to have gone
missing in 29a3eda89995, this ticket captures the need to bring the Python 3
codebase up to match Python 2.7.
--
assignee: eric.araujo
components: Distutils
messages
Jason R. Coombs added the comment:
As suggested, I created issue19544 to track the larger effort.
--
___
Python tracker
<http://bugs.python.org/issue7457>
___
___
Jason R. Coombs added the comment:
Confirmed - and to be included in issue19544.
--
nosy: +jason.coombs
___
Python tracker
<http://bugs.python.org/issue1
Jason R. Coombs added the comment:
This change was rolled back before the release of 3.2, so only exists in 2.7.
See issue19544 for details.
--
nosy: +jason.coombs
___
Python tracker
<http://bugs.python.org/issue6
Jason R. Coombs added the comment:
After spending several hours spelunking, we identified what we believe are the
tickets that were backed out in the aforementioned reversion.
issue1180
issue6516
issue7457
issue6466
issue6286
Additionally, issue6377 (renaming .compiler to .compiler_obj) was
Changes by Jason R. Coombs :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue6516>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Jason R. Coombs :
--
assignee: tarek -> akuchling
nosy: +akuchling
___
Python tracker
<http://bugs.python.org/issue1180>
___
___
Python-bugs-list mai
Changes by Jason R. Coombs :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue1180>
___
___
Python-bugs-list mailing list
Unsubscrib
Jason R. Coombs added the comment:
This change didn't make it into Python 3.2 but is in 2.7. see issue19544 for
details.
--
assignee: tarek -> jason.coombs
components: +Distutils
nosy: +alexis, jason.coombs
status: closed -> open
___
Pyt
Changes by Jason R. Coombs :
--
assignee: tarek -> jason.coombs
___
Python tracker
<http://bugs.python.org/issue6286>
___
___
Python-bugs-list mailing list
Un
Jason R. Coombs added the comment:
This change didn't make it into Python 3.2 but is in 2.7. see issue19544 for
details.
--
nosy: +jason.coombs
status: closed -> open
___
Python tracker
<http://bugs.python.or
Changes by Jason R. Coombs :
--
assignee: tarek -> jason.coombs
___
Python tracker
<http://bugs.python.org/issue7457>
___
___
Python-bugs-list mailing list
Un
Changes by Jason R. Coombs :
--
versions: +Python 3.3, Python 3.4 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue6286>
___
___
Python-bugs-list mailin
Changes by Jason R. Coombs :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue7457>
___
___
Python-bugs-list
Changes by Jason R. Coombs :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue6286>
___
___
Python-bugs-list mailing list
Unsubscrib
Jason R. Coombs added the comment:
The patch as committed causes the Windows 64-bit builds to fail to compile.
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/3187/steps/compile/logs/stdio
--
nosy: +jason.coombs
status: closed -> o
Jason R. Coombs added the comment:
Thanks Ned. I did see that and have pushed 394ed9deebd4. I believe that
corrects the only test failure.
--
___
Python tracker
<http://bugs.python.org/issue19
Changes by Jason R. Coombs :
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue6516>
___
___
Pyth
Changes by Jason R. Coombs :
--
assignee: akuchling -> jason.coombs
___
Python tracker
<http://bugs.python.org/issue1180>
___
___
Python-bugs-list mai
Changes by Jason R. Coombs :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue1180>
___
___
Python-bugs-list mailing list
Unsubscrib
Jason R. Coombs added the comment:
emxccompiler is no longer present in Python 3.4, so this ticket has become
invalid.
--
resolution: fixed -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Jason R. Coombs added the comment:
Thanks Victor.
Yes, it appears that there's yet another unported issue #7408, a follow-up to
#6516.
--
___
Python tracker
<http://bugs.python.org/is
Jason R. Coombs added the comment:
In issue #19544, #6516 was ported to Python 3.4. After doing so, this issue
re-emerges.
--
assignee: tarek -> jason.coombs
nosy: +jason.coombs
resolution: accepted ->
status: closed -> open
versions: +P
Jason R. Coombs added the comment:
I'm declaring this fixed and watching the buildbots for confirmation.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python
Jason R. Coombs added the comment:
I believe all identified issues have been ported/fixed.
--
assignee: eric.araujo -> jason.coombs
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Changes by Jason R. Coombs :
--
assignee: tarek -> jason.coombs
___
Python tracker
<http://bugs.python.org/issue12853>
___
___
Python-bugs-list mailing list
Un
Changes by Jason R. Coombs :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.or
Jason R. Coombs added the comment:
Berker reports in issue12853, msg202927 that the issue is fixed for Python 3.3
and 3.4 by the patch for issue6286 applied as part of issue19544.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -&g
Jason R. Coombs added the comment:
Thanks Gregory for the report and patch. I was unaware of this ticket when I
was correcting the deprecation warnings for distutils, so I've just used your
patch as a reference and pushed the remaining fixes as you indicated.
--
resolution: -&g
Jason R. Coombs added the comment:
A third counterargument is:
3. Newer developers (and even seasoned ones) adding new tests may use existing
tests as a model for best practices. If the existing tests model sub-optimal
practices, then those practices will be perpetuated both in the codebase
New submission from Jason R. Coombs:
Consider this simple example in Powershell (Windows 8.1):
C:\Users\jaraco> cat .\print-input.py
import sys
print(next(sys.stdin))
C:\Users\jaraco> echo foo | .\print-input.py
foo
The BOM (byte order mark) appears in the standard input stream. When
1501 - 1600 of 1863 matches
Mail list logo
