[issue1580] Use shorter float repr when possible

[Mark Dickinson]

Mark Dickinson  added the comment:

[Raymond]
> Is there a way to use SSE when available and x86 when it's not.

I guess it's possible in theory, but I don't know of any way to do this in 
practice.  I suppose one could trap the SIGILL generated by the attempted 
use of an SSE2 instruction on a non-supported platform---is this how 
things used to work for 386s without the 387?  That would make a sequence 
of floating-point instructions on non-SSE2 x86 horribly slow, though.

Antoine: as Raymond said, the advantage of SSE2 for numeric work is 
accuracy, predictability, and consistency across platforms.  The SSE2 
instructions finally put an end to all the problems arising from the 
mismatch between the precision of the x87 floating-point registers (64-
bits) and the precision of a C double (53-bits).  Those difficulties 
include (1) unpredictable rounding of intermediate values from 64-bit 
precision to 53-bit precision, due to spilling of temporaries from FPU 
registers to memory, and (2) double-rounding.  The arithmetic of Python 
itself is largely immune to the former, but not the latter.  (And of 
course the register spilling still causes headaches for various bits of 
CPython).

Those difficulties can be *mostly* dealt with by setting the x87 rounding 
precision to double (instead of extended), though this doesn't fix the 
exponent range, so one still ends up with double-rounding on underflow.  
The catch is that one can't mess with the x87 state globally, as various 
library functions (especially libm functions) might depend on it being in 
whatever the OS considers to be the default state.

There's a very nice paper by David Monniaux that covers all this:  
definitely recommended reading after you've finished Goldberg's "What 
Every Computer Scientist...".  It can currently be found at:

http://hal.archives-ouvertes.fr/hal-00128124/en/

An example: in Python (any version), try this:

>>> 1e16 + 2.
10002.0

On OS X, Windows and FreeBSD you'll get the answer above.
(OS X gcc uses SSE2 by default; Windows and FreeBSD both
make the default x87 rounding-precision 53 bits).

On 32-bit Linux/x86 or Solaris/x86 you'll likely get the answer

10004.0

instead, because Linux doesn't (usually?) change the Intel default
rounding precision of 64-bits.  Using SSE2 instead of the x87 would have 
fixed this.



--

___
Python tracker 

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

[issue5786] len(reversed([1,2,3])) does not work anymore in 2.6.2

[Christof]

Christof  added the comment:

A compatibility break in a minor bugfix version is never a good idea I
guess. I understand the reasoning but this change may break quite a few
packages (at least it broke mine). A workaround in programs is easy but
for already released and deployed versions simply not possible. A change
for Python 2.7 would be at least annoying too but I guess could be
justified. Just my thoughts...

--

___
Python tracker 

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

[issue918368] urllib doesn't correct server returned urls

[Senthil]

Senthil  added the comment:

The attached patch fixes this issue and adds the test too. Followed John
J Lee's suggestion for the patch.Can someone review this?

For the other referenced issue1153027, bug is not reproducible in the
trunk and I see that fix has been made in revision 43132. It follows the
approach of percent encoding space at redirect_request. I shall verify
if we need to change that to a different fix or present one would be
sufficient.

--
assignee:  -> orsenthil
keywords: +patch
Added file: http://bugs.python.org/file13720/issue918368-py27.diff

___
Python tracker 

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

[issue5657] bad repr of itertools.count object with negative value on OS X 10.4 with 10.5 build

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Fixed in r71743 (trunk), r71744 (2.6), r71746 (3.0), r71745 (3.1)

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue1602133] non-framework built python fails to define environ properly

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I can reproduce this with a unix build of python2.5:

* Install a unix build of python 2.5 (--with-pydebug) as 
  /opt/python2.5-dbg

