Tim Golden added the comment:
Thanks for doing the investigation. Yes, that comment was added by me
as part of the fix for issue1677. I'll try to have a look at the
codepath you describe to see if we can add a similar workaround. The
Ctrl-C / SIGINT handling on Windows is less than ide
Tim Golden added the comment:
issue9035.2.patch is an updated version of Atsuo's patch.
Known issues:
* I haven't reworked it for the new memory-management API
* There's no test for a non-root mount point (which is really the basis for
this issue). It's difficult to see
Tim Golden added the comment:
issue9035.3.patch has switched to the new memory management API and has
tweaked the tests slightly for robustness.
This approach does introduce a behavioural change: the root of a SUBSTed
drive (essentially a symlink into the Dos namespace) will raise an
OSError
Changes by Tim Golden :
Removed file: http://bugs.python.org/file31092/issue9035.3.patch
___
Python tracker
<http://bugs.python.org/issue9035>
___
___
Python-bugs-list m
Changes by Tim Golden :
Removed file: http://bugs.python.org/file31087/issue9035.2.patch
___
Python tracker
<http://bugs.python.org/issue9035>
___
___
Python-bugs-list m
Tim Golden added the comment:
4th and hopefully final patch. Added tests for byte paths. Reworked the ismount
so it uses the original detection approach first (which is wholly lexical) and
drops back to the volume path technique only if the path doesn't appear to be a
drive or a share
Changes by Tim Golden :
--
assignee: tim.golden ->
___
Python tracker
<http://bugs.python.org/issue4708>
___
___
Python-bugs-list mailing list
Unsubscri
Tim Golden added the comment:
This one seems to have been fixed by the importlib rebuild. I haven't bothered
to trace the code path, but certainly "import nul" returns the expected
"ImportError: No module named 'nul'" in both Debug & Release builds.
Changes by Tim Golden :
--
assignee: tim.golden ->
___
Python tracker
<http://bugs.python.org/issue2889>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Tim Golden :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue16921>
___
___
Python-bugs-list
Tim Golden added the comment:
This has been covered off by work done with the test.support package including
context managers for temporary files / directories, and a waitfor mechanism
which waits some time if a file can't be accessed.
--
resolution: -> works for me
stat
Tim Golden added the comment:
I propose to close this one: using Python 3.3 on Win7 I can successfully stat
NTFS Junctions. Is there any remaining issue?
--
___
Python tracker
<http://bugs.python.org/issue18
Tim Golden added the comment:
Fixed. Thanks for the patch
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Tim Golden added the comment:
Here's an updated patch against trunk with tests & doc changes
--
status: languishing -> open
Added file: http://bugs.python.org/file31165/issue2528.2.patch
___
Python tracker
<http://bugs.pytho
Tim Golden added the comment:
... and to answer Amaury's question in msg109871 it creates a reasonable
consistency between the results of os.access and the user's actual ability to
read / write a file. eg, you might have no permissions whatsoever on the file
but as long as it wasn&#
Changes by Tim Golden :
Removed file: http://bugs.python.org/file9919/os_access-r62091.patch
___
Python tracker
<http://bugs.python.org/issue2528>
___
___
Python-bug
Tim Golden added the comment:
I attach a patch against 3.3; this is substantially Dave Chambers' original
patch with a trivial test added and a doc change. This means that HKCR is
scanned to determine extensions and these will override anything in the
mimetypes db. The doc change highl
Tim Golden added the comment:
Thanks for the review, Ben. Updated patches attached.
1 & 3) default_encoding -- Your two points appear to contradict each
other slightly. What's in the updated patches is: 3.x has no encoding
(because everything's unicode end-to-end); 2.7 attempt
Tim Golden added the comment:
Just to confirm: I can reproduce this more or less consistently on all versions
of Python 2.2 -> 3.2 on Windows 7. Those are distribution builds -- ie not
debug builds I've made myself. But it certainly does occur on a debug build of
2.7.
I'm try
Tim Golden added the comment:
OK, I've run out of time to look, but the culprit looks like it's an odd
interaction between my_fgets in myreadline.c and the interrupt handler in
signal. There's a section of code which is conditional on
ERROR_OPERATION_ABORTED being returned fr
Tim Golden added the comment:
That'll be my next move when I get some more time.
I've got someone coming over to see me (about real work!)
--
___
Python tracker
<http://bugs.python.
Tim Golden added the comment:
OK, it is a race condition between the code in myreadline.c and the
signal_handler in signalmodule.c. It can take between 0 and 3 sleeps for
the myreadline code to see the signal tripped. Patch on its way for 2.7;
VS 2010 downloading so that 3.x patch can be
Tim Golden added the comment:
Attached is a patch against Python 2.7. It checks in a loop for SIGINT and, if
it still hasn't fired, assumed Ctrl-Z was pressed which generates the same
error.
--
assignee: -> tim.golden
keywords: +patch
Added file: http://bugs.python.org/f
Tim Golden added the comment:
Yep.
--
___
Python tracker
<http://bugs.python.org/issue1677>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Tim Golden added the comment:
To be clear: ERROR_OPERATION_ABORTED is set when Ctrl-Z is hit as the
only thing on a line. If it's just an extra character then it operates
like any other keypress.
--
___
Python tracker
<http://bugs.py
Tim Golden added the comment:
This patch is for 2.7 and does enough to solve the issue without a major
rework. The signal module onthe default branch has had a lot of love
recently and I'll definitely make use of that for a 3.x patch.
--
___
P
Tim Golden added the comment:
Nope. Ctrl-C also sets EOF
--
___
Python tracker
<http://bugs.python.org/issue1677>
___
___
Python-bugs-list mailing list
Unsub
Tim Golden added the comment:
And here's a patch for the default branch, using the new sigint event as
Kristan suggested.
--
Added file: http://bugs.python.org/file26202/issue1677-python3x.patch
___
Python tracker
<http://bugs.python.org/i
Tim Golden added the comment:
And here's the patch against 3.2 (essentially the 2.7 patch but allowing for
the removal of RISCOS support)
--
Added file: http://bugs.python.org/file26207/issue1677-python32.patch
___
Python tracker
Changes by Tim Golden :
Removed file: http://bugs.python.org/file26207/issue1677-python32.patch
___
Python tracker
<http://bugs.python.org/issue1677>
___
___
Python-bug
Changes by Tim Golden :
Added file: http://bugs.python.org/file26208/issue1677-python32.patch
___
Python tracker
<http://bugs.python.org/issue1677>
___
___
Python-bug
Tim Golden added the comment:
> Tim, you've got tabs in your 3.3 patch.
Thanks, Antoine. I'll sort that out. (Goodness know how;
none of my editors use tabs).
> Other than that, I wonder why you wait for 100 ms in 3.3 but 10 ms in the
> other versions?
Ummm. Becaus
Changes by Tim Golden :
--
resolution: -> fixed
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Tim Golden added the comment:
THis was fixed almost two years ago in Py3K. Won't fix for 2.7
--
resolution: -> fixed
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pytho
Tim Golden added the comment:
Daniel. If you have any interest in this issue, would you mind
summarising the state of affairs, please? I have no direct interest in
the result but I'm happy to commit a patch or even to work one up if
somone can come up with a single, concrete sugge
Tim Golden added the comment:
Effectively made redundant by PEP 397, implemented in 3.3
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Tim Golden added the comment:
Closing as it's been pending for six months and I see nothing further to add
--
stage: -> committed/rejected
status: pending -> closed
___
Python tracker
<http://bugs.python.
Tim Golden added the comment:
On 01/07/2012 21:37, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW
>> and SH_DENYNO were exposed in the os module, then maybe tempfile could
>>
Tim Golden added the comment:
On 30/06/2012 06:45, Daniel Lenski wrote:
> My preferred solution would be to replace the binary delete argument of the
> current NamedTemporaryFile implementation with finer-grained options:
>delete=False # don't delete
&g
Tim Golden added the comment:
A "0" prefix to a number is taken by Python 2.x to introduce a series of octal
(base 8) digits. You can't have 8 in base 8 so the number (and anything higher)
is rejected.
--
nosy: +tim.golden
resolution: -> rejected
stage: -&g
Changes by Tim Golden :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15254>
___
___
Python-bugs-list mailing list
Unsubscri
Tim Golden added the comment:
Could you create a failing test, please, Tim S?
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue15267>
___
___
Tim Golden added the comment:
I can confirm that this isn't a problem for 3.x. No-one's listed in the experts
list for the httplib module but Senthil appears to be the de factor maintainer
so I've added him to the call for his opinion. My feeling would be to do the
simplest
Tim Golden added the comment:
Well os.listdir doesn't fail to access a UNC path on Windows x64 in
general. So presumably this particular path is not accessible by the
buildbot process owner?
--
___
Python tracker
<http://bugs.python.org/is
Tim Golden added the comment:
It's using an administrative share (\\server\d$) and those are usually
restricted with share permissions -- different from NTFS permissions.
That the process runs as a service is likely to have an effect since
services are conventionally run with minimum-priv
Tim Golden added the comment:
For this particular buildbot setup, maybe yes. But it would be possible
in principle to have a buildbot configuration which could allow the test
to execute. (eg one running under a user account which can access the
path via an admin share). Does the buildbot owner
Tim Golden added the comment:
My guess is that it's to do with Service Hardening. I did a quick dump
of my token in an interactive session and as the owner of a service.
Quite a few differences. I haven't read up on this area yet so I'm not
sure what options there are / how
Tim Golden added the comment:
Simplest solution might be to catch PermissionError and call skipTest from
within. This would allow buildbots to run the test which had access through the
relevant share.
--
___
Python tracker
<http://bugs.python.
Tim Golden added the comment:
Take the other approach and catch ACCESS_DENIED and skip?
--
___
Python tracker
<http://bugs.python.org/issue15334>
___
___
Pytho
Tim Golden added the comment:
(I just ran up a service and its environ does include PROMPT, at least
on an XP machine)
--
___
Python tracker
<http://bugs.python.org/issue15
Tim Golden added the comment:
It already produces a TypeError with a specific message if the input is
not iterable. You seem to be using a homegrown dialect; with the
conventional list (csv.reader("the quick brown fox")) you very quickly
see that you're iterating over a string.
Tim Golden added the comment:
This is a (near) duplicate of issue7443, I think.
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue15
Tim Golden added the comment:
I'm +1 on the approach in principle. I'm tentative about using ctypes
for this just because I don't believe we use it anywhere else. But at
the least I suggest applying the patch to see how Jeremy's buildbot
behaves. If there are wider objection
Tim Golden added the comment:
Fine with me
--
___
Python tracker
<http://bugs.python.org/issue15496>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Golden added the comment:
Paul, are you using the hg tip of pywin32? pywin32_postintall.py was
patched a couple of months ago to use imp.load_dynamic (essentially to
work around this issue).
--
nosy: +tim.golden
___
Python tracker
<h
Tim Golden added the comment:
Unfortunately this missed the boat for 3.3; I'll target 3.4 when we've got a
branch to commit to.
--
versions: +Python 3.4 -Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.
Changes by Tim Golden :
--
assignee: tim.golden ->
___
Python tracker
<http://bugs.python.org/issue6839>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Tim Golden :
--
assignee: -> tim.golden
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue16097>
___
___
Python-bugs-list mai
Tim Golden added the comment:
Committed in bb77400af434.
Thanks
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Tim Golden added the comment:
The natural way to do this in windows is using the Job API:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684161%28v=vs.85%29.aspx
However I'm not sure where to apply this within the multiprocessing
architecture (or if it's even a
Tim Golden added the comment:
Confirming that this doesn't happen on 2.7
py -2 £.py succeeds
py -3 £.py gives:
python: failed to set __main__.__loader__
--
___
Python tracker
<http://bugs.python.org/is
Changes by Tim Golden :
--
nosy: +christian.heimes
___
Python tracker
<http://bugs.python.org/issue16328>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Golden added the comment:
[this response appears to have got lost in an email black hole somewhere]
I assume that "$PYTHONPATH" is actually referring to sys.exec_prefix
(and not the PYTHONPATH env var which has nothing to do with this).
In any case c:\python27\scripts is still
I assume that "$PYTHONPATH" is actually referring to sys.exec_prefix
(and not the PYTHONPATH env var which has nothing to do with this).
In any case c:\python27\scripts is still the place for scripts. There is
a c:\python27\tools\scripts (which you're welcome to add to your %PATH%
if you find the
Tim Golden added the comment:
+1
--
___
Python tracker
<http://bugs.python.org/issue19962>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Tim Golden added the comment:
The attached patch issue9291.7.patch (which is essentially an amalgam of
9291.patch & 9291a.patch with some tweaks of my own) does appear to solve the
issue. My Windows setup is UK, so if any of the people still watching this
issue could test against a
Tim Golden added the comment:
All tests pass on 3.5 and in an unelevated prompt. I'll have a closer look at
the code tomorrow.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Tim Golden :
Removed file: http://bugs.python.org/file34925/issue9291.7.patch
___
Python tracker
<http://bugs.python.org/issue9291>
___
___
Python-bugs-list m
Tim Golden added the comment:
Another version of the patch: this one, in addition to removing the unnecessary
encodes, also does the check for extensions before attempting to open the
registry key, and narrows down the try-catch block to just the attempt to read
the "Content Type&q
Tim Golden added the comment:
This looks like a duplicate of issue9291; could you test the latest patch over
there, please?
--
assignee: -> tim.golden
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issu
Tim Golden added the comment:
I can confirm that the problem (which really is a hard crash) only applies to
2.7 and that the patch tests and fixes it. I'm happy to apply. Any objections?
--
assignee: -> tim.golden
nosy: +tim.golden
__
Tim Golden added the comment:
Committed. Thanks for the patch.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Golden added the comment:
Backed out the commits after all the Windows buildbots broke. Need to look
further. (No problems on a Win7 or Ubuntu build here).
--
___
Python tracker
<http://bugs.python.org/issue18
Tim Golden added the comment:
Here are a couple:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/4423
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8288
--
___
Python tracker
<h
Tim Golden added the comment:
I'm just pinging #python-dev to see if there's a way to request a buildbot
build from a specific server-side clone.
Meanwhile, though, I definitely introduced a change into your code which I
thought I had reverted, but clearly hadn't! The cod
Tim Golden added the comment:
Yes, now that the custom allocator / tracing stuff is in place:
otherwise there's no way for custom allocation or tracing to occur.
Please go ahead and rework the patch when you have the time.
Also, since the setup of the reparse header is such an underdocum
Tim Golden added the comment:
Fixed by issue9291
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Golden added the comment:
I updated the docs to emphasise that the file parameter to marshal.dump must be
a real file, not a wrapper.
--
assignee: -> tim.golden
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Tim Golden :
--
assignee: -> tim.golden
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pytho
Tim Golden added the comment:
The crypto stuff's not really my area. I agree that the patch looks sane.
--
___
Python tracker
<http://bugs.python.org/is
Tim Golden added the comment:
I can confirm that this crashes on Windows as well. Failure actually occurs in
gcmodule.c:finalize_garbage. Adding Guido as it looks as it's tied to asyncio.
--
nosy: +Guido.van.Rossum, tim.golden
___
Python tr
Tim Golden added the comment:
Unfortunately it looks as though this wasn't the correct way to close a Crypto
handle. It isn't a conventional handle and we be using CryptReleaseContext to
"close" it. cf
http://msdn.microsoft.com/en-us/library/windows/desktop/aa382041%28
Changes by Tim Golden :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue21393>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Tim Golden :
--
resolution: fixed ->
___
Python tracker
<http://bugs.python.org/issue21393>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Tim Golden:
At present test_zipfile uses shutil.rmtree to remove its test artefacts. This
intermittently but frequently fails to remove cleanly on a Windows development
box. Changing it to use the test.support helper functions should reduce the
incidence
Changes by Tim Golden :
--
keywords: +patch
Added file: http://bugs.python.org/file35156/issue21440.test_zipfile.patch
___
Python tracker
<http://bugs.python.org/issue21
Tim Golden added the comment:
Same goes for test_tarfile (updated patch attached)
--
Added file: http://bugs.python.org/file35157/issue21440.test_tarzipfile.patch
___
Python tracker
<http://bugs.python.org/issue21
Tim Golden added the comment:
Adding Zach as another Windows dev
--
nosy: +zach.ware
___
Python tracker
<http://bugs.python.org/issue21440>
___
___
Python-bug
Tim Golden added the comment:
Thanks, Zach. I was aware that calloc was in the air, but I wasn't sure
if it had been committed and I'd delayed on this enough so I thought I'd
push for now. We can always revisit.
--
___
Python
Tim Golden added the comment:
Thanks. I get them enough that it stops a test run being particularly
useful, especially when I've just touched something (eg unlink) which
might conceivably affect something like tarfile.
--
___
Python tracker
Tim Golden added the comment:
Buildbots seem happy. Thanks very much for the patches!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Golden added the comment:
Thanks for the research, eryksun. As long as it doesn't hurt let's leave
it as is for now.
--
___
Python tracker
<http://bugs.python.o
Tim Golden added the comment:
Thanks, eryksun: failed experiments are still useful data for future
reference!
--
___
Python tracker
<http://bugs.python.org/issue18
Tim Golden added the comment:
Use CryptReleaseContext to release Crypt handle on Windows
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Tim Golden :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Golden added the comment:
Well PyBytes_GET_SIZE is documented as returning a Py_ssize_t so I'd say it's
perfectly valid.
--
___
Python tracker
<http://bugs.python.o
Tim Golden added the comment:
To be honest I can't get excited about this one. The only sensible change is to
remove the rather specific comment about ValueError and just leave the fact
that only certain signals are valid.
Because the C code defines module-level constants on the bas
Tim Golden added the comment:
Ok, so to move this forward we have essentially two proposals:
1) Add a remove_readonly flag
2) Add a doc example which shows how to use the onerror handler to remove a
recalcitrant file.
I'm -0.5 on (1) because it feels like Windows-specific clutter; and
Tim Golden added the comment:
Fixed by issue9291
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Changes by Tim Golden :
--
nosy: -tim.golden
___
Python tracker
<http://bugs.python.org/issue1528593>
___
___
Python-bugs-list mailing list
Unsubscribe:
201 - 300 of 607 matches
Mail list logo
