[issue920573] http libraries throw errors internally in BitTorrent

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'll take another look at it the week.

--
assignee:  -> rhettinger
status: pending -> open

___
Python tracker 

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

[issue6019] Minor typos in ctypes docs

[Georg Brandl]

Georg Brandl  added the comment:

Fixed in r72661.

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

[issue6028] Interpreter crashes when chaining an infinite number of exceptions

[Yury]

New submission from Yury :

def error_handle():
try:
print(5/0)
except:
error_handle()

error_handle()

Fatal Python error: Cannot recover from stack overflow.
Aborted

The interpreter should not crash. Perhaps a RuntimeError should be
thrown instead.

--
components: Interpreter Core
messages: 87797
nosy: yury
severity: normal
status: open
title: Interpreter crashes when chaining an infinite number of exceptions
type: crash
versions: Python 3.0

___
Python tracker 

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

[issue6029] FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) [SPARC/64-bit]

[Peter Bray]

New submission from Peter Bray :

Greetings,

  I have downloaded and compiled Python 3.1b1 on Solaris 10 Update 6
with GCC 4.1.2 on {SPARC,x86} x {32-bit,64-bit} and encountered only one
test harness failure, which was on SPARC 64-bit.

  Included below are the initial details, is there something more I can
do to assist, if so, please be specific.

Regards,
Peter


./python Lib/test/regrtest.py -v test_ctypes

==
FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
self.check_type(c_longdouble, 3.14)
  File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: First differing element 1:
0.0
3.14
- (-3, 0.0)
+ (-3, 3.14)

--
Ran 328 tests in 3.853s

FAILED (failures=1)
test test_ctypes failed -- Traceback (most recent call last):
  File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
self.check_type(c_longdouble, 3.14)
  File "/tmp/64-bit/Python-3.1b1/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: First differing element 1:
0.0
3.14
- (-3, 0.0)
+ (-3, 3.14)

1 test failed:
test_ctypes

The test code (from Python-3.1b1/Lib/ctypes/test/test_callbacks.py)

79  
80  def test_longdouble(self):
81  self.check_type(c_longdouble, 3.14)
82  self.check_type(c_longdouble, -3.14)
83  

and ealier in the same file

11  
12  def callback(self, *args):
13  self.got_args = args
14  return args[-1]
15  
16  def check_type(self, typ, arg):
17  PROTO = self.functype.__func__(typ, typ)
18  result = PROTO(self.callback)(arg)
19  if typ == c_float:
20  self.failUnlessAlmostEqual(result, arg, places=5)
21  else:
22  self.failUnlessEqual(self.got_args, (arg,))
23  self.failUnlessEqual(result, arg)
24  
25  PROTO = self.functype.__func__(typ, c_byte, typ)
26  result = PROTO(self.callback)(-3, arg)
27  if typ == c_float:
28  self.failUnlessAlmostEqual(result, arg, places=5)
29  else:
30  self.failUnlessEqual(self.got_args, (-3, arg))
31  self.failUnlessEqual(result, arg)
32  
 


[softw...@specula] 64-bit SPARC % gcc -v
Using built-in specs.
Target: sparc64-sun-solaris2.10
Configured with: ../configure --prefix=/pkgs/64-bit/release/gcc-4.1.2
--with-local-prefix=/pkgs/64-bit --disable-nls --disable-multilib
--enable-shared --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-gmp=/pkgs/64-bit
--with-mpfr=/pkgs/64-bit --enable-languages=c,c++,objc,obj-c++,fortran
sparc64-sun-solaris2.10
Thread model: posix
gcc version 4.1.2

[softw...@specula] 64-bit SPARC % cat /etc/release 
  Solaris 10 10/08 s10s_u6wos_07b SPARC
   Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.
Use is subject to license terms.
Assembled 27 October 2008

Build Procedure
---

Python 3.1b1

## Note PKGS_PREFIX=/pkgs/64-bit and PKGS_RELEASE=/pkgs/64-bit/release

gtar fxv /Python-3.1b1.tar.bz2
cd Python-3.1b1

# The CPPFLAGS & LDFLAGS are used by setup.py in external modules builds
CPPFLAGS="-I${PKGS_PREFIX}/include" LDFLAGS="-L${PKGS_PREFIX}/lib"
./configure --prefix=${PKGS_RELEASE}/Python-3.1b1
--datarootdir=${PKGS_RELEASE}/Python-3.1b1 --with-universal-archs=64-bit 

echo "crypt cryptmodule.c" >> Modules/Setup.local  ## Solaris does not
need -lcrypt

gmake
gmake test

--
assignee: theller
components: Tests, ctypes
messages: 87798
nosy: illumino, theller
severity: normal
status: open
title: FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) 
[SPARC/64-bit]
type: behavior
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

[issue1182143] making builtin exceptions more informative

[R. David Murray]

R. David Murray  added the comment:

See also issue 5353.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue5353] Improve IndexError messages with actual values

[R. David Murray]

R. David Murray  added the comment:

See also issue 1182143.

--

___
Python tracker 

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

[issue1152248] Enhance file.readlines by making line separator selectable

[R. David Murray]

R. David Murray  added the comment:

> cat temp
this is$#a weird$#file$#
> ./python
Python 3.1b1+ (py3k:72632:72633M, May 15 2009, 05:11:27)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('temp', newline='$#')
[50354 refs]
>>> f.readlines()
['this is$#', 'a weird$#', 'file$#', '\n']

All I did was comment out the 'newline' argument validity check in textio.c.

--
keywords: +easy
nosy: +r.david.murray

___
Python tracker 

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Nick Coghlan]

Nick Coghlan  added the comment:

While RDM's quick test is encouraging, I think one of the key things is
going to be developing tests for the various cases:

