Tim Golden m...@timgolden.me.uk added the comment:
This is a duplicate of http://bugs.python.org/issue8036
(which I still haven't got around to applying...)
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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 1900 = year is ok
Tim Golden m...@timgolden.me.uk 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 rep...@bugs.python.org
http://bugs.python.org/issue13674
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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 rep
Changes by Tim Golden m...@timgolden.me.uk:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13524
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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 m...@timgolden.me.uk 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 specify
which must
Tim Golden m...@timgolden.me.uk added the comment:
'fraid not. I've never had to dig into the allocation stuff at this level.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13483
Tim Golden m...@timgolden.me.uk 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 rep...@bugs.python.org
http://bugs.python.org/issue13210
Changes by Tim Golden m...@timgolden.me.uk:
--
nosy: +brian.curtin, jason.coombs, tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13419
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk added the comment:
Are you aware of PEP 397?
http://www.python.org/dev/peps/pep-0397/
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12394
Tim Golden m...@timgolden.me.uk added the comment:
Adding Mark H as the author of PEP 397
--
nosy: +mhammond
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12394
Changes by Tim Golden m...@timgolden.me.uk:
--
nosy: +markmcmahon, tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12382
___
___
Python
Tim Golden m...@timgolden.me.uk added the comment:
I'm just patching a clone now.
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12084
Tim Golden m...@timgolden.me.uk 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 the Unicode stuff
Tim Golden m...@timgolden.me.uk 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 rep...@bugs.python.org
http://bugs.python.org/issue11583
Tim Golden m...@timgolden.me.uk 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:/temp exists
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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 tracker
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk added the comment:
+1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11750
___
___
Python-bugs-list mailing list
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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 rep...@bugs.python.org
http://bugs.python.org/issue10684
Tim Golden m...@timgolden.me.uk added the comment:
Reopening as there seems to be some possibility of progress
--
nosy: -BreamoreBoy
resolution: invalid -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Tim Golden m...@timgolden.me.uk:
--
versions: +Python 3.3 -Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1602
Tim Golden m...@timgolden.me.uk 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 one to do
Tim Golden m...@timgolden.me.uk 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 m...@timgolden.me.uk added the comment:
Removing docs unless this actually becomes a doc issue
--
nosy: +tim.golden -d...@python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10190
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: d...@python - bethard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10190
___
___
Python
Tim Golden m...@timgolden.me.uk 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 rep...@bugs.python.org
http
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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 rep
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
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk added the comment:
Merely from a Windows point-of-view, you could get the full
command line fairly easily:
code
import ctypes
pstring = ctypes.windll.kernel32.GetCommandLineW ()
print (ctypes.c_wchar_p (pstring).value)
/code
TJG
--
nosy: +tim.golden
Tim Golden m...@timgolden.me.uk added the comment:
I'm afraid I don't know; might be worth asking that on the main python mailing
list.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2972
Tim Golden m...@timgolden.me.uk 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 rep...@bugs.python.org
http://bugs.python.org
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9699
___
___
Python-bugs-list
Tim Golden m...@timgolden.me.uk 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
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1559298
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2528
___
___
Python-bugs-list
Tim Golden m...@timgolden.me.uk added the comment:
I have no strong opinion, Roumen, (and no experience with the package)
but why -1 from you?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2889
Tim Golden m...@timgolden.me.uk added the comment:
+1 in principle
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9654
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
components: -Interpreter Core
nosy: +tim.golden
versions: +Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue798876
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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.
--
assignee: - tim.golden
Tim Golden m...@timgolden.me.uk added the comment:
I can confirm that the patched regrtest runs ok on WinXP.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9433
Tim Golden m...@timgolden.me.uk 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
Changes by Tim Golden m...@timgolden.me.uk:
--
components: +Windows
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1102
Tim Golden m...@timgolden.me.uk 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
status: open - closed
Tim Golden m...@timgolden.me.uk 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 less
useful!
I don't
Tim Golden m...@timgolden.me.uk 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 implements
Tim Golden m...@timgolden.me.uk 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
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
nosy: +tim.golden
versions: -Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9575
Tim Golden m...@timgolden.me.uk added the comment:
Fudge-fix committed as r83948, r83958. Not sure what status to set
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9055
Tim Golden m...@timgolden.me.uk 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 rep
Tim Golden m...@timgolden.me.uk 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:
code
import os
path = c:\\ + \\.join (130 * ['xx
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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 tracker
Tim Golden m...@timgolden.me.uk 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
Tim Golden m...@timgolden.me.uk 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 rep
Changes by Tim Golden m...@timgolden.me.uk:
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5673
___
___
Python-bugs-list
Tim Golden m...@timgolden.me.uk added the comment:
There are at least two ways to do non-blocking file IO on Windows:
Overlapped I/O
I/O Completion ports
Don't know what's best here, but happy to see what might be achieved
if it was thought worth pursuing.
--
nosy: +tim.golden
Tim Golden m...@timgolden.me.uk added the comment:
OK, the issue identified by Hirokazu Yamamoto in msg113106 only actually
affects the 2.x series, because of the awkwardly multiple-level interaction
between file handles. The io rewrite in 3.x seems not to suffer the same way.
Nonetheless
Tim Golden m...@timgolden.me.uk added the comment:
Committed in r83815, r83816, r83817
--
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3210
Tim Golden m...@timgolden.me.uk added the comment:
Committed as r83830, r83831, r83832
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2304
Tim Golden m...@timgolden.me.uk added the comment:
Duplicate of #2304
--
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1714451
Tim Golden m...@timgolden.me.uk added the comment:
I can't reproduce on W7. Strangely, though, although my banner suggests that I
have exactly the same build as you, I get a \r\n at the end of the
communicate bytestream, not a simple \n as you're getting. Do you have any
environment variables
Tim Golden m...@timgolden.me.uk added the comment:
I've just run this:
code
import os
fd = os.popen(cat.exe, w)
for i in range (100):
_ = fd.write (%d\n % i)
fd.flush ()
/code
and seen the expected list of numbers on the screen. cat.exe is from the
gnuwin32 tools but I'm assuming
Tim Golden m...@timgolden.me.uk added the comment:
To confirm the situation on 3.x: a unicode string with non-ascii-encodable
characters is fine. The easy test here in the uk is a pound sign:
code
import subprocess
FILENAME = abc£.bat
FILENAME.encode (ascii)
#
# UnicodeEncodeError
#
with open
Tim Golden m...@timgolden.me.uk added the comment:
OK, I'm going to close this one:
* commands is out of 3.x
* it's a convenience for 2.x anyway, not a showstopper
If anyone feels keen enough to reopen the request, I'm willing to commit a
suitable patch against the release27-maint branch
Tim Golden m...@timgolden.me.uk added the comment:
Committed in r83759 r83760 r83761
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3210
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7443
___
___
Python-bugs-list
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4708
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1714451
Changes by Tim Golden m...@timgolden.me.uk:
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1681974
___
___
Python-bugs-list
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1672853
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1707753
Changes by Tim Golden m...@timgolden.me.uk:
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1142
___
___
Python-bugs-list
Changes by Tim Golden m...@timgolden.me.uk:
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6609
___
___
Python-bugs-list
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6839
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8006
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
components: +Windows
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2304
Tim Golden m...@timgolden.me.uk added the comment:
Blast. Thanks; I'll have to rework those patches then.
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3210
Tim Golden m...@timgolden.me.uk added the comment:
If individual users want to change these around, it's easy enough to do so
post-hoc. Closing as won't fix.
--
nosy: +tim.golden
resolution: - wont fix
___
Python tracker rep...@bugs.python.org
http
Changes by Tim Golden m...@timgolden.me.uk:
--
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1566260
Tim Golden m...@timgolden.me.uk added the comment:
Patch attached with code test which fixes this within _subprocess.c at least
for Windows
--
assignee: - tim.golden
Added file: http://bugs.python.org/file18398/3210.r83741.patch
___
Python tracker
Tim Golden m...@timgolden.me.uk added the comment:
Patch added for 31 branch
--
Added file: http://bugs.python.org/file18399/3210.release31-maint.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3210
Tim Golden m...@timgolden.me.uk added the comment:
Patch added for 27 branch
--
Added file: http://bugs.python.org/file18400/3210.release27-maint.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3210
Tim Golden m...@timgolden.me.uk added the comment:
Brian, I'm not sure that the test as rewritten will exercise the error.
The key is that the traceback object will prevent the handles
from being finalised until it is itself finalised. After your
change I expect the handles to release anyway
Changes by Tim Golden m...@timgolden.me.uk:
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6040
___
___
Python-bugs-list
401 - 500 of 601 matches
Mail list logo
