[issue7120] logging depends on multiprocessing

[Vinay Sajip]

Vinay Sajip  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, but that fix needs to go
into GAE, I guess?

Benjamin, I believe you added this change (in r70348), are you
comfortable with what I'm proposing? Anyone else have any objections?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7121] ImportError of urllib.request & http.client under PYTHONHOME/Lib

[Ezio Melotti]

Ezio Melotti  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 again and when it calls urllib.request,
urllib has not been completely imported yet, so the call fails.
Try to use another name for your program.

--
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: compile error -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7121] ImportError of urllib.request & http.client under PYTHONHOME/Lib

[mike]

New submission from mike :

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):
  File "http.py", line 4, in 
import urllib.request
  File "C:\Program Files\Python311\lib\urllib\request.py", line 86, in

import http.client
  File "D:\program\python\http.py", line 6, in 
response = urllib.request.urlopen('http://python.org/')
AttributeError: 'module' object has no attribute 'request'


   However, if I copy http.py to directory PYTHONHOME/Lib and run
command "python http.py" under directory PYTHONHOME/Lib, it works
successfully; if you move it to other directories and run the command,
the error will be returned.


   Note: the source code of http.py is copied from python311.chm under
directory PYTHONHOME/Doc.

--
components: Library (Lib)
files: http.py
messages: 93965
nosy: mikezp59
severity: normal
status: open
title: ImportError of urllib.request & http.client under PYTHONHOME/Lib
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file15121/http.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] logging depends on multiprocessing

[Guido van Rossum]

Guido van Rossum  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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6941] Socket error when launching IDLE

[Brett Cannon]

Changes by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] 2.6.4rc1 regression

[Guido van Rossum]

Guido van Rossum  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

[Jesse Noller]

Jesse Noller  added the comment:

Yeah, the auto-generation is too clever and needs to be pulled out 
entirely.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

[Terrence Cole]

Terrence Cole  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 recursion, however.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6403] distutils builds extension modules to root package directory

[Sridhar Ratnakumar]

Changes by Sridhar Ratnakumar :


--
nosy: +srid

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] 2.6.4rc1 regression

[Benjamin Peterson]

Benjamin Peterson  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, so it tries to use logging.warn,
which tries to import multiprocessing...

--
assignee:  -> vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] 2.6.4rc1 regression

[Guido van Rossum]

Guido van Rossum  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] 2.6.4rc1 regression

[Philip Jenvey]

Changes by Philip Jenvey :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] 2.6.4rc1 regression

[Philip Jenvey]

Philip Jenvey  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

[Jesse Noller]

Jesse Noller  added the comment:

Nothing jumps out to me off the top of my head - I can take a closer look 
at this after my pycon planning duties finish up in a few weeks. I agree 
this is unintended behavior. I'll need to audit the tests to make sure 
that A> This is being tested, and B> Those tests are not disabled.

When we included multiprocessing, some tests were deemed too unstable at 
the time, and we disabled. This was unfortunate, and I haven't been able 
to circle back and spend the time needed to refactor the test suite.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] 2.6.4rc1 regression

[Guido van Rossum]

Guido van Rossum  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] 2.6.4rc1 regression

[Benjamin Peterson]

Benjamin Peterson  added the comment:

How many lines are there in the traceback? Are there repetitions?

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] 2.6.4rc1 regression

[Guido van Rossum]

Guido van Rossum  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6941] Socket error when launching IDLE

[Bonnie Douglas]

Bonnie Douglas  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 mine is also running XP and ditched IDLE because it kept
crashing.  I explained my reconfiguration of the firewall to him
yesterday but he hasn't implemented my changes yet so I can't report his
success/failure.

Notepad++ is a great editor to use with Python; it is Python-aware (and
it's free).  Another colleague uses it along with "print" in his code
for debugging.

Finally, our computer scientist recommends using Linux only.  Apparently
that solves all problems?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7120] 2.6.4rc1 regression

[Guido van Rossum]

New submission from Guido van Rossum :

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 always worked with 2.6 as well, modulo 1-2 
warnings.  But not 2.6.4rc1!  Even on a trivial app I get "RuntimeError: 
maximum recursion depth exceeded".  I'm attaching a file with the 
traceback (repetitive stuff elided).

I'd be happy to provide more details if they are needed to reproduce.  I'm 
using the Google App Engine SDK 1.2.6.

--
components: Library (Lib)
files: traceback.txt
messages: 93952
nosy: gvanrossum
severity: normal
status: open
title: 2.6.4rc1 regression
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15120/traceback.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

[Terrence Cole]

Terrence Cole  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 disable the ability for proxied objects to be
unredirected in the manager, as in the attached svn diff, this solves
the problem that Carlos and I are seeing.  Surprisingly, after applying
this change, the full multiprocessing regression test still runs fine. 
I'm sure this change should have some greater impact, but I'm not sure
what.  I would appreciate if someone more knowledgeable could comment.

--
keywords: +patch
Added file: http://bugs.python.org/file15119/mp_proxy_hack.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7111] core dump when stderr is moved

[Daniel Stutzbach]

Daniel Stutzbach  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 applications have no
stdin, stdout, or stderr.  