- binary mode, single byte line ending
- binary mode, multi-byte line ending
- text mode, single byte single char line ending*
- text mode, multi-byte single char line ending
- text mode, multiple char line ending

The text mode tests would need to cover a variety of encodings (e.g.
ASCII, latin-1, UTF-8, UTF-16, UTF-32 and maybe something like koi8-r
and/or some of the CJK codecs).

*if applicable to codec under test

--

___
Python tracker 

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Antoine Pitrou]

Antoine Pitrou  added the comment:

-1 on this idea. readlines() exists precisely because line endings are
special when it comes to text IO (because of the various platform
differences).

If you want to split on any character, you can just use read() followed
by split(). No need to graft additional complexity on the file IO classes.

--

___
Python tracker 

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

[issue6028] Interpreter crashes when chaining an infinite number of exceptions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This is normal behaviour, actually. The RuntimeError *is* raised, but
you catch it in the except clause and then recurse again ad infinitum.
The interpreter realizes that it "cannot recover from stack overflow",
as the message says, and then bails out.

--
nosy: +pitrou
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

[issue1152248] Enhance file.readlines by making line separator selectable

[Antoine Pitrou]

Antoine Pitrou  added the comment:

And it's certainly not easy to do correctly :)

--

___
Python tracker 

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Uh, trying again to remove the keyword :-(

--
keywords:  -easy

___
Python tracker 

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, let me qualify my position a bit:
- -1 for abusing the newline parameter
- -1 for abusing readlines()
- +0 on an additional method ("readchunks" was suggested) which does the
splitting, either on a single character or on a string

Please bear in mind the latter should involve, for each of the C and
Python implementations:
- a generic unoptimized version for BufferedIOBase
- a generic unoptimized version for TextIOBase
- an optimized version for BufferedReader/BufferedRandom
- an optimized version for TextIOWrapper

However, it is certainly an interesting task for someone wanting to play
with C code, optimizations, etc.

--

___
Python tracker 

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Nick Coghlan]

Nick Coghlan  added the comment:

I agree with Antoine - given that the newlines parameter now deals with
Skip's alternate line separator use case, a new method "readrecords"
that takes a mandatory record separator makes more sense than using
readlines to read things that are not lines. (of course, taking the
alternate line ending use case away also reduces the total number of use
cases for the new method).

Note that the problem with the read()+split() approach is that you
either have to read the whole file into memory (which this RFE is trying
to avoid) or you have to do your own buffering and so forth to split
records as you go. Since the latter is both difficult to get right and
very similar to what the IO module already has to do for readlines(), it
makes sense to include the extra complexity there.

--

___
Python tracker 

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Nick Coghlan]

Nick Coghlan  added the comment:

I agree with Antoine - given that the newlines parameter now deals with
Skip's alternate line separator use case, a new method "readrecords"
that takes a mandatory record separator makes more sense than using
readlines to read things that are not lines. (of course, taking the
alternate line ending use case away also reduces the total number of use
cases for the new method).

Note that the problem with the read()+split() approach is that you
either have to read the whole file into memory (which this RFE is trying
to avoid) or you have to do your own buffering and so forth to split
records as you go. Since the latter is both difficult to get right and
very similar to what the IO module already has to do for readlines(), it
makes sense to include the extra complexity there.

--

___
Python tracker 

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Nick Coghlan]

Changes by Nick Coghlan :


--

___
Python tracker 

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

[issue1655] imaplib is not IPv6-capable

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r72662, thanks!

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

[issue1309352] Make fcntl work properly on AMD64

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I confirm this on trunk, using Brad's test script.

--
nosy: +pitrou
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

[issue1309352] Make fcntl work properly on AMD64

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is an updated patch with a test.

--
Added file: http://bugs.python.org/file13988/fcntl.patch3.txt

___
Python tracker 

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

[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails

[Hans L]

Changes by Hans L :


--
nosy: +hozn

___
Python tracker 

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

[issue1309352] Make fcntl work properly on AMD64

[Antoine Pitrou]

Antoine Pitrou  added the comment:

As for the calling convention concern, it seems to me that a sane ABI
wouldn't make a difference between ints and longs - both should fit in a
standard machine word.

--
stage: test needed -> patch review

___
Python tracker 

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

[issue5964] WeakSet cmp methods

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Why are you confused? You already asked that question earlier in the thread.

--

___
Python tracker 

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

[issue1706039] Added clearerr() to clear EOF state

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Does it apply to 3.1?

--

___
Python tracker 

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

[issue1200] Allow array.array to be parsed by the t# format unit.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm not sure what t# is for. Jeffrey, have you tried using y* instead?
(you must call PyBuffer_Release at the end)

--

___
Python tracker 

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Note that the problem with the read()+split() approach is that you
> either have to read the whole file into memory (which this RFE is trying
> to avoid) or you have to do your own buffering and so forth to split
> records as you go. Since the latter is both difficult to get right and
> very similar to what the IO module already has to do for readlines(), it
> makes sense to include the extra complexity there.

I wonder how often this use case happens though. Usually you first split
on lines, and only then you split on another character or string (think
CSV files, HTTP headers, etc.).

When you don't split on lines, conversely, you probably have a binary
format, and binary formats have more efficient ways of chunking (for
example, a couple of bytes at the beginning indicating the length of the
chunk).

--

___
Python tracker 

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

[issue5353] Improve IndexError messages with actual values

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue1182143] making builtin exceptions more informative

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

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

[issue5625] test_urllib2 fails - urlopen error file not on local host

[Derek Morr]

Changes by Derek Morr :


--
nosy: +dmorr

___
Python tracker 

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

[issue5964] WeakSet cmp methods

[Robert Schuppenies]

Robert Schuppenies  added the comment:

Maybe because I take the doc too specfic. It says "A rich comparison
method may return the singleton NotImplemented if it does not implement
the operation for a given pair of arguments."

