Tim Golden added the comment:
> I don't see why the wmi module ( https://pypi.org/project/WMI/ ) can't be
> used instead to get the information
Well I can speak here as the author of that module and as an (occasional) core
developer. The wmi module stands on the shoulderes of the p
Change by Tim Golden :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Golden added the comment:
New changeset 7bddd96982072d04bd6314da1ee7f40b7f875f00 by Tim Golden in branch
'main':
bpo-45621: Small changes to mmap (GH-29247)
https://github.com/python/cpython/commit/7bddd96982072d04bd6314da1ee7f40b7f875f00
Change by Tim Golden :
--
keywords: +patch
pull_requests: +27511
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29247
___
Python tracker
<https://bugs.python.org/issu
New submission from Tim Golden :
Following issue40915 a few small items still need to be addressed, mostly
cosmetic / naming:
* A comment should have been removed but wasn't
* A comment should have been added but wasn't
* The use of the string "TEST" should be avoided in tests pa
Change by Tim Golden :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Golden added the comment:
New changeset aea5ecc458084e01534ea6a11f4181f369869082 by Tim Golden in branch
'main':
bpo-40915: Fix mmap resize bugs on Windows (GH-29213)
https://github.com/python/cpython/commit/aea5ecc458084e01534ea6a11f4181f369869082
Change by Tim Golden :
--
keywords: +patch
pull_requests: +27477
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29213
___
Python tracker
<https://bugs.python.org/issu
Change by Tim Golden :
--
resolution: later -> duplicate
superseder: -> multiple problems with mmap.resize() in Windows
___
Python tracker
<https://bugs.python.org/
Tim Golden added the comment:
Superseded by issue40915
--
___
Python tracker
<https://bugs.python.org/issue2733>
___
___
Python-bugs-list mailing list
Unsub
Change by Tim Golden :
--
resolution: -> later
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue2733>
___
Change by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<https://bugs.python.org/issue40915>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Golden added the comment:
(switching stage to resolved because it's closed/rejected; sorry for the noise)
--
stage: -> resolved
___
Python tracker
<https://bugs.python.org/issu
Tim Golden added the comment:
https://bugs.python.org/issue40915 is related
Retargetting for 3.10+
--
assignee: -> tim.golden
versions: +Python 3.10, Python 3.11 -Python 2.7, Python 3.2
___
Python tracker
<https://bugs.python.org/iss
Tim Golden added the comment:
Closing this as out-of-date. The original bug was reported against 2.7 and
Win8, both of which are either end-of-life now.
No follow up in 9 years and I'm quite certain that modern Pythons handle all
manner of Unicode chars on the console
Tim Golden added the comment:
Closing as no longer reproducible in the current codebase on my current laptop
--
resolution: -> not a bug
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<https://bugs.python.org/issue40912>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Golden added the comment:
Thanks, Eryk. I've had a couple of casts at this (and also with an eye to
https://bugs.python.org/issue40912 in a very similar area).
Trouble is I can't come up with a way of adding a set.. function which doesn't
seem wholly artificial, given that it's
Change by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<https://bugs.python.org/issue40913>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Golden added the comment:
Thinking about testing here.. is there any straightforward way to cause
WaitForSingleObjectEx to fail?
The code change would be fairly slight and amenable to inspection, but it would
be good to actually test
Tim Golden added the comment:
This is the existing issue https://bugs.python.org/issue37945 which I haven't
had time to progress. Please feel free to follow up
--
___
Python tracker
<https://bugs.python.org/issue38
Tim Golden added the comment:
This feels like one of those changes where what's in place is clearly flawed
but any change seems like it'll break stuff which people have had in place for
years.
I'll try to look at a least-breaking change but I'm honestly not sure what that
would look like
Tim Golden added the comment:
I agree that that could be a fix. And certainly, if it turns out that this
could never have (recently) worked as Eryk is suggesting, then let's go for it.
But I still have this uneasy feeling that it's not failing on the buildbots and
I can't see any sign
Tim Golden added the comment:
Thanks, Eryk. Your explanation is as clear as always. But my question is, then:
why is my machine failing this test [the only one which uses this two-part
locale] and not the buildbots or (presumably) any other Windows developer
Tim Golden added the comment:
Just to save you looking, the code in
https://github.com/python/cpython/blob/master/Modules/_localemodule.c#L107
converts the 2-tuple to lang.encoding form so the C module is seeing
"en_GB.cp1252"
--
Tim Golden added the comment:
Ok; so basically this doesn't work:
import locale
locale.setlocale(locale.LC_CTYPE, locale.getdefaultlocale())
It gives "locale.Error: unsupported locale setting" which comes from
https://github.com/python/cpython/blob/master/Modules/_localemod
New submission from Tim Golden :
On a Win10 machine I'm consistently seeing test_locale (and test__locale) fail.
I'll attach pythoninfo.
==
ERROR: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous
Tim Golden added the comment:
Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 03:37:03) [MSC v.1900 64 bit
(AMD64)] on win32
I can't reproduce this on Windows. And it does seem an unlikely combination of
effect and cause.
Do I take it that if you take out all the "logging...&q
Tim Golden added the comment:
I'm afraid you'll have to use English in this forum so that all current and
future readers have the best chance of understanding the situation. Thank you
very much for making the effort this far.
If anyone on this issue knows of a Chinese-language forum where
Change by Tim Golden :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Golden added the comment:
Thanks for the information, eryksun.
For the moment, I can only say with a fair degree of certainty that using the
tempfile functions as I have in test_bz2 & test_mmap appears to solve the issue
which is repeatably if intermittently present without that ch
Tim Golden added the comment:
New changeset 6a62e1d365934de82ff7c634981b3fbf218b4d5f by Tim Golden in branch
'master':
bpo-34239: Convert test_bz2 to use tempfile (#8485)
https://github.com/python/cpython/commit/6a62e1d365934de82ff7c634981b3fbf218b4d5f
Change by Tim Golden :
--
keywords: +patch
pull_requests: +8008
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34240>
___
___
Python-
New submission from Tim Golden :
test_mmap currently uses the test.support.TESTFN functionality which creates a
temporary file local to the test directory named around the pid.
This can give rise to race conditions where tests are competing with each other
to delete and recreate the file
Change by Tim Golden :
--
keywords: +patch
pull_requests: +8007
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34239>
___
___
Python-
New submission from Tim Golden :
test_bz2 currently uses the test.support.TESTFN functionality which creates a
temporary file local to the test directory named around the pid.
This can give rise to race conditions where tests are competing with each other
to delete and recreate the file
Tim Golden added the comment:
New changeset ff64add8d4be2e37c552ba702f629b0b6639cd33 by Tim Golden in branch
'master':
bpo-34195: Fix case-sensitive comparison in test_nt_helpers (GH-8448)
https://github.com/python/cpython/commit/ff64add8d4be2e37c552ba702f629b0b6639cd33
Tim Golden added the comment:
Test fixed to ignore case and volume differences between paths
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Tim Golden :
--
keywords: +patch
pull_requests: +7970
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Tim Golden added the comment:
I think I've got down to the determining factor. For info:
PYTHONHOME has nothing to do with it: the same thing happens if I cd into
PCBuild\win32 and run python_d.exe directly
For historical reasons the directory in which I'm building
(c:\work-in-progress
Tim Golden added the comment:
@eryksun almost idly I ran your ctypes code in the built interpreter. As
written, it produces a lower-case c:\\ as yours did.
But...
Running Debug|Win32 interpreter...
Python 3.8.0a0 (heads/master:7a3056f, Jul 23 2018, 08:23:33) [MSC v.1912 32 bit
(Intel
Tim Golden added the comment:
Thanks, @eryksun. Whatever the reason, it's consistently failing in the way I
describe. A case-insensitive test is obviously good for that and for the other
reasons you give, so I'll patch the test anyway
Tim Golden added the comment:
import nt, sys; assert
sys.executable.startswith(nt._getvolumepathname(sys.executable))
This code fails only when run from the python.bat as created by
pcbuild\build.bat. The obvious difference is that the batch file sets
PYTHONHOME which, presumably, is used
New submission from Tim Golden :
>From a fresh build on Win10 with VS2017:
python -munittest -v test.test_ntpath.TestNtpath.test_nt_helpers
gives the following error:
==
FAIL: test_nt_helpers (test.test_ntpath.TestNtp
Tim Golden added the comment:
For shell objects such as shortcuts you could use os.startfile which invokes
ShellExecute under the covers
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Tim Golden <m...@timgolden.me.uk>:
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Tim Golden added the comment:
[Housekeeping] Closing this as fixed. The mimetypes fix is in; the 3.4
installer is well out of support. If any other issues arise on current
installers they should be raised as new issues.
--
resolution: -> fixed
stage: -> resolved
status
Tim Golden added the comment:
I can't reproduce either on 2.7 or on 3.5 with any of the examples shown.
Closing again as not-a-bug.
--
resolution: -> not a bug
status: open -> closed
versions: -Python 2.7, Python 3.4
___
Python tracke
Tim Golden added the comment:
I think you're suppressing sys.stderr after the "with". Try a NameError
or anything.
Alternatively, try a "with" which isn't using sys.stderr
Obviously, the next question is why *that's* happening.
Tim Golden added the comment:
Since the webmaster@ address tends to bear the brunt of these, can I
make sure I understand the situation?
* The only installers affected are those for x86/32-bit Windows 3.5.3
* By default [I just checked] the launcher checkbox is not checked
Tim Golden added the comment:
Although I don't remember seeing a crash out as quick as this, common
causes for this kind of thing are to do with environment variables
pointing to still-existing or part-existing installations. Can you try:
set PY
from a command prompt, please, to see if any
Tim Golden added the comment:
Do you have any Python environment variables set?
If you're not sure, try at a command prompt:
SET PY
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Tim Golden added the comment:
This sometimes happens when someone copies from a book or a tutorial and
includes as though code the banner header which is only meant to
illustrate the context.
--
___
Python tracker <rep...@bugs.python.org>
Tim Golden added the comment:
Applies, builds & tests ok for me for Win32 Release build (ie build.bat
-e) on Win 8.1 x64.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.o
Tim Golden added the comment:
As it happens, all the code I use which calls CoInitialise[Ex] does so
with STA. But do I understand correctly that, if you implement this,
there's no way for me to select MTA? If so I would consider that a major
drawback
Tim Golden added the comment:
Built 64-bit 2.7 but can't reproduce on tip, 2.7.12rc1 or 2.7.11 tags.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Tim Golden added the comment:
The crash is actually happening in Modules/_ssl.c:_get_peer_alt_names.
> _ssl.pyd!_get_peer_alt_names(x509_st * certificate) Line 810 + 0x2
bytes C
_ssl.pyd!_decode_certificate(x509_st * certificate) Line 1187 + 0x8
bytes C
_ssl.
Tim Golden added the comment:
I can reproduce with the download build but not with a freshly-built executable
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Tim Golden added the comment:
I did wonder about that. It's good that we can reproduce the issue
without pip, but it's probably going to be messy to debug! I've got VS
2008 on this machine but no time at the moment to build & debug.
Don't know if Zach or Steve might be able to
Tim Golden added the comment:
Thanks, Paul. Adding Benjamin as 2.7 release manager. This looks like a release
blocker to me.
--
nosy: +benjamin.peterson
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Tim Golden added the comment:
James, which installer did you use (just so I can try to reproduce as
closely as possible)?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Tim Golden added the comment:
Re-opening at user's request on Paul Moore's advice. He's already nosy so can
comment here if needed.
It would be good to get independent verification. I'll try to install the rc
for 2.7.12 to see if I can reproduce.
--
resolution: third party ->
st
Tim Golden added the comment:
The key point here is that if I run the example as given on my Win 8.1
box, it doesn't work. (The venv I'm using is called nw0).
d:\tim\.venvs>dir nw0\Scripts\activate.bat
Volume in drive D is New Volume
Volume Serial Number is 2639-22DA
Directory of d:\
Tim Golden added the comment:
I haven't tested everywhere but some versions of Windows don't in fact
accept forward slashes on the cmd.exe command line. Suggest changing to
backslashes as there's no reason to do otherwise.
--
nosy: +tim.golden
Changes by Tim Golden <m...@timgolden.me.uk>:
--
nosy: -tim.golden
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25444>
___
_
Tim Golden added the comment:
I'd just bail as early as poss. from the installer. If it's possible to
detect Windows versions, stick something like "The last version to
support WinXP is 3.4". If that's too tricky, perhaps something "Your
system may be unsupported. Please
Tim Golden added the comment:
I don't feel that strongly, but my preference would be
"python35[-whatever]" rather than the version with the spaces & the
dots. Both for ease of use and for some kind of continuity with the
c:\pythonxy we've had
Tim Golden added the comment:
Can you confirm whether it also fails if you pass in a unicode string? eg
shutil.rmtree(ufilename.txt)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24672
Tim Golden added the comment:
Zach, is there a write-up in the devguide for how to do this? And/or
could you send me the same email, please?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24432
Tim Golden added the comment:
I'm not sure why you expect this to work: the Python C API relies on the
presence of a Python installation to work. It's not, in itself, a means of
bundling Python. I assume you must have at least had the python .dll present or
the program wouldn't even have had
Tim Golden added the comment:
Thanks for the very thorough review. This isn't going to make it into
3.5, but I'll rework it in the light of your comments and see if people
are happy with it in the optional argument variation.
--
___
Python tracker
Tim Golden added the comment:
That is a possibility which hadn't occurred to me. @eryksun, would you
mind eyeballing the patch over on issue2582? It almost certainly won't
apply cleanly as it's been almost two years since I last refreshed it,
but you can hopefully gauge the intent
Tim Golden added the comment:
Tests failed on Windows probably because of NamedTemporaryFile
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21916
Tim Golden added the comment:
@RDM I'm sitting with Greg at a London Python session and we've run through
these tests on 3.4/3.5. I know you were reviewing this code at PyCon. Are you
happy for me to commit from here?
--
___
Python tracker rep
Tim Golden added the comment:
My reluctance to commit the os.access patch is because it will cause
such a behaviour change in a function which has been pretty stable for a
long while. It'll certainly be more correct, but at the undoubted
expense of breaking someone's long-working code
Tim Golden added the comment:
Serhiy's offered a review and we can take it from here. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21916
Tim Golden added the comment:
To eliminate pip from the equation, can you just try running: py on its own
command line?
Also: what platform are you on? Win7? Win8.1? 32-bit or 64-bit? Are you running
in an unusually restrictive user environment
Tim Golden added the comment:
Jaivish Kothari,
Thanks for making the effort to contribute. Can I suggest you have a
look at the Core Mentorship site:
http://pythonmentors.com/
and perhaps join the Core Mentorship list:
http://mail.python.org/mailman/listinfo/core-mentorship
TJG
Tim Golden added the comment:
Perhaps unsurprisingly, I can't reproduce this on Python 2.7.9 32-bit running
on Win7 Home Premium.
Python doesn't handle CapsLock/Shift interaction directly: it just gets what it
gets from the underlying OS or framework. So I'm at a loss to know what might
Tim Golden added the comment:
I can't see anything here which is clearly a Python bug. If the OP or anyone
else cares to come back (after more than 4 years!) with a clearly-reproducible
problem I'm happy to revisit.
I apologise for waking up this issue after so long; we really should have
Tim Golden added the comment:
One small thing to bear in mind is that the existing code (ie with the extra
linefeed) raises an IndentationError if cut-and-pasted into the interactive
interpreter; with the OP's change, it succeeds. Might not have been their
intention, but certainly is the case
Tim Golden added the comment:
(Laughs). I admit, I was so close to the trees, I missed the fact that
the doc is, as you say, a What's New, and for Python 2.4. Agree that to
change this now would be somewhat ludicrous.
If some similar patch were proposed to some more current, relevant
Tim Golden added the comment:
Adding Paul Moore as he's essentially the intersection between distutils
Windows
--
nosy: +paul.moore
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23970
Tim Golden added the comment:
Well, in the interests of due diligence, I checked out built each of the four
flavours (32/64 Release/Debug) independently and without any errors. I then
rebuilt each with the wrong Platform (ie for Win32 in the x64 directory and
vice versa) without cleaning
Tim Golden added the comment:
Sounds good to me. It's really a question as to the point where
practicality beats purity...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21411
Tim Golden added the comment:
Are we talking about re-implementing StdPrinter in terms of
OutputDebugString? (Either always, on Windows, or as a fallback?)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23861
New submission from Tim Golden:
PCBuild\build.bat takes an argument of -e to pull in external libraries.
Either by accident or by design the main build will run in addition. However if
you'd run pcbuild -e simply to pull in externals, you might not have specified
extra build params
Tim Golden added the comment:
Fair enough
--
resolution: - not a bug
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23856
Tim Golden added the comment:
Turns out to be non-issue after all! I was working through the import code for
other reasons and noticed that the WindowsRegistryFinder was there. I'll spare
you the complications of debugging the _bootstrap part of import, but basically
the code in _bootstrap.py
Tim Golden added the comment:
I think they stopped using them a while back in favour of a pywin32.pth
file.
I don't think I even knew you could use the registry for sys.path.
If no-one's shouted since the changes to importlib (which was 3.3?) I
think we can quietly drop this and hope no-one
Tim Golden added the comment:
Adding Mark Hammond in case I'm wrong about the (lack of) impact on pywin32
--
nosy: +mhammond
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21319
Tim Golden added the comment:
Unless someone comes back who remembers what the ulterior motive was: I
agree; remove the check and just the crash happen.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23765
Tim Golden added the comment:
This has come up again in issue23604. Steve, please apply your patch. I think
it should go against 2.7, 3.4 3.5 especially since all those versions now
ship with ensurepip.
--
___
Python tracker rep...@bugs.python.org
Tim Golden added the comment:
This is a duplicate of issue22028.
Daiyue Weng: to move forward, can you apply the fix referred to in this post:
https://mail.python.org/pipermail/python-list/2015-January/696688.html
(ie the removing corrupted keys section from
http://www.swarley.me.uk/blog
Tim Golden added the comment:
The problem is that this isn't an area I'm particularly familiar with
(either in Python nor in Windows) so I need time to ramp up my awareness
of what Steve's proposing plus then assessing the change. I'll try...
but I rather hope Zach gets there first
Tim Golden added the comment:
And, just to be clear to Serhiy who I know doesn't use Windows,
os.access really is a worthless function in its present form: worse,
even, because it can be misleading. I have a long-standing patch to
convert it to use AccessCheck but I've never quite had the guts
Changes by Tim Golden m...@timgolden.me.uk:
--
components: +Windows
nosy: +tim.golden, zach.ware
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23465
Changes by Tim Golden m...@timgolden.me.uk:
--
resolution: - not a bug
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23463
Tim Golden added the comment:
Colons are valid in filenames to introduce Alternate Data Stream:
https://msdn.microsoft.com/en-us/library/cc422524.aspx
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23463
Changes by Tim Golden m...@timgolden.me.uk:
--
resolution: - wont fix
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17023
1 - 100 of 601 matches
Mail list logo