* Install pyobjc 2.2-dev (from PyObjC's subversion repository)

* Build the addressbook plugin example in pyobjc-framework-AddressBook

* Install said plugin and open the AddressBook application

* The plugin won't load, and the console will mention that _environ 
  cannot be found.

I haven't tested this with python 2.6 or later yet, 2.5 happens to be 
the version of Python I test PyObjC with.

--
resolution: works for me -> accepted
status: pending -> open

___
Python tracker 

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

[issue5791] title information of unicodedata is wrong in some cases

[Carl Friedrich Bolz]

New submission from Carl Friedrich Bolz :

There seems to be a problem with some unicode character's title information:

$ python2.6
Python 2.6.2c1 (release26-maint, Apr 14 2009, 08:02:48)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> unichr(453)
u'\u01c5'
>>> unichr(453).title()
u'\u01c4'

But the title should return the same character, according to this:

http://www.fileformat.info/info/unicode/char/01c5/index.htm

(I also checked the files that unicode.org provides). I tried to follow
the problem a bit, it seems to come from _PyUnicode_ToTitlecase in
unicodetype.c. The unicode record contains the offset of the character
to its titled version. If the character is its own titled version, then
the offset is zero. But zero is also used for when there is no
information available, so the offset to the upper-case version of the
character is used. If this is a different character (as for the example
above), the result of .title() is wrong.

--
components: Interpreter Core
messages: 86163
nosy: cfbolz
severity: normal
status: open
title: title information of unicodedata is wrong in some cases
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

___
Python tracker 

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

[issue5791] title information of unicodedata is wrong in some cases

[Martin v. Löwis]

Martin v. Löwis  added the comment:

This is a duplicate of issue4971

--
nosy: +loewis
resolution:  -> duplicate
status: open -> closed
superseder:  -> Incorrect title case

___
Python tracker 

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

[issue5413] urllib ctypes error on Mac OS X Server 10.5

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The attached patch is not entirely correct, I'm not yet uploading an 
updated patch because the fix is obvious.

I cannot reproduce this with a the 2.6.2 installer (build on PPC) nor 
with a recent build from subversion (python-trunk, build on X86). My 
tests were done on a PPC G4 iMac running the following version of OSX:

ProductName:Mac OS X
ProductVersion: 10.4.11
BuildVersion:   8S165

Xcode is:

$ xcodebuild -version
Component versions: DevToolsCore-660.0; DevToolsSupport-651.0

I'm currently installing 10.5 server in a VM, and will try to test that 
as well (using Rosetta). I don't have access to a PPC machine running 
10.5 server, the 10.4 system I mention above cannot be easily 
reinstalled.

BTW. I intend to commit the fixed version of my patch regardless of 
whether this fixes the issue because it is slightly more correct to 
fetch CoreFoundation symbols directly from the CoreFoundation framework 
instead of relying on SystemConfiguration's "connection" to that 
framework.

--

___
Python tracker 

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

[issue5786] len(reversed([1,2,3])) does not work anymore in 2.6.2

[Mark Dickinson]

Mark Dickinson  added the comment:

Is there a 2.6 release imminent?  I thought I saw some discussion of a 
2.6.3 release, but I'm not sure what the eventual decision was. If so, 
perhaps this change could be quickly reverted in the release26-maint 
branch?

--
nosy: +marketdickinson

___
Python tracker 

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

[issue5788] datetime.timedelta is inconvenient to use...

[Brian Quinlan]

Changes by Brian Quinlan :


Added file: http://bugs.python.org/file13721/totalseconds2.diff

___
Python tracker 

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

[issue5788] datetime.timedelta is inconvenient to use...

[Brian Quinlan]

Brian Quinlan  added the comment:

Attached is a patch that implements .total_seconds as an instance method

--

___
Python tracker 

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

[issue5792] Enable short float repr() on Solaris/x86

[Mark Dickinson]

New submission from Mark Dickinson :

The short float repr() that's in 3.1 (probably) doesn't work on 
Solaris/x86 when using Sun's compiler to build.  It would be nice to
fix this.

It probably works on Solaris/x86/gcc, though confirmation of that would be 
appreciated.

Marking as easy, because this should be an easy task for someone who has 
access to the appropriate setup.  I can probably do all the 
autoconf/define stuff required, but I need help from someone who has 
access to Solaris/x86 and who can be available to do testing.

--
components: Interpreter Core
keywords: easy
messages: 86168
nosy: marketdickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable short float repr() on Solaris/x86
type: feature request
versions: Python 3.1

___
Python tracker 

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

[issue5792] Enable short float repr() on Solaris/x86

[Mark Dickinson]

Mark Dickinson  added the comment:

See the comments in the Include/pyport.h file for an explanation of
what's required. (Search for HAVE_PY_SET_53BIT_PRECISION.)

--

___
Python tracker 

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

[issue5793] Rationalize isdigit / isalpha / tolower / ... uses throughout Python source

[Mark Dickinson]

New submission from Mark Dickinson :

Problem: the standard C character handling functions from ctype.h 
(isalpha, isdigit, isxdigit, isspace, toupper, tolower, etc.) are locale 
aware, but for almost all uses CPython needs locale-unaware versions of 
these.

There are various solutions in the current source:

- there's a file Include/bytes_methods.h which provides suitable 
ISDIGIT/ISALPHA/... macros, but also undefines the standard functions.
As it is, it can't be included in Python.h since that would break
3rd party code that includes Python.h and also uses isdigit.

- some files have their own solution:  Python/pystrtod.c defines
its own (probably inefficient) ISDIGIT and ISSPACE macros.

- in some places the standard C functions are just used directly (and 
possibly incorrectly).  A gotcha here is that one has to remember to use 
Py_CHARMASK to avoid errors on some platforms.  (See issue 3633 for an 
example.)

It would be nice to clean all this up, and have one central, efficient, 
easy-to-use set of Py_ISDIGIT/Py_ISALPHA ... locale-independent macros (or 
functions) that could be used safely throughout the Python source.

--
components: Interpreter Core
keywords: easy
messages: 86170
nosy: eric.smith, marketdickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Rationalize isdigit / isalpha / tolower / ... uses throughout Python 
source
type: feature request
versions: Python 2.7, Python 3.1

___
Python tracker 

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

[issue5785] Condition.wait() does not respect its timeout

[Stéphane]

Stéphane  added the comment:

Ok I fixed the issue thanks to the help from Piet van Oostrum: I didn't 
call gobject.threads_init(), so that gave the unexpected behaviour. It 
is certainly bad documentation on the gobject side, but you may 
consider adding some kind of warning on the threading documentation 
page, since I guess gobject is quite commonly used.

--

___
Python tracker 

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

[issue5786] len(reversed([1,2,3])) does not work anymore in 2.6.2

[Daniel Diniz]

Daniel Diniz  added the comment:

Setting as a release blocker so Barry can consider this for 2.6.3
(-committers seems to suggest that it'll be released soon).

--
nosy: +ajaksu2
priority:  -> release blocker
stage:  -> commit review
type:  -> behavior

___
Python tracker 

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

[issue5793] Rationalize isdigit / isalpha / tolower / ... uses throughout Python source

[Eric Smith]

Eric Smith  added the comment:

I concur. I've also been bitten by forgetting Py_CHARMASK, so a single
version that took this into account (and was locale-unaware) would be
welcome.

In private mail I'd mentioned that if these are functions, they should
take int. But I now think that's incorrect, and they should take char or
unsigned char. I think the standard C functions take int because they
also allow EOF. I think the Py_ versions should allow only characters
and not allow EOF. Py_CHARMASK already enforces this, anyway, with
likely undefined results.

--

___
Python tracker 

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

[issue5463] Remove deprecated features from struct module

[Mark Dickinson]

Mark Dickinson  added the comment:

Hmm.  In 3.0 and 2.7, I get:

>>> from struct import pack
>>> pack('L', 123.0)
sys:1: DeprecationWarning: integer argument expected, got float
b'{\x00\x00\x00'

So it looks like we already changed py3k to get rid of the 
DeprecationWarning.

I think the idea was that eventually *only* integers would be accepted 
for the integer format codes.  So pack('L', 123.0) should ideally raise 
TypeError.  If we're not going to do that, we should at least put the 
DeprecationWarning back in, but it seems better to actually go ahead 
with the deprecation.

--

___
Python tracker 

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

[issue1530559] struct.pack raises TypeError where it used to convert

[Mark Dickinson]

Mark Dickinson  added the comment:

Stealing this from Bob.  Bob, please steal it back it you want it!

--

___
Python tracker 

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

[issue1530559] struct.pack raises TypeError where it used to convert

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee: bob.ippolito -> marketdickinson

___
Python tracker 

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

[issue5463] Remove deprecated features from struct module

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's an updated version of your patch:  all I've done is fix up
get_(u)long, get_(u)longlong and get_pylong so that they only accept 
integers.

--
Added file: http://bugs.python.org/file13722/cleanup_float_coerce_patch_v2.diff

___
Python tracker 

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

[issue5756] idle pydoc et al removed from 3.1 without versioned replacements

[Kurt B. Kaiser]

Changes by Kurt B. Kaiser :


--
nosy: +kbk

___
Python tracker 

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

[issue5794] pickle/cPickle of recursive tuples create pickles that cPickle can't load

[Carl Witty]

New submission from Carl Witty :

When I try to pickle a recursive tuple (that recurses through a list),
pickle can load the result but cPickle fails with "unpickling stack
overflow".

(I just downloaded and built Python 2.6.2 on 64-bit x86 Debian testing
to verify this bug; it also fails on Python 2.5.2 on 32-bit x86 Debian
testing.  I think that probably it doesn't depend on the architecture or
operating system at all.)

Here is the test case.  At the end, cPickle.loads raises an exception;
instead, it should produce an object equivalent to v, like pickle.loads
does.  (I didn't show it in the test case, but pickles produced by
pickle.dumps have the same behavior -- they work with pickle.loads but
not cPickle.loads.)

>>> v = ([],)
>>> v[0].append(v)
>>> import pickle
>>> import cPickle
>>> v
([([...],)],)
>>> vp = cPickle.dumps(v)
>>> pickle.loads(vp)
([([...],)],)
>>> cPickle.loads(vp)
Traceback (most recent call last):
  File "", line 1, in 
cPickle.UnpicklingError: unpickling stack underflow

--
components: Library (Lib)
messages: 86177
nosy: cwitty
severity: normal
status: open
title: pickle/cPickle of recursive tuples create pickles that cPickle can't load
type: behavior
versions: 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

[issue5463] Remove deprecated features from struct module

[Mark Dickinson]

Mark Dickinson  added the comment:

Committed part 3 in r71755.  Thank you!

Is there anything else you think we need to fix up here?

--
resolution:  -> accepted
stage: test needed -> committed/rejected
status: open -> pending

___
Python tracker 

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

[issue5463] Remove deprecated features from struct module

[Mark Dickinson]

Mark Dickinson  added the comment:

That should be r71754, of course.

--
status: pending -> open

___
Python tracker 

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

[issue5463] Remove deprecated features from struct module

[Mark Dickinson]

Changes by Mark Dickinson :


--
status: open -> pending

___
Python tracker 

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

[issue1530559] struct.pack raises TypeError where it used to convert

[Mark Dickinson]

Mark Dickinson  added the comment:

The deprecated struct features (float coercion, overflow wrapping) have 
been removed for py3k in r70497, r70688, r71754.  I don't plan to backport 
this to 2.7; I'll just try to fix the behaviour in a minimal way there.

One thing that's not clear to me:  what's the rationale for raising 
struct.error everywhere instead of more specific Python errors; e.g., 
TypeError for struct.pack('L', 'not an integer') and OverflowError for 
struct.pack('L', 10**100)?  Is there a particular use-case for "except 
struct.error"?

--
priority: critical -> normal

___
Python tracker 

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

[issue1741130] struct.pack("I", "foo"); struct.pack("L", "foo") should fail

[Mark Dickinson]

Mark Dickinson  added the comment:

It looks as though this was sort-of fixed sometime between 2.6.1 and 
2.6.2.  In 2.6.2, I get the following (and results from trunk and 3.0.1 
are similar):

Python 2.6.2+ (release26-maint:71755, Apr 19 2009, 22:06:02) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack('L', 'not an integer')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for &: 'str' and 'long'

That error message suggests that there's something nasty happening 
somewhere, though.  It looks as though we're getting the right type of 
exception, but for the wrong reasons.

--

___
Python tracker 

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

[issue1530559] struct.pack raises TypeError where it used to convert

[Bob Ippolito]

Bob Ippolito  added the comment:

I believe that struct.error is just how it worked before 2.5

--

___
Python tracker 

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

[issue5795] test_distutils failure on the ppc Debian buildbot

[Antoine Pitrou]

New submission from Antoine Pitrou :

The following test fails on the ppc Debian buildbot (trunk and py3k):

test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ...
gcc-4.3: x86_64: No such file or directory
cc1: error: unrecognized command line option "-arch"
ERROR

==
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
--
Traceback (most recent call last):
  File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/tests/test_build_ext.py",
line 64, in test_build_ext
cmd.run()
  File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/command/build_ext.py",
line 353, in run
self.build_extensions()
  File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/command/build_ext.py",
line 480, in build_extensions
self.build_extension(ext)
  File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/command/build_ext.py",
line 550, in build_extension
depends=ext.depends)
  File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/ccompiler.py",
line 695, in compile
self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
  File
"/home/pybot/buildarea/trunk.klose-debian-ppc/build/Lib/distutils/unixccompiler.py",
line 180, in _compile
raise CompileError, msg
CompileError: command 'gcc' failed with exit status 1

Here are links to the log files:
http://www.python.org/dev/buildbot/trunk.stable/ppc%20Debian%20unstable%20trunk/builds/388/step-test/0
http://www.python.org/dev/buildbot/3.x.stable/ppc%20Debian%20unstable%203.x/builds/654/step-test/0

--
assignee: tarek
components: Distutils
messages: 86183
nosy: pitrou, tarek
priority: normal
severity: normal
status: open
title: test_distutils failure on the ppc Debian buildbot
type: behavior
versions: Python 2.7, Python 3.1

___
Python tracker 

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

[issue5795] test_distutils failure on the ppc Debian buildbot

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Two strange things:
- "-arch" doesn't exist, it should be "-march="
- why is there a reference to x86_64 on a ppc buildbot?

--
nosy: +doko

___
Python tracker 

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

[issue5795] test_distutils failure on the ppc Debian buildbot

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, I assume "-arch x86_64" is a MacOS X-specific gcc flag.
The problem could be with distutils.tests.test_util:test_get_platform
which borks the environment variable CFLAGS by adding this flag.

--

___
Python tracker 

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

[issue5796] test_posix, test_pty crash under Windows

[Antoine Pitrou]

New submission from Antoine Pitrou :

This seems related to the import behaviour changes in regrtest.

Re-running test 'test_posix' in verbose mode
test test_posix crashed -- : No module
named pwd
Traceback (most recent call last):
  File "../lib/test/regrtest.py", line 569, in runtest_inner
the_package = __import__(abstest, globals(), locals(), [])
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_posix.py",
line 8, in 
import pwd
ImportError: No module named pwd
Re-running test 'test_pty' in verbose mode
test test_pty crashed -- : No module
named fcntl
Traceback (most recent call last):
  File "../lib/test/regrtest.py", line 569, in runtest_inner
the_package = __import__(abstest, globals(), locals(), [])
  File
"E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_pty.py",
line 2, in 
import fcntl
ImportError: No module named fcntl

http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%20trunk/builds/2056/step-test/0

--
assignee: r.david.murray
components: Tests, Windows
messages: 86186
nosy: pitrou, r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: test_posix, test_pty crash under Windows
type: crash
versions: Python 2.7, Python 3.1

___
Python tracker 

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

[issue5785] Condition.wait() does not respect its timeout

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I don't think we need warnings about third party libraries in our docs.

--
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue5670] Speed up pickling of dicts in cPickle

[Kelvin Liang]

Kelvin Liang  added the comment:

Can this patch be used or ported to 2.5.x?

--
nosy: +feisan

___
Python tracker 

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

[issue5797] there is en exception om Create User page

[nabeel]

New submission from nabeel :

there is en exception om Create User page

--
messages: 86189
nosy: nabeel
severity: normal
status: open
title: there is en exception om Create User page
type: crash
versions: Python 3.1

___
Python tracker 

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