New submission from Jason R. Coombs :
If the version or name passed to distutils.core.setup is unicode, this results
in a UnicodeDecodeError. Consider this setup.py:
from distutils.core import setup
setup(
name=u'issue13381',
version=u'1.0',
modules=
Jason R. Coombs added the comment:
First, the term 'gztar' doesn't appear in this ticket, and since the issue only
applies when sdist --format gztar, I mention that here.
Also, issue8396 suggests encoding using sys.getfilesystemencoding().
--
nosy
Jason R. Coombs added the comment:
Python 2.7 is not aware of symlinks and treats them like their targets, so it
should be able to list a symlink directory or access a file within one. For
example:
PS C:\Users\jaraco> cmd /c dir
Volume in drive C is system
Volume Serial Number is 2455-9
Jason R. Coombs added the comment:
I should mention that there is third-party symlink support in jaraco.windows
(http://pypi.python.org/pypi/jaraco.windows). Just easy_install it, and then
use jaraco.windows.filesystem.symlink.
If there are features you need for symlink support in
Jason R. Coombs added the comment:
Brian, I'm still not sure I see the problem with os.listdir. It includes
symlinks when listing a dir and traverses them naturally when referencing them
as part of a path to listdir. Under what conditions does it
Jason R. Coombs added the comment:
Some variables could be a missing privilege or role, or perhaps a UAC
restriction. What error do you get when you attempt to invoke os.listdir on a
symlink directory?
--
___
Python tracker
<h
Jason R. Coombs added the comment:
On Windows Vista and Windows 7, there should be a symlink directory:
C:\Documents and Settings -> .\Users
Perhaps a good test would be:
assert 'Documents and Settings' in os.listdir('C:\\')
As long as there aren't any i18n
Changes by Jason R. Coombs :
--
status: closed ->
title: No knowledge of symlinks on Windows -> Symbolic links omitted by
os.listdir on some systems
___
Python tracker
<http://bugs.python.org/i
Jason R. Coombs added the comment:
If this issue is important to you, please follow the link above to the
Microsoft Connect site and vote for the issue. More votes should mean it will
get more attention. Thanks.
--
___
Python tracker
<h
Jason R. Coombs added the comment:
This bug doesn't appear to be present in 3.1, so the 2.7 patch is all that
applies at this time.
--
resolution: -> fixed
status: open -> closed
versions: -Python 2.6
___
Python tracker
<http://b
Changes by Jason R. Coombs :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12666>
___
___
Python-bugs-list
Changes by Jason R. Coombs :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13211>
___
___
Python-bugs-list
Jason R. Coombs added the comment:
Antoine, I think Arfrever is on to something here. It does appear the new test
added to test_urllib2 is failing, but for reasons I don't exactly understand.
I'm initializing the HTTPError instance according to its signature in
urllib.error, but i
Jason R. Coombs added the comment:
After yet another commit, the build bots are green again:
http://hg.python.org/cpython/rev/8fa1dc66de5d
--
___
Python tracker
<http://bugs.python.org/issue13
New submission from Jason R. Coombs :
In http://docs.python.org/dev/library/argparse.html#action, when describing an
arbitrary action, the documentation states, "You can also specify an arbitrary
action by passing an object that implements the Action API." This statement
does not l
Changes by Jason R. Coombs :
--
title: Document the Action API -> Document the Action API in argparse
___
Python tracker
<http://bugs.python.org/issu
Jason R. Coombs added the comment:
You're right. The documentation isn't incorrect, if you're splitting hairs. But
it's not super friendly either.
Questions that the documentation should answer:
1) Does the action always need to be a subclass of an Action, or is that
Changes by Jason R. Coombs :
--
hgrepos: +95
___
Python tracker
<http://bugs.python.org/issue13540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
I've attached a repository and patch with the recommended changes. I created an
additional section that includes the documentation for the Action class
(specifically the __init__ and __call__ signatures).
I believe this addresses the issues I raised
Changes by Jason R. Coombs :
--
keywords: +patch
Added file: http://bugs.python.org/file23949/956c6d33a57d.diff
___
Python tracker
<http://bugs.python.org/issue13
Jason R. Coombs added the comment:
Most of the Action subclasses in argparse override __init__ and they raise
ValueErrors when the parameters aren't as expected for that argument. This was
my reason for adding that comment. If the basic Actions require this level of
validation, would
Jason R. Coombs added the comment:
I meant to paste the repro with distutils.core:
python -c "from distutils.core import setup; setup(name=u'foo')" sdist
--formats gztar
--
___
Python tracker
<http://bug
Jason R. Coombs added the comment:
This error is also encountered if the package name is unicode. The error can be
simply reproduced with this command:
python -c "from setuptools import setup; setup(name=u'foo')" sdist --formats
gztar
The error also occurs with th
New submission from Jason R. Coombs :
python -c "import tarfile; tarfile.open(u'hello.tar.gz', 'w|gz')"
produces
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 1
Jason R. Coombs added the comment:
I believe the underlying cause of this issue is #13639.
--
___
Python tracker
<http://bugs.python.org/issue11638>
___
___
Pytho
Jason R. Coombs added the comment:
I've created a repo to continue this work. I've integrated David's patch
(thanks).
It's not obvious to me what the encoding should be. Python and the tarfile
module can accept unicode filenames. It seems that only the gzip part of
Changes by Jason R. Coombs :
Added file: http://bugs.python.org/file24059/9e9ea96eb0dd.diff
___
Python tracker
<http://bugs.python.org/issue11638>
___
___
Python-bug
Jason R. Coombs added the comment:
That looks like a good patch to me. Do you want to commit it, or would you
rather I do?
--
___
Python tracker
<http://bugs.python.org/issue13
Jason R. Coombs added the comment:
> > Encoding to 'utf-8' or the default file system encoding doesn't seem
> > right (as the characters end up getting stored in the gzip archive itself).
> I don’t understand.
The characters are being stored in the gzip archive as
Jason R. Coombs added the comment:
I also feel (1) or (3) is best for this issue. If there is a _better_
implementation, it should be reserved for a separate improvement to Python
3.2+.
I lean slightly toward (3) because it would support filenames with Unicode
characters other than latin-1
Changes by Jason R. Coombs :
--
keywords: +patch
Added file: http://bugs.python.org/file24092/774933cf7775.diff
___
Python tracker
<http://bugs.python.org/issue11
Jason R. Coombs added the comment:
Thanks to Lars for suggesting the fix, replacing 'w|gz' with 'w:gz'. I
attempted this change in the latest revision of my fork (774933cf7775.diff).
While this change does address the issue if a unicode string is passed which
can be encod
New submission from Jason R. Coombs :
While investigating #11638, I encountered another encoding issue related to
tarballs. Consider this command:
python -c "import gzip; gzip.GzipFile(u'\xe5rchive', 'w',
fileobj=open(u'\xe5rchive', 'wb'))&qu
Changes by Jason R. Coombs :
--
components: +Library (Lib)
___
Python tracker
<http://bugs.python.org/issue13664>
___
___
Python-bugs-list mailing list
Unsub
Jason R. Coombs added the comment:
I've captured the cause of the UnicodeEncodeErrors as #13664.
After rebasing the changes to include the fix for #13639, I found that the
tests were still failing until I also reverted the patch to call tarfile.open
with 'w:gz'. Now all the
Changes by Jason R. Coombs :
Added file: http://bugs.python.org/file24095/dc1045d08bd8.diff
___
Python tracker
<http://bugs.python.org/issue11638>
___
___
Python-bug
Jason R. Coombs added the comment:
Since the tests now pass, and the only changes were to the tests, I've pushed
them to the master. And with that I'm marking this ticket as closed.
--
status: open -> closed
___
Python t
New submission from Jason R. Coombs :
When constructing a ctypes.c_char_p with a unicode string, a confusing error
message is reported:
> python -c "import ctypes; ctypes.c_char_p('foo')"
Traceback (most recent call last):
File "", line 1, in
TypeError: s
Jason R. Coombs added the comment:
> That's a shame. I tested it in advance. I'll correct or revert tonight or
> tomorrow.
--
title: python setup.py sdist --formats tar* crashes if version is unicode ->
python setup.py sdist --formats tar* crashes if versionis
Jason R. Coombs added the comment:
I've limited the scope of the patch to attempt to only test on those platforms
that can actually create unicode-named files. I'll watch the buildbots to see
if that corrects the failures (since I don't have the failing platforms
Jason R. Coombs added the comment:
The changes to the default branch seem to have cleaned up the test failures on
most platforms (still waiting on the ARM results). So I've backported the test
skips to the Python 2.7 branch as well.
--
___
P
Jason R. Coombs added the comment:
I recently encountered this error, and in the process of troubleshooting,
developed this one-line to reproduce the problem. I'm including it here for
posterity (and in case anybody wants to test a given version of Python for the
error):
python -c
Jason R. Coombs added the comment:
Windows symlinks, much like Unix symlinks, should dereference naturally when
open is called, although there is a bug in later versions of the c runtime
calling stat on a symlink. See issue6727 for details.
--
title: upload command no longer accepts
Jason R. Coombs added the comment:
I've filed a support incident with the Microsoft Support team to try to push
this issue determine a fix or workaround.
--
___
Python tracker
<http://bugs.python.org/i
Jason R. Coombs added the comment:
To the extent that we can, we should try to support relative symlinks. Absolute
symlinks aren't the right thing in some cases, where the symlinks should be
movable with their targets. I use relative links extensively.
Is it worth considering changin
Jason R. Coombs added the comment:
I'll take a look.
--
Added file: http://bugs.python.org/file22357/smime.p7s
___
Python tracker
<http://bugs.python.org/issue12084>
___
smime.p7s
Descript
Jason R. Coombs added the comment:
I looked into the possibility of retaining newline characters even for files
with mixed newlines, but I've decided that's too intrusive an approach. The
current implementation specifically takes measures to strip whitespaces from
the ends of li
Jason R. Coombs added the comment:
I've encountered a use-case where the need to pickle NoneType is more relevant
(and difficult to work around).
We have a strongly-type Limited Python language, LimPy, which is based on
Python (https://bitbucket.org/yougov/limpy). This parser takes, as
Jason R. Coombs added the comment:
No problem. I'll rebase and push the current patch as-is, and then backport to
3.2 and 2.7 without the option (just raising the error when mixed newlines are
encountered).
--
___
Python tracker
Jason R. Coombs added the comment:
> I assume you’re not talking about hg.python.org/cpython?
My name appears as jason.coombs. But your note does remind me that I need to
review the devguide, since it's been a while since I've pushed something. I may
also look into linking/m
Jason R. Coombs added the comment:
I've stripped the undesirable revisions and updated the bitbucket repo so it
now contains three changesets for Python 3.2 and 3.3 and suggested.
I don't believe running the test suite is relevant, as I grepped the test suite
for reindent, and
Jason R. Coombs added the comment:
> > Script run without extensions when run with an explicit python
> > command.
> Like “python.exe setup” when the file really is setup.py? I’d
> never have guessed that.
No. Python.exe expects the full path. The only way to execute sc
Jason R. Coombs added the comment:
What do you think about this:
https://bitbucket.org/jaraco/cpython-issue10639/changeset/ea63310dddce
The patch is a little more intrusive than the Python 3 patch because Python 2.7
doesn't allow specifying the newline to use when writing a file (a
Jason R. Coombs added the comment:
> Instead of writing a new class, what about using io.open instead of the
> builtin? Then you’ll be able to use the same patch than 3.2.
Ooh. Excellent suggestion.
--
___
Python tracker
<http://bugs.p
Changes by Jason R. Coombs :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10639>
___
___
Python-bugs-list
Jason R. Coombs added the comment:
I don't believe that's the issue. The [server-login] is for Python 2.5 and
earlier. Also note that I already had [server-login] in the .pypirc when the
error occurred, so I don't think that's a factor either.
This same .pypirc works jus
Jason R. Coombs added the comment:
The 'spec_newline' in particular is only in the trunk (not in the backports),
as it's part of the new --newline option.
--
___
Python tracker
<http://bugs.pyt
Jason R. Coombs added the comment:
I hadn't realized that the other global variables were defined at the module
level or I would have implemented this originally. Please let me know if this
patch doesn't correct the issue.
--
___
Pyth
Changes by Jason R. Coombs :
--
stage: needs patch -> commit review
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10639>
___
___
New submission from Jason R. Coombs :
In `whatsnew/3.0.html`, there is little said about the map builtin:
map() and filter() return iterators. If you really need a list, a quick fix is
e.g. list(map(...)), but a better fix is often to use a list comprehension
(especially when the original
Jason R. Coombs added the comment:
I believe the correct solution to (2) is to use itertools.zip_longest. So to
port to Python 3, the example would use:
print(list(map(to_tuple, itertools.zip_longest([1,2,3], [4,5,6,7]
--
___
Python
Jason R. Coombs added the comment:
I've created a patch to address (1) and (2).
Is there any value in also including this in the 2to3 fixer? I can see that
it's a simple translation, but adds complexity to the converted code. I'd be
content to go with just a documentation pa
Changes by Jason R. Coombs :
--
keywords: +patch
Added file: http://bugs.python.org/file22839/bc362109eed8.diff
___
Python tracker
<http://bugs.python.org/issue12
Jason R. Coombs added the comment:
I don't know how that repo got to be private; I created it just like every
other public repo I have, and I thought I was only allowed one private repo
(this was my second). In any case, I updated the setting, and now it appears to
be accessible via th
Jason R. Coombs added the comment:
I'm not sure how the bugtracker patch mechanism works, but the patch it
produced included a lot of changes that I didn't make (changesets already
committed to the master repo).
--
keywords: -patch
Jason R. Coombs added the comment:
I'm attaching the diff at
https://bitbucket.org/jaraco/cpython-issue12666/changeset/bc362109eed8
--
keywords: +patch
Added file:
http://bugs.python.org/file22848/cpython-issue12666-bc362109eed8.diff
___
P
Jason R. Coombs added the comment:
I agree the two calls should probably be consistent, though I also suspect that
VOLUME_NAME_NT is always longer than VOLUME_NAME_DOS.
My justification for using VOLUME_NAME_NT is that the final name might not be
located on a DOS-accessible name. My
Jason R. Coombs added the comment:
In the case where I did use VOLUME_NAME_NT, I think I chose it because it
returned a more robust result. That is, it's not clear what the result is if
the result is not on a volume that is assigned a drive letter, but all files
referenced must h
Jason R. Coombs added the comment:
The big problem with adding the %python%\scripts directory to the path is it
makes a lot of assumptions about how Python is deployed.
And it raises some questions. What should the precedence be? What should happen
if multiple versions of Python are
Jason R. Coombs added the comment:
In msg108954, I believe belopolsky is mistaken in stating that "it would be
easy to simply provide custom __getinitargs__ or __reduce__ to support it". It
appears __getinitargs__ does not work on Python 2.5 or Python 2.7. Exceptions
of the follo
Jason R. Coombs added the comment:
After some further reading, I found that PEP-352
(http://www.python.org/dev/peps/pep-0352/) explicitly states that "Including
programmatic information (e.g., an error code number) should be stored as a
separate attribute in a subclass [and not in the
Jason R. Coombs added the comment:
I'm unsure. I think when I addressed the issue, I was only concerned with
symlinks. The Vista behavior sounds correct to me, so it may be that XP was
left with the legacy behavior as it doesn't have native symlink support. It
sounds as if the beha
New submission from Jason R. Coombs :
The Queue object has a maxsize parameter and attribute, but due to the test for
a full queue, shrinking the maxsize could result in the Queue not recognizing
that it is full.
The attached patch (against the Python 3 trunk) demonstrates this limitation
Jason R. Coombs added the comment:
I should point out that in Python 2.5, it was possible for a subclass to
override the _full method to account for this situation, but with Python 2.6
and later, the calculation in _full was hand-inlined... so it's not readily
possible for a subcla
Jason R. Coombs added the comment:
I'm not sure what our use case is. I discovered this when I was looking at our
project's util library, and we have a Queue subclass that overrides _full to
handle the scenario where the queue shrinks. I'm guessing it's being used to
dy
Jason R. Coombs added the comment:
Thanks!
--
___
Python tracker
<http://bugs.python.org/issue10110>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jason R. Coombs :
It appears that distutils isn't loading the authentication information from
.pypirc. I ran this test on Python 3.2 64-bit on Windows.
PS C:\Users\jaraco\projects\hgtools> python -m pdb setup.py sdist upload
> c:\users\jaraco\projects\hgtools
New submission from Jason R. Coombs :
It appears that with Python 3.2 (Windows 64-bit), the distutils upload -r
command no longer accepts the repository section name, but instead only
attempts to parse it as a URL. This is a regression from Python 2.7.
PS C:\Users\jaraco\projects\hgtools
Changes by Jason R. Coombs :
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue11473>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jason R. Coombs :
Consider the Python file
#!python
True = 1
False = 0
The 2to3 script returns an empty diff for this file.
These lines (especially when the values are canonical), are clearly for
backward compatibility to early Python 2.x editions (2.2.1 and
New submission from Jason R. Coombs :
Consider the Python file:
import _winreg
_winreg.foo
x = _winreg
Currently, 2to3 converts this to:
import winreg
winreg.foo
x = _winreg
The result will elicit a NameError on line 3 (if line 2 is valid). Is it
possible to support
Jason R. Coombs added the comment:
Agreed.
I encountered it in https://github.com/dottedmag/path.py, which has since been
"patched" by removing the compatibility clauses, but that means that Python
2.2.1 and earlier are no longer supported by the project.
If it's not worth
Jason R. Coombs added the comment:
Good call. Closing.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Jason R. Coombs added the comment:
This bug affects distutils2. See #11502.
--
nosy: +jaraco
___
Python tracker
<http://bugs.python.org/issue11276>
___
___
Pytho
Jason R. Coombs added the comment:
This bug also affects poster. http://bitbucket.org/jaraco/poster (httplib
reference in httpstreaming.py)
--
___
Python tracker
<http://bugs.python.org/issue11
Jason R. Coombs added the comment:
it looks like lib maintainers can work around the limitation by using the
syntax:
import _winreg as winreg
And then reference the name winreg (or any other preferred name).
--
___
Python tracker
<h
Changes by Jason R. Coombs :
--
nosy: +jaraco
___
Python tracker
<http://bugs.python.org/issue6792>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
That's interesting. You're saying that you've been using symlinked packages for
some time and that it works for you. I filed this bug because it's never worked
for me. Can you describe a little bit about the environment in which you&
Jason R. Coombs added the comment:
And since you seem to have some systems that honor symlinked packages, can you
run the attached test_import_symlink_package.py and report the results?
--
___
Python tracker
<http://bugs.python.org/issue6
Jason R. Coombs added the comment:
Thanks for that. The output is very telling.
First, it shows there's a bug in the test script where an exception occurs when
it succeeds because a .pyc file is created and not properly cleaned up.
Second, it demonstrates that the bug as I reported it i
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file14741/test_import_symlink_package.py
___
Python tracker
<http://bugs.python.org/issue6727>
___
___
Jason R. Coombs added the comment:
I updated the test script to avoid the error when the .pyc (or __pycache__) is
created.
--
Added file: http://bugs.python.org/file21959/test_import_symlink_package.py
___
Python tracker
<http://bugs.python.
Jason R. Coombs added the comment:
Confirmed the issue exists on Python 2.7 and 3.2
--
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue6
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file21959/test_import_symlink_package.py
___
Python tracker
<http://bugs.python.org/issue6727>
___
___
Jason R. Coombs added the comment:
Updated script to run under Python 3.2 as well.
--
Added file: http://bugs.python.org/file21962/test_import_symlink_package.py
___
Python tracker
<http://bugs.python.org/issue6
Jason R. Coombs added the comment:
Re msg125818, I agree that the mixed EOLs is also a potential problem, though
the proposed solution behaves better than the status quo, where the EOLs get
converted without warning.
It would be desirable for the patch to be more robust in that situation
Jason R. Coombs added the comment:
I've made some progress on this issue. Thanks to Waldemar's findings, I'm able
to selectively reproduce the issue by installing/uninstalling the Visual C++
redistributable that includes KB2467174 on a Windows 7 RTM installation.
So I a
Jason R. Coombs added the comment:
I decided to investigate further. I created another script to test the call to
_wstat to try to recreate the -1 return code, but I was unable to do so. I'm
attaching the script, which creates the same 'sample' package, but instead of
callin
Jason R. Coombs added the comment:
Digging deeper with the Visual Studio debugger, I discovered the following
interesting outcome (run with cmd.exe):
@echo off
mklink /d sample sample-target
mkdir sample-target
echo "" > sample-target\__init__.py
:: Bef
Jason R. Coombs added the comment:
Indeed, this appears to be a bug in stat64.c, specifically a regression in
KB2467174. If I look at the code for _wstat64i32, it doesn't have the code that
calls into _wsopen_s for symlinked files/dirs, so uses the legacy behavior to
stat the targ
101 - 200 of 1490 matches
Mail list logo
