Tim Golden added the comment:
I've reviewed the docs for English and general readability. As
mentioned, I've no idea of the tech involved. I did look through the
bdb.py source and the existing docs for pdb to get some idea of the
terminology used. Ultimately I've changed very litt
Tim Golden added the comment:
Do you realise that the code at the bottom of bb.py is executed when you
import it from aa.py? In other words, when you run aa.py, the whole of
your significant code is running within an import statement. I don't
know if it's the cause of the problem (
Tim Golden added the comment:
Not, apparently, on my (XP SP2) box:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
&
Changes by Tim Golden :
--
nosy: +brian.curtin, jason.coombs, tim.golden
___
Python tracker
<http://bugs.python.org/issue13419>
___
___
Python-bugs-list mailin
Tim Golden added the comment:
Thanks. I was going to ask about this to see if anyone had already done
the legwork.
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue13
Tim Golden added the comment:
'fraid not. I've never had to dig into the allocation stuff at this level.
--
___
Python tracker
<http://bugs.python.o
Tim Golden added the comment:
The environment passed to a Windows process must contain
certain things. (I don't at this moment remember exactly
what). You can't just pass the one thing you're adding.
Change your "e = ..." line to something like:
e = os.environ
e[&#x
Tim Golden added the comment:
Re-opening because there's a real problem here which can crash Python hard.
Simplest reproduction:
import sys
import subprocess
subprocess.Popen (sys.executable, env={})
Affects 2.x and 3.x tip (haven't tried others yet but I don't imagine
Tim Golden added the comment:
Yes. I've added the "Windows" component on the tracker.
(At least I think I have). It's to do with CreateProcess
needing at least certain items in the environment passed.
I'm trying to track down some docs on MSDN which sp
Tim Golden added the comment:
OK, the long and short is that spwaning a process without passing
in SystemRoot is asking for trouble. There's a blog post here
which gives an example:
http://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-systemroot-in-a-custom-enviro
Tim Golden added the comment:
After a discussion on python-dev:
http://mail.python.org/pipermail/python-dev/2011-December/114733.html
I propose to close this call tomorrow as wontfix
--
___
Python tracker
<http://bugs.python.org/issue13
Changes by Tim Golden :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13524>
___
___
Python-bugs-list
Tim Golden added the comment:
Yes, but the MS crt strftime *for %y* requires a year >= 1900 (ie
tm_year >= 0). Looks like we need a special check.
--
___
Python tracker
<http://bugs.python.org/i
Tim Golden added the comment:
This is happening on Windows x86 against the current tip. The MS C runtime can
handle older dates; it's just that we're taking 1900 off the year at some
point. (At least, I think that's what's happening). FWIW you only need
time.strftime to
Tim Golden added the comment:
... and that's because the tm struct defines the tm_year field as an offset
from 1900. Sorry for the false start. I'll look at the MS runtime stuff instead
--
___
Python tracker
<http://bugs.python.o
Tim Golden added the comment:
Well, the code in 2.x is quite different from that in 3.x.
Specifically, the 2.x code assumes that, for Windows, no
year before 1900 is valid for any of the formats. So a
simple check throws a ValueError for tm_year < 0. For 3.x
the assumption was that Windows
Tim Golden added the comment:
Yes, sorry. I wasn't clear enough. There *are* still checks
in the 3.x code (for the kind of thing you're showing). But
the checks assume 1000 <= year <= maxint is ok for all format
parameters on Windows. In fact, for %y, only 19
Tim Golden added the comment:
What happens if you try "python -S" (capital S)? In principle this should
bypass the need to load site.py. Even if that works we still have a problem to
solve, but at least it might narrow things down.
--
nosy: +
Tim Golden added the comment:
One (presumably unintended) side-effect is that you can now do os.path.isdir on
a wildcard and the first returned entry will be tested for directoryness:
import os
os.path.isdir ("c:/tem*")
# => True where c
Tim Golden added the comment:
Code looks good and tests pass. Only one thing: the code in the patched
lib\ntpath.py still refers to FindFirstFile
--
___
Python tracker
<http://bugs.python.org/issue11
Tim Golden added the comment:
I'm just patching a clone now.
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue12084>
___
___
Pytho
Tim Golden added the comment:
All expected tests pass on 3.2 branch (Win7 32-bit). The patch doesn't
apply cleanly to trunk; not sure if it's expected to or not. The code
looks ok on paper. I'll leave Victor to quibble over th
Changes by Tim Golden :
--
nosy: +markmcmahon, tim.golden
___
Python tracker
<http://bugs.python.org/issue12382>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Golden added the comment:
Are you aware of PEP 397?
http://www.python.org/dev/peps/pep-0397/
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue12
Tim Golden added the comment:
Adding Mark H as the author of PEP 397
--
nosy: +mhammond
___
Python tracker
<http://bugs.python.org/issue12394>
___
___
Python-bug
Tim Golden added the comment:
Obviously someone's code would break if it were relying on the Unix
errno only in a Windows-only situation to determine the situation of
opening a directory which isn't one. But that combination of events
doesn't seem terribly likely.
Speaking fo
Tim Golden added the comment:
In the interests of moving this forward, I've committed the one-line removal of
the assertion in r83948. Hopefully that will bring this buildbot back to life.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Tim Golden :
--
assignee: -> tim.golden
nosy: +tim.golden
versions: -Python 2.5
___
Python tracker
<http://bugs.python.org/issue9575>
___
___
Py
Tim Golden added the comment:
Fudge-fix committed as r83948, r83958. Not sure what status to set
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/iss
Tim Golden added the comment:
ReComitted as r83947, r83956, r83957 and this time the buildbots look happy.
(At least as regards this change).
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Tim Golden added the comment:
I can't get it crash on a path that short. I can produce an error message if I
push it beyond the 254 limit, but you can work around that by applying the
filesystem namespace prefix:
import os
path = "c:\\" + "\\".join (130 *
Tim Golden added the comment:
See: http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
I tried first with your exact path and it caused no issues on
my Win7 box. FWIW you could easily roll your own os.walk
(starting by copying the code that's there) if you needed
to ro
Tim Golden added the comment:
Fixed by issue2304
--
components: -Library (Lib), Tests, Windows
nosy: +tim.golden
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tr
Tim Golden added the comment:
OK; issue2304 is now fixed and closed. But it doesn't seem to make any
difference to this behaviour. I've just retested and I see on py3k the
behaviour the OP saw. CreateProcess does the same thing and I couldn't even get
it to work with multipl
Tim Golden added the comment:
Thanks for the feedback. I'll close this for now as "works for me". Feel free
to reopen if you can come up with anything fresh.
--
resolution: -> works for me
stage: -> committed/rejected
s
Tim Golden added the comment:
Closing as "won't fix": this would be the same if you had any code which tried
to do os.mkdir ("aux"). By way of comparison, Info-ZIP's UnZip returns
"checkdir error: aux exists but is not directory" which actually seems
Changes by Tim Golden :
--
assignee: -> tim.golden
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue3099>
___
___
Python-bugs-list mai
Tim Golden added the comment:
I don't see any reason to turn this down except, perhaps, for keeping something
simple.
Certainly I don't believe that Windows users will be confused by the fact that
there are wildcards other than "*" and "?". fnmatch already im
Tim Golden added the comment:
Assuming I understand you correctly, could I propose this rather less involved
patch which simply specifies the sys.executable as part of the command line.
The test doesn't propose to test file associations and indeed two of the test
already fill i
Changes by Tim Golden :
--
components: +Windows
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue1102>
___
___
Python-bugs-list mailing list
Unsub
Tim Golden added the comment:
This is usually because the bug mentioned in issue7443 (although it
could be something else, obviously). It should sort itself out on the
next run. I'll rerun on my local checkout to see if there real WinXP issues.
--
nosy: +tim.g
Tim Golden added the comment:
I can confirm that the patched regrtest runs ok on WinXP.
--
___
Python tracker
<http://bugs.python.org/issue9433>
___
___
Pytho
Tim Golden added the comment:
It looks as though issue2889 has a better chance of getting into the VS build
than this one, which appears to be MingW-based (at a quick glance). I'm loosely
keen to see it in, although I have no knowledge of curses as such. I'll assign
it to my
Tim Golden added the comment:
I'll pick it up for the moment to shepherd it along because I'm reasonably keen
to see a Windows curses in the stdlib. However, I'm no expert in curses and I
don't promise to do anything immediate with it.
--
assi
Changes by Tim Golden :
--
assignee: -> tim.golden
components: -Interpreter Core
nosy: +tim.golden
versions: +Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue
Tim Golden added the comment:
+1 in principle
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue9654>
___
___
Python-bugs-list mailin
Tim Golden added the comment:
I have no strong opinion, Roumen, (and no experience with the package)
but why -1 from you?
--
___
Python tracker
<http://bugs.python.org/issue2
Changes by Tim Golden :
--
assignee: -> tim.golden
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue1559298>
___
___
Python-bugs-list mai
Changes by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<http://bugs.python.org/issue2528>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<http://bugs.python.org/issue9699>
___
___
Python-bugs-list mailing list
Unsubscri
Tim Golden added the comment:
I'll pick this up and try to decide what's best to
do. I'm away from home for a few weeks and have only
intermittent internet access. Thanks, Sorin, for
a reproducible test case.
--
title: invalid call of Windows API _popen() generating Th
Tim Golden added the comment:
+1 on the idea in general; I'm away at the moment
and not in a position to review the patch. Hopefully
Brian can review/commit
--
___
Python tracker
<http://bugs.python.org/i
Tim Golden added the comment:
Merely from a Windows point-of-view, you could get the full
command line fairly easily:
import ctypes
pstring = ctypes.windll.kernel32.GetCommandLineW ()
print (ctypes.c_wchar_p (pstring).value)
TJG
--
nosy: +tim.golden
Tim Golden added the comment:
I'm afraid I don't know; might be worth asking that on the main python mailing
list.
--
___
Python tracker
<http://bugs.python.
Tim Golden added the comment:
Suggest you raise a separate feature-request issue for that, Geoff, perhaps
offering the two implementations described. Perhaps raise it it on python-ideas
first to gauge reactions. I'm +0 myself since it's so easy to do anyway and I
don't kn
Tim Golden added the comment:
BoĊĦtjan, the code segment you quote is the *fallback* if the
C module hasn't been built for some reason. The module simply
calls through to the underlying C Library. I notice you're
running on Windows, so this is a useful MS page:
http://msdn.microsoft
Tim Golden added the comment:
I've only read the patch and not applied it, yet. But in principle I'm
+1 on this. If Brian doesn't get there first, I'll try to apply later.
--
___
Python tracker
<http://bug
Tim Golden added the comment:
I'm afraid this falls outside my particular area of knowledge, and also
outside the remit of the bug tracker. Perhaps you could post to
python-list to see if anyone there can help?
--
___
Python tracker
Tim Golden added the comment:
If you don't often use the console, then I expect your console settings
have Insert mode off. (Alt-Space > Properties > Options > Insert Mode [x])
--
nosy: +tim.golden
___
Python tracker
<http:
Agree that it's not really up to us; and that it's trivial to change
once for all future python processes.
As to the left-click blocking, I think that's "Quick Edit" mode you're
thinking of, not "Insert"
TJG
___
Python-bugs-list mailing list
Unsubsc
Tim Golden added the comment:
Removing docs unless this actually becomes a doc issue
--
nosy: +tim.golden -d...@python
___
Python tracker
<http://bugs.python.org/issue10
Changes by Tim Golden :
--
assignee: d...@python -> bethard
___
Python tracker
<http://bugs.python.org/issue10190>
___
___
Python-bugs-list mailing list
Un
Tim Golden added the comment:
Patch fixes the issue and tests run ok on 3.3 Win7; just building a 2.7 branch
to test
--
___
Python tracker
<http://bugs.python.org/issue10
Tim Golden added the comment:
For clarity, while making unlink more robust is no bad thing, the error occurs
when the unlink *succeeds* but a subsequent create of the same name fails. This
happens when an indexer, Virus scanner or TortoiseSvn etc. has opened the file
with SHARE_DELETE. This
Tim Golden added the comment:
Well http://bugs.python.org/issue7443#msg102833 outlines the problems I
encountered while trying to do essentially that. Nothing insurmountable, but
definitely bigger than simply adding one line of code.
Looks to me like there are two avenues of approach (and
Tim Golden added the comment:
+1
--
___
Python tracker
<http://bugs.python.org/issue11750>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Tim Golden added the comment:
FWIW I agree with MvL: os.stat is one of those awkward customers
left over from the idea that Windows could be posix-compliant,
even though the relevant concepts don't actually map particularly
well. ISTM that anyone seriously wanting to determine wh
Tim Golden added the comment:
I can't say I'd object as such, but the [Index] tab already
contains the items in the General Index and is arguably the
killer feature of the CHM in any case.
--
nosy: +tim.golden
___
Python trac
Tim Golden added the comment:
I've just rebuilt on Windows against tip. test_glob is failing:
test test_glob failed -- Traceback (most recent call last):
File "c:\work-in-progress\python\cpython-9584\lib\test\test_glob.py", line
135, in test_glob_curly_braces
os.path
Tim Golden added the comment:
But at the least, the start of the para might be slightly reworded to something
like: "If you specifically need to avoid name clashes with subclasses, there is
limited support..." which avoids the phrase "Since there is a valid use-case
for class-
Tim Golden added the comment:
It's almost certainly coming straight back from the O/S,
where Python is doing its usual thing of channelling
an O/S error directly. Obviously we could special-case
this or any other specific error; but we usually don't
--
nosy: +
Tim Golden added the comment:
I'm not quite sure how anyone's supposed to determine
which bugs are likely to have been worked around and
which haven't :) I'm also unsure why a clear bugfix
shouldn't make it into a minor version release. Surely
this isn't the only
Tim Golden added the comment:
Reopening as there seems to be some possibility of progress
--
nosy: -BreamoreBoy
resolution: invalid ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/
Changes by Tim Golden :
--
versions: +Python 3.3 -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue1602>
___
___
Python-bugs-list mailin
Tim Golden <[EMAIL PROTECTED]> added the comment:
The _multiprocessing module is not building under Windows at the moment.
Attempting to import multiprocessing (from an .exe build from the
current svn) gives "ImportError: No module named _multiprocessing" and
the test suite sk
Tim Golden <[EMAIL PROTECTED]> added the comment:
Benjamin Peterson wrote:
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> On Wed, Jun 11, 2008 at 9:20 AM, Tim Golden <[EMAIL PROTECTED]> wrote:
>> Tim Golden <[EMAIL PROTECTED]> added the com
Tim Golden <[EMAIL PROTECTED]> added the comment:
I'm sorry; I've had a look and there's no chance of my updating the
solution and project files by hand; and I can't run Visual Studio at the
moment. I'll try emailing Trent or Christian in the hope that o
Tim Golden <[EMAIL PROTECTED]> added the comment:
Trent's supplied me with enough info to patch the project files
manually. The attached patch against r64120 results in the
_multiprocessing module building. I'm running the tests now but I'll
upload the patch in any ca
Tim Golden <[EMAIL PROTECTED]> added the comment:
Giampaolo Rodola' wrote:
> New submission from Giampaolo Rodola' <[EMAIL PROTECTED]>:
>
> By using:
> http://www.python.org/dev/daily-msi/python-2.6.14041.msi
>
>
> C:\>C:\python26\python
>
Tim Golden <[EMAIL PROTECTED]> added the comment:
The attached file sp-3.py simulates what I think is happening within the
subprocess module. Note that the OS handle is duplicated to allow
inheritance and then left unclosed on failure. If it is explicitly
closed, the file can be removed.
New submission from Tim Golden <[EMAIL PROTECTED]>:
The following code raises an Assertion Failure under debug in r64518
running on Windows XP SP2:
import ctypes
class X (ctypes.Structure): pass
ctypes.POINTER (X)
Assertion failed: PyErr_Occurred(), file ..\Modules\_ctypes\_ctypes.c
Tim Golden <[EMAIL PROTECTED]> added the comment:
The comment just before _ctypes.c:309 indicates that when a NULL is
returned at that point, an error condition should already obtain.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Tim Golden added the comment:
Traceback (most recent call last):
File "", line 1, in
WindowsError: [Error 6] The handle is invalid
I suspect that .iterkeys / .itervalues would be more
acceptable spellings as those mirror the dict methods.
Whether the idea of extending _winreg
Tim Golden added the comment:
Sorry; the email interface messed that up. The code
which triggered the error was:
import _winreg
list (
_winreg.IterValue (
_winreg.OpenKey (_winreg.HKEY_CURRENT_USER, "Console")
)
)
--
Tim Golden added the comment:
Just think about it for a minute:
t = (1, 2)
print id (t), t
t += (1, 2, 3)
print id (t), t
Not mutating, merely creating a new new object
and giving it the same name
--
nosy: +tim.golden
___
Python tracker
<h
Tim Golden added the comment:
On 31/03/2010 14:20, Michael Foord wrote:
> - TESTFN
>
> This is a global for setting the directory temporary files are created in?
> Don't think I like the global approach. Which functions is it used by?
It's used *all over the place*. I
Tim Golden added the comment:
Seeing the same thing on 32-bit WinXP on x86
On 07/04/2010 14:34, Stefan Krah wrote:
>
> New submission from Stefan Krah:
>
> On Windows/amd64, I get loads of pickling errors in test_multiprocessing.
>
> Type 1 error:
>
> Tracebac
Tim Golden added the comment:
This is basically a rerun of this discussion a couple of years ago:
http://mail.python.org/pipermail/python-dev/2008-April/078333.html
The problem certainly still happens against trunk -- I have a semi-aggressive
test-harness which can cause it to reproduce
Tim Golden added the comment:
In one window run the attached script (assumes you have pywin32 installed) with
a parameter of the directory the TESTFN file will end up in. Then run, eg,
test_zipfile in another window. For me:
c:\temp> watch_dir.py C:\work_in_progress\make-snapshots\tr
Tim Golden added the comment:
I put together a trivial patch against the 2.7 trunk (basically: I added
a os.rename before the os.remove in test_support.unlink) and reran my
test harness with test_zipfile... and it still failed because, of course,
test_zipfile calls shutil.rmtree which bypasses
Tim Golden added the comment:
I'm afraid that the problem doesn't lie in the unlink: DeleteFile
succeeds. The problem is that the file is only marked for delete
until such time as the last SHARE_DELETE handle on it is closed.
Until that time, an attempt to (re)create the file for anyt
Tim Golden added the comment:
> Then we shouldn't use DeleteFile in the first place to delete the file,
> but instead CreateFile, with DELETE access (and FILE_SHARE_DELETE
> sharing). If that fails, we need to move the file to the bin
> (see unlink_nt for details).
I see what
New submission from Tim Golden :
There is a reference to _winreg left in test_winsound. Trivial patch attached
renames this to winreg.
--
components: Tests
files: test_winsound.patch
keywords: patch
messages: 103042
nosy: tim.golden
severity: normal
status: open
title: _winreg
Changes by Tim Golden :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue8385>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Tim Golden :
test_pickle failing on WinXP
http://svn.python.org/projects/python/branches/py3k/Lib r80044
==
ERROR: test_unicode (__main__.CPicklerTests
Tim Golden added the comment:
Yes:
C:\temp>\work_in_progress\make-snapshots\branches
Python 3.2a0 (py3k:80030, Apr 13 2010, 11:13:13)
Type "help", "copyright", "credits" or "license"
>>> &#x
Tim Golden added the comment:
Well that's embarrassing: I updated but didn't rebuild. Sorry for the noise;
all tests passing now. Please close the call.
--
___
Python tracker
<http://bugs.python.
New submission from Tim Golden :
test_linecache in the current py3k branch is failing on my WinXP machine with
ERROR_SHARING_VIOLATION.
The attached trivial patch appears to fix the problem, altho' I'm unfamiliar
with the module in question so it may be that there's
New submission from Tim Golden :
If test_heapq is run before test_import on the current py3k head,
test_import will fail as per the attached traceback.
python -m test.regrtest -W test_heapq test_import > test_import.log
At a glance I can't see any obvious reason why test_heapq should
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue8273>
___
___
Python-bugs-list mailing list
Unsubscribe:
1 - 100 of 607 matches
Mail list logo