Python 2 will raise IOError: Bad File Descriptor when the user tries to
write to stdout or stderr (more accurately, it raises the exception when
trying to flush data to the file descriptor).  

I just tested pythonw.exe.  If I set sys.stderr by hand to a file, then
write to sys.stdout, 2.6 will correctly write the exception to the file.
 3.1 exits silently.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7112] unicodetype_db.h warning: integer constant is too large for 'long'

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc  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 -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

[Terrence Cole]

Terrence Cole  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:

# CODE #
from multiprocessing import Manager
manager = Manager()
ns_proxy = manager.Namespace()
evt_proxy = manager.Event()
ns_proxy.my_event_proxy = evt_proxy
print ns_proxy.my_event_proxy

# TRACEBACK #
Traceback (most recent call last):
  File "test_nsproxy.py", line 39, in 
print ns_proxy.my_event_proxy
  File "/usr/lib64/python2.6/multiprocessing/managers.py", line 989, in
__getattr__
return callmethod('__getattribute__', (key,))
  File "/usr/lib64/python2.6/multiprocessing/managers.py", line 740, in
_callmethod
raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError:
-
Unserializable message: ('#RETURN', )
-

Storing a proxy into a proxied object and then accessing the proxy 
returns a copy of the object itself and not the stored proxy.  Thus,
updates to the nested dict are local and do not update the real object,
and proxies to unpicklable objects raise an exception when accessed.

--
nosy: +terrence

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7112] unicodetype_db.h warning: integer constant is too large for 'long'

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7111] core dump when stderr is moved

[Antoine Pitrou]

Antoine Pitrou  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 streams
OSError: [Errno 9] Bad file descriptor
Abandon

If we want to allow for closed {stdin, stdout, stderr}, I'm not sure
what the semantics should be. Should sys.std{in, out, err} be None? Or a
file object which always throws an error?

Under Python 2.x, you don't get a crash but the behaviour is quite
unhelpful anyway:

$ python -c 'print 1' >&-
close failed in file object destructor:
Error in sys.excepthook:

Original exception was:

--
nosy: +pitrou
priority:  -> normal
versions: +Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Martin v . Löwis]

Martin v. Löwis  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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4610] Unicode case mappings are incorrect

[Martin v . Löwis]

Martin v. Löwis  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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC

[Koen van de Sande]

Koen van de Sande  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 .pyd files are not in the Python main 
folder. And therefore they shouldn't have a manifest for the runtimes 
(because it will look in the current folder relative to the DLL/pyd), 
because then the runtimes of the main python.exe will be used (which 
can then be in the same folder as the 'embedded' MSVCR location).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7115] extension module builds fail when using paths in the extension name

[Tarek Ziadé]

Tarek Ziadé  added the comment:

Added complementary fix in r75395

--
nosy: +pje

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6941] Socket error when launching IDLE

[adgprogramming]

adgprogramming  added the comment:

Oh! And my OS is Windows XP SP3 Media Center Edition Version.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6941] Socket error when launching IDLE

[adgprogramming]

adgprogramming  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 for IDLE, I am fine with 
that, I am an experienced programmer. I just need instructions.

Please help!

--
nosy: +adgprogramming
Added file: http://bugs.python.org/file15118/idleerror.bmp

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Mark Dickinson]

Mark Dickinson  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Mark Dickinson]

Changes by Mark Dickinson :


Removed file: http://bugs.python.org/file15115/tsc2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Mark Dickinson]

Mark Dickinson  added the comment:

Whoops. Wrong patch.  Here's the right one.

--
Added file: http://bugs.python.org/file15116/tsc2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Mark Dickinson]

Mark Dickinson  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 separates the i386 and x86_64 cases.

Assigning to Martin for review.

--
assignee: mark.dickinson -> loewis
Added file: http://bugs.python.org/file15115/tsc2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4610] Unicode case mappings are incorrect

[Jeff Senn]

Jeff Senn  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 unicode object casing methods -- 
that could then be used within any future sort of locale object 
to handle correct casing -- but don't rely on such.)

Most of the special casing rules can be accomplished by 
a decomposition (or recursive decomposition) on the character
followed by casing the result -- so NO new table is necessary
-- only marking up the characters so implicated (there are
extra unused bits in the char type table that could be used 
for this purpose -- so no additional space needed there either).  

What remains are a tiny handful of cases that need to be handled
in code.

I have a half finished implementation of this, in case anyone
is interested.

--
nosy: +senn

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7119] email: msg.items() returns different values before and after msg.as_string()

[Jon Nelson]

New submission from Jon Nelson :

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:

[('Content-Type', 'multipart/form-data'), ('MIME-Version', '1.0')]
[('Content-Type', 'multipart/form-data;
boundary="===0836597002796039051=="'), ('MIME-Version', '1.0')]

The latter is correct, the former is not - it is missing the boundary!
items() should behave the same regardless of whether or not as_string()
has been called.


Confirmed in 2.4 and 2.6

--
components: Library (Lib)
messages: 93935
nosy: jnelson
severity: normal
status: open
title: email:  msg.items() returns different values before and after 
msg.as_string()
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7105] weak dict iterators are fragile because of unpredictable GC runs

[Antoine Pitrou]

Antoine Pitrou  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Mark Dickinson]

