Gregory P. Smith added the comment:
gah. i was tracking this down because I saw some strange errors that made me
suspect it might exist (in 2.7) when trying to use a zipped up standard library
but had not had time to confirm it. :(
I really should have rolled back the CLs causing it before
Changes by Gregory P. Smith :
--
title: Issue with zipimport in 3.3.4 -> Issue with zipimport in 3.3.4 and
3.4.0rc1
___
Python tracker
<http://bugs.python.org/issu
Changes by Gregory P. Smith :
Added file: http://bugs.python.org/file34103/issue20621-34-rollbacks-gps01.diff
___
Python tracker
<http://bugs.python.org/issue20
Gregory P. Smith added the comment:
if you look at the zipimport.c file log there was one additional tiny change to
fix a potential memory leak made after the change I suggested backing out:
http://hg.python.org/cpython/log/fb5f4cfc3230/Modules/zipimport.c
anyways, yes, backing up to the
Gregory P. Smith added the comment:
What do you mean by "everything"? How much did you back out? I *ONLY* wanted
the patches I posted in 20621 backed out as those were the source of the
problem.
The changes made on 2014-01-06 and 2014-01-07 were good even though they only
address
Gregory P. Smith added the comment:
Confirmed that Modules/zipimport.c in the 3.3 and default branches is identical
to the version from late last year. Both should be good for 3.3.5 and 3.4.0
releases.
--
___
Python tracker
<h
Gregory P. Smith added the comment:
At this point i'll be reapplying things since 8dbf8edb7128 to 2.7 and trying to
untangle where the problem came in. I confirmed with diff that you've backed
everything out to the pre-January state in all branches.
I've had part of th
Gregory P. Smith added the comment:
I believe this happens on all platforms.
--
___
Python tracker
<http://bugs.python.org/issue20621>
___
___
Python-bugs-list m
New submission from Gregory P. Smith:
Please cherry-pick 52ab9e1ff46a to roll back the zipimport brokenness.
This is the change that fixes issue20621 which is causing a rapid 3.3.5 brown
bag release.
--
assignee: larry
messages: 211391
nosy: gregory.p.smith, larry
priority: release
Gregory P. Smith added the comment:
Thanks for trying. :) I've got a complicated "test" case of zipping up the
stdlib into python27.zip and running the Python test suite against that
which also tends to trigger the bugs. Some tests failing with SystemError
and such.
It smell
Gregory P. Smith added the comment:
there's a separate issue open for you with the necessary rollback patch to
apply to your 3.4 release branch. http://bugs.python.org/issue20651
This particular issue is actually solved in default, 3.3 and 2.7 as benjamin
did the backouts/rollbacks o
Gregory P. Smith added the comment:
I don't see why this cannot wait until 3.4.1.
True, rounding away from zero is desirable in these cases but it seems like
this should be a non issue most of the time and any distro (ubuntu) that picks
up 3.4.0 can apply this fix to their own python pa
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue15819>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue19142>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
*Rereads latest patch*
I'm happy with this being backported as a bugfix to 3.1 and 2.6 so long
as the set_tunnel method is hidden. Call it _set_tunnel() in the
backport (and don't document its
Gregory P. Smith added the comment:
good catch. thanks!
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue6567>
___
___
Python-bug
Changes by Gregory P. Smith :
--
assignee: -> ezio.melotti
___
Python tracker
<http://bugs.python.org/issue5511>
___
___
Python-bugs-list mailing list
Un
Gregory P. Smith added the comment:
Agreed, a standalone release combined with a public announcement about
its availability is a must if we want to get any sort of wide spread
testing.
It'd be great if we had a fully characterized set of tests for the
behavior of the existing engine... b
Changes by Gregory P. Smith :
--
assignee: loewis -> gregory.p.smith
nosy: +gregory.p.smith
priority: low -> normal
___
Python tracker
<http://bugs.python.org/
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
priority: -> normal
___
Python tracker
<http://bugs.python.org/
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue1006238>
___
___
Python-
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue1597850>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue5404>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
nice test case rhettg.
This is a correctness issue to prevent data loss on EINTR.
I've attached a patch that builds on rhettg's but allows the EINTR signal
to propagate upwards as desired by loweis and jorend for both read() and
readli
Gregory P. Smith added the comment:
realistically, file objects (Objects/fileobject.c) never raise EINTR as
they use the C library fread/fwrite/fclose underneath. Why should a
socket based file object every be allowed to raise EINTR rather than
handling it internally?
IMHO people should
Gregory P. Smith added the comment:
for each of these discrepancies that you're finding, please consider
submitting them as patches that add a unittest to the existing test
suite. otherwise their behavior guarantees will be lost regardless of if
the suite in this issue is adopted. t
Gregory P. Smith added the comment:
r73916 appears to fix this?
--
___
Python tracker
<http://bugs.python.org/issue3392>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
merged into release31-maint in r74425.
reopen the issue if this doesn't fix the problem.
--
status: open -> closed
versions: -Python 2.6
___
Python tracker
<http://bugs.python.or
Gregory P. Smith added the comment:
fixed in trunk r74426. socket.socket.sendall() and all
socket._fileobject methods (read/readline/write/flush) now properly
handle EINTR internally.
sendall will allow a python signal handler to raise an exception
aborting it in unknown state, otherwise it
Gregory P. Smith added the comment:
Note that http://bugs.python.org/issue4879 may have already fixed this
problem in trunk r68532.
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue2
Gregory P. Smith added the comment:
Okay, I do not think this has been fixed yet. Anyone calling
getresponse() can indeed use buffering=True, it can mess things up if
the do not close the connection afterwards.
The addition of the sockbuf parameter to HTTPConnection as proposed in
Gregory P. Smith added the comment:
backported to release26-maint in r74456.
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue6
Gregory P. Smith added the comment:
I believe there will be a problem with the patch committed in r68532.
If getresponse(buffering=True) is called, extra data on the socket may
be consumed by the socket.makefile() buffer which will cause problems if
the connection is not closed immediately
Gregory P. Smith added the comment:
Anything that adds a new parameter can not be backported to 2.6 as that
counts as an API change / feature addition.
--
___
Python tracker
<http://bugs.python.org/issue2
Gregory P. Smith added the comment:
trunk r74463 now forces the HTTPResponse to close afterwards when
buffering=True to avoid the issue.
--
___
Python tracker
<http://bugs.python.org/issue4
Gregory P. Smith added the comment:
trunk r74463 now forces the HTTPResponse with buffering=True to close
afterwards using a HTTPResponse._must_close flag similar to what was
suggested in buffered_socket.diff in this issue.
--
___
Python tracker
Gregory P. Smith added the comment:
I am also unable to reproduce the reported problem using the
pastebin.ca/973578 code. The time to download 400mb from localhost
remains the same regardless of buffering=False (default) or True.
The problem still exists but it is better described in
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue6665>
___
___
Python-
Gregory P. Smith added the comment:
+1 on the PyXXX_ClearFreeList patch and calling them from gc.collect()
as is done with the others.
I agree with Guido, don't add a tp_free_list slot as the common case
would be NULL.
Regarding gc clearing freelists: I agree with Antoine and M
Gregory P. Smith added the comment:
haha wow I just read the fnmatch code... trunk r2734 | guido | 1992-01-12
added fnmatch._cache for it to cache compiled regular expressions. That
has -long- since become unnecessary as the re module does that itself. ;)
I'll clean this up while f
Gregory P. Smith added the comment:
aww, i guess the _cache does cache the result of the glob -> regular
expression translation. it needs to stay for that.
--
___
Python tracker
<http://bugs.python.org/iss
Gregory P. Smith added the comment:
changing the '$' to \Z(?ms)' fixes the problem.
--
___
Python tracker
<http://bugs.python.org/issue6665>
___
___
Gregory P. Smith added the comment:
fixed in trunk r74475, py3k r74476
--
___
Python tracker
<http://bugs.python.org/issue6665>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
I'll backport this to 2.6 and 3.1 later (its too late for 3.1.1).
--
versions: -Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/i
Gregory P. Smith added the comment:
That code was indeed a mess. I've incorporated most suggestions from
your cleaned up version (and fixed a bug in it) in trunk r74479.
Have you ever seen __get_builtin_constructor fail in practice? I can
imagine that packing up a stripped down p
Gregory P. Smith added the comment:
Yeah I'd take this to the list. Perhaps this is destined to be a public
API.
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/i
Gregory P. Smith added the comment:
btw, when using async io (poll, select, etc) I -think- your socket will
see a read event when the server closes the connection (sends you a FIN
or even a RST) at which point your sock.recv() when you've been told
data was ready will return 0 bytes indic
New submission from Gregory P. Smith :
The python logging module uses a lock to surround many operations, in
particular. This causes deadlocks in programs that use logging, fork
and threading simultaneously.
1) spawn one or more threads in your program
2) have at least one of those threads
Gregory P. Smith added the comment:
hmm apparently the bug i was fixing in r74463 is not actually a bug, the
httplib module does not support streaming requests in any way so even with
a new socket buffer being constructed per request, the buffer is
guaranteed to be empty at the end of
Gregory P. Smith added the comment:
reverted in r74522
--
___
Python tracker
<http://bugs.python.org/issue6724>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
The decryption provided by the zipfile module is for the worthless
32-bit crc based "encryption" of zipfiles. I think promoting the use of
that is a bad idea.
zipfile can be used by people to get their data out of such files. We
should not enco
Gregory P. Smith added the comment:
I've started a project to patch this and similar messes up for Python
2.4 and later here:
http://code.google.com/p/python-atfork/
I'd like to take ideas or implementations from that when possible for
future use in the python standa
Gregory P. Smith added the comment:
The people who do not know how to get over that wall would be equally
stumped if presented with tokenized .pyc or .pyo files. No fake
encryption needed.
--
___
Python tracker
<http://bugs.python.org/issue6
Gregory P. Smith added the comment:
Already reverted in
r74522 | gregory.p.smith | 2009-08-18 22:33:48 -0700 (Tue, 18 Aug 2009)
for that reason.
--
___
Python tracker
<http://bugs.python.org/issue4
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue6508>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
we should never pretend an old module doesn't exist. leave optparse as
optparse. argparse can come in under its own name.
we can mark getopt and optparse as deprecated at some point and remove
them in 10 years :)
+1 on inclusion btw. It looks like
Changes by Gregory P. Smith :
--
priority: -> low
___
Python tracker
<http://bugs.python.org/issue6800>
___
___
Python-bugs-list mailing list
Unsubscri
Gregory P. Smith added the comment:
There is no OS level API to kill threads. Python does not kill threads.
When you exec, your entire process should be replaced by the OS, threads
shouldn't matter they should simply disappear just as the rest of your
process state does.
This is
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue1590864>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Gregory P. Smith :
--
nosy: +collinwinter, gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue6713>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
On Mon, Sep 14, 2009 at 11:15 AM, Armin Ronacher wrote:
>
> Armin Ronacher added the comment:
>
>> @Armin: Doesn't that argument apply to *any* library proposed for
>> inclusion in the standard library? By which logic we should ne
Gregory P. Smith added the comment:
For reference, this is related to http://bugs.python.org/issue6721 but
deals with the C API side of things for an atfork mechanism to be used by
extension modules.
--
nosy: +gregory.p.smith
___
Python tracker
Gregory P. Smith added the comment:
issue 6923 has been opened to provide a C API for an atfork mechanism for
use by extension modules.
--
components: +Library (Lib)
___
Python tracker
<http://bugs.python.org/issue6
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
priority: -> normal
___
Python tracker
<http://bugs.python.org/
Gregory P. Smith added the comment:
Documentation note added (copied from tarfile) in trunk r75149,
release26-maint r75150 (hopefully in time for 2.6.3 but thats up to
Barry).
--
___
Python tracker
<http://bugs.python.org/issue6
Gregory P. Smith added the comment:
Adding a warning to the documentation is not wrong, it is the only thing
that is possible for the 2.6.3 release. Its too late in the current
release process to change code.
--
___
Python tracker
<h
Gregory P. Smith added the comment:
yes this will be fixed in 2.7/3.2.
as for creative uses where someone might want the out of supplied path
overwriting behavior? those people are insane and should be made to jump
through extra hoops to get it
Changes by Gregory P. Smith :
--
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue6972>
___
___
Python-bugs-list mailin
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
priority: -> high
___
Python tracker
<http://bugs.python.org/issue7079>
___
___
Python-bugs-
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue812369>
___
___
Python-
Gregory P. Smith added the comment:
> Antoine Pitrou added the comment:
>
> Rather than having a kind of global module registry, locks could keep
> track of what was the last PID, and reinitialize themselves if it changed.
> This is assuming getpid() is fast :-)
Locks can&#x
Gregory P. Smith added the comment:
no need for that. the problem is that they're held by a thread that
does not exist in the newly forked child process so they will never be
released in the new process.
example: if you fork while another thread is in the middle of logging
something and
Gregory P. Smith added the comment:
Seems simple enough, I don't see why not.
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/i
Gregory P. Smith added the comment:
This only appears to happen on Solaris. What version of Solaris are you
using? (i doubt that matters, i expect it happens on all versions)
I haven't look closely enough at the code yet, but reinitializing the
import lock in the child process should
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith -gps
___
Python tracker
<http://bugs.python.org/issue7208>
___
___
Python-
Gregory P. Smith added the comment:
Peter - can you apply the patch from svn r76000 and test that it works
properly on Solaris?
--
___
Python tracker
<http://bugs.python.org/issue7
Gregory P. Smith added the comment:
It might mean that other threads with access to the same file handle
could interfere and intercept part of the password entry if they wanted
to but thats not too concerning.
py3k/Modules/_io/bufferedio.c which is presumably used when input is
sys.stdin
Gregory P. Smith added the comment:
Documenting the parameters needed to avoid all AC_TRY_RUNs is a good first
step for any that are not obvious how to convert from AC_TRY_RUN into
something else.
--
___
Python tracker
<http://bugs.python.
Gregory P. Smith added the comment:
Removing a toxic person from the cc list. Mike, please go harm some other
all volunteer project.
--
nosy: -vapier
___
Python tracker
<http://bugs.python.org/issue1006
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
components: +Library (Lib)
nosy: +gregory.p.smith
priority: -> normal
title: getpass crashes when several returns are in stdin before getpass was
called -> getpass raises IOError when several returns are in std
Gregory P. Smith added the comment:
am unable to duplicate this behavior on Linux or OS X using python 2.6.
What platform did you see the problem on?
that said, can you apply the following patch to your getpass.py and see if
it helps at all?
http://svn.python.org/view/python/trunk/Lib
Gregory P. Smith added the comment:
ah i misread your example. the following works to reproduce it:
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
&
Gregory P. Smith added the comment:
and the r76000 patch does not fix it. investigating.
--
___
Python tracker
<http://bugs.python.org/issue7246>
___
___
Pytho
Gregory P. Smith added the comment:
change that. it looks like r76000 in trunk already fixes this. i was
using an old build when i tried earlier.
merged into release26-maint in r76015.
--
resolution: -> fixed
status: open -> closed
___
Gregory P. Smith added the comment:
merged into release26-maint in r76015. this patch also fixed issue7246.
py3k r76017
release31-maint r76019
--
resolution: -> fixed
status: open -> closed
versions: -Python 2.6, Python 2.7
___
Python t
Gregory P. Smith added the comment:
Fixed in release26-maint r76022. This will appear in Python 2.6.5.
I'm leaving release30-maint alone as it is already in 3.1.
sorry for not making it into 2.6.3/2.6.4 despite the code being ready. I
should've set this as a relea
Gregory P. Smith added the comment:
release26-maint r76023 to appear in Python 2.6.5.
release31-maint r76024 to appear in Python 3.1.2.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Gregory P. Smith added the comment:
Thanks for the patch!
applied in trunk r76028/r76029. py3k r76030/r76032
There are more of these, other bugs are open that should result in us
cleaning them up. see issue1006238 for example.
--
resolution: -> fixed
status: open ->
Gregory P. Smith added the comment:
these two have been merged and applied to trunk.
"""
i fixed the chflags specific check a long time ago (as i imagine others
have as well):
http://sources.gentoo.org/dev-lang/python/files/python-2.6-chflags-
cross.patch
same goes for the
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue6873>
___
___
Python-
Changes by Gregory P. Smith :
--
priority: -> normal
___
Python tracker
<http://bugs.python.org/issue6873>
___
___
Python-bugs-list mailing list
Unsubscri
Gregory P. Smith added the comment:
How about defining this in threading.py:
def _enumerate():
"""Internal use only: enumerate() without the lock."""
return _active.values() + _limbo.values()
And calling it from _threading_local instead of accessi
Gregory P. Smith added the comment:
Reviewers: ,
http://codereview.appspot.com/150055/diff/1/4
File Modules/_threadmodule.c (right):
http://codereview.appspot.com/150055/diff/1/4#newcode221
Modules/_threadmodule.c:221: return PyBool_FromLong((long) r);
This explicit (long) cast is unnecessary
Gregory P. Smith added the comment:
Can you make the C implementation's repr() show something similar to the
Python implementation?
--
___
Python tracker
<http://bugs.python.org/i
Gregory P. Smith added the comment:
Attaching an updated patch that includes unittests.
I also changed the set functions to take input as long's instead of int's
as that is more likely to fit within a uid_t and forced the return values
on the get's to fit within a long and use
Changes by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
priority: -> normal
___
Python tracker
<http://bugs.python.org/
Changes by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue7406>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
indeed, those were missed. fixed in trunk r77007 and release26-maint
r77008.
--
___
Python tracker
<http://bugs.python.org/issue1747
Gregory P. Smith added the comment:
I applied the same fix that was applied to chown in trunk r77007 for
lchown and fchown. Could you test it on a platform where it previously
failed?
The existing code might still have issues if there are platforms where
uid_t and gid_t are unsigned but
Gregory P. Smith added the comment:
lemburg - see which issue #?
Anyways perhaps the right thing to do instead of trunk r65961 would have
been to change the s# to an s*.
Undoing it will be more painful now as several changes have gone in since
that require undoing and possibly redoing
2701 - 2800 of 3274 matches
Mail list logo