I see the type check of the 'other' object as an operation towards the
equal comparison, since it validates wether 'self' and 'other' can be
equal at all. If they are of a different type, then they cannot be
equal, thus the anwser to "Are 'self' and 'other' equal?" should be
False. This again, would mean an equal operation is implemented and
returning NotImplemented is not the right anwser.

But going through similar code snippets shows otherwise, so my
understanding must be lacking something. Therefore here is patch which
returns NotImplemented.

--
Added file: http://bugs.python.org/file13989/_weakrefset-notimplemented.patch

___
Python tracker 

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

[issue5964] WeakSet cmp methods

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I see the type check of the 'other' object as an operation towards the
> equal comparison, since it validates wether 'self' and 'other' can be
> equal at all. If they are of a different type, then they cannot be
> equal, thus the anwser to "Are 'self' and 'other' equal?" should be
> False. This again, would mean an equal operation is implemented and
> returning NotImplemented is not the right anwser.

The explanation for NotImplemented is that an user-defined class may
decide it can compare equal to a WeakSet (without inheriting from
WeakSet). Returning NotImplemented from WeakSet.__eq__ gives a chance to
the user-defined class' __eq__ method to be called.

--

___
Python tracker 

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

[issue1200] Allow array.array to be parsed by the t# format unit.

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

I actually have no idea what I was trying to do when I ran into this. I
think it was a use somewhere in the standard libraries rather than my
own code, so if uses of t# are gone from there, I'd have no objections
to closing this bug.

--

___
Python tracker 

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

[issue5964] WeakSet cmp methods

[Antoine Pitrou]

Antoine Pitrou  added the comment:

You can commit the latest patch, provided all tests pass.

--
assignee:  -> schuppenies
resolution:  -> accepted
stage: patch review -> commit review

___
Python tracker 

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

[issue2116] weakref copy module interaction

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r72662, r72670. Thanks!

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

[issue1152248] Enhance file.readlines by making line separator selectable

[Douglas Alan]

Douglas Alan  added the comment:

Antoine Pitrou  wrote:

> Nick Coghlan  added the comment:

> > Note that the problem with the read()+split() approach is that you
> > either have to read the whole file into memory (which this RFE is 
trying
> > to avoid) or you have to do your own buffering and so forth to split
> > records as you go. Since the latter is both difficult to get right 
and
> > very similar to what the IO module already has to do for 
readlines(), it
> > makes sense to include the extra complexity there.

> I wonder how often this use case happens though.

Every day for me.  The reason that I originally brought up this request
some years back on comp.lang.python was that I wanted to be able to use
Python easily like I use the xargs program.

E.g.,

   find -type f -regex 'myFancyRegex' -print0 | stuff-to-do-on-each-
file.py

With "-print0" the line separator is chaged to null, so that you can
deal with filenames that have newlines in them.

("find" and "xargs" traditionally have used newline to separate files,
but that fails in the face of filenames that have newlines in them, so
the -print0 argument to find and the "-0" argument to xargs were
thankfully eventually added as a fix for this issue.  Nulls are not
allowed in filenames.  At least not on Unix.)

> When you don't split on lines, conversely, you probably have a binary
> format,

That's not true for the daily use case I just mentioned.

|>ouglas

P.S. I wrote my own version of readlines, of course, as the archives of
comp.lang.python will show.  I just don't feel that everyone should be
required to do the same, when this is the sort of thing that sysadmins
and other Unix-savy folks are wont to do on a daily basis.

P.P.S. Another use case is that I often end up with files that have
beeen transferred back and forth between Unix and Windows and
god-knows-what-else, and the newlines end up being some weird mixture of
carriage returns and line feeds (and sometimes some other stray
characters such as "=20" or somesuch) that many programs seem to have a
hard time recognizing as newlines.

--

___
Python tracker 

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

[issue6028] Interpreter crashes when chaining an infinite number of exceptions

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Hmm, the interpreter should not crash so easily with pyre Python code.
(The same code correctly raises RuntimeException wich python 2.x)
The issue should be corrected IMO.

The exact behavior seem to depend on where the recursion limit is detected:

- If it is detected at the beginning of the function (at the start of
PyEval_EvalFrameEx) or before the "try" statement, the exception is
correctly propagated and displayed. This case always happens with 2.x,
and you get the same on 3.0 if you add for example str()
at the beginning of the function.