Mark Dickinson  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

http://lxr.linux.no/linux+v2.6.31/arch/x86/include/asm/msr.h

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7043] test_urllib: constructLocalFileUrl returns invalid URLs on Windows

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Windows buildbots pass for this test. Closing the issue.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Mark Dickinson]

Mark Dickinson  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 using "a" and "d", 
would presumably also work here?


> If you can, I think you 
> can "simplify" the code by directly outputting to (int*)v and 
>((int*)v)[1];

I'll take a look at that.  Thanks.

> FWIW, I don't consider a bug that only occurs --with-tsc and only on 
> AMD64 critical.

Sorry.  I got overexcited.  Changed priority to 'normal'.

--
priority: critical -> normal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Martin v . Löwis]

Martin v. Löwis  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 a+b;
}

My Apple gcc 4.0.1 compiles that into 

_f:
pushq   %rbp
movq%rsp, %rbp
rdtsc
addq%rdi, %rax
leave
ret

Here, %rdi is the incoming parameter; %rdx is not considered at all. 
This seems to come from DImode (double integer) processing: gcc just 
"knows" that a DImode variable lives in a single register on AMD64.

So even if your code is right in principle, I still think there is a gcc 
bug here.

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. If you can, I think you 
can "simplify" the code by directly outputting to (int*)v and 
((int*)v)[1]; this would be worthwhile only if the generated code 
actually gets better by omitting the shift operation.

FWIW, I don't consider a bug that only occurs --with-tsc and only on 
AMD64 critical.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Mark Dickinson]

Mark Dickinson  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 (or 
x86_64 in 32-bit mode), and one for x86_64 in 64-bit mode.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Mark Dickinson]

Mark Dickinson  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 "rdx or rax" for a 64-bit quantity.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6603] Compilation error if configuref --with-computed-gotos

[Martin v . Löwis]

Martin v. Löwis  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 
EAX. The exact place where this gets used has varied recently quite a 
lot; it currently lives in predicates.md:

http://gcc.gnu.org/viewcvs/trunk/gcc/config/i386/constraints.md?
revision=149373&view=markup

where "A" becomes the letter denoting the AD_REGS constraint. So IIUC, 
this means that EDX is the output of the insn, and your change should 
have no effect. I suggest talking to gcc people what the problem might 
be.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7118] urllib2.urlopen() timeout argument ignored after redirect

[Senthil Kumaran]

Senthil Kumaran  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: +orsenthil

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Tarek Ziadé]

Changes by Tarek Ziadé :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError

[Tarek Ziadé]

Tarek Ziadé  added the comment:

The new issue is : #7115

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5915] PEP 383 implementation

[Martin v . Löwis]

Martin v. Löwis  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 do use it most likely will have 
to support 2.6 and earlier, as well, so they aren't helped with the 
handler. My advise to such libraries is that they should include and 
register their own implementation of it, or else fall back to "strict" 
on 2.x (say).

In any case: this issue is closed by PEP 383 being implemented. If you 
still desire a backport, please create a new report.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7101] tarfile: OSError with TarFile.add(..., recursive=True) about non-existing file

[Lars Gustäbel]

Changes by Lars Gustäbel :


--
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6963] Add worker process lifetime to multiprocessing.Pool - patch included

[Jesse Noller]

Jesse Noller  added the comment:

Well, it's in feb, but I'm involved in some intense planning right now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7118] urllib2.urlopen() timeout argument ignored after redirect

[Gerald Thaler]

New submission from Gerald Thaler :

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: urllib2.urlopen() timeout argument ignored after redirect
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6963] Add worker process lifetime to multiprocessing.Pool - patch included

[Charles Cazabon]

Charles Cazabon  added the comment:

Okay, thanks, Jesse.  Didn't realize the Con was on.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6963] Add worker process lifetime to multiprocessing.Pool - patch included

[Jesse Noller]

Jesse Noller  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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7111] core dump when stderr is moved

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

After some searching around with Google, "2>&-" means "close file
descriptor 2" (i.e., standard error).

--
nosy: +stutzbach

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7117] Backport py3k float repr to trunk

[Mark Dickinson]

New submission from Mark Dickinson :

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,
though.  Something like the following?

(1) Check in David Gay's code plus necessary build changes,
configuration steps, etc;  conversions still use the old code.

(2) Switch to using the new code for float -> string (str, repr, float
formatting) and string -> float conversions (float, complex
constructors, numeric literals in Python code).  [Substeps?]

(3) Fix up builtin round function to use the new code.

(4) Make any necessary fixes to the documentation.  (Raymond, I assume
you'll take care of the whatsnew changes when the time comes?)

(1), (3) and (4) should be straightforward.  (2) is where most of the
work is, I think.  I think it should be possible to do the stage (2)
work in pieces without breaking too much.

--
assignee: mark.dickinson
components: Interpreter Core
messages: 93918
nosy: eric.smith, mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Backport py3k float repr to trunk
type: feature request
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com