New submission from Mark Dickinson dicki...@gmail.com:
See the thread starting at:
http://mail.python.org/pipermail/python-dev/2009-October/092958.html
Eric suggested that we don't need a separate branch for this; sounds
fine to me. It should still be possible to do the backport in stages,
Daniel Stutzbach dan...@stutzbachenterprises.com added the comment:
After some searching around with Google, 2- means close file
descriptor 2 (i.e., standard error).
--
nosy: +stutzbach
___
Python tracker rep...@bugs.python.org
Jesse Noller jnol...@gmail.com added the comment:
I plan on reviewing the patch once my work with PyCon is completed, which
should be within the next few weeks. The next release this would show up
in (2.7/3.2) is not for some time.
--
___
Python
Charles Cazabon charlesc-pyt...@pyropus.ca added the comment:
Okay, thanks, Jesse. Didn't realize the Con was on.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6963
___
New submission from Gerald Thaler ger...@netestate.de:
When a HTTP request done with urllib2.urlopen() gets redirected, the
second request will ignore the given timeout value and may hang
indefinitely.
--
messages: 93922
nosy: gthaler
severity: normal
status: open
title:
Jesse Noller jnol...@gmail.com added the comment:
Well, it's in feb, but I'm involved in some intense planning right now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6963
___
Changes by Lars Gustäbel l...@gustaebel.de:
--
assignee: - lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7101
___
Martin v. Löwis mar...@v.loewis.de added the comment:
I'm skeptical that a backport is a useful thing. First, the handler is
primarily meant for use with PEP 383, which means that it's all
internal; few applications will ever need to use it explicitly.
Furthermore, applications/libraries that
Tarek Ziadé ziade.ta...@gmail.com added the comment:
The new issue is : #7115
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7064
___
___
Changes by Tarek Ziadé ziade.ta...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7064
___
___
Python-bugs-list
Senthil Kumaran orsent...@gmail.com added the comment:
Can you mention the python --version in which you encountered this issue?
And piece of code which loops indefinitely?
The propagation of timeout to redirects has been fixed with Issue5102.
--
assignee: - orsenthil
nosy:
Martin v. Löwis mar...@v.loewis.de added the comment:
I'm skeptical that the patch is right (or, rather, that it is not a
compiler bug). According to
http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/i386.h?view=markup
in macro REG_CLASS_CONTENTS, the class AD_REGS includes indeed EDX and
Mark Dickinson dicki...@gmail.com added the comment:
Here's a relevant gcc bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21249
As I understand it, the rules are that in 32-bit mode A means edx/eax
for a 64-bit quantity, and in 64-bit mode A means rdx/rax for a 128-bit
quantity and
Mark Dickinson dicki...@gmail.com added the comment:
I just found a more recent one:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41133
Whether this is a gcc misfeature or not, it sounds as though it's not
going to change.
Maybe there should be two separate READ_TIMESTAMP cases? One for x86
Martin v. Löwis mar...@v.loewis.de added the comment:
Looking at this further, it seems that the rdtsc code got miscompiled on
x64 for some time already. Consider this code
typedef unsigned long long uint64;
uint64 f(uint64 b)
{
uint64 a;
__asm__ __volatile__(rdtsc : =A (a));
return
Mark Dickinson dicki...@gmail.com added the comment:
As for the specific code: I'm not sure whether it's guaranteed that
you can truncate output registers in an asm. If you can't, you
should make the output registers 64-bit integers on AMD64.
Specifying eax and edx directly, rather than
Senthil Kumaran orsent...@gmail.com added the comment:
Windows buildbots pass for this test. Closing the issue.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7043
Mark Dickinson dicki...@gmail.com added the comment:
FWIW, the Linux source splits things up into 32-bit and 64-bit, and uses
A for 32-bit and a and d for 64-bit; their 64-bit code (after
unwinding the macros) is essentially identical to the code in the patch.
See
Antoine Pitrou pit...@free.fr added the comment:
It occurs weaksets have the same problem, here is a new patch fixing
them as well.
--
Added file: http://bugs.python.org/file15114/weakiter3.patch
___
Python tracker rep...@bugs.python.org
New submission from Jon Nelson jnel...@users.sourceforge.net:
import os
try:
from email.mime.multipart import MIMEMultipart
except ImportError:
from email.MIMEMultipart import MIMEMultipart
m = MIMEMultipart('form-data')
print m.items()
m.as_string()
print m.items()
print out:
Jeff Senn s...@users.sourceforge.net added the comment:
Has there been any action on this? a PEP?
I disagree that using ICU is good way to simply get proper
unicode casing. (A heavy hammer for a small task...)
I agree locales are a different issue (and would prefer
optional arguments to the
Mark Dickinson dicki...@gmail.com added the comment:
simplify the code by directly outputting to (int*)v and
((int*)v)[1];
This does indeed seem to produce better compiler output, at least under
Apple gcc-4.0.1, Apple gcc-4.2.1, and non-Apple gcc-4.4.1.
Here's a revised patch, which also
Mark Dickinson dicki...@gmail.com added the comment:
Whoops. Wrong patch. Here's the right one.
--
Added file: http://bugs.python.org/file15116/tsc2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6603
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file15115/tsc2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6603
___
Mark Dickinson dicki...@gmail.com added the comment:
Aargh. I somehow deleted a backslash between testing and submitting that
patch. Sorry.
Third time lucky.
--
Added file: http://bugs.python.org/file15117/tsc3.patch
___
Python tracker
adgprogramming knd_a...@yahoo.com added the comment:
Here is what happened to me. See the attachment.
P.S.: I launched the installer and hit repair. Everything went fine in
the installer, but the problem still occured.
Should I upgrade to 3.11?
If I have to make a change in the source code
adgprogramming knd_a...@yahoo.com added the comment:
Oh! And my OS is Windows XP SP3 Media Center Edition Version.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6941
___
Tarek Ziadé ziade.ta...@gmail.com added the comment:
Added complementary fix in r75395
--
nosy: +pje
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7115
___
Koen van de Sande k...@tibed.net added the comment:
It may actually be enough to just place the
Microsoft.VC90.CRT.manifest file into the Python folder (the one with
python.exe and the CRT DLLs).
I concur with what Christoph says, that is how the embedded
installation works. However, the
Martin v. Löwis mar...@v.loewis.de added the comment:
I have a half finished implementation of this, in case anyone
is interested.
Feel free to upload it here. I'm fairly skeptical that it is
possible to implement casing correctly in a locale-independent
way.
--
Martin v. Löwis mar...@v.loewis.de added the comment:
The patch is fine, please apply (notice that the 2.6 branch is closed for
anything but 2.6.3 regressions right now, so you may want to defer this
after 2.6.4).
--
assignee: loewis - mark.dickinson
resolution: - accepted
Antoine Pitrou pit...@free.fr added the comment:
Please note that normally an error message is output, but of course it
doesn't display since stderr is invalid :-)
It's clearer if you close stdout instead:
$ ./python -c 'pass' -
Fatal Python error: Py_Initialize: can't initialize sys standard
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Fixed with r75396 (trunk) and r75397 (py3k)
I'll check with the buildbots before I close this issue.
--
resolution: - fixed
status: open - pending
___
Python tracker rep...@bugs.python.org
Terrence Cole terre...@zettabytestorage.com added the comment:
I get the same results on:
Python 2.6.2 (r262:71600, Sep 14 2009, 18:47:57)
[GCC 4.3.2] on linux2
I think this is the same issue I was seeing yesterday. You can exercise
the issue and cause an exception with just 6 lines:
#
Marc-Andre Lemburg m...@egenix.com added the comment:
Amaury Forgeot d'Arc wrote:
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Fixed with r75396 (trunk) and r75397 (py3k)
Thanks, Amaury.
I'll check with the buildbots before I close this issue.
--
status: pending -
Daniel Stutzbach dan...@stutzbachenterprises.com added the comment:
Is it even possible to portably test the validity of a file descriptor
without trying to write/read it?
When I first saw this bug, my gut feeling was well, don't do that
then! However, I then recalled that Windows GUI
Terrence Cole terre...@zettabytestorage.com added the comment:
When a manager receives a message, it unpickles the arguments; this
calls BaseProxy.__reduce__, which calls RebuildProxy. If we are in the
manager, this returns the actual object, otherwise it returns a new
proxy. If we naively
New submission from Guido van Rossum gu...@python.org:
Following my own (Twitter) advice I downloaded the 2.6.4rc1 release
candidate and installed it on my x86 iMac running OS X 10.5.8, and tried
to run a Google App Engine app with it. Google App Engine prefers Python
2.5, but so far it has
Bonnie Douglas bonnie.doug...@biarri.com added the comment:
The only other thing that I've done is change my firewall software.
I use Bullguard. I had to use the Custom Security settings for the
Firewall, but set it to always allow pythonw.exe and python.exe access
to all ports.
A colleague of
Guido van Rossum gu...@python.org added the comment:
FWIW, I've ruled out App Engine SDK 1.2.6 as the source of the regression;
on a MacBook Pro with the same OS 10.5.8 I get a similar traceback with
SDK 1.2.6.
--
___
Python tracker
Guido van Rossum gu...@python.org added the comment:
The full traceback had probably 1000 lines (or whatever the limit is); the
piece between two calls to logging.warn() is repeated over and over.
--
___
Python tracker rep...@bugs.python.org
Philip Jenvey pjen...@underboss.org added the comment:
App engine shows up after every import statement, so it must have some
kind of import hook -- which can do evil things
--
nosy: +pjenvey
___
Python tracker rep...@bugs.python.org
Changes by Philip Jenvey pjen...@underboss.org:
--
nosy: +vinay.sajip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7120
___
___
Python-bugs-list
Guido van Rossum gu...@python.org added the comment:
Yes, App Engine uses a PEP 302 style import hook to implement the sandbox.
Could it be that there's a new module dependency introduced by 2.6.3-4?
--
___
Python tracker rep...@bugs.python.org
Benjamin Peterson benja...@python.org added the comment:
While I am not able to reproduce this by running 1.2.6 on Gentoo Linux
with Rietveld, I will make an educated guess that it is the from
multiprocessing import current_process line in r75130. I doubt this
module is available on app engine,
Changes by Sridhar Ratnakumar sridh...@activestate.com:
--
nosy: +srid
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6403
___
___
Python-bugs-list
Terrence Cole terre...@zettabytestorage.com added the comment:
The tests for the SyncManager are being automagically generated at
import time -- I was not quite able to follow that well enough to know
exactly what is getting tested, or if they are even enabled. It did not
appear to contain any
Jesse Noller jnol...@gmail.com added the comment:
Yeah, the auto-generation is too clever and needs to be pulled out
entirely.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6766
___
Guido van Rossum gu...@python.org added the comment:
The dependency of logging on multiprocessing feels backwards. But it's
not actually a new regression, it seems that was there in 2.6.2.
--
___
Python tracker rep...@bugs.python.org
Changes by Brett Cannon br...@python.org:
--
nosy: -brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6941
___
___
Python-bugs-list
Guido van Rossum gu...@python.org added the comment:
The addition of multiprocessing support to logging seems to have happened
in 2.6.2; bad timing for a feature. :-(
--
title: 2.6.4rc1 regression - logging depends on multiprocessing
___
Python
New submission from mike mikez...@gmail.com:
There's a python program in the attached file http.py, I import
urllib.request in http.py, and urllib.request imports http.client.
When I try to run http.py by command python http.py, the error is as
below:
Traceback (most recent call last):
Ezio Melotti ezio.melo...@gmail.com added the comment:
Your file is named 'http.py'. When urllib.request tries to import
http.client your file (D:\program\python\http.py) is picked up first
instead of the right one ('C:\Program Files\Python311\lib\http\client.py').
Your file is then executed
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
I propose to fix it by just setting logRecord.processName to None for
now, which is what should happen if multiprocessing isn't available.
In environments where multiprocessing is not available,
logging.logMultiprocessing should be False,
54 matches
Mail list logo