- The crash occurs when the recursion limit is detected while
PyEval_EvalFrameEx calls PyErr_NormalizeException() (in the "why ==
WHY_EXCEPTION" block). This does not change the control flow: the
original exception is simply replaced by the RuntimeError, and nested
calls continue 50 more frames.

Here is a tentative patch.

--
keywords: +patch
nosy: +amaury.forgeotdarc
resolution: invalid -> 
status: closed -> open
Added file: http://bugs.python.org/file13990/stackoverflow.patch

___
Python tracker 

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

[issue5998] Add __bool__ to threading.Event and multiprocessing.Event

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I'm closing because a lack of positive feedback on the list.

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

___
Python tracker 

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

[issue5353] Improve IndexError messages with actual values

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This issue is about formatting a value into an error message.
#1182143 is about adding values that have already been formatted into an
error message to the resulting exception object.  If this suggestion
were implemented, then IndexError would be added to the exceptions
covered by #1182143

Patches to mailing lists tend to get lost.  Thank you for finding
Bjourne's. I have invited him (at the email then given) to update it and
attach it here.

--

___
Python tracker 

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

[issue5353] Improve IndexError messages with actual values

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I've seen his patch and am working on my own variant that also attaches
the index value as a separate field in the args tuple.  The problem may
be that it slows down the code -- at first I thought that didn't matter,
but someone made a good effort to make the existing code fast (possibly
to support cases where IndexError is used for control flow instead of
for error conditions).

--

___
Python tracker 

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

[issue5141] C API for appending to arrays

[kxroberto]

kxroberto  added the comment:

I had a similar problem creating a C-fast array.array interface for Cython.
The array.pxd package here (latest zip file)
http://trac.cython.org/cython_trac/ticket/314
includes a arrayarray.h file, which provides ways for efficient creation
and growth from C (extend, extend_buffer, resize, resize_smart ). Its
probably in one of the next Cython distributions anyway, and will be
maintained. And perhaps array2 and arrayM extension subclasses (very
light-weight numpy) with public API coming soon too.
It respects the different Python versions, so its a lite "quasi API".
And in case there will be a (unlikely) change in future Pythons, the
Cython people will take care as far as there is no official API coming up.
Or perhaps most people with such interest use Cython anyway.

--
nosy: +kxroberto

___
Python tracker 

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

[issue6015] Tkinter Scrollbar in OS X 10.5

[Marc Culler]

Marc Culler  added the comment:

I have the same issues with Python 2.6 code I have written.  In OS X
10.4 the scrollbars work correctly with a Tkinter Text widget.  The same
code running in 10.5 exhibits this erratic behavior.  It appears as
though mouse movement events are queued up, causing the mouse to get
ahead of the scrollbar.  Later, at some random time, it appears as
though the queued events get processed all at once, causing the
scrollbar to leap ahead of the mouse.  The scrollbar widget display also
becomes corrupted at times, with the blue color from the slider being
written into the buttons at the bottom.

--
components: +Tkinter -IDLE
nosy: +culler
title: Scrollbar in Idle os x 10.5 -> Tkinter Scrollbar in OS X 10.5
type:  -> performance
versions: +Python 2.6 -Python 3.1

___
Python tracker 

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

[issue5975] csv unix file format ('\n' line terminator)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

New features must be targeted at 2.7/3.2.  2.5 is in security-fix only
mode and 2.6 in bug-fix only mode, as is 3.0.  3.1 is in beta with new
features pretty well frozen.

--
nosy: +tjreedy
versions: +Python 2.7, Python 3.2 -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

[issue6030] io.BufferedWriter C module missing _write_lock

[Josh Roesslein]

New submission from Josh Roesslein :

The C version of BufferedWriter is missing the _write_lock attribute.
I am not sure if there is a reason for this or it was left out by
accident. Python version still has the attribute.

--
components: Extension Modules, IO, Library (Lib)
messages: 87831
nosy: jroesslein
severity: normal
status: open
title: io.BufferedWriter C module missing _write_lock
type: behavior
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

[issue6030] io.BufferedWriter C module missing _write_lock

[Benjamin Peterson]

Benjamin Peterson  added the comment:

That's supposed to be a private attribute, so, yes, the omission was
purposeful.

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

[issue5980] Add bug tracker tasks to PEP 101

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Would these tasks, whereever documented, be entirely manual or partly
automated?  I just fixed new feature request #5975 which originally
selected 2.5,2.6,3.0.  It would be nice if the tracker automatically
rejected such invalid selections and selected 2.7/3.2 instead.

--
nosy: +tjreedy

___
Python tracker 

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

[issue5980] Add bug tracker tasks to PEP 101

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I of course agree that these tasks should be listed somewhere, but have
no opinion on which PEP, if not both.

--

___
Python tracker 

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

[issue6030] io.BufferedWriter C module missing _write_lock

[Josh Roesslein]

Josh Roesslein  added the comment:

Okay so even if you extend the BufferedWriter class, you should not
be using that lock for thread safety, correct? But you must still use
locks since its not thread safe still?

--

___
Python tracker 

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

[issue6028] Interpreter crashes when chaining an infinite number of exceptions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Amaury, your patch might make some individual cases better, but it won't
prevent a FatalError from occurring in all cases.

Also, it makes things worse in the following case:

def recurse():
try:
recurse()
except:
recurse()

recurse()

(the script goes into an uninterruptible infinite loop, rather than
raising an explicit Fatal error)

More useful, IMHO, would be to patch Py_FatalError() so that a traceback
is printed.

--

___
Python tracker 

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

[issue6030] io.BufferedWriter C module missing _write_lock

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The C BufferedWriter class itself is thread-safe. I'm not sure what you
are worried about, perhaps you are writing your own derived class?

--
nosy: +pitrou

___
Python tracker 

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

[issue5141] C API for appending to arrays

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This has more chances of seeing some progress if you propose a patch.

--
nosy: +pitrou

___
Python tracker 

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

[issue5982] classmethod, staticmethod: expose wrapped function

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Having to bind and unbind a classmethod to get at the function is
definitely a bit weird, and also susceptible to changing implementation,
but do you have a practical use case to motivate the effort needed?

In Py3, '__func__' replaced 'im_func', and that is the name to use if
the attribute is added.  A change in 3.2 is at least as likely as a
change in 2.7.

--
nosy: +tjreedy
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

[issue5985] Implement os.path.samefile and os.path.sameopenfile on Windows

[Terry J. Reedy]

Terry J. Reedy  added the comment:

At this point, 2.7/3.2 are the only targets for new features.

--
nosy: +tjreedy
versions:  -Python 2.5, Python 2.6, Python 3.0, Python 3.1

___
Python tracker 

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

[issue6029] FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) [SPARC/64-bit]

[Clifford W Johnson]

Changes by Clifford W Johnson :


--
nosy: +JohnsonCW

___
Python tracker 

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

[issue5975] csv unix file format ('\n' line terminator)

[Jay Talbot]

Jay Talbot  added the comment:

I'm sorry. I will remember to try and look up where the new features are
being targeted. Reporting bugs and requesting new features here is new
to me. Everyone seems to have their own rules.

--

___
Python tracker 

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

[issue6029] FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) [SPARC/64-bit]

[Clifford W Johnson]

