Mark Hammond added the comment:
I can confirm the code in question was removed and that long filenames
are possible in 2.5. Eg:
import os
p = "?\\" + os.getcwdu()
for i in range(10):
p = os.path.join(p, 'x' * 100)
os.mkdir(p)
os.stat(p)
print len(p)
I don&#
Changes by Mark Hammond:
--
nosy: +mhammond
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1455>
__
___
Python-bugs-list mailing list
Unsubs
Mark Hammond 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
apps which use only bu
Mark Hammond 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 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 to hel
Mark Hammond 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, that a
manifest with only
Mark Hammond 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, subclassing the com
Mark Hammond 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
<http://bugs.python.org/issue7
Mark Hammond 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)
Issue 7833 has a patch
Mark Hammond 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 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 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 the
*buf++ = DELIM; s
Mark Hammond 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 to
customizi
Mark Hammond added the comment:
A manifest seems to be currently created fine - can you provide steps to
reproduce the problem you see?
--
___
Python tracker
<http://bugs.python.org/issue13
New submission from Mark Hammond :
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 just appends
argv to
Changes by Mark Hammond :
Added file: http://bugs.python.org/file22161/hello.py
___
Python tracker
<http://bugs.python.org/issue12200>
___
___
Python-bugs-list mailin
Changes by Mark Hammond :
Added file: http://bugs.python.org/file22162/hello-install.py
___
Python tracker
<http://bugs.python.org/issue12200>
___
___
Python-bugs-list m
Changes by Mark Hammond :
--
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 tracker
Mark Hammond 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 is
not inst
Mark Hammond 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
<http://bu
Mark Hammond 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: open ->
Mark Hammond 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,
we should probably allow a
Mark Hammond 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, the
author will wa
New submission from Mark Hammond :
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 like
"bar&qu
New submission from Mark Hammond :
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: normal
status: open
Mark Hammond 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)
Mark Hammond 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 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 -
Mark Hammond 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 *even if* we change Python
Mark Hammond 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
Mark Hammond 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
<http://bugs.python.
Changes by Mark Hammond :
--
keywords: +needs review -patch
___
Python tracker
<http://bugs.python.org/issue6498>
___
___
Python-bugs-list mailing list
Unsub
Mark Hammond added the comment:
It will return 1 if you specify a script to run and that has an unhandled
exception.
--
___
Python tracker
<http://bugs.python.org/issue6
Mark Hammond 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
<http://bugs.python.org/issue6
Mark Hammond 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 ssize_
Mark Hammond 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 with a
manifest (
Mark Hammond <[EMAIL PROTECTED]> added the comment:
pywin32 has a 'winerror' module, which is (basically) a h2py generated
module from the same header (although initially generated roughly a
decade ago and hand-tweaked since then). Its unfortunate pywin32 still
hasn't adopt
Mark Hammond <[EMAIL PROTECTED]> added the comment:
What should struct.calcsize() do with a 'p' format string?
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://
New submission from Mark Hammond <[EMAIL PROTECTED]>:
A number of tests are designed to be skipped on 64bits, but they don't
detect 64bit windows builds as 64bits. Also, test_bytes.test_repeat()
assumes sys.maxint bytes can't be allocated, which isn't necessarily
true on Wi
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3617>
___
___
Python
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Obviously IANAL, but my reading of eula.txt included with VS9 seems less
restrictive than the 2003 one. It has 2 clauses that seem relevant:
* [you must] require distributors and external end users to agree to
terms that protect it at
Mark Hammond <[EMAIL PROTECTED]> added the comment:
MAL:
> This was already discussed on the PSF members mailing list.
Yeah, but not specifically about VS2008 which this bug seemed to be
specifically targetting. FWIW, this appears like *less* of a problem
for 2.6 than for 2.4 and
New submission from Mark Hammond <[EMAIL PROTECTED]>:
[from python-dev]
I've found a recursion related crash in test_cpickle on 64bit builds.
Specifically, the 'cPickleDeepRecursive' is causing a stack overflow,
and the debugger tells me the actual recursion depth was 6
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
assignee: -> mhammond
keywords: +64bit
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I forgot about sys.maxsize - that makes things much cleaner, and even
means I don't need to skip the check for insane amounts of memory.
If you think this is OK, please also specifically say if you approve for
me to check it into tr
Mark Hammond <[EMAIL PROTECTED]> added the comment:
It looks like I made a dupe at http://bugs.python.org/issue3625, where I
reported the same thing on 64bit windows (and 2 other cases that I'd be
interested to know if cause problems for you too...)
--
nosy
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Thanks. Checked into the trunk in r65986
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Sorry for the initial noise - your analysis is correct, mine was flawed
:) Simple recursion to a depth of 1000 does work fine on a 64bit build.
cpickle.patch does make test_cpickle pass for me. FWIW,
find_recursionlimit.py now ca
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3566>
___
___
Python
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I stumbled across this when mimetools import of test failed due to
finding a local test package, not the python test package, so I too will
be happy to see this fixed.
--
nosy: +mhammond
___
New submission from Mark Hammond <[EMAIL PROTECTED]>:
It appears r66103 introduced a regression - file objects are treated as
having an encoding, so non-ascii data fails. It was further complicated
by the fact that file objects in 2.6 have an 'encoding' attribute, but
by default
Changes by Mark Hammond <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11370/logging_encoding.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I instrumented the code a little. The error is happening because
self.client_startupdone never gets set to True. This is supposed to be
set in the client_startupdone() method. It expects an event type of
db.DB_EVENT_REP_STARTUPDONE,
Mark Hammond <[EMAIL PROTECTED]> added the comment:
As discussed with Barry on #python-dev, I committed r66498 which skips
the failing assertion on Windows and replaces it with some noise to
stderr. Note that only that one assertion fails - the rest of the test
passes on Windows.
Also,
Mark Hammond <[EMAIL PROTECTED]> added the comment:
We are seeing one more error almost identical to the one I fixed (even
the method name is the same), but its at line 315 - this is the last
error in the Windows buildbot! Please let me know if you would like me
to make a similar "f
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Actually, I've decided to leave it alone. The buildbots most recent
failure was:
test test_bsddb3 failed -- Traceback (most recent call last):
File
"S:\buildbots\python\trunk.nelson-windows\build\lib\bsddb\test\test_repli
Mark Hammond <[EMAIL PROTECTED]> added the comment:
pywin32 has a number of files that break in this way - often files
generated by h2py.py
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The following source file:
"""
import _winreg
_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "foo")
"""
results in the following "patch":
-import _winreg
-_winreg.OpenKey(_winreg.H
New submission from Mark Hammond <[EMAIL PROTECTED]>:
Create an empty directory with only 2 files, foo.py and bar.py, both
exactly 1 line:
foo.py:
|from bar import bar
bar.py:
|bar = "bar"
Running 2to3 results in the following patch for foo.py:
-from bar import bar
+from
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I must be going crazy, but I can't see r66707 in the trunk, the py3k
branch, or anywhere else in the svn tree. Can you please lend me a
clue-stick?
___
Python tracker <[EMAIL PRO
New submission from Mark Hammond <[EMAIL PROTECTED]>:
All the exception handlers i dustutils.file_utils._copy_file_contents()
are of the form:
|except os.error as e:
|(errno, errstr) = e
This fails to unpack the exception in py3k. I'm attaching a patch that
uses exception
Mark Hammond <[EMAIL PROTECTED]> added the comment:
r66806 on the py3k branch.
--
assignee: -> mhammond
resolution: accepted -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://b
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The way build_py uses lib2to3 is out of date. Instead of a dummy
Options object a dict should be used, and it seems the 'fixers' must
explicitly be loaded. I'm afraid I don't have a specific patch as I
don't
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The distutils commands 'build_scripts' and 'install_data' both may end
up installing .py files. Such .py file should be able tobe run through
lib2to3 in the same way supported by build_py.
pywin32 has en
Mark Hammond <[EMAIL PROTECTED]> added the comment:
r=me - thanks.
--
keywords: -needs review
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1284316>
___
__
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4091>
___
___
Python
Changes by Mark Hammond :
--
nosy: +mhammond
___
Python tracker
<http://bugs.python.org/issue7833>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Hammond 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 - it is just
that they usually don&#
Mark Hammond 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 this would
f
Mark Hammond 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 no longer has a 't
Mark Hammond added the comment:
I'm not sure why the approach of "load-em-all" is being taken.
Interestingly, SHGetFolderPathW is listed as deprecated, so I doubt that
list will grow too much, but the implementation as specified prevents
the user from using other facilities av
New submission from Mark Hammond <[EMAIL PROTECTED]>:
I've taken the liberty of adding Trent, Christian and Martin to the nosy
list as I know they are actively, if reluctantly interested in this.
This patch allows the distutils to cross-compile on Windows. It has
been tested on x8
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Hi Marc-Andre,
The PCBuild/README.txt file has some info about compatibility with VS
versions (but probably needs to say more about x64 builds). There is
also talk about releasing "Profile Guided Optimization" built bina
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I'd like to keep this issue specifically about cross-compilation in the
current tree, and while some of the other ideas may have merit, let's
not bog this issue down with them unless they directly impact the patch.
Does
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Been sitting here for a while without comment, so:
Sending_winreg.c
Committed revision 62180.
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PR
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The move to vs2008 has caused .manifest files to be created next to
distutils created extensions modules, rather than being embedded as
recommended by Microsoft.
See http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx
The at
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Checked in r62197, including the patch from Thomas. Note I expanded the
patch to the distutils doc (noting you need to build Python itself for
the target platform before it works) and added a short entry to Misc/NEWS
--
reso
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I can repro this too using python-2.6a2.msi - after selecting "just for
me" on XP running as a non-admin user, I see an error message regarding
permissions. On vista, I get an elevation prompt (and if I hit "allow",
i
New submission from Mark Hammond <[EMAIL PROTECTED]>:
The attached patch adds basic UAC support to bdist_wininst created
installers. A new option '--user-access-control' has been added to
bdist_wininst, which is written to the INI file read by the installer.
The installer read
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Note that we are actually using the linker to *generate* the manifest
(something linkers pre VC2005 couldn't do), so if we could tell the
linker to skip that manifest generation and embed it directly in the
DLL, it would certainl
Mark Hammond <[EMAIL PROTECTED]> added the comment:
For those trying to follow along at home: best I can tell we have 3
other issues on this: #1092502 and #1389051 are dupes of an initial bug,
but the fix for those bugs caused regressions reported in this bug and
in #2632. To try and
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2601>
__
___
Python-b
Changes by Mark Hammond <[EMAIL PROTECTED]>:
--
resolution: -> duplicate
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2601>
__
___
Python-b
Mark Hammond <[EMAIL PROTECTED]> added the comment:
FYI, #2632 is tracking a regression caused by this change.
--
nosy: +mhammond
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
New submission from Mark Hammond <[EMAIL PROTECTED]>:
As per a thread on python-dev, I offered to add sys.iswow64process. I'm
attaching a patch that does this (including news, docs and tests). I'm
adding Martin to the nosy list as he has expressed reservations ("It
sound
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Checked in as r62636
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I'm not sure if that is suggesting MS had no reason to add that API
function, or those reasons don't apply to users of Python, but as its
clear there is significant resistance I'm rejecting this report.
--
res
Mark Hammond <[EMAIL PROTECTED]> added the comment:
> I'm skeptical about adding build_data support, as it's not
> obvious what files would need conversion.
All .py files should be converted. I can't think why a project would
use this 2to3 capability for script
Mark Hammond <[EMAIL PROTECTED]> added the comment:
Thinking more about data_files, I'd agree that blindly converting all
.py files and nothing more isn't as useful for install_data as the other
commands. It might make more sense to allow data_files to specify a
list of patte
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I don't see a problem with this and can see how it would help with
private assemblies.
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Hammond <[EMAIL PROTECTED]> added the comment:
I can see how this might be useful, but I agree it should not happen by
default, at least until it has been out for a while and feedback is
clear that people do want it by default.
I'd also like to find a way to pass all args, n
Mark Hammond added the comment:
I've no time to dig deeper now as I suspect testing will require removal
of the vc9 assembly from the GAC and testing with a local one, but some
comments:
test.c's error is "can't find the DLL" - this will be as we attempt to
load Pyth
Mark Hammond added the comment:
I meant to mention: FWIW, *some* py2exe apps work fine with the old
scheme - specifically, IIUC, any app will work fine so long as the .pyd
files were next to the executable, which is next to the assembly. I
understand this is a significant restriction, but its
New submission from Mark Hammond :
This block in exceptions.c:
#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__)
...
/* turn off assertions in debug mode */
prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0);
#endif
Does exactly what the c
Mark Hammond added the comment:
I've hacked together something that fixes the problem. I'm working on
making it a real patch, but the basis is:
* In DllMain (dl_nt.c), we call:
case DLL_PROCESS_ATTACH:
GetCurrentActCtx(&PyWin_DLLhActivationContext);
Mark Hammond added the comment:
It would be interesting to know which tests actually fail. If the tests
are explicitly checking a bad fd, then IMO it makes more sense for that
test to simply be avoided in debug builds and nothing of value would be
left untested. OTOH, I'd also be happy
Mark Hammond added the comment:
I guess another option is to expose it via msvcrt and let the test
themselves disable it?
___
Python tracker
<http://bugs.python.org/issue4
Mark Hammond added the comment:
Attaching a patch which works for me against python 2.6. Only ever
tested on Vista (ie, where the function pointers etc all load)
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file12536/bug4566.patch
Changes by Mark Hammond :
Removed file: http://bugs.python.org/file12536/bug4566.patch
___
Python tracker
<http://bugs.python.org/issue4566>
___
___
Python-bugs-list m
1 - 100 of 184 matches
Mail list logo
