Jason R. Coombs added the comment:
Amaury, that was a good suggestion, but I did with Eric's help track down a
mechanism to test for the presence of the symlink creation privilege. I prefer
to have a proper check rather than to attempt to create one and test for the
failure message be
Jason R. Coombs added the comment:
Brian, thanks for the review. I really appreciate it. I'll fix all of the
identified issues.
> Lib/test/test_posixpath.py
> - Lines 365-366 - why check has_symlink() and immediately check it
> again?
In the unpatched code, there were two call
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file15933/windows symlink draft 19.patch
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16003/windows symlink draft 20.patch
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
Added file: http://bugs.python.org/file16178/windows symlink draft 21.patch
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16174/windows symlink draft 21.patch
___
Python tracker
<http://bugs.python.org/issue1578
Jason R. Coombs added the comment:
This latest patch (22) does some refactoring in test_posixpath to reduce
nesting, limit duplicated code, and skip failing tests on Windows.
The only task now is to address the failing tests in a limited user account.
--
Added file: http
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16178/windows symlink draft 21.patch
___
Python tracker
<http://bugs.python.org/issue1578
Jason R. Coombs added the comment:
This new patch (23) renames support.has_symlink and
support.skip_unless_has_symlink to "can_symlink". This more accurately reflects
the functionality.
--
title: Add os.link() and os.symlink() and os.path.islink() support for
Wind
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file15932/failures.txt
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Python-bug
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16180/windows symlink draft 22.patch
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16193/windows symlink draft 23.patch
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16194/windows symlink draft 24.patch
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16197/smime.p7s
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Python-bugs-list m
Jason R. Coombs added the comment:
I'm interested in finding a workaround for this issue in the next 24 hours. I
can also help contribute a test case. I'll investigate further.
--
nosy: +jaraco
___
Python tracker
<http://bugs.python.
Jason R. Coombs added the comment:
Attached is a patch against the py3k branch that fixes the issue by changing
the mode used to open the target script. It includes a unittest that elicits
the issue and validates the fix.
The patch should also probably be applied to the 31maint branch
Jason R. Coombs added the comment:
I personally make heavy use of the command line and continue to install python
to %ProgramFiles%. I find the space in the pathname to be a non-issue. After
%programfiles%\Python26 and %programfiles%\Python26\Scripts are added to the
path, and .py is added
Jason R. Coombs added the comment:
Martin: Would it be sufficient to copy the ACLs from %programfiles%, or would
it be better to hard-code the permissions from %programfiles% from a known
standard configuration? Is it known if the ACLs on %programfiles% in WinXP
differ from later platforms
New submission from Jason R. Coombs :
On Python 2.6 and Python 2.7a, calling ntpath.realpath(os.devnull) returns
'nul' (two backslashes followed by nul), which is not a valid filename.
This appears to have been fixed in Python 3.1, as on 3.1.1,
ntpath.realpath(os.devnul
Jason R. Coombs added the comment:
This bug does not exhibit in Python 3.1.1.
--
nosy: +jaraco
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue7
Jason R. Coombs added the comment:
Indeed, this is a duplicate. My search failed probably because ntpath.abspath
is ntpath.realpath.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Jason R. Coombs added the comment:
Attaching a test against trunk which elicits the error reported in this bug.
--
keywords: +patch
Added file: http://bugs.python.org/file16419/issue7909-test.patch
___
Python tracker
<http://bugs.python.
New submission from Jason R. Coombs :
Documentation for Python 2.6.5 and 3.1.2 both describe using the smtplib as so:
s = smtplib.SMTP()
s.sendmail(me, [you], msg.as_string())
s.quit()
However, this sample usage is incorrect and doesn't work in practice, because
s.connect
Jason R. Coombs added the comment:
It appears in r71882, the change was made in deference to issue4239.
--
___
Python tracker
<http://bugs.python.org/issue8
Jason R. Coombs added the comment:
According to issue4239#msg75355, the connect call is not required, but I
believe he is mistaken. The connect call is required unless the s object is
constructed with host/port parameters, in which case the call to connect
(without any parameters) will
Jason R. Coombs added the comment:
Matt, I hope you don't mind, but I added you as nosy on this issue as it
relates to a change you suggested.
--
nosy: +matt
___
Python tracker
<http://bugs.python.org/i
Jason R. Coombs added the comment:
I agree. I found the documentation very difficult to understand. The term
"top-level" can be confusing. Consider instead something like "search the
entire tree".
A few other comments about the documentation of findtext:
fin
Jason R. Coombs added the comment:
This latest patch (26) only merges the latest changes from the repo.
--
Added file: http://bugs.python.org/file16761/windows symlink draft 26.patch
___
Python tracker
<http://bugs.python.org/issue1578
Jason R. Coombs added the comment:
Is there a reason this didn't get reviewed for the 3.1.2 release? What steps
need to be taken to see that it makes it into a 3.1.3 release?
--
___
Python tracker
<http://bugs.python.org/i
New submission from Jason R. Coombs :
Using Windows 7 32-bit, and /branches/p...@79802.
When I run the test_tarfile from the regrtest script, often the first run will
succeed and subsequent runs will fail (though sometimes a first run will fail
and rarely a subsequent run will succeed). It
Jason R. Coombs added the comment:
My initial troubleshooting indicated to me that the intermittent test_tarfile
problem exists independent of the symlink patch, so it was not relevant to this
issue.
I've tried to do some more thorough troubleshooting, and this continues to be
my fi
Jason R. Coombs added the comment:
> To be clear, all of my tests were without any patches applied.
--
___
Python tracker
<http://bugs.python.org/iss
Jason R. Coombs added the comment:
I've tried reproducing this on a clean system and have thusfar been unable to.
I'll try to eliminate variables on the failing system and perhaps this will
elicit some information about what's causing the intermittent failures with the
Jason R. Coombs added the comment:
After grabbing a clean checkout, I'm unable to reproduce this problem where I
was seeing it earlier, so I suspect the problem is in fact related to one or
more lingering patches that were applied to the source. Please close this
ticket as in
Jason R. Coombs added the comment:
While trying to reproduce the transient test_tarfile errors, I found two more
tests that appear to be failing when symlinks cannot be created, now skipped by
patch 27.
--
Added file: http://bugs.python.org/file16809/windows symlink draft 27.patch
New submission from Jason R. Coombs :
While trying to work out a failing
test_platform.PlatformTest.test_architecture_via_symlink, I found a more
fundamental problem.
In the build environment, python.exe depends on pythonXX.dll being in the same
directory as sys.executable to load the
Jason R. Coombs added the comment:
This attached patch against the py3k branch adds a test that reproduces the
described behavior.
--
keywords: +patch
Added file: http://bugs.python.org/file16811/reproduction as test.patch
___
Python tracker
<h
Jason R. Coombs added the comment:
I've been fighting a failing test in test_platform (when
test.support.can_symlink() is True). Turns out the problem is caused by the
fact that the Python DLL cannot be resolved when the executable isn't in the
same directory (which is the case whe
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16196/windows symlink draft 25.patch
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16761/windows symlink draft 26.patch
___
Python tracker
<http://bugs.python.org/issue1578
Jason R. Coombs added the comment:
Thanks!
--
___
Python tracker
<http://bugs.python.org/issue8342>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
This patch includes a routine that adds the directory of the python executable
to the path before attempting to run a symlinked executable (in test_platform).
--
Added file: http://bugs.python.org/file16821/windows symlink draft 28.patch
Jason R. Coombs added the comment:
In the last patch, I addressed test_platform running a test under a symlinked
Python. I then found the same error resulting from essentially the same code in
test_sysconfig. So I refactored those methods into a generator method in
test.support. This is
Changes by Jason R. Coombs :
Added file: http://bugs.python.org/file16825/windows symlink draft 29.patch
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16809/windows symlink draft 27.patch
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16821/windows symlink draft 28.patch
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16824/windows symlink draft 28.patch
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
Added file: http://bugs.python.org/file16833/admin results - no patch.zip
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Changes by Jason R. Coombs :
Added file: http://bugs.python.org/file16834/admin results - patch 29.zip
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Jason R. Coombs added the comment:
With patch 29, I believe all patch-related test failures are corrected.
The remaining failures in some modules (namely test_tarfile, test_glob,
test_mailbox, test_warnings) can be demonstrated to occur in unpatched builds.
Since some failures are transient
Changes by Jason R. Coombs :
Added file: http://bugs.python.org/file16835/guest results - patch 29.zip
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16202/guest results.zip
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Python-bug
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file16203/admin results.zip
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Python-bug
Jason R. Coombs added the comment:
It seems issue7443 discusses the cause of the transient failures.
--
___
Python tracker
<http://bugs.python.org/issue1578
Changes by Jason R. Coombs :
--
nosy: +jaraco
___
Python tracker
<http://bugs.python.org/issue7443>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jason R. Coombs :
I'm using Python 3.1.2 64-bit on Windows.
I've found that even if "absolute_import" is imported from __future__, 2to3
will convert imports to be treated as relative.
To demonstrate this behavior, I created a small package "
Jason R. Coombs added the comment:
More importantly, is there a workaround for main.py that will work in Python 2,
and in Python 3 after 2to3, that doesn't require any module renaming?
--
___
Python tracker
<http://bugs.python.org/i
Jason R. Coombs added the comment:
I found a workaround by excluding the "import" fixer that seems to work.
For the example,
> 2to3 -x import abs_imp_test
The command still modifies main, but it only removes the __future__ directive
and doesn't modify the imports.
For my
Jason R. Coombs added the comment:
When I was working on a routine to checkout/patch/build/test/cleanup Python
(see https://svn.jaraco.com/jaraco/python/jaraco.develop, and particularly
scripts/test-windows-symlink-patch.py), I ran into a similar problem during the
cleanup step. I tried
New submission from Jason R. Coombs :
When trying to create a sub-subclass of a ctypes.Structure, the behavior
is not as expected.
An executable example that describes the problem in detail and
demonstrates the issue is available at
http://paste.turbogears.org/paste/29555 and also attached
New submission from Jason R. Coombs :
Using Python 2.6.1, I'm unable to pickle a simple object with an array
of wide characters.
import ctypes, pickle
class MyStruct(ctypes.Structure):
_fields_ = [('name', ctypes.c_wchar*2)]
s = MyStruct('DC')
pickle.dumps(s) # ra
Jason R. Coombs added the comment:
I just discovered that trying to pickle a structure with even just a
c_wchar (not an array) also fails.
--
title: ctypes unwilling to allow pickling wide character array -> ctypes
unwilling to allow pickling wide charac
New submission from Jason R. Coombs :
Using Python 2.5.4 and Python 2.6.1 on 32-bit python, when passing a
regular string to a function expecting pointer to a wide string
(wintypes.LPCWSTR), the function executes without problems.
When calling the same using Python 2.6.1 on 64-bit windows, the
Jason R. Coombs added the comment:
After putting together a more simple example without externalities, I'm
unable to continue to assert the discrepancy between 32 and 64-bit
Windows, although I do still see where narrow character strings are
treated as wide character buffers.
See the att
Jason R. Coombs added the comment:
Or alternately, is it possible (and reasonable) for ctypes to inspect
the function signature and create wide character buffers when appropriate?
___
Python tracker
<http://bugs.python.org/issue5
Jason R. Coombs added the comment:
I've confirmed that my original assumption was quite false, and that
even if the parameters are the correct width, WNetAddConnection2W
behaves differently in 64-bit windows versus 32-bit windows, so it made
a bad test case.
So I've changed the tit
Jason R. Coombs added the comment:
I see this in the documentation, which basically answers the question:
"windll does not try to select [wide or narrow functions] by magic, you
must access the version you need by specifying GetModuleHandleA or
GetModuleHandleW explicitely, and then ca
Jason R. Coombs added the comment:
Thanks for the excellent suggestion.
Please close this issue.
___
Python tracker
<http://bugs.python.org/issue5119>
___
___
Python-bug
Jason R. Coombs added the comment:
As a workaround, could you use ctypes to pull the environment back into
the python context? For example:
http://paste.turbogears.org/paste/34734
--
nosy: +jaraco
___
Python tracker
<http://bugs.python.
Jason R. Coombs added the comment:
I'm in support of adding Path support for sys.path, but I also agree with Eric,
there are innumerable consumers of sys.path beyond importlib. and since
pathlib.Path isn't a str, it would likely introduce incompatibility. On the
other h
Jason R. Coombs added the comment:
The behavior you describe is intentional _and_ deterministic. The library
discovers distributions in the order found based on the search path provided,
with the search path defaulting to sys.path.
The expectation is therefore that the metadata should be
Jason R. Coombs added the comment:
Aha. I learned how to run commands in the poetry environment... and how to
locate files in that environment. With that, I figured out where the
environment is and where the package metadata is coming from:
```
$ docker run -it @$(docker build -q .) bash -c
Change by Jason R. Coombs :
--
assignee: -> jaraco
___
Python tracker
<https://bugs.python.org/issue47004>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Jason R. Coombs :
Importlib_metadata 4.11.1-3 introduced a few bug fixes. Importantly, 4.11.2
fixed a [serious
defect](https://github.com/python/importlib_metadata/issues/369). Let's
incorporate those fixes into CPython.
--
messages: 415075
nosy: jaraco
pri
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +29952
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31854
___
Python tracker
<https://bugs.python.org/issu
Jason R. Coombs added the comment:
New changeset b1e286860742e7ba6fadc75e3ddb6c2899a56919 by Jason R. Coombs in
branch 'main':
bpo-47004: Sync with importlib_metadata 4.11.3. (#31854)
https://github.com/python/cpython/commit/b1e286860742e7ba6fadc75e3ddb6c
Change by Jason R. Coombs :
--
pull_requests: +29955
pull_request: https://github.com/python/cpython/pull/31857
___
Python tracker
<https://bugs.python.org/issue47
Change by Jason R. Coombs :
--
pull_requests: +29957
pull_request: https://github.com/python/cpython/pull/31859
___
Python tracker
<https://bugs.python.org/issue47
Jason R. Coombs added the comment:
New changeset d929aa70e2a324ea48fed221c3257f929be05115 by Jason R. Coombs in
branch '3.10':
[3.10] bpo-47004: Sync with importlib_metadata 4.11.3. (GH-31854). (GH-31857)
https://github.com/python/cpython/commit/d929aa70e2a324ea48fed221c3257f
Jason R. Coombs added the comment:
New changeset 177be52517da9a876a3f9e670f88c4731b906986 by Jason R. Coombs in
branch '3.9':
[3.9] bpo-47004: Sync with importlib_metadata 4.11.3. (GH-31854). (GH-31859)
https://github.com/python/cpython/commit/177be52517da9a876a3f9e670f88c4
Change by Jason R. Coombs :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jason R. Coombs :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jason R. Coombs added the comment:
See https://github.com/pypa/setuptools/issues/3007#issuecomment-1068621865
where I did a brief analysis and probable explanation.
What it boils down to: Setuptools needs to supply its own copy of distutils
aggressively. It provides an opt out for this
Jason R. Coombs added the comment:
I'd advocate for not supporting bytes paths and instead updating the
documentation to require strings.
--
nosy: +jaraco
___
Python tracker
<https://bugs.python.org/is
Jason R. Coombs added the comment:
Thanks for the report.
Yes, the issues are related, where .version and .name returning None are
specific manifestations of the metadata not having that key and the behavior
being ill-defined.
I haven't yet decided if metadata items being undefined s
Change by Jason R. Coombs :
--
assignee: -> jaraco
___
Python tracker
<https://bugs.python.org/issue47060>
___
___
Python-bugs-list mailing list
Unsubscrib
Jason R. Coombs added the comment:
Closing without prejudice. Happy to revisit if there's more information on how
importlib could/should behave differently.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://b
Jason R. Coombs added the comment:
I'm going to close this issue again, as the implementation is now present in at
least a couple of releases. May I suggest that if there are ongoing concerns or
issues to open up a new issue and reference this one and loop me into the
conversation? I&#
Change by Jason R. Coombs :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jason R. Coombs added the comment:
In an attempt to replicate Terry's usage, I added the following patch:
```
diff --git a/Lib/idlelib/idle_test/test_text.py
b/Lib/idlelib/idle_test/test_text.py
index 0f31179e04..be977bbfff 100644
--- a/Lib/idlelib/idle_test/test_text.py
+++ b/Lib/id
Jason R. Coombs added the comment:
Inada, you're right. Good catch. I think I missed that behavior from before
because I used `grep ERROR` and when I ran it this time, I just assumed the
output would be the same, but it's clear that even _with descriptions enabled_,
the location o
Jason R. Coombs added the comment:
I ran into this same issue. I notice that gettext is a dependency of git, so a
common dependency when developing. Is there perhaps a way that CPython could be
made to ignore gettext on macos Silicon or to detect an incompatible platform
and thus ignore it
Jason R. Coombs added the comment:
And indeed, after removing the `grep ERROR` part of the repro, even the repro
seems to be invalid:
```
cpython main $ ./python.exe -m test.test_importlib -v -k
test_entry_points_unique
test_entry_points_unique_packages
Jason R. Coombs added the comment:
Well, I'm using a mac with gettext installed as part of `brew install git` with
homebrew installed using the standard procedure.
Only after running `brew remove --ignore-dependencies gettext` and re-running
configure/make did the command build, but
Jason R. Coombs added the comment:
SG. Thanks for the advice. I'll dive in and experiment and report back when I
have progress.
--
status: closed -> open
___
Python tracker
<https://bugs.python.org
Jason R. Coombs added the comment:
I did [this
search](https://www.google.com/search?q=gittext+homebrew+"ld%3A+symbol(s)+not+found+for+architecture+arm64"),
which surfaced a few related results.
[This
article](https://lifesaver.codes/answer/pyenv-arm64-builds-confused-by-x86-64-
Jason R. Coombs added the comment:
As suggested, I uninstalled and reinstalled everything in homebrew:
$ brew list | xargs brew remove
$ brew install [email protected] python-launcher [email protected] [email protected] gh git
Even after following those steps and setting LDFLAGS and CPPFLAGS to point to
`brew
Jason R. Coombs added the comment:
Aha. If I configure/make without LDFLAGS or CPPFLAGS set, compilation works.
Then I noticed for `LDFLAGS`, some users were using `-L`. I thought it was
slightly odd that my recipe was using `-I` for both flags. How is it that [this
mistake](https
Jason R. Coombs added the comment:
It's possible my bad experience may have been avoided through issue35905.
--
___
Python tracker
<https://bugs.python.org/is
Jason R. Coombs added the comment:
I've confirmed that prior to the patch in PR 30194, the location of the failure
was indeed reported. It was just not reported on the same line:
```
cpython main $ git log -1
commit 3e93af0b06cada874c4a16868b6f863b599919f2 (HEAD -> main)
Author:
601 - 700 of 1863 matches
Mail list logo