Clifford W Johnson  added the comment:

I get a nearly identical failure building Python 2.6.2 on a SPARC64
machine running Solaris 5.10 using GCC 4.1.1.

# ./python ./Lib/test/test_ctypes.py
...
test_longdouble (ctypes.test.test_callbacks.Callbacks) ... FAIL
...

==
FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks)
--
Traceback (most recent call last):
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
self.check_type(c_longdouble, 3.14)
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: (-3, 0.0) != (-3, 3.1401)

--
Ran 319 tests in 1.951s

FAILED (failures=1)
Traceback (most recent call last):
  File "./Lib/test/test_ctypes.py", line 12, in 
test_main()
  File "./Lib/test/test_ctypes.py", line 9, in test_main
run_unittest(unittest.TestSuite(suites))
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/test/test_support.py",
line 722, in run_unittest
_run_suite(suite)
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/test/test_support.py",
line 705, in _run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 81, in test_longdouble
self.check_type(c_longdouble, 3.14)
  File
"/home/build/clifford/gpdb/tools/python/2.6.2/objs/sol10_sparc_64/Lib/ctypes/test/test_callbacks.py",
line 30, in check_type
self.failUnlessEqual(self.got_args, (-3, arg))
AssertionError: (-3, 0.0) != (-3, 3.1401)

--

___
Python tracker 

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

[issue5956] test_distutils fails for Python 3.1b1 on MacOS X

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ouch! Could you try to simply open() an exe file in the interactive
interpreter?
What does os.stat() give on this exe file?
What does os.stat() give on a "real" directory?

If some files are also directories under MacOS X, perhaps we must
reconsider the directory detection routine in _fileio.c.

--
nosy: +pitrou

___
Python tracker 

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

[issue5956] test_distutils fails for Python 3.1b1 on MacOS X

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
components: +IO

___
Python tracker 

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

[issue5956] test_distutils fails for Python 3.1b1 on MacOS X

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Where does wininst-6.0.1.exe come from? I don't see it on a fresh
checkout (there's only wininst-6.0.exe (without the ".1")). Does MacOS X
create these "aliases" automatically?

Did you install Python 3.1 or are your running directly from the source
tree?

--

___
Python tracker 

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

[issue6031] BaseServer.shutdown documentation is incomplete

[Gabriel Genellina]

New submission from Gabriel Genellina :

BaseServer.shutdown is documented as "Tells the serve_forever() loop to 
stop and waits until it does."

The docstring is much more explicit: """Stops the serve_forever loop. 
Blocks until the loop has finished. This must be called while 
serve_forever() is running in another thread, or it will deadlock."""

Combined with #2302 I'd rewrite both (rst and docstring) as:

BaseServer.shutdown(): Tells the serve_forever() loop to stop, and 
waits until the loop has finished. This must be called after 
serve_forever() has started and while it is running in another thread, 
or the shutdown() call will deadlock."

--
assignee: georg.brandl
components: Documentation
messages: 87845
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: BaseServer.shutdown documentation is incomplete
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6032] Fix refleaks in test_urllib2_localnet

[Collin Winter]

New submission from Collin Winter :

Currently (r72673), test_urllib2_localnet leaks references. This is due
to state implicitly shared between tests. The attached patch fixes this
by removing the shared state.

The problem is also present in py3k. I'll port the patch once I commit
to trunk. Should this be backported so we can take test_urllib2_localnet
off the refleak test blacklist in Misc/build.sh in those branches?

--
components: Tests
files: urllib2_localnet.patch
keywords: patch
messages: 87846
nosy: collinwinter
severity: normal
stage: patch review
status: open
title: Fix refleaks in test_urllib2_localnet
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file13991/urllib2_localnet.patch

___
Python tracker 

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

[issue6032] Fix refleaks in test_urllib2_localnet

[Daniel Diniz]

Daniel Diniz  added the comment:

Collin,
This the fix for issue 6002, right? Does issue 1208304 also cause leaks
in your tests?

--
dependencies: +test_urllib2_localnet DigestAuthHandler leaks nonces
nosy: +ajaksu2
priority:  -> normal

___
Python tracker 

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

[issue6032] Fix refleaks in test_urllib2_localnet

[Collin Winter]

Collin Winter  added the comment:

