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
New submission from Tim Smith :
In httplib.py, there is this code to try to get the body length:
def _set_content_length(self, body):
# Set the content-length based on the body.
thelen = None
try:
thelen = str(len(body))
except TypeError, te
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 Smith added the comment:
Here is a program that demonstrates the problem:
import httplib
import tempfile
f = tempfile.TemporaryFile()
f.write("Hello, Temporary File!")
f.seek(0)
c = httplib.HTTPConnection('bugs.python.org')
c.request('
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 Peters added the comment:
Matthew is right: the nested quantifiers can cause this to take a very long
time when the regexp doesn't match. Note that the example cannot match,
because nothing in the regexp can match the space before "warning" in the
example string.
Tim Peters added the comment:
Matthew, yes, PyPy's regex module implements regular expressions of the
"computer science" (as opposed to POSIX) sense. See Friedl's book for a full
explanation. Short course is that regex's flavor of regexp matching is
linear-time, but
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 Savannah added the comment:
As an update (since someone else has this problem) this issue stopped once we
converted from centos to archlinux (www.archlinux.org). May be an underlying
issue with something in the centos environment. We used the same modules same
configuration basically same
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
Tim Chase added the comment:
http://docs.python.org/library/mailbox.html#mailbox.Message still points to
mailbox.Message instead of email.Message "A subclass of the email.Message
module’s {bad link}Message{/bad link}"
Not sure if this is a matter of changes that haven't yet be
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 Peters added the comment:
+1. Note that this really can't be done in user-level code. For example,
consider matching the pattern
a|ab
against the string
ab
Without being _forced_ to consider the "ab" branch, the regexp will match just
the "a" branch. So, e
Tim Peters added the comment:
Antoine, that's certainly the conceptual intent here. Can't say whether your
attempt works in all cases. The docs don't guarantee it. For example, if the
original regexp started with (?x), the docs explicitly say the effect of (?x)
is undefine
Tim Peters added the comment:
Matthew, Guido wrote "check that the whole input string matches" (or slice if
pos and (possibly also) endpos is/are given). So, yes, \Z is more to the point
than $ if people want to continue wasting time trying to implement this as a
Python-level funct
Tim Peters added the comment:
Serhiy, I expect this is easy to implement _inside_ the regexp engine. The
complications come from trying to do it outside the engine. But even there,
wrapping the original regexp in
(?:)\Z
is at worst very close. The only insecurity with that I've th
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 Peters added the comment:
I like "matchall" fine, but I can't channel Guido on names - he sometimes gets
those wrong ;-)
--
___
Python tracker
<http://bugs.pyt
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 Peters added the comment:
In the absence of Guido here, I'll channel him ;-) "The problem" with oddball
platforms has been that some require major changes in many parts of the
interpreter, and then all the added cruft complicates life for every
maintainer, while few peo
Tim Peters added the comment:
The first footnote in the docs explain this:
Examples containing both expected output and an
exception are not supported. Trying to guess where
one ends and the other begins is too error-prone,
and that also makes for a confusing test.
So, sorry
Tim Peters added the comment:
Steven, no objection here.
--
___
Python tracker
<http://bugs.python.org/issue21183>
___
___
Python-bugs-list mailing list
Unsub
Tim Peters added the comment:
Yup, agreed with all: ValueError makes a lot more sense, but the change
shouldn't be backported.
--
___
Python tracker
<http://bugs.python.org/is
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
Tim Peters added the comment:
Comparison can certainly trigger a recursion error if the sequences contain no
(or few) matching non-junk elements, but contain many "almost matching"
elements. If the sequences have lengths M and N, recursion can go as deep as
2*min(M, N) then.
Now i
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 Peters added the comment:
I wonder whether this new function would attract any users, given that the user
already has control over the smallest ratio that will be accepted, and over the
maximum number of close matches returned. That's always been sufficient for me.
What useful th
Tim Peters added the comment:
Russell, I'm still looking for a sufficiently compelling "use case" here:
something tangible and useful that can be done with the new function that can't
be easily done now.
"I plan to write a web API that accepts a word, 'doge&#x
Tim Peters added the comment:
Just noting that, for me, the problem goes away if
del c, c2
is added as the last line of the test. This suggests the problem is due to
changes in end-of-life module cleanup.
Without that line, I see 3 kinds of output:
1.
del child
del child
del parent
parent
Changes by Tim Peters :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue21351>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
I think Antoine is right on all counts. The most surprising bit may be that p,
c, and c2 are in reference cycles, but - surprising or not - that's always been
true. The reason "it worked" before 3.4 is that CPython happened to break the
cycle
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 Peters added the comment:
After more thought, I don't think the user can do anything to influence
finalization order in cases like this, short of adding "del" statements (or
moral equivalents) to break cycles before the interpreter shuts down.
Fine by me ;-) Something C
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 Peters added the comment:
I don't see a way to test it either, but it's easy enough to prove it's correct
;-) That is, looks good to me!
--
nosy: +tim.peters
___
Python tracker
<http://bugs.pyt
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 Peters added the comment:
There's no way to influence finalization order for objects in cycles, and there
never was. So nothing actually changed in that respect ;-) What did change is
that Python used to forcibly break many module-level cycles in a way that just
happened to resu
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 Peters added the comment:
Guido, that's no good. The outer loop is traversing a doubly-linked circular
list, and it should be flatly impossible for gc to ever be NULL - the list
structure is insanely damaged if any gc_next or gc_prev field reachable from it
is NULL (gc always comes
Tim Peters added the comment:
Thought question: suppose finalize_garbage() is called with a collectable list
all of whose members are in fact going to be destroyed?
I don't see how the loop iteration logic could reliably work then. For
concreteness, suppose there's only object -
1401 - 1500 of 2346 matches
Mail list logo
