New submission from Mark Hammond :
Comparing two paths, PurePath.relative_to fails with ValueError if the second
path is not in the first.
>>> Path('/a/b').relative_to('/a/b/c')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3
Change by Mark Hammond :
--
keywords: +patch
pull_requests: +21265
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22210
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Hammond :
install.c tries to dynamically load PyCFunction_New at
https://github.com/python/cpython/blob/fb2718720346c8c7a0ad2d7477f20e9a5524ea0c/PC/bdist_wininst/install.c#L686
- however, since 3.8 this no longer exists - PyCFunction_New is a #define
which calls
Mark Hammond added the comment:
Yes, while I appreciate the gesture, I am somewhat embarrassed these days - as
you say, many others deserve this more than me these days.
So please remove it.
--
___
Python tracker
<https://bugs.python.
Mark Hammond added the comment:
Can we get this mentioned somewhere? Eg,
https://www.python.org/downloads/release/python-390b3/ doesn't mention anything
about minimum versions. https://www.python.org/downloads/windows/ also has
prominent notices like "Note that Python 3.8.3rc1 c
Change by Mark Hammond :
--
nosy: +mhammond
___
Python tracker
<https://bugs.python.org/issue39631>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Hammond added the comment:
pywin32, up until recently, just listed 3 directories in its .pth file - these
were for directories which pre-dated packages and were never converted. Eg,
"import win32api" actually loads win32api.pyd from the "site-packages/win32"
New submission from Mark Hammond:
Received via email:
PEP-397 (PEP 397 -- Python launcher for Windows) says:
"""
The launcher installation is registered in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CurrentVersion\SharedDLLs with a
reference counter.
"""
The
Mark Hammond added the comment:
While I agree the risk is fairly low and it will require effort to actually do,
it still sounds worth fixing at some point. A user might be tricked into
downloading a DLL - eg, Firefox will happily save it without any scary UI -
it's just a file. Later they run
Mark Hammond added the comment:
> > This may well break things like pythonwin until they also grow support
> > for the new param
> I expect that, which is why I'm only proposing it for 3.6 onwards. While
> adding support for a new major version of Python should be fairly
Mark Hammond added the comment:
I've a few reservations here:
* CoInitialize will load a number of COM DLLs into the process, which isn't
free and will have some memory and performance costs for programs that don't
use COM. I see around 10 such DLLs loaded.
* pythoncom uses sys.coinit_flags
Mark Hammond added the comment:
> Mark said the "built binary links against the DLL version of the CRT
> but I just checked in 3.5.1 that you actually didn't switch that
> one to link against vcruntime140.dll like you did with everything else
Yeah, I didn't dig too much further
New submission from Mark Hammond:
Binaries created by bdist_wininst fail on 3.5+ for 2 reasons:
* The built binary links against the DLL version of the CRT. This means the
binary will typically fail to start as the CRT DLL isn't found.
* When looking for 32bit Python versions, it fails
New submission from Mark Hammond:
The launcher was recently updated to look in PCBuild/win32 to support the win32
binaries being built in this directory instead of the top-level PCBuild
directory. However, when this new launcher tries to find a binary for, say,
Python 2.7, it doesn't find
Mark Hammond added the comment:
> When is the launcher ever going to find Python built in-place?
On the machine that built Python in-place :) I have a dev environment where all
Python versions and pywin32 are built and that's the environment where py.exe
is failing. My build scripts
Mark Hammond added the comment:
It appears bdist_wininst wasn't updated for this so installed created by
distutils don't work in 32bit versions - is there a different bug open for
that? (Or I'm doing something wrong, but the installer fails and a quick scan
of the source doesn't seem
Mark Hammond added the comment:
Awesome, thanks, sorry I missed that.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25921>
___
__
New submission from Mark Hammond:
Revision 34b35aa1967d pushed new versions of wininst-14.8*.exe, but didn't
include the VS project files required to build it, thus meaning it can't
reasonably be built from the source tree.
--
components: Build
messages: 256823
nosy: mhammond
Mark Hammond added the comment:
> and the launcher was actually updated to match the registry key
> directly, rather than special-casing the "-32" suffix
It appears this has broken the launcher. A freshly-built py.exe from Python 3.5
doesn't seem to find older 32bit versions, w
Mark Hammond added the comment:
> The original naming ("3.5") can't be used because you can't
> simultaneously install 32-bit and 64-bit per-user Pythons with the same
> key name.
They will be in different nodes - the 32bit version would be under Wow6432Node.
The py.exe lau
Mark Hammond added the comment:
File redirection has nothing to do with win-unicode-console
Thank you, that comment is spot on - there are multiple issues being conflated
here. This bug is purely about the tty/console behaviour.
--
___
Python
Mark Hammond added the comment:
The crash you see is maybe not a crash at all.
I'd call it a crash - the repl shouldn't exit. But it's not necessarily part
of *this* bug.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Mark Hammond:
Python 3.3 and earlier have in methodobject.c:
/* PyCFunction_New() is now just a macro that calls PyCFunction_NewEx(),
but it's part of the API so we need to keep a function around that
existing C extensions can call.
*/
#undef PyCFunction_New
Mark Hammond added the comment:
I get the impression the first link just punted and the second supports the
fact many people would see it as an improvement.
So a patch that both works and addresses the concerns would probably be most
welcome
Mark Hammond added the comment:
I am trying to draw attention to the situation where the script has no
shebang line, and there is no other explicit configuration info for
py.exe.
In that case, the user should just type python scriptname.py - py.exe is for
cases where just specifying python
Mark Hammond added the comment:
Vinay's idea makes sense to me. Paul can also subtly change the patch such
that when SCRIPT_WRAPPER is defined, failure to find the wrapper is fatal and
prints a message specific to this fact rather than just starting an interactive
Python (assuming I read
Mark Hammond added the comment:
I don't understand the motivation for this - how will it be used in practice?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18491
Mark Hammond added the comment:
Obviously I'm missing a little context, but it seems a little wrong for the
same launcher to be doing this double-duty. It seems we only want to use the
launcher in this way as it already has some of the interesting code we need -
but the vast majority
Mark Hammond added the comment:
The problem is that Explorer displays the IDC_APPSTARTING icon when an app
launches, until that app does something ui-ish (eg, creating a window, fetching
a windows message). I could reproduce the problem on XP, and pushed a fix for
the launcher to
https
Mark Hammond added the comment:
If anyone would like to test the fix out, I've put a 32bit pyw.exe with the fix
at http://starship.python.net/crew/skippy/downloads/pyw.exe
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Mark Hammond added the comment:
The GIL state api was mainly interested in the case of a thread which has
(possibly) never been seen before calling into Python. IIUC, the proposal here
is so that a thread that *has* been seen before can be associated with a
thread-state specified
Mark Hammond added the comment:
To clarify, I wrote:
can be associated with a thread-state specified by the
embedding application
Where I meant to say:
Can be associated with an interpreter state and corresponding thread-state ...
Or something like that - it's been a while since I've
New submission from Mark Hammond skippy.hamm...@gmail.com:
Note the error message in the title is only for Python 2.x - Python 3.x shows
an empty string instead, but otherwise seems identical.
This was first brought to my attention via
http://sourceforge.net/tracker/?func=detailaid
Changes by Mark Hammond skippy.hamm...@gmail.com:
--
nosy: +mhammond
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1677
___
___
Python-bugs-list
Mark Hammond skippy.hamm...@gmail.com added the comment:
To clarify the second comment from Eric: it is actually the first of the
proposals that I consider controversial - moving where python.exe lives
(regardless of to where) will break 3rd party tools. If a decision was made to
move
Mark Hammond skippy.hamm...@gmail.com added the comment:
Tools that use the registry will typically look up the InstallPath key and look
for python.exe there. They will not look in sub-directories (except some may
look in PCBuild and PCBuild/amd64). It is exactly those tools I'm concerned
Mark Hammond skippy.hamm...@gmail.com added the comment:
Those instructions in section 5.4 do seem wrong. On first reading they imply
that you need to start with a clean source tree on your 32bit Windows, then
build the 64bit version of Python. So far so good. However, then you need to
run
Mark Hammond skippy.hamm...@gmail.com added the comment:
Can't you just install a 64bit Python in a different directory and use that
executable to build the 64bit installer? It seems less error prone and should
work without manually copying stuff or changing any code
Mark Hammond skippy.hamm...@gmail.com added the comment:
I don't quite understand how the order will be wrong. Which earlier entry is
causing the problem? OTOH though, I also don't quite understand how the build
would work at all if a 32bit Python is used to invoke distutils with
--plat
Mark Hammond skippy.hamm...@gmail.com added the comment:
I thought this shouldn't be a problem - that as pythonxx.dll contains a
manifest with the references and also contains hoops to ensure its activation
context is used when loading dynamic modules, that things should work
correctly
Mark Hammond skippy.hamm...@gmail.com added the comment:
Actually, I think this is OK - the reference to the x86 is in the tests and
those tests don't actually perform a build, just check the manifest is detected
and stripped (ie, the test should still work fine on 64bit boxes). Ideally
Mark Hammond skippy.hamm...@gmail.com added the comment:
See also http://bugs.python.org/issue13038 - same exception but in a different
content, but the underlying cause may be similar.
--
nosy: +mhammond
___
Python tracker rep...@bugs.python.org
New submission from Mark Hammond skippy.hamm...@gmail.com:
test_types.py converts types.StringTypes to str - but types.StringTypes is
a tuple, so expressions like type(x) in type.StringTypes fails after
conversion with TypeError: argument of type 'type' is not iterable
Attaching a fix
Mark Hammond skippy.hamm...@gmail.com added the comment:
ack - that is a really good point. IIRC it can be *. I'll try and look at
this over the next day or 2.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7833
Mark Hammond skippy.hamm...@gmail.com added the comment:
A manifest seems to be currently created fine - can you provide steps to
reproduce the problem you see?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13486
Mark Hammond skippy.hamm...@gmail.com added the comment:
I can't explain why this might be happening given the Python dll is still build
against vc9 - I'm guessing this can't be reproduced without vs10 in the mix?
Re making the feature optional - distutils doesn't really lend itself
Mark Hammond skippy.hamm...@gmail.com added the comment:
The first chunk of that patch is for when pythonhome==NULL. There is also a
similar block just under it when MS_WINDOWS is not defined. While I don't know
in which cases this will be built without that define, it looks as though
Mark Hammond skippy.hamm...@gmail.com added the comment:
I don't think a buildbot will be necessary - like the earlier compilers, they
may have basic support but they don't all get buildbot support. The problem
isn't the lack of ability/will to get things working with VS2010 - it is more
Mark Hammond skippy.hamm...@gmail.com added the comment:
I pushed the changes to 2.7, 3.2 and 3.3. I'm happy to help with
distutils2/packaging but I'll need to do that later once I work out where to
start :) Therefore I'm not yet closing this issue
Mark Hammond skippy.hamm...@gmail.com added the comment:
My experience is that for VS2008 at least, the /MANIFESTFILE: option seems to
be ignored if there is nothing to put in the manifest, and this tends to be
true if you use a static CRT instead of the DLL based one (ie, if you use /MT
Mark Hammond skippy.hamm...@gmail.com added the comment:
New version of the patch with the small tweaks requested plus a NEWS entry.
--
Added file: http://bugs.python.org/file23400/bug-7833-tweaks-plus-news.patch
___
Python tracker rep
Mark Hammond skippy.hamm...@gmail.com added the comment:
Thanks for the review. One note:
| +def manifest_setup_ldargs
| I’d make all new methods private ones (i.e. leading underscore).
They aren't strictly private and are designed to be overridden by subclasses
(although in practice
Mark Hammond skippy.hamm...@gmail.com added the comment:
My apologies Eric - I had completely overlooked those tests. Attaching a new
patch with a test. Note the existing test doesn't actually perform a build so
the new test also doesn't, but it does check the core logic (ie
Mark Hammond skippy.hamm...@gmail.com added the comment:
I'm reluctant to commit to adding test infrastructure for the distutils build
commands - if I've missed existing infrastructure and adding such tests would
actually be relatively simple, please educate me! Or if someone else would
like
Mark Hammond skippy.hamm...@gmail.com added the comment:
For some reason, IE is struggling to even display the page - it just seems to
sit there loading the page without displaying anything, but hitting stop then
refresh usually brings it up. But if you kill IE (which best I can tell can
Mark Hammond skippy.hamm...@gmail.com added the comment:
This is biting people (including me :) so I'm going to try hard to get this
fixed. One user on the python-win32 mailing list resorts to rebuilding every
3rd party module he uses with this patch to get things working again (although
Mark Hammond skippy.hamm...@gmail.com added the comment:
The most recent version of PEP397 has removed all mentioned of this reference
implementation - the C implementation at
https://bitbucket.org/vinay.sajip/pylauncher/ is now the reference.
--
resolution: - out of date
status
Mark Hammond skippy.hamm...@gmail.com added the comment:
Adding tests would be fairly painful - there is no test infrastructure in place
for generating and running installers at all, and worse, the changes are likely
to not work correctly when run from a Python build tree when the built DLL
Mark Hammond skippy.hamm...@gmail.com added the comment:
(OTOH though, I could tweak the patch to work in a built tree - it would mean
appending PCBuild to the dir and retrying the DLL load if the other options
fail...)
--
___
Python tracker rep
Changes by Mark Hammond skippy.hamm...@gmail.com:
--
assignee: tarek - mhammond
keywords: +patch
stage: - patch review
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22205/issue12200.patch
___
Python
New submission from Mark Hammond skippy.hamm...@gmail.com:
Probably in all versions, but certainly in 2.7.
If you create an installer with bdist_wininst and specify an install_script,
that script is not run on uninstallation.
See attached test case: setup.py specifies an install_script which
Changes by Mark Hammond skippy.hamm...@gmail.com:
Added file: http://bugs.python.org/file22161/hello.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12200
Changes by Mark Hammond skippy.hamm...@gmail.com:
Added file: http://bugs.python.org/file22162/hello-install.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12200
Mark Hammond skippy.hamm...@gmail.com added the comment:
As Tim Roberts says on the python-win32 list:
Actually, on closer examination, it may be a bit difficult to sell this. The
Microsoft compilers do not define this symbol at all. The SDK defines
SSIZE_T (as a long). Nothing defines
Mark Hammond skippy.hamm...@gmail.com added the comment:
It will return 1 if you specify a script to run and that has an unhandled
exception.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6498
Mark Hammond skippy.hamm...@gmail.com added the comment:
Good catch - new patch with PyRun_SimpleStringFlags() corrected too.
--
keywords: +patch
Added file: http://bugs.python.org/file21448/bug-6498.patch
___
Python tracker rep...@bugs.python.org
Mark Hammond skippy.hamm...@gmail.com added the comment:
Note the quoted documentation in comment 1, the paragraph Note that if an
otherwise unhandled SystemError ...
I don't think that paragraph is correct - SystemError doesn't seem to terminate
Py_Main - but if you replace SystemError
Mark Hammond skippy.hamm...@gmail.com added the comment:
@Rogi - you seem to have a problem with your keyboard - the 'h' and 'e' keys
seem to have been swapped.
The docs are wrong regardless - I don't think anyone would suggest the
behaviour match the docs regarding SystemError - having
Mark Hammond skippy.hamm...@gmail.com added the comment:
@Rogi - you might like to re-read my responses a couple more times:
* I refer to SystemError as the docs *you quoted* refer to SystemError.
Therefore, we should *not* make the implementation match the docs - the docs
would be wrong
Mark Hammond skippy.hamm...@gmail.com added the comment:
What teh docs says currently about SystemError calling
exit() is just _WRONG_.
Correct - the docs should be fixed - which is what this bug is currently
addressing (see the Components and Assigned To fields)
Also, I am not asking
Mark Hammond skippy.hamm...@gmail.com added the comment:
For completeness, here is a doc patch against 2.6 which corrects the
documentation.
--
keywords: +patch
Added file: http://bugs.python.org/file21447/bug-6498.patch
___
Python tracker rep
Changes by Mark Hammond skippy.hamm...@gmail.com:
--
keywords: +needs review -patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6498
Mark Hammond skippy.hamm...@gmail.com added the comment:
Isn't the only problem here that the docs refer to SystemError instead of
SystemExit - eg 'raise SystemError(foo)' in an interactive session doesn't
terminate the process at all (and I don't believe it should) whereas SystemExit
New submission from Mark Hammond skippy.hamm...@gmail.com:
A tracking bug for the reference implementation of PEP397 - A Python launcher
for Windows.
--
assignee: mhammond
components: Documentation
files: pep-0397-reference.py
messages: 131723
nosy: mhammond
priority: normal
severity
New submission from Mark Hammond mhamm...@users.sourceforge.net:
fileConfig has code to detect existing child loggers and ensure they are
enabled if the parent is configured. However, the approach it takes of sorting
the log names can fail in some cases. eg, if 3 loggers exist with names
Mark Hammond mhamm...@users.sourceforge.net added the comment:
Thinking more about this, I think the approach of this patch is more complex
than necessary. I think a better patch would be one which *unconditionally*
removes the manifest from extension modules. For maximum flexibility though
Mark Hammond mhamm...@users.sourceforge.net added the comment:
I'm wondering if, in practice, extensions which need a manifest can have the
manifest being generated completely by the linker - ie, I expect that in most
cases where something other than the CRT or MFC is needed in the manifest
Mark Hammond mhamm...@users.sourceforge.net added the comment:
I'm failing to get a new pywin32 out of the door due to this issue. I've spent
a few hours playing with this and I think the analysis is generally correct
here. The key thing is that when using distutils, the extensions end up
Mark Hammond mhamm...@users.sourceforge.net added the comment:
FWIW, I think the rules are fairly well explained in the comments in
PC/getpathp.c; last time I looked at this, the only thing I couldn't really
decide was where in the official docs these comments should be put (after
Mark Hammond mhamm...@users.sourceforge.net added the comment:
With the caveat that I haven't tested it (I'm currently traveling), the patch
looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8954
Mark Hammond mhamm...@users.sourceforge.net added the comment:
A quick check of my tree shows that the 32 and 64 bit versions are the same in
this regard - the raw stubs wininst-9.0.exe and wininst-9.0-amd64.exe do not
depend on the CRT. A test install of 2.6.5-amd64, then using the 64bit
Mark Hammond mhamm...@users.sourceforge.net added the comment:
Is it possible the installer is being run from a network share? A comment from
PC/bdist_wininst/install.c:
// interesting failure scenario that has been seen: initial executable
// runs from a network drive
Mark Hammond mhamm...@users.sourceforge.net added the comment:
I tried to use this in place of shlex for parsing IMAP responses for the
'imapclient' package. A couple of things struck me.
* The class no longer has a next() method but probably should be added for b/w
compat.
* The class
Mark Hammond mhamm...@users.sourceforge.net added the comment:
the pywin32 DLLs have 2 heads. They are Python extension modules as well as
regular DLLs. They are built by distutils and therefore have no manifests - I
think many packages use distutils to build their extension modules
Mark Hammond mhamm...@users.sourceforge.net added the comment:
Another consideration here will be how distutils will work in a python with
restricted permissions - the pattern of just run 'setup.py install' will not
work unless it is done from an elevated command-prompt. As I expect
Changes by Mark Hammond mhamm...@users.sourceforge.net:
--
nosy: +mhammond
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7833
___
___
Python-bugs
Changes by Mark Hammond mhamm...@users.sourceforge.net:
--
nosy: +mhammond
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6132
___
___
Python-bugs
Mark Hammond mhamm...@users.sourceforge.net added the comment:
Checked into the trunk as r72387 (after normalizing whitespace in
ntpath.py after the precommit-hook failed). Thanks Larry and Eric!
--
resolution: - fixed
status: open - closed
Mark Hammond mhamm...@users.sourceforge.net added the comment:
Should the DeprecationWarning for splitunc be a PendingDeprectionWarning
for 3.1 and get 'upgraded' in 3.2?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5799
Mark Hammond mhamm...@users.sourceforge.net added the comment:
This looks good to me.
My take on Guido's earlier notes are that they caused a problem in
practice, and the philosophical concerns added justification for
removing it. I'm yet to meet a Windows user with a philosophical
objection
Mark Hammond mhamm...@users.sourceforge.net added the comment:
So it looks like I broke the ability to override --build-lib :( Without
testing, I think you might also need to handle the cross-compile case -
the version may be the same, but the platform different. I know
distutils is a PITA so
Mark Hammond mhamm...@users.sourceforge.net added the comment:
+1 on the idea - it's not the first time I've forgotten that works on
platforms other than Windows. It appears the patch you attached is
reversed though (or its just way too early for me
Mark Hammond mhamm...@users.sourceforge.net added the comment:
It could also point to a python launcher, which reads the first line
What would that first line look like on Windows?
o:\src\python-2.6-svn\PCBuild\python.exe would be appropriate for my
machine, but I wouldn't really be happy
Mark Hammond mhamm...@users.sourceforge.net added the comment:
oops - this slipped off my radar. I agree with *both* Frederic and Tony
:) The module promises to raise an EnvironmentError, which is does.
However, the main killer from my POV is that a 'winerror' attribute is
likely
Mark Hammond mhamm...@users.sourceforge.net added the comment:
It is still present, but I'm not sure what problems can be seen due to
this so can't comment on its desirability. It would also introduce a
backwards compatability concern but I've not enough experience to know
how much of a problem
New submission from Mark Hammond mhamm...@users.sourceforge.net:
% py30 -c str(memoryview(bytearray((1,2,3
Traceback (most recent call last):
File string, line 1, in module
TypeError: __str__ returned non-string (type bytes)
The expected behaviour is that a string representation
Mark Hammond mhamm...@users.sourceforge.net added the comment:
Python shouldn't (IMHO) crahs, even if you give bogus input to
python functions.
But it doesn't actually crash does it? It throws an assertion dialog,
which sucks when the machine is unattended - which is why it is a
problem
Mark Hammond mhamm...@users.sourceforge.net added the comment:
Fair enough - but assertions are still disabled while your reference
count is 0, which is still while other arbitrary code is running.
While I agree this is an improvement, I'm afraid I'm not playing close
enough attention
Mark Hammond mhamm...@users.sourceforge.net added the comment:
I believe your new patch suffers the same problem. Consider the blocks
like:
+ /* turn off crt asserts on windows since we have no control over fd */
+ Py_BEGIN_CRT_ERROR_HANDLING
Py_BEGIN_ALLOW_THREADS
New submission from Mark Hammond mhamm...@users.sourceforge.net:
In bug 4804, there is some debate about how desirable it is for Python
to unconditionally disable all CRT assertions on Windows - however,
there is agreement that exposing the ability to enable and disable these
assertions via
1 - 100 of 179 matches
Mail list logo