Yes, this is a patch for issue 6002 (sorry, didn't find it). I haven't
seen any refleaks from issue 1208304, but I was only looking at this one
particular failure (since it was showing up in Unladen Swallow's refleak
builds).

--

___
Python tracker 

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

[issue5677] Serious interpreter crash and/or arbitrary memory leak using .read() on writable file

[Daniel Diniz]

Changes by Daniel Diniz :


--
components: +IO
nosy: +benjamin.peterson, pitrou
priority:  -> high
stage:  -> test needed
versions:  -Python 2.4

___
Python tracker 

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

[issue4188] Lib/threading.py causes infinite recursion when running as verbose

[Daniel Diniz]

Changes by Daniel Diniz :


--
priority:  -> high
stage:  -> test needed
type:  -> behavior

___
Python tracker 

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

[issue4186] type() doesn't accept bases and dict keyword arguments

[Daniel Diniz]

Changes by Daniel Diniz :


--
stage:  -> test needed
type:  -> behavior

___
Python tracker 

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

[issue4174] Performance optimization for min() and max() over lists

[Daniel Diniz]

Daniel Diniz  added the comment:

Given the drawbacks mentioned (and the fact that the current patch would
break when the list mutates under its feet), is this still valid?

--
nosy: +ajaksu2
stage:  -> test needed

___
Python tracker 

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

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

[Benjamin Peterson]

New submission from Benjamin Peterson :

This is an optimization ported from PyPy. [1] It tries to prevent bound
methods from being created by using the stack as a cache. I couldn't
apply this to builtin methods because those use a method-wrapper
descriptor. The results were not very impressive. However, I'm attaching
the patch to see if anyone else wants to look at it.

[1]
http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizations.html#id1


Test minimum run-timeaverage  run-time
 thisother   diffthisother 
 diff
---
  BuiltinFunctionCalls:   342ms   340ms   +0.6%   378ms   361ms
  +4.7%
   BuiltinMethodLookup:   315ms   308ms   +2.3%   333ms   319ms
  +4.5%
 CompareFloats:   250ms   251ms   -0.3%   257ms   258ms
  -0.7%
 CompareFloatsIntegers:   266ms   265ms   +0.4%   273ms   273ms
  -0.2%
   CompareIntegers:   233ms   232ms   +0.4%   238ms   238ms
  -0.2%
CompareInternedStrings:   279ms   275ms   +1.3%   285ms   284ms
  +0.3%
  CompareLongs:   225ms   223ms   +1.1%   231ms   229ms
  +0.8%
CompareStrings:   238ms   235ms   +1.3%   244ms   243ms
  +0.6%
CompareUnicode:   243ms   246ms   -0.9%   252ms   252ms
  -0.1%
ComplexPythonFunctionCalls:   307ms   301ms   +2.0%   315ms   309ms
  +1.8%
 ConcatStrings:   372ms   366ms   +1.6%   376ms   385ms
  -2.1%
 ConcatUnicode:   260ms   259ms   +0.4%   266ms   269ms
  -0.9%
   CreateInstances:   351ms   336ms   +4.7%   365ms   346ms
  +5.5%
CreateNewInstances:   265ms   256ms   +3.6%   281ms   264ms
  +6.5%
   CreateStringsWithConcat:   290ms   289ms   +0.1%   304ms   301ms
  +1.2%
   CreateUnicodeWithConcat:   220ms   219ms   +0.8%   227ms   223ms
  +1.8%
  DictCreation:   201ms   200ms   +0.4%   204ms   206ms
  -1.0%
 DictWithFloatKeys:   400ms   418ms   -4.4%   410ms   424ms
  -3.4%
   DictWithIntegerKeys:   298ms   294ms   +1.2%   306ms   304ms
  +0.6%
DictWithStringKeys:   260ms   264ms   -1.5%   270ms   275ms
  -2.1%
  ForLoops:   224ms   223ms   +0.2%   232ms   232ms
  +0.2%
IfThenElse:   160ms   160ms   +0.0%   168ms   182ms
  -8.0%
   ListSlicing:   293ms   292ms   +0.5%   302ms   306ms
  -1.2%
NestedForLoops:   301ms   300ms   +0.2%   305ms   308ms
  -0.8%
  NestedListComprehensions:   323ms   328ms   -1.7%   331ms   335ms
  -1.3%
  NormalClassAttribute:   313ms   314ms   -0.1%   323ms   330ms
  -2.1%
   NormalInstanceAttribute:   284ms   283ms   +0.4%   289ms   288ms
  +0.4%
   PythonFunctionCalls:   259ms   278ms   -6.7%   274ms   289ms
  -5.3%
 PythonMethodCalls:   358ms   357ms   +0.3%   371ms   365ms
  +1.6%
 Recursion:   389ms   398ms   -2.1%   395ms   407ms
  -2.9%
  SecondImport:   335ms   319ms   +5.2%   346ms   380ms
  -8.9%
   SecondPackageImport:   338ms   326ms   +3.6%   350ms   337ms
  +4.0%
 SecondSubmoduleImport:   413ms   403ms   +2.5%   426ms   411ms
  +3.6%
   SimpleComplexArithmetic:   341ms   345ms   -1.2%   351ms   355ms
  -1.1%
SimpleDictManipulation:   288ms   298ms   -3.7%   293ms   303ms
  -3.1%
 SimpleFloatArithmetic:   272ms   275ms   -1.1%   279ms   286ms
  -2.7%
  SimpleIntFloatArithmetic:   211ms   204ms   +3.3%   216ms   215ms
  +0.5%
   SimpleIntegerArithmetic:   207ms   203ms   +1.7%   214ms   213ms
  +0.5%
  SimpleListComprehensions:   275ms   273ms   +0.6%   281ms   281ms
  -0.1%
SimpleListManipulation:   224ms   229ms   -2.5%   234ms   241ms
  -2.9%
  SimpleLongArithmetic:   252ms   253ms   -0.6%   263ms   266ms
  -1.0%
SmallLists:   290ms   301ms   -3.8%   299ms   311ms
  -3.9%
   SmallTuples:   254ms   253ms   +0.3%   261ms   266ms
  -1.9%
 SpecialClassAttribute:   311ms   309ms   +0.7%   320ms   321ms
  -0.2%
  SpecialInstanceAttribute:   358ms   358ms   +0.1%   370ms   371ms
  -0.4%
StringMappings:   817ms   833ms   -1.9%   823ms   852ms
  -3.4%
  StringPredicates:   488ms   538ms   -9.2%   495ms   547ms
  -9.4%
 StringSlicing:   295ms   296ms   -0.2%   306ms   323ms
  -5.5%
 TryExcept:   282ms   280ms   +1.0%   291ms   288ms
  +1.0%
TryFinally:   290ms   255ms  +14.1%   300ms   263ms
 +14.1%
TryRaiseExcept:   261ms   256ms   +1.7%   271ms   263ms
  +3.1%
  TupleSlicing:   281ms   270ms   +4.3%   289ms   277ms
  +4.3%
   UnicodeMappings:   329ms   337ms   -2.4%   337ms   348ms
  -3.0%
 UnicodePredicates:   295ms   329ms  -10.4%   303ms   338m

[issue5956] test_distutils fails for Python 3.1b1 on MacOS X

[Jean Brouwers]

Jean Brouwers  added the comment:

Here are the answers to your questions.

% python
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('Lib/distutils/command/wininst-6.0.exe')
Traceback (most recent call last):
  File "", line 1, in 
IOError: [Errno 21] Is a directory: 'Lib/distutils/command/wininst-6.0.exe'

>>> import os
>>> os.path.isdir('Lib/distutils/command/wininst-6.0.exe')
True

>>> os.stat('Lib/distutils/command/wininst-6.0.exe')
posix.stat_result(st_mode=16877, st_ino=6314085L, st_dev=234881026L, 
st_nlink=2, st_uid=501, 
st_gid=501, st_size=68L, st_atime=1242244664, st_mtime=1241712622, 
st_ctime=1241712622)

>>> os.stat('Lib/distutils/command')
posix.stat_result(st_mode=16877, st_ino=6314060L, st_dev=234881026L, 
st_nlink=58, st_uid=501, 
st_gid=501, st_size=1972L, st_atime=1242244781, st_mtime=1242245012, 
st_ctime=1242245012)


But here is the root cause.  The Python-3.1b1 files were created by Stuffit 
Expander ffrom the original 
Python-3.1b1 tar ball downloaded from the Python website.  Changing the Stuffit 
preferences does not 
make any difference.  

However, if that same tar ball is uncompressed by the  tar -zxf ... command, 
there are no directories.  
Only five simple files, as expected:

-rw-r--r--   1 jean  jean   61440 Jul 15  2008 wininst-6.0.exe
-rw-r--r--   1 jean  jean   65536 Jul 15  2008 wininst-7.1.exe
-rw-r--r--   1 jean  jean   61440 Jan 20 13:25 wininst-8.0.exe
-rw-r--r--   1 jean  jean  224256 Jan 29 05:08 wininst-9.0-amd64.exe
-rw-r--r--   1 jean  jean  196096 Jan 29 05:08 wininst-9.0.exe


After removing the directory files (and renaming the *.1.exe to *.exe), the 
regression tests passes.

% ./python.exe ../Python-3.1b1/Lib/test/test_distutils.py
test_formats (distutils.tests.test_bdist.BuildTestCase) ... ok
test_simple_built (distutils.tests.test_bdist_dumb.BuildDumbTestCase) ... ok
test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase) ... ok
test_quiet (distutils.tests.test_bdist_rpm.BuildRpmTestCase) ... ok
test_get_exe_bytes (distutils.tests.test_bdist_wininst.BuildWinInstTestCase) 
... ok
test_build_libraries (distutils.tests.test_build_clib.BuildCLibTestCase) ... ok
test_check_library_dist (distutils.tests.test_build_clib.BuildCLibTestCase) ... 
ok
test_finalize_options (distutils.tests.test_build_clib.BuildCLibTestCase) ... ok
test_get_source_files (distutils.tests.test_build_clib.BuildCLibTestCase) ... ok
test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_optional_extension (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_solaris_enable_shared (distutils.tests.test_build_ext.BuildExtTestCase) 
... ok
test_user_site (distutils.tests.test_build_ext.BuildExtTestCase) ... ok
test_empty_package_dir (distutils.tests.test_build_py.BuildPyTestCase) ... ok
test_package_data (distutils.tests.test_build_py.BuildPyTestCase) ... ok
test_build (distutils.tests.test_build_scripts.BuildScriptsTestCase) ... ok
test_default_settings (distutils.tests.test_build_scripts.BuildScriptsTestCase) 
... ok
test_version_int (distutils.tests.test_build_scripts.BuildScriptsTestCase) ... 
ok
test_check_all (distutils.tests.test_check.CheckTestCase) ... ok
test_check_document (distutils.tests.test_check.CheckTestCase) ... ok
test_check_metadata (distutils.tests.test_check.CheckTestCase) ... ok
test_check_restructuredtext (distutils.tests.test_check.CheckTestCase) ... ok
test_simple_run (distutils.tests.test_clean.cleanTestCase) ... ok
test_dump_options (distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_dirname (distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_filename (distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_string (distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_string_list (distutils.tests.test_cmd.CommandTestCase) ... ok
test_make_file (distutils.tests.test_cmd.CommandTestCase) ... ok
test_server_empty_registration 
(distutils.tests.test_config.PyPIRCCommandTestCase) ... ok
test_server_registration (distutils.tests.test_config.PyPIRCCommandTestCase) 
... ok
test_clean (distutils.tests.test_config_cmd.ConfigTestCase) ... ok
test_dump_file (distutils.tests.test_config_cmd.ConfigTestCase) ... ok
test_finalize_options (distutils.tests.test_config_cmd.ConfigTestCase) ... ok
test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase) ... ok
test_run_setup_provides_file (distutils.tests.test_core.CoreTestCase) ... ok
test_run_setup_uses_current_dir (distutils.tests.test_core.CoreTestCase) ... ok
test_copy_tree_verbosity (distutils.tests.test_dir_util.DirUtilTestCase) ... ok
test_create_tree_verbosity (distutils.tests.test_dir_util.DirUtilTestCase) ... 
ok
test_mkpath_remove_tree_verbosity 
(distutils.tests.test_dir_util.DirUtilTestCase) ... ok
test_command_packages_cmdline (distutils.tests.test_dist.DistributionTestCase) 
... ok
test_comma

[issue6034] Fix object.__reversed__ doc

[Terry J. Reedy]

New submission from Terry J. Reedy :

3.3.5. Emulating container types
object.__reversed__(self)
says in 3.0 and 3.1 and I assume in 2.x:
"Objects should normally only provide __reversed__() if they do not
support the sequence protocol and an efficient implementation of reverse
iteration is possible."

The builtin sequences violate this because because they do support the
sequence and have __ reversed__ methods anyway.  And iterables that do
not support that protocol obviously *must* provide a method to be
reverse iterable.

I believe the point is that it is hard for Python code to beat the
C-coded version of the obvious

def __reversed__(self):
   for i in reversed(range(self.__len__)):
  yield self.__getitem__(i)

So I think the entry should say: "Objects that support the sequence
protocol should only provide __reversed__ if they can provide an
implementation that is more efficient than the one provided by
reversed()." possibly followed by "Objects that do not supposrt the
sequence protocol must provide __reversed__ to be reverse iterable."

--
assignee: georg.brandl
components: Documentation
messages: 87852
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Fix object.__reversed__ doc
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue5992] spurious space after opening parenthesis when auto-completing

[Terry J. Reedy]

Terry J. Reedy  added the comment:

What system are you using?  On Windows 3.0.1, standard interpreter window,
'h' 'e' '' prints 'h' 'e' ' ' ' ' (making, with '>>> ', 8 chars.
Which is to say, there is no tab completion.

On IDLE, same brings up box and   completes to 'help'

--
nosy: +tjreedy

___
Python tracker 

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

[issue5996] abstract class instantiable when subclassing dict

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I presume you claim the dict example to be a bug in relation to "A class
that has a metaclass derived from ABCMeta cannot be instantiated unless
all of its abstract methods and properties are overridden."

There is the same difference with @abstractproperty
Windows, 3.0.1

class C(metaclass=abc.ABCMeta):
@abc.abstractmethod
def f(self): return True

class C2(dict,metaclass=abc.ABCMeta):
@abc.abstractmethod
def f(self): return True

c2=C2()
print(c2.f())

c=C()
# prints
True
...
TypeError: Can't instantiate abstract class C with abstract methods f

--
nosy: +tjreedy

___
Python tracker 

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

[issue6017] Dict fails to notice addition and deletion of keys during iteration

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The OP reported a real mismatch between doc and behavior.  If the
behavior is not changed, I think the doc should be.  Other implementors,
reading the doc, might think that they do have to write code to track
changes.  From the doc, I thought that CPython did that.

So I suggest changing reopening and changing the doc to say
"Changing the net size of the dictionary while using iteritems() will
raise a RuntimeError."  Same for iterkeys() and itervalues()[sp?]

Or remove the warning, as happened in the Py3 changeover to views, or
was that a mistake?

--
nosy: +tjreedy

___
Python tracker 

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

[issue6028] Interpreter crashes when chaining an infinite number of exceptions

[Yury]

Yury  added the comment:

The code you posted causes an infinite loop in the 2.x branch as well.
Anyway, I do not see how crashing is a desired result. An infinite loop
means the programmer made a mistake somewhere. A crash means the
interpreter did.

--

___
Python tracker 

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

[issue858809] Use directories from configure rather than hardcoded

[soundmurderer]

soundmurderer  added the comment:

I can confirm that --bindir and --libdir are broken in Python 2.6.2,
despite the fact that ./configure --help lists them as helpful options.
 At the very least, ./configure should complain if you're using options
that don't do anything!  That would be the easy fix.

Here is what I am doing:

./configure \
--prefix=/home/soundmurderer \
--bindir=/home/soundmurderer/bin/x86_64/Python-2.6.2 \
--libdir=/home/soundmurderer/lib/x86_64 

OK, now let's see the relevant section of the generated Makefile:

# Install prefix for architecture-independent files
prefix= /home/soundmurderer/auzilov

# Install prefix for architecture-dependent files
exec_prefix=${prefix}

# Install prefix for data files
datarootdir=${prefix}/share

# Expanded directories
BINDIR= $(exec_prefix)/bin
LIBDIR= $(exec_prefix)/lib
MANDIR= ${datarootdir}/man
INCLUDEDIR= ${prefix}/include
CONFINCLUDEDIR= $(exec_prefix)/include
SCRIPTDIR=  $(prefix)/lib

# Detailed destination directories
BINLIBDEST= $(LIBDIR)/python$(VERSION)
LIBDEST=$(SCRIPTDIR)/python$(VERSION)
INCLUDEPY=  $(INCLUDEDIR)/python$(VERSION)
CONFINCLUDEPY=  $(CONFINCLUDEDIR)/python$(VERSION)
LIBP=   $(LIBDIR)/python$(VERSION)

So, the --libdir and --bindir flags had no effect on LIBDIR and BINDIR,
and I wind up editing the Makefile by hand to get desired behavior.

--
nosy: +soundmurderer

___
Python tracker 

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

[issue858809] Use directories from configure rather than hardcoded

[soundmurderer]

soundmurderer  added the comment:

I tried applying nijel's 2.3.2 patch to Python 2.6.2 Makefile.pre.in,
then configure/make/install with --bindir and --libdir flags to
./configure.  It works in terms of producing the correct Makefile with
LIBDIR and BINDIR that I want, but I get problems after the "make
install" step when I launch the Python interpreter.  This is what happens:

Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
'import site' failed; use -v for traceback
Python 2.6.2 (r262:71600, May 15 2009, 22:46:19)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

I can work around bad imports and "could not find libraries" by adding
various subdirs of my desired LIBDIR to PYTHONHOME and PYTHONPATH.  But
the point is -- I thought that a *properly* installed Python
distribution should know where to find its own standard libraries??  I
should not have to hack PYTHONHOME and PYTHONPATH to get my local
install to work... right?

Once upon a time in 2.5.x days, I was able to do a local install using
only ./configure --prefix, and that's it.  No hacking PYTHONHOME or
PYTHONPATH that I recall.

How is the path to stuff like site.py getting encoded in the Python
installation?  Because I suspect that although nijel's patch may work
for generating makefiles that put binaries/libs in the right place, that
encoding step is still getting botched, requiring to manually set
PYTHONHOME and PYTHONPATH as a workaround.

Or maybe I am just confused.

--

___
Python tracker 

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