From report at bugs.python.org  Sat Aug  1 01:21:07 2009
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 31 Jul 2009 23:21:07 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1249082467.52.0.102396191094.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

I tested asyncore_fix_refused-3.patch on Mac OS X 10.5 - all asyncore 
and asynchat tests pass.

There is one minor issue - _exception calls the non existing 
handle_close_event instead of handle_close.

However, looking again at the code I think that it is ugly and wrong - 
handle_expt_event should handle the low level expt event called from 
select, allowing third party dispatcher to override the behavior as 
needed.

Another issue - lately, a new event was added - handle_connect_event - 
this is wrong! there is no such low level event. handle_connect is a 
high level event, implied by first read or write on the connecting 
socket. This event will break 3rd party dispatcher that does not 
implement it, and is not documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Sat Aug  1 02:47:43 2009
From: report at bugs.python.org (Christopher Dolan)
Date: Sat, 01 Aug 2009 00:47:43 +0000
Subject: [issue5737] add Solaris errnos
In-Reply-To: <1239469549.92.0.788554665966.issue5737@psf.upfronthosting.co.za>
Message-ID: <1249087663.62.0.986270728496.issue5737@psf.upfronthosting.co.za>


Christopher Dolan <shyboyswin at gmail.com> added the comment:

This is a patch against the latest subversion revision that adds the
addition errno names, numbers, and messages available in Solaris.

----------
keywords: +patch
nosy: +cdolan
Added file: http://bugs.python.org/file14616/issue5737.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5737>
_______________________________________

From report at bugs.python.org  Sat Aug  1 06:00:40 2009
From: report at bugs.python.org (James Abbatiello)
Date: Sat, 01 Aug 2009 04:00:40 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1249099240.35.0.441474091904.issue6608@psf.upfronthosting.co.za>


James Abbatiello <abbeyj at gmail.com> added the comment:

Since there's no good way to disable the assertion (see issue4804),
checking the validity of the argument beforehand looks like an option. 
The checking that's currently being done in the strftime()
implementation looks useful but it is not enough.  The checking in the
MS implementation of asctime() is very strict and validates the entire
date, not just one field at a time.  So there's no way to print out
non-existant dates like (2009, 2, 31, 0, 0, 0, 0, 0, 0) -> 'Mon Feb 31
00:00:00 2009'.  

I don't know if anybody is relying on that kind of behavior.  If not
then the function could be limited to accept only valid dates. 
Alternatively we could just not call down to asctime() but instead
provide our own implementation using sprintf/strftime.

----------
nosy: +abbeyj

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Sat Aug  1 08:11:47 2009
From: report at bugs.python.org (bones7456)
Date: Sat, 01 Aug 2009 06:11:47 +0000
Subject: [issue6611] HTMLParser cannot deal with mixture of arbitrary data and
	character reference
In-Reply-To: <1249026354.39.0.530341625498.issue6611@psf.upfronthosting.co.za>
Message-ID: <1249107107.73.0.535669996134.issue6611@psf.upfronthosting.co.za>


bones7456 <bones7456 at gmail.com> added the comment:

another fix way:
and these three lines to the head of file:

import sys
reload(sys)
sys.setdefaultencoding('utf8')

----------
nosy: +bones7456

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6611>
_______________________________________

From report at bugs.python.org  Sat Aug  1 13:51:22 2009
From: report at bugs.python.org (Nir Soffer)
Date: Sat, 01 Aug 2009 11:51:22 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1249127482.83.0.0484103098969.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

I was wrong about handle_connect_event - it is called only from the 
dispatcher, so it will not break 3rd party dispatcher.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Sat Aug  1 14:09:54 2009
From: report at bugs.python.org (Nir Soffer)
Date: Sat, 01 Aug 2009 12:09:54 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1249128594.73.0.21168054249.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

This is asyncore-fix-refused-3.patch with some fixes:

 1. Call handle_close instead of non exiting handle_close_event
 2. Remove unneeded handle_close_event in test classes
 3. Revert removal of handle_expt_event in test classes - not clear why it 
was removed in the previous patch.

Tested on Mac OS X 10.5.

----------
Added file: http://bugs.python.org/file14617/asyncore-fix-refused-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Sat Aug  1 16:26:12 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 01 Aug 2009 14:26:12 +0000
Subject: [issue4432] IDLE.app (Mac) File Menu MIssing Options
In-Reply-To: <1227662544.21.0.925756353896.issue4432@psf.upfronthosting.co.za>
Message-ID: <1249136772.01.0.353748730911.issue4432@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Closing. I have seen the code changes regarding idle and mac and I
believe this issue has been fixed (some time after the OP started this,
but it has).

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4432>
_______________________________________

From report at bugs.python.org  Sat Aug  1 17:24:32 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 01 Aug 2009 15:24:32 +0000
Subject: [issue3559] Pasted \n not same as typed \n
In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za>
Message-ID: <1249140272.16.0.505761406894.issue3559@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This seems to be problematic in general. I have worked on a patch now,
but it fails to succeed while pasting multiple lines. The problem is
that when a second line is pasted, IDLE is still marked as "executing"
so it ends up just pasting the line without executing it.

----------
keywords: +patch
Added file: http://bugs.python.org/file14618/fix_idleshell_paste.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3559>
_______________________________________

From report at bugs.python.org  Sat Aug  1 18:09:07 2009
From: report at bugs.python.org (OG7)
Date: Sat, 01 Aug 2009 16:09:07 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>


New submission from OG7 <onyxg7 at users.sourceforge.net>:

There is an additional test for multiprocessing's logging support here:
http://code.google.com/p/python-multiprocessing/issues/detail?id=18
(disregard the fix, it is only needed for the backport).

----------
components: Library (Lib)
messages: 91163
nosy: OG7, jnoller
severity: normal
status: open
title: multiprocessing logging support test
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Sat Aug  1 18:20:50 2009
From: report at bugs.python.org (Liu DongMiao)
Date: Sat, 01 Aug 2009 16:20:50 +0000
Subject: [issue6611] HTMLParser cannot deal with mixture of arbitrary data and
	character reference
In-Reply-To: <1249026354.39.0.530341625498.issue6611@psf.upfronthosting.co.za>
Message-ID: <1249143650.15.0.856539739844.issue6611@psf.upfronthosting.co.za>


Liu DongMiao <liudongmiao at gmail.com> added the comment:

i think this should not be a bug.

as we dont know the encoding of str, so we cannt deal with str and
unicode together. 

in my example, str is in utf-8, so i need to convert unicode to str in
utf-8.

i will takes bones' suggestion.

----------
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6611>
_______________________________________

From report at bugs.python.org  Sat Aug  1 19:49:22 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Sat, 01 Aug 2009 17:49:22 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1249148962.64.0.300674644941.issue6550@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

handle_expt_event was removed in the test classes because it is no 
longer being used by any of the tests.  None of them send OOB data (also 
known as priority data), so handle_expt_event should never be called.  
When I have a chance to compare your patch to mine (Monday, likely), 
I'll comment then.

In terms of "handle_expt_event should handle the low level expt event 
called from select", what you don't seem understand is that and "expt 
event" is not an exception event, it's a "we got OOB data" event, and 
with the patches, it is called at *exactly* the time it should be: when 
there is OOB data.  It used to be mistakenly called in the select loop 
whenever any sort of non-normal condition happened on the socket, which 
was a serious design flaw, and lead to significant misunderstanding 
about the purpose of the method.

With the _exception() call as-is, it now behaves like the 
asyncore.poll2() function, which is the right thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Sat Aug  1 20:55:43 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 01 Aug 2009 18:55:43 +0000
Subject: [issue5124] IDLE - pasting text doesn't delete selection
In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za>
Message-ID: <1249152943.41.0.119797924985.issue5124@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

btw, I just added a patch for issue3559 which could be easily adjusted
to work as described in this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5124>
_______________________________________

From report at bugs.python.org  Sat Aug  1 22:43:47 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sat, 01 Aug 2009 20:43:47 +0000
Subject: [issue6616] PyList_APPEND (append without incref)
In-Reply-To: <1249159427.67.0.400493436196.issue6616@psf.upfronthosting.co.za>
Message-ID: <1249159427.67.0.400493436196.issue6616@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

This patch was made on python r74276

Often when writing in C/Python I want to append to a list within a C
loop of an unknown length.
When this is done for newly created PyObject (which is quite common) -
you need to assign each item to a variable and then decref it.

eg:
 PyObject *item= PyFloat_FromDouble(x);
 PyList_Append(list, item);
 Py_DECREF(item);

I have seen people make mistakes with this (in pygame code and
blender3d), and run  PyList_Append(list, PyFloat_FromDouble(x)),
ofcourse this is not the fault of python/c api that devs do not read
docs properly but I think it would be very convenient to have an append
that works in a similar way to PyList_SET_ITEM

This simple patch allows...
 PyList_APPEND(list, PyFloat_FromDouble(x))

doc included.

----------
files: py3_APPEND.diff
keywords: patch
messages: 91167
nosy: ideasman42
severity: normal
status: open
title: PyList_APPEND (append without incref)
versions: Python 3.2
Added file: http://bugs.python.org/file14619/py3_APPEND.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6616>
_______________________________________

From report at bugs.python.org  Sat Aug  1 22:45:08 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 01 Aug 2009 20:45:08 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1249159508.57.0.0333949790902.issue4832@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I'm attaching a very similar patch that I tested on Linux and Windows.
It just combines the default behaviour with the details required for
Windows, that is, the default extension is set to '.py' for Windows and
'' elsewhere (the default).

----------
Added file: http://bugs.python.org/file14620/fix_defaultextension.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Sat Aug  1 23:05:21 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Aug 2009 21:05:21 +0000
Subject: [issue6616] PyList_APPEND (append without incref)
In-Reply-To: <1249159427.67.0.400493436196.issue6616@psf.upfronthosting.co.za>
Message-ID: <1249160721.4.0.655559478536.issue6616@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> This simple patch allows...
>  PyList_APPEND(list, PyFloat_FromDouble(x))

This isn't a good idea because the error checking 
for the inner function is lost.  The current API
encourages keeping one function per line so that 
the ref counting and error-checking are more obvious.

Also, I'm not too keen on adding second-ways-to-do-it.
The C API is already somewhat fat, making it harder
to learn and remember.  The current API has standard
patterns of creating and consuming references.
Introducing variants that don't follow those patterns
makes it harder to review code and determine that it 
is correct.

It is better to learn to use the API as designed than
to commingle two different styles.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6616>
_______________________________________

From report at bugs.python.org  Sat Aug  1 23:37:58 2009
From: report at bugs.python.org (Sandip Thorat)
Date: Sat, 01 Aug 2009 21:37:58 +0000
Subject: [issue6617] During compiling python 3.1 getting error Undefined
	symbol libintl_bind_textdomain_codeset
In-Reply-To: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>
Message-ID: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>


New submission from Sandip Thorat <thoratsandip at gmail.com>:

Hi 

I am installing Python-3.1 on "SunOS sunx7qa 5.10 Generic_127112-06 
i86pc i386 i86pc".

./configure  done without any error.

But 'make' throwing folloing error:



gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes  -I. -IInclude -I./Include  -DPy_BUILD_CORE -
DSVNVERSION="\"`LC_ALL=C echo Unversioned directory`\"" -o 
Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython3.1.a
ar rc libpython3.1.a Modules/getbuildinfo.o
ar rc libpython3.1.a Parser/acceler.o  Parser/grammar1.o  
Parser/listnode.o  Parser/node.o  Parser/parser.o  Parser/parsetok.o  
Parser/bitset.o  Parser/metagrammar.o  Parser/firstsets.o  
Parser/grammar.o  Parser/pgen.o Parser/myreadline.o Parser/tokenizer.o
ar rc libpython3.1.a Objects/abstract.o  Objects/boolobject.o  
Objects/bytes_methods.o  Objects/bytearrayobject.o  
Objects/bytesobject.o  Objects/cellobject.o  Objects/classobject.o  
Objects/cobject.o  Objects/codeobject.o  Objects/complexobject.o  
Objects/descrobject.o  Objects/enumobject.o  Objects/exceptions.o  
Objects/genobject.o  Objects/fileobject.o  Objects/floatobject.o  
Objects/frameobject.o  Objects/funcobject.o  Objects/iterobject.o  
Objects/listobject.o  Objects/longobject.o  Objects/dictobject.o  
Objects/memoryobject.o  Objects/methodobject.o  Objects/moduleobject.o  
Objects/object.o  Objects/obmalloc.o  Objects/capsule.o  
Objects/rangeobject.o  Objects/setobject.o  Objects/sliceobject.o  
Objects/structseq.o  Objects/tupleobject.o  Objects/typeobject.o  
Objects/unicodeobject.o  Objects/unicodectype.o  Objects/weakrefobject.o
ar rc libpython3.1.a Python/_warnings.o  Python/Python-ast.o  
Python/asdl.o  Python/ast.o  Python/bltinmodule.o  Python/ceval.o  
Python/compile.o  Python/codecs.o  Python/errors.o  Python/frozen.o  
Python/frozenmain.o  Python/future.o  Python/getargs.o  
Python/getcompiler.o  Python/getcopyright.o  Python/getplatform.o  
Python/getversion.o  Python/graminit.o  Python/import.o  
Python/importdl.o  Python/marshal.o  Python/modsupport.o  
Python/mystrtoul.o  Python/mysnprintf.o  Python/peephole.o  
Python/pyarena.o  Python/pyctype.o  Python/pyfpe.o  Python/pymath.o  
Python/pystate.o  Python/pythonrun.o  Python/structmember.o  
Python/symtable.o  Python/sysmodule.o  Python/traceback.o  
Python/getopt.o  Python/pystrcmp.o  Python/pystrtod.o  Python/dtoa.o  
Python/formatter_unicode.o  Python/dynload_shlib.o      Python/thread.o
ar rc libpython3.1.a Modules/config.o  Modules/getpath.o  
Modules/main.o  Modules/gcmodule.o
ar rc libpython3.1.a Modules/_threadmodule.o  Modules/signalmodule.o  
Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  
Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  
Modules/_functoolsmodule.o  Modules/_localemodule.o  
Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o 
Modules/bufferedio.o Modules/textio.o Modules/stringio.o  
Modules/zipimport.o  Modules/symtablemodule.o  Modules/xxsubtype.o
ranlib libpython3.1.a
gcc   -o python \
                Modules/python.o \
                libpython3.1.a -lresolv -lsocket -lnsl -lrt -ldl   -lm
Undefined                       first referenced
 symbol                             in file
libintl_bind_textdomain_codeset     libpython3.1.a(_localemodule.o)
libintl_gettext                     libpython3.1.a(_localemodule.o)
libintl_textdomain                  libpython3.1.a(_localemodule.o)
libintl_dcgettext                   libpython3.1.a(_localemodule.o)
libintl_bindtextdomain              libpython3.1.a(_localemodule.o)
libintl_dgettext                    libpython3.1.a(_localemodule.o)
ld: fatal: Symbol referencing errors. No output written to python
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `python'
bash-3.00$ pwd


Need your help to resolve this issue.

----------
components: Installation
messages: 91170
nosy: thoratsandip
severity: normal
status: open
title: During compiling python 3.1 getting error Undefined symbol libintl_bind_textdomain_codeset
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6617>
_______________________________________

From report at bugs.python.org  Sat Aug  1 23:46:10 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 01 Aug 2009 21:46:10 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1249163170.04.0.959957176978.issue6615@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6615>
_______________________________________

From report at bugs.python.org  Sat Aug  1 23:55:16 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Sat, 01 Aug 2009 21:55:16 +0000
Subject: [issue6618] Typo in a listing in 5.2.9 of language reference
In-Reply-To: <1249163716.22.0.790124274674.issue6618@psf.upfronthosting.co.za>
Message-ID: <1249163716.22.0.790124274674.issue6618@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

Error in:

Python v3.1 documentation >> The Python language reference >>

In the listing at the end of section 5.2.9 Yield expressions,
line 7:

...             except Exception, e:

is syntactically incorrect and consequently raises a Syntax Error.
Should read:

...             except Exception as e:

----------
assignee: georg.brandl
components: Documentation
messages: 91171
nosy: georg.brandl, gregorlingl
severity: normal
status: open
title: Typo in a listing in 5.2.9 of language reference
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6618>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:13:55 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:13:55 +0000
Subject: [issue6619] Remove duplicated function in Lib/inspect.py
In-Reply-To: <1249164835.58.0.202112743442.issue6619@psf.upfronthosting.co.za>
Message-ID: <1249164835.58.0.202112743442.issue6619@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The isgenerator() function looks duplicated, remove the one with the
shortest docstring

----------
components: Library (Lib)
files: py3k-inspect.py-remove-duplicated-func.patch
keywords: patch
messages: 91172
nosy: vincele
severity: normal
status: open
title: Remove duplicated function in Lib/inspect.py
versions: Python 3.2
Added file: http://bugs.python.org/file14621/py3k-inspect.py-remove-duplicated-func.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6619>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:18:37 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:18:37 +0000
Subject: [issue6620] Variable may be used before first being assigned to in
	Lib/locale.py
In-Reply-To: <1249165117.85.0.22004101137.issue6620@psf.upfronthosting.co.za>
Message-ID: <1249165117.85.0.22004101137.issue6620@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The last_interval variable could potentially be used before being first
assigned a value.

----------
components: Library (Lib)
files: py3k-locale.py-use-before-assignment.patch
keywords: patch
messages: 91173
nosy: vincele
severity: normal
status: open
title: Variable may be used before first being assigned to in Lib/locale.py
versions: Python 3.2
Added file: http://bugs.python.org/file14622/py3k-locale.py-use-before-assignment.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6620>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:22:06 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:22:06 +0000
Subject: [issue6621] [RFC] Remove leftover use of Carbon module from
	Lib/binhex.py
In-Reply-To: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>
Message-ID: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The binhex module still has uses of the deprecated and now now removed
Carbon module.

The attached patch 'fix' this by removing the code, something else may
be required, but I don't know what.

So this is only a RFC to start discussion

----------
components: Library (Lib)
files: py3k-binhex.py-remove-carbon-module-use.patch
keywords: patch
messages: 91174
nosy: vincele
severity: normal
status: open
title: [RFC] Remove leftover use of Carbon module from Lib/binhex.py
versions: Python 3.2
Added file: http://bugs.python.org/file14623/py3k-binhex.py-remove-carbon-module-use.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6621>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:24:47 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:24:47 +0000
Subject: [issue6622] [RFC] wrong variable used in Lib/poplib.py
In-Reply-To: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
Message-ID: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The poplib modules use the 'secret' variable during its creation, this
may be a mistake. Perhaps the intention was to use the 'password' instead...

----------
components: Library (Lib)
files: py3k-poplib.py-use-wrong-variable.patch
keywords: patch
messages: 91175
nosy: vincele
severity: normal
status: open
title: [RFC] wrong variable used in Lib/poplib.py
versions: Python 3.2
Added file: http://bugs.python.org/file14624/py3k-poplib.py-use-wrong-variable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6622>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:25:35 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:25:35 +0000
Subject: [issue6623] Lib/ftplib.py
Message-ID: <1249165535.5.0.936372690866.issue6623@psf.upfronthosting.co.za>


Changes by Vincent Legoll <vincent.legoll at gmail.com>:


----------
components: Library (Lib)
nosy: vincele
severity: normal
status: open
title: Lib/ftplib.py
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6623>
_______________________________________

From report at bugs.python.org  Sun Aug  2 00:29:41 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Sat, 01 Aug 2009 22:29:41 +0000
Subject: [issue6623] Lib/ftplib.py netrc class parsing problem
In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za>
Message-ID: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

The 'macro_lines' list should probably be emptied upon leaving macro
parsing mode.

Simplify code by using the 'macro_name' variable as the boolean for
macro parsing mode.

Deprecated code probably should be fixed until completely removed

----------
keywords: +patch
title: Lib/ftplib.py -> Lib/ftplib.py netrc class parsing problem
Added file: http://bugs.python.org/file14625/py3k-ftplib.py-use-before-assignment.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6623>
_______________________________________

From report at bugs.python.org  Sun Aug  2 01:53:44 2009
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 01 Aug 2009 23:53:44 +0000
Subject: [issue6624] PyArg_ParseTuple with "s" format and NUL: Bogus TypeError
	detail string.
In-Reply-To: <1249170824.71.0.297411055704.issue6624@psf.upfronthosting.co.za>
Message-ID: <1249170824.71.0.297411055704.issue6624@psf.upfronthosting.co.za>


New submission from Sean Reifschneider <jafo at tummy.com>:

As detailed in the python-dev post:

   http://mail.python.org/pipermail/python-dev/2009-July/090791.html

I have found a bug in the handling of PyArg_ParseTuple where a NUL in an
argument causes a message like this:

   syslog.syslog('hello\0there')
   TypeError: [priority,] message string

Instead of:

   TypeError: must be string without null bytes, not str

This seems to be a thinko in Python/getargs.c at line 331:

   msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va,
        flags, levels, msgbuf,
        sizeof(msgbuf), &freelist);
   if (msg) {
      seterror(i+1, msg, levels, fname, message);   <<< Line 331
      return cleanreturn(0, freelist);
   }

This also applies to Python 3 trunk in line 390.

I think that's supposed to be "msg" instead of "message" in the last
argument.

I have made this change and "make test" for both python and py3k trunks
is clean.

----------
assignee: jafo
components: Interpreter Core
messages: 91177
nosy: jafo
priority: normal
severity: normal
stage: committed/rejected
status: open
title: PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail string.
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6624>
_______________________________________

From report at bugs.python.org  Sun Aug  2 01:55:54 2009
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 01 Aug 2009 23:55:54 +0000
Subject: [issue6624] PyArg_ParseTuple with "s" format and NUL: Bogus TypeError
	detail string.
In-Reply-To: <1249170824.71.0.297411055704.issue6624@psf.upfronthosting.co.za>
Message-ID: <1249170954.58.0.216165260521.issue6624@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Fixed in python trunk commit 74277.
Fixed in py3k trunk commit 74278.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6624>
_______________________________________

From report at bugs.python.org  Sun Aug  2 05:02:15 2009
From: report at bugs.python.org (Campbell Barton)
Date: Sun, 02 Aug 2009 03:02:15 +0000
Subject: [issue6616] PyList_APPEND (append without incref)
In-Reply-To: <1249159427.67.0.400493436196.issue6616@psf.upfronthosting.co.za>
Message-ID: <1249182135.76.0.360169406164.issue6616@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

Hi Raymond, in general I agree with your comments that adding 2 ways to
do things is not great. The reason I still think this is an advantage is
that I know the API well enough (with manipulating dicts/lists etc) and
I still want this function for the sake of convenience.

For the same reason that PyList_SET_ITEM is useful, this is useful too.

Loosing the error checking is a disadvantage but in many cases API's
dont do error checking for every new item allocated.

Python's own code does this in a few cases with PyList_SET_ITEM...
eg.
 ./Python/_warnings.c:857: PyList_SET_ITEM(filters, 1,
create_filter(PyExc_ImportWarning, "ignore"))
./Python/Python-ast.c:2757: PyList_SET_ITEM(value, i,
ast2obj_cmpop((cmpop_ty)asdl_seq_GET(o->v.Compare.ops, i)));

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6616>
_______________________________________

From report at bugs.python.org  Sun Aug  2 12:16:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 10:16:43 +0000
Subject: [issue6595] Make Decimal constructor accept all unicode decimal
	digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1249208203.95.0.83304452298.issue6595@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Committed to py3k in r74279, release31-maint in r74280.  Leaving open for 
backport to 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________

From report at bugs.python.org  Sun Aug  2 13:03:43 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 11:03:43 +0000
Subject: [issue6595] Make Decimal constructor accept all unicode decimal
	digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1249211023.55.0.80480384671.issue6595@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Backported to trunk and release26-maint in r74281 and r74282.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________

From report at bugs.python.org  Sun Aug  2 15:00:48 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Sun, 02 Aug 2009 13:00:48 +0000
Subject: [issue6625] UnicodeEncodeError on pydoc's CLI
In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
Message-ID: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>


New submission from Christoph Burgmer <cburgmer at ira.uka.de>:

pydoc fails with a UnicodeEncodeError for properly specified Unicode
docstrings (u"""...""") on the command line interface.

See attached patch that encodes the output with the system's encoding.

----------
components: Extension Modules
files: unicode.patch
keywords: patch
messages: 91182
nosy: christoph
severity: normal
status: open
title: UnicodeEncodeError on pydoc's CLI
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14626/unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6625>
_______________________________________

From report at bugs.python.org  Sun Aug  2 17:11:29 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 02 Aug 2009 15:11:29 +0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1249225889.0.0.134847166089.issue2053@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I have reviewed the latest patch now, it is nice in general but I
dislike the idea of increasing even more EditorWindow. I would really
prefer to put this somewhere else, like.. idlelib/dialogs.py. Also, I'm
inclined to remove this master/parent hiding and continue making it
explicit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
_______________________________________

From report at bugs.python.org  Sun Aug  2 17:52:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 15:52:25 +0000
Subject: [issue6619] Remove duplicated function in Lib/inspect.py
In-Reply-To: <1249164835.58.0.202112743442.issue6619@psf.upfronthosting.co.za>
Message-ID: <1249228345.79.0.565628263167.issue6619@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report!  Fixed in r74285 (trunk), r74286 (release26-maint), 
r74287 (py3k) and r74288 (release31-maint).

----------
nosy: +marketdickinson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6619>
_______________________________________

From report at bugs.python.org  Sun Aug  2 18:05:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 02 Aug 2009 16:05:30 +0000
Subject: [issue6604] test_distutils subtest test_get_exe_bytes fails depending
	on execution order
In-Reply-To: <1248972876.14.0.894982225722.issue6604@psf.upfronthosting.co.za>
Message-ID: <1249229130.22.0.975950290611.issue6604@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This was fixed in r71759 and backported in the 2.6 branch in r71765,

thanks for the feedback!

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6604>
_______________________________________

From report at bugs.python.org  Sun Aug  2 18:09:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 16:09:30 +0000
Subject: [issue6620] Variable may be used before first being assigned to in
	Lib/locale.py
In-Reply-To: <1249165117.85.0.22004101137.issue6620@psf.upfronthosting.co.za>
Message-ID: <1249229370.62.0.527711123996.issue6620@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So this can happen only if grouping is [0] (or an equivalent iterable).  
Since this is an invalid grouping, I think the appropriate response would 
be for _grouping_intervals([0]) to raise an exception (which is what it 
currently does as soon as you iterate over the result, though this is 
possibly not by design. :)

Vincent, does the attached patch (_grouping_intervals.patch, against py3k) 
silence the pylint warning?

----------
nosy: +marketdickinson
Added file: http://bugs.python.org/file14627/_grouping_intervals.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6620>
_______________________________________

From report at bugs.python.org  Sun Aug  2 18:12:42 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 02 Aug 2009 16:12:42 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1249229562.22.0.341637399665.issue2698@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The vcvarsall.bat eror is unrelated to the error James and Eric are
mentioned, which is another error fixed in the revision Hagen points.

Lenard, could you re-run it under the latest 2.6 version with the global
option --verbose please ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Sun Aug  2 18:20:25 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 02 Aug 2009 16:20:25 +0000
Subject: [issue6555] distutils config file should have the same name on both
	platforms and all scopes
In-Reply-To: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za>
Message-ID: <1249230025.16.0.7974673023.issue6555@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The mac/win difference is with the starting dot because it's impossible
under windows to name a file under the directory browser UI that starts
with a ".". You have to be a power-user to do so. (pydistutils.cfg
versus .pydistutils.cfg)

Now for pydistutils.cfg  vs distutils.cfg I don't know why it's like
that. It should be "distutils.cfg" everywhere imho. Even if the global
and local one are eventually merged. I'll launch a thread about it on
distutils-sig.

Next, setup.cfg is for the current directory because this how you
operate with packages that have setup.py+setup.cfg files : you chdir in
the directory then run a distutils command.

Last, under windows, it should use os.path.expanduser('~') instead of
looking for a HOME variable. this will be fix in any case.

----------
nosy: +exarkun
priority:  -> normal
resolution:  -> accepted
type:  -> behavior
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6555>
_______________________________________

From report at bugs.python.org  Sun Aug  2 18:28:35 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 16:28:35 +0000
Subject: [issue6622] [RFC] wrong variable used in Lib/poplib.py
In-Reply-To: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
Message-ID: <1249230515.96.0.615322496871.issue6622@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Comparing with trunk, I agree that it seems very likely that 'password' is 
intended here.

It's unfortunate that the test-suite doesn't expose this bug;  it would be 
good to come up with a test that covers this.

----------
nosy: +marketdickinson
stage:  -> test needed
type:  -> behavior
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6622>
_______________________________________

From report at bugs.python.org  Sun Aug  2 19:54:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 17:54:55 +0000
Subject: [issue6621] [RFC] Remove leftover use of Carbon module from
	Lib/binhex.py
In-Reply-To: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>
Message-ID: <1249235695.39.0.100126062032.issue6621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

As far as I can tell, it looks safe to just remove these two blocks.  
There's a third block that should be removed as well (the second "if 
os.name == 'mac': ..." in the hexbin function.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6621>
_______________________________________

From report at bugs.python.org  Sun Aug  2 19:55:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 17:55:32 +0000
Subject: [issue6621] [RFC] Remove leftover use of Carbon module from
	Lib/binhex.py
In-Reply-To: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>
Message-ID: <1249235732.69.0.782995651994.issue6621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This should be fixed in the 3.1 maintenance branch as well.

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6621>
_______________________________________

From report at bugs.python.org  Sun Aug  2 20:17:26 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 18:17:26 +0000
Subject: [issue6621] [RFC] Remove leftover use of Carbon module from
	Lib/binhex.py
In-Reply-To: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>
Message-ID: <1249237046.12.0.57601412.issue6621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue 2715.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6621>
_______________________________________

From report at bugs.python.org  Sun Aug  2 20:46:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 18:46:15 +0000
Subject: [issue2715] Remove carbon-specific code from binhex
In-Reply-To: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>
Message-ID: <1249238775.15.0.198924769427.issue2715@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This came up again recently in issue 6621.

What's the current status of the binhex module in py3k?  It looks as 
though the Carbon-specific code has been *partially* but not completely 
removed.  In particular, there are references to FSSpec remaining, but 
no FSSpec is imported anywhere.

The references to FSSpec are all inside "if os.name == 'mac': ... " 
blocks.  On my 10.5/Intel and 10.4/PPC systems os.name gives 'posix', so 
these blocks never get executed.

Is it safe to simply remove these blocks?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2715>
_______________________________________

From report at bugs.python.org  Sun Aug  2 20:47:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 18:47:20 +0000
Subject: [issue6621] [RFC] Remove leftover use of Carbon module from
	Lib/binhex.py
In-Reply-To: <1249165326.88.0.231668096917.issue6621@psf.upfronthosting.co.za>
Message-ID: <1249238840.89.0.580217067393.issue6621@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing as a duplicate of issue 2715.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Remove carbon-specific code from binhex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6621>
_______________________________________

From report at bugs.python.org  Sun Aug  2 21:15:40 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 02 Aug 2009 19:15:40 +0000
Subject: [issue2715] Remove carbon-specific code from binhex
In-Reply-To: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>
Message-ID: <1249240540.86.0.349414970545.issue2715@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

>From my understanding the mac platform is OS 9, so that code in those 'if' 
blocks can go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2715>
_______________________________________

From report at bugs.python.org  Sun Aug  2 21:19:24 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sun, 02 Aug 2009 19:19:24 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>


New submission from Jacob Rus <jacobolus at gmail.com>:

See discussion started right at the end of the month at
http://mail.python.org/pipermail/python-dev/2009-July/090928.html

And continued at
http://mail.python.org/pipermail/python-dev/2009-August/thread.html

Basically, the mimetypes module is fragile and very confusing code, 
built up over years of feature creep without refactoring or careful 
overall design. I'd like to cut it down to a more manageable code size, 
fix some bugs, update the included list of mime types, and use some nice 
Python features of versions 2.2+. Ideally someone reading the module 
once through would be able to understand what it does.

Patches to be attached shortly.

----------
components: Library (Lib)
messages: 91196
nosy: jrus
severity: normal
status: open
title: show Python mimetypes module some love
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sun Aug  2 21:22:19 2009
From: report at bugs.python.org (Tal Einat)
Date: Sun, 02 Aug 2009 19:22:19 +0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1249240939.5.0.847143178387.issue2053@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

The whole point of this patch is to make the EditorWindow's Text widget
the default master/parent for its dialogs!

IMO this makes sense, since this is a reasonable and intuitive default
for such methods of the EditorWindow object. I understand the "explicit
is better than implicit" argument, but that doesn't mean that having a
reasonable default value is always wrong. In this case having a default
value both simplifies the code considerably and makes sense, so IMO it
is justified.


Also, please note that the patch actually reduces the size of
EditorWindow.py (both character and line counts) and cleans up the code
in many places. Yes, the definition of the relevant methods is not
trivial, but it is in just one area of the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:02:44 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 02 Aug 2009 20:02:44 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

When threads are created by a C extension loaded with ctypes,
threading.local() objects are always empty. If one uses
_threading_local.local() instead of threading.local(), the problem does
not occur. 

More information and example program showing the behaviour:
http://code.google.com/p/fusepy/issues/detail?id=15

----------
components: Library (Lib)
messages: 91198
nosy: Nikratio
severity: normal
status: open
title: threading.local() does not work with C-created threads
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:04:49 2009
From: report at bugs.python.org (James Abbatiello)
Date: Sun, 02 Aug 2009 20:04:49 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1249243489.08.0.349377778748.issue6608@psf.upfronthosting.co.za>


James Abbatiello <abbeyj at gmail.com> added the comment:

Further investigation shows that MS asctime() doesn't like leap seconds
and causes an assertion when passing (2008, 12, 31, 23, 59, 60, 2, 366,
-1) -> 'Wed Dec 31 23:59:60 2008'.

Given that and since asctime() is such a simple function I think it
makes more sense to roll our own.  Attached is a rough patch which does
this.  It pulls the bounds checking used in strftime() out into its own
function so it can be used in both places.  Overriding ctime() is
necessary because Windows decided to use " %02d" instead of "%3d" to
print the day of the month.  Without overriding ctime() the output of
ctime(t) would be different from asctime(localtime(t)) and cause
test_conversion() to fail.  There is a USE_SYSTEM_ASCTIME switch to
decide whether to use the system asctime() or the internal one.

----------
keywords: +patch
Added file: http://bugs.python.org/file14628/asctime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:08:57 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sun, 02 Aug 2009 20:08:57 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249243737.71.0.945088474598.issue6626@psf.upfronthosting.co.za>


Jacob Rus <jacobolus at gmail.com> added the comment:

This diff should leave the semantics of the module essentially unchanged 
(including lazy-loading of default files), and also leave the particular 
MIME types used unchanged, even though these are out of date and should be 
updated; a subsequent suggested version will address that, perhaps after 
some discussion.

----------
keywords: +patch
Added file: http://bugs.python.org/file14629/mimetypes-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:11:00 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 20:11:00 +0000
Subject: [issue2715] Remove carbon-specific code from binhex
In-Reply-To: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>
Message-ID: <1249243860.67.0.827275337867.issue2715@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Brett.  I've removed those blocks in r74289 (py3k) and r74290 
(release31-maint).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2715>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:13:09 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Aug 2009 20:13:09 +0000
Subject: [issue2715] Remove carbon-specific code from binhex
In-Reply-To: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>
Message-ID: <1249243989.2.0.864019790327.issue2715@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It looks to me as though this issue can now be closed.  Ronald, any 
comments?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2715>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:23:49 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sun, 02 Aug 2009 20:23:49 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249244629.91.0.85187797756.issue6626@psf.upfronthosting.co.za>


Jacob Rus <jacobolus at gmail.com> added the comment:

Here is a version of the patch which does away with the lazy loading: 
these are a small handful of easy-to-parse ~40k files; if the import takes 
an extra eye-blink, it shouldn't be too big a deal.

----------
Added file: http://bugs.python.org/file14630/mimetypes3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:24:29 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sun, 02 Aug 2009 20:24:29 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249244669.87.0.337532681049.issue6626@psf.upfronthosting.co.za>


Changes by Jacob Rus <jacobolus at gmail.com>:


Removed file: http://bugs.python.org/file14629/mimetypes-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:27:00 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sun, 02 Aug 2009 20:27:00 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249244820.74.0.753406837054.issue6626@psf.upfronthosting.co.za>


Jacob Rus <jacobolus at gmail.com> added the comment:

A fixed version of the patch from msg91200, 2009-08-02 20:08

----------
Added file: http://bugs.python.org/file14631/mimetypes2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:43:48 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sun, 02 Aug 2009 20:43:48 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249245828.13.0.605895609332.issue6626@psf.upfronthosting.co.za>


Jacob Rus <jacobolus at gmail.com> added the comment:

This version (#4) switches to expressing the default types as a list of 
tuples instead of as a dict, so that we can include duplicate rows so that 
"reverse" type -> extension lookups will behave properly, once we start 
changing the actual content of the defaults.

The types_map and common_types dictionaries (aliases to the singleton 
MimeTypes object's types_map property) have been left behaving as before 
for backwards compatibility.

The tests still pass.

----------
Added file: http://bugs.python.org/file14632/mimetypes4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sun Aug  2 22:54:11 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 02 Aug 2009 20:54:11 +0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1249246451.28.0.408356695231.issue2053@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I thought the main point of this issue was to define standard functions,
methods, classes (or something in that sense), in order to make the
creation of tk dialogs uniform across IDLE.

Right now it seems reasonable to keep the parent hidden, but I think it
may not help much for maintaining. I really consider a good idea to
define explicitly who is the parent of a dialog, it wasn't an attempt to
refer to the phrase you cited.

I trust you it reduces the size on that file, I really didn't count how
many lines were removed and how many were added, but these dialogs can
be used anywhere around IDLE so I don't see why keeping them inside
EditorWindow is a good idea. It would reduce even more (some few lines)
EditorWindow's size doing so, and it would make more sense as I see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
_______________________________________

From report at bugs.python.org  Sun Aug  2 23:44:28 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Aug 2009 21:44:28 +0000
Subject: [issue6616] PyList_APPEND (append without incref)
In-Reply-To: <1249159427.67.0.400493436196.issue6616@psf.upfronthosting.co.za>
Message-ID: <1249249468.62.0.92931833838.issue6616@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> I know the API well enough (with manipulating dicts/lists etc) 
> and I still want this function for the sake of convenience.

Given that your level of skill is higher than the average user,
I recommend adding this to your own standard libraries or headers.
No need to muck-up the environment for everyone else.

----------
assignee:  -> rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6616>
_______________________________________

From report at bugs.python.org  Sun Aug  2 23:52:44 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sun, 02 Aug 2009 21:52:44 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249249964.7.0.434792884046.issue6626@psf.upfronthosting.co.za>


Jacob Rus <jacobolus at gmail.com> added the comment:

Here is a list I generated of all the current Apache mime.types:

I would just as soon include this in the python standard library, either 
just the Apache file as is, or even these python object literals (maybe 
in a file outside of mimetypes.py), and then *not* import from Apache 
files by default, to cut down on external dependencies. There are 
several alternate MIME types for various types that should be added to 
this list (in earlier positions so they only are used in the type -> 
extension map).

The only issue is that some users may have added to their Apache 
mime.types files for the sake of getting mailman or other python 
programs to do what they want. So I'm not entirely sure to what extent 
we should be 100% backwards compatible in such edge cases. 

My personal opinion is that the 'strict' option is unnecessary and 
should be set to do nothing, because users are more likely to want the 
predictable behavior where an unorthodox type gives back the proper 
extension, than the behavior where their code fails unless they pass a 
flag in: I don't see any reason for a user to want a 'type doesn't 
exist' message back for non-registered types. This isn't a "test for 
IANA registration" module.

----------
Added file: http://bugs.python.org/file14633/apache_mimetypes.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Mon Aug  3 00:05:08 2009
From: report at bugs.python.org (Rhett Garber)
Date: Sun, 02 Aug 2009 22:05:08 +0000
Subject: [issue1628205] socket.readline() interface doesn't handle EINTR
	properly
Message-ID: <1249250708.77.0.000418409257115.issue1628205@psf.upfronthosting.co.za>


Rhett Garber <rhettg at gmail.com> added the comment:

I've hit this issue as well.
Attached is an updated patch to 2.6 branch and a test case.
I wrote up more details here:
http://nullhole.com/2009/08/02/anatomy-of-a-regression-test/

----------
nosy: +rhettg
Added file: http://bugs.python.org/file14634/diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628205>
_______________________________________

From report at bugs.python.org  Mon Aug  3 01:15:46 2009
From: report at bugs.python.org (brian)
Date: Sun, 02 Aug 2009 23:15:46 +0000
Subject: [issue6628] IDLE freezes after encountering a syntax error
In-Reply-To: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>
Message-ID: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>


New submission from brian <omniscient.brian at gmail.com>:

Running Python 3.1/ IDLE, which was installed on top of a Python 2.5.4
install, Mac OSX 10.4

This seems like such an obvious bug, but I can't find it in the current
list of issues - so I suspect that it may not be reproducible on other
computers, but it's certainly reproducible on my laptop.

If I run a module with (any?) syntax error (for example,

for i in range(10) #missing semicolon
    print i

the interpreter will catch it and send you to fix it. Then, any
subsequent attempts to run that same module will freeze IDLE. The
problem doesn't occur if you run a different module.

----------
components: IDLE
messages: 91210
nosy: brian89
severity: normal
status: open
title: IDLE freezes after encountering a syntax error
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6628>
_______________________________________

From report at bugs.python.org  Mon Aug  3 05:20:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 03 Aug 2009 03:20:50 +0000
Subject: [issue4652] IDLE does not work with Unicode
In-Reply-To: <1229154229.3.0.726059762082.issue4652@psf.upfronthosting.co.za>
Message-ID: <1249269650.02.0.165849798055.issue4652@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I can't seem to reproduce that, maybe it could be a tk issue ?

Can you try writing anything (that doesn't work on IDLE) on a
tkinter.Text widget to see if it shows there ? You could use this code
below:

from tkinter import Text

text = Text()
print(text.tk.call('info', 'patchlevel'))
text.focus_set()
text.pack()
text.mainloop()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4652>
_______________________________________

From report at bugs.python.org  Mon Aug  3 14:19:55 2009
From: report at bugs.python.org (Nir Soffer)
Date: Mon, 03 Aug 2009 12:19:55 +0000
Subject: [issue6550] asyncore incorrect failure when connection is refused and
	using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1249301995.86.0.0156921921481.issue6550@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

handle_expt is documented to be called when there is OOB data. However,
handle_expt_event is not documented, and according the framework design
as I see it, it simply means "socket has exceptional condition" when
select returns. On unix, this means there is oob data, and on Windows,
it means "there is some error".

This works exactly the same for handle_read_event and handle_write_event
- they may be called on connection refused error. Checking for errors in
handle_expt_event is the right thing to do, and allow you to avoid the
ugly checks and double try..except in _exception.

If you want handle_foo_event to be called only on foo events, then they
will not have anything to do except calling handle_foo. This is actually
the case now in handle_expt_event. I don't see any advantage of this
design change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________

From report at bugs.python.org  Mon Aug  3 05:27:51 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 03 Aug 2009 03:27:51 +0000
Subject: [issue4691] IDLE Code Caching Windows
In-Reply-To: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za>
Message-ID: <1249270071.85.0.436349028862.issue4691@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Amaury, from what I remember your suggestion has been applied some time
ago. Can you check if the newest Windows installer still adds an '-n' by
default ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4691>
_______________________________________

From report at bugs.python.org  Mon Aug  3 08:47:41 2009
From: report at bugs.python.org (Javier)
Date: Mon, 03 Aug 2009 06:47:41 +0000
Subject: [issue6630] string.Template custom pattern not working
In-Reply-To: <1249282061.67.0.26692722483.issue6630@psf.upfronthosting.co.za>
Message-ID: <1249282061.67.0.26692722483.issue6630@psf.upfronthosting.co.za>


New submission from Javier <javier.collado at gmail.com>:

In the string.Template documentation
(http://docs.python.org/library/string.html) it's explained that if a
custom regular expression for pattern substitution is needed, it's
possible to override idpattern class attribute (whose default value is
[_a-z][_a-z0-9]*).

However, if the custom pattern that is needed is just uppercase
letters, something like [A-Z]+ won't work because of the following line
in the _TemplateMetaclass class __init__ method:
cls.pattern = _re.compile(pattern, _re.IGNORECASE | _re.VERBOSE)

I would say that this is an error (IGNORECASE just shouldn't be there)
and that the line above should be:
cls.pattern = _re.compile(pattern, _re.VERBOSE)
and the default value for idpattern:
[_a-zA-Z][_a-zA-Z0-9]*

Do you agree on this? Is there any reason for the IGNORECASE option to
be passed to re.compile?

----------
components: IO, Regular Expressions
messages: 91217
nosy: jcollado
severity: normal
status: open
title: string.Template custom pattern not working
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6630>
_______________________________________

From report at bugs.python.org  Mon Aug  3 09:47:32 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Aug 2009 07:47:32 +0000
Subject: [issue6609] zipfile: WindowsError [267] The directory name is invalid
In-Reply-To: <1248999170.31.0.424602339152.issue6609@psf.upfronthosting.co.za>
Message-ID: <1249285652.21.0.163317485214.issue6609@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #481171.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6609>
_______________________________________

From report at bugs.python.org  Mon Aug  3 09:59:23 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 03 Aug 2009 07:59:23 +0000
Subject: [issue6589] smtpd.SMTPServer can cause asyncore.loop to enter
	infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1249286363.3.0.660886348667.issue6589@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________

From report at bugs.python.org  Mon Aug  3 15:33:03 2009
From: report at bugs.python.org (albert Mietus)
Date: Mon, 03 Aug 2009 13:33:03 +0000
Subject: [issue6631] urlparse.urlunsplit() can't handle relative files (for
	urllib*.open()
In-Reply-To: <1249306383.87.0.829314243328.issue6631@psf.upfronthosting.co.za>
Message-ID: <1249306383.87.0.829314243328.issue6631@psf.upfronthosting.co.za>


New submission from albert Mietus <albert at mietus.nl>:

The functions urlparse.url{,un}split() and urllib{,2}.open() do not work 
together for relative, local files, due a bug in urlunsplit.

Given a file f='./rel/path/to/file.html' it can be open directly by 
urllib.open(f), but not in urllib2! as the later needs a scheme.
We can create a sound url with spilt/unspilt and a default scheme:
f2=urlparse.urlunsplit(urlparse.urlsplit(f,'file')); which works most 
cases, HOWEVER a bogus netloc is added for relative filepaths.

If have isolated this  "buggy" function, added some local testcode and 
made patch/workaround in my file 'unsplit.py' Which is included. Hope 
this will contribute to a real patch.


--Groetjes, Albert

ALbert Mietus
                                                Don't send spam mail!
Mijn missie: http://SoftwareBeterMaken.nl      product, proces & imago.
Mijn leven in het kort:        
http://albert.mietus.nl/Doc/CV_ALbert.html

----------
components: Library (Lib)
files: unsplit.py
messages: 91222
nosy: albert
severity: normal
status: open
title: urlparse.urlunsplit() can't handle relative files (for urllib*.open()
type: performance
Added file: http://bugs.python.org/file14637/unsplit.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6631>
_______________________________________

From report at bugs.python.org  Mon Aug  3 07:53:03 2009
From: report at bugs.python.org (Brandon Dixon)
Date: Mon, 03 Aug 2009 05:53:03 +0000
Subject: [issue4691] IDLE Code Caching Windows
In-Reply-To: <1249270071.85.0.436349028862.issue4691@psf.upfronthosting.co.za>
Message-ID: <22e7e1600908022252ra6ae44u8c1cf6d827d025a0@mail.gmail.com>


Brandon Dixon <brandon.s.dixon at gmail.com> added the comment:

Can you guys let me know when this is fixed or thought to be fixed. I would
like to test from my end just to ensure.

On Sun, Aug 2, 2009 at 11:27 PM, Guilherme Polo <report at bugs.python.org>wrote:

>
> Guilherme Polo <ggpolo at gmail.com> added the comment:
>
> Amaury, from what I remember your suggestion has been applied some time
> ago. Can you check if the newest Windows installer still adds an '-n' by
> default ?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4691>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14636/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4691>
_______________________________________
-------------- next part --------------
Can you guys let me know when this is fixed or thought to be fixed. I would like to test from my end just to ensure. <br><br><div class="gmail_quote">On Sun, Aug 2, 2009 at 11:27 PM, Guilherme Polo <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Guilherme Polo &lt;<a href="mailto:ggpolo at gmail.com">ggpolo at gmail.com</a>&gt; added the comment:<br>
<br>
Amaury, from what I remember your suggestion has been applied some time<br>
ago. Can you check if the newest Windows installer still adds an &#39;-n&#39; by<br>
default ?<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue4691" target="_blank">http://bugs.python.org/issue4691</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Brandon Dixon - CCNA, OSCP, WebSphere DataPower Solution Developer<br>Information Systems Security Engineer<br><a href="http://www.dueyesterday.net">www.dueyesterday.net</a> - Documentation for the masses<br>



From report at bugs.python.org  Mon Aug  3 17:44:38 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 03 Aug 2009 15:44:38 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1222041136.39.0.521824941747.issue3926@psf.upfronthosting.co.za>
Message-ID: <1249314278.51.0.948768869161.issue3926@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This looks good Scott, I'm just attaching the .diff here with real minor
changes and will be applying if no one is against it.

----------
keywords: +patch
Added file: http://bugs.python.org/file14638/idle_fixwarnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Mon Aug  3 04:34:51 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 03 Aug 2009 02:34:51 +0000
Subject: [issue1175686] add "reload" function to IDLE
Message-ID: <1249266891.44.0.830666203164.issue1175686@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Closing this in favour of issue1721083.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Add File - Reload

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1175686>
_______________________________________

From report at bugs.python.org  Mon Aug  3 04:55:00 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 03 Aug 2009 02:55:00 +0000
Subject: [issue1721083] Add File - Reload
Message-ID: <1249268100.63.0.294710380904.issue1721083@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I have done a very initial patch in an attempt to define where we should
go with this feature. There are several different proposals around this
issue and the superseded one, I opted to implement the simplest one
which is to add a 'Revert' entry in the file menu which re-reads the
file currently open.

There are at least two problems with this patch. First, I don't think
there is a non-hacky way to place a command on a menu in a specific
place by using an idle extension, so, the 'Revert' entry is the last
entry in the file menu right now. I guess this would be solved by not
making this an extension and then proceed to manually remove the menu
entry while creating the shell window (similarly to what it is done when
running under mac osx). The second problem happens when reverting the
file, I'm not sure if it should be done differently but this seems to
cause some problem with Multicall.

----------
keywords: +patch
Added file: http://bugs.python.org/file14635/idle_filerevert.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721083>
_______________________________________

From report at bugs.python.org  Mon Aug  3 09:06:24 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 03 Aug 2009 07:06:24 +0000
Subject: [issue6570] Tutorial clarity: section 4.7.2, parameters and arguments
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1249283184.26.0.343664010848.issue6570@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I'll try to rephrase the section.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________

From report at bugs.python.org  Mon Aug  3 09:36:28 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 03 Aug 2009 07:36:28 +0000
Subject: [issue6609] zipfile: WindowsError [267] The directory name is invalid
In-Reply-To: <1248999170.31.0.424602339152.issue6609@psf.upfronthosting.co.za>
Message-ID: <1249284988.61.0.375528118873.issue6609@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

You're right, "aux" is a reserved name on Windows (like prn, con, and a 
few others). There is a way to force the OS to actually create such 
files, but not every tool can handle them correctly.

If the zip file is intended to be Windows-compatible, it should not use 
such names; ask the project developers.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6609>
_______________________________________

From report at bugs.python.org  Mon Aug  3 04:00:41 2009
From: report at bugs.python.org (Karoly Lorentey)
Date: Mon, 03 Aug 2009 02:00:41 +0000
Subject: [issue6629] seek doesn't properly handle file buffer,
	leads to silent data corruption
In-Reply-To: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>
Message-ID: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>


New submission from Karoly Lorentey <karoly at lorentey.hu>:

The new io.BufferedRandom implementation in Python 3.1 has a broken seek 
that seems not to properly handle the case when the target of the seek 
lies inside the contents of the file buffer.  It leaves the file object 
in a confused state, such that the next write operation applies after 
the end of the buffer(!) instead of the specified target.

I could reproduce the following symptoms on both Debian Lenny and Mac OS 
X Leopard.  I downloaded the Python 3.1 tarball from python.org, and 
built it by hand using './configure && make'.

$ ./python.exe
Python 3.1 (r31:73572, Aug  3 2009, 02:32:10) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> open("test", "wb").write(b"A" * 10000)
10000
>>> file = open("test", "rb+")
>>> file.read(10)       # Reads 4096 bytes into file buffer
b'AAAAAAAAAA'
>>> file.tell()
10
>>> file.seek(0)
0
>>> file.tell()
0
>>> file.write(b"B" * 10000)  # This should overwrite the whole file
10000
>>> file.tell()
14096  # Hmm, 0 + 10000 == 14096?
>>> file.close()
>>> d = open("test", "rb").read()
>>> len(d)
14096  # ?!
>>> d[0:10]      # The file should now consist of 10000 Bs...
b'AAAAAAAAAA'
>>> d[4090:4100]
b'AAAAAABBBB'    # ... but the Bs only start after a buffer's worth of 
As.

This bug has actually caused me some subtle, silent data corruption that 
went undetected for quite a while.  Hurray for backups!

The above code works fine in Python 3.0, and its Python 2.5 port also 
produces correct results.

A workaround for 3.1 is to call flush before every seek.

----------
components: IO
messages: 91211
nosy: lorentey
severity: normal
status: open
title: seek doesn't properly handle file buffer, leads to silent data corruption
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6629>
_______________________________________

From report at bugs.python.org  Mon Aug  3 18:34:04 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Aug 2009 16:34:04 +0000
Subject: [issue6630] string.Template custom pattern not working
In-Reply-To: <1249282061.67.0.26692722483.issue6630@psf.upfronthosting.co.za>
Message-ID: <1249317244.36.0.757226091085.issue6630@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Better to add a flags argument and leave the default flag as-is.

----------
assignee:  -> barry
components: +Library (Lib) -IO, Regular Expressions
nosy: +barry, rhettinger
type: behavior -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6630>
_______________________________________

From report at bugs.python.org  Mon Aug  3 18:34:45 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Aug 2009 16:34:45 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The decimal codec only handles characters in the Nd (Number, decimal)
Unicode category and whitespaces [a]. It is used by int(), float(),
complex() and indirectly by Decimal(), Fraction() and possibly others.
This works well only for plain digits (e.g. int(u'???')) but it
doesn't work for all the other characters used to represent numbers, like:
1. plus or minus sign, e.g. int(u'????') or int(u'????')
2. decimal point, e.g. float(u'????')
   2.1 some languages/alphabets use other chars (e.g. a comma or other
       symbols) instead of the decimal point.
3. exponential notation, e.g. float(u'???')
4. the 'j' in complex numbers, e.g. complex(u'??')
5. the 'x' and 'p' in hexadecimal floats, e.g.
float.fromhex(u'???????')
   5.1 hex floats also uses hexadecimal digits, see 6.3
6. digits > 9 for numbers with a base > 10, e.g. int(u'??', 16)
    6.1 not all the alphabets have the equivalent of the letters a-z
    6.2 afaik there are no standards that specify how to deal with
        digits >9
    6.3 in the Unicode FAQ [b] there's a link to a table [c] that says
        "Code points not listed in this file are not hexadecimal
        digits." This is not a standard though, and even if in the
        UCD [d] there's a file [e] where the numbers with the Hex_Digit
        property are defined, it doesn't say that *only* these numbers
        are valid hex digits. Also it doesn't say anything about
        different bases.
        Python currently accepts int(u'??', 16), int(u'?', 16)
        (U+096D - DEVANAGARI DIGIT SEVEN) and even int(u'?F', 16)
        (with a normal F it works, with a fullwidth ? it fails).
    6.4 UTS #18 [f] includes in the property 'xdigit' [g] (hexadecimal
        digit) all the chars defined in [c] and also all the chars with
        a Nd category. This also is not a standard, and it doesn't
        give indications about the valid hex digits and how int()
        should behave.
    6.5 if possible re and int() should agree. Any string that matches
        /^[[:xdigit:]]+$/ should work fine with int(s, 16) and vice 
        versa. See also #6561 [h] and #2636 [i].
7. possibly others


For all the chars listed in the points 1-5 there's no way, AFAIK, to
know their equivalents in other alphabets (if they exist at all) and
since (apparently) there's no standard that specifies how to handle
them, they should be kept out.
This will also avoid a number of problems, e.g. 2.1.

The fullwidth forms are an exception though: they seem to be the only
set of characters with a direct equivalent for all these chars, and they
are also the only non-ascii chars included in the list of chars with the
Unicode Hex_Digits property.

Including all the necessary chars from this range in the decimal codec
seems to me the best thing to do. The chars listed in the points 1-5
should all be implemented and they should work everywhere. The regex
used by Decimal/Fraction should be updated as well, since the decimal
codec is not accessible from Python (maybe it should be accessible, but
this is another issue).

Point 6 is a slightly different issue, even if it can be partially
solved if the fullwidth forms will be included. One of the possible
options is to limit the valid chars used by int() with bases > 10 only
to the characters listed in [c], but this won't be backward-compatible
with existing code and forward-compatible with [[:xdigit:]].
OTOH if we keep the current behavior it will be possible to express the
digits from 0 to 9 using several alphabets, but all the digits > 9 will
be limited to [a-fA-F] (and possibly [??????]).
For example, '7F' in the devanagari alphabet will result in a mix of
devanagari numbers and ascii letters, i.e. int(u'?F', 16) (this already
works in Python).


[a]:
http://svn.python.org/view/python/trunk/Objects/unicodeobject.c?view=markup
under 'Decimal Encoder'
[b]: http://unicode.org/faq/casemap_charprop.html#13
[c]: http://unicode.org/faq/hex-digit-values.txt - [0-9a-fA-
F?????????]
[d]: http://unicode.org/Public/UNIDATA/UCD.html#UCD_Files - PropList.txt
section
[e]: http://unicode.org/Public/UNIDATA/PropList.txt
[f]: http://unicode.org/reports/tr18/ - UTS #18: Unicode Regular Expressions
[g]: http://unicode.org/reports/tr18/#Compatibility_Properties - xdigit row
[h]: http://bugs.python.org/issue6561#msg90878 point (1) about int() and re
[i]: http://bugs.python.org/issue2636#msg65513 point 8) will introduce
[[:xdigit:]]

(Thanks to Mark Dickinson and Adam Olsen for pointing out some of these
issues.)

----------
components: Interpreter Core, Unicode
messages: 91225
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: Include more fullwidth chars in the decimal codec
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Mon Aug  3 18:35:22 2009
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 03 Aug 2009 16:35:22 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1249317322.99.0.630342102249.issue6596@psf.upfronthosting.co.za>


Francesco Del Degan <f.deldegan at ngi.it> added the comment:

I don't think that this is a python issue, because of this:

[root at localhost ~]# curl -O http://wm.exchanger.ru/asp/XMLWMList.asp?exchtype=1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
[root at localhost ~]# curl -O http://wm.exchanger.ru/asp/XMLWMList.asp?exchtype=1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9299  100  9299    0     0  15471      0 --:--:-- --:--:-- --:--:-- 22134


I done two request in rapid succession and into first i got a redirect to

	0x0000:  4500 008f 3abb 0000 3206 1d98 d49e ad94  E...:...2.......
	0x0010:  ac10 01d3 0050 b220 47ee 6cdb 8b3d 6233  .....P..G.l..=b3
	0x0020:  5011 0001 edc2 0000 4854 5450 2f31 2e31  P.......HTTP/1.1
	0x0030:  2033 3032 204d 6f76 6564 2054 656d 706f  .302.Moved.Tempo
	0x0040:  7261 7269 6c79 0d0a 436f 6e74 656e 742d  rarily..Content-
	0x0050:  4c65 6e67 7468 3a20 300d 0a4c 6f63 6174  Length:.0..Locat
	0x0060:  696f 6e3a 202f 6173 702f 584d 4c57 4d4c  ion:./asp/XMLWML
	0x0070:  6973 742e 6173 703f 6578 6368 7479 7065  ist.asp?exchtype
	0x0080:  3d31 3f34 6430 3266 3136 380d 0a0d 0a    =1?4d02f168....

as you can see, the ?4d02f168 part comes from the site, hence the 500 error from second request.

In the second try, i got correct response.

The weird thing is that into other systems, no curl request triggers a redirect from the site,
and in centOS only we have this weird behaviour.

----------
nosy: +pr0gg3d

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Mon Aug  3 18:36:02 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 03 Aug 2009 16:36:02 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249317362.13.0.128453209496.issue6632@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +lemburg, loewis, marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Mon Aug  3 18:38:55 2009
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 03 Aug 2009 16:38:55 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1249317535.38.0.775948399914.issue6596@psf.upfronthosting.co.za>


Francesco Del Degan <f.deldegan at ngi.it> added the comment:

Update: Now into the same system (CentOS) without any mod:

>>> import urllib2
>>> url = 'http://wm.exchanger.ru/asp/XMLWMList.asp?exchtype=1'
>>> t = urllib2.urlopen(url).read()
>>>
>>> t
'<?xml version="1.0"?>.........

i thinks that you should try to look for some bugs into CentOS 
distribution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Mon Aug  3 18:41:04 2009
From: report at bugs.python.org (Senthil)
Date: Mon, 03 Aug 2009 16:41:04 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1249317664.6.0.436578126247.issue6596@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Thanks for the update. I am closing this as Invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Mon Aug  3 18:51:17 2009
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 03 Aug 2009 16:51:17 +0000
Subject: [issue6557] urllib.urlopen creates bad requests when location header
	of 301 redirects contain spaces
In-Reply-To: <1248385969.73.0.0313821964129.issue6557@psf.upfronthosting.co.za>
Message-ID: <1249318277.95.0.252849461668.issue6557@psf.upfronthosting.co.za>


Francesco Del Degan <f.deldegan at ngi.it> added the comment:

urllib2 does escape spaces (and other characters too):

In [20]: 
u=urllib2.urlopen("http://sourceforge.net/project/showfiles.php?
group_id=16847&package_id=13374")

In [21]: u.url
Out[21]: 'http://sourceforge.net/projects/xmlrpc-c/files/Xmlrpc-
c%20Super%20Stable/'

In [22]: u.read()[0:100]
Out[22]: '\n\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xh'

----------
nosy: +pr0gg3d

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6557>
_______________________________________

From report at bugs.python.org  Mon Aug  3 18:58:38 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 03 Aug 2009 16:58:38 +0000
Subject: [issue6630] string.Template custom pattern not working
In-Reply-To: <1249282061.67.0.26692722483.issue6630@psf.upfronthosting.co.za>
Message-ID: <1249318718.69.0.347532154646.issue6630@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree with Raymond. I think it should either take a string and flags,
or a compiled regex object.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6630>
_______________________________________

From report at bugs.python.org  Mon Aug  3 19:02:53 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 03 Aug 2009 17:02:53 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249318973.64.0.555396001812.issue6632@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Mon Aug  3 19:04:11 2009
From: report at bugs.python.org (James)
Date: Mon, 03 Aug 2009 17:04:11 +0000
Subject: [issue6633] No handlers could be found for logger
In-Reply-To: <1249319051.14.0.476850462848.issue6633@psf.upfronthosting.co.za>
Message-ID: <1249319051.14.0.476850462848.issue6633@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

I was trying to suppress the error message as shown in the title, when I
found out (by searching through the source) that there is a NullHandler
for precisely this purpose.

http://svn.python.org/view/python/trunk/Lib/logging/__init__.py?r1=66211&r2=67511

do you think that:
1) this could be documented maybe here (
http://docs.python.org/library/logging.html#handler-objects ) i suppose?
and:
2) this null handler doesn't seem to exist in:
Python 2.5.2 (r252:60911, Oct  5 2008, 19:24:49) 
[GCC 4.3.2] on linux2
is this likely to get backported to 2.5? at the moment i've just
included the simple NullHandler class into my code.
3) also not my business really, but should it belong in the handlers.py
file?

thanks for all your hard work, i hope the comments are useful!

----------
components: Library (Lib)
messages: 91231
nosy: purpleidea
severity: normal
status: open
title: No handlers could be found for logger
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6633>
_______________________________________

From report at bugs.python.org  Mon Aug  3 19:06:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Aug 2009 17:06:58 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249319218.72.0.779910191776.issue6632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The bit that most convinces me that *some* change is desirable is that
(with py3k notation), int('?', 16) is legal but int('?', 16) is not.

In an ideal world one might hope that the set of characters accepted by 
int(s, 16) would be the same as those characters with the Unicode 
Hex_Digits property, but currently there's a mismatch for two different 
reasons... (1) fullwidth hex digits have property 'Hex_Digit' but aren't 
accepted, and (2) non-European decimal digits (e.g. Devanagari digits, 
etc.) don't have property 'Hex_Digit' but are accepted by int.

It's tempting to suggest that int and float should be modified to reject 
*any* decimal digits other than '0' through '9', and possibly their 
fullwidth variants.  (Jean-Paul Calderone already advanced this argument 
on #python-dev a few days ago;  essentially saying, if I understood him 
correctly, that dealing with localization shouldn't be part of the job 
of int or float.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Mon Aug  3 19:14:03 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 03 Aug 2009 17:14:03 +0000
Subject: [issue834351] Mouse wheel crashes program
Message-ID: <1249319643.09.0.421262952353.issue834351@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This is a tk issue, so the best way to fix this (if you don't want to
install something newer than Python 2.4 on Windows) is to install a
newer tcl/tk version.

Unfortunately the proposed workaround is way too specific, imagine if
other bindings had similar problems with different binding substitutions.

If we want to be safe, Tkinter should be passing only valid
substitutions for a given sequence but this is very awkward. But check
what the bind manual says ".. Some of the substitutions are only valid
for certain types of events; if they are used for other types of events
the value substituted is undefined.", note how it doesn't say ".. if
they are used for other types of events a segfault ensues".

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue834351>
_______________________________________

From report at bugs.python.org  Mon Aug  3 19:51:30 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 03 Aug 2009 17:51:30 +0000
Subject: [issue6618] Typo in a listing in 5.2.9 of language reference
In-Reply-To: <1249163716.22.0.790124274674.issue6618@psf.upfronthosting.co.za>
Message-ID: <1249321890.17.0.165302934413.issue6618@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74297, backported to 3.1 in r74298.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6618>
_______________________________________

From report at bugs.python.org  Mon Aug  3 20:23:08 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 03 Aug 2009 18:23:08 +0000
Subject: [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>
Message-ID: <1249323788.91.0.220608617407.issue2710@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Hi Don,

I don't think this is an issue about idle competing for tkinter
resources (or idle and tkinter competing for resources -- the other
meaning I got when reading your message).
>From what I remember this WSAEWOULDBLOCK is just a way for Windows to
tell "try to send this data again later", so this is actually related to
networking and not Tkinter vs. IDLE. If someone can confirm this then it
would be better to check for this specific error and ignore (pass) 
instead of always raising any socket.error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2710>
_______________________________________

From report at bugs.python.org  Mon Aug  3 20:33:23 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 03 Aug 2009 18:33:23 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1249324403.65.0.102918355.issue5712@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Mon Aug  3 20:43:50 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 03 Aug 2009 18:43:50 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <4A772FE3.60106@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> New submission from Ezio Melotti <ezio.melotti at gmail.com>:
> 
> The decimal codec only handles characters in the Nd (Number, decimal)
> Unicode category and whitespaces [a]. It is used by int(), float(),
> complex() and indirectly by Decimal(), Fraction() and possibly others.
> This works well only for plain digits (e.g. int(u'???')) but it
> doesn't work for all the other characters used to represent numbers, like:
> [...]

In general, Python has always stuck to the Unicode standard
for these things (as well as others like casing, etc.).

If the Unicode standard adopts a scheme for dealing with these
issues, we should include support for it.

Implementing something based on non-standards now and breaking
that support later on in order to implement the true standards
is not such a good idea.

There is work underway to define a standard for locale specific
formatting of numbers, dates, etc.:

    http://cldr.unicode.org/

Here's the TR with the data format specification:

    http://www.unicode.org/reports/tr35/tr35-12.html

I'm sure that the information gathered in that project will
sooner or later be folded back into the standard Unicode character
database. Once that's done we can then use that information to
e.g. determine the characters that make up a sign, decimal
point, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Mon Aug  3 21:21:51 2009
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Mon, 03 Aug 2009 19:21:51 +0000
Subject: [issue6634] sys.exit() called from threads other than the main one:
	undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>


New submission from Jan-Philip Gehrcke <jgehrcke at gmail.com>:

Hey there,

hopefully I fill out this form in an adequate way!

I ran into some problems while using sys.exit('msg') together with
threads, which could have been avoided with slightly more information in
the docs here: http://docs.python.org/library/sys.html#sys.exit 

Maybe the following two statements should not stay as they are:

(1) "Exit from Python."
-----------------------
This is not true when called from a thread other than the main one. We
could add a hint, saying that sys.exit() then actually behaves like
thread.exit(), which causes only the calling thread to exit, but not the
main program.

2) "[...] and any other object is printed to sys.stderr"
--------------------------------------------------------
This is also not true when called from a thread other than the main one.
Calling sys.exit('msg') then doesn't print anything to stderr. That was
annoying in my case and required debugging a bug that would have
discovered itself via stderr, if the message would have been printed..
:-) After some research, I think this behaviour is described in the
documentation for thread.exit(): "[...] this will cause the thread to
exit *silently*."


Okay, now that I am aware of this behaviour, I won't run into these
problems again. But the next one?

I think (1) is clearly a documentation thing. Regarding (2): first of
all, the documentation should say that the message is suppressed in
special cases (child threads). But: what argues against printing to
stderr here? I don't get the point and only see a lost feature,
affording a quick way to kill a thread while dropping an error message.
Was this kicked out intentionally? Maybe someone could help me with a
good argument here :-)


Thank you for your work,

Jan-Philip Gehrcke

----------
assignee: georg.brandl
components: Documentation
messages: 91237
nosy: georg.brandl, jgehrcke
severity: normal
status: open
title: sys.exit() called from threads other than the main one: undocumented behaviour
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6634>
_______________________________________

From report at bugs.python.org  Mon Aug  3 21:52:11 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 03 Aug 2009 19:52:11 +0000
Subject: [issue6630] string.Template custom pattern not working
In-Reply-To: <1249282061.67.0.26692722483.issue6630@psf.upfronthosting.co.za>
Message-ID: <1249329131.38.0.0603746522021.issue6630@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I agree w/Raymond.  string + flags

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6630>
_______________________________________

From report at bugs.python.org  Mon Aug  3 22:02:27 2009
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 03 Aug 2009 20:02:27 +0000
Subject: [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1249329747.65.0.513382828891.issue6596@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

10x for closing. It seems to me python is not mature as http client.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________

From report at bugs.python.org  Mon Aug  3 22:32:41 2009
From: report at bugs.python.org (Francesco Del Degan)
Date: Mon, 03 Aug 2009 20:32:41 +0000
Subject: [issue6635] Profiler doesn't print usage (indexError instead)
In-Reply-To: <1249331560.84.0.146355793731.issue6635@psf.upfronthosting.co.za>
Message-ID: <1249331560.84.0.146355793731.issue6635@psf.upfronthosting.co.za>


New submission from Francesco Del Degan <f.deldegan at ngi.it>:

$ python -m profile
Usage: profile.py [-o output_file_path] [-s sort] scriptfile [arg] ...

$ python -m profile -s calls
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/profile.py", line 619, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/profile.py", line 614, in main
    parser.print_usage()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1584, in print_usage
    print >>file, self.get_usage()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1570, in get_usage
    self.expand_prog_name(self.usage))
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1547, in expand_prog_name
    return s.replace("%prog", self.get_prog_name())
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/optparse.py", line 1542, in get_prog_name
    return os.path.basename(sys.argv[0])
IndexError: list index out of range


This is triggered by an early override of sys.argv when usage() is called (Lib/profile.py:603):

    if not sys.argv[1:]:
        parser.print_usage()
        sys.exit(2)

    (options, args) = parser.parse_args()
    sys.argv[:] = args

    if (len(sys.argv) > 0):
        sys.path.insert(0, os.path.dirname(sys.argv[0]))
        run('execfile(%r)' % (sys.argv[0],), options.outfile, options.sort)
    else:
        parser.print_usage()
    return parser




In the "else" branch it tries to print usage but sys.argv[] were already overwritten.

Attached is the proposed patch (tested with 2.5, 2.6, 3.1).

----------
components: Library (Lib)
files: python-profile-sysargv.patch
keywords: patch
messages: 91240
nosy: pr0gg3d
severity: normal
status: open
title: Profiler doesn't print usage (indexError instead)
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14639/python-profile-sysargv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6635>
_______________________________________

From report at bugs.python.org  Mon Aug  3 22:36:13 2009
From: report at bugs.python.org (Charles Mason)
Date: Mon, 03 Aug 2009 20:36:13 +0000
Subject: [issue6636] Non-existant directory in sys.path prevents further
	imports
In-Reply-To: <1249331773.17.0.57338899812.issue6636@psf.upfronthosting.co.za>
Message-ID: <1249331773.17.0.57338899812.issue6636@psf.upfronthosting.co.za>


New submission from Charles Mason <cemasoniv at gmail.com>:

Steps to reproduce:

1) Add to sys.path a path that does not exist
2) Import a module, any module.  This invokes get_path_importer over
every element of sys.path.  The NullImporter __init__ method is called
and an instance created for each non-existing path element in sys.path.
3) Create the path and put a valid module in said path
4) Try to import that module.

Behavior is that the interpreter fails to import.  This behavior seems
local to import.c only.

Attached a test case that shows "failed" for 2.5, 2.6, 3.0. 3.1rc1+.  I
have yet to test on the trunk but I can/will do that if necessary.

I believe I can fix this myself but I want to verify this is incorrect
behavior (a bug) and not an "Undocumented Feature" (or hell, maybe it
*is* documented somewhere).  I've skimmed over PEP 302 and didn't see
any relevant information.

If someone gives me the go ahead (or at least doesn't give me reason not
to), I'll get a patch put together, perhaps for several different "fixes".

----------
components: Interpreter Core
files: test.py
messages: 91241
nosy: cemasoniv
severity: normal
status: open
title: Non-existant directory in sys.path prevents further imports
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14640/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6636>
_______________________________________

From report at bugs.python.org  Mon Aug  3 23:25:53 2009
From: report at bugs.python.org (Tom Clarke)
Date: Mon, 03 Aug 2009 21:25:53 +0000
Subject: [issue6637] non-empty defaultdict .copy() fails returning empty dict
In-Reply-To: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>
Message-ID: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>


New submission from Tom Clarke <t.clarke at ic.ac.uk>:

The enclosed script when run under 2.6.2 IDLE standard distribution on
x86 shows that shallow copy (.copy()) of a non-empty defaultdict object
returns an empty defaultdict!

Other ways to copy, e.g. defaultdict(none, d.items()), work fine.

Bug appears under:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32

I have tested it on two different computers. They both also have the
visual installed from a v2.6 binary - but I can't see why this would
change standard libraries.

Hope I am not being stupid - this seems to big a bug to be real!

**Documentation on defaultdict states (nearly all) methods are same as
dict, and on dict defines copy() as returning a shallow copy.

**replace defaultdict by dict and this example works as expected

Best wishes, Tom

PS - I am new to python so forgive any stupidity!

----------
components: Library (Lib)
messages: 91242
nosy: tomcl
severity: normal
status: open
title: non-empty defaultdict .copy()  fails returning empty dict
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6637>
_______________________________________

From report at bugs.python.org  Mon Aug  3 23:29:27 2009
From: report at bugs.python.org (Tom Clarke)
Date: Mon, 03 Aug 2009 21:29:27 +0000
Subject: [issue6637] non-empty defaultdict .copy() fails returning empty dict
In-Reply-To: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>
Message-ID: <1249334967.76.0.304047726632.issue6637@psf.upfronthosting.co.za>


Changes by Tom Clarke <t.clarke at ic.ac.uk>:


Added file: http://bugs.python.org/file14641/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6637>
_______________________________________

From report at bugs.python.org  Mon Aug  3 23:59:33 2009
From: report at bugs.python.org (Ian Beaver)
Date: Mon, 03 Aug 2009 21:59:33 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1249336773.45.0.48918875378.issue1230540@psf.upfronthosting.co.za>


Ian Beaver <undercoveridiot at gmail.com> added the comment:

I found that the workaround suggested doesn't work when you have a
subclass of threading.Thread and you want to catch everything in the
module that contains the class to a common log.

Say you have a module with a socket server that spawns a thread on
accept and you want to log anything that tracebacks in the module. This
seems to work:

import sys
import logging
from functools import wraps

def myExceptHook(type, value, tb):
    """ Redirect tracebacks to error log """
    import traceback
    rawreport = traceback.format_exception(type, value, tb)
    report = '\n'.join(rawreport)
    log.error(report)

sys.excepthook = myExceptHook
    
def use_my_excepthook(view):
    """ Redirect any unexpected tracebacks """ 
    @wraps(view)
    def run(*args, **kwargs):
        try:
            return view(*args, **kwargs)
        except:
            sys.excepthook(*sys.exc_info())
    return run


Then in your thread subclass:


class MyThread(threading.Thread):
    def __init__(self, socket_conn):
        threading.Thread.__init__(self)
        self.my_conn = socket_conn

    @use_my_excepthook
    def run(self):
        """ Do stuff """

----------
nosy: +undercoveridiot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Tue Aug  4 00:24:05 2009
From: report at bugs.python.org (Ian Beaver)
Date: Mon, 03 Aug 2009 22:24:05 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1249338245.17.0.425430573854.issue1230540@psf.upfronthosting.co.za>


Ian Beaver <undercoveridiot at gmail.com> added the comment:

Instead of using decorators, this is a slightly simpler modification to
the proposed workaround that allows for any subclassed run method to
also be caught.


def installThreadExcepthook():
    """
    Workaround for sys.excepthook thread bug
    From
http://spyced.blogspot.com/2007/06/workaround-for-sysexcepthook-bug.html
   
(https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1230540&group_id=5470).
    Call once from __main__ before creating any threads.
    If using psyco, call psyco.cannotcompile(threading.Thread.run)
    since this replaces a new-style class method.
    """
    init_old = threading.Thread.__init__
    def init(self, *args, **kwargs):
        init_old(self, *args, **kwargs)
        run_old = self.run
        def run_with_except_hook(*args, **kw):
            try:
                run_old(*args, **kw)
            except (KeyboardInterrupt, SystemExit):
                raise
            except:
                sys.excepthook(*sys.exc_info())
        self.run = run_with_except_hook
    threading.Thread.__init__ = init

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Tue Aug  4 00:36:35 2009
From: report at bugs.python.org (John Machin)
Date: Mon, 03 Aug 2009 22:36:35 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249338995.73.0.429285017679.issue2636@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Problem is memory leak from repeated calls of e.g.
compiled_pattern.search(some_text). Task Manager performance panel shows
increasing memory usage with regex but not with re. It appears to be
cumulative i.e. changing to another pattern or text doesn't release memory.

Environment: Python 2.6.2, Windows XP SP3, latest (29 July) regex zip file.

Example:

8<-- regex_timer.py
import sys
import time
if sys.platform == 'win32':
    timer = time.clock
else:
    timer = time.time
module = __import__(sys.argv[1])
count = int(sys.argv[2])
pattern = sys.argv[3]
expected = sys.argv[4]
text = 80 * '~' + 'qwerty'
rx = module.compile(pattern)
t0 = timer()
for i in xrange(count):
    assert rx.search(text).group(0) == expected
t1 = timer()
print "%d iterations in %.6f seconds" % (count, t1 - t0)
8<---

Here are the results of running this (plus observed difference between
peak memory usage and base memory usage):

dos-prompt>\python26\python regex_timer.py regex 1000000 "~" "~"
1000000 iterations in 3.811500 seconds [60 Mb]

dos-prompt>\python26\python regex_timer.py regex 2000000 "~" "~"
2000000 iterations in 7.581335 seconds [128 Mb]

dos-prompt>\python26\python regex_timer.py re 2000000 "~" "~"
2000000 iterations in 2.549738 seconds [3 Mb]

This happens on a variety of patterns: "w", "wert", "[a-z]+", "[a-z]+t",
...

----------
nosy: +sjmachin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Aug  4 00:51:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Aug 2009 22:51:28 +0000
Subject: [issue6629] seek doesn't properly handle file buffer,
	leads to silent data corruption
In-Reply-To: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>
Message-ID: <1249339888.65.0.0182458596954.issue6629@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'll look into this as soon as possible.

----------
assignee:  -> pitrou
nosy: +pitrou
priority:  -> critical
stage:  -> needs patch
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6629>
_______________________________________

From report at bugs.python.org  Tue Aug  4 02:02:24 2009
From: report at bugs.python.org (Kevin Quick)
Date: Tue, 04 Aug 2009 00:02:24 +0000
Subject: [issue6638] optparse parse_args argument references wrong
In-Reply-To: <1249344144.51.0.386987314322.issue6638@psf.upfronthosting.co.za>
Message-ID: <1249344144.51.0.386987314322.issue6638@psf.upfronthosting.co.za>


New submission from Kevin Quick <kq1quick at gmail.com>:

In optparse description of "16.4.3.7. Parsing arguments" (http://
docs.python.org/library/optparse.html#parsing-arguments) the keyword 
argument to parse_args is "values=None" but in the description of the 
"options" return value and in the second sentence of the "Most common 
usage..." paragraph following, it is referred to as the "options" 
argument.

----------
assignee: georg.brandl
components: Documentation
messages: 91247
nosy: georg.brandl, kq1quick
severity: normal
status: open
title: optparse parse_args argument references wrong
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6638>
_______________________________________

From report at bugs.python.org  Tue Aug  4 02:09:25 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 00:09:25 +0000
Subject: [issue6639] turtle: _tkinter.TclError: invalid command name
	".10170160"
In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>
Message-ID: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I tried the following turtle program; it was taking some time to 
draw .. so I pressed C-c after which I saw the exception traceback.

> cat play.py 
from turtle import *

def f(length, depth):
   if depth == 0:
     forward(length)
   else:
     f(length/3, depth-1)
     right(60)
     f(length/3, depth-1)
     left(120)
     f(length/3, depth-1)
     right(60)
     f(length/3, depth-1)

f(500, 4)

> python play.py
Traceback (most recent call last):
  File "/Users/sridharr/as/pypm/bin/python", line 41, in <module>
    execfile(sys.argv[0])
  File "play.py", line 15, in <module>
    f(500, 4)
  File "play.py", line 11, in f
    f(length/3, depth-1)
  File "play.py", line 7, in f
    f(length/3, depth-1)
  File "play.py", line 9, in f
    f(length/3, depth-1)
  File "play.py", line 10, in f
    left(120)
  File "<string>", line 1, in left
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 1612, in left
    self._rotate(angle)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 3107, in _rotate
    self._update()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 2562, in _update
    self._update_data()
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 2553, in _update_data
    self._pencolor, self._pensize)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/turtle.py", line 569, in _drawline
    self.cv.coords(lineitem, *cl)
  File "<string>", line 1, in coords
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
lib-tk/Tkinter.py", line 2136, in coords
    self.tk.call((self._w, 'coords') + args)))
_tkinter.TclError: invalid command name ".10170160"
>

----------
components: Library (Lib)
messages: 91248
nosy: srid
severity: normal
status: open
title: turtle: _tkinter.TclError: invalid command name ".10170160"
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6639>
_______________________________________

From report at bugs.python.org  Tue Aug  4 02:09:40 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 00:09:40 +0000
Subject: [issue6639] turtle: _tkinter.TclError: invalid command name
	".10170160"
In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>
Message-ID: <1249344580.22.0.352270865826.issue6639@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
components: +Tkinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6639>
_______________________________________

From report at bugs.python.org  Tue Aug  4 02:42:35 2009
From: report at bugs.python.org (Myk Melez)
Date: Tue, 04 Aug 2009 00:42:35 +0000
Subject: [issue6640] urlparse should parse mailto: URL headers as query
	parameters
In-Reply-To: <1249346554.96.0.279967945769.issue6640@psf.upfronthosting.co.za>
Message-ID: <1249346554.96.0.279967945769.issue6640@psf.upfronthosting.co.za>


New submission from Myk Melez <myk at mozilla.org>:

RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt> specifies mailto: URLs as
having the following syntax:

     mailtoURL  =  "mailto:" [ to ] [ headers ]
     to         =  #mailbox
     headers    =  "?" header *( "&" header )
     header     =  hname "=" hvalue
     hname      =  *urlc
     hvalue     =  *urlc

The header fields in these URLs are roughly analogous to query
parameters in other URLs, but urlparse treats them as part of the path
(along with the email address):

>>> import urlparse
>>> urlparse.urlparse("mailto:foo at example.com?subject=hi")
ParseResult(scheme='mailto', netloc='',
path='foo at example.com?subject=hi', params='', query='', fragment='')

It should treat them as query parameters instead, which would not only
make it easier to access them but would also make it easier to access
the email address, since one would no longer have to parse headers, if
any, out of the path first.

----------
components: Library (Lib)
messages: 91249
nosy: mykmelez
severity: normal
status: open
title: urlparse should parse mailto: URL headers as query parameters
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6640>
_______________________________________

From report at bugs.python.org  Tue Aug  4 03:30:20 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 04 Aug 2009 01:30:20 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249349420.94.0.157461827046.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20090804.zip is a new version of the regex module.

The memory leak has been fixed.

----------
Added file: http://bugs.python.org/file14642/issue2636-20090804.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Aug  4 06:30:57 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 04 Aug 2009 04:30:57 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1249360257.73.0.165153945675.issue6598@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This patch replaces the random part with an increasing sequence (in a 
thread safe way).
Also, added a test case for make_msgid (there was none previously)

----------
keywords: +patch
nosy: +gagenellina
Added file: http://bugs.python.org/file14643/utils.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Tue Aug  4 06:31:30 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 04 Aug 2009 04:31:30 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1249360290.75.0.246967958838.issue6598@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Added file: http://bugs.python.org/file14644/test_email.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Tue Aug  4 06:32:45 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 04 Aug 2009 04:32:45 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1249360365.78.0.782730648366.issue6598@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
versions:  -3rd party, Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Tue Aug  4 11:50:50 2009
From: report at bugs.python.org (Tom Clarke)
Date: Tue, 04 Aug 2009 09:50:50 +0000
Subject: [issue6637] non-empty defaultdict .copy() fails returning empty dict
In-Reply-To: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>
Message-ID: <1249379450.59.0.450192814076.issue6637@psf.upfronthosting.co.za>


Tom Clarke <t.clarke at ic.ac.uk> added the comment:

NB - (discussion of significance of this bug)

Defaultdict called with no argument is anomalous & this problem can be 
avoided in such cases by using dict. However this is not possible if 
default value can change and the documentation specifically defines 
behavior when called with no parameter, so this case is allowed.

Furthermore this bug is unpleasant because when the default values are 
never used it is very counterintuitive to imagine that the an error in 
the default value function could have any effect on the output.

Possible solutions:
(1) raise error in this case, change documentation (I prefer)
(2) mend behaviour in this case

Best wishes, Tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6637>
_______________________________________

From report at bugs.python.org  Tue Aug  4 13:07:57 2009
From: report at bugs.python.org (David Roberts)
Date: Tue, 04 Aug 2009 11:07:57 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1249384077.65.0.666823349915.issue6562@psf.upfronthosting.co.za>


David Roberts <d at vidr.cc> added the comment:

I think I've narrowed it down to the ImageQt class provided by PIL -
commenting out the reference to this (in the constructor of the Tile
class referenced by TileProvider.run) stops the errors.

So how do I go about determining where the problem with ImageQt lies?
(It's only ~50 lines, so there can't be too many things that could
possibly go wrong)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Tue Aug  4 13:26:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Aug 2009 11:26:56 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1249385216.88.0.467978143116.issue6562@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't know, but you should probably contact the author, Fredrik Lundh,
and/or post on the PIL list. Since it is probably not a bug in Python
itself, I'm closing the issue.
(please reopen if you discover a problem in Python itself)

----------
nosy: +effbot
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Tue Aug  4 14:04:55 2009
From: report at bugs.python.org (Fredrik Lundh)
Date: Tue, 04 Aug 2009 12:04:55 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1249387495.3.0.766274661679.issue6562@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

PIL is completely thread-agnostic, so I not sure there's anything PIL can 
do to fix this.

(and ImageQt is of course an interface to PyQt, which is an interface to 
Qt, which consists of a *lot* more than 50 lines...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Tue Aug  4 16:04:37 2009
From: report at bugs.python.org (Esteban Feldman)
Date: Tue, 04 Aug 2009 14:04:37 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>


New submission from Esteban Feldman <esteban.feldman at gmail.com>:

When trying to use datetime.strptime %z directive got an unexpected error.

>>> from datetime import datetime
>>> 
>>> fecha = u'Sun Aug 02 19:01:25 +0000 2009'
>>> datetime.strptime(fecha, '%a %b %d %H:%M:%S %z %Y')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 317, in _strptime
    (bad_directive, format))
ValueError: 'z' is a bad directive in format '%a %b %d %H:%M:%S %z %Y'

----------
components: None
messages: 91256
nosy: Eka
severity: normal
status: open
title: strptime doesn't support %z format ?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Tue Aug  4 16:39:51 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 04 Aug 2009 14:39:51 +0000
Subject: [issue3961] Arrows key do not browse in the IDLE
In-Reply-To: <1222348011.21.0.891596482298.issue3961@psf.upfronthosting.co.za>
Message-ID: <1249396791.44.0.807571845854.issue3961@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Richard, IDLE doesn't support browsing the history of the commands
entered (see issue2704), so I believe this is not related to IDLE and I
believe you meant to talk about the standard python shell.

Since you have compiled python yourself it is possible that you didn't
have the development package of readline installed (it is
libreadline5-dev on ubuntu), which would cause the problem you described
when using the standard python shell.

----------
components:  -IDLE
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3961>
_______________________________________

From report at bugs.python.org  Tue Aug  4 18:30:28 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Aug 2009 16:30:28 +0000
Subject: [issue6637] non-empty defaultdict .copy() fails returning empty dict
In-Reply-To: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>
Message-ID: <1249403428.68.0.380095995028.issue6637@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the clear report.
I'll get this fixed-up.

----------
assignee:  -> rhettinger
components: +Extension Modules -Library (Lib)
nosy: +rhettinger
priority:  -> high
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6637>
_______________________________________

From report at bugs.python.org  Tue Aug  4 19:24:28 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 04 Aug 2009 17:24:28 +0000
Subject: [issue6628] IDLE freezes after encountering a syntax error
In-Reply-To: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>
Message-ID: <1249406668.19.0.448204542437.issue6628@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I can't reproduce a hang with the python.org 3.1 IDLE on either 10.4 or 
10.5 and with the system Tcl/Tk or with a newer Active Tcl/Tk 8.4 
installed.  Do you have another version of Tcl/Tk installed in 
/Library/Frameworks?  Can you give a step-by-step procedure for 
reproducing the problem you see?

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +nad, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6628>
_______________________________________

From report at bugs.python.org  Tue Aug  4 19:47:51 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Aug 2009 17:47:51 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1249408071.0.0.732255612198.issue4832@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

With this new patch, is it possible to create a file without extension
on Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Tue Aug  4 19:56:08 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 04 Aug 2009 17:56:08 +0000
Subject: [issue4765] IDLE fails to "Delete Custom Key Set" properly
In-Reply-To: <1230525520.13.0.417394561266.issue4765@psf.upfronthosting.co.za>
Message-ID: <1249408568.54.0.730920714767.issue4765@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Interesting, this is reproducible in any version under any OS but it is
more noticeable under Windows. In the step 6 you mentioned, IDLE is busy
printing warnings that you will never see if you don't run IDLE from a
terminal. Also, when you tried restarting IDLE I believe it were
actually starting up but wasting a lot of time with this non-existing
key binding.

The problem is that when you ask to delete a custom key set, given the
steps pointed out, IDLE will first remove the custom key bindings and
then will try to remove the bindings associated with the just removed
key bindings which will generate a lot of warnings since they no longer
exist.
A simple solution is to invert some steps when "Apply" is pressed so the
bindings are removed while they still exist in the config-keys.cfg file.
But if you have a config-keys.cfg like you described below and start
IDLE, it will still take a long time to load (at least it does in a
virtual machine here).

----------
keywords: +patch
versions: +Python 3.1
Added file: http://bugs.python.org/file14645/removekeybindingswhiletheyexist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4765>
_______________________________________

From report at bugs.python.org  Tue Aug  4 19:56:47 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 04 Aug 2009 17:56:47 +0000
Subject: [issue4765] IDLE fails to "Delete Custom Key Set" properly
In-Reply-To: <1230525520.13.0.417394561266.issue4765@psf.upfronthosting.co.za>
Message-ID: <1249408607.22.0.392722972494.issue4765@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4765>
_______________________________________

From report at bugs.python.org  Tue Aug  4 20:05:53 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 04 Aug 2009 18:05:53 +0000
Subject: [issue4832] idle filename extension
In-Reply-To: <1249408071.0.0.732255612198.issue4832@psf.upfronthosting.co.za>
Message-ID: <ac2200130908041105k4a180a9fr86eb8bb050a60d1c@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> With this new patch, is it possible to create a file without extension
> on Windows?

It is tricky but, answering your question, you could enter a name
ending with a period to save without an extension.

It seems this isn't going anywhere then. The default behaviour on
Linux is to get the .py already, so this patch changes nothing there.
On Windows no extension is set by default, and with this patch it is
always .py if no extension is specified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Tue Aug  4 20:21:51 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 04 Aug 2009 18:21:51 +0000
Subject: [issue6642] returning after forking a child thread doesn't call
	Py_Finalize
In-Reply-To: <1249410110.52.0.861898541816.issue6642@psf.upfronthosting.co.za>
Message-ID: <1249410110.52.0.861898541816.issue6642@psf.upfronthosting.co.za>


New submission from Reid Kleckner <rnk at mit.edu>:

I attached a test case to reproduce.

Here is what it does:
- The main thread in the parent process starts a new thread and waits
for it.
- The child thread forks.
- The child process creates a daemon thread, and returns.
- The parent process (in the thread that forked) calls os.waitpid(childpid).

What should happen is that the forked child process should terminate
because it shouldn't wait for the daemon thread, and
os.waitpid(childpid) should return after that, and then the main thread
should return from thread.join().

What happens is that because it was a child thread that forked, the C
stack starts inside of the pthread wrapper (or equivalent) instead of
main.  So when child process returns, it doesn't know that it is now the
main thread, and it doesn't execute Py_Finalize.  Furthermore, pthreads
doesn't call sys_exit_group because it thinks that it is a lone thread
returning, and it doesn't want to terminate the entire process group. 
When you look at it with 'ps f', this is what it looks like:

24325 pts/3    Ss     0:01 bash
 4453 pts/3    Sl     0:00  \_ ./python thread_fork_hang.py
 4459 pts/3    Zl     0:07  |   \_ [python] <defunct>
 4467 pts/3    R+     0:00  \_ ps f

Here's the stack traces from the parent process:
(gdb) bt 
#0  0x00007ffff7bd0991 in sem_wait () from /lib/libpthread.so.0
#1  0x0000000000587abd in PyThread_acquire_lock (lock=0x12bb680,
waitflag=1) at ../../unladen2/Python/thread_pthread.h:349
#2  0x00000000005b1660 in lock_PyThread_acquire_lock
(self=0x7ffff7f37150, args=<value optimized out>)
    at ../../unladen2/Modules/threadmodule.c:46
#3  0x000000000055b89d in _PyEval_CallFunction (stack_pointer=0x128ff20,
na=<value optimized out>, nk=0) at ../../unladen2/Python/eval.cc:4046
#4  0x000000000055644c in PyEval_EvalFrame (f=0x128fd60) at
../../unladen2/Python/eval.cc:2518
#5  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7ef9670,
globals=0x1, locals=0x2, args=0x123bbd8, argcount=1, kws=0x123bbe0,
kwcount=0, 
    defs=0x7ffff7e540e8, defcount=1, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#6  0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x123bbe0,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#7  0x000000000055644c in PyEval_EvalFrame (f=0x123ba40) at
../../unladen2/Python/eval.cc:2518
#8  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efea30,
globals=0x1, locals=0x2, args=0x12038c8, argcount=1, kws=0x12038d0,
kwcount=0, 
    defs=0x7ffff7e54368, defcount=1, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#9  0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x12038d0,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#10 0x000000000055644c in PyEval_EvalFrame (f=0x1203750) at
../../unladen2/Python/eval.cc:2518
#11 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7f55d50,
globals=0x0, locals=0x0, args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0, 
    defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#12 0x000000000055bc02 in PyEval_EvalCode (co=0x12bb680, globals=0x80,
locals=0x0) at ../../unladen2/Python/eval.cc:552
#13 0x000000000057deb1 in PyRun_FileExFlags (fp=0x1121260,
filename=0x7fffffffe6be "thread_fork_hang.py", start=<value optimized out>, 
    globals=0x10fa010, locals=0x10fa010, closeit=1,
flags=0x7fffffffe290) at ../../unladen2/Python/pythonrun.c:1359
#14 0x000000000057e167 in PyRun_SimpleFileExFlags (fp=0x1121260,
filename=0x7fffffffe6be "thread_fork_hang.py", closeit=1,
flags=0x7fffffffe290)
    at ../../unladen2/Python/pythonrun.c:955
#15 0x00000000004d8954 in Py_Main (argc=-134459232, argv=<value
optimized out>) at ../../unladen2/Modules/main.c:695
#16 0x00007ffff6cdf1c4 in __libc_start_main () from /lib/libc.so.6
#17 0x00000000004d7ae9 in _start ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x40800950 (LWP 4458))]#0 
0x00007ffff7bd234f in waitpid () from /lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff7bd234f in waitpid () from /lib/libpthread.so.0
#1  0x00000000005b6adf in posix_waitpid (self=<value optimized out>,
args=<value optimized out>) at ../../unladen2/Modules/posixmodule.c:5797
#2  0x000000000055b89d in _PyEval_CallFunction (stack_pointer=0x129cff8,
na=<value optimized out>, nk=0) at ../../unladen2/Python/eval.cc:4046
#3  0x000000000055644c in PyEval_EvalFrame (f=0x129ce60) at
../../unladen2/Python/eval.cc:2518
#4  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7f558f0,
globals=0x0, locals=0x0, args=0x7ffff7f98068, argcount=0, kws=0x1239f70, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#5  0x00000000005d98fc in function_call (func=0x7ffff7eefc80,
arg=0x7ffff7f98050, kw=0x1286d20) at ../../unladen2/Objects/funcobject.c:524
#6  0x00000000004dc68d in PyObject_Call (func=0x7ffff7eefc80,
arg=0x7ffff7f98050, kw=0x1286d20) at ../../unladen2/Objects/abstract.c:2487
#7  0x00000000005549d0 in _PyEval_CallFunctionVarKw
(stack_pointer=0x129ce08, num_posargs=<value optimized out>, num_kwargs=0, 
    flags=<value optimized out>) at ../../unladen2/Python/eval.cc:45
#8  0x0000000000559de2 in PyEval_EvalFrame (f=0x129cc80) at
../../unladen2/Python/eval.cc:2560
#9  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe710,
globals=0x1, locals=0x1, args=0x11f1478, argcount=1, kws=0x11f1480,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#10 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x11f1480,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#11 0x000000000055644c in PyEval_EvalFrame (f=0x11f12e0) at
../../unladen2/Python/eval.cc:2518
#12 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe850,
globals=0x1, locals=0x1, args=0x11f1290, argcount=1, kws=0x11f1298,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#13 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x11f1298,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#14 0x000000000055644c in PyEval_EvalFrame (f=0x11f1110) at
../../unladen2/Python/eval.cc:2518
#15 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe7b0,
globals=0x1, locals=0x1, args=0x7ffff7ee9fe8, argcount=1, kws=0x0,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#16 0x00000000005d97fd in function_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ee9fd0, kw=0x0) at ../../unladen2/Objects/funcobject.c:524
#17 0x00000000004dc68d in PyObject_Call (func=0x7ffff7e55ed8,
arg=0x7ffff7ee9fd0, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#18 0x00000000004e3bff in instancemethod_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ee9fd0, kw=0x0) at ../../unladen2/Objects/classobject.c:2579
#19 0x00000000004dc68d in PyObject_Call (func=0x7ffff7f3c640,
arg=0x7ffff7f98050, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#20 0x0000000000553530 in PyEval_CallObjectWithKeywords
(func=0x7ffff7f3c640, arg=0x7ffff7f98050, kw=0x0) at
../../unladen2/Python/eval.cc:45
#21 0x00000000005b1a6d in t_bootstrap (boot_raw=0x125b300) at
../../unladen2/Modules/threadmodule.c:425
#22 0x00007ffff7bca3f7 in start_thread () from /lib/libpthread.so.0
#23 0x00007ffff6d98b3d in clone () from /lib/libc.so.6
#24 0x0000000000000000 in ?? ()

The child process is defunct, but you can still trace the left over
thread with and attach to that with GDB if you guess the process id.  I
couldn't figure out how to get ps to tell it to me, though.  Here's that
trace:

(gdb) bt
#0  0x0000000000558412 in PyEval_EvalFrame (f=0x1245190) at
../../unladen2/Python/eval.cc:2336
#1  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7fce7b0,
globals=0x0, locals=0x0, args=0x7ffff7f98068, argcount=0, kws=0x10eb600, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
../../unladen2/Python/eval.cc:3093
#2  0x00000000005d98fc in function_call (func=0x7ffff7e56d70,
arg=0x7ffff7f98050, kw=0x123ba90) at ../../unladen2/Objects/funcobject.c:524
#3  0x00000000004dc68d in PyObject_Call (func=0x7ffff7e56d70,
arg=0x7ffff7f98050, kw=0x123ba90) at ../../unladen2/Objects/abstract.c:2487
#4  0x00000000005549d0 in _PyEval_CallFunctionVarKw
(stack_pointer=0x1245138, num_posargs=<value optimized out>, num_kwargs=0, 
    flags=<value optimized out>) at ../../unladen2/Python/eval.cc:45
#5  0x0000000000559de2 in PyEval_EvalFrame (f=0x1244fb0) at
../../unladen2/Python/eval.cc:2560
#6  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe710,
globals=0x1, locals=0x1, args=0x1244ee8, argcount=1, kws=0x1244ef0,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#7  0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x1244ef0,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#8  0x000000000055644c in PyEval_EvalFrame (f=0x1244d50) at
../../unladen2/Python/eval.cc:2518
#9  0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe850,
globals=0x1, locals=0x1, args=0x1247c00, argcount=1, kws=0x1247c08,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#10 0x000000000055b7b0 in _PyEval_CallFunction (stack_pointer=0x1247c08,
na=1, nk=0) at ../../unladen2/Python/eval.cc:4188
#11 0x000000000055644c in PyEval_EvalFrame (f=0x1247a80) at
../../unladen2/Python/eval.cc:2518
#12 0x000000000055b225 in PyEval_EvalCodeEx (co=0x7ffff7efe7b0,
globals=0x1, locals=0x1, args=0x7ffff7ef0528, argcount=1, kws=0x0,
kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at ../../unladen2/Python/eval.cc:3093
#13 0x00000000005d97fd in function_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ef0510, kw=0x0) at ../../unladen2/Objects/funcobject.c:524
#14 0x00000000004dc68d in PyObject_Call (func=0x7ffff7e55ed8,
arg=0x7ffff7ef0510, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#15 0x00000000004e3bff in instancemethod_call (func=0x7ffff7e55ed8,
arg=0x7ffff7ef0510, kw=0x0) at ../../unladen2/Objects/classobject.c:2579
#16 0x00000000004dc68d in PyObject_Call (func=0x7ffff7f53230,
arg=0x7ffff7f98050, kw=0x0) at ../../unladen2/Objects/abstract.c:2487
#17 0x0000000000553530 in PyEval_CallObjectWithKeywords
(func=0x7ffff7f53230, arg=0x7ffff7f98050, kw=0x0) at
../../unladen2/Python/eval.cc:45
#18 0x00000000005b1a6d in t_bootstrap (boot_raw=0x1273e60) at
../../unladen2/Modules/threadmodule.c:425
#19 0x00007ffff7bca3f7 in start_thread () from /lib/libpthread.so.0
#20 0x00007ffff6d98b3d in clone () from /lib/libc.so.6
#21 0x0000000000000000 in ?? ()
(gdb) pystack
thread_fork_hang.py (15): daemon
Current language:  auto; currently c
Current language:  auto; currently c++
/home/rnk/unladen2/Lib/threading.py (481): run
/home/rnk/unladen2/Lib/threading.py (523): __bootstrap_inner
/home/rnk/unladen2/Lib/threading.py (498): __bootstrap
Current language:  auto; currently c
Current language:  auto; currently c++
Current language:  auto; currently c

You can see that it's stuck in the daemon's busy loop from the test case.

So what's the right way to fix this?  Should Py_Finalize be called for
the child?  The problem is that if the parent process registers cleanup
code via the atexit module or something, it might be run twice, once in
the parent and once in the child.  However, it's closer to the semantics
of fork, and I'd say that's what you get for using it.  Most people
still using fork are probably just turning around and exec'ing anyway.

I'm willing to write the fix if we can agree on a solution.

----------
components: Library (Lib)
files: thread_fork_hang.py
messages: 91263
nosy: rnk
severity: normal
status: open
title: returning after forking a child thread doesn't call Py_Finalize
versions: Python 3.2
Added file: http://bugs.python.org/file14646/thread_fork_hang.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6642>
_______________________________________

From report at bugs.python.org  Tue Aug  4 20:48:11 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Aug 2009 18:48:11 +0000
Subject: [issue4691] IDLE Code Caching Windows
In-Reply-To: <1229567875.32.0.686259683955.issue4691@psf.upfronthosting.co.za>
Message-ID: <1249411691.26.0.830630594517.issue4691@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, the -n switch was removed from the Windows installer with r72335
(issue5847)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4691>
_______________________________________

From report at bugs.python.org  Tue Aug  4 20:56:49 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 04 Aug 2009 18:56:49 +0000
Subject: [issue6643] joining a child that forks can deadlock in the forked
	child process
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>


New submission from Reid Kleckner <rnk at mit.edu>:

This bug is similar to the importlock deadlock, and it's really part of
a larger problem that you should release all locks before you fork. 
However, we can fix this in the threading module directly by freeing and
resetting the locks on the main thread after a fork.

I've attached a test case that inserts calls to sleep at the right
places to make the following occur:
- Main thread spawns a worker thread.
- Main thread joins worker thread.
- To join, the main thread acquires the lock on the condition variable
(worker.__block.acquire()).
== switch to worker ==
- Worker thread forks.
== switch to child process ==
- Worker thread, which is now the only thread in the process, returns.
- __bootstrap_inner calls self.__stop() to notify any other threads
waiting for it that it returned.
- __stop() tries to acquire self.__block, which has been left in an
acquired state, so the child process hangs here.
== switch to worker in parent process ==
- Worker thread calls os.waitpid(), which hangs, since the child never
returns.

So there's the deadlock.

I think I should be able to fix it just by resetting the condition
variable lock and any other locks hanging off the only thread left
standing after the fork.

----------
components: Library (Lib)
files: forkjoindeadlock.py
messages: 91265
nosy: rnk
severity: normal
status: open
title: joining a child that forks can deadlock in the forked child process
versions: Python 2.6
Added file: http://bugs.python.org/file14647/forkjoindeadlock.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6643>
_______________________________________

From report at bugs.python.org  Tue Aug  4 21:03:19 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Aug 2009 19:03:19 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1249412599.9.0.0897953195372.issue6562@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This error is certainly due to a C function that sets an exception but
does not return an error value.
When running with a debug build of python, you will see "XXX undetected
error" printed to stderr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Tue Aug  4 21:19:56 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 19:19:56 +0000
Subject: [issue6644] cmathmodule.c: Extra comma in enum - fails on AIX
In-Reply-To: <1249413596.71.0.0983950331585.issue6644@psf.upfronthosting.co.za>
Message-ID: <1249413596.71.0.0983950331585.issue6644@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Please the remove extra comma in Modules/cmathmodule.c

64 :	 	 	eimes enum special_types {
65 :	 	 	eimes 	ST_NINF,	/* 0, negative infinity 
*/
66 :	 	 	eimes 	ST_NEG,		/* 1, negative finite 
number (nonzero) */
67 :	 	 	eimes 	ST_NZERO,	/* 2, -0. */
68 :	 	 	eimes 	ST_PZERO,	/* 3, +0. */
69 :	 	 	eimes 	ST_POS,		/* 4, positive finite 
number (nonzero) */
70 :	 	 	eimes 	ST_PINF,	/* 5, positive infinity 
*/
71 :	 	 	eimes 	ST_NAN,		/* 6, Not a Number */
72 :	 	 	eimes };

To see why this is necessary, peruse a similar issue reported earlier: 
http://bugs.python.org/issue5889

----------
components: Build, Extension Modules
messages: 91267
nosy: christian.heimes, srid
severity: normal
status: open
title: cmathmodule.c: Extra comma in enum - fails on AIX
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6644>
_______________________________________

From report at bugs.python.org  Tue Aug  4 21:26:25 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Aug 2009 19:26:25 +0000
Subject: [issue6644] cmathmodule.c: Extra comma in enum - fails on AIX
In-Reply-To: <1249413596.71.0.0983950331585.issue6644@psf.upfronthosting.co.za>
Message-ID: <1249413985.1.0.367040841387.issue6644@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks!  Fixed in r74303, r74304, r74305, r74306.

----------
nosy: +marketdickinson
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6644>
_______________________________________

From report at bugs.python.org  Tue Aug  4 21:26:36 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Aug 2009 19:26:36 +0000
Subject: [issue6637] non-empty defaultdict .copy() fails returning empty dict
In-Reply-To: <1249334752.4.0.485254518119.issue6637@psf.upfronthosting.co.za>
Message-ID: <1249413996.92.0.791982309177.issue6637@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed.  See r74299, r74300, r74301, and r74302.

Thanks for the bug report.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6637>
_______________________________________

From report at bugs.python.org  Tue Aug  4 21:27:33 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 04 Aug 2009 19:27:33 +0000
Subject: [issue6645] multiprocessing build fails on AIX - /dev/urandom (or
	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

./Modules/ld_so_aix cc_r -qlanglvl=ansi -bI:Modules/python.exp build/
temp.aix-5.1-2.6/home/apy/rrun/build/activ
epython-DEV/build/py2_6_2-aix-powerpc-apyee26-rrun/python/Modules/
_multiprocessing/multiprocessing.o build/temp
.aix-5.1-2.6/home/apy/rrun/build/activepython-DEV/build/py2_6_2-aix-
powerpc-apyee26-rrun/python/Modules/_multip
rocessing/socket_connection.o build/temp.aix-5.1-2.6/home/apy/rrun/
build/activepython-DEV/build/py2_6_2-aix-pow
erpc-apyee26-rrun/python/Modules/_multiprocessing/semaphore.o -o build/
lib.aix-5.1-2.6/_multiprocessing.so
*** WARNING: importing extension "_multiprocessing" failed with <type 
'exceptions.NotImplementedError'>: /dev/u
random (or equivalent) not found

----------
components: Build, Extension Modules
messages: 91270
nosy: srid
severity: normal
status: open
title: multiprocessing build fails on AIX - /dev/urandom (or equivalent) not found
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Tue Aug  4 22:12:49 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Aug 2009 20:12:49 +0000
Subject: [issue6633] No handlers could be found for logger
In-Reply-To: <1249319051.14.0.476850462848.issue6633@psf.upfronthosting.co.za>
Message-ID: <1249416769.7.0.13223535747.issue6633@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> vsajip
nosy: +vsajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6633>
_______________________________________

From report at bugs.python.org  Tue Aug  4 22:12:55 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 04 Aug 2009 20:12:55 +0000
Subject: [issue6642] returning after forking a child thread doesn't call
	Py_Finalize
In-Reply-To: <1249410110.52.0.861898541816.issue6642@psf.upfronthosting.co.za>
Message-ID: <1249416775.26.0.314884019919.issue6642@psf.upfronthosting.co.za>


Changes by Reid Kleckner <rnk at mit.edu>:


----------
versions: +Python 2.6 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6642>
_______________________________________

From report at bugs.python.org  Tue Aug  4 22:51:08 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 04 Aug 2009 20:51:08 +0000
Subject: [issue6463] IDLE with Tk-Cocoa: Edit, format menus hang
In-Reply-To: <1247337114.05.0.431997282863.issue6463@psf.upfronthosting.co.za>
Message-ID: <1249419068.26.0.94619274362.issue6463@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6463>
_______________________________________

From report at bugs.python.org  Tue Aug  4 22:57:29 2009
From: report at bugs.python.org (Lenard Lindstrom)
Date: Tue, 04 Aug 2009 20:57:29 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1249419449.01.0.268792192269.issue2698@psf.upfronthosting.co.za>


Lenard Lindstrom <len-l at telus.net> added the comment:

Here is the build with Python 2.6.2. It works now.

C:\pygame\bug2698>python setup.py build --compiler=mingw32 --verbose
running build
running build_ext
building 'simple' extension
creating build
creating build\temp.win32-2.6
creating build\temp.win32-2.6\Release
C:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\python26\include
-IC:\python26\PC -c simple.c -o build\temp.win32-2.6\Release\simple.o
writing build\temp.win32-2.6\Release\simple.def
creating build\lib.win32-2.6
C:\mingw\bin\gcc.exe -mno-cygwin -shared -s
build\temp.win32-2.6\Release\simple.o
build\temp.win32-2.6\Release\simple.def -LC:\python26\libs
-LC:\python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\simple.pyd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Tue Aug  4 23:01:29 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 04 Aug 2009 21:01:29 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1249419689.93.0.0317394260736.issue2698@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

ok then, I am closing it 

thanks for the feedback !

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Tue Aug  4 23:18:45 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 04 Aug 2009 21:18:45 +0000
Subject: [issue6643] joining a child that forks can deadlock in the forked
	child process
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1249420725.38.0.666770067697.issue6643@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

Here's a patch for 3.2 which adds the fix and a test case.  I also
verified that the problem exists in 3.1, 2.7, and 2.6 and backported the
patch to those versions, but someone should review this one before I
upload those.

----------
keywords: +patch
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14648/forkdeadlock.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6643>
_______________________________________

From report at bugs.python.org  Tue Aug  4 23:31:14 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 04 Aug 2009 21:31:14 +0000
Subject: [issue6620] Variable may be used before first being assigned to in
	Lib/locale.py
In-Reply-To: <1249165117.85.0.22004101137.issue6620@psf.upfronthosting.co.za>
Message-ID: <1249421474.06.0.533661342791.issue6620@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

Yes it does

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6620>
_______________________________________

From report at bugs.python.org  Tue Aug  4 23:51:38 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 04 Aug 2009 21:51:38 +0000
Subject: [issue6622] [RFC] wrong variable used in Lib/poplib.py
In-Reply-To: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
Message-ID: <1249422698.03.0.997933715611.issue6622@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

Could someone ensure the attached unittest does the job, I blindly
copied from above...

I don't know how to launch an unittest with the svn 'Lib', it takes the
system one and just messing with PYTHONPATH won't work either.

----------
Added file: http://bugs.python.org/file14649/py3k-poplib.py-use-wrong-variable-unittest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6622>
_______________________________________

From report at bugs.python.org  Tue Aug  4 23:56:59 2009
From: report at bugs.python.org (brian)
Date: Tue, 04 Aug 2009 21:56:59 +0000
Subject: [issue6628] IDLE freezes after encountering a syntax error
In-Reply-To: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>
Message-ID: <1249423019.96.0.350646222708.issue6628@psf.upfronthosting.co.za>


brian <omniscient.brian at gmail.com> added the comment:

I have Tcl/tk 8.4.7 installed.

To reproduce the hang on my machine:
open IDLE
new window
enter the following code:
  for i in range(10)
      print(i)
run module (saved as test.py)
interpreter complains (shell is still responsive at this point)
fix the code by adding the colon after the for loop
run module again (at this point, IDLE hangs)
While the top menu bar is responsive, all options are greyed out, and
apple-Q doesn't work. Force-quit is necessary to shut IDLE down. Also,
the force-quit menu doesn't show IDLE as being unresponsive, whereas
usually there will be a red alert for an unresponsive program.

Hope this helps

----------
components:  -Macintosh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6628>
_______________________________________

From report at bugs.python.org  Wed Aug  5 00:00:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 04 Aug 2009 22:00:31 +0000
Subject: [issue6620] Variable may be used before first being assigned to in
	Lib/locale.py
In-Reply-To: <1249165117.85.0.22004101137.issue6620@psf.upfronthosting.co.za>
Message-ID: <1249423231.44.0.177094342766.issue6620@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  Committed in r74312 (trunk), r74313 (py3k).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6620>
_______________________________________

From report at bugs.python.org  Wed Aug  5 00:04:32 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Tue, 04 Aug 2009 22:04:32 +0000
Subject: [issue6623] Lib/ftplib.py netrc class parsing problem
In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za>
Message-ID: <1249423472.61.0.741056267482.issue6623@psf.upfronthosting.co.za>


Vincent Legoll <vincent.legoll at gmail.com> added the comment:

If the macro_lines is not emptied upon end of parsing a macro
definition, if there's another macro definiton it will 'inherit' the
lines from the previous one, which could very well be uncool.

The use before definition should also be fixed.

Please advise if a better fix would be to completely remove the Netrc
class from ftplib, or replace it with a compatibility wrapper that use
the netrc module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6623>
_______________________________________

From report at bugs.python.org  Wed Aug  5 00:28:11 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 04 Aug 2009 22:28:11 +0000
Subject: [issue2335] Backport set literals
In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
Message-ID: <1249424891.4.0.695903093122.issue2335@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here is a patch for backporting set literals to the trunk.

----------
keywords: +patch
nosy: +alexandre.vassalotti
stage:  -> patch review
Added file: http://bugs.python.org/file14650/backport_set_literal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2335>
_______________________________________

From report at bugs.python.org  Wed Aug  5 00:37:00 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Aug 2009 22:37:00 +0000
Subject: [issue2335] Backport set literals
In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
Message-ID: <1249425420.66.0.377895903543.issue2335@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Guido, I thought you had decided for this to just be a 3.x feature.

Alex, if this goes forward, were you also going to change the repr() for
sets and the corresponding pprint code?  Are set comprehensions on the
radar screen also.  IMO, these all go hand in hand.

----------
assignee:  -> gvanrossum
nosy: +gvanrossum, rhettinger
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2335>
_______________________________________

From report at bugs.python.org  Wed Aug  5 00:59:25 2009
From: report at bugs.python.org (Ned Deily)
Date: Tue, 04 Aug 2009 22:59:25 +0000
Subject: [issue6628] IDLE freezes after encountering a syntax error
In-Reply-To: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>
Message-ID: <1249426765.22.0.869976234495.issue6628@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks, I'm now able to reproduce on both 10.4 and 10.5 with the Apple-
supplied Tcl/Tk 8.4.7 but apparently not with a newer Tcl/Tk nor with 
2.6.2.  Investigating further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6628>
_______________________________________

From report at bugs.python.org  Wed Aug  5 01:03:35 2009
From: report at bugs.python.org (David House)
Date: Tue, 04 Aug 2009 23:03:35 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1249427015.2.0.649162341866.issue6641@psf.upfronthosting.co.za>


David House <dmhouse at gmail.com> added the comment:

>From the documentation from time.strptime() (which acts the same as
datetime.strptime()):

"Only the directives specified in the documentation [of time.strftime()]
are supported. Because strftime() is implemented per platform it can
sometimes offer more directives than those listed. But strptime() is
independent of any platform and thus does not necessarily support all
directives available that are not documented as supported."

So I think invalid.

----------
nosy: +dmhouse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Wed Aug  5 01:21:24 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 04 Aug 2009 23:21:24 +0000
Subject: [issue5449] bug fix to prevent io.BytesIO from accepting arbitrary
	keyword arguments
In-Reply-To: <1236556380.35.0.110625961105.issue5449@psf.upfronthosting.co.za>
Message-ID: <1249428084.74.0.853637604047.issue5449@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r74316.

Thanks!

----------
nosy: +alexandre.vassalotti
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5449>
_______________________________________

From report at bugs.python.org  Wed Aug  5 01:27:34 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 04 Aug 2009 23:27:34 +0000
Subject: [issue2335] Backport set literals
In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
Message-ID: <1249428454.87.0.941970893444.issue2335@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I think we should keep the repr() of sets as is to avoid breaking any
code. And yes, I plan to port set comprehensions along with dict
comprehension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2335>
_______________________________________

From report at bugs.python.org  Wed Aug  5 01:51:27 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 04 Aug 2009 23:51:27 +0000
Subject: [issue1967] Backport dictviews to 2.7
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1249429887.81.0.352955054289.issue1967@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I have refreshed Thomas's patch to reflect recent updates to dictviews.
I also added the documentation for dictviews.

----------
nosy: +alexandre.vassalotti
stage:  -> patch review
Added file: http://bugs.python.org/file14651/backport_dictviews.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1967>
_______________________________________

From report at bugs.python.org  Wed Aug  5 01:53:21 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 04 Aug 2009 23:53:21 +0000
Subject: [issue1967] Backport dictviews to 2.7
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1249430001.35.0.497693097353.issue1967@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here is a patch for 2to3 to support the translation of code using dictviews.

----------
Added file: http://bugs.python.org/file14652/2to3_fixer_dictviews.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1967>
_______________________________________

From report at bugs.python.org  Wed Aug  5 02:05:57 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 00:05:57 +0000
Subject: [issue6636] Non-existant directory in sys.path prevents further
	imports
In-Reply-To: <1249331773.17.0.57338899812.issue6636@psf.upfronthosting.co.za>
Message-ID: <1249430757.72.0.400608688419.issue6636@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Looks like an optimization for the common case when directories aren't 
created "on the fly". Your proposal would slow down all imports (a 
typical sys.path actually contains a few nonexisting directories).

Quoting PEP302:

    The results of path hook checks are cached in
    sys.path_importer_cache, which is a dictionary mapping path entries
    to importer objects.  The cache is checked before sys.path_hooks is
    scanned.  If it is necessary to force a rescan of sys.path_hooks, it
    is possible to manually clear all or part of
    sys.path_importer_cache.

So the problem is that some cached data is outdated. In this case, 
after creating a directory that might be listed in sys.path, you should 
clear the cached entries using either of these lines:

sys.path_importer_cache.pop("/tmp/foobar", None)
sys.path_importer_cache.clear()

and then your test code succeeds.

(I'd close the issue as 'invalid')

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6636>
_______________________________________

From report at bugs.python.org  Wed Aug  5 02:14:48 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 00:14:48 +0000
Subject: [issue6634] sys.exit() called from threads other than the main one:
	undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1249431288.99.0.0216376334609.issue6634@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

I agree with you; the docs should be improved, and I see no reason for 
sys.exit("msg") NOT to write to stderr inside a child thread.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6634>
_______________________________________

From report at bugs.python.org  Wed Aug  5 02:23:13 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 00:23:13 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249431793.18.0.60290395652.issue6632@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Wed Aug  5 02:35:14 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Aug 2009 00:35:14 +0000
Subject: [issue2335] Backport set literals
In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
Message-ID: <1249432514.19.0.487868777584.issue2335@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Raymond, I know you see this differently, but personally I don't see a
problem with 2.7 getting additional backports of 3.x features, as long
as they are backwards compatible. While personally I wouldn't spend
effort on this particular backport, I don't see a problem when someone
volunteers a patch. In this specific case, I am fine with accepting set
literals and set comprehensions as new syntax. I do agree that repr()
needs to be kept the same as it was under 2.6.

----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2335>
_______________________________________

From report at bugs.python.org  Wed Aug  5 03:06:28 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Wed, 05 Aug 2009 01:06:28 +0000
Subject: [issue6642] returning after forking a child thread doesn't call
	Py_Finalize
In-Reply-To: <1249410110.52.0.861898541816.issue6642@psf.upfronthosting.co.za>
Message-ID: <1249434388.52.0.53890589029.issue6642@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

Here's a patch against 2.6 for one way to fix it.  I imagine it has
problems, but I wanted to throw it out there as a straw man.

This patch builds on the patch for http://bugs.python.org/issue6643
since some of the test cases will occasionally deadlock without it.

----------
keywords: +patch
Added file: http://bugs.python.org/file14653/finalize-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6642>
_______________________________________

From report at bugs.python.org  Wed Aug  5 03:11:28 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 01:11:28 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1249434688.18.0.865752641318.issue5712@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

With 2.6.2 on Windows, I get filenames surrounded by {}, all in a 
single unicode string.
The change may be related to the new Tk library used, not directly the 
tkFileDialog module.

(BTW, I don't see *any* unit tests for tkinter :( )

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Wed Aug  5 03:42:45 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 05 Aug 2009 01:42:45 +0000
Subject: [issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 !=
	6.9999999999999984e-308
In-Reply-To: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>
Message-ID: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

test test_pickle failed -- errors occurred; run in verbose mode for 
details
test_pickletools
test test_pickletools failed -- Traceback (most recent call last):
  File "/home/apy/rrun/tmp/autotest/apy/lib/python2.6/test/
pickletester.py", line 546, in test_float
    self.assertEqual(value, got)
AssertionError: 6.9999999999999994e-308 != 6.9999999999999984e-308

----------
components: Tests
messages: 91292
nosy: srid
severity: normal
status: open
title: test_pickle fails on AIX -- 6.9999999999999994e-308 != 6.9999999999999984e-308
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6646>
_______________________________________

From report at bugs.python.org  Wed Aug  5 03:47:38 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 01:47:38 +0000
Subject: [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>
Message-ID: <1249436858.75.0.0680769178287.issue2710@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

AFAIK, WSAEWOULDBLOCK means that the socket is in nonblocking mode and 
the attempted operation could wait indefinitely to complete. But I 
don't understand how that could happen since a previous select() 
confirmed the socket is writeable...
Probably the whole code block could be replaced by a single 
self.sock.sendall(s) call.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2710>
_______________________________________

From report at bugs.python.org  Wed Aug  5 03:53:14 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Aug 2009 01:53:14 +0000
Subject: [issue2335] Backport set literals
In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
Message-ID: <1249437194.75.0.114591596007.issue2335@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

These all seem fine to me.  Was just checking in because I thought you
had previously pronounced otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2335>
_______________________________________

From report at bugs.python.org  Wed Aug  5 04:00:32 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 02:00:32 +0000
Subject: [issue6625] UnicodeEncodeError on pydoc's CLI
In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
Message-ID: <1249437632.76.0.664569897764.issue6625@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

After applying your patch, are string (not unicode) docstrings still 
being handled properly?
Adding a test case (in Lib/test/test_pydoc.py) would be nice too.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6625>
_______________________________________

From report at bugs.python.org  Wed Aug  5 04:13:52 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 02:13:52 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1249438432.02.0.614653498702.issue5505@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This is a duplicate of #1633941

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Wed Aug  5 04:18:00 2009
From: report at bugs.python.org (Fan Decheng)
Date: Wed, 05 Aug 2009 02:18:00 +0000
Subject: [issue1633941] for line in sys.stdin: doesn't notice EOF the first
	time
Message-ID: <1249438680.28.0.145977713299.issue1633941@psf.upfronthosting.co.za>


Changes by Fan Decheng <fandecheng at gmail.com>:


----------
nosy: +r_mosaic

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633941>
_______________________________________

From report at bugs.python.org  Wed Aug  5 04:29:59 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 05 Aug 2009 02:29:59 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1249434688.18.0.865752641318.issue5712@psf.upfronthosting.co.za>
Message-ID: <ac2200130908041929i6ce5c823kfc0ccef3b47f2dae@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> With 2.6.2 on Windows, I get filenames surrounded by {}, all in a
> single unicode string.

This string surrounded by { } indicates it is supposed to be a tcl
list, which didn't get converted but should be done by tkFileDialog.

> The change may be related to the new Tk library used, not directly the
> tkFileDialog module.
>

It could be, or not. A simple solution would be to call the splitlist
function from _tkinter on that string, which tkFileDialog should be
doing indifferently of expecting objects from _tkinter or not.

> (BTW, I don't see *any* unit tests for tkinter :( )
>

There are some one a separated branch for now, but it doesn't include
tkFileDialog yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Wed Aug  5 04:34:38 2009
From: report at bugs.python.org (David Roberts)
Date: Wed, 05 Aug 2009 02:34:38 +0000
Subject: [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1249439678.0.0.17712740944.issue6562@psf.upfronthosting.co.za>


David Roberts <d at vidr.cc> added the comment:

Ok, so if it's a bug in (Py)Qt then I'm not going to worry about it.

I've managed to fix the issue in my case anyway, by (essentially) replacing:
    image = Image.open(fname)
    image.load()
    tile = ImageQt(image)
with (the much more obvious way to do it):
    tile = QImage(fname)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________

From report at bugs.python.org  Wed Aug  5 04:48:28 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 05 Aug 2009 02:48:28 +0000
Subject: [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1249436858.75.0.0680769178287.issue2710@psf.upfronthosting.co.za>
Message-ID: <ac2200130908041948s64ecd1d5i2758aca0d03647@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> AFAIK, WSAEWOULDBLOCK means that the socket is in nonblocking mode and
> the attempted operation could wait indefinitely to complete.

Rather pessimistic way to see it :) I've always read it as "operation
cannot be completed without blocking".

> But I
> don't understand how that could happen since a previous select()
> confirmed the socket is writeable...

Richard Stevens, MSDN
(http://msdn.microsoft.com/en-us/library/ms741540(VS.85).aspx) and
possibly several other authors and places will tell it is possible to
happen. I've always seen this being handled as "try again later".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2710>
_______________________________________

From report at bugs.python.org  Wed Aug  5 06:45:02 2009
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 05 Aug 2009 04:45:02 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1249447502.82.0.824623428968.issue6526@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, I need a double-check here, David. At this point I have narrowed it 
down to this code triggering it::

  finder = importlib._bootstrap._PyPycFileFinder('.')
  sys.path_importer_cache['.'] = finder

And I am not kidding, that assignment is required. I might be able to 
narrow the code down further in _PyPycFileFinder, but I wanted to double-
check that I have not gone insane and that these two lines do indeed 
trigger the problem.

----------
assignee: brett.cannon -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Wed Aug  5 06:53:01 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 04:53:01 +0000
Subject: [issue6647] warnings.catch_warnings is not thread-safe
In-Reply-To: <1249447980.99.0.321429613778.issue6647@psf.upfronthosting.co.za>
Message-ID: <1249447980.99.0.321429613778.issue6647@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

warnings.catch_warnings is a context manager supposed to save and 
restore warnings filters, and optionally record all warnings issued.

But it does so in a completely thread-unsafe way, by replacing the 
module's "showwarning" and "filters" attributes on enter, and restoring 
them on exit. If the __enter__ / __exit__ calls of two threads overlap, 
after leaving the last block the warnings state is not the same as the 
original state, as it should be.

I don't know how to fix this, other than using locks (that could block 
indefinitely) or severely restricting how catch_warnings may be used. 
At least, this issue should be documented.

----------
components: Library (Lib)
files: error-warnings.py
messages: 91301
nosy: gagenellina
severity: normal
status: open
title: warnings.catch_warnings is not thread-safe
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14654/error-warnings.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6647>
_______________________________________

From report at bugs.python.org  Wed Aug  5 06:56:04 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 04:56:04 +0000
Subject: [issue6635] Profiler doesn't print usage (indexError instead)
In-Reply-To: <1249331560.84.0.146355793731.issue6635@psf.upfronthosting.co.za>
Message-ID: <1249448164.27.0.903027260106.issue6635@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

The patch looks fine to me.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6635>
_______________________________________

From report at bugs.python.org  Wed Aug  5 07:44:16 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 05 Aug 2009 05:44:16 +0000
Subject: [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>
Message-ID: <1249451056.41.0.0439265187632.issue2710@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

So this patch should fix it. But I cannot fire the bug using the posted 
example, and there are no test cases for this module yet, so I could 
not test it.

----------
keywords: +patch
Added file: http://bugs.python.org/file14655/rpc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2710>
_______________________________________

From report at bugs.python.org  Wed Aug  5 12:14:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 10:14:18 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249467258.52.0.434004376706.issue6632@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

On the specific point of:

>   2.1 some languages/alphabets use other chars (e.g. a comma or other
>       symbols) instead of the decimal point.

I think it's not the job of the float() constructor to support it.
Depending on the country, the comma has different meanings when put in a
number (thousands separator or decimal separator). Ditto for the point,
but using a point as decimal separator is the accepted standard for
non-localized computer I/O.

More generally, I think the fact that int(), float() et al. support
non-ASCII decimal digits should be seen as a convenience rather than a
willingness to accomodate the broadest set possible of inputs. Which
means, we should only add support for new formats only if it's sensible,
safe and non-ambiguous to do so.

I also agree with Marc-Andr?'s argument that the Unicode spec should be
a good guide here.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Wed Aug  5 12:17:13 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 10:17:13 +0000
Subject: [issue6645] multiprocessing build fails on AIX - /dev/urandom (or
	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1249467433.53.0.986236266481.issue6645@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jnoller
nosy: +jnoller
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Wed Aug  5 12:27:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 10:27:04 +0000
Subject: [issue5737] add Solaris errnos
In-Reply-To: <1239469549.92.0.788554665966.issue5737@psf.upfronthosting.co.za>
Message-ID: <1249468024.24.0.38614804911.issue5737@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Martin, what do you think?

----------
nosy: +loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5737>
_______________________________________

From report at bugs.python.org  Wed Aug  5 12:34:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 10:34:22 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1249468462.68.0.513378787044.issue6603@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't reproduce here (using gcc 4.3.2). Have you tried `make
distclean`? Is it a fresh checkout?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Wed Aug  5 12:37:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 10:37:56 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1249468676.13.0.980760527773.issue6600@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If your patch really fixes the issue, it is probably a compiler problem.
Does IBM have a user group or support line to which you can take this?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Wed Aug  5 12:43:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 10:43:22 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1249469002.21.0.658271943906.issue6594@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure there's anything we should do about this. Some
architectures are unreasonably slow at some things, and the old SPARC
implementations are a niche nowadays. I suppose you may witness the same
kinds of slowdowns if you use cPickle rather than json.

(I'm looking for the "abysmally low" priority setting :-))

----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito, pitrou
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________

From report at bugs.python.org  Wed Aug  5 12:52:50 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 10:52:50 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1249469570.12.0.0710757925475.issue1436346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some comments:
- since there is already a weekday() method, the new method should be
called yearday() rather than yday()
- ditto for fromyday(): fromyearday() would be better
- Modules/datetimemodule.c should only be indented with tabs, but your
patch indents it with spaces in some places
- the algorithm in date_fromyday() looks suboptimal: if you repeatedly
call days_in_month(), you shouldn't have to call days_before_month() at
the end, you can compute it by yourself

I haven't tested the patch yet.

Marc-Andr?, do you have any take on the principle of this?

----------
nosy: +lemburg
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Wed Aug  5 12:59:33 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 10:59:33 +0000
Subject: [issue4997] xml.sax.saxutils.XMLGenerator should write to
	io.RawIOBase.
In-Reply-To: <1232361357.86.0.976302026477.issue4997@psf.upfronthosting.co.za>
Message-ID: <1249469973.11.0.12290139307.issue4997@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You shouldn't remove the defaulting behaviour for `out`, but use
`sys.stdout.buffer` instead.

Bonus points if you add a test so that this kind of bug doesn't go
unnoticed again.

PS: it's ironic that the default encoding here is iso-8859-1. This piece
of code is really getting old.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4997>
_______________________________________

From report at bugs.python.org  Wed Aug  5 13:01:38 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 11:01:38 +0000
Subject: [issue6501] Fatal LookupError: unknown encoding: cp0 on Windows
	embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1249470098.72.0.497364098586.issue6501@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Graham, is the workaround ok for you or do you think this is something
Python itself should handle?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Wed Aug  5 13:05:51 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 11:05:51 +0000
Subject: [issue1524938] PEP MemoryError with a lot of available memory gc not
	called
Message-ID: <1249470351.67.0.0257850145279.issue1524938@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure what we should do anyway. Your program will first swap out
and thrash before the MemoryError is raised. Invoking the GC when memory
allocation fails would avoid the MemoryError, but not the massive
slowdown due to swapping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524938>
_______________________________________

From report at bugs.python.org  Wed Aug  5 13:06:58 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 Aug 2009 11:06:58 +0000
Subject: [issue1436346] yday in datetime module
In-Reply-To: <1249469570.12.0.0710757925475.issue1436346@psf.upfronthosting.co.za>
Message-ID: <4A7967CE.7030701@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Some comments:
> - since there is already a weekday() method, the new method should be
> called yearday() rather than yday()
> - ditto for fromyday(): fromyearday() would be better
> - Modules/datetimemodule.c should only be indented with tabs, but your
> patch indents it with spaces in some places
> - the algorithm in date_fromyday() looks suboptimal: if you repeatedly
> call days_in_month(), you shouldn't have to call days_before_month() at
> the end, you can compute it by yourself
> 
> I haven't tested the patch yet.
> 
> Marc-Andr?, do you have any take on the principle of this?

mxDateTime uses attributes for such things, ie. .day_of_week,
.day_of_year, .days_in_month. No idea, why the datetime module
chose to implement access to this static information as method.

I've never had a request for a way to construct a date by
giving the year and day of the year - probably because it's
just too easy to do by hand:

217
>>> Date(2009, 1, 1) + (217 - 1)
<mx.DateTime.DateTime object for '2009-08-05 00:00:00.00' at 2b5320c262f0>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Wed Aug  5 13:09:26 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 05 Aug 2009 11:09:26 +0000
Subject: [issue1436346] yday in datetime module
Message-ID: <1249470566.7.0.494218470684.issue1436346@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Hmm, looks like there's a bug in roundup's email interface... the code
snippet should have read:

>>> from mx.DateTime import *
>>> today().day_of_year
217
>>> Date(2009, 1, 1) + (217 - 1)
<mx.DateTime.DateTime object for '2009-08-05 00:00:00.00' at 2b5320c262f0>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1436346>
_______________________________________

From report at bugs.python.org  Wed Aug  5 13:29:50 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Wed, 05 Aug 2009 11:29:50 +0000
Subject: [issue6625] UnicodeEncodeError on pydoc's CLI
In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
Message-ID: <1249471790.69.0.749062705879.issue6625@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

Here is a diff for test/test_pydoc.py (against Python2.6) which though
doesn't trigger due to how Python handles output encoding. This test
here will pass, but pydoc will still fail:

$ pydoc test/pydoc_mod.py > /dev/null
Traceback (most recent call last):
  File "/usr/bin/pydoc", line 5, in <module>
    pydoc.cli()
  File "/usr/lib/python2.5/pydoc.py", line 2226, in cli
    help.help(arg)
  File "/usr/lib/python2.5/pydoc.py", line 1691, in help
    else: doc(request, 'Help on %s:')
  File "/usr/lib/python2.5/pydoc.py", line 1482, in doc
    pager(title % desc + '\n\n' + text.document(object, name))
  File "/usr/lib/python2.5/pydoc.py", line 1300, in pager
    pager(text)
  File "/usr/lib/python2.5/pydoc.py", line 1398, in plainpager
    sys.stdout.write(plain(text))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in
position 936: ordinal not in range(128)

----------
Added file: http://bugs.python.org/file14656/pydoc_unicode_testcase_notworking.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6625>
_______________________________________

From report at bugs.python.org  Wed Aug  5 14:05:03 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 12:05:03 +0000
Subject: [issue6629] seek doesn't properly handle file buffer,
	leads to silent data corruption
In-Reply-To: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>
Message-ID: <1249473903.12.0.547943327687.issue6629@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an initial patch. Could you try it on your workload?

----------
keywords: +patch
Added file: http://bugs.python.org/file14657/issue6629.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6629>
_______________________________________

From report at bugs.python.org  Wed Aug  5 14:08:59 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Wed, 05 Aug 2009 12:08:59 +0000
Subject: [issue6501] Fatal LookupError: unknown encoding: cp0 on Windows
	embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1249474139.7.0.255334753988.issue6501@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

Python should be as robust as possible and thus should be fixed, but I am 
happy with using the workaround so if this is more a question of what 
priority to mark this, I wouldn't see it as being urgent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Wed Aug  5 14:50:47 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Aug 2009 12:50:47 +0000
Subject: [issue6647] warnings.catch_warnings is not thread-safe
In-Reply-To: <1249447980.99.0.321429613778.issue6647@psf.upfronthosting.co.za>
Message-ID: <1249476647.46.0.0452584481649.issue6647@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Any function whose purpose is to mutate global (non thread-local) state
is inherently "thread-unsafe". The only reasonable possibility is to
document it as such.

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6647>
_______________________________________

From report at bugs.python.org  Wed Aug  5 15:13:33 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 05 Aug 2009 13:13:33 +0000
Subject: [issue6645] multiprocessing build fails on AIX - /dev/urandom (or
	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1249478013.35.0.609822514526.issue6645@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Without access to an AIX machine, and even with it (I'm not an AIX guy by 
any stretch) it's going to be virtually impossible for me to fix this. A 
patch would be appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Wed Aug  5 17:44:03 2009
From: report at bugs.python.org (Karoly Lorentey)
Date: Wed, 05 Aug 2009 15:44:03 +0000
Subject: [issue6629] seek doesn't properly handle file buffer,
	leads to silent data corruption
In-Reply-To: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>
Message-ID: <1249487043.37.0.782295508173.issue6629@psf.upfronthosting.co.za>


Karoly Lorentey <karoly at lorentey.hu> added the comment:

The patch does fix my issue, thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6629>
_______________________________________

From report at bugs.python.org  Wed Aug  5 17:48:49 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 05 Aug 2009 15:48:49 +0000
Subject: [issue6648] codecs documentation does not mention surrogateescape
In-Reply-To: <1249487329.19.0.991009276368.issue6648@psf.upfronthosting.co.za>
Message-ID: <1249487329.19.0.991009276368.issue6648@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

On http://docs.python.org/3.1/library/codecs.html it says that

----
Possible values for errors are 'strict' (raise an exception in case of
an encoding error), 'replace' (replace malformed data with a suitable
replacement marker, such as '?'), 'ignore' (ignore malformed data and
continue without further notice), 'xmlcharrefreplace' (replace with the
appropriate XML character reference (for encoding only)) and
'backslashreplace' (replace with backslashed escape sequences (for
encoding only)) as well as any other error handling name defined via
register_error().
-----

shouldn't the 'surrogateescape' error handler from
http://docs.python.org/3.1/library/os.html#file-names-command-line-arguments-and-environment-variables
be mentioned here as well?

----------
assignee: georg.brandl
components: Documentation
messages: 91321
nosy: Nikratio, georg.brandl
severity: normal
status: open
title: codecs documentation does not mention surrogateescape
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6648>
_______________________________________

From report at bugs.python.org  Wed Aug  5 18:21:09 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 05 Aug 2009 16:21:09 +0000
Subject: [issue6649] idlelib/rpc.py missing exit status on exithook
In-Reply-To: <1249489269.49.0.307291234061.issue6649@psf.upfronthosting.co.za>
Message-ID: <1249489269.49.0.307291234061.issue6649@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

SocketIO.exithook on idlelib/rpc.py is missing the exit status, this is
a minor issue since both client and server used on IDLE override this
method to do something else.

----------
components: IDLE
files: missing_exitstatus.diff
keywords: patch
messages: 91322
nosy: gpolo
priority: low
severity: normal
status: open
title: idlelib/rpc.py missing exit status on exithook
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14658/missing_exitstatus.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6649>
_______________________________________

From report at bugs.python.org  Wed Aug  5 18:36:28 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 05 Aug 2009 16:36:28 +0000
Subject: [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>
Message-ID: <1249490188.5.0.659527622406.issue2710@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I just tried writing tests for it, but I don't know idlelib/rpc.py
enough yet. You can see this first attempt at:
http://svn.python.org/view?view=rev&revision=74320

I started trying to test rpc.RPCClient together with run.main but it
seemed too high level. Then I moved to try to test rpc.SocketIO
directly, but it seems I'm doing wrong things there. Most of times
SocketIOTest will fail by raising ValueError which then causes the
server process to finish and either cause a "Connection reset by peer",
"Broken pipe" or nothing (these are on Linux, on Windows I would expect
to get "An existing connection was forcibly closed by the remote host").
Sometimes it also succeeds.

----------
versions: +Python 2.7, Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2710>
_______________________________________

From report at bugs.python.org  Wed Aug  5 19:14:39 2009
From: report at bugs.python.org (Torne Wuff)
Date: Wed, 05 Aug 2009 17:14:39 +0000
Subject: [issue6650] sre_parse contains a confusing generic error message
In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>
Message-ID: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>


New submission from Torne Wuff <torne-pythonbugs at wolfpuppy.org.uk>:

sre_parse raises an exception with the message "syntax error" - very
generic and confusing - in the case where something that looks like a
lookbehind assertion is invalid.

>>> import re
>>> re.match('(?<foo>.*)', 'foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/re.py", line 137, in match
    return _compile(pattern, flags).match(string)
  File "/usr/lib/python2.5/re.py", line 241, in _compile
    raise error, v # invalid expression
sre_constants.error: syntax error

This example is a typo for '(?P<foo>.*)' :)

This is the only case in sre_parse where the message "syntax error" is
used - the others are much more descriptive. Attached patch changes it
to "bad lookbehind assertion type: %s" for python 2.x head; should be
applied to 3.x also.

----------
components: Regular Expressions
files: sre_error_msg.diff
keywords: patch
messages: 91324
nosy: torne
severity: normal
status: open
title: sre_parse contains a confusing generic error message
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14659/sre_error_msg.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6650>
_______________________________________

From report at bugs.python.org  Wed Aug  5 19:14:40 2009
From: report at bugs.python.org (Artur Frysiak)
Date: Wed, 05 Aug 2009 17:14:40 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1249492480.47.0.293016122985.issue6603@psf.upfronthosting.co.za>


Artur Frysiak <wiget at pld-linux.org> added the comment:

reproduced on fresh checkout from
http://svn.python.org/projects/python/branches/py3k (rev. 74321)

$ gcc --version|head -n 1
gcc (PLD-Linux) 4.4.1 20090724 (release)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Wed Aug  5 20:51:48 2009
From: report at bugs.python.org (Shawn)
Date: Wed, 05 Aug 2009 18:51:48 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1249498308.04.0.196531421632.issue6594@psf.upfronthosting.co.za>


Shawn <swalker at opensolaris.org> added the comment:

As I mentioned, there's also noticeable performance penalties on recent
SPARC systems, such as Niagra T1000, T2000, etc.  The degradation is
just less obvious (a 10-15 second penalty instead of a 20 or 30 second
penalty).  While x86 enjoys no penalty at all (in my testing so far).

Here's an example of the data structure:

    {    
      "packages":{
        "package-name-1":{
          "publisher":"publisher-name-1",
          "versions":[
            [    
              "0.5.11,5.11-0.86:20080422T230436Z",
              {    
                "depend":{
                  "require":[
                    {    
                      "fmri":"foo"
                    },   
                    {    
                      "fmri":"bar"
                    }    
                  ],   
                  "optional":[
                    {    
                      "fmri":"baz"
                    },   
                    {    
                      "fmri":"quux"
                    }    
                  ]    
                }    
              }    
            ],   
          ]    
        }    
      }    
    }    

Now imagine that there are 45,000 package-name-x entries in the
structure above, and that basically replicates what I'm writing.

If I turn the above structure into a list of lists instead, the penalty
is significantly reduced (halved at least).  If I flatten the stack even
farther, the penalty is essentially gone.  The greater the depth of the
data structure, the greater the penalty.

As for priority, I wouldn't call this "end of the world", but it does
create some unfortunate surprises for developers that rely on the json
module.  Given the long service lifetimes of SPARC systems (due to cost
:)), I suspect this would be of benefit for a long time to come.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________

From report at bugs.python.org  Wed Aug  5 21:23:12 2009
From: report at bugs.python.org (Erick Tryzelaar)
Date: Wed, 05 Aug 2009 19:23:12 +0000
Subject: [issue6651] Py3k's posixpath.relpath not compatible with
	ntpath.relpath
In-Reply-To: <1249500192.85.0.26357988262.issue6651@psf.upfronthosting.co.za>
Message-ID: <1249500192.85.0.26357988262.issue6651@psf.upfronthosting.co.za>


New submission from Erick Tryzelaar <idadesub at users.sourceforge.net>:

It looks like Python 3.x's relpath isn't compatible between posixpath
and ntpath. In posixpath.relpath, the start keyword defaults to None,
but ntpath.relpath, the start keyword defaults to curdir.

Interestingly enough, 2.6 and 2.7 have a different implementation of
posixpath.relpath, where it explicitly sets the start to equal curdir,
just like ntpath does.

----------
components: Library (Lib)
messages: 91327
nosy: erickt
severity: normal
status: open
title: Py3k's posixpath.relpath not compatible with ntpath.relpath
type: performance
versions: Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6651>
_______________________________________

From report at bugs.python.org  Wed Aug  5 21:35:45 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Aug 2009 19:35:45 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1249500945.78.0.078222141291.issue6594@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Are you sure that recursion depth is the issue?  Have you tried the same
number and kind of objects listed serially (unnested)?  This would help
rule-out memory allocation issues and would instead confirm that it has
something to do with the C stack.

It would be helpful if you uploaded your test data strings and timing
suite.  Are you able to run a C profile so we can tell where the hotspot
is?  Can you run PyYAML over the same data to see if it is similarly
afflicted (yaml is a superset of json).

Also, try timing a repr() serialization of the same data,
x=repr(rootobj).  The repr code also uses recursion and it has to build
a big string in memory.  It has to visit every node, so it will reveal
whether memory cache misses are the culprit.  

Try your timings with GC turned-off so that we can rule that out.

Do you have some option to compile with an alternate memory allocator
(such as dlmalloc).  A crummy memory allocator may be the issue since
serialization entails creating many small strings, then joining and
resizing them.

Also, try serializing to /dev/null so that we can exclude fileio issues
(buffering and whatnot).

Sorry for all the requests, but there are many possible culprits and I
think it unlikely that recursion is the cause (much of the code in
Python works recursively -- everything from repr to gc -- so if that
were the problem, everything would run slower, not just json serialization).

----------
assignee: bob.ippolito -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________

From report at bugs.python.org  Wed Aug  5 21:45:56 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 05 Aug 2009 19:45:56 +0000
Subject: [issue6633] No handlers could be found for logger
In-Reply-To: <1249319051.14.0.476850462848.issue6633@psf.upfronthosting.co.za>
Message-ID: <1249501556.24.0.449858443879.issue6633@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

1) It's not appropriate to document NullHandler at the point you
describe, as that's the API for Handlers. However, it is documented at

http://docs.python.org/library/logging.html#configuring-logging-for-a-library

I will check that NullHandler is added to documentation where the
available handler classes are listed.

2) Unlikely to be backported to 2.5, as it's a new feature (2.5
documentation tells how to create the class in user's own code).

3) NullHandler was placed in the main logging package along with the
other "elementary" handlers which are likely to be of most general use -
the handlers.py module is intended for more specialised handlers.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6633>
_______________________________________

From report at bugs.python.org  Wed Aug  5 21:47:09 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Wed, 05 Aug 2009 19:47:09 +0000
Subject: [issue6652] missing cmath functions
In-Reply-To: <1249501629.27.0.648462584075.issue6652@psf.upfronthosting.co.za>
Message-ID: <1249501629.27.0.648462584075.issue6652@psf.upfronthosting.co.za>


New submission from Phillip M. Feldman <pfeldman at verizon.net>:

The online documentation describes functions cmath.phase and
cmath.polar, but when I try to import these, I get "cannot import name"
errors.

----------
assignee: georg.brandl
components: Documentation
messages: 91330
nosy: georg.brandl, pfeldman at verizon.net
severity: normal
status: open
title: missing cmath functions
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6652>
_______________________________________

From report at bugs.python.org  Wed Aug  5 21:53:29 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Aug 2009 19:53:29 +0000
Subject: [issue6652] missing cmath functions
In-Reply-To: <1249501629.27.0.648462584075.issue6652@psf.upfronthosting.co.za>
Message-ID: <1249502009.48.0.782035567577.issue6652@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

These functions are new in Python 2.6; they do not appear in the Python
2.5 docs.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6652>
_______________________________________

From report at bugs.python.org  Wed Aug  5 22:23:52 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 05 Aug 2009 20:23:52 +0000
Subject: [issue6653] Potential memory leak in multiprocessing
In-Reply-To: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>
Message-ID: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>


New submission from Jesse Noller <jnoller at gmail.com>:

I have example code to show this. It creates a system-wide memory leak 
on Linux/Unix (present until the next reboot), unless the last statement 
in the target of mp.Process ensures a manual clean up of the globals.

The problem is line 353 in multiprocessing/forking.py. The function 
exit() is defined as os._exit on Linux and ExitProcess on Windows, none 
of which allows normal clean up.

>>> help(os._exit)
Help on built-in function _exit in module nt:

_exit(...)
   _exit(status)

   Exit to the system with specified status, without normal exit 
processing.


The problem is fixed if line 353 in forking.py is changed from

exit(exitcode)

to

sys.exit(exitcode)




Test run without bugfix:

G:\DEVELO~1\SHARED~2>python test.py
open handle to 569f439b24e24fc8a547b81932616066
[[ 0.  0.  0.  0.]
 [ 0.  0.  0.  0.]]
open handle to 0582d4b161c546f582c1c96e7bd0c39d
open handle to 569f439b24e24fc8a547b81932616066
modified array
closed handle to 569f439b24e24fc8a547b81932616066
[[ 1.  1.  1.  0.]
 [ 1.  1.  1.  0.]]
closed handle to 569f439b24e24fc8a547b81932616066


You can see here that opening and closing of handles are unmatched. This 
is on Windows, where the kernel ensures the clean-up, so it may not 
matter. But on Unix this would have created a permament (system wide) 
memory leak! What is happening here is globals not being cleaned up due 
to the use of os._exit instead of sys.exit.


Test run with bugfix:

G:\DEVELO~1\SHARED~2>python test.py
open handle to 930778d27b414253bc329f2b70adaa05
[[ 0.  0.  0.  0.]
 [ 0.  0.  0.  0.]]
open handle to 3f6cebf8c5de413685bb770d02ae9666
open handle to 930778d27b414253bc329f2b70adaa05
modified array
closed handle to 930778d27b414253bc329f2b70adaa05
closed handle to 3f6cebf8c5de413685bb770d02ae9666
[[ 1.  1.  1.  0.]
 [ 1.  1.  1.  0.]]
closed handle to 930778d27b414253bc329f2b70adaa05



Now all allocations and deallocations are matched.


Regards,
Sturla Molden

----------
files: test.zip
messages: 91332
nosy: jnoller
severity: normal
status: open
title: Potential memory leak in multiprocessing
Added file: http://bugs.python.org/file14660/test.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6653>
_______________________________________

From report at bugs.python.org  Wed Aug  5 22:25:02 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 05 Aug 2009 20:25:02 +0000
Subject: [issue6653] Potential memory leak in multiprocessing
In-Reply-To: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>
Message-ID: <1249503902.75.0.475532249701.issue6653@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Additional comments from Sturla:

Hello Jesse,

Yes there is a bug in multiprocessing.

Diagnosis:

- Processes created by multiprocessing (mp.Process or mp.Pool) exit in a 
way that prevents the Python interpreter from running deallocation code 
for all extension objects (only the locals are cleaned up). Resources 
allocated by extension objects referenced in globals may leak 
permanently.

Sub-processes seem to commit an ungraceful suicide on exit. If the 
kernel cleans up after a non-graceful exit this is ok. But if the kernel 
do not, as in the case of System V IPC objects, we have a permanent 
resource leak. This is very similar to the reason why manually killing 
threads is prohibited in Python.

I have example code to show this. It creates a system-wide memory leak 
on Linux/Unix (present until the next reboot), unless the last statement 
in the target of mp.Process ensures a manual clean up of the globals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6653>
_______________________________________

From report at bugs.python.org  Wed Aug  5 22:27:19 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 05 Aug 2009 20:27:19 +0000
Subject: [issue6653] Potential memory leak in multiprocessing
In-Reply-To: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>
Message-ID: <1249504039.46.0.684989520204.issue6653@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6653>
_______________________________________

From report at bugs.python.org  Wed Aug  5 22:39:57 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 05 Aug 2009 20:39:57 +0000
Subject: [issue6653] Potential memory leak in multiprocessing
In-Reply-To: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>
Message-ID: <1249504797.36.0.666039948404.issue6653@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

> Calling os.exit in a child process may be dangerous. It can cause 
> unflushed buffers to be flushed twice: once in the parent and once in 
> the child. 

I assume you mean sys.exit. If this is the case, multiprocessing needs 
a mechanism to chose between os._exit and sys.exit for child 
processes. Calling os._exit might also be dangerous because it could 
prevent necessary clean-up code from executing  (e.g. in C 
extensions). I had a case where shared memory on Linux (System V IPC) 
leaked due to os._exit. The deallocator for my extension type never 
got to execute in child processes. The deallocator was needed to 
release the shared segment when its reference count dropped to 0. 
Changing to sys.exit solved the problem. On Windows there was no leak, 
because the kernel did the reference counting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6653>
_______________________________________

From report at bugs.python.org  Wed Aug  5 22:48:58 2009
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 05 Aug 2009 20:48:58 +0000
Subject: [issue6653] Potential memory leak in multiprocessing
In-Reply-To: <1249503832.66.0.0114205396453.issue6653@psf.upfronthosting.co.za>
Message-ID: <1249505338.85.0.180167914204.issue6653@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

> In the future please use the bug tracker to file and track bugs with, 
> so things are not as lossy. 


Ok, sorry :) 
Also see Piet's comment here. He has a valid case against sys.exit in 
some cases. Thus it appears that both ways of shutting down child 
processes might be dangerous: If we don't want buffers to flush we 
have to use os._exit. If we want clean-up code to execute we have to 
use sys.exit. If we want both we are screwed. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6653>
_______________________________________

From report at bugs.python.org  Wed Aug  5 22:58:40 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 05 Aug 2009 20:58:40 +0000
Subject: [issue6605] smtplib.SMTP.sendmail() rejected after quit(),
	connect() sequence, no HELO
In-Reply-To: <1248985082.82.0.727591290783.issue6605@psf.upfronthosting.co.za>
Message-ID: <1249505920.44.0.300242678799.issue6605@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> smtplib doesn't clear helo/ehlo flags on quit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6605>
_______________________________________

From report at bugs.python.org  Wed Aug  5 23:07:48 2009
From: report at bugs.python.org (James)
Date: Wed, 05 Aug 2009 21:07:48 +0000
Subject: [issue6633] No handlers could be found for logger
In-Reply-To: <1249319051.14.0.476850462848.issue6633@psf.upfronthosting.co.za>
Message-ID: <1249506468.6.0.883750989341.issue6633@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

very well,
i didn't notice the
http://docs.python.org/library/logging.html#configuring-logging-for-a-library
and i thank you for your time and efforts!

cheers,
_J

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6633>
_______________________________________

From report at bugs.python.org  Wed Aug  5 23:16:40 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 05 Aug 2009 21:16:40 +0000
Subject: [issue6654] Add "path" to the xmrlpc dispatcher method
In-Reply-To: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>
Message-ID: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

I've created http://codereview.appspot.com/100046 on Rietveld:
by passing the "path" component of the xmlrpc request to the dispatch 
method, it
becomes possible to dispatch differently according to this.  This patch 
provides
that addition.  Additionally, it provides an MultiPathXMLRPCDispatcher 
mixin
class and a MultiPathXMLRPCServer that uses it, to have multiple 
dispatchers for
different paths.
This allows a single server port to serve different XMLRPC servers as
differentiated by the HTTP path.  A test is also preovided.

I've also prophylacticly emailed this to phython-ideas.

----------
components: Library (Lib)
messages: 91337
nosy: krisvale
severity: normal
status: open
title: Add "path" to the xmrlpc dispatcher method
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6654>
_______________________________________

From report at bugs.python.org  Thu Aug  6 01:10:13 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 05 Aug 2009 23:10:13 +0000
Subject: [issue2333] Backport set and dict comprehensions
In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
Message-ID: <1249513813.12.0.88763259312.issue2333@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here is a patch to backport dict and set comprehensions to the trunk.

The patch preserves the Python 3.x's syntax and semantics of the
feature. Although this makes dict and set comprehensions is inconsistent
with list comprehension, I believe this is reasonable since the backport
aimed to improve the compatibility of Python 2.x with Python 3.x.

The patch also adds support for dict and set comprehensions to the
'compiler' package. However, the support is quirky and use the list
comprehension semantics of Python 2.x. This allowed me to keep the patch
simple and to keep myself sane ;-).

Finally, the patch changes the name of the following syntax nodes:
'gen_expr', 'gen_iter', 'gen_if', and 'testlist_gexp'. I don't know if
we have compatibility requirements for this; so I don't know if this is
an issue.

----------
keywords: +patch
nosy: +alexandre.vassalotti
stage:  -> patch review
title: Backport dict comprehensions -> Backport set and dict comprehensions
Added file: http://bugs.python.org/file14661/backport_dict_and_set_comprehension.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2333>
_______________________________________

From report at bugs.python.org  Thu Aug  6 01:11:45 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 05 Aug 2009 23:11:45 +0000
Subject: [issue2334] Backport set comprehensions
In-Reply-To: <1205775496.96.0.230528149509.issue2334@psf.upfronthosting.co.za>
Message-ID: <1249513905.16.0.00605368498422.issue2334@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Backport set and dict comprehensions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2334>
_______________________________________

From report at bugs.python.org  Thu Aug  6 01:12:32 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 05 Aug 2009 23:12:32 +0000
Subject: [issue2333] Backport set and dict comprehensions
In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
Message-ID: <1249513952.83.0.826578587433.issue2333@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
dependencies: +Backport set literals

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2333>
_______________________________________

From report at bugs.python.org  Thu Aug  6 02:32:38 2009
From: report at bugs.python.org (Christopher Lee)
Date: Thu, 06 Aug 2009 00:32:38 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1249518758.11.0.758069409132.issue5736@psf.upfronthosting.co.za>


Christopher Lee <leec at chem.ucla.edu> added the comment:

Another reason this issue is really important, is that the lack of a
consistent iter() interface for dbm.* makes shelve iteration not
scalable; i.e. trying to iterate on a Shelf will run self.dict.keys() to
load the entire index into memory.  This seems contrary to a primary
purpose of shelve, namely to store the index on-disk so as to avoid
having to keep the whole index in memory.  

I suspect that for most users, shelve is the main way they will access
the dbm.* interfaces.  Therefore, fixing the dbm.* interfaces so that
shelve is scalable seems like an important need.

Once dbm and gdbm support the iterator protocol, it will be trivial to
add an __iter__() method to shelve.Shelf, that simply returns
iter(self.dict).

----------
nosy: +foobaron

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________

From report at bugs.python.org  Thu Aug  6 02:39:06 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 06 Aug 2009 00:39:06 +0000
Subject: [issue2345] Using an exception variable outside an 'except' clause
	should raise a Py3K warning
In-Reply-To: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za>
Message-ID: <1249519146.02.0.645649508545.issue2345@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Brett, could you provide an example of "an exception bound to a variable"?

----------
nosy: +alexandre.vassalotti
priority: critical -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2345>
_______________________________________

From report at bugs.python.org  Thu Aug  6 02:50:06 2009
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Aug 2009 00:50:06 +0000
Subject: [issue2345] Using an exception variable outside an 'except' clause
	should raise a Py3K warning
In-Reply-To: <1205778549.05.0.340690581025.issue2345@psf.upfronthosting.co.za>
Message-ID: <1249519806.26.0.24860893895.issue2345@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

try:
    raise Exception("I should not be seen")
except Exception, exc:
    pass

print exc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2345>
_______________________________________

From report at bugs.python.org  Thu Aug  6 03:08:12 2009
From: report at bugs.python.org (Christopher Lee)
Date: Thu, 06 Aug 2009 01:08:12 +0000
Subject: [issue6045] Fix dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <1249520892.48.0.119221353983.issue6045@psf.upfronthosting.co.za>


Christopher Lee <leec at chem.ucla.edu> added the comment:

I suspect that for most users, shelve is the main way they will access
the dbm.* interfaces.  Based on that, the dict methods that are really
needed on dbm.* objects are just: __iter__, __len__, __getitem__,
__setitem__, __delitem__, __contains__, has_key, and keys.  

Note: Issue 5736 aims to make dbm.* support the iterator protocol, which
would be crucial for making shelve iteration scalable (currently,
iterating on a Shelf will call self.dict.keys(), loading the entire
index into memory!).

The dbm.* docs could also explicitly tell users who want a *complete*
dict interface to create a class that inherits from both dbm and
UserDict.DictMixin / MutableMapping.

----------
nosy: +foobaron

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6045>
_______________________________________

From report at bugs.python.org  Thu Aug  6 03:18:44 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 06 Aug 2009 01:18:44 +0000
Subject: [issue6645] multiprocessing build fails on AIX - /dev/urandom (or
	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1249521524.52.0.454470615298.issue6645@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I suppose multiprocessing invokes `os.random` somewhere. And os.random 
fails on AIX for obvious reasons:

>>> os.urandom(10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/srid/ActivePythonEE-2.6.2.3-aix-powerpc64/i/lib/python2.6/
os.py", line 755, in urandom
    raise NotImplementedError("/dev/urandom (or equivalent) not found")
NotImplementedError: /dev/urandom (or equivalent) not found
>>> 

Why should multiprocessing require `urandom` at all? Can't it fallback 
to os.random, if os.urandom is unavailable?

try:
    os.urandom(10)
except NotImplementedError:
    urandom = os.urandom
else:
    urandom = os.random

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Thu Aug  6 03:21:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 06 Aug 2009 01:21:04 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1249521664.22.0.79772989996.issue6600@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Update: posixmodule.c too has the same problem. Attaching similar patch 
for this:

--- python/Modules/posixmodule.c.orig   2009-08-05 09:47:07.000000000 
-0700
+++ python/Modules/posixmodule.c        2009-08-05 09:48:46.000000000 
-0700
@@ -6451,7 +6451,7 @@
                return NULL;
 
        /* Sanitize mode.  See fileobject.c */
-       mode = PyMem_MALLOC(strlen(orgmode)+3);
+       mode = PyMem_MALLOC(3+strlen(orgmode));

----------
keywords: +patch
Added file: http://bugs.python.org/file14662/aix2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Aug  6 03:23:54 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 06 Aug 2009 01:23:54 +0000
Subject: [issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1249521834.06.0.151690595941.issue6600@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

It does appear that this problem occurs wherever `strlen` is used .. 
and given that strlen is a macro on AIX, I suspect the problem is with 
the macro definition itself.

I will see if wrapping the arguments to PyMem_MALLOC in parenthesis 
would help. And/or investigate the problem further.

As for your belief that it might be a compiler bug, I will wait till 
investigating the actual cause of the problem before drawing any 
conclusions. Till then, there is no reason to commit the current 
(experimental/workaround) patches to Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Aug  6 03:26:12 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 06 Aug 2009 01:26:12 +0000
Subject: [issue6600] MemoryError in AiX 64-bit - PyMem_MALLOC fails in
	open/fdopen
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1249521972.66.0.273635770021.issue6600@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
title: MemoryError in AiX 64-bit build - PyMem_MALLOC failed -> MemoryError in AiX 64-bit - PyMem_MALLOC fails in open/fdopen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________

From report at bugs.python.org  Thu Aug  6 04:08:54 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 06 Aug 2009 02:08:54 +0000
Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue
In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za>
Message-ID: <1249524534.64.0.359954656836.issue4660@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Fix checked into python trunk with r74326, 26 maint w/ r74327

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4660>
_______________________________________

From report at bugs.python.org  Thu Aug  6 04:10:01 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 06 Aug 2009 02:10:01 +0000
Subject: [issue4660] multiprocessing.JoinableQueue task_done() issue
In-Reply-To: <1229273282.85.0.657676661464.issue4660@psf.upfronthosting.co.za>
Message-ID: <1249524601.25.0.793786386814.issue4660@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I used the protected JoinableQueue put method suggested by Brian.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4660>
_______________________________________

From report at bugs.python.org  Thu Aug  6 04:14:14 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 06 Aug 2009 02:14:14 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1249524854.6.0.747909686047.issue6064@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Thu Aug  6 04:33:30 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 06 Aug 2009 02:33:30 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1249526010.61.0.782466244081.issue1745@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy: +alexandre.vassalotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Thu Aug  6 05:35:20 2009
From: report at bugs.python.org (Dj Gilcrease)
Date: Thu, 06 Aug 2009 03:35:20 +0000
Subject: [issue6655] etree iterative find[text]
In-Reply-To: <1249529720.45.0.62463367335.issue6655@psf.upfronthosting.co.za>
Message-ID: <1249529720.45.0.62463367335.issue6655@psf.upfronthosting.co.za>


New submission from Dj Gilcrease <digitalxero at gmail.com>:

I recently converted a project from using a custom  implementation of 
xml.dom.minidom to using EelemntTree that comes with python2.5+ and 
found myself wishing for a find(tag_or_path) method that would do so iteratively instead of just on the current elements direct children. 
This is possible with the code as written;

looking_for = None
for el in etree.getiterator(tag_or_path):
    looking_for = el
    break

I have to do this type of action so often in my code that I just decided 
to grab the python implementation of etree that came with py2.6 and 
include it with my app and patch in an iter_find method as the instant 
break for loop is just asking for maintenance issues down the road what 
I forget why I was breaking on the first loop no matter what.

----------
components: XML
files: ElementTree.py.patch
keywords: patch
messages: 91348
nosy: Digitalxero
severity: normal
status: open
title: etree iterative find[text]
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14663/ElementTree.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6655>
_______________________________________

From report at bugs.python.org  Thu Aug  6 05:36:15 2009
From: report at bugs.python.org (Dj Gilcrease)
Date: Thu, 06 Aug 2009 03:36:15 +0000
Subject: [issue6655] etree iterative find[text]
In-Reply-To: <1249529720.45.0.62463367335.issue6655@psf.upfronthosting.co.za>
Message-ID: <1249529775.01.0.624991134555.issue6655@psf.upfronthosting.co.za>


Dj Gilcrease <digitalxero at gmail.com> added the comment:

second patch file

----------
Added file: http://bugs.python.org/file14664/ElementPath.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6655>
_______________________________________

From report at bugs.python.org  Thu Aug  6 09:47:25 2009
From: report at bugs.python.org (Francesco Del Degan)
Date: Thu, 06 Aug 2009 07:47:25 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1249544845.39.0.847936662377.issue6280@psf.upfronthosting.co.za>


Francesco Del Degan <f.deldegan at ngi.it> added the comment:

Hi, i started to produce a patch for timemodule.c.

Working into it, i found that we have almost 3 way to do that:

1. Use timegm(3) function where HAVE_TIMEGM is defined (i have a working patch for it)

2. Implement a more portable timegm function with tzset and mktime where HAVE_MKTIME and 
HAVE_WORKING_TZSET is defined (i have a working patch for it)

3. Doing some calculation taking calendar.timegm as example.


What do you think about it?

Thanks,
Francesco "pr0gg3d" Del Degan

----------
nosy: +pr0gg3d

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Thu Aug  6 10:22:37 2009
From: report at bugs.python.org (Simon Cross)
Date: Thu, 06 Aug 2009 08:22:37 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1249546957.58.0.232100157529.issue6280@psf.upfronthosting.co.za>


Changes by Simon Cross <hodgestar at gmail.com>:


----------
nosy: +hodgestar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Thu Aug  6 11:17:51 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 09:17:51 +0000
Subject: [issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 !=
	6.9999999999999984e-308
In-Reply-To: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>
Message-ID: <1249550271.25.0.646642819542.issue6646@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> marketdickinson
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6646>
_______________________________________

From report at bugs.python.org  Thu Aug  6 11:39:05 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 09:39:05 +0000
Subject: [issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 !=
	6.9999999999999984e-308
In-Reply-To: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>
Message-ID: <1249551545.28.0.0640914193708.issue6646@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report!

What's the underlying hardware on your machine?

Here's a Python 2.6 interpreter session on my machine (OS X 10.5/Intel).  
Would it be possible for you to execute the same commands on your machine 
and tell me what you get?

Python 2.6.2 (r262:71600, Jun 17 2009, 09:08:27) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from sys import float_info
>>> float_info
sys.floatinfo(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, 
min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, 
mant_dig=53, epsilon=2.2204460492503131e-16, radix=2, rounds=1)
>>> from pickle import dumps, loads
>>> x = 7e-308
>>> x
7.0000000000000004e-308
>>> p = [dumps(x, proto) for proto in range(3)]
>>> p
['F7.0000000000000004e-308\n.', 'G\x00)*\xee\xa4Z\xae\xe0.', 
'\x80\x02G\x00)*\xee\xa4Z\xae\xe0.']
>>> up = [loads(z) for z in p]
>>> up
[7.0000000000000004e-308, 7.0000000000000004e-308, 7.0000000000000004e-
308]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6646>
_______________________________________

From report at bugs.python.org  Thu Aug  6 13:09:38 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Thu, 06 Aug 2009 11:09:38 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>


New submission from Christoph Burgmer <cburgmer at ira.uka.de>:

locale.format_string doesn't return same result as a normal
"string" % format
directive, but raises a TypeError. See attached test case for Python
2.6.

>>> locale.format_string('%f%%', 1.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/locale.py", line 195, in format_string
    return new_f % val
TypeError: not enough arguments for format string
>>> '%f%%' % 1.0
'1.000000%'

----------
components: Library (Lib)
files: locale_percents_test.diff
keywords: patch
messages: 91352
nosy: christoph
severity: normal
status: open
title: locale.format_string fails on escaped percentage
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14665/locale_percents_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Thu Aug  6 13:14:39 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Thu, 06 Aug 2009 11:14:39 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1249557279.0.0.0016050381192.issue6656@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

This patch removes '%%' entities from the regex results and only
replaces other matches with '%s' which later then get replaced by
localized versions so that escaped percentage entities don't show up in
localized parsing anymore.

Removing case '%%' from the regex completely does not sound feasible
and will result in '%%d' having a match '%d', though d should be a
normal character.

The replacing of regex matches does not look that beautiful, feel free
to rewrite said part.

----------
Added file: http://bugs.python.org/file14666/locale_percents.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Thu Aug  6 13:18:55 2009
From: report at bugs.python.org (Sheepherd)
Date: Thu, 06 Aug 2009 11:18:55 +0000
Subject: [issue6657] Copy documentation section
In-Reply-To: <1249557535.14.0.530083384684.issue6657@psf.upfronthosting.co.za>
Message-ID: <1249557535.14.0.530083384684.issue6657@psf.upfronthosting.co.za>


New submission from Sheepherd <sheepherd2k at hotmail.com>:

The enumerated part in about the exact usage of the conversion specifier
in "String Formatting Operations"
http://docs.python.org/library/stdtypes.html#string-formatting should be
copied to http://docs.python.org/library/string.html#formatspec to make
the usage of the specifier clear.

----------
assignee: georg.brandl
components: Documentation
messages: 91354
nosy: Sheepherd, georg.brandl
severity: normal
status: open
title: Copy documentation section
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6657>
_______________________________________

From report at bugs.python.org  Thu Aug  6 13:47:47 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 06 Aug 2009 11:47:47 +0000
Subject: [issue6658] typo in buffer api docs
In-Reply-To: <1249559267.03.0.842450307551.issue6658@psf.upfronthosting.co.za>
Message-ID: <1249559267.03.0.842450307551.issue6658@psf.upfronthosting.co.za>


New submission from Alexey Shamrin <shamrin at gmail.com>:

Typo in PyObject_GetBuffer docs: "...handle all the complexibity..."

Links:

http://docs.python.org/c-api/buffer.html#buffer-related-functions
http://docs.python.org/dev/c-api/buffer.html#buffer-related-functions
http://docs.python.org/3.1/c-api/buffer.html#buffer-related-functions
http://docs.python.org/dev/py3k/c-api/buffer.html#buffer-related-functions

----------
assignee: georg.brandl
components: Documentation
messages: 91355
nosy: ash, georg.brandl
severity: normal
status: open
title: typo in buffer api docs
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6658>
_______________________________________

From report at bugs.python.org  Thu Aug  6 13:57:54 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 06 Aug 2009 11:57:54 +0000
Subject: [issue6658] typo in buffer api docs
In-Reply-To: <1249559267.03.0.842450307551.issue6658@psf.upfronthosting.co.za>
Message-ID: <1249559874.4.0.20952720553.issue6658@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

Well, there's another typo in buffer documentation (PyBuffer_Release):

"This shouldd be called..."

Only in 2.x series:

http://docs.python.org/c-api/buffer.html#PyBuffer_Release
http://docs.python.org/dev/c-api/buffer.html#PyBuffer_Release

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6658>
_______________________________________

From report at bugs.python.org  Thu Aug  6 14:07:36 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 06 Aug 2009 12:07:36 +0000
Subject: [issue6659] buffer c-api: memoryview object documentation
In-Reply-To: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>
Message-ID: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>


New submission from Alexey Shamrin <shamrin at gmail.com>:

"A memoryview object is an extended buffer object that could replace the
buffer object (but doesn?t have to as that could be kept as a simple 1-d
memoryview object)."

Well, buffer object was dropped Python 3, wasn't it?

http://docs.python.org/dev/py3k/c-api/buffer.html#memoryview-objects
http://docs.python.org/3.1/c-api/buffer.html#memoryview-objects

----------
assignee: georg.brandl
components: Documentation
messages: 91357
nosy: ash, georg.brandl
severity: normal
status: open
title: buffer c-api: memoryview object documentation
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6659>
_______________________________________

From report at bugs.python.org  Thu Aug  6 14:14:52 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 12:14:52 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249560892.63.0.815473269799.issue6632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Python's current support for localization in int and float seems largely 
accidental, as far as I can tell.  But I appreciate the argument that
despite the current inconsistencies, we shouldn't add extra support 
without a standard to base it on.

I'm not sure how relevant TR35 is to this situation;  that seems to be 
about localization, and I don't really understand why it should be the 
job of int and float to deal with localization (even though they 
currently do, to some extent).  I'd even argue for removing support[*] 
for anything other than ASCII digits from int and float, except that 
that would likely break existing applications, and annoy people.  Out of 
curiosity, I asked on #python about this, and found that there are 
people working with CJK alphabets who find it convenient that int 
currently accepts fullwidth digits.  I don't know whether there's anyone 
who cares that int and float currently accept e.g., Devanagari digits.

I guess I'm +0.2 for preserving the status quo, for now.

([*] I'm aware that I'm being a bit inconsistent here, since I was 
recently arguing that the Decimal type should accept non-European 
decimal digits partly based on the fact that int and float do.  But in 
the case of Decimal there's an underlying standard that recommends 
acceptance of these digits, and compliance with that standard has 
generally taken precedence over consistency with Python's other numeric 
types.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Thu Aug  6 14:58:42 2009
From: report at bugs.python.org (djc)
Date: Thu, 06 Aug 2009 12:58:42 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1249563522.45.0.428320832924.issue1537721@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1537721>
_______________________________________

From report at bugs.python.org  Thu Aug  6 15:21:35 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 06 Aug 2009 13:21:35 +0000
Subject: [issue1628205] socket.readline() interface doesn't handle EINTR
	properly
Message-ID: <1249564895.56.0.887418127605.issue1628205@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

nice test case rhettg.

This is a correctness issue to prevent data loss on EINTR.

I've attached a patch that builds on rhettg's but allows the EINTR signal 
to propagate upwards as desired by loweis and jorend for both read() and 
readline() calls.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
Added file: http://bugs.python.org/file14667/issue1628205-gps01.diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628205>
_______________________________________

From report at bugs.python.org  Thu Aug  6 15:31:37 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 06 Aug 2009 13:31:37 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249560892.63.0.815473269799.issue6632@psf.upfronthosting.co.za>
Message-ID: <4A7ADB35.3000009@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Dickinson wrote:
> Python's current support for localization in int and float seems largely 
> accidental, as far as I can tell.

Not at all. The support for non-ASCII numeric characters
in int() and float() is by design - however, I did not look
at things like decimal points, minus/plus signs, etc. at the
time and only included support for numeric values associated
with a number of code points, such as ? for 1/2.

> But I appreciate the argument that
> despite the current inconsistencies, we shouldn't add extra support 
> without a standard to base it on.
> 
> I'm not sure how relevant TR35 is to this situation;  that seems to be 
> about localization, and I don't really understand why it should be the 
> job of int and float to deal with localization (even though they 
> currently do, to some extent).  I'd even argue for removing support[*] 
> for anything other than ASCII digits from int and float, except that 
> that would likely break existing applications, and annoy people.  Out of 
> curiosity, I asked on #python about this, and found that there are 
> people working with CJK alphabets who find it convenient that int 
> currently accepts fullwidth digits.  I don't know whether there's anyone 
> who cares that int and float currently accept e.g., Devanagari digits.

My suggestion is to wait for the Unicode locale project to collect
locale based information on numeric formatting. I'm sure that some
of this information will be entered back into the Unicode database
in form of code point properties for e.g. decimal points, signs, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Thu Aug  6 15:42:05 2009
From: report at bugs.python.org (Rodrigo Steinmuller Wanderley)
Date: Thu, 06 Aug 2009 13:42:05 +0000
Subject: [issue6582] test_telnetlib doesn't test Telnet.write
In-Reply-To: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>
Message-ID: <1249566125.59.0.501863169061.issue6582@psf.upfronthosting.co.za>


Rodrigo Steinmuller Wanderley <rodrigoswanderley at gmail.com> added the comment:

Did only minor modifications to TelnetSocketSendall class.

Please review the following patch.

----------
keywords: +patch
nosy: +rwanderley
Added file: http://bugs.python.org/file14668/write_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6582>
_______________________________________

From report at bugs.python.org  Thu Aug  6 16:04:34 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 14:04:34 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249317285.35.0.709481915004.issue6632@psf.upfronthosting.co.za>
Message-ID: <1249567474.38.0.367548603962.issue6632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Mark Dickinson]
> Python's current support for localization in int and float seems
> largely accidental, as far as I can tell.

[MAL]
> Not at all. [...]

Apologies;  'accidental' was a poor choice of word here.

> however, I did not look
> at things like decimal points, minus/plus signs, etc. at the
> time and only included support for numeric values associated
> with a number of code points, such as ? for 1/2.

I'm less concerned about decimal points and the like, and more bothered by 
the fact that e.g., int(x, 16) accepts some, but not all, characters with 
the Hex_Digit property.  This seems counter to the intent of the Unicode 
standard.

[MAL]
> My suggestion is to wait for the Unicode locale project to collect
> locale based information on numeric formatting. [...]

Sounds fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Thu Aug  6 16:35:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 14:35:31 +0000
Subject: [issue6622] [RFC] wrong variable used in Lib/poplib.py
In-Reply-To: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
Message-ID: <1249569331.19.0.257296505767.issue6622@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Could someone ensure the attached unittest does the job, I blindly
> copied from above...

Unfortunately it doesn't, because the apop method needs a timestamp in the 
welcome message in order to work.  I've adapted it to make this work---see 
attached patch 'issue6622.patch'.

> I don't know how to launch an unittest with the svn 'Lib', it takes
> the system one and just messing with PYTHONPATH won't work either.

I'm not entirely sure what you're asking here.  On OS X, I usually do 
something like the following at a Terminal prompt:

newton:py3k dickinsm$ ./python.exe Lib/test/test_poplib.py

For better control over output and various other things, use the regrtest 
module:

newton:py3k dickinsm$ ./python.exe Lib/test/regrtest.py -v test_poplib

(execute Lib/test/regrtest.py --help to see a list of options).

----------
Added file: http://bugs.python.org/file14669/issue6622.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6622>
_______________________________________

From report at bugs.python.org  Thu Aug  6 16:38:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 14:38:13 +0000
Subject: [issue6622] [RFC] wrong variable used in Lib/poplib.py
In-Reply-To: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
Message-ID: <1249569493.93.0.576275800073.issue6622@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Adding Giampaolo Rodola to the nosy list, since he worked on the test code 
recently.  Giampaolo, any comments?

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6622>
_______________________________________

From report at bugs.python.org  Thu Aug  6 17:49:12 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 06 Aug 2009 15:49:12 +0000
Subject: [issue6622] [RFC] wrong variable used in Lib/poplib.py
In-Reply-To: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
Message-ID: <1249573752.83.0.106544478211.issue6622@psf.upfronthosting.co.za>


Giampaolo Rodola' <billiejoex at users.sourceforge.net> added the comment:

@Mark
I can't test your patch right now as I don't have a Python 3.x installed
here but it looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6622>
_______________________________________

From report at bugs.python.org  Thu Aug  6 18:08:46 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 16:08:46 +0000
Subject: [issue6622] [RFC] wrong variable used in Lib/poplib.py
In-Reply-To: <1249165487.21.0.506053747681.issue6622@psf.upfronthosting.co.za>
Message-ID: <1249574926.56.0.288322856072.issue6622@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Patch committed, r74330 (py3k) and r74331 (release31-maint).
Thanks, Giampaolo and Vincent!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6622>
_______________________________________

From report at bugs.python.org  Thu Aug  6 18:24:08 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 16:24:08 +0000
Subject: [issue2333] Backport set and dict comprehensions
In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
Message-ID: <1249575848.18.0.89029501234.issue2333@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Alexandre, I can't get this to apply cleanly to my svn trunk checkout 
(r74328) (see attached log).  Am I doing something stupid?

----------
nosy: +marketdickinson
Added file: http://bugs.python.org/file14670/patch_failure.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2333>
_______________________________________

From report at bugs.python.org  Thu Aug  6 18:44:08 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 06 Aug 2009 16:44:08 +0000
Subject: [issue2333] Backport set and dict comprehensions
In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
Message-ID: <1249577048.78.0.524136979899.issue2333@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

You need to apply the set literal patch I posted in issue2335 first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2333>
_______________________________________

From report at bugs.python.org  Thu Aug  6 18:52:13 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 16:52:13 +0000
Subject: [issue2333] Backport set and dict comprehensions
In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
Message-ID: <1249577533.69.0.873358406361.issue2333@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, that works.  Thanks!  (I'll pay more attention to the tracker 
Dependencies field in future.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2333>
_______________________________________

From report at bugs.python.org  Thu Aug  6 19:44:17 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Aug 2009 17:44:17 +0000
Subject: [issue6658] typo in buffer api docs
In-Reply-To: <1249559267.03.0.842450307551.issue6658@psf.upfronthosting.co.za>
Message-ID: <1249580657.26.0.384904701213.issue6658@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74333, will be merged to the other branches eventually.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6658>
_______________________________________

From report at bugs.python.org  Thu Aug  6 19:45:31 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Aug 2009 17:45:31 +0000
Subject: [issue6659] buffer c-api: memoryview object documentation
In-Reply-To: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>
Message-ID: <1249580731.49.0.148659328434.issue6659@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Benjamin is listed as the section author.

----------
assignee: georg.brandl -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6659>
_______________________________________

From report at bugs.python.org  Thu Aug  6 19:48:51 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Aug 2009 17:48:51 +0000
Subject: [issue6657] Copy documentation section
In-Reply-To: <1249557535.14.0.530083384684.issue6657@psf.upfronthosting.co.za>
Message-ID: <1249580931.73.0.119853499446.issue6657@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm not sure which "enumerated part" you mean.  Can you propose a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6657>
_______________________________________

From report at bugs.python.org  Thu Aug  6 19:49:44 2009
From: report at bugs.python.org (kee nethery)
Date: Thu, 06 Aug 2009 17:49:44 +0000
Subject: [issue6660] Desire python.org documentation link to user contribution
	wiki (per function)
In-Reply-To: <1249580984.63.0.922866340136.issue6660@psf.upfronthosting.co.za>
Message-ID: <1249580984.63.0.922866340136.issue6660@psf.upfronthosting.co.za>


New submission from kee nethery <kee at kagi.com>:

Proposal: For each permalink headline in the official documentation, 
link to a wiki page specific to that headline. Allow users to easily 
view and contribute comments and examples around that specific 
documentation headline. For example:
http://docs.python.org/reference/lexical_analysis.html#string-literal-
concatenation
would have an auto-generated link in the main docs of (for example):
http://wiki.docs.python.org/2.6.2#reference#lexical_analysis.html#string
-literal-concatenation
Easy to create, self administering, perhaps valuable to new users, 
completely unofficial.

Newbies need examples, lots of examples. Newbies have noob questions 
about things they are stumbling across that experienced users have 
forgotten was once confusing. For experienced users that knowledge is 
now part of their Python DNA. According to people on the "python-list" 
other languages have wiki style user contribution areas that allow 
newbies to document the things they found confusing (and the answers) 
and to provide lots of code examples. Periodically this newbie 
information is rolled back into the official mainline docs. Requiring 
newbies to join this tracking system and to submit bugs is just way to 
complex for something that is now trivial to do with a wiki and it 
obviously causes the new user contributions to be pretty non-existent. 
Python would be a much easier language to learn if newbies could easily 
contribute through the main documentation web site.

----------
assignee: georg.brandl
components: Documentation
messages: 91373
nosy: georg.brandl, keenethery, nnorwitz
severity: normal
status: open
title: Desire python.org documentation link to user contribution wiki (per function)
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________

From report at bugs.python.org  Thu Aug  6 19:51:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Aug 2009 17:51:11 +0000
Subject: [issue6648] codecs documentation does not mention surrogateescape
In-Reply-To: <1249487329.19.0.991009276368.issue6648@psf.upfronthosting.co.za>
Message-ID: <1249581071.21.0.546860084628.issue6648@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74334.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6648>
_______________________________________

From report at bugs.python.org  Thu Aug  6 19:56:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Aug 2009 17:56:43 +0000
Subject: [issue6660] Desire python.org documentation link to user contribution
	wiki (per function)
In-Reply-To: <1249580984.63.0.922866340136.issue6660@psf.upfronthosting.co.za>
Message-ID: <1249581403.05.0.319344126589.issue6660@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is already in planning; Sphinx will grow a webapp system that also
allows suggestions for changes.

----------
resolution:  -> later
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________

From report at bugs.python.org  Thu Aug  6 20:06:04 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Aug 2009 18:06:04 +0000
Subject: [issue6659] buffer c-api: memoryview object documentation
In-Reply-To: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>
Message-ID: <1249581964.05.0.857603891634.issue6659@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the terminology in these docs is not very precise and helpful.
There are two things here:
- the buffer /struct/ a.k.a Py_buffer, which can only be used from C
code and using the dedicated "new buffer API"
- the memoryview, which is a Python object (a PyObject *) wrapping a
buffer struct; as a PyObject *, it can be used everywhere a regular
Python object is expected (whether in C or in Python)

Then, as you point out, there's a third thing: the old "buffer" object
from Python 2.x; but it should not be mentioned at all in the 3.x docs,
since it's completely gone.

Endly... to be honest, I don't understand what the sentence you've
quoted is supposed to mean :-(, so I don't know how to correct it.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6659>
_______________________________________

From report at bugs.python.org  Thu Aug  6 20:13:00 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Aug 2009 18:13:00 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1249582380.78.0.183686791014.issue6594@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As Raymond said, and besides, when you talk about "penalty", please
explain what the baseline is. Otherwise it's a bit hard to follow.

(and I stress again that SPARC is a nich platform, even Niagara :-);
moreover, Niagara is throughput-oriented rather than latency-oriented,
so poor single-threaded performance shouldn't be much of a surprise)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________

From report at bugs.python.org  Thu Aug  6 20:19:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Aug 2009 18:19:01 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1249582741.04.0.0669700400433.issue6598@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it ok if the message id is predictable?
Besides, _gen_next_number() can more efficiently be written as:

_gen_next_number = itertools.cycle(xrange(N))

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Thu Aug  6 20:46:50 2009
From: report at bugs.python.org (Shawn)
Date: Thu, 06 Aug 2009 18:46:50 +0000
Subject: [issue6594] json C serializer performance tied to structure depth on
	some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1249584410.51.0.0369251240652.issue6594@psf.upfronthosting.co.za>


Shawn <swalker at opensolaris.org> added the comment:

First, I want to apologise for not providing more detail initially. 
Notably, one thing you may want to be aware of is that I'm using python
2.4.4 with the latest version of simplejson.  So my timings and
assumptions here are based on the fact that simplejson was adopted as
the 'json' module in python, and I filed the bug here as it appeared
that is where bugs are being tracked for the json module.

To answer your questions though, no, I can't say with certainty that
recursion depth is the issue.  That's just a theory proposed by a
developer intimately familiar with SPARC architecture, who said register
windows on SPARC tend to cause recursive call structures to execute
poorly.  It also seemed to play itself out empirically throughout
testing I performed where any reduction in the depth of the structure
would shave seconds off the write times on the SPARC systems I tested.

I'm also willing to try many of the other things you listed, but I will
have to get back to you on that as I have a project coming due soon.

With that said, I can provide sample data soon, and will do so.  I'll
attach the resulting gzip'd JSON file to make it easy to read and dump.

I would also note that:

* I have tried serialising using cStringIO, which made no significant
difference in performance.

* I have tried different memory allocators, which only seemed to make
things slower, or made little difference.

* Writing roughly the same amount of data (in terms of megabytes), but
in a flatter structure, also increased the performance of the serializer.

* In my testing, it seemed dict serialisation in particular was
problematic from a performance standpoint.

* If I recall correctly from the profile I did, iterencode_dict was
where most of the time was eaten, but I can redo the profile for a more
accurate analysis.

As for Antoine's comments:

I'd like to believe Python is very useful software, and any platform it
it runs on means that the respective market capitalization of the
platform is irrelevant; better performing Python is always good.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________

From report at bugs.python.org  Thu Aug  6 21:13:03 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 06 Aug 2009 19:13:03 +0000
Subject: [issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 !=
	6.9999999999999984e-308
In-Reply-To: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>
Message-ID: <1249585983.84.0.0217409324908.issue6646@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

It is a powerpc 64-bit AIX machine:

>>> os.uname()
('AIX', 'asaixv5152', '1', '5', '000C763E4C00')
>>> platform.uname()
('AIX', 'asaixv5152', '1', '5', '000C763E4C00', 'powerpc')

The commands you have requested:

>>> from sys import float_info
>>> float_info
sys.floatinfo(max=1.7976931348623157e+308, max_exp=1024, 
max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, 
min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.2204460492503131e-16, 
radix=2, rounds=1)
>>> from pickle import dumps, loads
>>> x = 7e-308
>>> x
6.9999999999999994e-308
>>> p = [dumps(x, proto) for proto in range(3)]
>>> p
['F6.9999999999999994e-308\n.', 'G\x00)*\xee\xa4Z\xae\xdf.', '\x80\x02G
\x00)*\xee\xa4Z\xae\xdf.']
>>> up = [loads(z) for z in p]
>>> up
[6.9999999999999984e-308, 6.9999999999999994e-308, 
6.9999999999999994e-308]
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6646>
_______________________________________

From report at bugs.python.org  Thu Aug  6 21:51:50 2009
From: report at bugs.python.org (Rodrigo Steinmuller Wanderley)
Date: Thu, 06 Aug 2009 19:51:50 +0000
Subject: [issue2637] urllib.quote() escapes characters unnecessarily and
	contrary to docs
In-Reply-To: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>
Message-ID: <1249588310.23.0.655352401243.issue2637@psf.upfronthosting.co.za>


Rodrigo Steinmuller Wanderley <rodrigoswanderley at gmail.com> added the comment:

> Unreserved characters can be escaped without changing the semantics
> of the URI, but this should not be done unless the URI is being used
> in a context that does not allow the unescaped character to appear.

How can we identify "a context that does not allow the unescaped
character to appear"?

----------
nosy: +rwanderley

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2637>
_______________________________________

From report at bugs.python.org  Thu Aug  6 22:10:19 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 06 Aug 2009 20:10:19 +0000
Subject: [issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 !=
	6.9999999999999984e-308
In-Reply-To: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>
Message-ID: <1249589419.97.0.757223380749.issue6646@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  So pickle protocol 0 is where it's failing;  protocols 1 and 2 
are okay.  It looks as though there's a problem with double <-> string 
(i.e., binary <-> decimal) conversion here.

This probably also means that there are more serious problems on AIX, 
e.g., that float(repr(x)) == x fails for at least some Python floats x.  
That is, on my system:

>>> x = 7e-308
>>> float(repr(x)) == x
True

I expect that you'd get 'False' for this.  Is that right?  If you do get 
False, does this happen for any randomly chosen float x, or is it just 
very small values like the above that are problematic?

Is there any chance the FPU rounding mode has somehow been set to 
something other than round-to-nearest?  (It seems unlikely, but it's 
worth checking.)

These bits of Python are based on the assumption that conversion of an 
IEEE 754-format C double to a decimal string with 17 significant digits 
and back again recovers the original double.  A conforming hosted 
implementation of C99 that defines __STDC_IEC_559__ should satisfy this 
assumption (see Appendix F of the standard, especially section F.5);  
the IEEE 754 standard also recommends this behaviour.

So if your C implementation defines __STDC_IEC_559__ then this can 
reasonably be considered a platform bug.  Does it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6646>
_______________________________________

From report at bugs.python.org  Thu Aug  6 22:10:48 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Aug 2009 20:10:48 +0000
Subject: [issue6661] Transient test_multiprocessing failure
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I just got the following test_multiprocessing error (cannot reproduce,
though):

test test_multiprocessing failed -- Traceback (most recent call last):
  File
"/home/antoine/cpython/seek-6629/Lib/test/test_multiprocessing.py", line
232, in test_active_children
    self.assertTrue(p in self.active_children())
AssertionError: False is not True

----------
assignee: jnoller
components: Library (Lib), Tests
messages: 91383
nosy: jnoller, pitrou
priority: normal
severity: normal
status: open
title: Transient test_multiprocessing failure
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________

From report at bugs.python.org  Thu Aug  6 22:33:39 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 06 Aug 2009 20:33:39 +0000
Subject: [issue6661] Transient test_multiprocessing failure
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1249590819.91.0.826450976203.issue6661@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

ugh. that's not useful. Dunno how I'm going to track down seemingly random 
and unreproducible issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________

From report at bugs.python.org  Thu Aug  6 22:36:35 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Aug 2009 20:36:35 +0000
Subject: [issue6661] Transient test_multiprocessing failure
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1249590995.06.0.780512768177.issue6661@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I know, I was posting it for completeness, and it case someone else
witnesses it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________

From report at bugs.python.org  Thu Aug  6 22:40:01 2009
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 06 Aug 2009 20:40:01 +0000
Subject: [issue6661] Transient test_multiprocessing failure
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1249591201.01.0.780378372632.issue6661@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I know, just makes me :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________

From report at bugs.python.org  Thu Aug  6 22:52:26 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Aug 2009 20:52:26 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1249591946.36.0.466342554358.issue6603@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm afraid you'll have to investigate a bit by yourself, or wait for a
core developer to get the same problem :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Thu Aug  6 22:54:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Aug 2009 20:54:08 +0000
Subject: [issue6629] seek doesn't properly handle file buffer,
	leads to silent data corruption
In-Reply-To: <1249264841.18.0.232875994092.issue6629@psf.upfronthosting.co.za>
Message-ID: <1249592048.94.0.871124258593.issue6629@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the patch + tests in r74336 (trunk), r74338 (py3k) and
r74339 (3.1).
Thanks for the report, and don't hesitate to do more stress testing of
the IO lib!

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6629>
_______________________________________

From report at bugs.python.org  Thu Aug  6 23:56:20 2009
From: report at bugs.python.org (kee nethery)
Date: Thu, 06 Aug 2009 21:56:20 +0000
Subject: [issue6660] Desire python.org documentation link to user contribution
	wiki (per function)
In-Reply-To: <1249581403.05.0.319344126589.issue6660@psf.upfronthosting.co.za>
Message-ID: <CFD6A54C-C710-47E9-8340-5495B94EB655@kagi.com>


kee nethery <kee at kagi.com> added the comment:

Georg,
So there will be a link next to each numbered section in the  
documentation that links to a user editable wiki page about that  
section?
That will be highly useful. Glad to hear it. I know I'd like to  
contribute the gotchas I was confused by and the sample code snippets  
that solved a specific generic problem. Having more sample code linked  
from each numbered section in the docs would make my life easier when  
trying to learn Python.
Kee Nethery

On Aug 6, 2009, at 10:56 AM, Georg Brandl wrote:

>
> Georg Brandl <georg at python.org> added the comment:
>
> This is already in planning; Sphinx will grow a webapp system that  
> also
> allows suggestions for changes.
>
> ----------
> resolution:  -> later
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6660>
> _______________________________________

-------------------------------------------------
I check email roughly 2 to 3 times per business day.
Kagi main office: +1 (510) 550-1336

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________

From report at bugs.python.org  Fri Aug  7 00:38:33 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Aug 2009 22:38:33 +0000
Subject: [issue6660] Desire python.org documentation link to user contribution
	wiki (per function)
In-Reply-To: <1249580984.63.0.922866340136.issue6660@psf.upfronthosting.co.za>
Message-ID: <1249598313.09.0.395016293451.issue6660@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

There will be comments for each function/class etc., as well as a
feature to suggest a change for the proper text of a section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________

From report at bugs.python.org  Fri Aug  7 00:55:57 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 06 Aug 2009 22:55:57 +0000
Subject: [issue3600] Include Tcl/Tk 8.5.4 in the windows binary for the
	upcoming beta3
In-Reply-To: <1219160248.58.0.797023815673.issue3600@psf.upfronthosting.co.za>
Message-ID: <1249599357.68.0.325687718767.issue3600@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3600>
_______________________________________

From report at bugs.python.org  Fri Aug  7 00:56:54 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 06 Aug 2009 22:56:54 +0000
Subject: [issue3438] PyCF_DONT_IMPLY_DEDENT can be used to activate the with
	statement
In-Reply-To: <1216915140.34.0.387873405525.issue3438@psf.upfronthosting.co.za>
Message-ID: <1249599414.73.0.956957337052.issue3438@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This isn't going to happen, closing.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3438>
_______________________________________

From report at bugs.python.org  Fri Aug  7 03:25:10 2009
From: report at bugs.python.org (Dave Day)
Date: Fri, 07 Aug 2009 01:25:10 +0000
Subject: [issue6662] HTMLParser.HTMLParser doesn't handle malformed charrefs
In-Reply-To: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
Message-ID: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>


New submission from Dave Day <dayveday at gmail.com>:

When HTMLParser.HTMLParser encounters a malformed charref (for example 
&#bad;) it no longer parsers the following HTML correctly.

For example:
  <p>&#bad;</p>
Recognises the starttag "p" but considers the rest to be data.

To reproduce:
class MyParser(HTMLParser.HTMLParser):
  def handle_starttag(self, tag, attrs):
    print 'Start "%s"' % tag
  def handle_endtag(self,tag):
    print 'End "%s"' % tag
  def handle_charref(self, ref):
    print 'Charref "%s"' % ref
  def handle_data(self, data):
    print 'Data "%s"' % data
parser = MyParser()
parser.feed('<p>&#bad;</p>')
parser.close()

Expected output:
Start "p"
Data "&#bad;"
End "p"

Actual output:
Start "p"
Data "&#bad;</p>"

----------
components: Library (Lib)
messages: 91392
nosy: dayveday
severity: normal
status: open
title: HTMLParser.HTMLParser doesn't handle malformed charrefs
type: behavior
versions: Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6662>
_______________________________________

From report at bugs.python.org  Fri Aug  7 08:00:14 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Fri, 07 Aug 2009 06:00:14 +0000
Subject: [issue6663] re.findall does not always return a list of strings
In-Reply-To: <1249624814.45.0.837975483748.issue6663@psf.upfronthosting.co.za>
Message-ID: <1249624814.45.0.837975483748.issue6663@psf.upfronthosting.co.za>


New submission from Phillip M. Feldman <pfeldman at verizon.net>:

As per the Python documentation, the following regular expression should
produce a list containing the strings '6.7', 7.33', and '9':

re.findall('(-?\d+[.]\d+)|(-?\d+[.]?)|(-?[.]\d+)', 'asdf6.7jjjj7.33ff9')

Instead, it generates a list of tuples.  Either the documentation should
be changed to make it consistent with what re.findall is actually doing,
or, better yet, re.findall should be fixed.

----------
components: Regular Expressions
messages: 91393
nosy: pfeldman at verizon.net
severity: normal
status: open
title: re.findall does not always return a list of strings
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6663>
_______________________________________

From report at bugs.python.org  Fri Aug  7 10:03:42 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Fri, 07 Aug 2009 08:03:42 +0000
Subject: [issue6659] buffer c-api: memoryview object documentation
In-Reply-To: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>
Message-ID: <1249632222.9.0.932073191821.issue6659@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

Antoine, it seems, this sentence was taken literally from PEP3118
(http://www.python.org/dev/peps/pep-3118/#new-c-api-calls-are-proposed).
PEP authors discussed if __builtins__.buffer should be removed.

I agree, old __builtins__.buffer should not be mentioned here at all.

I think, the best way to fix is to describe what is memoryview at the
C-level and properly document its C API. For example,
PyMemoryView_GetContiguous is not documented here at all (some
documentation is in header file - see memoryobject.h). I suggest
rewriting the whole section (see below). 

Notes:

1. I haven't documented #define's from memoryview.h - do we need to? 

2. I have renamed 'fort' to 'order'. It sounds much better now I
think... Can we also change memoryview.h to use 'order'? I also want to
rename 'obj' to 'buffer'. What do you think? It will simplify
description of these functions...

3. I haven't documented 'buffertype'. Feel free to do so ;-) There's
some text in PEP3118, in memoryview.h and memoryview.c.

MemoryView objects
==================

PyMemoryViewObject is a subtype of PyObject representing Python
:class:`memoryview` object.

.. cfunction:: PyObject* PyMemoryView_FromObject(PyObject *obj)

   Return a memoryview object from an object that defines the buffer
interface.

.. cfunction:: PyObject * PyMemoryView_GetContiguous(PyObject *obj,  int
buffertype, char order)

   Return a memoryview object to a contiguous chunk of memory (in either
'C' or 'F'ortran order) from an object that defines the buffer
interface. If memory is contiguous, the memoryview object points to the
original memory. Otherwise copy is made and the memoryview points to a
new bytes object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6659>
_______________________________________

From report at bugs.python.org  Fri Aug  7 10:45:54 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 Aug 2009 08:45:54 +0000
Subject: [issue6632] Include more fullwidth chars in the decimal codec
In-Reply-To: <1249567474.38.0.367548603962.issue6632@psf.upfronthosting.co.za>
Message-ID: <4A7BE9BE.1010601@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Dickinson wrote:
> 
> I'm less concerned about decimal points and the like, and more bothered by 
> the fact that e.g., int(x, 16) accepts some, but not all, characters with 
> the Hex_Digit property.  This seems counter to the intent of the Unicode 
> standard.

int()/float() use the decimal codec for numbers - this only supports
base-10 numbers. For hex numbers, we'd need a new hex codec (only
the encoder part, actually), otherwise, int('a') would start to return
10.

Any takers ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6632>
_______________________________________

From report at bugs.python.org  Fri Aug  7 10:52:38 2009
From: report at bugs.python.org (rubisher)
Date: Fri, 07 Aug 2009 08:52:38 +0000
Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc
In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za>
Message-ID: <1249635158.69.0.368024801933.issue6006@psf.upfronthosting.co.za>


rubisher <rubisher at scarlet.be> added the comment:

Well a few spare time let me investigate this way: using gc[cj] libffi.

I so first install libffi-4.2.0-3 as well as libffi-devel-4.2.0-3 (not
sure this last one is required, though) then configure python (2.6) with
--with-system-ffi but it doesn't seems to be enough to locate libffi so
I added symbolic links:
/usr/lib/libffi.a -> ../../opt/freeware/lib/libffi.a

/usr/include/ffi.h -> \
../../opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/ffi.h
/usr/include/ffitarget.h -> \
../../opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/ffitarget.h

After that I reach to compile python2.6.2 without error and at a first
glance it seems to work fine (just rebuild bzr 1.17 and launch some
cmdl, ;<)).

Hope this could help for python3 and xlC,
    r.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6006>
_______________________________________

From report at bugs.python.org  Fri Aug  7 11:14:15 2009
From: report at bugs.python.org (Neil Hodgson)
Date: Fri, 07 Aug 2009 09:14:15 +0000
Subject: [issue6664] readlines should understand Line Separator and Paragraph
	Separator characters
In-Reply-To: <1249636455.06.0.336549280075.issue6664@psf.upfronthosting.co.za>
Message-ID: <1249636455.06.0.336549280075.issue6664@psf.upfronthosting.co.za>


New submission from Neil Hodgson <nyamatongwe at users.sourceforge.net>:

Unicode includes Line Separator U+2028 and Paragraph Separator U+2029
line ending characters. The readlines method of the file object returned
by the built-in open does not treat these characters as line ends
although the object returned by codecs.open(..., encoding='utf-8') does.

The attached program creates a UTF-8 file containing three lines with
the second line ended with a Paragraph Separator. The program then reads
this file back in as a text file. Only two lines are seen when reading
the file back in.

The desired behaviour is for the file to be read in as three lines.

----------
components: IO
files: lineends.py
messages: 91397
nosy: nyamatongwe
severity: normal
status: open
title: readlines should understand Line Separator and Paragraph Separator characters
versions: Python 3.1
Added file: http://bugs.python.org/file14671/lineends.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6664>
_______________________________________

From report at bugs.python.org  Fri Aug  7 11:49:19 2009
From: report at bugs.python.org (Josef Skladanka)
Date: Fri, 07 Aug 2009 09:49:19 +0000
Subject: [issue6665] fnmatch fails on filenames containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>


New submission from Josef Skladanka <jskladan at redhat.com>:

Hello,
at the moment, fnmatch.fnmatch() will fail to match any string, which
has \n character. This of course breaks glob as well.

Example

> import fnmatch
> fnmatch.fnmatch("foo\nbar", "foo*")
False

> import glob
> open("foobar", "w").close()
> open("foo\nbar", "w").close()
> glob.glob("foo*")
['foobar']

while the expected result is ['foobar', 'foo\nbar']. The standard C
fnmatch function from fnmatch.h is behaving correctly i.e. this code
will print out "match!"

#include <fnmatch.h>
#include <stdio.h>

int main()
{
    if (fnmatch("foo*", "foo\nbar", FNM_NOESCAPE) == 0)
        printf("match!\n");
    else
        printf("fail!\n");
    return 0;
}


This misbehaviour is caused by the fnmatch.translate() which adds $ to
the end of the regexp. Without the ending $ the fnmatch function works OK.

----------
components: Library (Lib)
messages: 91398
nosy: rajcze
severity: normal
status: open
title: fnmatch fails on filenames containing \n character
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6665>
_______________________________________

From report at bugs.python.org  Fri Aug  7 11:50:15 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 07 Aug 2009 09:50:15 +0000
Subject: [issue6666] List of dirs to ignore in trace.py is applied only for
	the first file
In-Reply-To: <1249638615.65.0.163009414102.issue6666@psf.upfronthosting.co.za>
Message-ID: <1249638615.65.0.163009414102.issue6666@psf.upfronthosting.co.za>


New submission from Bogdan Opanchuk <bg at bk.ru>:

When creating a trace.Trace object or running trace.py one can specify
list of directories to ignore (ignoredirs or --ignore-dir
correspondingly). It is passed to trace.Ignore constructor, which stores
iterator to map(), applied to this list, in self._dirs. So, when
Ignore.names() execution passes to the block "for d in self._dirs:" for
the first time, iterator saves its state (in the end of the list) and
next times the code in this block is completely ignored. The result is
that 'ignoredirs' parameter does not actually work (except for the one
lucky file).

Proposed patch is attached.

----------
components: Library (Lib)
files: trace.diff
keywords: patch
messages: 91399
nosy: bogdan.opanchuk
severity: normal
status: open
title: List of dirs to ignore in trace.py is applied only for the first file
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14672/trace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6666>
_______________________________________

From report at bugs.python.org  Fri Aug  7 11:53:31 2009
From: report at bugs.python.org (maro)
Date: Fri, 07 Aug 2009 09:53:31 +0000
Subject: [issue6667] logging config - using FileHandler's delay argument?
In-Reply-To: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>
Message-ID: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>


New submission from maro <misgis at gmail.com>:

I'm not sure, if it's an issue. I don't know how to use argument 'delay'
of FileHandler in my logging.conf file.

[handler_tarFileHandler]
class=FileHandler
level=DEBUG
formatter=simpleFormatter
args=('/tmp/_tar2ncConverter.log','a+')
delay=True # file is created only when first message is emited (delay =
True), not working, empty file is always created...

If I put delay to FileHandler's constructor args
('/tmp/_tar2ncConverter.log','a+',None,True) I get error message about
missing arguments. It is an issue, or just my wrong arranged args?

regards 
maro

----------
components: None
messages: 91400
nosy: maro
severity: normal
status: open
title: logging config - using FileHandler's delay argument?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6667>
_______________________________________

From report at bugs.python.org  Fri Aug  7 12:02:56 2009
From: report at bugs.python.org (maro)
Date: Fri, 07 Aug 2009 10:02:56 +0000
Subject: [issue6667] logging config - using of FileHandler's delay argument?
In-Reply-To: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>
Message-ID: <1249639376.12.0.574983756014.issue6667@psf.upfronthosting.co.za>


Changes by maro <misgis at gmail.com>:


----------
title: logging config - using FileHandler's delay argument? -> logging config - using of FileHandler's delay argument?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6667>
_______________________________________

From report at bugs.python.org  Fri Aug  7 14:23:36 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Fri, 07 Aug 2009 12:23:36 +0000
Subject: [issue6663] re.findall does not always return a list of strings
In-Reply-To: <1249624814.45.0.837975483748.issue6663@psf.upfronthosting.co.za>
Message-ID: <1249647816.27.0.870888494795.issue6663@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

You've made three groups with parentheses. Just drop them:

>>> re.findall('-?\d+[.]\d+|-?\d+[.]?|-?[.]\d+', 'asdf6.7jjjj7.33ff9')
['6.7', '7.33', '9']

Everything is according to documentation: "If one or more groups are
present in the pattern, return a list of groups; this will be a list of
tuples if the pattern has more than one group."

http://docs.python.org/library/re.html#re.findall

I would suggest to close this bug.

----------
nosy: +ash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6663>
_______________________________________

From report at bugs.python.org  Fri Aug  7 14:41:04 2009
From: report at bugs.python.org (albert Mietus)
Date: Fri, 07 Aug 2009 12:41:04 +0000
Subject: [issue6631] urlparse.urlunsplit() can't handle relative files (for
	urllib*.open()
In-Reply-To: <1249306383.87.0.829314243328.issue6631@psf.upfronthosting.co.za>
Message-ID: <1249648864.81.0.545130158191.issue6631@psf.upfronthosting.co.za>


albert Mietus <albert at mietus.nl> added the comment:

There was a bug in the workaround:

    if not ( scheme == 'file' and not netloc and url[0] != '/'):
---------------------------------------------=================---

The {{{and url[0] != '/'}}} was missing (above is corrected)

The effect: split/unspilt file:///path resulted in file:/path

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6631>
_______________________________________

From report at bugs.python.org  Fri Aug  7 15:36:31 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 07 Aug 2009 13:36:31 +0000
Subject: [issue1135] xview/yview of Tix.Grid is broken
In-Reply-To: <1189314445.29.0.484479560219.issue1135@psf.upfronthosting.co.za>
Message-ID: <1249652191.66.0.67472525426.issue1135@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I've looked into this again and now I'm attaching a patch very similar
to xview_yview.patch. Is anyone against adding these mixins ?

----------
Added file: http://bugs.python.org/file14673/xview_yview_mixins.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1135>
_______________________________________

From report at bugs.python.org  Fri Aug  7 16:34:34 2009
From: report at bugs.python.org (Vlada Peric)
Date: Fri, 07 Aug 2009 14:34:34 +0000
Subject: [issue6668] locale.py: can't parse sr_RS@latin locale
In-Reply-To: <1249655674.35.0.635015975428.issue6668@psf.upfronthosting.co.za>
Message-ID: <1249655674.35.0.635015975428.issue6668@psf.upfronthosting.co.za>


New submission from Vlada Peric <vlada.peric at gmail.com>:

The sr_RS locale in glibc corresponds to the Cyrillic script, while the 
agreed upon locale for the Latin alphabet is sr_RS at latin. Unfortunately, 
the locale python module crashes when trying to parse this locale. Here 
is the traceback:

File "/usr/lib/python2.6/locale.py", line 497, in get locale
  return _parse_localename(localename)
File "usr/lib/python2.6/locale.py", line 410, in _parse_localename
  raise ValueError, 'unknown locale: %s' % localename

Looking at the code, it only checks for the @euro modifier and ignores 
all other modifiers (including @latin). This is all when I set 
LANG=sr_RS at latin. If I use LANG=sr_RS.UTF8 at latin (also allowed by 
glibc), Python interprets this as the sr_RS locale (which is wrong, as 
that is for Cyrillic).

----------
components: Unicode
messages: 91404
nosy: VPeric
severity: normal
status: open
title: locale.py: can't parse sr_RS at latin locale
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6668>
_______________________________________

From report at bugs.python.org  Fri Aug  7 16:41:18 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 07 Aug 2009 14:41:18 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1249656078.92.0.63342147423.issue1028@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Attaching a patch against trunk, I believe this solves the problems
described here.

----------
versions: +Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14674/issue1028.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Fri Aug  7 17:53:33 2009
From: report at bugs.python.org (kee nethery)
Date: Fri, 07 Aug 2009 15:53:33 +0000
Subject: [issue6660] Desire python.org documentation link to user contribution
	wiki (per function)
In-Reply-To: <1249598313.09.0.395016293451.issue6660@psf.upfronthosting.co.za>
Message-ID: <01ED5C33-AF57-4482-9E60-55B6207A6115@kagi.com>


kee nethery <kee at kagi.com> added the comment:

awesome. looking forward to it.
Kee

On Aug 6, 2009, at 3:38 PM, Georg Brandl wrote:

>
> Georg Brandl <georg at python.org> added the comment:
>
> There will be comments for each function/class etc., as well as a
> feature to suggest a change for the proper text of a section.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6660>
> _______________________________________

-------------------------------------------------
I check email roughly 2 to 3 times per business day.
Kagi main office: +1 (510) 550-1336

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________

From report at bugs.python.org  Fri Aug  7 18:19:52 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Aug 2009 16:19:52 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1249661992.19.0.698446867876.issue6626@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Fri Aug  7 18:20:02 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 07 Aug 2009 16:20:02 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1249662002.61.0.542256294291.issue6627@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Fri Aug  7 18:43:35 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 07 Aug 2009 16:43:35 +0000
Subject: [issue6168] Missing Shell menu in Linux IDLE
In-Reply-To: <1243889984.38.0.346185167721.issue6168@psf.upfronthosting.co.za>
Message-ID: <1249663415.12.0.904978722586.issue6168@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

>From what I read here this is not a problem caused by the sources
distributed by python.org, so I'm closing this. It seems more
appropriate to move this to Ubuntu's bug tracker.

----------
nosy: +gpolo
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6168>
_______________________________________

From report at bugs.python.org  Fri Aug  7 19:35:11 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 07 Aug 2009 17:35:11 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1249666511.95.0.963517793639.issue1028@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Uhm, in the long run I believe it will be better to move to
Tcl_CreateObjCommand since it is said that commands created by it are
significantly faster than the ones created by Tcl_CreateCommand (more
information about this can be found at tcl documentation).

I'm only writing this because, as other places that deal with tcl
objects, more care must be taken. For instance, I have applied the
issue1028.diff on the tk_and_idle_maintenance branch and found two
problems that are now patched by adjusts1.diff. It is very likely that
there are other bugs around, I'll be trying some tkinter applications to
try to find some of them but help is very much needed. Note that there
are some tkinter tests on this tk_and_idle_maintenance and they all
pass, but they do not fully cover tkinter at this moment so improving
them would be good too.

----------
Added file: http://bugs.python.org/file14675/adjusts1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Fri Aug  7 20:05:48 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 07 Aug 2009 18:05:48 +0000
Subject: [issue1628205] socket.readline() interface doesn't handle EINTR
	properly
Message-ID: <1249668348.78.0.137341974318.issue1628205@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

realistically, file objects (Objects/fileobject.c) never raise EINTR as 
they use the C library fread/fwrite/fclose underneath.  Why should a 
socket based file object every be allowed to raise EINTR rather than 
handling it internally?

IMHO people should only expect to handle EINTR when doing 
socket.send/recv or os.read/write/close, not using a file-like object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628205>
_______________________________________

From report at bugs.python.org  Fri Aug  7 21:34:17 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 07 Aug 2009 19:34:17 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1249582741.04.0.0669700400433.issue6598@psf.upfronthosting.co.za>
Message-ID: <96486.68664.qm@web32806.mail.mud.yahoo.com>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

--- El jue 6-ago-09, Antoine Pitrou <report at bugs.python.org> escribi?:

> Antoine Pitrou <pitrou at free.fr>
> added the comment:
> 
> Is it ok if the message id is predictable?

I don't know of any use of message ids apart from uniquely identifying the message, but we could still keep a random part followed by the sequence.

> Besides, _gen_next_number() can more efficiently be written
> as:
> 
> _gen_next_number = itertools.cycle(xrange(N))

Written that way it will eventually hold a list with 100000 integers forever.

      Yahoo! Cocina

Encontra las mejores recetas con Yahoo! Cocina.

http://ar.mujer.yahoo.com/cocina/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Fri Aug  7 21:46:19 2009
From: report at bugs.python.org (Phillip M. Feldman)
Date: Fri, 07 Aug 2009 19:46:19 +0000
Subject: [issue6663] re.findall does not always return a list of strings
In-Reply-To: <1249647816.27.0.870888494795.issue6663@psf.upfronthosting.co.za>
Message-ID: <4A7C8477.2060302@verizon.net>


Phillip M. Feldman <pfeldman at verizon.net> added the comment:

You are right-- the documentation does say this, although it took me a 
while to understand what it means.  Thanks!

It seems as though there's a flaw in the design here, because there 
should be some mechanism for grouping elements of a regular expression 
without having findall treat these as groups for purposes of packaging 
the output.  If someone really wants to get lists of tuples out of 
findall, then it might make sense to input a tuple of strings instead of 
a single string.

Phillip

Alexey Shamrin wrote:
> Alexey Shamrin <shamrin at gmail.com> added the comment:
>
> You've made three groups with parentheses. Just drop them:
>
>   
>>>> re.findall('-?\d+[.]\d+|-?\d+[.]?|-?[.]\d+', 'asdf6.7jjjj7.33ff9')
>>>>         
> ['6.7', '7.33', '9']
>
> Everything is according to documentation: "If one or more groups are
> present in the pattern, return a list of groups; this will be a list of
> tuples if the pattern has more than one group."
>
> http://docs.python.org/library/re.html#re.findall
>
> I would suggest to close this bug.
>
> ----------
> nosy: +ash
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6663>
> _______________________________________
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6663>
_______________________________________

From report at bugs.python.org  Fri Aug  7 21:59:18 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 07 Aug 2009 19:59:18 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1249675158.2.0.477979689936.issue6598@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Removed file: http://bugs.python.org/file14643/utils.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Fri Aug  7 21:59:53 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 07 Aug 2009 19:59:53 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1249675193.7.0.335846580404.issue6598@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Added file: http://bugs.python.org/file14676/utils.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Fri Aug  7 23:11:16 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 07 Aug 2009 21:11:16 +0000
Subject: [issue6669] TarFile.getmembers fails at struct.unpack: unpack
	requires a string argument of length 4
In-Reply-To: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>
Message-ID: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Perhaps this must be wrapped under a programmer-expected custom 
exception class (TarError maybe)

    for tarinfo in tarfileobj.getmembers():
  File "/home/apy/ActivePython-2.6/lib/python2.6/tarfile.py", line 
1791, in getmembers
    self._load()        # all members, we first have to
  File "/home/apy/ActivePython-2.6/lib/python2.6/tarfile.py", line 
2352, in _load
    tarinfo = self.next()
  File "/home/apy/ActivePython-2.6/lib/python2.6/tarfile.py", line 
2307, in next
    self.fileobj.seek(self.offset)
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 382, in 
seek
    self.read(1024)
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 219, in 
read
    self._read(readsize)
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 267, in 
_read
    self._read_eof()
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 300, in 
_read_eof
    crc32 = read32(self.fileobj)
  File "/home/apy/ActivePython-2.6/lib/python2.6/gzip.py", line 24, in 
read32
    return struct.unpack("<I", input.read(4))[0]
error: unpack requires a string argument of length 4

----------
components: Library (Lib)
messages: 91412
nosy: srid
severity: normal
status: open
title: TarFile.getmembers fails at struct.unpack: unpack requires a string argument of length 4
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6669>
_______________________________________

From report at bugs.python.org  Fri Aug  7 23:33:27 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 07 Aug 2009 21:33:27 +0000
Subject: [issue6527] test_ttk_guionly buildbot test crash:
	Tcl_FinalizeNotifier: notifier pipe not initialized
In-Reply-To: <1248125424.97.0.178196969881.issue6527@psf.upfronthosting.co.za>
Message-ID: <1249680807.73.0.612226995252.issue6527@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I notice this some time ago, let's continue this on issue5120. Can you
test the patch attached there on a mac ? I don't have one, so I'm not
sure if it fixes the issue or not.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6527>
_______________________________________

From report at bugs.python.org  Sat Aug  8 01:19:35 2009
From: report at bugs.python.org (Rhett Garber)
Date: Fri, 07 Aug 2009 23:19:35 +0000
Subject: [issue1628205] socket.readline() interface doesn't handle EINTR
	properly
Message-ID: <1249687175.88.0.836769632981.issue1628205@psf.upfronthosting.co.za>


Rhett Garber <rhettg at gmail.com> added the comment:

Good addition Gregory.
Totally agree on handling EINTR in even more cases.
You can't really expect the caller to know they need to deal with this
sort of thing when using these higher level call. The whole point is the
abstract away some of the complexity of dealing with the system call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628205>
_______________________________________

From report at bugs.python.org  Sat Aug  8 01:54:47 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 07 Aug 2009 23:54:47 +0000
Subject: [issue6663] re.findall does not always return a list of strings
In-Reply-To: <1249624814.45.0.837975483748.issue6663@psf.upfronthosting.co.za>
Message-ID: <1249689287.84.0.454095568259.issue6663@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

In a regular expression (...) will group and capture, whereas (?:...)
will only group and not capture.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6663>
_______________________________________

From report at bugs.python.org  Sat Aug  8 07:15:27 2009
From: report at bugs.python.org (Stuart Mentzer)
Date: Sat, 08 Aug 2009 05:15:27 +0000
Subject: [issue6461] multiprocessing: freezing apps on Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1249708527.45.0.913007486864.issue6461@psf.upfronthosting.co.za>


Stuart Mentzer <sgm at objexx.com> added the comment:

Further experimentation revealed that freeze_support() works properly
and the proposed patch is not necessary or desirable for the general
freeze case. In the case of an embedded app that calls set_executable()
it seems that the "else" block calling _python_exe should be taken but
won't be, so I still think there may be a problem here.

In our situation it turned out that an imported module was grabbing the
command line arguments before freeze_support() was called and when that
was addressed the need for a separate python executable and calling
set_executable() was eliminated.

I suggest that the documentation for freeze_support() make it clear that
it must get called before an application processes the arguments or that
the application must allow a --multiprocessing-fork option with a string
value so that the initialization continues until freeze_support() is called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6461>
_______________________________________

From report at bugs.python.org  Sat Aug  8 13:37:02 2009
From: report at bugs.python.org (Nir Soffer)
Date: Sat, 08 Aug 2009 11:37:02 +0000
Subject: [issue2637] urllib.quote() escapes characters unnecessarily and
	contrary to docs
In-Reply-To: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>
Message-ID: <1249731422.84.0.937752937479.issue2637@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

You can control what is safe in your particular context using the safe 
keyword argument.

How do you want to support unicode? you must decide which character 
encoding you like, which depends on the server side decoding the url.

Just document the fact that this function does not accept unicode.

----------
nosy: +nirs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2637>
_______________________________________

From report at bugs.python.org  Sat Aug  8 15:46:28 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 08 Aug 2009 13:46:28 +0000
Subject: [issue6461] multiprocessing: freezing apps on Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1249739188.33.0.867610043097.issue6461@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Thanks for following up on this Stuart - I'll update the docs accordingly

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6461>
_______________________________________

From report at bugs.python.org  Sat Aug  8 17:27:41 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 08 Aug 2009 15:27:41 +0000
Subject: [issue6667] logging config - using of FileHandler's delay argument?
In-Reply-To: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>
Message-ID: <1249745261.3.0.841161895319.issue6667@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Please attach a complete configuration file (with the delay parameter in
the args) and a short script which loads this configuration and
demonstrates the problem.

----------
nosy: +vsajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6667>
_______________________________________

From report at bugs.python.org  Sat Aug  8 17:29:53 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 08 Aug 2009 15:29:53 +0000
Subject: [issue6667] logging config - using of FileHandler's delay argument?
In-Reply-To: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>
Message-ID: <1249745393.77.0.500480442881.issue6667@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vsajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6667>
_______________________________________

From report at bugs.python.org  Sat Aug  8 17:43:03 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 08 Aug 2009 15:43:03 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1249746183.97.0.0791244398519.issue1028@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Today I noticed the StringObj manpage (from tcl) says that the bytes
that represent an tcl object should be treated as read-only (although it
uses char *) so this issue1028.diff may very well cause a segfault at
some point.

I'm attaching a new patch that fixes this and also uses
Tcl_GetStringFromObj, instead of directly accessing the bytes member of
a tcl object, so we know its string representation is not invalid.

----------
Added file: http://bugs.python.org/file14677/issue1028_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Sat Aug  8 18:32:56 2009
From: report at bugs.python.org (Sandip Thorat)
Date: Sat, 08 Aug 2009 16:32:56 +0000
Subject: [issue6617] During compiling python 3.1 getting error Undefined
	symbol libintl_bind_textdomain_codeset
In-Reply-To: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>
Message-ID: <1249749176.28.0.443339969656.issue6617@psf.upfronthosting.co.za>


Sandip Thorat <thoratsandip at gmail.com> added the comment:

Plz assist to install Python on Solaris_x86

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6617>
_______________________________________

From report at bugs.python.org  Sat Aug  8 21:50:07 2009
From: report at bugs.python.org (brimac)
Date: Sat, 08 Aug 2009 19:50:07 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>


New submission from brimac <brimac at bcs.org>:

I am having a problem when printing 'The Python Tutorial' at
http://docs.python.org/tutorial/
I am using XP and Firefox and an HP Laserjet.
The page displays OK but the printout has a 68 mm margin on the left.
The margin on the right is 18 mm but the text is cut off, sometimes
mid-letter. The other 14 pages in the tutorial have the same problem.
I've tried changing from Portrait to Landscape. The text gets wider, the
margins are the same size, and the text is still cut off.
I have not noticed this with any other documents, on this website or
elsewhere. I'm sure if you print/preview you will see the problem.
My guess is that there is a fault with the printout file at python.org

----------
assignee: georg.brandl
components: Documentation
messages: 91422
nosy: brimac, georg.brandl
severity: normal
status: open
title: Printing the 'The Python Tutorial'
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6670>
_______________________________________

From report at bugs.python.org  Sat Aug  8 23:26:48 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 Aug 2009 21:26:48 +0000
Subject: [issue6583] 2to3 fails to fix test.test_support
In-Reply-To: <1248672082.21.0.412952291584.issue6583@psf.upfronthosting.co.za>
Message-ID: <1249766808.35.0.428522523951.issue6583@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We decided a while ago that it wasn't worth adding the complication to
fix_imports to handle this case, since test.test_support isn't
technically public API.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6583>
_______________________________________

From report at bugs.python.org  Sun Aug  9 03:28:49 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 09 Aug 2009 01:28:49 +0000
Subject: [issue6557] urllib.urlopen creates bad requests when location header
	of 301 redirects contain spaces
In-Reply-To: <1248385969.73.0.0313821964129.issue6557@psf.upfronthosting.co.za>
Message-ID: <1249781329.91.0.219499677991.issue6557@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

This bug is already fixed in trunk (Python2.7) and py3k branch -
Issue918368.

I see that the fix was not backported, I shall do that (once the svn is up).

----------
resolution:  -> accepted
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6557>
_______________________________________

From report at bugs.python.org  Sun Aug  9 03:32:17 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 09 Aug 2009 01:32:17 +0000
Subject: [issue1712522] urllib.quote throws exception on Unicode URL
Message-ID: <1249781537.75.0.60244356278.issue1712522@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
resolution:  -> accepted
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1712522>
_______________________________________

From report at bugs.python.org  Sun Aug  9 05:49:16 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 09 Aug 2009 03:49:16 +0000
Subject: [issue2637] urllib.quote() escapes characters unnecessarily and
	contrary to docs
In-Reply-To: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>
Message-ID: <1249789756.22.0.315246715195.issue2637@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

The way to handle this issue would be add these characters 
'%/:=&?~#+!$,;'@()*[]' to always_safe list.

There has been a similar issue in the past Issue918368, tough in a
different context.

And if you see, urllib.urlopen function always passes these values as 
the safe parameter to the quote function,

fullurl = quote(fullurl, safe="%/:=&?~#+!$,;'@()*[]")

Handling of unicode is a different issue, but for the current report,
this change should suffice.

----------
assignee: georg.brandl -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2637>
_______________________________________

From report at bugs.python.org  Sun Aug  9 07:38:27 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 09 Aug 2009 05:38:27 +0000
Subject: [issue6667] logging config - using of FileHandler's delay argument?
In-Reply-To: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>
Message-ID: <1249796307.16.0.801500279373.issue6667@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6667>
_______________________________________

From report at bugs.python.org  Sun Aug  9 12:35:26 2009
From: report at bugs.python.org (Aliaksandr Stelmachonak)
Date: Sun, 09 Aug 2009 10:35:26 +0000
Subject: [issue6671] webbrowser.py doesn't respect xfce default browser
In-Reply-To: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>
Message-ID: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>


New submission from Aliaksandr Stelmachonak <mail.avatar at gmail.com>:

Currently webbrowser.py only trying to use GNOME and KDE default browser 
setting. This patch adds launching Xfce default browser if xfce environment detected.

----------
components: Library (Lib)
files: webbrowser.py.patch
keywords: patch
messages: 91426
nosy: ava1ar
severity: normal
status: open
title: webbrowser.py doesn't respect xfce default browser
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14678/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6671>
_______________________________________

From report at bugs.python.org  Sun Aug  9 13:40:01 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Aug 2009 11:40:01 +0000
Subject: [issue6663] re.findall does not always return a list of strings
In-Reply-To: <1249624814.45.0.837975483748.issue6663@psf.upfronthosting.co.za>
Message-ID: <1249818001.58.0.914403864947.issue6663@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6663>
_______________________________________

From report at bugs.python.org  Sun Aug  9 14:24:50 2009
From: report at bugs.python.org (=?utf-8?q?Jan_Schl=C3=BCter?=)
Date: Sun, 09 Aug 2009 12:24:50 +0000
Subject: [issue6672] Add Mingw recognition to pyport.h to allow building
	extensions
In-Reply-To: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>
Message-ID: <1249820690.51.0.767085753138.issue6672@psf.upfronthosting.co.za>


New submission from Jan Schl?ter <python-bugs at jan-schlueter.de>:

This addresses missing statements for recognizing the Mingw compiler in 
pyport.h, needed to build several extension modules on Windows using 
Mingw. I will first explain the background, then indicate what needs to 
be changed and end with some pointers to "related work".

Pyport.h of Python 2.5 and 2.6 (I do not have other versions to check) 
addresses an issue with Cygwin's gcc by preventing the declaration of 
"__declspec(dllimport)" for function definitions (using the PyAPI_FUNC
(RTYPE) makro), relying on the compiler's auto-import definition 
instead, because the compiler would not otherwise throw an "initializer 
element is not constant" error when using e.g. PyObject_GenericGetAttr 
in a PyTypeObject declaration of a C/C++ extension module (more 
generally, whenever an imported Python API function is used as a 
constant).
Python 2.6.2 (r262:71605) and Python 2.5.4 (r254:67916) do not check 
for the Mingw compiler in pyport.h, although Mingw behaves the same as 
the Cygwin version, at least regarding the "__declspec" declaration.

To fix that, each check for __CYGWIN__ in pyport.h should also check 
for __MINGW32___ to behave the same way. svn.python.org currently does 
not reply, so I can not create a patch against the trunk nor check 
whether this issue has already been addressed.

Issue 5046 included a patch to pyport.h fixing this, but it has been 
rejected due to other suggested changes that were not mature.
http://recipes.gobolinux.org/r/?list=Python&ver=3.1-
r1&file=arm/20061116160247-
bf48b-7db78fe2f80b3137ce349cf4314364768555ff50.gz.diff suggests the 
same change.
http://www.indashpc.org/vbullettin/viewtopic.php?p=5003#5003 gives some 
more background information on how I found and fixed the problem.
An internet search for "python initializer element is not constant" 
shows that numerous people have been encountering this problem when 
trying to build a python extension module.

----------
components: Build
messages: 91427
nosy: f0k
severity: normal
status: open
title: Add Mingw recognition to pyport.h to allow building extensions
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6672>
_______________________________________

From report at bugs.python.org  Sun Aug  9 16:09:45 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 09 Aug 2009 14:09:45 +0000
Subject: [issue6673] Py3.1 hangs in coroutine and eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Here's a simple coroutine that works perfectly in Python 2.6 but seems
to let Py3.1 enter an infinite loop that ends up eating all memory.

-----------------
def printing_sink():
    "A simple sink that prints the received values."
    while True:
        print( (yield) )

def chunker(chunk_size, target):
    """Receives single items and forwards chunks of a fixed size.

    Usage example:
    >>> sink = printing_sink()
    >>> next(sink)
    >>> cr = chunker(4, sink)
    >>> next(cr)

    >>> for i in range(8):
    ...    cr.send(i)
    [0, 1, 2, 3]
    [4, 5, 6, 7]
    >>> cr.close()
    """
    while True:
        target.send([ (yield) for i in range(chunk_size) ])

if __name__ == '__main__':
    import doctest
    doctest.testmod()
-----------------

Fails on:
Python 3.1 (r31:73572, Jun 28 2009, 21:07:35)
[GCC 4.3.2] on linux2

Works on:
Python 2.6.2 (r262:71600, Apr 17 2009, 11:29:30)
[GCC 4.3.2] on linux2

The problem seems to be the list comprehension. When I replace it with a
normal for-loop, it works perfectly.

----------
components: Interpreter Core
messages: 91428
nosy: scoder
severity: normal
status: open
title: Py3.1 hangs in coroutine and eats up all memory
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Sun Aug  9 17:40:47 2009
From: report at bugs.python.org (Nir Soffer)
Date: Sun, 09 Aug 2009 15:40:47 +0000
Subject: [issue2637] urllib.quote() escapes characters unnecessarily and
	contrary to docs
In-Reply-To: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>
Message-ID: <1249832447.09.0.00189511447167.issue2637@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

Senthil said:
> The way to handle this issue would be add these characters 
> '%/:=&?~#+!$,;'@()*[]' to always_safe list.

This is wrong - for example, '&=?' are NOT safe when quoting parameters
for query string. This will break exiting code that assume the default
safe parameters.

Other characters may be unsafe in other parts of the url - I did not
check which - and I don't have time to check. The current default
(safe='/') is the best option - it will work correctly in most case, and
in the worst is escaping some characters which are safe in particular
use case.

Since only the user know the context, the user should add safe
characters to the function. If you don't specify anything, the function
should be safe as possible for the worst use case.

If you want to add characters to the default safe list, you have to make
sure that the function will not break for common use cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2637>
_______________________________________

From report at bugs.python.org  Sun Aug  9 18:04:53 2009
From: report at bugs.python.org (Nir Soffer)
Date: Sun, 09 Aug 2009 16:04:53 +0000
Subject: [issue2637] urllib.quote() escapes characters unnecessarily and
	contrary to docs
In-Reply-To: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>
Message-ID: <1249833893.55.0.397333423607.issue2637@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

Here is one example of code that would break if the safe parameter is
changed in a careless way mentioned here (look for url_encode):

http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/urls.py#L112

I'm sure we can find similar code in every web application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2637>
_______________________________________

From report at bugs.python.org  Sun Aug  9 20:24:32 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 09 Aug 2009 18:24:32 +0000
Subject: [issue2637] urllib.quote() escapes characters unnecessarily and
	contrary to docs
In-Reply-To: <1249832447.09.0.00189511447167.issue2637@psf.upfronthosting.co.za>
Message-ID: <20090809182422.GB4308@ubuntu.ubuntu-domain>


Senthil <orsenthil at gmail.com> added the comment:

On Sun, Aug 09, 2009 at 03:40:47PM +0000, Nir Soffer wrote:
> for query string. This will break exiting code that assume the default
> safe parameters.
> 
> Other characters may be unsafe in other parts of the url - I did not

I agree with your comments and I had similar thoughts too.

The RFC spec says that different components in URL  have have
different characters that needs to be quoted.

The quote function is documented that it is *intended for path
component* and Python Documention provides a usage overview of quote
assuming that the developer will know what he/she is doing. It does
not deal with the specifics of quote w.r.t to URL components.

My comment was biased from the changes made to urllib.urlopen function
where we explicitly passed on reserved characters to the safe
parameter of quote and we got expected results. this change has been
there for few months now without any breakage reports.  And that
change was not according to any RFC but more based on the practical
issues encountered.

Yes, I agree that changes to quote function is bound to break the
code which relied on the earlier behaviour. I see at least 3 tests in
stdlib breaking, which can be modified without any loss in meaning, if
we want go with the change.

But, I feel it is okay to heed to your objection and leave the
function as it is. 
The need to change it does not have a strong backing in RFC.  It is a
not a bug, considering the documentation.

Only thing to live with will be urlopen's passing of safe characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2637>
_______________________________________

From report at bugs.python.org  Sun Aug  9 23:22:07 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Aug 2009 21:22:07 +0000
Subject: [issue6673] Py3.1 hangs in coroutine and eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1249852927.66.0.943580504248.issue6673@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Try list(genexp) instead of [listcomp] in 2.x and see what happens...

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Sun Aug  9 23:25:14 2009
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 09 Aug 2009 21:25:14 +0000
Subject: [issue6126] Python 3 pdb: shows internal code, breakpoints don't work
In-Reply-To: <1243451707.7.0.0771543881281.issue6126@psf.upfronthosting.co.za>
Message-ID: <1249853114.65.0.622867535518.issue6126@psf.upfronthosting.co.za>


Alex Gr?nholm <alex.gronholm+python at nextday.fi> added the comment:

Why has this not been resolved yet? Not having a working debugger is a
severe hindrance to the acceptance of Py3k.

----------
nosy: +agronholm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6126>
_______________________________________

From report at bugs.python.org  Sun Aug  9 23:59:50 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Aug 2009 21:59:50 +0000
Subject: [issue6126] Python 3 pdb: shows internal code, breakpoints don't work
In-Reply-To: <1243451707.7.0.0771543881281.issue6126@psf.upfronthosting.co.za>
Message-ID: <1249855190.81.0.894854080204.issue6126@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Attached patch confirmedly fixes this.  Will commit as soon as svn is
back up.

----------
assignee:  -> georg.brandl
keywords: +patch
nosy: +georg.brandl
Added file: http://bugs.python.org/file14679/pdb-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6126>
_______________________________________

From report at bugs.python.org  Mon Aug 10 00:06:27 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 09 Aug 2009 22:06:27 +0000
Subject: [issue6673] Py3.1 hangs in coroutine and eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1249855587.95.0.863253110089.issue6673@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Hmm, ok, so this is actually an anticipated bug? And I assume this has
been discussed before and was decided to get solved by doing... what?

Is it documented somewhere why this happens and what one must avoid to
not run into this kind of pitfall?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Mon Aug 10 00:09:25 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Aug 2009 22:09:25 +0000
Subject: [issue6673] Py3.1 hangs in coroutine and eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1249855765.37.0.964655102398.issue6673@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No idea, actually. I just wanted to point out that it is nothing
specific to Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Mon Aug 10 10:18:21 2009
From: report at bugs.python.org (Aliaksandr Stelmachonak)
Date: Mon, 10 Aug 2009 08:18:21 +0000
Subject: [issue6671] webbrowser.py doesn't respect xfce default browser
In-Reply-To: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>
Message-ID: <1249892301.21.0.0390064941395.issue6671@psf.upfronthosting.co.za>


Changes by Aliaksandr Stelmachonak <mail.avatar at gmail.com>:


Added file: http://bugs.python.org/file14680/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6671>
_______________________________________

From report at bugs.python.org  Mon Aug 10 10:19:45 2009
From: report at bugs.python.org (Aliaksandr Stelmachonak)
Date: Mon, 10 Aug 2009 08:19:45 +0000
Subject: [issue6671] webbrowser.py doesn't respect xfce default browser
In-Reply-To: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>
Message-ID: <1249892385.45.0.883567756728.issue6671@psf.upfronthosting.co.za>


Changes by Aliaksandr Stelmachonak <mail.avatar at gmail.com>:


Removed file: http://bugs.python.org/file14678/webbrowser.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6671>
_______________________________________

From report at bugs.python.org  Mon Aug 10 10:54:55 2009
From: report at bugs.python.org (Vlastimil Brom)
Date: Mon, 10 Aug 2009 08:54:55 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249894495.78.0.272898787331.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

First, many thanks for this contribution; it's great, that the re 
module gets updated in that comprehensive way!

I'd like to report some issue with the current version 
(issue2636-20090804.zip).

Using an empty string as the search pattern ends up consuming system 
resources and the function doesn't return anything nor raise an 
exception or crash (within several minutes I tried).
The current re engine simply returns the empty matches on all character 
boundaries in this case.

I use win XPh SP3, the behaviour is the same on python 2.5.4 and 2.6.2:
It should be reproducible with the following simple code:

>>> import re
>>> import regex
>>> re.findall("", "abcde")
['', '', '', '', '', '']
>>> regex.findall("", "abcde")
_

regards
    vbr

----------
nosy: +vbr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Aug 10 12:35:16 2009
From: report at bugs.python.org (Shashi Gowda)
Date: Mon, 10 Aug 2009 10:35:16 +0000
Subject: [issue6674] Fatal error: deallocating None
In-Reply-To: <1249900516.3.0.450252107319.issue6674@psf.upfronthosting.co.za>
Message-ID: <1249900516.3.0.450252107319.issue6674@psf.upfronthosting.co.za>


New submission from Shashi Gowda <connect2shashi at gmail.com>:

I'm using the megahal mh_python module to make a bot instance learn from
a several 100 files. The code works as it should for 4-6 files before
crashing with this error message "Fatal error: deallocating None" There
isn't much documentation on this anywhere.

----------
components: Interpreter Core
files: learn.py
messages: 91438
nosy: shashi
severity: normal
status: open
title: Fatal error: deallocating None
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file14681/learn.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6674>
_______________________________________

From report at bugs.python.org  Mon Aug 10 12:58:10 2009
From: report at bugs.python.org (John Machin)
Date: Mon, 10 Aug 2009 10:58:10 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249901890.43.0.624278151974.issue2636@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Adding to vbr's report: [2.6.2, Win XP SP3] (1) bug mallocs memory
inside loop (2) also happens to regex.findall with patterns 'a{0,0}' and
'\B' (3) regex.sub('', 'x', 'abcde') has similar problem BUT 'a{0,0}'
and '\B' appear to work OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Aug 10 13:26:52 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 10 Aug 2009 11:26:52 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1249903612.25.0.27171469917.issue6670@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6670>
_______________________________________

From report at bugs.python.org  Mon Aug 10 13:47:32 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 10 Aug 2009 11:47:32 +0000
Subject: [issue6556] "HOME" is not a standard environment variable on Windows
In-Reply-To: <1248379761.36.0.601035706586.issue6556@psf.upfronthosting.co.za>
Message-ID: <1249904852.72.0.552434573146.issue6556@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I tried to echo both %HOME% and %USERPROFILE% on a few windows systems
(XP, 2k3 Server and Vista) and only the latter worked. %HOME% is not set
in any of these systems.

----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6556>
_______________________________________

From report at bugs.python.org  Mon Aug 10 13:49:32 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 10 Aug 2009 11:49:32 +0000
Subject: [issue6519] Reorder 'with' statement for files in Python Tutorial
In-Reply-To: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za>
Message-ID: <1249904972.78.0.349154328874.issue6519@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6519>
_______________________________________

From report at bugs.python.org  Mon Aug 10 14:19:01 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 10 Aug 2009 12:19:01 +0000
Subject: [issue6674] Fatal error: deallocating None
In-Reply-To: <1249900516.3.0.450252107319.issue6674@psf.upfronthosting.co.za>
Message-ID: <1249906741.37.0.385998923199.issue6674@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Is your mh_python module written in C/C++ or Python?  If it's written
in C or C++ check your Py_DECREF calls.  You are probably doubly
decrementing some object which at times refers to Py_None.  Do that
enough and you eventually try to deallocate it.

In fact, it does appear that the Megahal python wrapper is written
in C.  I don't know where the source is, but it's almost certain the
problem lies there, not in the Python interpreter core.  I suggest you
contact the Megahal author(s).

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6674>
_______________________________________

From report at bugs.python.org  Mon Aug 10 14:30:28 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 10 Aug 2009 12:30:28 +0000
Subject: [issue6670] Printing the 'The Python Tutorial'
In-Reply-To: <1249761006.45.0.422242383232.issue6670@psf.upfronthosting.co.za>
Message-ID: <1249907428.1.0.552505354665.issue6670@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I can reproduce the issue using the "Print preview" on Firefox and on
IE, on the tutorial and on other pages as well.
The Doc has a couple of print rules at the end of
http://docs.python.org/_static/basic.css and they look correct (and they
are also W3C valid). While I was trying to debug the problem using the
Web Developer plug-in of Firefox and the "Edit CSS" option the problem
disappeared without changing anything.
This is quite weird and lead me to think that there could be a priority
problem (even if I can't see any other rule that overrides the print rules).

Possible solutions could be:
1) add a couple of !important in the print rules;
2) move the print rules somewhere else;
3) create a distinct print CSS where to put all the print rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6670>
_______________________________________

From report at bugs.python.org  Mon Aug 10 15:44:26 2009
From: report at bugs.python.org (D Hardy)
Date: Mon, 10 Aug 2009 13:44:26 +0000
Subject: [issue6675] inf == inf (wrong IEEE 754 behaviour)
In-Reply-To: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>
Message-ID: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>


New submission from D Hardy <diggory.hardy at gmail.com>:

Currently python evaluates infinity as equal to itself in my tests (2.6.2 and 3.0.1+
from ubuntu). I'm not entirely sure whether the behaviour of 'inf == inf' is specified
by IEEE 754, but it leads to results like:

>>> 1e400
inf
>>> 1e400 == 1e500
True

And hence unittests which use tests like

if not (math.fabs(value1 - value2) <= 0.00000001 *
max(math.fabs(value1),math.fabs(value2))):
    fail

don't always fail when they should (when a value is inf).

This is a specific example (and probably not the recommended way of testing
values in any case), but I think "inf != inf" is generally considered the correct
behaviour. (Although maybe this is left over from the PEP 42 / PEP 754 mess; I
wasn't able to find the current status of implementing IEEE 754 behaviour in
python.)

----------
components: None
messages: 91443
nosy: Cyborg16
severity: normal
status: open
title: inf == inf (wrong IEEE 754 behaviour)
type: behavior
versions: Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6675>
_______________________________________

From report at bugs.python.org  Mon Aug 10 15:50:37 2009
From: report at bugs.python.org (tobias)
Date: Mon, 10 Aug 2009 13:50:37 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1249912237.3.0.973444037857.issue4953@psf.upfronthosting.co.za>


tobias <fatbull at web.de> added the comment:

Actually, I think this whole issue is more complex. For example,
consider a (fictious) CGI script where users can upload an image and a
description and the script sends a success/error message in return.

In this case, one has to:
- read the HTTP request header from stdin as US-ASCII
- read the image from stdin as raw binary data
- read the description from stdin as a string in some encoding
- write the HTTP response header to stdout as US-ASCII
- write the response message to stdout in some (other) encoding
- write error messages to server log via stderr as US-ASCII
Also, there are cases when a cgi script should return binary data
instead (e.g., images or archive files) or apply a transfer encoding
(e.g., gzip).

Although FieldStorage only cares about reading, it still has to cope
with intermixed textual and binary data. So the only practical way in my
opinion is to use raw binary data and have FieldStorage decode strings
on demand, since only the programmer knows whether a field should
contain text or binary data. FieldStorage should offer two methods for
this purpose: one for reading binary data and another for reading and
decoding strings on-the-fly (possibly using a default encoding passed to
its constructor).

----------
nosy: +tobias

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Aug 10 16:06:05 2009
From: report at bugs.python.org (Tim Peters)
Date: Mon, 10 Aug 2009 14:06:05 +0000
Subject: [issue6675] inf == inf (wrong IEEE 754 behaviour)
In-Reply-To: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>
Message-ID: <1249913165.83.0.95815586876.issue6675@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

+inf == +inf, and -inf == -inf, are required by the 754 standard. 
However, +inf - +inf, and -inf - -inf, are required (by the same
standard) to signal invalid operation and, if that signal is masked (as
it is in Python), to return a NaN.  Then NaN == x is false for any value
of x (including a NaN).

OTOH, +inf != -inf, +inf - -inf == +inf, and -inf - +inf == -inf.

Current versions of Python implement all of that.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6675>
_______________________________________

From report at bugs.python.org  Mon Aug 10 16:16:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 Aug 2009 14:16:20 +0000
Subject: [issue6675] inf == inf (wrong IEEE 754 behaviour)
In-Reply-To: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>
Message-ID: <1249913780.23.0.129120240816.issue6675@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Section 5.11 of IEEE 754-2008, paragraph 2, says:

"""Infinite operands of the same sign shall compare equal."""

So Python's behaviour follows the standard here.

Producing 'is close to' tests is always tricky if you want to be able to
deal with IEEE special values (subnormals, negative zero, infinities, 
NaNs).  You could always write your unittest as:

if not (value1 == value2 or <relative_error_test>).

but this still doesn't consider NaNs, and probably doesn't do what you 
want for subnormals either.

Closing as invalid.

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6675>
_______________________________________

From report at bugs.python.org  Mon Aug 10 16:18:29 2009
From: report at bugs.python.org (Artur Frysiak)
Date: Mon, 10 Aug 2009 14:18:29 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1249913909.32.0.358689300728.issue6603@psf.upfronthosting.co.za>


Artur Frysiak <wiget at pld-linux.org> added the comment:

Adding -fno-caller-saves to OPT in Makefile fixes problem.

BTW All compilations done on x86_64 architecture.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Mon Aug 10 16:18:58 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 10 Aug 2009 14:18:58 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249913938.72.0.523305340522.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20090810.zip should fix the empty-string bug.

----------
Added file: http://bugs.python.org/file14682/issue2636-20090810.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Aug 10 16:34:55 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Aug 2009 14:34:55 +0000
Subject: [issue6674] Fatal error: deallocating None
In-Reply-To: <1249900516.3.0.450252107319.issue6674@psf.upfronthosting.co.za>
Message-ID: <1249914895.95.0.827976875274.issue6674@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6674>
_______________________________________

From report at bugs.python.org  Mon Aug 10 16:42:25 2009
From: report at bugs.python.org (Timothy Farrell)
Date: Mon, 10 Aug 2009 14:42:25 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1249915345.75.0.9656426237.issue4953@psf.upfronthosting.co.za>


Timothy Farrell <tfarrell at swgen.com> added the comment:

I think you hit the nail on the head.  Now we just need (someone) to
code it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Mon Aug 10 17:04:50 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 10 Aug 2009 15:04:50 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249916690.72.0.145437582532.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20090810#2.zip has some further improvements and bugfixes.

----------
Added file: http://bugs.python.org/file14683/issue2636-20090810#2.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Aug 10 18:03:24 2009
From: report at bugs.python.org (D Hardy)
Date: Mon, 10 Aug 2009 16:03:24 +0000
Subject: [issue6675] inf == inf (wrong IEEE 754 behaviour)
In-Reply-To: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>
Message-ID: <1249920204.25.0.235471416132.issue6675@psf.upfronthosting.co.za>


D Hardy <diggory.hardy at gmail.com> added the comment:

Oh; OK, thanks for the response.

Sorry, I've used +/- inf and NaN values in other languages and was under the
impression inf != inf under IEEE 754. I think this requires explicitly testing for
infinity then.

For anyone interested, I've written a test which seems to work well. Sub-normals I
don't think are an issue since it doesn't deal with the binary representation (it was
never intended to be computationally efficient). It's at:
http://code.google.com/p/openmalaria/source/browse/trunk/test/compareOutputsFl

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6675>
_______________________________________

From report at bugs.python.org  Mon Aug 10 18:23:25 2009
From: report at bugs.python.org (Matthew)
Date: Mon, 10 Aug 2009 16:23:25 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>


New submission from Matthew <webmaster at adurosolutions.com>:

I'm using the Expat python interface to parse multiple XML files in an
application and have found that it throws a "Memory Error" exception if
multiple calls are made to xmlparser.ParseFile(file) on the same
xmlparser object. This occurs even with a vanilla xmlparser object
created with xml.parsers.expat.ParserCreate().

Python Version: 2.6.2
Operating System: Ubuntu

----------
components: XML
files: expat-error.py
messages: 91452
nosy: realpolitik
severity: normal
status: open
title: expat parser throws Memory Error when parsing multiple files
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14684/expat-error.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Mon Aug 10 18:29:29 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 10 Aug 2009 16:29:29 +0000
Subject: [issue6675] inf == inf (wrong IEEE 754 behaviour)
In-Reply-To: <1249911865.84.0.497315252674.issue6675@psf.upfronthosting.co.za>
Message-ID: <1249921769.64.0.395132916417.issue6675@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The only issue with subnormals is that a simple relative error test is 
usually inappropriate.  For example, on an IEEE 754 machine 2**-1073 
should almost always be considered a good approximation to 2**-1074, since 
the two floats are adjacent; but the relative error here is 100%!  But I 
see that in the code you linked you have a combination of a relative error 
and absolute error tests, so this isn't a problem.

There's something similar to your code in the Python tests:  see function 
'almostEqualF' in Lib/test/test_cmath.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6675>
_______________________________________

From report at bugs.python.org  Mon Aug 10 18:31:05 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Aug 2009 16:31:05 +0000
Subject: [issue6603] Compilation error if configuref --with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1249921865.76.0.439535691397.issue6603@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It sounds like a compiler bug... It would be nice if people could give
results with other gcc versions and builds.
(my test was done on x86-64 too, by the way)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________

From report at bugs.python.org  Mon Aug 10 18:55:45 2009
From: report at bugs.python.org (Matthew)
Date: Mon, 10 Aug 2009 16:55:45 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1249923345.92.0.297081166146.issue6676@psf.upfronthosting.co.za>


Matthew <webmaster at adurosolutions.com> added the comment:

This also occurs with Python 2.5.1 on OS X

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Mon Aug 10 19:09:52 2009
From: report at bugs.python.org (Mike Cowperthwaite)
Date: Mon, 10 Aug 2009 17:09:52 +0000
Subject: [issue6677] Place the term "delete" within the documentation for
	os.remove() and os.rmdir()
In-Reply-To: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>
Message-ID: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>


New submission from Mike Cowperthwaite <mikec at lathropengineering.com>:

"Remove" and "unlink" are not the most widely-known verbs that come
to mind when thinking about deleting objects from the filesystem.
A recent Google search for "python delete file" led to the documentation
for the 'os' module:
  http://docs.python.org/library/os.html
but searching within that page for "delet" completely misses
os.remove(), os.unlink(), and os.rmdir().

Suggest simply expanding the first sentence of os.remove()'s paragraph to:
   Remove the file /path/ (delete the file).

Similarly for os.rmdir():
   Remove the directory /path/ (delete the directory).

Also regarding os.rmdir(), it would be nice to add a mention here of
this information from os.walk(): "rmdir() doesn?t allow deleting a
directory before the directory is empty."

The URL above is for the 2.6 version (chapter 16.1.4); also seen in the
3.1 documentation (15.1.5); presumably it's also in the development
versions.  Patching backwards as far as feasible would be appreciated.

----------
assignee: georg.brandl
components: Documentation
messages: 91456
nosy: georg.brandl, mcow
severity: normal
status: open
title: Place the term "delete" within the documentation for os.remove() and os.rmdir()
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6677>
_______________________________________

From report at bugs.python.org  Mon Aug 10 19:46:40 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 10 Aug 2009 17:46:40 +0000
Subject: [issue1207589] Right Click Context Menu
Message-ID: <1249926400.29.0.699225102468.issue1207589@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

What do you think about adding a third element for each tuple in
rmenu_specs ? This new element would be a string determining the name of
a function that would be called to define the state of each entry in the
right menu. If None is used in place of a string, then it is assumed
that the entry doesn't require such thing.

Attaching a patch that does that. It also adds cut/copy/paste to the
right menu in IDLE shell.

----------
Added file: http://bugs.python.org/file14685/rightmenu_copypastecut.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1207589>
_______________________________________

From report at bugs.python.org  Mon Aug 10 19:49:00 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 10 Aug 2009 17:49:00 +0000
Subject: [issue1207589] Right Click Context Menu
Message-ID: <1249926540.02.0.783358658289.issue1207589@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> 2) display assigned hot keys in popup menu

Is that really necessary ? I've looked for that on some applications I
use most and none of them include hot keys in right menus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1207589>
_______________________________________

From report at bugs.python.org  Mon Aug 10 20:25:01 2009
From: report at bugs.python.org (William Mill)
Date: Mon, 10 Aug 2009 18:25:01 +0000
Subject: [issue6678] inspect.currentframe documentation omits optional depth
	parameter
In-Reply-To: <1249928701.73.0.0206445902812.issue6678@psf.upfronthosting.co.za>
Message-ID: <1249928701.73.0.0206445902812.issue6678@psf.upfronthosting.co.za>


New submission from William Mill <bill.mill at gmail.com>:

help(inspect.currentframe) reads:

---------------------------------
_getframe(...)
    _getframe([depth]) -> frameobject

Return a frame object from the call stack.  If optional integer depth is
given, return the frame object that many calls below the top of the
stack. If that is deeper than the call stack, ValueError is raised.  The
default for depth is zero, returning the frame at the top of the call stack.
        
This function should be used for internal and specialized
purposes only.
-------------------------------

The python library documentation, however, doesn't mention the optional
depth parameter:

-------------------------------
inspect.currentframe()
    Return the frame object for the caller?s stack frame.
-------------------------------

I think substituting the help() text for the library documentation's
text would be an improvement.

----------
assignee: georg.brandl
components: Documentation
messages: 91459
nosy: georg.brandl, llimllib
severity: normal
status: open
title: inspect.currentframe documentation omits optional depth parameter
type: feature request
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6678>
_______________________________________

From report at bugs.python.org  Mon Aug 10 21:27:48 2009
From: report at bugs.python.org (Vlastimil Brom)
Date: Mon, 10 Aug 2009 19:27:48 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249932468.1.0.843595392458.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I'd like to confirm, that the above reported error is fixed in 
issue2636-20090810#2.zip
While testing the new features a bit, I noticed some irregularity in 
handling the Unicode Character Properties; 
I tried randomly some of those mentioned at http://www.regular-
expressions.info/unicode.html using the simple findall like above.

It seems, that only the short abbreviated forms of the properties are 
supported, however, the long variants are handled in different ways.
Namely, the properties names containing whitespace or other non-letter 
characters cause some probably unexpected exception:

>>> regex.findall(ur"\p{Ll}", u"abcDEF")
[u'a', u'b', u'c']
# works ok

\p{LowercaseLetter} isn't supported, but seems to be handled, as it 
throws "error: undefined property name" at the end of the traceback.

\p{Lowercase Letter} \p{Lowercase_Letter} \p{Lowercase-Letter} 
isn't probably expected, the traceback is:

>>> regex.findall(ur"\p{Lowercase_Letter}", u"abcDEF")
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Python25\lib\regex.py", line 194, in findall
    return _compile(pattern, flags).findall(string)
  File "C:\Python25\lib\regex.py", line 386, in _compile
    parsed = _parse_pattern(source, info)
  File "C:\Python25\lib\regex.py", line 465, in _parse_pattern
    branches = [_parse_sequence(source, info)]
  File "C:\Python25\lib\regex.py", line 477, in _parse_sequence
    item = _parse_item(source, info)
  File "C:\Python25\lib\regex.py", line 485, in _parse_item
    element = _parse_element(source, info)
  File "C:\Python25\lib\regex.py", line 610, in _parse_element
    return _parse_escape(source, info, False)
  File "C:\Python25\lib\regex.py", line 844, in _parse_escape
    return _parse_property(source, ch == "p", here, in_set)
  File "C:\Python25\lib\regex.py", line 983, in _parse_property
    if info.local_flags & IGNORECASE and not in_set:
NameError: global name 'info' is not defined
>>> 

Of course, arbitrary strings other than properties names are handled 
identically.

Python 2.6.2 version behaves the same like 2.5.4.

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Aug 10 22:10:38 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 10 Aug 2009 20:10:38 +0000
Subject: [issue6679] obsolete paragraph in re doc for re.sub
In-Reply-To: <1249935038.17.0.324286013964.issue6679@psf.upfronthosting.co.za>
Message-ID: <1249935038.17.0.324286013964.issue6679@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

The documentation of re.sub states:

"The pattern may be a string or an RE object; if you need to specify
regular expression flags, you must use a RE object, or use embedded
modifiers in a pattern; for example, sub("(?i)b+", "x", "bbbb BBBB")
returns 'x x'."

but there is now a flags argument so that paragraph should be deleted.

----------
assignee: georg.brandl
components: Documentation
messages: 91461
nosy: MLModel, georg.brandl
severity: normal
status: open
title: obsolete paragraph in re doc for re.sub
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6679>
_______________________________________

From report at bugs.python.org  Mon Aug 10 23:53:34 2009
From: report at bugs.python.org (Rodrigo Steinmuller Wanderley)
Date: Mon, 10 Aug 2009 21:53:34 +0000
Subject: [issue6582] test_telnetlib doesn't test Telnet.write
In-Reply-To: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>
Message-ID: <1249941214.19.0.529739908395.issue6582@psf.upfronthosting.co.za>


Changes by Rodrigo Steinmuller Wanderley <rwanderley at rsw.digi.com.br>:


Removed file: http://bugs.python.org/file14668/write_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6582>
_______________________________________

From report at bugs.python.org  Mon Aug 10 23:54:36 2009
From: report at bugs.python.org (Rodrigo Steinmuller Wanderley)
Date: Mon, 10 Aug 2009 21:54:36 +0000
Subject: [issue6582] test_telnetlib doesn't test Telnet.write
In-Reply-To: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>
Message-ID: <1249941276.81.0.930053929534.issue6582@psf.upfronthosting.co.za>


Changes by Rodrigo Steinmuller Wanderley <rwanderley at rsw.digi.com.br>:


Added file: http://bugs.python.org/file14686/telnetlib_writetest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6582>
_______________________________________

From report at bugs.python.org  Tue Aug 11 00:02:02 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 10 Aug 2009 22:02:02 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249941722.1.0.633233824767.issue2636@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

for each of these discrepancies that you're finding, please consider 
submitting them as patches that add a unittest to the existing test 
suite.  otherwise their behavior guarantees will be lost regardless of if 
the suite in this issue is adopted.  thanks!

I'll happily commit any passing re module unittest additions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Aug 11 00:42:19 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 10 Aug 2009 22:42:19 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249944139.74.0.753457993344.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20090810#3.zip adds more Unicode character properties such as
"\p{Lowercase_Letter}", and also Unicode script ranges.

In addition, the 'findall' method now accepts an 'overlapped' argument
for finding overlapped matches. For example:

>>> regex.findall(r"(..)", "abc")
['ab']
>>> regex.findall(r"(..)", "abc", overlapped=True)
['ab', 'bc']

----------
Added file: http://bugs.python.org/file14687/issue2636-20090810#3.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Aug 11 00:45:55 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Aug 2009 22:45:55 +0000
Subject: [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1249944355.61.0.0816527516937.issue5120@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

To follow up your question posted on issue 6527 (sorry for the
duplicate), I don't currently have a mac to test on.  I might have
access to one in a couple weeks, though.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5120>
_______________________________________

From report at bugs.python.org  Tue Aug 11 00:47:24 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 10 Aug 2009 22:47:24 +0000
Subject: [issue6680] Python 3.1 fails to build when db.h contains non-UTF-8
	characters
In-Reply-To: <1249944443.54.0.496415697007.issue6680@psf.upfronthosting.co.za>
Message-ID: <1249944443.54.0.496415697007.issue6680@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Python 3.1 fails to build when db.h contains non-UTF-8 characters.
Python 3.1 checks for db.h even though Python 3 doesn't contain bsddb
module.

See also https://bugs.gentoo.org/show_bug.cgi?id=280001

Please at least apply the attached patch, or completely remove check
for db.h.

----------
components: Build
files: python-3.1-setup.py.patch
keywords: patch
messages: 91465
nosy: Arfrever
severity: normal
status: open
title: Python 3.1 fails to build when db.h contains non-UTF-8 characters
versions: Python 3.1
Added file: http://bugs.python.org/file14688/python-3.1-setup.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6680>
_______________________________________

From report at bugs.python.org  Tue Aug 11 00:58:34 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Aug 2009 22:58:34 +0000
Subject: [issue6681] email.parser clips trailing \n of multipart/mixed part if
	part ends in \r\n
In-Reply-To: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>
Message-ID: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

I am using an edge case of multipart/mixed and find that the
multipart/mix parser in the email package is broken.  See attached
example.  Similar code using cgi.FieldStorage (!) works fine.

The problem happens through the following combination of factors:

1. Content-Length given
2. Content-Transfer-Encoding: 8bit
3. Last two bytes of the part body are '\r\n'

In this case, the final '\n' is removed from the part body, leaving it a
byte short.  Note that interior occurrences of '\r\n' work fine, as does
any other binary data -- it's only a trailing '\r\n' that breaks.

Note that technically perhaps the use of 8bit is invalid; but the same
problem happens when using binary instead.

The problem can be reproduced in Python 3.x using nearly the same demo
by change the cStringIO import to "import io".

----------
components: Library (Lib)
files: barry.py
messages: 91466
nosy: gvanrossum
severity: normal
status: open
title: email.parser clips trailing \n of multipart/mixed part if part ends in \r\n
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14689/barry.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6681>
_______________________________________

From report at bugs.python.org  Tue Aug 11 01:38:03 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Aug 2009 23:38:03 +0000
Subject: [issue6681] email.parser clips trailing \n of multipart/mixed part if
	part ends in \r\n
In-Reply-To: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>
Message-ID: <1249947483.26.0.2004216001.issue6681@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Older Python versions too.

----------
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6681>
_______________________________________

From report at bugs.python.org  Tue Aug 11 08:11:08 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Aug 2009 06:11:08 +0000
Subject: [issue6126] Python 3 pdb: shows internal code, breakpoints don't work
In-Reply-To: <1243451707.7.0.0771543881281.issue6126@psf.upfronthosting.co.za>
Message-ID: <1249971068.55.0.849024630349.issue6126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reading this patch, is it normal that the file is opened in text mode
without an encoding specified? What if the source file uses a different
encoding than the default system one?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6126>
_______________________________________

From report at bugs.python.org  Tue Aug 11 08:15:43 2009
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Aug 2009 06:15:43 +0000
Subject: [issue6126] Python 3 pdb: shows internal code, breakpoints don't work
In-Reply-To: <1243451707.7.0.0771543881281.issue6126@psf.upfronthosting.co.za>
Message-ID: <1249971343.79.0.634892595749.issue6126@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That's a good question :)

A quick test shows that exec() does honor coding cookies in code given
as a bytestring, so simply changing to open(..., "rb") should be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6126>
_______________________________________

From report at bugs.python.org  Tue Aug 11 10:01:53 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Aug 2009 08:01:53 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1249977713.35.0.943957007291.issue6656@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I fixed this a different way that seems cleaner.  In the process, I
discovered that passing a mapping argument to format_string is
completely broken.  Here is an expanded set of tests that demonstrate
this.  This diff is against trunk.

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
priority:  -> normal
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5
Added file: http://bugs.python.org/file14690/locale-tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Tue Aug 11 10:05:42 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Aug 2009 08:05:42 +0000
Subject: [issue6656] locale.format_string fails on escaped percentage
In-Reply-To: <1249556978.14.0.317265689402.issue6656@psf.upfronthosting.co.za>
Message-ID: <1249977942.64.0.211195846532.issue6656@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a patch against trunk that fixes both the mapping handling and
the % escape handling.

The thing that worries me about this patch is that there are (obviously)
not a comprehensive set of tests proving that format_string actually
behaves like % formatting does.  So my refactoring could have broken
other behavior and I wouldn't know it.  However, since % formatting is
effectively depricated, I'm not sure how much effort it is worth putting
in to this....

----------
keywords: +needs review
stage:  -> patch review
Added file: http://bugs.python.org/file14691/locale-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6656>
_______________________________________

From report at bugs.python.org  Tue Aug 11 11:56:21 2009
From: report at bugs.python.org (Mitar)
Date: Tue, 11 Aug 2009 09:56:21 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1249984581.11.0.192098760025.issue2504@psf.upfronthosting.co.za>


Mitar <mmitar at gmail.com> added the comment:

I would just like to add that I am also looking forwards to this feature.

----------
nosy: +mitar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Tue Aug 11 13:15:32 2009
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 11 Aug 2009 11:15:32 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249989332.02.0.0247249497132.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Sorry for the dumb question, which may also suggest, that I'm 
unfortunately unable to contribute at this level (with zero knowledge 
of C and only "working" one for Python):
Where can I find the sources for tests etc. and how they are eventually 
to be submitted? Is some other account needed besides the one for 
bugs.python.org?

Anyway, the long character properties now work in the latest version 
issue2636-20090810#3.zip

In the mentioned overview 
http://www.regular-expressions.info/unicode.html
there is a statement for the property names: "You may omit the 
underscores or use hyphens or spaces instead." 
While I'm not sure, that it is a good thing to have that many 
variations, they should probably be handled in the same way.

Now, the whitespace (and also non ascii characters) in the property 
name seem to confuse the parser: these pass silently (don't match 
anything) and don't throw an exception like "undefined property name".

cf.

>>> regex.findall(ur"\p{Dummy Property}", u"abcDEF")
[]
>>> regex.findall(ur"\p{D?mm?Pr?p?rt?}", u"abcDEF")
[]
>>> regex.findall(ur"\p{DummyProperty}", u"abcDEF")
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "regex.pyc", line 195, in findall
  File "regex.pyc", line 563, in _compile
  File "regex.pyc", line 642, in _parse_pattern
  File "regex.pyc", line 654, in _parse_sequence
  File "regex.pyc", line 662, in _parse_item
  File "regex.pyc", line 787, in _parse_element
  File "regex.pyc", line 1021, in _parse_escape
  File "regex.pyc", line 1159, in _parse_property
error: undefined property name 'DummyProperty'
>>> 

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Aug 11 14:59:24 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Aug 2009 12:59:24 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1249995564.41.0.931089780249.issue2636@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Take a look a the dev FAQ, linked from http://www.python.org/dev.  The
tests are in Lib/test in a distribution installed from source, but
ideally you would be (anonymously) pulling the trunk from SVN (when it
is back) and creating your patches with respect to that code as
explained in the FAQ.  You would be adding unit test code to
Lib/test/test_re.py, though it looks like re_tests.py might be an
interesting file to look at as well.

As the dev docs say, anyone can contribute, and writing tests is a great
way to start, so please don't feel like you aren't qualified to
contribute, you are.  If you have questions, come to #python-dev on
freenode.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Aug 11 16:26:32 2009
From: report at bugs.python.org (Anders Blomdell)
Date: Tue, 11 Aug 2009 14:26:32 +0000
Subject: [issue6682] Default traceback does not handle PEP302 loaded modules
In-Reply-To: <1250000791.92.0.10910978351.issue6682@psf.upfronthosting.co.za>
Message-ID: <1250000791.92.0.10910978351.issue6682@psf.upfronthosting.co.za>


New submission from Anders Blomdell <anders.blomdell at control.lth.se>:

While trying to get a PEP302 import hook to function properly, I found
that the default traceback picks up the wrong sourcecode for PEP302
loaded modules.

The testcase pep302_traceback.py tries to emulate the behavior of the
files in ordinary, which generates the following output when run:

  (cd ordinary ; python2.6.2 main.py )   

  A.__name__= a
  B.__name__ a.b
  Traceback (most recent call last):
    File "main.py", line 6, in <module>
      a.A()
  File "/tmp/ordinary/a/__init__.py", line 6, in __init__
    b.B()
  File "/tmp/ordinary/a/b/__init__.py", line 4, in __init__
    raise Exception()
  Exception

But when i run the testcase, I get the following:

  python2.6.2 pep302_traceback.py 
  ### Show possible bug in default linecache (works in 2.6.2)
  A.__name__= a
  B.__name__= a.b
  Traceback (most recent call last):
    File "pep302_traceback.py", line 82, in <module>
      i.load_module("__main__")
    File "pep302_traceback.py", line 58, in load_module
      exec(code, mod.__dict__)
    File "<__main__.Importer>/main.py", line 6, in <module>
      a.A()
    File "<__main__.Importer>/a/__init__.py", line 6, in __init__
      b.B()
    File "<__main__.Importer>/a/b/__init__.py", line 4, in __init__
      raise Exception()
  Exception
  ### Show possible bug in default traceback (does not work in 2.6.2)
  A.__name__= a
  B.__name__= a.b
  Traceback (most recent call last):
    File "pep302_traceback.py", line 88, in <module>
      i.load_module("__main__")
    File "pep302_traceback.py", line 58, in load_module
      exec(code, mod.__dict__)
    File "<__main__.Importer>/main.py", line 6, in <module>
      # main.py picked up from somewhere in sys.path
    File "<__main__.Importer>/a/__init__.py", line 6, in __init__
      # __init__.py picked up from somewhere in sys.path
    File "<__main__.Importer>/a/b/__init__.py", line 4, in __init__
      # __init__.py picked up from somewhere in sys.path
  Exception

I.e. in python 2.6 the linecache module correctly picks up PEP302 loaded
code, while the default traceback picks up any source file from sys.path
that happens to match the name of the file that generated the exception.
When run with python2.5.2, the linecache module also locates the wrong
file from sys.path.

----------
components: Interpreter Core
files: bug.tar
messages: 91475
nosy: anders.blomdell at control.lth.se
severity: normal
status: open
title: Default traceback does not handle PEP302 loaded modules
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14692/bug.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6682>
_______________________________________

From report at bugs.python.org  Tue Aug 11 17:17:06 2009
From: report at bugs.python.org (kee nethery)
Date: Tue, 11 Aug 2009 15:17:06 +0000
Subject: [issue6660] Desire python.org documentation link to user contribution
	wiki (per function)
In-Reply-To: <4A80E843.5010806@acm.org>
Message-ID: <BC139A19-F31E-4143-8778-11ECC110DBFD@kagi.com>


kee nethery <kee at kagi.com> added the comment:

Is there anything I can do to help this happen? Am thinking that these  
are the steps to the process.

1. Create wiki.docs.python.org using the wiki setup template already  
used by wiki.python.org.
2. Lock page creation except for one specific account.
3. Create a template wiki page that has all the subsections desired  
(one per language version)
4. Grab all the existing docs for say version 2.5 moving forward, and  
at each perma-link, add a user contributions wiki link.
5. Keep track of all the user contribution wiki links
6. spin through the list of links and generate all the empty user  
contribution wiki pages.
7. release the docs with the new user contributions wiki links.

I'm not a wiki expert but I'd be happy to build the thing that creates  
each user contribution wiki link in the docs. Then I could pass the  
modified document files back to you. You could verify they are as  
desired. Once that looks good I could have code that spins through the  
links and creates the pages in the wiki.

Kee Nethery

> From: Georg Brandl <report at bugs.python.org>
> Date: August 6, 2009 3:38:33 PM PDT
> To: kee at kagi.com
> Subject: [issue6660] Desire python.org documentation link to user  
> contribution wiki (per function)
> Reply-To: Python tracker <report at bugs.python.org>
>
>
> Georg Brandl <georg at python.org> added the comment:
>
> There will be comments for each function/class etc., as well as a
> feature to suggest a change for the proper text of a section.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6660>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________

From report at bugs.python.org  Tue Aug 11 17:21:06 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 11 Aug 2009 15:21:06 +0000
Subject: [issue6681] email.parser clips trailing \n of multipart/mixed part if
	part ends in \r\n
In-Reply-To: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>
Message-ID: <1250004066.48.0.847337872289.issue6681@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Note that the headers in the subpart don't matter at all.  I'm sure this
is not a problem with MIME parsing, but with line ending issues.  It
might be related to mixing line endings, but we know that the email
package has some line ending problems.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6681>
_______________________________________

From report at bugs.python.org  Tue Aug 11 18:17:17 2009
From: report at bugs.python.org (Eric Shubert)
Date: Tue, 11 Aug 2009 16:17:17 +0000
Subject: [issue6683] smtplib authentication - try all mechanisms
In-Reply-To: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>
Message-ID: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>


New submission from Eric Shubert <python at shubes.net>:

The login method in smtplib.py tries only one authentication mechanism.
There are legitimate situations where cram-md5 might fail, yet plain or
login would succeed.

RFC2554 states:
  If an AUTH command fails, the client may try another authentication
  mechanism by issuing another AUTH command.

The login method should attempt all mechanisms in preferred_auths before
returning a failure. This will make the code more robust, returning a
failure only when absolutely no authentication is possible.

----------
messages: 91478
nosy: shubes
severity: normal
status: open
title: smtplib authentication - try all mechanisms
type: behavior
versions: Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6683>
_______________________________________

From report at bugs.python.org  Tue Aug 11 18:22:36 2009
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Tue, 11 Aug 2009 16:22:36 +0000
Subject: [issue6683] smtplib authentication - try all mechanisms
In-Reply-To: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>
Message-ID: <1250007756.81.0.601163233111.issue6683@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
assignee:  -> ghaering
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6683>
_______________________________________

From report at bugs.python.org  Tue Aug 11 18:44:30 2009
From: report at bugs.python.org (mrjbq7)
Date: Tue, 11 Aug 2009 16:44:30 +0000
Subject: [issue6684] "x / 1" and "x * 1" should return x
In-Reply-To: <1250009070.48.0.664173919374.issue6684@psf.upfronthosting.co.za>
Message-ID: <1250009070.48.0.664173919374.issue6684@psf.upfronthosting.co.za>


New submission from mrjbq7 <mrjbq7 at users.sourceforge.net>:

There are a couple arithmetic operations that idempotent, where the 
returned python object is the same python object as the input.  

For example, given a number:

>>> x = 12345

The abs() builtin returns the same number object if it is already a 
positive value:

>>> id(x)
17124964
>>> id(abs(x))
17124964

The "multiply by zero" operation returns a single "zero" object:

>>> id(x * 0)
16794004
>>> id(x * 0)
16794004

But, the "multiply by 1" or "divide by 1" does not:

>>> id(x * 1)
17124928
>>> id(x * 1)
17124880
>>> id(x / 1)
17203652
>>> id(x / 1)
17124952

----------
messages: 91479
nosy: mrjbq7
severity: normal
status: open
title: "x / 1" and "x * 1" should return x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6684>
_______________________________________

From report at bugs.python.org  Tue Aug 11 18:44:57 2009
From: report at bugs.python.org (mrjbq7)
Date: Tue, 11 Aug 2009 16:44:57 +0000
Subject: [issue6684] "x / 1" and "x * 1" should return x
In-Reply-To: <1250009070.48.0.664173919374.issue6684@psf.upfronthosting.co.za>
Message-ID: <1250009097.84.0.520487732148.issue6684@psf.upfronthosting.co.za>


Changes by mrjbq7 <mrjbq7 at users.sourceforge.net>:


----------
components: +Interpreter Core
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6684>
_______________________________________

From report at bugs.python.org  Tue Aug 11 18:56:42 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Aug 2009 16:56:42 +0000
Subject: [issue6684] "x / 1" and "x * 1" should return x
In-Reply-To: <1250009070.48.0.664173919374.issue6684@psf.upfronthosting.co.za>
Message-ID: <1250009802.43.0.307774843682.issue6684@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry, Python makes no guarantees about object identity for numbers, so
this is just an optimization request.  While it could save a little
space (one number object) and a little time (for allocating that
object), the special casing imposes a small (but non-zero) cost on every
other case for multiplication and division -- optimizing one corner case
at the expense of the general case.

* practicality beat purity
* special cases are not special enough ...

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6684>
_______________________________________

From report at bugs.python.org  Tue Aug 11 19:56:37 2009
From: report at bugs.python.org (Troy J. Farrell)
Date: Tue, 11 Aug 2009 17:56:37 +0000
Subject: [issue6685] CGI module documentation references method 'toupper';
	should be 'upper'
In-Reply-To: <1250013397.33.0.441269604909.issue6685@psf.upfronthosting.co.za>
Message-ID: <1250013397.33.0.441269604909.issue6685@psf.upfronthosting.co.za>


New submission from Troy J. Farrell <troy at entheossoft.com>:

The cgi module references a method 'toupper' on strings which should
really reference 'upper'.  The line is around 211 of cgi.txt, depending
on the version of the documentation.  Search for "`toupper`", (include
the backticks.)

----------
assignee: georg.brandl
components: Documentation
messages: 91481
nosy: georg.brandl, troy
severity: normal
status: open
title: CGI module documentation references method 'toupper'; should be 'upper'
type: feature request
versions: Python 2.6, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6685>
_______________________________________

From report at bugs.python.org  Tue Aug 11 20:19:33 2009
From: report at bugs.python.org (Collin Winter)
Date: Tue, 11 Aug 2009 18:19:33 +0000
Subject: [issue6643] joining a child that forks can deadlock in the forked
	child process
In-Reply-To: <1249412209.9.0.200329347238.issue6643@psf.upfronthosting.co.za>
Message-ID: <1250014773.56.0.426991064995.issue6643@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
components: +Interpreter Core
nosy: +collinwinter, jyasskin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6643>
_______________________________________

From report at bugs.python.org  Tue Aug 11 21:04:26 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 11 Aug 2009 19:04:26 +0000
Subject: [issue6680] Python 3.1 fails to build when db.h contains non-UTF-8
	characters
In-Reply-To: <1249944443.54.0.496415697007.issue6680@psf.upfronthosting.co.za>
Message-ID: <1250017466.59.0.709852389458.issue6680@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6680>
_______________________________________

From report at bugs.python.org  Tue Aug 11 21:19:54 2009
From: report at bugs.python.org (Colin Stewart)
Date: Tue, 11 Aug 2009 19:19:54 +0000
Subject: [issue6686] xml.sax.xmlreader.XMLReader.getProperty
	(xml.sax.handler.property_xml_string) returns bytes
In-Reply-To: <1250018393.94.0.435666063731.issue6686@psf.upfronthosting.co.za>
Message-ID: <1250018393.94.0.435666063731.issue6686@psf.upfronthosting.co.za>


New submission from Colin Stewart <colin at owlfish.com>:

The documentation for the xml.sax.handler.property_xml_string SAX
property states that it should be "data type: String".  However when
retrieving this value in Python 3.1 it returns a bytes object instead.

This makes handling the returned value very difficult because there is
no method for retrieving the character set encoding that the XML was
originally encoded with.

This is currently blocking the port of SimpleTAL to Python 3 achieving
feature parity with Python 2.

----------
components: XML
messages: 91482
nosy: cms103
severity: normal
status: open
title: xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6686>
_______________________________________

From report at bugs.python.org  Tue Aug 11 23:15:33 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Aug 2009 21:15:33 +0000
Subject: [issue6687] Move the special-case for integer objects out of
	PyBytes_FromObject.
In-Reply-To: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
Message-ID: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

The documentation for PyBytes_FromObject states:

.. cfunction:: PyObject* PyBytes_FromObject(PyObject *o)

   Return the bytes representation of object *o* that implements
   the buffer protocol.

However, there exists a special-case for integer object in
PyBytes_FromObject that makes the function return a null-initialized
bytes object. Currently, this is only used for handling `bytes(10)'.

I don't like changing APIs after a stable release, but I believe this
behaviour is error-prone and surprising (and darn right annoying even).
So, I believe the special-case should be made specific to the bytes
constructor.

Thus, here is the fine patch.

----------
components: Interpreter Core
files: move_int_special_case.diff
keywords: 26backport, patch
messages: 91483
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Move the special-case for integer objects out of PyBytes_FromObject.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14693/move_int_special_case.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6687>
_______________________________________

From report at bugs.python.org  Tue Aug 11 23:18:14 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Aug 2009 21:18:14 +0000
Subject: [issue6687] Move the special-case for integer objects out of
	PyBytes_FromObject.
In-Reply-To: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
Message-ID: <1250025494.99.0.177737914664.issue6687@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Oh, in case you wonder, the added PyUnicode_Check(x) check is to force
PyBytes_FromObject to raise an error when given an empty unicode string
(I will this as a comment in my patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6687>
_______________________________________

From report at bugs.python.org  Tue Aug 11 23:25:20 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Aug 2009 21:25:20 +0000
Subject: [issue6687] Move the special-case for integer objects out of
	PyBytes_FromObject.
In-Reply-To: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
Message-ID: <1250025920.55.0.690724350598.issue6687@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

+1

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6687>
_______________________________________

From report at bugs.python.org  Tue Aug 11 23:34:37 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Aug 2009 21:34:37 +0000
Subject: [issue6688] Optimize PyBytes_FromObject.
In-Reply-To: <1250026477.34.0.625583102893.issue6688@psf.upfronthosting.co.za>
Message-ID: <1250026477.34.0.625583102893.issue6688@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

Optimize PyBytes_FromObject by adding special-cases for list and tuple
objects and by using _PyObject_LengthHint() instead of an arbitrary
value for the size of the initial buffer.

[Without the patch]
./python -m timeit -s "x = list(range(256))" "bytes(x)"
100000 loops, best of 3: 7.19 usec per loop

./python -m timeit -s "x = tuple(range(256))" "bytes(x)"
100000 loops, best of 3: 7.14 usec per loop

./python -m timeit -s "x = list(range(256))*100" "bytes(x)"
1000 loops, best of 3: 591 usec per loop

./python -m timeit -s "x = range(256)" "bytes(x)"
100000 loops, best of 3: 8.45 usec per loop


[With the patch]

./python -m timeit -s "x = list(range(256))" "bytes(x)"
100000 loops, best of 3: 4.43 usec per loop

./python -m timeit -s "x = tuple(range(256))" "bytes(x)"
100000 loops, best of 3: 4.53 usec per loop

./python -m timeit -s "x = list(range(256))*100" "bytes(x)"
1000 loops, best of 3: 335 usec per loop

./python -m timeit -s "x = range(256)" "bytes(x)"
100000 loops, best of 3: 7.56 usec per loop

----------
components: Interpreter Core
files: optimize_bytes_from_object.diff
keywords: patch
messages: 91486
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize PyBytes_FromObject.
type: performance
Added file: http://bugs.python.org/file14694/optimize_bytes_from_object.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6688>
_______________________________________

From report at bugs.python.org  Tue Aug 11 23:38:11 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Aug 2009 21:38:11 +0000
Subject: [issue1023290] proposed struct module format code addition
Message-ID: <1250026691.07.0.0626354502326.issue1023290@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I went ahead and coded a new API for converting long integers to byte
arrays and vice-versa. My patch adds two new methods to the long type:
.as_bytes() and .frombytes(). The patch itself is well-documented; but
nevertheless, here's some examples: 

>>> (1024).as_bytes()
b'\x04\x00'
>>> (1024).as_bytes(fixed_length=10)
b'\x00\x00\x00\x00\x00\x00\x00\x00\x04\x00'
>>> (-1024).as_bytes(fixed_length=10)
b'\xff\xff\xff\xff\xff\xff\xff\xff\xfc\x00'
>>> (-1024).as_bytes(little_endian=True)
b'\x00\xfc'
>>> ((2**16)-1).as_bytes(fixed_length=2, signed=False)
b'\xff\xff'

>>> int.frombytes(b'\x00\x10')
16
>>> int.frombytes(b'\x00\x10', little_endian=True)
4096
>>> int.frombytes(b'\xfc\x00')
-1024
>>> int.frombytes(b'\xfc\x00', signed=False)
64512


This patch depends on another patch posted in issue #6687. So, apply the
other patch before testing this one.

----------
nosy: +alexandre.vassalotti
Added file: http://bugs.python.org/file14695/long_and_bytes_conversion.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Tue Aug 11 23:58:24 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 11 Aug 2009 21:58:24 +0000
Subject: [issue6673] Py3.1 hangs in coroutine and eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1250027904.95.0.0238005941255.issue6673@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Not a bug.

The list comprehension in your chunker:

    while True:
        target.send([ (yield) for i in range(chunk_size) ])

is equivalent to the following generator in Python 3:

    while True:
        def g():
            for i in range(chunk_size):
                yield (yield)
        target.send(list(g()))

This clearly needs not what you want. So, just rewrite your code using
for-loop:

    while True:
        result = []
        for i in range(chunk_size):
            result.append((yield))
        target.send(result)

----------
nosy: +alexandre.vassalotti
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Wed Aug 12 00:58:57 2009
From: report at bugs.python.org (Jacob Rus)
Date: Tue, 11 Aug 2009 22:58:57 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1250031537.63.0.728577081134.issue6626@psf.upfronthosting.co.za>


Jacob Rus <jacobolus at gmail.com> added the comment:

Plone uses this thing, which has *much* more complexity than necessary for 
the standard library, but it might be nice to pick up the code for pulling 
types out of the windows registry, for instance.

http://svn.plone.org/svn/archetypes/Products.MimetypesRegistry/trunk/Produ
cts/MimetypesRegistry/MimeTypesRegistry.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Wed Aug 12 05:00:22 2009
From: report at bugs.python.org (John Machin)
Date: Wed, 12 Aug 2009 03:00:22 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250046022.36.0.0616708172034.issue2636@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

What is the expected timing comparison with re? Running the Aug10#3
version on Win XP SP3 with Python 2.6.3, I see regex typically running
at only 20% to %50 of the speed of re in ASCII mode, with
not-very-atypical tests (find all Python identifiers in a line, failing
search for a Python identifier in an 80-byte text). Is the supplied
_regex.pyd from some sort of debug or unoptimised build? Here are some
results:

dos-prompt>\python26\python -mtimeit -s"import re as
x;r=x.compile(r'[A-Za-z_][A-Za-z0-9_]+');t='    def __init__(self, arg1,
arg2):\n'" "r.findall(t)"
100000 loops, best of 3: 5.32 usec per loop

dos-prompt>\python26\python -mtimeit -s"import regex as
x;r=x.compile(r'[A-Za-z_][A-Za-z0-9_]+');t='    def __init__(self, arg1,
arg2):\n'" "r.findall(t)"
100000 loops, best of 3: 12.2 usec per loop

dos-prompt>\python26\python -mtimeit -s"import re as
x;r=x.compile(r'[A-Za-z_][A-Za-z0-9_]+');t='1234567890'*8" "r.search(t)"
1000000 loops, best of 3: 1.61 usec per loop

dos-prompt>\python26\python -mtimeit -s"import regex as
x;r=x.compile(r'[A-Za-z_][A-Za-z0-9_]+');t='1234567890'*8" "r.search(t)"
100000 loops, best of 3: 7.62 usec per loop

Here's the worst case that I've found so far:

dos-prompt>\python26\python -mtimeit -s"import re as
x;r=x.compile(r'z{80}');t='z'*79" "r.search(t)"
1000000 loops, best of 3: 1.19 usec per loop

dos-prompt>\python26\python -mtimeit -s"import regex as
x;r=x.compile(r'z{80}');t='z'*79" "r.search(t)"
1000 loops, best of 3: 334 usec per loop

See Friedl: "length cognizance". Corresponding figures for match() are
1.11 and 8.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Aug 12 06:40:32 2009
From: report at bugs.python.org (Jacob Rus)
Date: Wed, 12 Aug 2009 04:40:32 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1250052032.43.0.17393069997.issue6626@psf.upfronthosting.co.za>


Changes by Jacob Rus <jacobolus at gmail.com>:


Removed file: http://bugs.python.org/file14632/mimetypes4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Wed Aug 12 06:41:31 2009
From: report at bugs.python.org (Jacob Rus)
Date: Wed, 12 Aug 2009 04:41:31 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1250052091.3.0.474677599481.issue6626@psf.upfronthosting.co.za>


Changes by Jacob Rus <jacobolus at gmail.com>:


Added file: http://bugs.python.org/file14696/mimetypes4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Wed Aug 12 09:33:27 2009
From: report at bugs.python.org (David Fraser)
Date: Wed, 12 Aug 2009 07:33:27 +0000
Subject: [issue2304] subprocess under windows fails to quote properly
	when	shell=True
In-Reply-To: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za>
Message-ID: <1250062407.66.0.0683752142742.issue2304@psf.upfronthosting.co.za>


Changes by David Fraser <davidf at sjsoft.com>:


----------
nosy: +davidfraser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2304>
_______________________________________

From report at bugs.python.org  Wed Aug 12 09:54:24 2009
From: report at bugs.python.org (Chris Withers)
Date: Wed, 12 Aug 2009 07:54:24 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250063664.65.0.157354990447.issue2576@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

I tried to use the following to change the buffersize for a download:

from base64 import encodestring
from httplib import HTTPResponse,HTTPConnection,HTTPSConnection,_UNKNOWN
from datetime import datetime

class FHTTPResponse(HTTPResponse):

    def __init__(self, sock, debuglevel=0, strict=0, method=None):
        print "creating response"
        self.fp = sock.makefile('rb',4096)
        self.debuglevel = debuglevel
        self.strict = strict
        self._method = method

        self.msg = None

        # from the Status-Line of the response
        self.version = _UNKNOWN # HTTP-Version
        self.status = _UNKNOWN  # Status-Code
        self.reason = _UNKNOWN  # Reason-Phrase

        self.chunked = _UNKNOWN         # is "chunked" being used?
        self.chunk_left = _UNKNOWN      # bytes left to read in current 
chunk
        self.length = _UNKNOWN          # number of bytes left in 
response
        self.will_close = _UNKNOWN      # conn will close at end of 
respons    
class FHTTPConnection(HTTPConnection):
    response_class = FHTTPResponse

class FHTTPSConnection(HTTPSConnection):
    response_class = FHTTPResponse

conn = FHTTPSConnection('localhost')
headers = {}
auth = 'Basic '+encodestring('usernmae:password').strip()
headers['Authorization']=
t = datetime.now()
print t
conn.request('GET','/somefile.zip',None,headers)
print 'request:',datetime.now()-t
response = conn.getresponse()
print 'response:',datetime.now()-t
data = response.read()
print 'read:',datetime.now()-t

..however, I saw absolutely no change in download speed.

Aren, I notice in your pastebin code that you do response.read(10485700) 
in a loop rather than just one response.read(), why is that?

----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Wed Aug 12 10:33:58 2009
From: report at bugs.python.org (David Fraser)
Date: Wed, 12 Aug 2009 08:33:58 +0000
Subject: [issue6689] subprocess doesn't pass arguments correctly on Linux when
	shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>


New submission from David Fraser <davidf at sjsoft.com>:

(from
http://stackoverflow.com/questions/1253122/why-does-subprocess-popen-with-shelltrue-work-differently-on-linux-vs-windows/1254322)

When using subprocess.Popen(args, shell=True) to run "gcc --version"
(just as an example), on Windows we get this:

>>> from subprocess import Popen
>>> Popen(['gcc', '--version'], shell=True)
gcc (GCC) 3.4.5 (mingw-vista special r3) ...

So it's nicely printing out the version as I expect. But on Linux we get
this:

>>> from subprocess import Popen
>>> Popen(['gcc', '--version'], shell=True)
gcc: no input files

Because gcc hasn't received the --version option.

The docs don't specify exactly what should happen to the args under
Windows, but it does say, on Unix, "If args is a sequence, the first
item specifies the command string, and any additional items will be
treated as additional shell arguments." IMHO the Windows way is better,
because it allows you to treat Popen(arglist) calls the same as
Popen(arglist, shell=True) ones.

The strange implementation is actually the UNIX one, which does the
following (where each space separates a different argument):

/bin/sh -c gcc --version

It looks like the correct implementation (at least on Linux) would be:

/bin/sh -c "gcc --version" gcc --version

Since this would set the command string from the quoted parameters, and
pass the other parameters successfully.

>From the sh man page section for -c:

    Read commands from the command_string operand instead of from the
standard input. Special parameter 0 will be set from the command_name
operand and the positional parameters ($1, $2, etc.) set from the
remaining argument operands.

This patch seems to fairly simply do the trick, as well as testing it.

----------
components: Library (Lib)
files: current-2.6.patch
keywords: patch
messages: 91492
nosy: davidfraser
severity: normal
status: open
title: subprocess doesn't pass arguments correctly on Linux when shell=True
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14697/current-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________

From report at bugs.python.org  Wed Aug 12 10:34:45 2009
From: report at bugs.python.org (David Fraser)
Date: Wed, 12 Aug 2009 08:34:45 +0000
Subject: [issue6689] subprocess doesn't pass arguments correctly on Linux when
	shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250066085.64.0.688283004424.issue6689@psf.upfronthosting.co.za>


Changes by David Fraser <davidf at sjsoft.com>:


Added file: http://bugs.python.org/file14698/current-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________

From report at bugs.python.org  Wed Aug 12 12:30:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Aug 2009 10:30:55 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250073055.23.0.957361754558.issue2576@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I must admit I don't understand the conflict between buffering and
pipelined requests. This is all sequential reading and the buffer should
be transparent, shouldn't it?

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Wed Aug 12 13:11:22 2009
From: report at bugs.python.org (Chris Withers)
Date: Wed, 12 Aug 2009 11:11:22 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250075482.58.0.77107510479.issue2576@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Well, for me, buffer size doesn't appear to have made any difference...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Wed Aug 12 14:04:10 2009
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 12 Aug 2009 12:04:10 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250078650.91.0.50242524046.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

</lurk>
Re: timings

Thanks for the info, John.  First of all, I really like those tests and
could you please submit a patch or other document so that we could
combine them into the python test suite.

The python test suite, which can be run as part of 'make test' or IIRC
there is a way to run JUST the 2 re test suites which I seem to have
senior moment'd, includes a built-in timing output over some of the
tests, though I don't recall which ones were being timed: standard cases
or pathological (rare) ones.  Either way, we should include some timings
that are of a standard nature in the test suite to make Matthew's and
any other developer's work easier.

So, John, if you are not familiar with the test suite, I can look into
adding the specific cases you've developed into the test suite so we can
have a more representative timing of things.  Remember, though, that
when run as a single instance, at least in the existing engine, the re
compiler caches recent compiles, so repeatedly compiling an expression
flattens the overhead in a single run to a single compile and lookup,
where as your tests recompile at each test (though I'm not sure what
timeit is doing: if it invokes a new instance of python each time, it is
recompiling each time, if it is reusing the instance, it is only
compiling once).

Having not looked at Matthew's regex code recently (nice name, BTW), I
don't know if it also contains the compiled expression cache, in which
case, adding it in might help timings.  Originally, the cache worked by
storing ~100 entries and cleared itself when full; I have a modification
which increases this to 256 (IIRC) and only removes the 128 oldest to
prevent thrashing at the boundary which I think is better if only for a
particular pathological case.

In any case, don't despair at these numbers, Matthew: you have a lot of
time and potentially a lot of ways to make your engine faster by the
time 1.7 alpha is coined.  But also be forewarned, because, knowing what
I know about the current re engine and what it is further capable of, I
don't think your regex will be replacing re in 1.7 if it isn't at least
as fast as the existing engine for some standard set of agreed upon
tests, no matter how many features you can add.  I have no doubt, with a
little extra monkey grease, we could implement all new features in the
existing engine.  I don't want to have to reinvent the wheel, of course,
and if Matthew's engine can pick up some speed everybody wins!  So, keep
up the good work Matthew, as it's greatly appreciated!

Thanks all!

Jeffrey.

<lurk>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Aug 12 14:16:22 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Aug 2009 12:16:22 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1250078650.91.0.50242524046.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250079563.15735.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Remember, though, that
> when run as a single instance, at least in the existing engine, the re
> compiler caches recent compiles, so repeatedly compiling an expression
> flattens the overhead in a single run to a single compile and lookup,
> where as your tests recompile at each test

They don't. The pattern is compiled only once. Please take a look at
http://docs.python.org/library/timeit.html#command-line-interface

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Aug 12 14:29:13 2009
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Wed, 12 Aug 2009 12:29:13 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250080153.8.0.724721325323.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Mea culpa et mes apologies,

The '-s' option to John's expressions are indeed executed only once --
they are one-time setup lines.  The final quoted expression is what's
run multiple times.

In other words, improving caching in regex will not help.  >sigh<

Merci, Antoine!

Jeffrey.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Aug 12 14:42:50 2009
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 12 Aug 2009 12:42:50 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250080970.77.0.652359549322.issue2636@psf.upfronthosting.co.za>


Changes by Walter D?rwald <walter at livinglogic.de>:


----------
nosy:  -doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Aug 12 17:51:35 2009
From: report at bugs.python.org (Jack Diederich)
Date: Wed, 12 Aug 2009 15:51:35 +0000
Subject: [issue6582] test_telnetlib doesn't test Telnet.write
In-Reply-To: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>
Message-ID: <1250092295.29.0.864409099066.issue6582@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Thanks Rodrigo,  I'll integrate this and check it in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6582>
_______________________________________

From report at bugs.python.org  Wed Aug 12 18:43:59 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 16:43:59 +0000
Subject: [issue1612262] Class Browser doesn't show internal classes
Message-ID: <1250095439.58.0.165688469361.issue1612262@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

The attached patch adds support for nested objects in pyclbr and also in
ClassBrowser.

I have yet to find an optimal way to test this on test_pyclbr (I did
some things here, none very nice), so you will notice tests are missing
on this patch.

----------
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file14699/show_nested_objects.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1612262>
_______________________________________

From report at bugs.python.org  Wed Aug 12 20:01:39 2009
From: report at bugs.python.org (Collin Winter)
Date: Wed, 12 Aug 2009 18:01:39 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250100099.58.0.112960791264.issue2636@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

FYI, Unladen Swallow includes several regex benchmark suites: a port of 
V8's regex benchmarks (regex_v8); some of the regexes used when tuning 
the existing sre engine 7-8 years ago (regex_effbot); and a 
regex_compile benchmark that tests regex compilation time.

See http://code.google.com/p/unladen-swallow/wiki/Benchmarks for more 
details, including how to check out and run the benchmark suite. You'll 
need to modify your experimental Python build to have "import re" import 
the proposed regex engine, rather than _sre. The benchmark command would 
look something like `./perf.py -r -b regex /control/python 
/experiment/python`, which will run all the regex benchmarks in rigorous 
mode. I'll be happy to answer any questions you have about our 
benchmarks.

I'd be very interested to see how the proposed regex engine performs on 
these tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Aug 12 20:17:55 2009
From: report at bugs.python.org (Bertrand Janin)
Date: Wed, 12 Aug 2009 18:17:55 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1250101075.98.0.62412626982.issue3244@psf.upfronthosting.co.za>


Changes by Bertrand Janin <tamentis at neopulsar.org>:


----------
nosy: +tamentis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Wed Aug 12 20:18:24 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Aug 2009 18:18:24 +0000
Subject: [issue6680] Python 3.1 fails to build when db.h contains non-UTF-8
	characters
In-Reply-To: <1249944443.54.0.496415697007.issue6680@psf.upfronthosting.co.za>
Message-ID: <1250101104.23.0.360615819265.issue6680@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r74357.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6680>
_______________________________________

From report at bugs.python.org  Wed Aug 12 20:31:52 2009
From: report at bugs.python.org (Chad Miller)
Date: Wed, 12 Aug 2009 18:31:52 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1250101912.82.0.738351256398.issue1068268@psf.upfronthosting.co.za>


Chad Miller <python at chad.org> added the comment:

File
"/home/cmiller/work/cabzr/desktopcouch/getport-at-call-time/desktopcouch/start_local_couchdb.py",
line 93, in run_couchdb
    retcode = subprocess.call(local_exec)
  File "/usr/lib/python2.6/subprocess.py", line 444, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.6/subprocess.py", line 1123, in wait
    pid, sts = os.waitpid(self.pid, 0)
exceptions.OSError: [Errno 4] Interrupted system call

Now what?  The process started, but I have no way of knowing when it
finishes or the exit value when it does, because I don't have access to
the Popen object.  Nor can I even kill it and try again, because I can't
get he process id.

try/except in my code can never help.  It must be put in the stdlib.

Or, if this is too egregious, then the docs should scream that
subprocess.call can never safely be used, and users should avoid it.



  File
"/home/cmiller/work/cabzr/desktopcouch/getport-at-call-time/desktopcouch/start_local_couchdb.py",
line 93, in run_couchdb
    retcode = subprocess.call(local_exec)
  File "/usr/lib/python2.6/subprocess.py", line 444, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.6/subprocess.py", line 595, in __init__
    errread, errwrite)
  File "/usr/lib/python2.6/subprocess.py", line 1084, in _execute_child
    data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
exceptions.OSError: [Errno 4] Interrupted system call


This os.read is a byproduct of something the Popen.__init__
implementation must do, and it is safe for it to continue to get the
information it needs, without the user's knowledge.

The process is started, then this is aborted before the Popen.stdout and
.stderr are set up, leaving the object in a weird state.

----------
nosy: +cmiller
Added file: http://bugs.python.org/file14700/trunk-diff-unified.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Wed Aug 12 21:19:58 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 Aug 2009 19:19:58 +0000
Subject: [issue6686] xml.sax.xmlreader.XMLReader.getProperty
	(xml.sax.handler.property_xml_string) returns bytes
In-Reply-To: <1250018393.94.0.435666063731.issue6686@psf.upfronthosting.co.za>
Message-ID: <1250104798.54.0.938991288343.issue6686@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Would you like to contribute a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6686>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:06:34 2009
From: report at bugs.python.org (Colin Stewart)
Date: Wed, 12 Aug 2009 21:06:34 +0000
Subject: [issue6686] xml.sax.xmlreader.XMLReader.getProperty
	(xml.sax.handler.property_xml_string) returns bytes
In-Reply-To: <1250018393.94.0.435666063731.issue6686@psf.upfronthosting.co.za>
Message-ID: <1250111194.27.0.657777189248.issue6686@psf.upfronthosting.co.za>


Colin Stewart <colin at owlfish.com> added the comment:

I'm not familiar with the inner workings of the expat integration with
Python, so the attached patches need careful review.

The first patch (expatreader.py.patch) is the minimum to resolve this
issue.  The second patch (expatreader.py.patch2) also exposes the
version and encoding parameters via the Locator2 interface
(http://www.saxproject.org/apidoc/org/xml/sax/ext/Locator2.html), which
I'd recommend including.

----------
keywords: +patch
Added file: http://bugs.python.org/file14701/expatreader.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6686>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:07:28 2009
From: report at bugs.python.org (Colin Stewart)
Date: Wed, 12 Aug 2009 21:07:28 +0000
Subject: [issue6686] xml.sax.xmlreader.XMLReader.getProperty
	(xml.sax.handler.property_xml_string) returns bytes
In-Reply-To: <1250018393.94.0.435666063731.issue6686@psf.upfronthosting.co.za>
Message-ID: <1250111248.17.0.853220394899.issue6686@psf.upfronthosting.co.za>


Colin Stewart <colin at owlfish.com> added the comment:

Adding second patch.

----------
Added file: http://bugs.python.org/file14702/expatreader.py.patch2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6686>
_______________________________________

From report at bugs.python.org  Wed Aug 12 23:32:08 2009
From: report at bugs.python.org (Alex)
Date: Wed, 12 Aug 2009 21:32:08 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

Just like we turn BUILD_LIST; COMPARE_OP (in) into a LOAD_CONST if all
the members are consts, we can do the same for BUILD_SET, instead
turning it into a LOAD_CONST of a frozenset.  The following is the
bytecode that is current produced for each datastructure.

>>> dis.dis(lambda o: o in (1,2,3))
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               3 ((1, 2, 3)) 
              6 COMPARE_OP               6 (in) 
              9 RETURN_VALUE         
>>> dis.dis(lambda o: o in [1,2,3])
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               3 ((1, 2, 3)) 
              6 COMPARE_OP               6 (in) 
              9 RETURN_VALUE         
>>> dis.dis(lambda o: o in {1,2,3})
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               0 (1) 
              6 LOAD_CONST               1 (2) 
              9 LOAD_CONST               2 (3) 
             12 BUILD_SET                3 
             15 COMPARE_OP               6 (in) 
             18 RETURN_VALUE

----------
components: Interpreter Core
messages: 91506
nosy: alex
severity: normal
status: open
title: BUILD_SET followed by COMPARE_OP (in) can be optimized if all items are consts
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:23:37 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Aug 2009 22:23:37 +0000
Subject: [issue6599] 2to3 test_print_function_option fails on Windows
In-Reply-To: <1248916455.36.0.400701947417.issue6599@psf.upfronthosting.co.za>
Message-ID: <1250115817.48.0.616263420783.issue6599@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r74359.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6599>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:47:42 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 22:47:42 +0000
Subject: [issue6691] Support for nested classes and function for pyclbr
In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
Message-ID: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

I have worked on a patch for adding support for nested classes and
nested functions in pyclbr. I believe this might be useful for some
applications, and also for issue1612262.

The patch attached also contains a test and updated documentation.

----------
components: Library (Lib)
files: pyclbr_nested_objects.diff
keywords: patch
messages: 91508
nosy: gpolo
severity: normal
status: open
title: Support for nested classes and function for pyclbr
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14703/pyclbr_nested_objects.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6691>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:48:57 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 22:48:57 +0000
Subject: [issue6691] Support for nested classes and function for pyclbr
In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
Message-ID: <1250117337.49.0.989964366892.issue6691@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file14703/pyclbr_nested_objects.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6691>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:49:18 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 22:49:18 +0000
Subject: [issue6691] Support for nested classes and function for pyclbr
In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
Message-ID: <1250117358.4.0.105066504535.issue6691@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
dependencies: +Support for nested classes and function for pyclbr
Added file: http://bugs.python.org/file14704/classbrowser_nesting_support.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6691>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:49:38 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 22:49:38 +0000
Subject: [issue6691] Support for nested classes and function for pyclbr
In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
Message-ID: <1250117378.15.0.913028558468.issue6691@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file14704/classbrowser_nesting_support.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6691>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:49:58 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 22:49:58 +0000
Subject: [issue6691] Support for nested classes and function for pyclbr
In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
Message-ID: <1250117398.19.0.819519605392.issue6691@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
dependencies:  -Support for nested classes and function for pyclbr
Added file: http://bugs.python.org/file14705/pyclbr_nested_objects.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6691>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:51:15 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 22:51:15 +0000
Subject: [issue1612262] Class Browser doesn't show internal classes
Message-ID: <1250117475.59.0.277010843017.issue1612262@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I've removed the previous patch from here and attached an updated one on
issue6691.

Now the patch attached here only contains changes related to
idlelib.ClassBrowser.

----------
dependencies: +Support for nested classes and function for pyclbr
Added file: http://bugs.python.org/file14706/classbrowser_nesting_support.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1612262>
_______________________________________

From report at bugs.python.org  Thu Aug 13 00:51:23 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 12 Aug 2009 22:51:23 +0000
Subject: [issue1612262] Class Browser doesn't show internal classes
Message-ID: <1250117483.91.0.256456556114.issue1612262@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file14699/show_nested_objects.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1612262>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:16:38 2009
From: report at bugs.python.org (Ben Hoyt)
Date: Wed, 12 Aug 2009 23:16:38 +0000
Subject: [issue6689] subprocess doesn't pass arguments correctly on Linux when
	shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250118998.12.0.664284264541.issue6689@psf.upfronthosting.co.za>


Changes by Ben Hoyt <benhoyt at gmail.com>:


----------
nosy: +benhoyt
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________

From report at bugs.python.org  Thu Aug 13 01:18:04 2009
From: report at bugs.python.org (Ben Hoyt)
Date: Wed, 12 Aug 2009 23:18:04 +0000
Subject: [issue6689] subprocess doesn't pass arguments correctly on Linux when
	shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250119084.21.0.640025764581.issue6689@psf.upfronthosting.co.za>


Ben Hoyt <benhoyt at gmail.com> added the comment:

Oops, didn't intend to change the type, changing back.

----------
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________

From report at bugs.python.org  Thu Aug 13 03:17:09 2009
From: report at bugs.python.org (Berwyn)
Date: Thu, 13 Aug 2009 01:17:09 +0000
Subject: [issue6689] subprocess doesn't pass arguments correctly on Linux when
	shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250126229.31.0.432824180134.issue6689@psf.upfronthosting.co.za>


Berwyn <berwyn at brush.co.nz> added the comment:

I agree with the patch, and it works fine:
    /bin/sh -c "gcc --version" gcc --version

But I begin to wonder whether bash has a bug since bash only seems to
observe the string, not the parameters after it.  For example:
    $ bash -c "./printargs.py abc" def ghi jkl
produces:
    ['./printargs.py', 'abc']

where printargs.py is:
    #!/usr/bin/python
    import sys
    print sys.argv

Just something to be aware of.

----------
nosy: +berwyn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________

From report at bugs.python.org  Thu Aug 13 03:34:09 2009
From: report at bugs.python.org (Andrew Azarov)
Date: Thu, 13 Aug 2009 01:34:09 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>


New submission from Andrew Azarov <equand at gmail.com>:

Is there a possibility of such feature in the future releases of Python?
Currently I see only select and epoll available, but on FreeBSD 7.2 with
a lot of connections asyncore (1600+ active HTTP connections) has
problems (not giving complete response) with epoll (select is
problematic after 250+ connections (not enough descriptors)).

----------
components: Library (Lib)
messages: 91512
nosy: Ikinoki
severity: normal
status: open
title: asyncore kqueue support
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6692>
_______________________________________

From report at bugs.python.org  Thu Aug 13 05:28:22 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 03:28:22 +0000
Subject: [issue3573] IDLE hangs when passing invalid command line args
	(directory(ies) instead of file(s))
In-Reply-To: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>
Message-ID: <1250134102.93.0.237044121897.issue3573@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
superseder:  -> Idle hangs when given a nonexistent filename.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3573>
_______________________________________

From report at bugs.python.org  Thu Aug 13 05:28:40 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 03:28:40 +0000
Subject: [issue3573] IDLE hangs when passing invalid command line args
	(directory(ies) instead of file(s))
In-Reply-To: <1218929546.33.0.178143371283.issue3573@psf.upfronthosting.co.za>
Message-ID: <1250134120.85.0.726632002771.issue3573@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
superseder: Idle hangs when given a nonexistent filename. -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3573>
_______________________________________

From report at bugs.python.org  Thu Aug 13 05:29:30 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 03:29:30 +0000
Subject: [issue4985] Idle hangs when given a nonexistent filename.
In-Reply-To: <1232256473.01.0.852239057685.issue4985@psf.upfronthosting.co.za>
Message-ID: <1250134170.34.0.0428932921054.issue4985@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Closing this in favour of issue 3573.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> IDLE hangs when passing invalid command line args (directory(ies) instead of file(s))

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4985>
_______________________________________

From report at bugs.python.org  Thu Aug 13 09:49:02 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 13 Aug 2009 07:49:02 +0000
Subject: [issue6679] obsolete paragraph in re doc for re.sub
In-Reply-To: <1249935038.17.0.324286013964.issue6679@psf.upfronthosting.co.za>
Message-ID: <1250149742.61.0.595785601256.issue6679@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74365.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6679>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:17:23 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 13 Aug 2009 08:17:23 +0000
Subject: [issue6126] Python 3 pdb: shows internal code, breakpoints don't work
In-Reply-To: <1243451707.7.0.0771543881281.issue6126@psf.upfronthosting.co.za>
Message-ID: <1250151443.37.0.25284549547.issue6126@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74366, and merged back to 3.1 branch in r74367.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6126>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:31:58 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 13 Aug 2009 08:31:58 +0000
Subject: [issue6693] New functions in site.py to get user/global site packages
	paths
In-Reply-To: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>
Message-ID: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

As discussed in Distutils-SIG.

Here's a patch for site.py that adds:

- getsitepackages : Returns a list containing all global site-packages
directories (and possibly site-python).

- getusersitepackages: Returns the user-specific site-packages directory
path.

- getuserbase: Returns the `user base` directory path.

----------
assignee: tarek
components: Library (Lib)
files: site.patch
keywords: patch
messages: 91516
nosy: tarek
priority: normal
severity: normal
status: open
title: New functions in site.py to get user/global site packages paths
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14707/site.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6693>
_______________________________________

From report at bugs.python.org  Thu Aug 13 10:40:56 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Aug 2009 08:40:56 +0000
Subject: [issue6693] New functions in site.py to get user/global site packages
	paths
In-Reply-To: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>
Message-ID: <1250152856.9.0.610063454127.issue6693@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Two things:

 * The globals should get a comment explaining what their purpose is and
where they are being initialized.

 * The get*() functions should only initialize the globals if they are
set to None. In the patch, they are initialized every time the functions
are called.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6693>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:04:09 2009
From: report at bugs.python.org (Alex Morega)
Date: Thu, 13 Aug 2009 09:04:09 +0000
Subject: [issue6694] itertools documentation still contains references to
	ifilterfalse and izip_longest
In-Reply-To: <1250154249.26.0.325655481188.issue6694@psf.upfronthosting.co.za>
Message-ID: <1250154249.26.0.325655481188.issue6694@psf.upfronthosting.co.za>


New submission from Alex Morega <alex at grep.ro>:

The pages http://docs.python.org/dev/py3k/library/itertools.html and 
http://docs.python.org/3.1/library/itertools.html contain the names 
"ifilterfalse" and "izip_longest" in code examples for the "filterfalse" 
and "zip_longest" functions.

----------
assignee: georg.brandl
components: Documentation
messages: 91518
nosy: alex.morega, georg.brandl
severity: normal
status: open
title: itertools documentation still contains references to ifilterfalse and izip_longest
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6694>
_______________________________________

From report at bugs.python.org  Thu Aug 13 11:16:46 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 13 Aug 2009 09:16:46 +0000
Subject: [issue6694] itertools documentation still contains references to
	ifilterfalse and izip_longest
In-Reply-To: <1250154249.26.0.325655481188.issue6694@psf.upfronthosting.co.za>
Message-ID: <1250155006.11.0.486408774614.issue6694@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74398.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6694>
_______________________________________

From report at bugs.python.org  Thu Aug 13 18:45:31 2009
From: report at bugs.python.org (Matthias Troffaes)
Date: Thu, 13 Aug 2009 16:45:31 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>


New submission from Matthias Troffaes <matthias.troffaes at gmail.com>:

The Python C API provides PyXXX_ClearFreeList functions to allow the
float, int, etc... freelists to be freed, potentially releasing memory
to the OS earlier. Currently, there is no such API for the dict, set,
and list freelists.

The attached patch adds PyXXX_ClearFreeList functions to the C API, so
the dict, set, and list freelists can be freed as well.

----------
components: Interpreter Core
files: py3k-clearfreelist-dict_set_list.patch
keywords: patch
messages: 91520
nosy: matthiastroffaes
severity: normal
status: open
title: PyXXX_ClearFreeList for dict, set, and list
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14708/py3k-clearfreelist-dict_set_list.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Thu Aug 13 18:49:09 2009
From: report at bugs.python.org (Matthias Troffaes)
Date: Thu, 13 Aug 2009 16:49:09 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250182149.06.0.442635782799.issue6695@psf.upfronthosting.co.za>


Matthias Troffaes <matthias.troffaes at gmail.com> added the comment:

I attach a second patch which also calls the new PyXXX_ClearFreeList
functions on garbage collection, during gc.collect().

----------
Added file: http://bugs.python.org/file14709/py3k-clearfreelist-gc_collect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Thu Aug 13 18:57:17 2009
From: report at bugs.python.org (Alexander Myodov)
Date: Thu, 13 Aug 2009 16:57:17 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

Seems like a minor documentation issue in 2.x became more significant 
one in 3.x.

In Python 2.6 (and lower), the documentation on Profile objects 
discussed them as a part of hotshot module, while omitting the fact 
that any profiler module, either of profile/cProfile/hotshot, supports 
them (though in fact, hotshot Profile objects have an api a bit 
different from profile/cProfile Profile objects). Note http://
docs.python.org/2.6/library/hotshot.html#profile-objects - there is no 
separate documentation of non-hotshot Profile objects, though they are 
largely similar. This is a minor issue which could probably be fixed in 
2.7 as a separate problem - otherwise it is pretty unclear from the 
documentation, what methods do cProfile Profile objects support (eg, 
they support enable()/disable() and runcall() methods, which is pretty 
useful for profiling, but impossible to find in documentation).

In Python 3.1, looks like everything related to hotshot was removed 
from the documents, including the documentation on Profile objects - 
which should not have been. This means, that now the documentation on 
profilers does not cover any Profile classes at all - see http://
docs.python.org/3.1/library/profile.html . For example, the official 
documentation doesn't say any way to profile a function passing 
arguments to it and receiving its result - while profile/cProfile 
Profile objects still do support runcall() method.

----------
assignee: georg.brandl
components: Documentation
messages: 91522
nosy: georg.brandl, honeyman
severity: normal
status: open
title: Profile objects should be documented
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6696>
_______________________________________

From report at bugs.python.org  Thu Aug 13 18:57:45 2009
From: report at bugs.python.org (Matthias Troffaes)
Date: Thu, 13 Aug 2009 16:57:45 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250182665.24.0.716875666555.issue6695@psf.upfronthosting.co.za>


Matthias Troffaes <matthias.troffaes at gmail.com> added the comment:

I'm also attaching a test script to check the effect of the two patches
on gc.collect(). If many objects are allocated, space savings appear to
be relevant.



Before applying the patch (debug build on linux 64 bit):

Memory used (begin): 121Mb

memtest 2000000 int
====================
Memory used (peak): 297Mb
Memory used (end): 122Mb
Unfreed memory: 1Mb

memtest 2000000 str
====================
Memory used (peak): 455Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 float
====================
Memory used (peak): 236Mb
Memory used (end): 127Mb
Unfreed memory: 6Mb

memtest 2000000 int
====================
Memory used (peak): 313Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 Test
====================
Memory used (peak): 372Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 Test2
====================
Memory used (peak): 361Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 _tuple
====================
Memory used (peak): 529Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 _set
====================
Memory used (peak): 846Mb
Memory used (end): 765Mb
Unfreed memory: 644Mb

memtest 2000000 _dict
====================
Memory used (peak): 1241Mb
Memory used (end): 1241Mb
Unfreed memory: 1120Mb

memtest 2000000 Test3
====================
Memory used (peak): 1241Mb
Memory used (end): 765Mb
Unfreed memory: 644Mb
[40720 refs]



After applying the patch (same build system):

Memory used (begin): 121Mb

memtest 2000000 int
====================
Memory used (peak): 298Mb
Memory used (end): 121Mb
Unfreed memory: 0Mb

memtest 2000000 str
====================
Memory used (peak): 455Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 float
====================
Memory used (peak): 236Mb
Memory used (end): 127Mb
Unfreed memory: 6Mb

memtest 2000000 int
====================
Memory used (peak): 312Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 Test
====================
Memory used (peak): 374Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 Test2
====================
Memory used (peak): 361Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 _tuple
====================
Memory used (peak): 528Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 _set
====================
Memory used (peak): 846Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 _dict
====================
Memory used (peak): 1240Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 Test3
====================
Memory used (peak): 999Mb
Memory used (end): 123Mb
Unfreed memory: 2Mb
[40740 refs]

----------
Added file: http://bugs.python.org/file14710/py3k-freelist_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Thu Aug 13 19:42:22 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 13 Aug 2009 17:42:22 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1250185342.22.0.347249721005.issue3392@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Unfortunately, this change has broken windows support of the subprocess
module, which now reports, on "import subprocess".

>>> import subprocess
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\loewis\31\python\lib\subprocess.py", line 390, in <module>
    _PIPE_BUF = getattr(select, 'PIPE_BUF', 512)
NameError: name 'select' is not defined

As a consequence, even building Python on Windows now fails, so setting
the priority to "release blocker". One solution would be to move the
"import select" to being top-level.

----------
nosy: +benjamin.peterson, loewis
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Thu Aug 13 19:58:53 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Aug 2009 17:58:53 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1250186333.67.0.0348150121878.issue3392@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

r73916 appears to fix this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Thu Aug 13 20:00:58 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 13 Aug 2009 18:00:58 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250186458.37.0.999600339635.issue6695@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Instead of expanding the C API for each type which supports a free
list perhaps there should be a single call, say, PyObject_ClearFreeList,
which takes a pointer to the appropriate type object as an argument.
PyTypeObject can then grow a tp_free_list slot through which the
function calls a type-specific free list clearing function.

Skip

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Thu Aug 13 20:04:32 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 13 Aug 2009 18:04:32 +0000
Subject: [issue3158] Doctest fails to find doctests in extension modules
In-Reply-To: <1214015505.39.0.384160170018.issue3158@psf.upfronthosting.co.za>
Message-ID: <1250186672.15.0.098142116507.issue3158@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

I've added Tim Peters to the nosy list. Is there anyone else who should
be considered as doctest maintainer? I've also checked further Python
versions - a quick a look at latest doctest source shows that the
problem is still there.

There are some details (and a workaround) in Cython FAQ:
http://wiki.cython.org/FAQ#HowcanIrundoctestsinCythoncode.28pyxfiles.29.3F

----------
nosy: +ash, tim_one
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3158>
_______________________________________

From report at bugs.python.org  Thu Aug 13 20:07:30 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 18:07:30 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1250186850.58.0.0228108275913.issue5150@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This has been closed but why not promote reindent.py to a module and add
an option on IDLE to allow a complete reindent.py run ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Thu Aug 13 20:34:09 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Aug 2009 18:34:09 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1250188449.59.0.874561065414.issue3392@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

merged into release31-maint in r74425.

reopen the issue if this doesn't fix the problem.

----------
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Thu Aug 13 20:37:14 2009
From: report at bugs.python.org (sorin)
Date: Thu, 13 Aug 2009 18:37:14 +0000
Subject: [issue4015] [patch] make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1250188634.36.0.113426462028.issue4015@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

I totally agree that we must create batch files for commands but not by
including python code inside them.

----------
nosy: +sorin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4015>
_______________________________________

From report at bugs.python.org  Thu Aug 13 20:52:24 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Aug 2009 18:52:24 +0000
Subject: [issue3392] subprocess fails in select when descriptors are large
In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za>
Message-ID: <1250189544.32.0.546949384371.issue3392@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I will retag 3.1.1rc then...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3392>
_______________________________________

From report at bugs.python.org  Thu Aug 13 20:57:23 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Aug 2009 18:57:23 +0000
Subject: [issue1628205] socket.readline() interface doesn't handle EINTR
	properly
Message-ID: <1250189843.39.0.3221227212.issue1628205@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in trunk r74426.  socket.socket.sendall() and all
socket._fileobject methods (read/readline/write/flush) now properly
handle EINTR internally.

sendall will allow a python signal handler to raise an exception
aborting it in unknown state, otherwise it handles EINTR as it should
and continues sending.

I'm leaving this issue open until it is merged into py3k and considered
for 2.6 and/or 3.1 release backporting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628205>
_______________________________________

From report at bugs.python.org  Thu Aug 13 22:07:32 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 13 Aug 2009 20:07:32 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters are
	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Python 3.1 segfaults when invalid UTF-8 characters are passed from
command line.

In BASH shell you can run:
$ python3.1 -c $'print("\x80")'
Segmentation fault

In other POSIX-compatible shells you can save the attached test.py
files in current directory and run:
$ python3.1 -c "$(<test.py)"
Segmentation fault

----------
components: Unicode
files: test.py
messages: 91533
nosy: Arfrever
severity: normal
status: open
title: Python 3.1 segfaults when invalid UTF-8 characters are passed from command line
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14711/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Thu Aug 13 22:10:49 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Aug 2009 20:10:49 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters are
	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250194249.74.0.347306934115.issue6697@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Thu Aug 13 22:12:09 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Aug 2009 20:12:09 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters are
	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250194329.62.0.405164675092.issue6697@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Thu Aug 13 22:49:25 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 13 Aug 2009 20:49:25 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters are
	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250196565.9.0.602194073729.issue6697@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I'm attaching crashers/invalid_utf8_characters_from_command_line.py.

----------
Added file: http://bugs.python.org/file14712/invalid_utf8_characters_from_command_line.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Thu Aug 13 22:52:43 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 13 Aug 2009 20:52:43 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters are
	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250196763.97.0.0497495253967.issue6697@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Removed file: http://bugs.python.org/file14712/invalid_utf8_characters_from_command_line.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Thu Aug 13 22:53:21 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 13 Aug 2009 20:53:21 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters are
	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250196801.3.0.845885579711.issue6697@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file14713/invalid_utf8_characters_from_command_line.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Thu Aug 13 23:02:10 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Aug 2009 21:02:10 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters are
	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250197330.53.0.713701142621.issue6697@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Thu Aug 13 23:14:05 2009
From: report at bugs.python.org (Alex Willmer)
Date: Thu, 13 Aug 2009 21:14:05 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250198045.18.0.619263219802.issue2636@psf.upfronthosting.co.za>


Alex Willmer <alex at moreati.org.uk> added the comment:

I've made an installable package of Matthew Barnett's patch. It may get
this to a wider audience. 

http://pypi.python.org/pypi/regex

Next I'll look at incorporating Andrew Kuchling's suggestion of the re
tests from CPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Aug 14 00:03:11 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 22:03:11 +0000
Subject: [issue6698] IDLE no longer opens only an edit window when configured
	to do so
In-Reply-To: <1250200991.43.0.141209205867.issue6698@psf.upfronthosting.co.za>
Message-ID: <1250200991.43.0.141209205867.issue6698@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

If someone configure IDLE to start a edit window by default, I believe
it should open only an edit window without starting shell window. This
has been the behaviour in previous version, but it is acting different now.

I looked into r71126 and I think this behaviour was changed there
unintentionally. Its log message doesn't seem to mention this change,
that is why I'm thinking this.

----------
components: IDLE
messages: 91536
nosy: gpolo
severity: normal
status: open
title: IDLE no longer opens only an edit window when configured to do so
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6698>
_______________________________________

From report at bugs.python.org  Fri Aug 14 01:58:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 23:58:50 +0000
Subject: [issue6699] IDLE: Warn user about overwriting a file that has a newer
	version on filesystem
In-Reply-To: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>
Message-ID: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

Creating this issue to address a suggestion of a new IDLE feature
pointed out on issue 1721083.

The feature in question is about warning the user about a newer version
of the file before overwriting it.

----------
components: IDLE
files: check_stmtime.diff
keywords: patch
messages: 91537
nosy: gpolo
severity: normal
status: open
title: IDLE: Warn user about overwriting a file that has a newer version on filesystem
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14714/check_stmtime.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6699>
_______________________________________

From report at bugs.python.org  Fri Aug 14 01:59:56 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 13 Aug 2009 23:59:56 +0000
Subject: [issue1721083] Add File - Reload
Message-ID: <1250207996.69.0.963310037775.issue1721083@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Kurt, there is now a patch on issue 6699 which adds your suggested feature:

"Adding a warning when saving that the file has changed on disk is a
good emacs feature which has saved my bacon a number of times.  That
would be a good feature to add to IDLE, but that's a different request".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721083>
_______________________________________

From report at bugs.python.org  Fri Aug 14 03:24:16 2009
From: report at bugs.python.org (Sye van der Veen)
Date: Fri, 14 Aug 2009 01:24:16 +0000
Subject: [issue812750] OSA support for properties broken
Message-ID: <1250213056.82.0.812013215203.issue812750@psf.upfronthosting.co.za>


Sye van der Veen <syeberman at rogers.com> added the comment:

I've attached a patch to remove "a replacement is expected for Python 
2.5".

----------
keywords: +patch
nosy: +syeberman
status: pending -> open
Added file: http://bugs.python.org/file14715/Issue812750.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812750>
_______________________________________

From report at bugs.python.org  Fri Aug 14 05:26:32 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 14 Aug 2009 03:26:32 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1250220392.82.0.513765355651.issue5689@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


----------
nosy: +Nikratio

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Fri Aug 14 05:51:12 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Aug 2009 03:51:12 +0000
Subject: [issue6681] email.parser clips trailing \n of multipart/mixed part if
	part ends in \r\n
In-Reply-To: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>
Message-ID: <1250221872.62.0.801034785231.issue6681@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks like it is a regular expression issue.  The code is trying to
delete the last linend before the boundary, which belongs to the
boundary according to the RFC, but it does so with the following RE:

    (\r\n|\r|\n)$

This RE matches '\r\n' in '\r\n\n', which is what Guido's message had. 
The code then deletes the number of characters equal to the length of
the match.  So yes, it is a mixed line ending problem.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6681>
_______________________________________

From report at bugs.python.org  Fri Aug 14 06:19:22 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 14 Aug 2009 04:19:22 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

inspect.getsource(obj) returns incorrect results when obj is a 
traceback or frame object outside any function (that is, at the module 
level).

This demo script shows the problem. The correct output should contain 
all source lines in the module, but it only returns the first two:


D:\temp>type show_inspect_bug.py
def foo(x):
  return y + z

import inspect
frame = inspect.currentframe()
print inspect.getsource(frame)


D:\temp>python show_inspect_bug.py
def foo(x):
  return y + z


The attached patch fixes the problem and adds some missing test cases.
Originally reported by Juanjo Conti at the local Python group.

----------
components: Library (Lib)
files: inspect.diff
keywords: patch
messages: 91541
nosy: gagenellina
severity: normal
status: open
title: inspect.getsource() returns incorrect source lines
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14716/inspect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 14 06:29:21 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 14 Aug 2009 04:29:21 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1250224160.99.0.408458236127.issue6700@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


Added file: http://bugs.python.org/file14717/show_inspect_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 14 09:46:24 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 14 Aug 2009 07:46:24 +0000
Subject: [issue4015] [patch] make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1250235984.94.0.586909501942.issue4015@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4015>
_______________________________________

From report at bugs.python.org  Fri Aug 14 09:52:17 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 14 Aug 2009 07:52:17 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250236337.02.0.569589614639.issue2576@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:02:52 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 14 Aug 2009 08:02:52 +0000
Subject: [issue6682] Default traceback does not handle PEP302 loaded modules
In-Reply-To: <1250000791.92.0.10910978351.issue6682@psf.upfronthosting.co.za>
Message-ID: <1250236972.17.0.0679538975985.issue6682@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6682>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:21:04 2009
From: report at bugs.python.org (David Fraser)
Date: Fri, 14 Aug 2009 08:21:04 +0000
Subject: [issue6689] subprocess doesn't pass arguments correctly on Linux when
	shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250238064.13.0.726820676582.issue6689@psf.upfronthosting.co.za>


David Fraser <davidf at sjsoft.com> added the comment:

Ah, upon closer inspection - the special parameters $0 $1 $2 etc
mentioned in the sh docs refer to parameters within the command string,
so that:
   sh -c 'echo $2 $0 $1' run for "the people"
produces:
   the people run for

So the correct patch would be to leave out the extra parameters and just
have the quoted string...

The question then becomes, is simple " ".join(args) sufficient or should
there be some quoting of them... attaching a patch in the meantime
although that needs to be resolved.

----------
Added file: http://bugs.python.org/file14718/subprocess-shell-args-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:21:21 2009
From: report at bugs.python.org (David Fraser)
Date: Fri, 14 Aug 2009 08:21:21 +0000
Subject: [issue6689] subprocess doesn't pass arguments correctly on Linux when
	shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250238081.14.0.0619656429958.issue6689@psf.upfronthosting.co.za>


Changes by David Fraser <davidf at sjsoft.com>:


Removed file: http://bugs.python.org/file14697/current-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:21:31 2009
From: report at bugs.python.org (David Fraser)
Date: Fri, 14 Aug 2009 08:21:31 +0000
Subject: [issue6689] subprocess doesn't pass arguments correctly on Linux when
	shell=True
In-Reply-To: <1250066038.48.0.373766477997.issue6689@psf.upfronthosting.co.za>
Message-ID: <1250238091.62.0.928717720559.issue6689@psf.upfronthosting.co.za>


Changes by David Fraser <davidf at sjsoft.com>:


Removed file: http://bugs.python.org/file14698/current-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6689>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:30:21 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 14 Aug 2009 08:30:21 +0000
Subject: [issue6556] "HOME" is not a standard environment variable on Windows
In-Reply-To: <1248379761.36.0.601035706586.issue6556@psf.upfronthosting.co.za>
Message-ID: <1250238621.63.0.931714634732.issue6556@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

%HOME% isn't set by Windows.
%HOMEDRIVE%%HOMEPATH% points to the user's home directory.
%USERPROFILE% is where the user's profile is stored, and may or may not 
be the same as his home directory.

%HOMEDRIVE%%HOMEPATH% should be used then, defaulting to %USERPROFILE% 
only when those variables are not set (that's unlikely, but could 
happen e.g. with the runas command)

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6556>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:43:37 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 14 Aug 2009 08:43:37 +0000
Subject: [issue6666] List of dirs to ignore in trace.py is applied only for
	the first file
In-Reply-To: <1249638615.65.0.163009414102.issue6666@psf.upfronthosting.co.za>
Message-ID: <1250239417.26.0.519177657262.issue6666@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

That's exactly the change 2to3 would suggest for that line. The guy 
doing the conversion must have missed it.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6666>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:43:47 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 14 Aug 2009 08:43:47 +0000
Subject: [issue6693] New functions in site.py to get user/global site packages
	paths
In-Reply-To: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>
Message-ID: <1250239427.04.0.150097904844.issue6693@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Done.

I've put Christian in the loop since he implemented the PEP 370
feature, to make sure these changes are fine with him.

----------
nosy: +christian.heimes
Added file: http://bugs.python.org/file14719/site.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6693>
_______________________________________

From report at bugs.python.org  Fri Aug 14 10:43:55 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 14 Aug 2009 08:43:55 +0000
Subject: [issue6693] New functions in site.py to get user/global site packages
	paths
In-Reply-To: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>
Message-ID: <1250239435.17.0.785314520438.issue6693@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file14707/site.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6693>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:03:48 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 14 Aug 2009 09:03:48 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>


New submission from Bogdan Opanchuk <bg at bk.ru>:

I am sorry if the same issue was already considered and rejected for
some reason; quick search did not show any traces of it.

What I am going to write here is just a proof of concept, but if the
idea of the patch is acceptable, I am eager to prepare proper patches
for lib, documentation and so on.

So, my aim was to make xmlrpc module frendlier to those who want to
extend its functionality locally in their own projects. Currently there
are several problems with it:
1. Marshaller, unmarshaller and parser cannot be substituted by custom
versions easily.
2. Custom version of marshaller will look ugly (i.e., because it may
need to call Marshaller.__dump)
3. Transport, parser and unmarshaller are coupled now, though they are
completely independent.

My patch seem to eliminate these problems (see attach). Briefly, it
contains the following changes:
1. Transport, parser and unmarshaller are decoupled
2. Custom masrshaller, parser and unmarshaller classes can be passed to
client and server classes as parameters
3. Made Marshaller class easier to extend:
- __dump() renamed to _dump()
- added _add_memo() and _del_memo() (and hid .memo field)
- memo is now a set() (instead of dictionary with None values)
- dispatch table was made private

Results:
(good) This patch does not invalidate any part of documentation (but it
needs to be extended, according to new marshaller/unmarshaller/parser
parameters)
(good) test_xmlrpc still passes (with one little change to it, patch is
attached)
(good) Extension is easy now - see xmlrpc_overload.py as an example
(added bytes(), tuple() and dict() with non-string keys support)
(bad) Programs which use exported, but undocumented parts of xmlrpc can
break (though most of them can be easily fixed)

----------
components: Library (Lib)
messages: 91546
nosy: bogdan.opanchuk
severity: normal
status: open
title: Make custom xmlrpc extension easier
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:04:28 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 14 Aug 2009 09:04:28 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1250240668.92.0.849088541968.issue6701@psf.upfronthosting.co.za>


Changes by Bogdan Opanchuk <bg at bk.ru>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:04:54 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 14 Aug 2009 09:04:54 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1250240694.71.0.174068101767.issue6701@psf.upfronthosting.co.za>


Changes by Bogdan Opanchuk <bg at bk.ru>:


Added file: http://bugs.python.org/file14721/client.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:05:11 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 14 Aug 2009 09:05:11 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1250240711.13.0.318729957556.issue6701@psf.upfronthosting.co.za>


Changes by Bogdan Opanchuk <bg at bk.ru>:


Added file: http://bugs.python.org/file14722/server.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:05:31 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 14 Aug 2009 09:05:31 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1250240731.29.0.413892835724.issue6701@psf.upfronthosting.co.za>


Changes by Bogdan Opanchuk <bg at bk.ru>:


Added file: http://bugs.python.org/file14723/test_xmlrpc.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Fri Aug 14 11:06:06 2009
From: report at bugs.python.org (Bogdan Opanchuk)
Date: Fri, 14 Aug 2009 09:06:06 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1250240766.89.0.269902665343.issue6701@psf.upfronthosting.co.za>


Changes by Bogdan Opanchuk <bg at bk.ru>:


Added file: http://bugs.python.org/file14724/xmlrpc_overload.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Fri Aug 14 14:28:17 2009
From: report at bugs.python.org (paolo)
Date: Fri, 14 Aug 2009 12:28:17 +0000
Subject: [issue6702] Tkinter: modify xview of entry widget
In-Reply-To: <1250252897.03.0.863989377891.issue6702@psf.upfronthosting.co.za>
Message-ID: <1250252897.03.0.863989377891.issue6702@psf.upfronthosting.co.za>


New submission from paolo <paolo.fragu at libero.it>:

I wish to propose a useful and smart method modify in Tkinter Library:

Previously to scroll this widget we had to write an external function
(recalling xview_moveto and xview_scroll).

With my method this operation is cleared and the same as all other
widgets (just have to call xview).

----------------------------------------------------------
Modify Proposal:
----------------------------------------------------------
Change the method xview of entry so it works as all widget scrollable,
and it's compatible with 'old' xview.

So to scroll entry widget:

entry_widget['xscrollcommand']=scroll_widget.set
scroll_widget['command']=entry_widget.xview

The change in module Tkinter is:

def xview(self,*args):
    """Query and change horizontal position of the view."""
    #modify
    if not args:
        return self._getdoubles(self.tk.call(self._w, 'xview'))
    #old code
    index=args[0]
    self.tk.call(self._w, 'xview', index)
----------------------------------------------------------
+
It's call the tk interpreter passing entry and xview without arguments;
returns a list containing two elements to pass to scrollbars via the
xscrollcommand option

If an argument (index) is passing, then display the character given by
index at the left edge of the window; it work as the original xview

With 'old' methon is impossible call xview without arguments, the change
has made possible this.

-----------------------------------------------------------------
To scroll entry without modify:
-------------------------------
import Tkinter as tk
root=tk.Tk()

def scollEntry(*args):
   if args[0]=='scroll':
        e.xview_scroll(args[1],args[2])
   if args[0]=='moveto':
        e.xview_moveto(args[1])

e=tk.Entry(width=10)
e.grid(row=0, sticky='e'+'w')

s=tk.Scrollbar(orient='horizontal')
s.grid(row=1, sticky='e'+'w')

e['xscrollcommand']=s.set
s['command']=scollEntry

root.mainloop()

--------------------------------------------------------------------
With modify:
------------
import Tkinter as tk
root=tk.Tk()

e=tk.Entry(width=10)
e.grid(row=0, sticky='e'+'w')

s=tk.Scrollbar(orient='horizontal')
s.grid(row=1, sticky='e'+'w')

e['xscrollcommand']=s.set
s['command']=e.xview

root.mainloop()

-----------------------------------------------------------------
It's work also with tk-8.5 and ttk
----------------------------------
import Tkinter as tk
import ttk
root=tk.Tk()

e=ttk.Entry(width=10)
e.grid(row=0, sticky='e'+'w')

s=ttk.Scrollbar(orient='horizontal')
s.grid(row=1, sticky='e'+'w')

e['xscrollcommand']=s.set
s['command']=e.xview

root.mainloop()
---------------------------------------------------------

I tested with Python 2.5 and tk 8.4 and also tk 8.5 and module ttk

----------
components: Tkinter
messages: 91547
nosy: paolo
severity: normal
status: open
title: Tkinter: modify xview of entry widget
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6702>
_______________________________________

From report at bugs.python.org  Fri Aug 14 14:42:20 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 14 Aug 2009 12:42:20 +0000
Subject: [issue6702] Tkinter: modify xview of entry widget
In-Reply-To: <1250252897.03.0.863989377891.issue6702@psf.upfronthosting.co.za>
Message-ID: <1250253740.42.0.401121792285.issue6702@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Please take a look on issue6180. Closing this as duplicate.

Also consider checking the issue 1135, your comments are welcome on both
issues and may help getting the fix committed.

----------
nosy: +gpolo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6702>
_______________________________________

From report at bugs.python.org  Fri Aug 14 15:34:09 2009
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 14 Aug 2009 13:34:09 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1250256849.67.0.0652624534415.issue6701@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy: +draghuram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Fri Aug 14 15:54:23 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 14 Aug 2009 13:54:23 +0000
Subject: [issue3344] IDLE - use enumerate instead of zip(count(), ...)
In-Reply-To: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za>
Message-ID: <1250258063.21.0.0836383267041.issue3344@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Committed on r74446, will merge into py3k.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3344>
_______________________________________

From report at bugs.python.org  Fri Aug 14 16:03:47 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 14 Aug 2009 14:03:47 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1222041136.39.0.521824941747.issue3926@psf.upfronthosting.co.za>
Message-ID: <1250258627.06.0.769716476221.issue3926@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Committed on r74447, will merge into py3k.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Fri Aug 14 16:37:24 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 14 Aug 2009 14:37:24 +0000
Subject: [issue1135] xview/yview of Tix.Grid is broken
In-Reply-To: <1189314445.29.0.484479560219.issue1135@psf.upfronthosting.co.za>
Message-ID: <1250260644.52.0.799851578351.issue1135@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This has been commited on r74448 now, will merge into py3k.

----------
resolution:  -> accepted
status: open -> closed
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1135>
_______________________________________

From report at bugs.python.org  Fri Aug 14 16:44:23 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 14 Aug 2009 14:44:23 +0000
Subject: [issue6180] Tkinter.Entry: fix for xview and some doc clarifications
In-Reply-To: <1243977667.14.0.414043606697.issue6180@psf.upfronthosting.co.za>
Message-ID: <1250261063.33.0.58322002237.issue6180@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This is now obsolete since r74448 and r74449, closing.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6180>
_______________________________________

From report at bugs.python.org  Fri Aug 14 17:07:36 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 14 Aug 2009 15:07:36 +0000
Subject: [issue1135] xview/yview of Tix.Grid is broken
In-Reply-To: <1250260644.52.0.799851578351.issue1135@psf.upfronthosting.co.za>
Message-ID: <ac2200130908140807r3bfb9d5br70bbed985df8f0d3@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> This has been commited on r74448 now, will merge into py3k.

py3k: r74450

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1135>
_______________________________________

From report at bugs.python.org  Fri Aug 14 17:08:04 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 14 Aug 2009 15:08:04 +0000
Subject: [issue3926] Idle doesn't obey the new improved warnings arguements
In-Reply-To: <1250258627.06.0.769716476221.issue3926@psf.upfronthosting.co.za>
Message-ID: <ac2200130908140807g7540513fy9e760a5bd8188c84@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Committed on r74447, will merge into py3k.

py3k: r74450

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3926>
_______________________________________

From report at bugs.python.org  Fri Aug 14 17:08:23 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 14 Aug 2009 15:08:23 +0000
Subject: [issue3344] IDLE - use enumerate instead of zip(count(), ...)
In-Reply-To: <1250258063.21.0.0836383267041.issue3344@psf.upfronthosting.co.za>
Message-ID: <ac2200130908140808p27cec165od109d64973953099@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> Committed on r74446, will merge into py3k.

py3k: r74450

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3344>
_______________________________________

From report at bugs.python.org  Fri Aug 14 18:12:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 Aug 2009 16:12:20 +0000
Subject: [issue6687] Move the special-case for integer objects out of
	PyBytes_FromObject.
In-Reply-To: <1250025332.91.0.596662376204.issue6687@psf.upfronthosting.co.za>
Message-ID: <1250266340.49.0.283287503534.issue6687@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+1 from me too;  I agree the current API of PyBytes_FromObject is ugly.  

Is there still a need for a separate C function for creating a zero-
initialized bytes object from a Py_ssize_t or a Python integer?  It's a 
fairly simple operation (PyBytes_FromStringAndSize + memset), so perhaps 
it doesn't need its own public function.

I'm not sure about the extra PyUnicode_Check:  this seems to go against 
Python's philosophy of duck-typing.  After all, the empty string *is* an 
iterable all of whose elements are integers.  And this check doesn't cover 
other, similar, cases:  for example, list('') will still be converted by 
PyBytes_FromObject, while list('123') won't.  What's the benefit?

If this check is going to stay, there should probably also be a unit test 
for this behaviour.

Apart from the reservation about the PyUnicode_Check, the patch looks good 
to me.  All tests pass on my machine (OS X 10.5) with this patch applied.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6687>
_______________________________________

From report at bugs.python.org  Fri Aug 14 18:18:17 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 14 Aug 2009 16:18:17 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

Hi All,

Line 355 of this code on the 2.6 branch and trunk:

http://svn.python.org/view/python/branches/release26-
maint/Lib/doctest.py?view=annotate
http://svn.python.org/view/python/trunk/Lib/doctest.py?annotate=69012

...contain a check that doesn't work cross platform.

I'd argue that the check is worthless and should be removed.
I'm happy to do this, but is this code tested?
If not, do I need to add a test when I remove those two lines?

cheers,

Chris

----------
assignee: cjw296
messages: 91557
nosy: cjw296
severity: normal
status: open
title: cross platform failure and silly test in doctest
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6703>
_______________________________________

From report at bugs.python.org  Fri Aug 14 18:23:27 2009
From: report at bugs.python.org (Matthias Troffaes)
Date: Fri, 14 Aug 2009 16:23:27 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250267007.29.0.342938102881.issue6695@psf.upfronthosting.co.za>


Matthias Troffaes <matthias.troffaes at gmail.com> added the comment:

Thanks for the feedback!

Attaching a new patch which implements tp_free_list slot as suggested -
I hope I did it correctly. I've only implemented the new slot for dict
so far, but I'm happy to tp_free_list-ify the other freelist types as
well, in a future patch, if this gets the green light.

Description of the patch:

* added tp_free_list slot to PyTypeObject (definitely for review: is the
location of tp_free_list right after tp_free sensible?)
* added PyType_ClearFreeList(PyTypeObject *) to C API, which calls the
tp_free_list function if not NULL
* inserted the new slot where necessary (e.g. in PyGen_Type) to sync
type definitions with the updated PyTypeObject
* created dict_free_list function and added it to PyDict_Type
* call PyType_ClearFreeList(&PyDict_Type) from gc.collect()

----------
Added file: http://bugs.python.org/file14725/py3k-tp_free_list-dict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri Aug 14 18:27:35 2009
From: report at bugs.python.org (jan matejek)
Date: Fri, 14 Aug 2009 16:27:35 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1250267255.18.0.584734077455.issue1294959@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

for completenes, here's a patch that's in use in SUSE. it's advantage
over Fedora's is that it works on both 32bit and 64bit installs

----------
Added file: http://bugs.python.org/file14726/Python-2.6.2-multilib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Fri Aug 14 18:41:59 2009
From: report at bugs.python.org (Giorgio)
Date: Fri, 14 Aug 2009 16:41:59 +0000
Subject: [issue1424148] urllib.FancyURLopener.redirect_internal looses data on
	POST!
Message-ID: <1250268119.12.0.606118382351.issue1424148@psf.upfronthosting.co.za>


Giorgio <giorgio at gilestro.tk> added the comment:

I am not sure where we stand with this issue. It seems to be an old one.
urllib2 still claim (as of python 2.6) the following;

# Strictly (according to RFC 2616), 301 or 302 in response
# to a POST MUST NOT cause a redirection without confirmation
# from the user (of urllib2, in this case).  In practice,
# essentially all clients do redirect in this case, so we
# do the same.
# be conciliant with URIs containing a space

This is just not true, we don't do the same at all. redirect_request
does not pass data along and it even changes the headers to reflect
content-size, thus behaving perfectly in accordance with RFC.

For those who stumbled upon this page looking for a workaround, this is
how to do: create a new class inheriting from HTTPRedirectHandler and
use this one instead:


class AutomaticHTTPRedirectHandler(urllib2.HTTPRedirectHandler):

    def redirect_request(self, req, fp, code, msg, headers, newurl):
        """Return a Request or None in response to a redirect.
        
        The default response in redirect_request claims not to 
        follow directives in RFC 2616 but in fact it does
        This class does not and makes handling 302 with POST
        possible
        """
        m = req.get_method()
        if (code in (301, 302, 303, 307) and m in ("GET", "HEAD")
            or code in (301, 302, 303) and m == "POST"):
            newurl = newurl.replace(' ', '%20')
            return urllib2.Request(newurl,
                           data=req.get_data(),
                           headers=req.headers,
                           origin_req_host=req.get_origin_req_host(),
                           unverifiable=True)
        else:
            raise urllib2.HTTPError(req.get_full_url(), code, msg,
headers, fp)

----------
nosy: +crocowhile
versions: +Python 2.5 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424148>
_______________________________________

From report at bugs.python.org  Fri Aug 14 19:04:06 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Aug 2009 17:04:06 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250269446.2.0.687357702536.issue6695@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Guido, do you want a slot assigned for this?

----------
assignee:  -> gvanrossum
nosy: +gvanrossum, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri Aug 14 19:14:32 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 14 Aug 2009 17:14:32 +0000
Subject: [issue6646] test_pickle fails on AIX -- 6.9999999999999994e-308 !=
	6.9999999999999984e-308
In-Reply-To: <1249436565.63.0.933597089559.issue6646@psf.upfronthosting.co.za>
Message-ID: <1250270072.56.0.327892433942.issue6646@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this as a won't fix:  as far as I can tell, the test failure is 
due to a platform deficiency (string <-> float conversions provided by the 
C standard library aren't correctly rounded; moreover, they're not 
accurate enough that converting a C double to 17 significant digits and 
back recovers the original double).  It's not clear what Python can 
reasonably do to fix this.  I'd prefer not to disable or weaken these 
tests, since they're useful on other platforms.

srid, if you do have any alternative suggestions about how this might be 
fixed then please do submit them.

For what it's worth, this particular failure should no longer be a problem 
in Python 3.1 and higher, since 3.1 uses its own string <-> float 
conversion code (based on David Gay's dtoa.c).

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6646>
_______________________________________

From report at bugs.python.org  Fri Aug 14 19:19:34 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Aug 2009 17:19:34 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250270374.34.0.177639062735.issue6695@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

A slot in every type object for this purpose seems wasteful; the large
majority of types won't have a free list.  (Remember, each user-defined
class allocates a full type structure on the heap.)

----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri Aug 14 19:46:15 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 14 Aug 2009 17:46:15 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1250271975.26.0.119345145131.issue4970@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

[...]
test_poll
test_popen
test_poplib
stub-asunix.sh: line 238: 25474 Unknown signal 32       $PYTHON 
$installdir/lib/python?.?/test/regrtest.py -w -u all,-curses,-audio,-
network -x $SKIPS
stub: core Python test suite FAILED (retval: 160)

----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:19:59 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Aug 2009 18:19:59 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250273999.46.0.486963246203.issue6695@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Marking the PyXXX_ClearFreeList version as approved.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Fri Aug 14 20:55:47 2009
From: report at bugs.python.org (Frank Wierzbicki)
Date: Fri, 14 Aug 2009 18:55:47 +0000
Subject: [issue6704] better col_offset for AST in statements like "for a,
	b in ..."
In-Reply-To: <1250276147.3.0.975792717277.issue6704@psf.upfronthosting.co.za>
Message-ID: <1250276147.3.0.975792717277.issue6704@psf.upfronthosting.co.za>


New submission from Frank Wierzbicki <fwierzbicki at gmail.com>:

For statements like:

for a,b in c:
   pass

The Tuple node "a,b" ends up with a col_offset of 0 (the position of the
"for"), but the col_offset should probably be 4 (the position of "a").
This is more consistent with other Tuple node col_offset results.

----------
components: Interpreter Core
files: ast.diff
keywords: patch
messages: 91566
nosy: fwierzbicki
severity: normal
status: open
title: better col_offset for AST in statements like "for a,b in ..."
versions: Python 2.7
Added file: http://bugs.python.org/file14727/ast.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6704>
_______________________________________

From report at bugs.python.org  Fri Aug 14 21:08:31 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Aug 2009 19:08:31 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1250276911.01.0.830081348118.issue6703@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

How about removing it and seeing if tests fail?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6703>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:00:42 2009
From: report at bugs.python.org (Frank Wierzbicki)
Date: Fri, 14 Aug 2009 20:00:42 +0000
Subject: [issue6704] better col_offset for AST in statements like "for a,
	b in ..."
In-Reply-To: <1250276147.3.0.975792717277.issue6704@psf.upfronthosting.co.za>
Message-ID: <1250280042.5.0.297191722883.issue6704@psf.upfronthosting.co.za>


Frank Wierzbicki <fwierzbicki at gmail.com> added the comment:

Adding tests to test_ast.py for the three cases that exercise the "for
a,b" scenario.  Also fixed a small bug in the test code generator in
test_ast.py

----------
Added file: http://bugs.python.org/file14728/ast.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6704>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:20:50 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 14 Aug 2009 20:20:50 +0000
Subject: [issue6556] "HOME" is not a standard environment variable on Windows
In-Reply-To: <1248379761.36.0.601035706586.issue6556@psf.upfronthosting.co.za>
Message-ID: <1250281250.86.0.882697432574.issue6556@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The code works as expected because it uses os.path.expanduser('~'),
which will look to the right values depending on the platform.

So it's just the documentation that is wrong about how distutils behaves
under Windows.

I'll fix this doc asap, thanks for the feedback.

----------
components: +Documentation -Distutils
resolution:  -> accepted
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6556>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:21:31 2009
From: report at bugs.python.org (John J Lee)
Date: Fri, 14 Aug 2009 20:21:31 +0000
Subject: [issue1424148] urllib.FancyURLopener.redirect_internal looses data on
	POST!
Message-ID: <1250281291.9.0.882283683623.issue1424148@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

This issue is not a bug, and should be closed.  It was discussed at 
length many years ago (different bug tracker ticket), and resolved.  
Since then the same issue seems to come up every year or so, 
apparently raised by people who haven't checked the issue tracker for 
previous discussion.  Please, somebody close this issue!


> It seems to be an old one.
> urllib2 still claim (as of python 2.6) the following;
> 
> # Strictly (according to RFC 2616), 301 or 302 in response
> # to a POST MUST NOT cause a redirection without confirmation
> # from the user (of urllib2, in this case).  In practice,
> # essentially all clients do redirect in this case, so we
> # do the same.

Note that this is NOT a statement about whether the request sent as a 
result of the redirect response contains the original POST data.


> This is just not true, we don't do the same at all. redirect_request
> does not pass data along and it even changes the headers to reflect
> content-size, thus behaving perfectly in accordance with RFC.

This appears to be a statement about (amongst other things) whether 
the request sent as a result of the redirect response contains the 
original POST data.

So where's the connection between the comment you quote and your 
response to it, Giorgio?  Actually, I hope you don't mind if I ask you 
not to answer that question, but instead to go and read, very 
carefully, the tracker discussion for the original fix that introduced 
the comment you posted (you should be able to find it by svn 
annotating the source, finding the appropriate commit, then looking 
for a reference in the commit message to a bug tracker issue ID).  
Once you've done that, please stop posting on this issue <0.2 wink>

Sorry, I'm not normally this grumpy, but this issue just seems to keep 
coming back forever, because people haven't spent the time to test 
browser behaviour, carefully read the RFC, tracker discussion, commit 
messages, etc.  If you have done all that and thought carefully and 
still think there's a bug, by all means come back, but please make 
sure you're extremely clear about *exactly* what you think is wrong, 
and why.  Write a test case, and cite specific RFC wording.  If what 
you think is wrong is not the same as the original issue described in 
the opening comment of this bug tracker ticket, please raise a new 
ticket rather than commenting on this one.


> For those who stumbled upon this page looking for a workaround, this 
is
> how to do: create a new class inheriting from HTTPRedirectHandler 
and
> use this one instead:

I don't know what this is a workaround *for*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424148>
_______________________________________

From report at bugs.python.org  Fri Aug 14 22:47:56 2009
From: report at bugs.python.org (Giorgio)
Date: Fri, 14 Aug 2009 20:47:56 +0000
Subject: [issue1424148] urllib.FancyURLopener.redirect_internal looses data on
	POST!
Message-ID: <1250282876.3.0.553932063069.issue1424148@psf.upfronthosting.co.za>


Giorgio <giorgio at gilestro.tk> added the comment:

>I don't know what this is a workaround *for*.

As you can see yourself, that code does a complete redirection, taking
along the post_data too which is simply not possible by default (and
that is obviously a pain in the neck).

I never said it was "bug" nor that the code had to be changed. I am just
saying this is "a lack of a feature" that obviously many would like to
see implemented - and this is probably why it "seems to come back forever".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424148>
_______________________________________

From report at bugs.python.org  Fri Aug 14 23:36:38 2009
From: report at bugs.python.org (Michael Gruen)
Date: Fri, 14 Aug 2009 21:36:38 +0000
Subject: [issue6705] '''3, 5'''.strip(r''', ''') does not strip comma,
	returns '3, 5'
In-Reply-To: <1250285798.29.0.625956146612.issue6705@psf.upfronthosting.co.za>
Message-ID: <1250285798.29.0.625956146612.issue6705@psf.upfronthosting.co.za>


New submission from Michael Gruen <gruenm at gmail.com>:

I am new, I apologize if this is a trivial or non-problem.  I have
researched for hours, tried every variant but cannot understand why this
doesn't work.

----------
components: None
messages: 91572
nosy: mgruen
severity: normal
status: open
title: '''3,5'''.strip(r''',''') does not strip comma, returns '3,5'
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6705>
_______________________________________

From report at bugs.python.org  Fri Aug 14 23:43:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Aug 2009 21:43:05 +0000
Subject: [issue6705] '''3, 5'''.strip(r''', ''') does not strip comma,
	returns '3, 5'
In-Reply-To: <1250285798.29.0.625956146612.issue6705@psf.upfronthosting.co.za>
Message-ID: <1250286185.28.0.173656730332.issue6705@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

strip removes any of a set of characters from the beginning and end of a
string, not the middle.

Please refer questions such as this to python-list or python-tutor. 
There are many helpful people on those lists who will help you learn
your way around python.

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6705>
_______________________________________

From report at bugs.python.org  Fri Aug 14 23:57:41 2009
From: report at bugs.python.org (Eric Smith)
Date: Fri, 14 Aug 2009 21:57:41 +0000
Subject: [issue6705] '''3, 5'''.strip(r''', ''') does not strip comma,
	returns '3, 5'
In-Reply-To: <1250285798.29.0.625956146612.issue6705@psf.upfronthosting.co.za>
Message-ID: <1250287061.98.0.256004638647.issue6705@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Good advice from R. David. In addition, you'll find the help command useful:

>>> help(''.strip)
Help on built-in function strip:

strip(...)
    S.strip([chars]) -> string or unicode
    
    Return a copy of the string S with leading and trailing
    whitespace removed.
    If chars is given and not None, remove characters in chars instead.
    If chars is unicode, S will be converted to unicode before stripping

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6705>
_______________________________________

From report at bugs.python.org  Sat Aug 15 00:12:06 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Aug 2009 22:12:06 +0000
Subject: [issue6681] email.parser clips trailing \n of multipart/mixed part if
	part ends in \r\n
In-Reply-To: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>
Message-ID: <1250287926.31.0.903531913413.issue6681@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The only way I can think of to fix this that won't fail in the case
where the body ends with just '\r' (rather than '\r\n' the way the test
body does) is to have feedparser keep track of what the overall line
endings for the stream being parsed are.  ie: to basicly outlaw
mixed-line-ending input (except insofar as such alternate line endings
are encoded in a non-text multipart).  That seems like something that
should only be considered in the context of email 6.0 rather than in a
bug fix.

cgi doesn't use a RE, by the way, it just looks at the last two
chars...and is subject to the same bug if a part ends with '\r' in input
with '\n' line terminators.

I've attached a patch that turns Guido's test into a test case, and
fixes his edge case.  I did not touch the other places where the eol RE
is used, since in those cases there should not be binary data preceeding
the line ending characters.

----------
keywords: +patch
priority:  -> normal
stage:  -> patch review
Added file: http://bugs.python.org/file14729/issue6681.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6681>
_______________________________________

From report at bugs.python.org  Sat Aug 15 00:39:33 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Aug 2009 22:39:33 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters are
	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250289573.42.0.683709136047.issue6697@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The error occurs in Py_Main(), on _PyUnicode_AsString(commandObj). The
problem is that _PyUnicode_AsString() is not checked for error. Here is
a patch fixing two errors:
 - display on error message instead of a crash on
_PyUnicode_AsString(commandObj) failure
 - don't call Py_DECREF(commandObj) if commandObj is NULL
(PyUnicode_FromWideChar error, a different error)

My patch also includes a test. The test should be moved somewhere else,
but I don't know where.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file14730/pymain.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Sat Aug 15 00:51:57 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Aug 2009 22:51:57 +0000
Subject: [issue6669] TarFile.getmembers fails at struct.unpack: unpack
	requires a string argument of length 4
In-Reply-To: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>
Message-ID: <1250290317.7.0.402249327216.issue6669@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

First, gzip should use its own errors: this issue depends on #6584.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6669>
_______________________________________

From report at bugs.python.org  Sat Aug 15 00:59:41 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Aug 2009 22:59:41 +0000
Subject: [issue6669] TarFile.getmembers fails at struct.unpack: unpack
	requires a string argument of length 4
In-Reply-To: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>
Message-ID: <1250290781.49.0.0558694137383.issue6669@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since 6584 is deemed (correctly, IMO) a feature request, this one must
be as well.

----------
dependencies: +gzip module has no custom exception
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
type: behavior -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6669>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:03:37 2009
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 14 Aug 2009 23:03:37 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <billiejoex at users.sourceforge.net>:

An old bad design choice in asyncore is how it forces the user to 
override handle_accept() and then call self.accept() to obtain a socket 
pair.

    def handle_accept(self):
        conn, addr = self.accept()

The documentation itself shows the code above as an example of how an 
asyncore-based server should handle an incoming connection.
What the doc doesn't say is that the user calling self.accept() is 
exposed to different risks:

- self.accept() can return None instead of a socket pair in which case 
TypeError is raised (see pyftpdlib bug: 
http://code.google.com/p/pyftpdlib/issues/detail?id=91)

- ECONNABORTED can be raised. This is reproducible on Linux by hammering 
the server with nmap (see pyftpdlib bug: 
http://code.google.com/p/pyftpdlib/issues/detail?id=105)

- EAGAIN can be raised too. I never experienced this error condition 
myself in pyftpdlib but by looking at twisted/internet/tcp.py it seems 
reasonable to catch EAGAIN too.

- The resulting address can be None, which means that the connection 
didn't take place.
This is reproducible by hammering the server with nmap (see pyftpdlib 
bug http://code.google.com/p/pyftpdlib/issues/detail?id=104).


The right thing to do when one of such events occur is to "return" as no 
connection has really been established between client and server.

Now, altough handling these kind of conditions is quite easy, the API 
design remains fundamentally wrong, as it forces the user to call 
accept().
As asyncore.py is structured right now the only chance the user has to 
properly accepting a connection is manually handling all these cases in 
his subclass.


My patch in attachment tries to solve this problem by defining a new 
"handle_accept_event()" method which takes care of all the error 
conditions described above resulting in handle_accept() be called *only 
when a connection really took place*.
When the connection is established handle_accept_event() stores the 
socket pair as an attribute and the next call to accept() returns that 
pair.
This preserves the current implementation without breaking any code as 
the user will have to override handle_accept() and then call accept() in 
the same manner [1], with the difference that self.accept() will always 
return a valid socket pair.

[1] 
    def handle_accept(self):
        conn, addr = self.accept()

----------
components: Library (Lib)
messages: 91579
nosy: giampaolo.rodola, josiahcarlson
severity: normal
status: open
title: asyncore's accept() is broken
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:06:42 2009
From: report at bugs.python.org (Dino Viehland)
Date: Fri, 14 Aug 2009 23:06:42 +0000
Subject: [issue6707] dir() on __new__'d module w/o dict crashes 2.6.2
In-Reply-To: <1250291202.25.0.109335007546.issue6707@psf.upfronthosting.co.za>
Message-ID: <1250291202.25.0.109335007546.issue6707@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

from types import ModuleType as M
m = M.__new__(M)
dir(m)

In 2.5 this raises an exception about not having __dict__, 2.6.2 
crashes out right.

----------
components: Interpreter Core
messages: 91580
nosy: DinoV
severity: normal
status: open
title: dir() on __new__'d module w/o dict crashes 2.6.2
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6707>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:07:11 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Aug 2009 23:07:11 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1250291231.27.0.618493938959.issue6239@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I agree that the C type 'char' is a byte, not a character. So Python3
should creates a Python bytes object for the ctypes "c_char_p" type.
Since Python 3.1 is out, is it too late to change it in the 3.x branch?
:-) Maybe for Python 3.2?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Sat Aug 15 01:53:12 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Aug 2009 23:53:12 +0000
Subject: [issue6673] Py3.1 hangs in coroutine and eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1250293992.31.0.654784797797.issue6673@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reopening - this should be rejected by the compiler as a SyntaxError,
since it is the comprehension equivalent of writing "return Value"
inside a generator function.

Specifically, in 3.x, the equivalent written out code is:

    while True:
        def _listcomp():
            result = []
            for i in range(chunk_size):
                result.append((yield))
            return result # Would trigger SyntaxError!
        target.send(_listcomp())

As noted in the comment, the compiler would disallow that expansion with
a SyntaxError on the marked line, so the comprehension equivalent should
be rejected as well. This also applies to dict and set comprehensions.

Generator expressions are slightly less clear, since their expanded
equivalent would produce legal code:

>>> g = ((yield)*(yield) for i in range(1))
>>> next(g)
>>> g.send(2)
>>> g.send(3)
6
>>> next(g)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

That first line is roughly equivalent to:
        def _genexp():
            for i in range(1):
                yield (yield)*(yield)
        g = _genexp()

So the compiler should probably be keeping track of whether it is inside
a comprehension or not to decide whether or not to allow yield expressions.

----------
keywords: +64bit
nosy: +ncoghlan
resolution: invalid -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:21:06 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sat, 15 Aug 2009 02:21:06 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1250302866.09.0.390505602074.issue6626@psf.upfronthosting.co.za>


Jacob Rus <jacobolus at gmail.com> added the comment:

Okay, here's a version of this patch which (a) adds deprecation warnings, 
and (b) doesn't bother with lazy init. It should still be nearly 
completely backwards compatible with the previous mimetypes module.

----------
Added file: http://bugs.python.org/file14731/mimetypes5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:21:11 2009
From: report at bugs.python.org (starz)
Date: Sat, 15 Aug 2009 02:21:11 +0000
Subject: [issue6708] raw_input() calls generate compile errors.
In-Reply-To: <1250302870.91.0.18677691598.issue6708@psf.upfronthosting.co.za>
Message-ID: <1250302870.91.0.18677691598.issue6708@psf.upfronthosting.co.za>


New submission from starz <b_lynch1 at yahoo.com>:

# ------ SOURCE -------
# cheerleading program
word = raw_input("Who do you go for? ")

for letter in word:
    call = "Gimme a " + letter + "!"
    print (call)
    print (letter) + "!"

print( "What does that spell?")
print( word + "!")

# ------- end source -------

## within python.help()
## --------------------
help> raw_input()
no Python documentation found for 'raw_input()'

help>

### --- run from O/S ---

C:\Program Files\OpenOffice.org 2.0\program\python3.1>python 
PYsource\test3.py
Traceback (most recent call last):
  File "PYsource\test3.py", line 22, in <module>
    word = raw_input("Who do you go for? ")
NameError: name 'raw_input' is not defined

C:\Program Files\OpenOffice.org 2.0\program\python3.1>

----------
components: Library (Lib)
files: test3.py
messages: 91584
nosy: starz
severity: normal
status: open
title: raw_input() calls generate compile errors.
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14732/test3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6708>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:30:38 2009
From: report at bugs.python.org (Jacob Rus)
Date: Sat, 15 Aug 2009 02:30:38 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1250303438.98.0.596917088751.issue6626@psf.upfronthosting.co.za>


Jacob Rus <jacobolus at gmail.com> added the comment:

And at Rietveld, patch version 5:
http://codereview.appspot.com/107042

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:38:38 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Aug 2009 02:38:38 +0000
Subject: [issue6677] Place the term "delete" within the documentation for
	os.remove() and os.rmdir()
In-Reply-To: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>
Message-ID: <1250303918.12.0.305091167583.issue6677@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If a change is make, 'remove (delete)' would be sufficient.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6677>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:39:54 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Aug 2009 02:39:54 +0000
Subject: [issue6709] It's possible to create TryExcept with no handlers
In-Reply-To: <1250303994.53.0.2741455605.issue6709@psf.upfronthosting.co.za>
Message-ID: <1250303994.53.0.2741455605.issue6709@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

I think we might need to devise some way to add custom validation when
AST is being compiled. For example, you can also pass a level to
ImportFrom which is < -1.

>>> x = ast.parse("try: x\nexcept y: pass")
>>> del x.body[0].handlers[:]
>>> compile(x, "<string>", "exec")
<code object <module> at 0x7f0a92aed918, file "<string>", line 1>
>>> from dis import dis
>>> dis(x)
>>> dis(compile(x, "<string>", "exec"))
  1           0 SETUP_EXCEPT             8 (to 11)
              3 LOAD_NAME                0 (x)
              6 POP_TOP
              7 POP_BLOCK
              8 JUMP_FORWARD             1 (to 12)
        >>   11 END_FINALLY
        >>   12 LOAD_CONST               0 (None)
             15 RETURN_VALUE

----------
components: Extension Modules, Interpreter Core
messages: 91587
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: It's possible to create TryExcept with no handlers
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6709>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:40:04 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Aug 2009 02:40:04 +0000
Subject: [issue6709] It's possible to create TryExcept with no handlers
In-Reply-To: <1250303994.53.0.2741455605.issue6709@psf.upfronthosting.co.za>
Message-ID: <1250304004.25.0.071077074337.issue6709@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6709>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:52:26 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 15 Aug 2009 02:52:26 +0000
Subject: [issue6708] raw_input() calls generate compile errors.
In-Reply-To: <1250302870.91.0.18677691598.issue6708@psf.upfronthosting.co.za>
Message-ID: <1250304746.54.0.0920712845653.issue6708@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Try it at the help> prompt without the parens (you're not calling
it here, just asking for the documentation on the name "raw_input".

help> raw_input

Help on built-in function raw_input in module __builtin__:

raw_input(...)
    raw_input([prompt]) -> string
    
    Read a string from standard input.  The trailing newline is stripped.
    If the user hits EOF (Unix: Ctl-D, Windows: Ctl-Z+Return), raise
EOFError.
    On Unix, GNU readline is used if enabled.  The prompt string, if given,
    is printed without a trailing newline before reading.

----------
nosy: +skip.montanaro
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6708>
_______________________________________

From report at bugs.python.org  Sat Aug 15 04:53:30 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Aug 2009 02:53:30 +0000
Subject: [issue6708] raw_input() calls generate compile errors.
In-Reply-To: <1250302870.91.0.18677691598.issue6708@psf.upfronthosting.co.za>
Message-ID: <1250304810.05.0.400025718736.issue6708@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

raw_input() has been renamed to input() in Python 3.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6708>
_______________________________________

From report at bugs.python.org  Sat Aug 15 07:32:15 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2009 05:32:15 +0000
Subject: [issue1660179] functools.compose to chain functions together
Message-ID: <1250314335.6.0.183769098338.issue1660179@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur with Martin's reasons for closing the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1660179>
_______________________________________

From report at bugs.python.org  Sat Aug 15 07:32:22 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2009 05:32:22 +0000
Subject: [issue1660179] functools.compose to chain functions together
Message-ID: <1250314342.27.0.0712463163975.issue1660179@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur with Martin's reasons for closing the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1660179>
_______________________________________

From report at bugs.python.org  Sat Aug 15 07:37:50 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2009 05:37:50 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250314670.05.0.455625207697.issue6695@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Does anyone here know why GC calls the free_xxx functions?  ISTM, they
cannot be involved in cycles.  Free lists are kept by container objects
to speed-up allocation.  Having GC call the free_xxx just slows down the
GC process and all the subsequent set/list/tuple allocations until the
free lists are built-up again.  IMO, the free_xxx functions should only
be called during atexit or by an explicit call from the user perhaps,
sys.clear_freelists() or somesuch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sat Aug 15 07:52:07 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 15 Aug 2009 05:52:07 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250315527.27.0.136955600351.issue2576@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Note that http://bugs.python.org/issue4879 may have already fixed this
problem in trunk r68532.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Sat Aug 15 08:27:46 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 15 Aug 2009 06:27:46 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250317666.65.0.92920584405.issue2576@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Okay, I do not think this has been fixed yet.  Anyone calling
getresponse() can indeed use buffering=True, it can mess things up if
the do not close the connection afterwards.

The addition of the sockbuf parameter to HTTPConnection as proposed in
buffered_socket.diff will work, but I'd follow the earlier work's lead.
 Don't expose it as the "sockbuf" integer.  Just use a boolean
"buffering" parameter that defaults to False.  When true, do the same
thing you do with sockbuf != 0.

I see little value in actually being able to specify the exact buffer
size used on the internal makefile on the HTTPConnection.  The default
will be sufficient.

If you still want the user to be able to control it, perhaps add a
HTTPConnection class attribute that defaults to -1
(socket.socket.makefile()'s bufsize default value) that you pass to
makefile.  Users can subclass HTTPConnection and give it a new value in
that case.  Personally I'd call that overkill.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Sat Aug 15 08:41:05 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 15 Aug 2009 06:41:05 +0000
Subject: [issue6117] Fix O(n**2) performance problem in socket._fileobject
In-Reply-To: <1243353839.6.0.278053470116.issue6117@psf.upfronthosting.co.za>
Message-ID: <1250318465.82.0.404198082136.issue6117@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

backported to release26-maint in r74456.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6117>
_______________________________________

From report at bugs.python.org  Sat Aug 15 08:46:14 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 15 Aug 2009 06:46:14 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1250318774.61.0.348391287596.issue4879@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I believe there will be a problem with the patch committed in r68532. 
If getresponse(buffering=True) is called, extra data on the socket may
be consumed by the socket.makefile() buffer which will cause problems if
the connection is not closed immediately after this response.

I mentioned this in comments on http://bugs.python.org/issue2576 which
happens to have a way of fixing this already proposed as they are trying
to solve an almost identical issue to this without yet having seen this
issue.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Sat Aug 15 09:49:49 2009
From: report at bugs.python.org (Mark Summerfield)
Date: Sat, 15 Aug 2009 07:49:49 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250322589.0.0.356740161312.issue2636@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

Hi,

I've noticed 3 differences between the re and regex engines. 
I don't know if they are intended or not, but thought it best to mention
them. (I used the issue2636-20090810#3.zip version.)

Python 2.6.2 (r262:71600, Apr 20 2009, 09:25:38) 
[GCC 4.3.2 20081105 (Red Hat 4.3.2-7)] on linux2
IDLE 2.6.2      
>>> import re, regex
>>> ############################################################ 1 of 3
>>> re1= re.compile(r"""
                    (?!<\w)(?P<name>[-\w]+)=
                    (?P<quote>(?P<single>')|(?P<double>"))?
                    (?P<value>(?(single)[^']+?|(?(double)[^"]+?|\S+)))
                    (?(quote)(?P=quote))
                    """, re.VERBOSE)
>>> re2= regex.compile(r"""
                    (?!<\w)(?P<name>[-\w]+)=
                    (?P<quote>(?P<single>')|(?P<double>"))?
                    (?P<value>(?(single)[^']+?|(?(double)[^"]+?|\S+)))
                    (?(quote)(?P=quote))
                    """, re.VERBOSE)
>>> text = "<table border='1'>"
>>> re1.findall(text)
[('border', "'", "'", '', '1')]
>>> re2.findall(text)
[]
>>> text = "<table border=1>"
>>> re1.findall(text)
[('border', '', '', '', '1>')]
>>> re2.findall(text)
[]
>>> ############################################################ 2 of 3
>>> re1 = re.compile(r"""^[ \t]*
                         (?P<parenthesis>\()?
                         [- ]?
                         (?P<area>\d{3})
                         (?(parenthesis)\))
                         [- ]?
                         (?P<local_a>\d{3})
                         [- ]?
                         (?P<local_b>\d{4})
                         [ \t]*$
                         """, re.VERBOSE)
>>> re2 = regex.compile(r"""^[ \t]*
                         (?P<parenthesis>\()?
                         [- ]?
                         (?P<area>\d{3})
                         (?(parenthesis)\))
                         [- ]?
                         (?P<local_a>\d{3})
                         [- ]?
                         (?P<local_b>\d{4})
                         [ \t]*$
                         """, re.VERBOSE)
>>> data = ("179-829-2116", "(187) 160 0880", "(286)-771-3878",
"(291) 835-9634", "353-896-0505", "(555) 555 5555", "(555) 555-5555",
"(555)-555-5555", "555 555 5555", "555 555-5555", "555-555-5555",
"601 805 3142", "(675) 372 3135", "810 329 7071", "(820) 951 3885",
"942 818-5280", "(983)8792282")
>>> for d in data:
	ans1 = re1.findall(d)
	ans2 = re2.findall(d)
	print "re=%s rx=%s %d" % (ans1, ans2, ans1 == ans2)

re=[('', '179', '829', '2116')] rx=[('', '179', '829', '2116')] 1
re=[('(', '187', '160', '0880')] rx=[] 0
re=[('(', '286', '771', '3878')] rx=[('(', '286', '771', '3878')] 1
re=[('(', '291', '835', '9634')] rx=[] 0
re=[('', '353', '896', '0505')] rx=[('', '353', '896', '0505')] 1
re=[('(', '555', '555', '5555')] rx=[] 0
re=[('(', '555', '555', '5555')] rx=[] 0
re=[('(', '555', '555', '5555')] rx=[('(', '555', '555', '5555')] 1
re=[('', '555', '555', '5555')] rx=[] 0
re=[('', '555', '555', '5555')] rx=[] 0
re=[('', '555', '555', '5555')] rx=[('', '555', '555', '5555')] 1
re=[('', '601', '805', '3142')] rx=[] 0
re=[('(', '675', '372', '3135')] rx=[] 0
re=[('', '810', '329', '7071')] rx=[] 0
re=[('(', '820', '951', '3885')] rx=[] 0
re=[('', '942', '818', '5280')] rx=[] 0
re=[('(', '983', '879', '2282')] rx=[('(', '983', '879', '2282')] 1
>>> ############################################################ 3 of 3
>>> re1 = re.compile(r"""
<img\s+[^>]*?src=(?:(?P<quote>["'])(?P<qimage>[^\1>]+?)   
(?P=quote)|(?P<uimage>[^"' >]+))[^>]*?>""", re.VERBOSE)
>>> re2 = regex.compile(r"""
<img\s+[^>]*?src=(?:(?P<quote>["'])(?P<qimage>[^\1>]+?)   
(?P=quote)|(?P<uimage>[^"' >]+))[^>]*?>""", re.VERBOSE)
>>> data = """<body> <img src='a.png'> <img alt='picture' src="b.png">
              <img alt="picture" src="Big C.png" other="xyx">
              <img src=icon.png alt=icon>
              <img src="I'm here!.jpg" alt="aren't I?">"""
>>> data = data.split("\n")
>>> data = [x.strip() for x in data]
>>> for d in data:
	ans1 = re1.findall(d)
	ans2 = re2.findall(d)
	print "re=%s rx=%s %d" % (ans1, ans2, ans1 == ans2)

re=[("'", 'a.png', '')] rx=[("'", 'a.png', '')] 1
re=[('"', 'b.png', '')] rx=[('"', 'b.png', '')] 1
re=[('"', 'Big C.png', '')] rx=[('"', 'Big C.png', '')] 1
re=[('', '', 'icon.png')] rx=[('', '', 'icon.png alt=icon')] 0
re=[('"', "I'm here!.jpg", '')] rx=[('"', "I'm here!.jpg", '')] 1

I'm sorry I haven't had the time to try to minimize the examples, but I
hope that at least they will prove helpful.

Number 3 looks like a problem with non-greedy matching; I don't know
about the others.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Aug 15 11:15:49 2009
From: report at bugs.python.org (Chris Withers)
Date: Sat, 15 Aug 2009 09:15:49 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250327749.41.0.772190948244.issue2576@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Why not allow True or an integer as values for a buffer_size parameter 
to the HTTPConnection constructor. False would be the default, which 
would mean "no buffering" as currently is the case. True would mean use 
buffering of the default size and an integer value would mean use 
buffering of that size?

Out of interest, has any of the proposed patching from this issue, 
[issue4336] or [issue4879] been marged to the 2.6 branch?

PS: As I said, for me, changing the buffer size made no difference, so I 
may have to open up a separate issue once I figure out what's going 
on...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Sat Aug 15 11:56:02 2009
From: report at bugs.python.org (Thomas Heller)
Date: Sat, 15 Aug 2009 09:56:02 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1250291231.27.0.618493938959.issue6239@psf.upfronthosting.co.za>
Message-ID: <4A86862A.1000206@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> I agree that the C type 'char' is a byte, not a character. So Python3
> should creates a Python bytes object for the ctypes "c_char_p" type.
> Since Python 3.1 is out, is it too late to change it in the 3.x branch?
> :-) Maybe for Python 3.2?

I think the current behaviour is clearly a bug, so I would apply
this patch to Python 3.1 as well.  Any comments?  Who will decide that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Sat Aug 15 12:30:02 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 Aug 2009 10:30:02 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1250332202.43.0.981235666958.issue4970@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

srid, I'm not sure why you added your comment;  a couple of sentences 
explaining where the output you posted comes from (what machine, what 
version of Python, under what circumstances) would be really useful.

If you're able to reproduce this failure and have time to figure out where 
it's coming from, that would be fantastic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Sat Aug 15 13:18:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 15 Aug 2009 11:18:37 +0000
Subject: [issue1023290] proposed struct module format code addition
Message-ID: <1250335117.21.0.553963564027.issue1023290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for this patch, Alexandre!

I'm +1 on applying a version of this patch.

I'm not convinced that the variable-length part (i.e., fixed_length=None) of 
int.as_bytes is all that useful;  the choices that need to be made about how to 
represent integers seem too arbitrary to standardize in this function.  In effect, the 
non-fixed-length version provides yet another serialization mechanism for integers, 
and there's no shortage of existing mechanisms.  As I see it, the purpose of the 
as_bytes and frombytes methods is lower-level:  providing a basic operation that will 
be used by various serialization methods.  So I'd suggest making fixed_length a 
required argument;  code requiring non-fixed-length conversions can use int.bit_length 
to help calculate the length they want.


<bikeshedding>
I'm also not convinced by the defaults for the other two arguments:  personally, I'd 
expect to need unsigned more often than signed, and little-endian more often than big-
endian.

Perhaps the byteorder should default to the native byteorder when not explicitly 
given?  That would bring the conversions more closely in line with the struct module.

Another possibility:  instead of 'little_endian', have a parameter 'byteorder' taking 
the value 'big' or 'little';  this would enable use of byteorder=sys.byteorder to 
explicitly specify native byteorder, and avoids bias towards one particular byte 
order.

Can we use 'length' instead of 'fixed_length'?
</bikeshedding>

There's a typo in the test_long part of the patch: aserrtRaises -> assertRaises;  
apart from that, all tests pass on OS X 10.5/Intel with this patch applied.

I'm in the process of looking at the code more thoroughly.

See related Python-ideas thread at:

http://mail.python.org/pipermail/python-ideas/2009-August/005489.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Sat Aug 15 13:34:12 2009
From: report at bugs.python.org (Eric Eisner)
Date: Sat, 15 Aug 2009 11:34:12 +0000
Subject: [issue1023290] proposed struct module format code addition
Message-ID: <1250336052.86.0.911728660024.issue1023290@psf.upfronthosting.co.za>


Eric Eisner <ede at mit.edu> added the comment:

Is there some pre-existing naming convention of as_X and fromX? It seems 
strange that two related functions would have a different use of 
underscores.

----------
nosy: +ede

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Sat Aug 15 13:49:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Aug 2009 11:49:16 +0000
Subject: [issue1023290] proposed struct module format code addition
Message-ID: <1250336956.2.0.619678755033.issue1023290@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree with the comments which were made on the following points:
- please use consistent naming (`as_bytes` / `from_bytes`, or `asbytes`
/ `frombytes`; my preference goes to the former, especially now that we
have `bit_length`)
- default byteorder should be native, certainly not big endian which is
a small minority amongst today's computers
- you should synchronize with the python-ideas discussion, so that the
final API gets validated more publicly; it would not be very pleasant
for a patch to be committed if discussion were still in flux, and
perhaps with different conclusions as to the API which should be adopted

Besides, your patch has indentation problems (mixed spaces and tabs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Sat Aug 15 13:58:16 2009
From: report at bugs.python.org (John J Lee)
Date: Sat, 15 Aug 2009 11:58:16 +0000
Subject: [issue1424148] urllib.FancyURLopener.redirect_internal looses data on
	POST!
Message-ID: <1250337496.12.0.469370516839.issue1424148@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

If you have a feature request, please open a separate ticket.  This one 
is about an alleged bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424148>
_______________________________________

From report at bugs.python.org  Sat Aug 15 15:17:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Aug 2009 13:17:00 +0000
Subject: [issue6707] dir() on __new__'d module w/o dict crashes 2.6.2
In-Reply-To: <1250291202.25.0.109335007546.issue6707@psf.upfronthosting.co.za>
Message-ID: <1250342220.18.0.219114989095.issue6707@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the report! Fixed in r74457.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6707>
_______________________________________

From report at bugs.python.org  Sat Aug 15 16:02:22 2009
From: report at bugs.python.org (John Machin)
Date: Sat, 15 Aug 2009 14:02:22 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250344942.01.0.0032122347172.issue2636@psf.upfronthosting.co.za>


John Machin <sjmachin at users.sourceforge.net> added the comment:

Simplification of mark's first two problems:

Problem 1: looks like regex's negative look-head assertion is broken
>>> re.findall(r'(?!a)\w', 'abracadabra')
['b', 'r', 'c', 'd', 'b', 'r']
>>> regex.findall(r'(?!a)\w', 'abracadabra')
[]


Problem 2: in VERBOSE mode, regex appears to be ignoring spaces inside
character classes

>>> import re, regex
>>> pat = r'(\w)([- ]?)(\w{4})'
>>> for data in ['abbbb', 'a-bbbb', 'a bbbb']:
...    print re.compile(pat).findall(data), regex.compile(pat).findall(data)
...    print re.compile(pat, re.VERBOSE).findall(data),
regex.compile(pat,regex.
VERBOSE).findall(data)
...
[('a', '', 'bbbb')] [('a', '', 'bbbb')]
[('a', '', 'bbbb')] [('a', '', 'bbbb')]
[('a', '-', 'bbbb')] [('a', '-', 'bbbb')]
[('a', '-', 'bbbb')] [('a', '-', 'bbbb')]
[('a', ' ', 'bbbb')] [('a', ' ', 'bbbb')]
[('a', ' ', 'bbbb')] []

HTH,
John

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Aug 15 16:03:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Aug 2009 14:03:47 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1250345027.82.0.959692098646.issue6239@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree that it's a bug.  Letting Benjamin decide whether to put it in
3.1.1 :)

----------
assignee: theller -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Sat Aug 15 16:07:16 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Aug 2009 14:07:16 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1250345027.82.0.959692098646.issue6239@psf.upfronthosting.co.za>
Message-ID: <1afaf6160908150707r31566b10pdbf06a02ec318316@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

Sounds ok to me.

2009/8/15 Georg Brandl <report at bugs.python.org>:
>
> Georg Brandl <georg at python.org> added the comment:
>
> I agree that it's a bug. ?Letting Benjamin decide whether to put it in
> 3.1.1 :)
>
> ----------
> assignee: theller -> benjamin.peterson
> nosy: +benjamin.peterson
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6239>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Sat Aug 15 18:12:30 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 15 Aug 2009 16:12:30 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250352750.62.0.661935347555.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20090815.zip fixes the bugs found in msg91598 and msg91607.

The regex engine currently lacks some of the optimisations that the re
engine has, but I've concluded that even with them the extra work that
the engine needs to do to make it easy to switch to breadth-wise
matching when needed is slowing it down too much (if it's matching only
depth-first then it can save only the changes to the 'context', but if
it's matching breadth-wise then it needs to duplicate the entire 'context').

I'm therefore seeing whether I can have 2 engines internally, one
optimised for depth-first and the other for breadth-wise, and switch
from the former to the latter if matching is taking too long.

----------
Added file: http://bugs.python.org/file14733/issue2636-20090815.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Aug 15 19:10:55 2009
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Aug 2009 17:10:55 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1250356255.83.0.0295703480507.issue6239@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I agree that it's a bug.
> Letting Benjamin decide whether to put it in 3.1.1 :)

And what about 3.0.x? Is this branch still alive or not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Sat Aug 15 19:15:04 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Aug 2009 17:15:04 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1250356255.83.0.0295703480507.issue6239@psf.upfronthosting.co.za>
Message-ID: <1afaf6160908151014l2c53f2eaw983930594c98e019@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2009/8/15 STINNER Victor <report at bugs.python.org>:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> I agree that it's a bug.
>> Letting Benjamin decide whether to put it in 3.1.1 :)
>
> And what about 3.0.x? Is this branch still alive or not?

No, it's as dead as a doornail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Sat Aug 15 19:35:28 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Aug 2009 17:35:28 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250357728.5.0.828373931275.issue6695@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The reason is that users expect gc.collect() to make its best to
diminish memory use. Clearing free lists can allow deallocting some
arenas which otherwise would still contain some used memory blocks. As
the comment says:

/* Clear all free lists
 * All free lists are cleared during the collection of the highest
generation.
 * Allocated items in the free list may keep a pymalloc arena occupied.
 * Clearing the free lists may give back memory to the OS earlier.
 */

Full collections (collections of the oldest generation) are rather rare,
so the performance impact is probably minimal, and it helps reduce
memory fragmentation from time to time (which can produce significant
effect as shown in Matthias' example).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sat Aug 15 19:40:02 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Aug 2009 17:40:02 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1250358002.67.0.929027885528.issue6690@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's certainly possible to do so, do you have a patch?

----------
nosy: +pitrou, rhettinger
priority:  -> normal
stage:  -> needs patch
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Sat Aug 15 19:51:01 2009
From: report at bugs.python.org (Senthil)
Date: Sat, 15 Aug 2009 17:51:01 +0000
Subject: [issue6557] urllib.urlopen creates bad requests when location header
	of 301 redirects contain spaces
In-Reply-To: <1248385969.73.0.0313821964129.issue6557@psf.upfronthosting.co.za>
Message-ID: <1250358661.12.0.675553745568.issue6557@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Fixed and Committed revision 74462

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6557>
_______________________________________

From report at bugs.python.org  Sat Aug 15 19:55:23 2009
From: report at bugs.python.org (Josiah Carlson)
Date: Sat, 15 Aug 2009 17:55:23 +0000
Subject: [issue1023290] proposed struct module format code addition
Message-ID: <1250358923.89.0.515620781765.issue1023290@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

I'm not a big fan of the names, but as long as the functionality exists, 
people can easily alias them as necessary.

I've not actually looked at the patch, but as long as it does what it 
says it does, it looks good.

My only question, does it makes sense to backport this to trunk so we 
get this in 2.7?  I personally would like to see it there, and would 
even be ok with a limitation that it only exists as part of longs.  If 
someone has the time to backport it; cool.  If not, I understand, and 
could live with it only being in 3.x .

Thank you for taking the time and making the effort in getting this into 
a recent Python :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:02:22 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 15 Aug 2009 22:02:22 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250373742.02.0.0255044302333.issue2576@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Anything that adds a new parameter can not be backported to 2.6 as that
counts as an API change / feature addition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:06:17 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Aug 2009 22:06:17 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250373977.52.0.413904489245.issue6695@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> The reason is that users expect gc.collect() to make 
> its best to diminish memory use.

I thought GC was expected to eliminate reference cycles.
Perhaps there ought to be a separate API, such as 
sys.clear_freelists(), to eliminate other memory use when 
needed.  Putting this in GC seems like feature creep and
has negative performance implications (long running programs
will likely find an immediate need to reallocate the freed
members).


> Allocated items in the free list may keep a pymalloc arena occupied.
> * Clearing the free lists may give back memory to the OS earlier.

These are both good reasons to expose the functionality somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:12:18 2009
From: report at bugs.python.org (Jim Fulton)
Date: Sat, 15 Aug 2009 22:12:18 +0000
Subject: [issue6710] hotshot stats load causes TypeError when multiple files
	are loaded
In-Reply-To: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>
Message-ID: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>


New submission from Jim Fulton <jim at zope.com>:

I've attached a script that demonstrates the problem.  When run with
Python 2.5, it outputs statistics.  When run with Python 2.6.2 it
generates a TypeError:

python2.6 hotshotbug.py
Traceback (most recent call last):
  File "hotshotbug.py", line 5, in <module>
    stats.add(hotshot.stats.load('p2'))
  File "/usr/local/python/2.6/lib/python2.6/pstats.py", line 171, in add
    self.stats[func] = add_func_stats(old_func_stat, stat)
  File "/usr/local/python/2.6/lib/python2.6/pstats.py", line 516, in
add_func_stats
    add_callers(t_callers, callers))
  File "/usr/local/python/2.6/lib/python2.6/pstats.py", line 526, in
add_callers
    zip(caller, new_callers[func])])
TypeError: zip argument #1 must support iteration

----------
components: Library (Lib)
files: hotshotbug.py
messages: 91619
nosy: j1m
severity: normal
status: open
title: hotshot stats load causes TypeError when multiple files are loaded
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14734/hotshotbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6710>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:13:27 2009
From: report at bugs.python.org (Jim Fulton)
Date: Sat, 15 Aug 2009 22:13:27 +0000
Subject: [issue6710] hotshot stats load causes TypeError when multiple files
	are loaded
In-Reply-To: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>
Message-ID: <1250374407.75.0.735690746141.issue6710@psf.upfronthosting.co.za>


Jim Fulton <jim at zope.com> added the comment:

Fred might be interested. :)

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6710>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:39:59 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 15 Aug 2009 22:39:59 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1250375999.59.0.856665749724.issue4879@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

trunk r74463 now forces the HTTPResponse to close afterwards when
buffering=True to avoid the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:41:18 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 15 Aug 2009 22:41:18 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250376078.94.0.693497740293.issue2576@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

trunk r74463 now forces the HTTPResponse with buffering=True to close
afterwards using a HTTPResponse._must_close flag similar to what was
suggested in buffered_socket.diff in this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:50:45 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Aug 2009 22:50:45 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250373977.52.0.413904489245.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250376829.4731.8.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 15 ao?t 2009 ? 22:06 +0000, Raymond Hettinger a ?crit :
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
> 
> > The reason is that users expect gc.collect() to make 
> > its best to diminish memory use.
> 
> I thought GC was expected to eliminate reference cycles.

Of course, but it's also the de facto API when wanting to reclaim
memory. The face that a single function call is sufficient is a good
thing in itself.

> Perhaps there ought to be a separate API, such as 
> sys.clear_freelists(), to eliminate other memory use when 
> needed.  Putting this in GC seems like feature creep and
> has negative performance implications (long running programs
> will likely find an immediate need to reallocate the freed
> members).

Performance claims should be substanstiated with actual numbers,
otherwise it's too easy to clutter the API with gratuitous
complications. The impact of reallocating may be negligible, or it might
even be positive if it improves cache locality.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sun Aug 16 00:59:50 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 15 Aug 2009 22:59:50 +0000
Subject: [issue6704] better col_offset for AST in statements like "for a,
	b in ..."
In-Reply-To: <1250276147.3.0.975792717277.issue6704@psf.upfronthosting.co.za>
Message-ID: <1250377190.0.0.511389562531.issue6704@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch! Commited in r74464.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6704>
_______________________________________

From report at bugs.python.org  Sun Aug 16 01:00:46 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 15 Aug 2009 23:00:46 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1250377246.92.0.828293953801.issue2576@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I am also unable to reproduce the reported problem using the
pastebin.ca/973578 code.  The time to download 400mb from localhost
remains the same regardless of buffering=False (default) or True.

The problem still exists but it is better described in issue1542407 and
should only effect the performance of reading the HTTP headers (a lot if
you're writing an application doing small/medium RPC requests over HTTP).

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
_______________________________________

From report at bugs.python.org  Sun Aug 16 04:31:36 2009
From: report at bugs.python.org (Alex)
Date: Sun, 16 Aug 2009 02:31:36 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1250389896.41.0.0998509763794.issue6690@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Antoine, I hope to have some time to write a patch for this in the
coming week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Sun Aug 16 07:04:12 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Aug 2009 05:04:12 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1250399052.28.0.763002888696.issue6690@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Sun Aug 16 08:25:40 2009
From: report at bugs.python.org (Joe Amenta)
Date: Sun, 16 Aug 2009 06:25:40 +0000
Subject: [issue6711] macurl2path has typos that raise AttributeError
In-Reply-To: <1250403940.35.0.572726504822.issue6711@psf.upfronthosting.co.za>
Message-ID: <1250403940.35.0.572726504822.issue6711@psf.upfronthosting.co.za>


New submission from Joe Amenta <amentajo at msu.edu>:

In a few spots, "urllib.parse" misses a "." after the package name.

e.g., "urllib.parse.quote" is spelled "urllib.parsequote", which
generates an AttributeError when run.

To reproduce, open up a python3.x interpreter and execute:
from macurl2path import *
url2pathname('doesnt_matter_what')
pathname2url('some_string')
_pncomp2url('something_else')

Attaching a patch that will fix the issue.

----------
components: Library (Lib)
files: py3k_url2path.patch
keywords: patch
messages: 91627
nosy: joe.amenta
severity: normal
status: open
title: macurl2path has typos that raise AttributeError
type: crash
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14735/py3k_url2path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6711>
_______________________________________

From report at bugs.python.org  Sun Aug 16 08:47:21 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 16 Aug 2009 06:47:21 +0000
Subject: [issue6711] macurl2path has typos that raise AttributeError
In-Reply-To: <1250403940.35.0.572726504822.issue6711@psf.upfronthosting.co.za>
Message-ID: <1250405241.52.0.727532701485.issue6711@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Thanks for the patch. 

Fixed it and 

Committed revision 74469 - py3.2
Committed revision 74470 - py3.1 maint.

I wonder how it got unnoticed so far.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6711>
_______________________________________

From report at bugs.python.org  Sun Aug 16 12:44:21 2009
From: report at bugs.python.org (Johannes Janssen)
Date: Sun, 16 Aug 2009 10:44:21 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>


New submission from Johannes Janssen <mail at johannes-janssen.de>:

As I learned on the mailing list the function sys._getframe() is not
available on all Python implementations (e.g. jython). This information
should be added to the documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 91629
nosy: georg.brandl, johannes.janssen
severity: normal
status: open
title: sys._getframe is not available on all Python implementations

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Sun Aug 16 13:12:55 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 16 Aug 2009 11:12:55 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250421175.91.0.567133597248.issue6712@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Sun Aug 16 13:53:25 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 16 Aug 2009 11:53:25 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1250423605.49.0.0753603572435.issue4395@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Sun Aug 16 16:28:07 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 16 Aug 2009 14:28:07 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250376829.4731.8.camel@localhost>
Message-ID: <19080.6000.580993.804289@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

>> I thought GC was expected to eliminate reference cycles.

    Antoine> Of course, but it's also the de facto API when wanting to
    Antoine> reclaim memory.

When did that happen?  I agree with Raymond.  The cyclic gc should just
reclaim cycles.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sun Aug 16 16:43:55 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Aug 2009 14:43:55 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <19080.6000.580993.804289@montanaro.dyndns.org>
Message-ID: <1250434019.5558.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> When did that happen?  I agree with Raymond.  The cyclic gc should just
> reclaim cycles.

People don't care about referential cycles, they care about freeing some
memory (if memory was available in infinite quantities nobody would care
about breaking cycles). That's how the API is used most of the time,
IMO. And that's why measurements of the usefulness of calling
gc.collect() are usually done in megabytes, not in number of
references :-).

So, while I agree that it sounds bizarre for the GC to do other
memory-related tasks, it's also quite practical. Besides, the GC already
has a heuristic for *when* to cleanup memory, and it makes sense to
reuse this heuristic for other memory cleanup tasks, rather than to
invent another heuristic or put the burden of the task on the user (who
usually won't even know what those freelists are).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sun Aug 16 16:47:34 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 16 Aug 2009 14:47:34 +0000
Subject: [issue6244] Support for tcl 8.6
In-Reply-To: <1244496903.79.0.308106230348.issue6244@psf.upfronthosting.co.za>
Message-ID: <1250434054.14.0.893748799252.issue6244@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This has been committed now, r74471,74472 (trunk) and r74473 (py3k).

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6244>
_______________________________________

From report at bugs.python.org  Sun Aug 16 17:13:56 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Aug 2009 15:13:56 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250435636.83.0.67002315053.issue6695@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The change was originally made in r60797, ? Implemented Martin's
suggestion to clear the free lists during the garbage collection of the
highest generation ?.

----------
nosy: +christian.heimes, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sun Aug 16 17:18:30 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 16 Aug 2009 15:18:30 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250435910.65.0.166953165238.issue6695@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

FWIW, I agree with Antoine here.  I think user expectation is that when
"garbage" is collected, at least some freed memory will be returned to
the operating system.  The normal user's conception of what "garbage" is
has nothing to do with cycles.  It just so happens that in CPython,
that's the main thing the garbage collector collects.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sun Aug 16 17:57:02 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Aug 2009 15:57:02 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250438222.9.0.118948872598.issue6695@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sun Aug 16 18:04:57 2009
From: report at bugs.python.org (Giorgos Verigakis)
Date: Sun, 16 Aug 2009 16:04:57 +0000
Subject: [issue6627] threading.local() does not work with C-created threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1250438697.91.0.519558915345.issue6627@psf.upfronthosting.co.za>


Changes by Giorgos Verigakis <verigak at gmail.com>:


----------
nosy: +verigak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________

From report at bugs.python.org  Sun Aug 16 19:08:05 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 16 Aug 2009 17:08:05 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250442485.27.0.00434473336065.issue6695@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I still stand by my suggestion to free memory as a side effect of
garbage collection. It may well be that an application will start
re-allocating blocks that soon end up in the free list again. OTOH, it
may also be that releasing those free lists, along with the freeing that
the GC just did, can cause arenas to become completely free, and thus be
returned to the operating system. Users really really want Python to
return memory to the operating system whenever possible, and on its own;
those free lists can block memory from being returned, more or less
unreasonably.

So unless it can be demonstrated (preferably in a realistic application)
that clearing the free lists has a measurable negative impact, I propose
to keep things the way they are.

IMO, it would be best if we could eliminate the freelists altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sun Aug 16 19:45:49 2009
From: report at bugs.python.org (Gawain Bolton)
Date: Sun, 16 Aug 2009 17:45:49 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>


New submission from Gawain Bolton <gp.bolton at computer.org>:

Converting integer & long types to their ASCII representation is a task
which can be quite CPU intensive due to the division & modulo
operations.  For long integers having hundreds or thousands of digits,
this can take a truly significant amount of CPU time.

I have written a special case for base 10 conversions which allows for
two improvements.
1) Two digits can be converted at a time, thus reducing the number of
div/mod operations by two.
2) An optimizing compiler can avoid performing a division operation when
the divisor is hardcoded.  The expensive division operation can be
replaced by a much faster multiplication operation.

My tests show an improvement of 1.6x to 1.8x improvement for integer
types and 2x improvement for longs.

Note that because integers are displayed using fprintf(), the
performance improvement is only seen when __repr__() is called.

Patch is provided against trunk.  It is somewhat difficult to read the
patch in one or two places due to the use of tabs.

----------
components: Interpreter Core
files: base10_conversion_performance_patch.txt
messages: 91636
nosy: gawain
severity: normal
status: open
title: Integer & Long types:  Performance improvement of 1.6x to 2x for base 10 conversions
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file14736/base10_conversion_performance_patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:12:16 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 18:12:16 +0000
Subject: [issue6665] fnmatch fails on filenames containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1250446336.82.0.171850294809.issue6665@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6665>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:23:48 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 18:23:48 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250447028.51.0.31108745184.issue6695@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

+1 on the PyXXX_ClearFreeList patch and calling them from gc.collect()
as is done with the others.

I agree with Guido, don't add a tp_free_list slot as the common case
would be NULL.

Regarding gc clearing freelists: I agree with Antoine and Martin. 
Clearing free lists in the highest generation of GC is a very good
thing.  Rebuilding them infrequently should not have a significant
performance impact and makes long running python jobs better behaved by
releasing more memory when possible.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:31:37 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 18:31:37 +0000
Subject: [issue6665] fnmatch fails on filenames containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1250447497.2.0.105970882024.issue6665@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

haha wow I just read the fnmatch code... trunk r2734 | guido | 1992-01-12 

added fnmatch._cache for it to cache compiled regular expressions.  That
has -long- since become unnecessary as the re module does that itself. ;)

I'll clean this up while fixing this bug.

----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6665>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:34:00 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 18:34:00 +0000
Subject: [issue6665] fnmatch fails on filenames containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1250447640.59.0.378338444524.issue6665@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

aww, i guess the _cache does cache the result of the glob -> regular
expression translation.  it needs to stay for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6665>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:48:33 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 18:48:33 +0000
Subject: [issue6665] fnmatch fails on filenames containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1250448513.54.0.826639216.issue6665@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

changing the '$' to \Z(?ms)' fixes the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6665>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:55:02 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 16 Aug 2009 18:55:02 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250448902.17.0.312339328964.issue6712@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The leading underscore is meant to convey that it is not guaranteed to 
exist. But in spite of this, we do plan long-term to make it explicit what 
all interpreters are expected to (not) support.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Sun Aug 16 20:59:02 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 18:59:02 +0000
Subject: [issue6665] fnmatch fails on filenames containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1250449142.13.0.0246042341378.issue6665@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in trunk r74475, py3k r74476

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6665>
_______________________________________

From report at bugs.python.org  Sun Aug 16 21:00:54 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 19:00:54 +0000
Subject: [issue6665] fnmatch fails on filenames containing \n character
In-Reply-To: <1249638559.7.0.0574356115412.issue6665@psf.upfronthosting.co.za>
Message-ID: <1250449254.56.0.0317112679078.issue6665@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I'll backport this to 2.6 and 3.1 later (its too late for 3.1.1).

----------
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6665>
_______________________________________

From report at bugs.python.org  Sun Aug 16 23:32:53 2009
From: report at bugs.python.org (Giorgos Verigakis)
Date: Sun, 16 Aug 2009 21:32:53 +0000
Subject: [issue6714] memmove fails with unicode strings
In-Reply-To: <1250458373.38.0.665694741005.issue6714@psf.upfronthosting.co.za>
Message-ID: <1250458373.38.0.665694741005.issue6714@psf.upfronthosting.co.za>


New submission from Giorgos Verigakis <verigak at gmail.com>:

A demonstration:

>>> buf = create_string_buffer('______')
>>> memmove(buf, 'SPAM', 4)
614584
>>> buf.raw
'SPAM__\x00'

>>> buf = create_string_buffer('______')
>>> memmove(buf, u'SPAM', 4)
614672
>>> buf.raw
'S\x00\x00\x00__\x00'

FWIW memmove fails in Python 3.0 too.

----------
assignee: theller
components: ctypes
messages: 91644
nosy: theller, verigak
severity: normal
status: open
title: memmove fails with unicode strings
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6714>
_______________________________________

From report at bugs.python.org  Sun Aug 16 23:42:43 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 16 Aug 2009 21:42:43 +0000
Subject: [issue6714] memmove fails with unicode strings
In-Reply-To: <1250458373.38.0.665694741005.issue6714@psf.upfronthosting.co.za>
Message-ID: <1250458963.12.0.817570621506.issue6714@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

What platform is this on? For a ucs4 platform, that is what I'd expect
the result to be. Check sys.maxunicode to see if you have a ucs2 or ucs4
build.

What do you expect as the result?

Remember that memmove takes a count of bytes, not a character count.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6714>
_______________________________________

From report at bugs.python.org  Mon Aug 17 00:01:03 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 22:01:03 +0000
Subject: [issue6281] Bug in hashlib
In-Reply-To: <1244933131.5.0.604284990762.issue6281@psf.upfronthosting.co.za>
Message-ID: <1250460063.73.0.0883746301153.issue6281@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

That code was indeed a mess.  I've incorporated most suggestions from
your cleaned up version (and fixed a bug in it) in trunk r74479.

Have you ever seen __get_builtin_constructor fail in practice?  I can
imagine that packing up a stripped down python interpreter with only a
subset of the hash extension modules would be the only time this would
likely be encountered.

I've changed your code to log an error and continue rather than silently
continue when an expected hash function is not available.  That error
log may be overkill, perhaps we should just leave catching this problem
up to the unittests.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6281>
_______________________________________

From report at bugs.python.org  Mon Aug 17 00:01:30 2009
From: report at bugs.python.org (Tobias Ivarsson)
Date: Sun, 16 Aug 2009 22:01:30 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250460090.97.0.657409671698.issue6712@psf.upfronthosting.co.za>


Tobias Ivarsson <thobes at gmail.com> added the comment:

While it is true that not all Python implementations support
sys._getframe() in some or all execution modes, Jython does support it,
even IronPython supports it with the proper startup parameters these days.

More importantly sys._getframe() [or something equivalent] *is*
available as a public API in the inspect module of Python, as
inspect.currentframe(). I don't know why the inspect module is not
brought up in the discussions about sys._getframe(), but it is a public
API. Would this mean that introspecting callframes is something all
interpreters are expected to support? Brett: what is your opinion?
Perhaps I should move this discussion to the mailing list?

----------
nosy: +thobe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Mon Aug 17 00:11:06 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 22:11:06 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250460666.67.0.542370326711.issue6712@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Yeah I'd take this to the list.  Perhaps this is destined to be a public
API.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Mon Aug 17 00:24:25 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 16 Aug 2009 22:24:25 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250461465.12.0.243929493366.issue6712@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

It's actually quite annoying that inspect takes a private API (that has
warnings in the documentation about its use) and makes it public. It's
just a direct alias. That in itself is not a good reason to say the
_getframe should be public.

Python frames are not available by *default* in Python, because of the
performance cost of using them.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Mon Aug 17 00:24:58 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 Aug 2009 22:24:58 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1250461498.96.0.307334525566.issue3566@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

btw, when using async io (poll, select, etc) I -think- your socket will
see a read event when the server closes the connection (sends you a FIN
or even a RST) at which point your sock.recv() when you've been told
data was ready will return 0 bytes indicating that the server has closed
the connection.

I like your MSG_PEEK hack here.  I'll figure out if this or something
else should go into (the giant mess that is) httplib.

----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Mon Aug 17 01:16:49 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 16 Aug 2009 23:16:49 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250464609.55.0.340778905532.issue6712@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It sounds like inspect needs to have its docs updated such that it makes 
it explicit inspect.currentframe() requires sys._getframe() to exist to 
return anything of use (the code returns None in other cases). So the 
public API can exist, but it needs to say what it depends on is optional.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Mon Aug 17 01:23:07 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 16 Aug 2009 23:23:07 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250419461.12.0.110179836515.issue6712@psf.upfronthosting.co.za>
Message-ID: <1250464987.96.0.379097926842.issue6712@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I meant in IronPython of course. D'oh. Anyway, I made the change to
inspect to keep it compatible with IronPython so I can make the
documentation change.

A mention in the sys._getframe docs that it is not guaranteed to exist
across implementations would be useful. I'll add that unless there are
major objections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Mon Aug 17 01:34:03 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 16 Aug 2009 23:34:03 +0000
Subject: [issue6712] sys._getframe is not available on all Python
	implementations
In-Reply-To: <1250464987.96.0.379097926842.issue6712@psf.upfronthosting.co.za>
Message-ID: <bbaeab100908161633g2ae0f238ta586c2bb63686ced@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sun, Aug 16, 2009 at 16:23, Michael Foord<report at bugs.python.org> wrote:
>
> Michael Foord <michael at voidspace.org.uk> added the comment:
>
> I meant in IronPython of course. D'oh. Anyway, I made the change to
> inspect to keep it compatible with IronPython so I can make the
> documentation change.
>
> A mention in the sys._getframe docs that it is not guaranteed to exist
> across implementations would be useful. I'll add that unless there are
> major objections.

You won't get objections as that's what the code does. I say just do
it and if people actually object we can back out the commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6712>
_______________________________________

From report at bugs.python.org  Mon Aug 17 01:46:49 2009
From: report at bugs.python.org (Giorgos Verigakis)
Date: Sun, 16 Aug 2009 23:46:49 +0000
Subject: [issue6714] memmove fails with unicode strings
In-Reply-To: <1250458373.38.0.665694741005.issue6714@psf.upfronthosting.co.za>
Message-ID: <1250466409.92.0.855129532678.issue6714@psf.upfronthosting.co.za>


Giorgos Verigakis <verigak at gmail.com> added the comment:

Yes, you are right. I thought that the different behavior was weird. Sorry 
this is not a bug.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6714>
_______________________________________

From report at bugs.python.org  Mon Aug 17 03:17:01 2009
From: report at bugs.python.org (Eric Smith)
Date: Mon, 17 Aug 2009 01:17:01 +0000
Subject: [issue6714] memmove fails with unicode strings
In-Reply-To: <1250458373.38.0.665694741005.issue6714@psf.upfronthosting.co.za>
Message-ID: <1250471821.54.0.602835605905.issue6714@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6714>
_______________________________________

From report at bugs.python.org  Mon Aug 17 04:26:09 2009
From: report at bugs.python.org (Senthil)
Date: Mon, 17 Aug 2009 02:26:09 +0000
Subject: [issue1424148] urllib.FancyURLopener.redirect_internal looses data on
	POST!
Message-ID: <1250475969.36.0.791844250927.issue1424148@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I am assigning this to myself. I shall do some research on this issue +
plus current standings by other clients/libraries and come out with a
summary.

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424148>
_______________________________________

From report at bugs.python.org  Mon Aug 17 08:29:08 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 17 Aug 2009 06:29:08 +0000
Subject: [issue6673] Py3.1 hangs in coroutine and eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1250490548.04.0.083952838461.issue6673@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Mon Aug 17 08:32:15 2009
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 17 Aug 2009 06:32:15 +0000
Subject: [issue6673] Py3.1 hangs in coroutine and eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1250490735.79.0.599360890756.issue6673@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Very good argumentation, thanks Nick!

I think this is worth being fixed in the 3.1 series.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Mon Aug 17 11:47:24 2009
From: report at bugs.python.org (devurandom)
Date: Mon, 17 Aug 2009 09:47:24 +0000
Subject: [issue6715] xz compression support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>


New submission from devurandom <devurandom at gmx.net>:

Python currently supports zlib, gzip and bzip2 compressors. What is missing is support 
for xz (http://tukaani.org/xz/). It comes with a C library.

----------
components: Library (Lib)
messages: 91657
nosy: devurandom
severity: normal
status: open
title: xz compression support
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Aug 17 13:37:28 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 17 Aug 2009 11:37:28 +0000
Subject: [issue6715] xz compression support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1250509048.14.0.998326491568.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is zc really a C library? I could find a standalone program, but no
shared object.
Actually, it seems that zc is a file format based on the lzma algorithm.
The plan could be to first implement the lzma module (issue5689), then a
xzfile module in pure python.

----------
dependencies: +please support lzma compression as an extension and in	the tarfile module
nosy: +amaury.forgeotdarc
stage:  -> needs patch
versions:  -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Aug 17 13:43:12 2009
From: report at bugs.python.org (Matthias Troffaes)
Date: Mon, 17 Aug 2009 11:43:12 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1250509392.51.0.776676584659.issue6695@psf.upfronthosting.co.za>


Matthias Troffaes <matthias.troffaes at gmail.com> added the comment:

To aid the discussion, I attach another quick patch which reports the
time spent on PyXXX_ClearFreeList calls during highest generation
garbage collection (including gc.collect()). For simplicity, the timer
uses clock() so the resolution is quite limited (appears to be 10ms on
my machine) and I don't claim that this is the best way of measuring
execution speed, but at least it gives some indication.

The patch also gives an indication at how frequently the highest
generation is collected.

Below is the result of the patch on the py3k-freelist_test.py test
script, on my machine (again, debug build). For reference, I've measured
the total time spent by the script as well, with the time command.

Summarizing, (30+70+30+30+50+70+20+110)/48420.0 = 0.0085 = 0.85% of time
is spent on freeing the freelists, in my test.

Another way to look at the data is that it roughly takes 10ms for each
100MB allocated (at least for the types of data in the script). Floats
seem to be an exception and take at least twice as long (not sure why).

Keep in mind that the test merely allocates and deallocates memory,
without doing much else, so it isn't a typical Python application.

$ time ./python py3k-freelist_test.py

Memory used (begin): 121Mb

memtest 2000000 int
====================
Memory used (peak): 297Mb
cleared free lists in 0 clock ticks (0.000000ms)
Memory used (end): 121Mb
Unfreed memory: 0Mb

memtest 2000000 str
====================
Memory used (peak): 455Mb
cleared free lists in 30000 clock ticks (30.000000ms)
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 float
====================
Memory used (peak): 236Mb
cleared free lists in 70000 clock ticks (70.000000ms)
Memory used (end): 127Mb
Unfreed memory: 6Mb

memtest 2000000 int
====================
Memory used (peak): 312Mb
cleared free lists in 0 clock ticks (0.000000ms)
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 Test
====================
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
Memory used (peak): 372Mb
cleared free lists in 30000 clock ticks (30.000000ms)
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 Test2
====================
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
Memory used (peak): 361Mb
cleared free lists in 30000 clock ticks (30.000000ms)
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 _tuple
====================
Memory used (peak): 529Mb
cleared free lists in 50000 clock ticks (50.000000ms)
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 _set
====================
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
Memory used (peak): 846Mb
cleared free lists in 70000 clock ticks (70.000000ms)
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 200000 _dict
====================
Memory used (peak): 233Mb
cleared free lists in 20000 clock ticks (20.000000ms)
Memory used (end): 123Mb
Unfreed memory: 2Mb

memtest 2000000 Test3
====================
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
cleared free lists in 0 clock ticks (0.000000ms)
Memory used (peak): 999Mb
cleared free lists in 110000 clock ticks (110.000000ms)
Memory used (end): 123Mb
Unfreed memory: 2Mb
cleared free lists in 0 clock ticks (0.000000ms)
[40763 refs]

real	0m50.921s
user	0m48.420s
sys	0m2.330s

----------
Added file: http://bugs.python.org/file14737/py3k-clearfreelist-time_gc_collect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6695>
_______________________________________

From report at bugs.python.org  Mon Aug 17 13:51:45 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 17 Aug 2009 11:51:45 +0000
Subject: [issue6715] xz compression support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <19081.17485.596056.497911@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

What is xz compression and why is it important?

Skip

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Aug 17 14:13:15 2009
From: report at bugs.python.org (devurandom)
Date: Mon, 17 Aug 2009 12:13:15 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1250511195.64.0.967302214797.issue6715@psf.upfronthosting.co.za>


devurandom <devurandom at gmx.net> added the comment:

Yes, xz-utils contains a C library, though it still caries the name
"liblzma.so", probably for historic reasons.
You are right that xz is a file format based around the lzma algorithm.
It just uses a more advanced container format. (lzma-utils had no
container at all.)

xz is the successor of lzma, which provides a better compression than
bzip2, while decompression speed is comparable with gzip. It is used by
the GNU project for source tarball compression (replacing bzip2) and
supported by GNU tar. See http://en.wikipedia.org/wiki/Xz,
http://tukaani.org/xz/ and http://tukaani.org/lzma/ for reference.

----------
title: xz compression support -> xz compressor support

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Aug 17 15:05:09 2009
From: report at bugs.python.org (pds)
Date: Mon, 17 Aug 2009 13:05:09 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>


New submission from pds <pirdirsir at gmail.com>:

There seem to be 3 problems in Python 3.1.1rc1 Windows installer package.

1. Command line argument of compileall.py seems wrong.
2. UnicodeEncodeError occurs depending on code page.
3. Syntax errors.

First, I tried to install Python 3.1.1rc1 just by double-clicking the
Windows msi installer package file, python-3.1.1rc1.msi, as an
administrator account, with the following environment and settings.

Operating System version: Windows XP Professional SP3 (Japanese version)
Install options: Install for all users
Destination directory: C:\Python31
Advanced options: Enable "Compile .py files to byte code after installation"

Then the following dialog message appeared during installation.

There is a problem with this Windows Installer package. A program run as
part of the setup did not finish as expected. Contact your support
personnel or package vendor.

Despite the message, installation of Python interpreter seemed completed
because the programs were registered in Windows start menu.
So I uninstalled Python 3.1.1rc1 to make sure the system to be clean,
and retried installation with the following command from command prompt
so I could see the log file later.

msiexec /i python-3.1.1rc1.msi /L*v python-3.1.1rc1.log

Installation failed again, and the following is the part of the log file
(python-3.1.1rc1.log).

MSI (s) (18:50) [15:08:25:096]: Note: 1: 1722 2: CompilePyc 3:
C:\Python31\python.exe 4: -Wi "C:\Python31\Lib\compileall.py" -f -x
bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib" 
MSI (s) (18:50) [15:08:25:096]: Note: 1: 2262 2: Error 3: -2147287038 
Error 1722. There is a problem with this Windows Installer package. A
program run as part of the setup did not finish as expected. Contact
your support personnel or package vendor.  Action CompilePyc, location:
C:\Python31\python.exe, command: -Wi "C:\Python31\Lib\compileall.py" -f
-x bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib" 
MSI (s) (18:50) [15:10:58:677]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (18:50) [15:10:58:677]: Product: Python 3.1.1rc1 -- Error 1722.
There is a problem with this Windows Installer package. A program run as
part of the setup did not finish as expected. Contact your support
personnel or package vendor.  Action CompilePyc, location:
C:\Python31\python.exe, command: -Wi "C:\Python31\Lib\compileall.py" -f
-x bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib" 

Also, installation completes normally if I choose not to compile .py
files in advanced options setting during the installer's setup dialog.

------
Problem 1: Command line argument of compileall.py seems wrong.

Because installation fails if I choose to compile .py files during
installation, I tried to compile .py files manually after installation
(without compilation) completes.

After finishing installation without compiling .py files, I did the
following command from Windows command prompt.

C:\Python31\python.exe "C:\Python31\Lib\compileall.py" -f -x
bad_coding|badsyntax|site-packages|py2_ "C:\Python31\Lib"

And I got the following error message.
(My Windows is Japanese version.)
'badsyntax' ??????????????????????????????
???? ?????????????????

This means, in English,
'badsyntax' is not recognized as an internal or external command,
operable program or batch file.

So I thought the command would be interpreted correctly if I embrace the
following part of the command with "".

bad_coding|badsyntax|site-packages|py2_

So I did the following from command prompt.

C:\Python31\python.exe "C:\Python31\Lib\compileall.py" -f -x
"bad_coding|badsyntax|site-packages|py2_" "C:\Python31\Lib"

And the compilation seemed to proceed.

However, the log file above (python-3.1.1rc1.log) says the argument is
not embraced with "" when compileall.py script is invoked during
installation process.
I suppose the argument not embraced with "" is one of the reasons why
installation process is interrupted.
Is this a bug of the installer package?

------
Problem 2: UnicodeEncodeError occurs depending on code page.

Compiling .py files seems to proceed by double-quoting the argument
discussed above when manually invoking compileall.py script, but the
following error occurs.

Listing C:\Python31\Lib\lib2to3\tests\data ...
Compiling C:\Python31\Lib\lib2to3\tests\data\crlf.py ...
***   File "C:\Python31\Lib\lib2to3\tests\data\crlf.py", line 1
    print "hi"
             ^
SyntaxError: invalid syntax

Compiling C:\Python31\Lib\lib2to3\tests\data\different_encoding.py ...
*** Traceback (most recent call last):
  File "C:\Python31\Lib\py_compile.py", line 142, in compile
    codeobject = builtins.compile(codestring, dfile or file,'exec')
  File "C:\Python31\Lib\lib2to3\tests\data\different_encoding.py", line 3
    print
u'\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde'
          ^
SyntaxError: invalid syntax

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python31\Lib\compileall.py", line 72, in compile_dir
    ok = py_compile.compile(fullname, None, dfile, True)
  File "C:\Python31\Lib\py_compile.py", line 146, in compile
    raise py_exc
py_compile.PyCompileError:   File
"C:\Python31\Lib\lib2to3\tests\data\different_encoding.py", line 3
    print
u'\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde'
          ^
SyntaxError: invalid syntax


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python31\Lib\compileall.py", line 170, in <module>
    exit_status = int(not main())
  File "C:\Python31\Lib\compileall.py", line 160, in main
    force, rx, quiet):
  File "C:\Python31\Lib\compileall.py", line 97, in compile_dir
    quiet):
  File "C:\Python31\Lib\compileall.py", line 97, in compile_dir
    quiet):
  File "C:\Python31\Lib\compileall.py", line 97, in compile_dir
    quiet):
  File "C:\Python31\Lib\compileall.py", line 80, in compile_dir
    print(err.msg)
UnicodeEncodeError: 'cp932' codec can't encode character '\xdf' in
position 86: illegal multibyte sequence

'cp932' is the default code page of Japanese version of Windows.
So I tried the following command to change the current code page of the
command prompt window to 850 (Latin-1) before running compileall.py
script, aiming to avoid the seemingly code-page specific problem.

chcp 850

By doing so, the UnicodeEncodeError seemed to be avoided as expected.

------
Problem 3: Syntax errors.

After changing the code page to 850, the UnicodeEncodeError doesn't seem
to occur.
However, the syntax errors still occur as follows.

Compiling C:\Python31\Lib\lib2to3\tests\data\crlf.py ...
***   File "C:\Python31\Lib\lib2to3\tests\data\crlf.py", line 1
    print "hi"
             ^
SyntaxError: invalid syntax

Compiling C:\Python31\Lib\lib2to3\tests\data\different_encoding.py ...
***   File "C:\Python31\Lib\lib2to3\tests\data\different_encoding.py",
line 3
    print u'??????????????????????????????????????????????????????????????'
          ^
SyntaxError: invalid syntax

I don't know about how these script files (crlf.py and
different_encoding.py) are used, but isn't it necessary for those lines
of print function to be written like print("hi") because the interpreter
version is 3.x?

----------
components: Installation
messages: 91662
nosy: pds
severity: normal
status: open
title: Windows install error when choosing to compile .py files
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Mon Aug 17 15:09:33 2009
From: report at bugs.python.org (Ryan Tucker)
Date: Mon, 17 Aug 2009 13:09:33 +0000
Subject: [issue5949] IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
In-Reply-To: <1241624741.51.0.445724304481.issue5949@psf.upfronthosting.co.za>
Message-ID: <1250514573.0.0.55263907954.issue5949@psf.upfronthosting.co.za>


Ryan Tucker <ryan at hoopycat.com> added the comment:

I can reproduce this problem with Python 2.6.  It manifests itself as a
lengthy iteration through an IMAP SSL mailbox locking up after a long
while and the interpreter consuming all available system memory.

I suspect this to be the combination of doom:

imaplib.py:
   1166         def readline(self):
   1167             """Read line from remote."""
   1168             line = []
   1169             while 1:
   1170                 char = self.sslobj.read(1)
   1171                 line.append(char)
   1172                 if char == "\n": return ''.join(line)

ssl.py:
    130     def read(self, len=1024):
    131 
    132         """Read up to LEN bytes and return them.
    133         Return zero-length string on EOF."""
    134 
    135         try:
    136             return self._sslobj.read(len)
    137         except SSLError, x:
    138             if x.args[0] == SSL_ERROR_EOF and
self.suppress_ragged_eofs:
    139                 return ''
    140             else:
    141                 raise

After setting suppress_ragged_eofs=False, I now get:

ssl.SSLError: [Errno 8] _ssl.c:1325: EOF occurred in violation of protocol

... instead of an explosion.  This I can trap and handle much more
easily than an infinite loop appending '' to a list on each iteration :-)

I can reliably reproduce this against my gmail mailbox, although it does
take some number of hours.  I am not sure if this would be an imaplib
bug or a ssl bug; I'd think ssl, because it is Not the Python Way to
bury an exception like this.

----------
nosy: +rtucker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5949>
_______________________________________

From report at bugs.python.org  Mon Aug 17 16:16:01 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Mon, 17 Aug 2009 14:16:01 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>


New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:

I suspect that there is some deeper (more severe) issue behind the
problem I describe below. I've observed the following on Windows only.
Didn't try it with different OSs

running dragbug.py shows different behaviour with Python 3.1 compared to
Python 2.6:

Running it with Python 3.1 and performing heavy turtle dragging with the
mouse results in:

Fatal Python error: Cannot recover from stack overflow
This application has requested the Runtime to terminate it in an unusual
way. Please contact the application's support team
-- As I do at the moment ;-) 

Running the same script from Python 2.6: The error is much harder to
reproduce (only with very excessive dragging). It's a bit easier to
reproduce when running the program from a console and  if it occurs one
gets a conventional Python error message:

First a long sequence of:
Exception in Tkinter callback
Traceback (most recent call last):
Exception RuntimeError: 'maximum recursion depth exceeded while .... 
ignored

Followed by:

Traceback (most recent call last):
  File "dragbug.py", line 10, in <module>
    mainloop()
  ....
  File "c:\Python26\lib\traceback.py", line 57, in print_tb
    if hasattr(sys, 'tracebacklimit'):
AttributeError: 'module' object has no attribute 'tracebacklimit'

This problem can be overcome by setting a higher recurson limit. But I
think one should require that it doesn't produce a Fatal Error like in
Python 3.1

Regards,
Gregor

----------
components: Library (Lib)
files: dragbug.py
messages: 91664
nosy: gregorlingl
severity: normal
status: open
title: Some problem with recursion handling
versions: Python 3.1
Added file: http://bugs.python.org/file14738/dragbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:16:01 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Aug 2009 16:16:01 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1250525761.96.0.35254998439.issue6717@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

With py3k trunk on Gentoo Linux after less than a second of flailing the
cursor around on the screen I got:

rdmurray at partner:~/python/py3k>./python dragbug.py 
Fatal Python error: Cannot recover from stack overflow.
zsh: abort      ./python dragbug.py

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:16:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Aug 2009 16:16:44 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1250525804.02.0.235196250596.issue6717@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Tkinter
priority:  -> normal
type:  -> crash
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:48:25 2009
From: report at bugs.python.org (Eric Pope)
Date: Mon, 17 Aug 2009 16:48:25 +0000
Subject: [issue6718] ValueError in 21.17.4.2. SocketServer.UDPServer Example
In-Reply-To: <1250527704.81.0.852484951369.issue6718@psf.upfronthosting.co.za>
Message-ID: <1250527704.81.0.852484951369.issue6718@psf.upfronthosting.co.za>


New submission from Eric Pope <slotterkey_privateer at yahoo.co.jp>:

In the client side example under
21.17.4.2. SocketServer.UDPServer Example:
at: 
http://docs.python.org/dev/library/socketserver.html

<<<<raises ValueError:
HOST, PORT = "localhost"
>>>>should have been:
HOST, PORT = "localhost", 9999

----------
assignee: georg.brandl
components: Documentation
messages: 91666
nosy: ericpope, georg.brandl
severity: normal
status: open
title: ValueError in 21.17.4.2. SocketServer.UDPServer Example
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6718>
_______________________________________

From report at bugs.python.org  Mon Aug 17 18:50:11 2009
From: report at bugs.python.org (samuel de framond)
Date: Mon, 17 Aug 2009 16:50:11 +0000
Subject: [issue6719] pdb messes up when debugging an non-ascii program
In-Reply-To: <1250527811.0.0.14372124674.issue6719@psf.upfronthosting.co.za>
Message-ID: <1250527811.0.0.14372124674.issue6719@psf.upfronthosting.co.za>


New submission from samuel de framond <samuel43 at laposte.net>:

consider a program like this one:

---- File: ./test.py ----
#/usr/bin/env python
#coding: utf8

print 'qwerty'
-------------------------

Here is a shell (e.g. bash) session:

$ python -m pdb ./test.py
--Return--
> /usr/lib/python2.6/encodings/__init__.py(69)normalize_encoding()->'latin1'
-> return '_'.join(encoding.translate(_norm_encoding_map).split())
(Pdb) 

While for a file without the line #2, the output would be:

$ python -m pdb ./test.py
> /home/.../test.py(3)<module>()
-> print 'qwerty'
(Pdb) 

Here is the thing: the normal behaviour of pdb in this case is to pause
before executing the first line of the program. Instead of this, it
pauses at line #69 in .../encodings/__init__.py, which makes pdb almost
unusable.
Plus, pdb's inline command "q" (or "quit") does not work anymore. Here,
the first line should close the program but it does not:

(Pdb) q
Traceback (most recent call last):
  File "/usr/lib/python2.6/pdb.py", line 1283, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib/python2.6/pdb.py", line 1202, in _runscript
    self.run(statement)
  File "/usr/lib/python2.6/bdb.py", line 368, in run
    exec cmd in globals, locals
  File "<string>", line 1, in <module>
  File "./test.py", line 2
 SyntaxError: encoding problem: with BOM (test.py, line 2)
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) 

if 'q' is types a second time in a row, it goes like this and we are
back to starting point:

(Pdb) q
Post mortem debugger finished. The ./test.py will be restarted
--Return--
> /usr/lib/python2.6/encodings/__init__.py(69)normalize_encoding()->'latin1'
-> return '_'.join(encoding.translate(_norm_encoding_map).split())
(Pdb)

----------
components: Library (Lib)
messages: 91667
nosy: smu
severity: normal
status: open
title: pdb messes up when debugging an non-ascii program
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6719>
_______________________________________

From report at bugs.python.org  Mon Aug 17 21:28:12 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Aug 2009 19:28:12 +0000
Subject: [issue6685] CGI module documentation references method 'toupper';
	should be 'upper'
In-Reply-To: <1250013397.33.0.441269604909.issue6685@psf.upfronthosting.co.za>
Message-ID: <1250537292.91.0.381016482064.issue6685@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed in r74492.  Thanks.

----------
assignee: georg.brandl -> r.david.murray
nosy: +r.david.murray
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: feature request -> behavior
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6685>
_______________________________________

From report at bugs.python.org  Mon Aug 17 22:13:12 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 17 Aug 2009 20:13:12 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1250539992.87.0.546479937319.issue1023290@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here's a new patch incorporating the suggestions I received on python-ideas.

Notable changes are:

  - The name of the methods have been changed to int.tobytes() and
    int.frombytes().
  - The tri-state `little_endian' argument has been removed in favor
    of the `byteorder' argument which takes either the string
    'little' or 'big'.
  - The `byteorder' argument has to be specified explicitly.
  - The variable-length version of int.tobytes() has been removed.
  - The `fixed_length' argument has been renamed to `length'. 
  - The `signed' argument is now keyword-only and now defaults to False.

----------
assignee:  -> alexandre.vassalotti
components: +Interpreter Core
stage:  -> patch review
title: proposed struct module format code addition -> Conversion of longs to bytes and vice-versa.
versions: +Python 3.2
Added file: http://bugs.python.org/file14739/long_and_bytes_conversion-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Mon Aug 17 22:23:21 2009
From: report at bugs.python.org (Benjamin Liles)
Date: Mon, 17 Aug 2009 20:23:21 +0000
Subject: [issue6720] multiprocessing logging
In-Reply-To: <1250540601.66.0.070668154898.issue6720@psf.upfronthosting.co.za>
Message-ID: <1250540601.66.0.070668154898.issue6720@psf.upfronthosting.co.za>


New submission from Benjamin Liles <benliles at gmail.com>:

In the backport package of the multiprocessing library. A bug was
introduced in version 2.6.2.1 when the logging module was modified. If
you use logging in the backport, you get the following:

Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/__init__.py",
line 744, in emit
    msg = self.format(record)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/__init__.py",
line 630, in format
    return fmt.format(record)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/logging/__init__.py",
line 421, in format
    s = self._fmt % record.__dict__
KeyError: 'processName'

----------
components: Library (Lib)
messages: 91670
nosy: benliles
severity: normal
status: open
title: multiprocessing logging
type: crash
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6720>
_______________________________________

From report at bugs.python.org  Mon Aug 17 22:29:52 2009
From: report at bugs.python.org (Alex Willmer)
Date: Mon, 17 Aug 2009 20:29:52 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1250540992.88.0.0286912305062.issue2636@psf.upfronthosting.co.za>


Alex Willmer <alex at moreati.org.uk> added the comment:

Matthew's 20080915.zip attachment is now on PyPI. This one, having a
more complete MANIFEST, will build for people other than me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Aug 17 22:46:53 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 17 Aug 2009 20:46:53 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1250542013.59.0.121963398368.issue1023290@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Before this gets applied, a (preferably final) decision should be made
whether it should be provided for 2.7 as well. Personally, it would be
fine with me either way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Mon Aug 17 23:02:06 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Aug 2009 21:02:06 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
In-Reply-To: <1250539992.87.0.546479937319.issue1023290@psf.upfronthosting.co.za>
Message-ID: <1250543111.6330.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Alexandre:

> Notable changes are:
> 
>   - The name of the methods have been changed to int.tobytes() and
>     int.frombytes().

Without wanting to bikeshed, I think these methods should take
underscores as other int methods already do. This kind of
inconsistencies is really annoying (have you ever used PHP? :-)).

Martin:

> Before this gets applied, a (preferably final) decision should be made
> whether it should be provided for 2.7 as well. Personally, it would be
> fine with me either way.

I'm also fine with adding it to 2.7 as well. But someone has to provide
a patch (2.7 still has both `int` and `long`, which will make the task a
bit more involved than a straight backport).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Tue Aug 18 01:06:19 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 17 Aug 2009 23:06:19 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

The python logging module uses a lock to surround many operations, in 
particular.  This causes deadlocks in programs that use logging, fork 
and threading simultaneously.

1) spawn one or more threads in your program
2) have at least one of those threads make logging calls that will be 
emitted.
3) have your main thread or another thread use os.fork() to run some 
python code in a child process.
4) If the fork happened while one of your threads was within the 
logging.Handler.handle() critical section (or anywhere else where 
handler.lock is acquired), your child process will deadlock as soon as 
it tries to log anything.  It inherited a held lock.

The deadlock is more likely to happen on a highly loaded system which 
tends to widen the deadlock opportunity window due to context switching.

A demo of the problem simplified into one file is attached.

The Python standard library should not be the cause of these deadlocks.  
We need a way for all standard library locks to be cleaned up when 
forking.  By doing one of the following:

A) acquire all locks before forking, release them immediately after.
B) forceably release all standard library locks after forking in the 
child process.

Code was added to call some cleanups after forking in 
http://bugs.python.org/issue874900 but there are more things that also 
need this same sort of cleanup (logging for example).

Rather than having to manually add after fork code hooks into every file 
in the standard library that uses locks, a more general solution to 
track and manage locks across fork would be a good idea.

----------
assignee: gregory.p.smith
files: lock_fork_thread_deadlock_demo.py
messages: 91674
nosy: gregory.p.smith
priority: high
severity: normal
status: open
title: Locks in python standard library should be sanitized on fork
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14740/lock_fork_thread_deadlock_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Aug 18 03:10:14 2009
From: report at bugs.python.org (Ionut Turturica)
Date: Tue, 18 Aug 2009 01:10:14 +0000
Subject: [issue1550273] Fix numerous bugs in unittest
Message-ID: <1250557814.76.0.115210711633.issue1550273@psf.upfronthosting.co.za>


Ionut Turturica <jonozzz at yahoo.com> added the comment:

I am a little bit concerned with the new __eq__:

    def __eq__(self, other):
        if type(self) is not type(other):
            return False
        return self._tests == other._tests

Why did you use "self._tests == other._tests" instead of "self is other" ?

After I upgraded to 2.6 I started to have some issues with a breadth
first iterator for a TestSuite and I tracked them down to this eq method.

----------
nosy: +jonozzz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1550273>
_______________________________________

From report at bugs.python.org  Tue Aug 18 03:32:59 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2009 01:32:59 +0000
Subject: [issue1550273] Fix numerous bugs in unittest
Message-ID: <1250559179.76.0.363046675429.issue1550273@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

At a guess, because equality is not the same as identity.  (If identity
was the requirement for equality for this class, the method body would
_just_ be self is other).

You should open a new bug report explaining the problem you are seeing
in more detail, with a reference to this one in the body of your message.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1550273>
_______________________________________

From report at bugs.python.org  Tue Aug 18 04:03:12 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2009 02:03:12 +0000
Subject: [issue6683] smtplib authentication - try all mechanisms
In-Reply-To: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>
Message-ID: <1250560992.49.0.941576636057.issue6683@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +easy
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6683>
_______________________________________

From report at bugs.python.org  Tue Aug 18 05:24:30 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Tue, 18 Aug 2009 03:24:30 +0000
Subject: [issue6463] IDLE with Tk-Cocoa: Edit, format menus hang
In-Reply-To: <1247337114.05.0.431997282863.issue6463@psf.upfronthosting.co.za>
Message-ID: <1250565870.43.0.0443780525699.issue6463@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Following active development and several bugfixes in Tk-Cocoa 8.5.7, the 
issue with the cut/paste events in IDLE's edit menu has resolved itself. 
Therefore I am closing this bug.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6463>
_______________________________________

From report at bugs.python.org  Tue Aug 18 07:25:05 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 18 Aug 2009 05:25:05 +0000
Subject: [issue6720] multiprocessing logging
In-Reply-To: <1250540601.66.0.070668154898.issue6720@psf.upfronthosting.co.za>
Message-ID: <1250573105.34.0.380650156888.issue6720@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6720>
_______________________________________

From report at bugs.python.org  Tue Aug 18 07:26:10 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 18 Aug 2009 05:26:10 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1250573170.44.0.396078508603.issue6444@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Marked as pending, as there has been no activity for a while. Will close
if there is no followup.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Tue Aug 18 11:29:43 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Tue, 18 Aug 2009 09:29:43 +0000
Subject: [issue6648] codecs documentation does not mention surrogateescape
In-Reply-To: <1249487329.19.0.991009276368.issue6648@psf.upfronthosting.co.za>
Message-ID: <1250587783.12.0.71105398709.issue6648@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

Georg, it would also be nice to give a link to 'surrogateescape'
information in os module [1]. Yes, you gave a link to PEP 383, but PEP
harder to follow and more lengthy.

[1]:
http://docs.python.org/3.1/library/os.html#file-names-command-line-arguments-and-environment-variables

----------
nosy: +ash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6648>
_______________________________________

From report at bugs.python.org  Tue Aug 18 12:38:45 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Tue, 18 Aug 2009 10:38:45 +0000
Subject: [issue6722] collections.namedtuple: confusing example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>


New submission from Alexey Shamrin <shamrin at gmail.com>:

Maybe it's just me, but it took me several attempts  to understand
namedtuple example in the documentation [1]. The problem is that the
first example uses verbose=True. It's very unusual to get Python source
as the output in Python shell. At first I thought there's some syntax
error in documentation source.

I know that several lines above one can read: "If verbose is true, the
class definition is printed just before being built." But during first
several attempts to understand namedtuple, I skipped it and directly
scrolled to the first example.

I think the first example on namedtuple usage shouldn't use verbose=True.

You could argue I had to try using namedtuple inside Python shell. I
agree. But unfortunately Python 2.6 was not installed on the computer I
was at.

[1]: http://docs.python.org/library/collections.html#collections.namedtuple

----------
assignee: georg.brandl
components: Documentation
messages: 91680
nosy: ash, georg.brandl
severity: normal
status: open
title: collections.namedtuple: confusing example
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6722>
_______________________________________

From jeremy at alum.mit.edu  Tue Aug 18 13:32:19 2009
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue, 18 Aug 2009 07:32:19 -0400
Subject: [issue3566] httplib persistent connections violate MUST in 
	RFC2616 sec 8.1.4.
In-Reply-To: <1250461498.96.0.307334525566.issue3566@psf.upfronthosting.co.za>
References: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
	<1250461498.96.0.307334525566.issue3566@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530908180432h11d91558k62d053da3d787dd8@mail.gmail.com>

Not that we've removed the try one more time branch of the code,
because it was causing other problems.

Jeremy

On Sun, Aug 16, 2009 at 6:24 PM, Gregory P. Smith<report at bugs.python.org> wrote:
>
> Gregory P. Smith <greg at krypto.org> added the comment:
>
> btw, when using async io (poll, select, etc) I -think- your socket will
> see a read event when the server closes the connection (sends you a FIN
> or even a RST) at which point your sock.recv() when you've been told
> data was ready will return 0 bytes indicating that the server has closed
> the connection.
>
> I like your MSG_PEEK hack here. ?I'll figure out if this or something
> else should go into (the giant mess that is) httplib.
>
> ----------
> priority: ?-> normal
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3566>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From report at bugs.python.org  Tue Aug 18 13:32:25 2009
From: report at bugs.python.org (Jeremy Hylton)
Date: Tue, 18 Aug 2009 11:32:25 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1250461498.96.0.307334525566.issue3566@psf.upfronthosting.co.za>
Message-ID: <e8bf7a530908180432h11d91558k62d053da3d787dd8@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

Not that we've removed the try one more time branch of the code,
because it was causing other problems.

Jeremy

On Sun, Aug 16, 2009 at 6:24 PM, Gregory P. Smith<report at bugs.python.org> wrote:
>
> Gregory P. Smith <greg at krypto.org> added the comment:
>
> btw, when using async io (poll, select, etc) I -think- your socket will
> see a read event when the server closes the connection (sends you a FIN
> or even a RST) at which point your sock.recv() when you've been told
> data was ready will return 0 bytes indicating that the server has closed
> the connection.
>
> I like your MSG_PEEK hack here. ?I'll figure out if this or something
> else should go into (the giant mess that is) httplib.
>
> ----------
> priority: ?-> normal
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue3566>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

----------
nosy: +jhylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:38:34 2009
From: report at bugs.python.org (Nicolas Goutte)
Date: Tue, 18 Aug 2009 12:38:34 +0000
Subject: [issue6723] csv.writer: example does not work
In-Reply-To: <1250599114.63.0.456902579657.issue6723@psf.upfronthosting.co.za>
Message-ID: <1250599114.63.0.456902579657.issue6723@psf.upfronthosting.co.za>


New submission from Nicolas Goutte <nicolas.goutte at extragroup.de>:

In the documentation for csv.writer, the example
spamWriter = csv.writer(open('eggs.csv', 'w'), delimiter=' ',
quotechar='|', quoting=QUOTE_MINIMAL)
does not work, as Python complains about "SyntaxError: invalid syntax",
as QUOTE_MINIMAL is not a global identifier.

By replacing QUOTE_MINIMAL by csv.QUOTE_MINIMAL there is no syntax error
anymore.

I have discovered the issue with python 2.6.2. All online documentation
version (2.6, 2.7, 3.1, 3.2) seem to have the same documentation (e.g.
http://docs.python.org/library/csv.html )

----------
assignee: georg.brandl
components: Documentation
messages: 91682
nosy: georg.brandl, nicolasg
severity: normal
status: open
title: csv.writer: example does not work
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6723>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:42:17 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2009 12:42:17 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1250599337.38.0.543588658927.issue4879@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

And that update causes failures in test_xmlrpc.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:43:52 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2009 12:43:52 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1250599432.55.0.621614394.issue4879@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
stage:  -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:47:39 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2009 12:47:39 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1250599659.7.0.267258105884.issue4879@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think I'll open a new ticket instead.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:49:44 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2009 12:49:44 +0000
Subject: [issue6724] r74463 causes failures in test_xmlrpc
In-Reply-To: <1250599784.86.0.0936114935604.issue6724@psf.upfronthosting.co.za>
Message-ID: <1250599784.86.0.0936114935604.issue6724@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The title says it all.

----------
assignee: gregory.p.smith
components: Library (Lib), Tests
messages: 91685
nosy: gregory.p.smith, r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: r74463 causes failures in test_xmlrpc
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6724>
_______________________________________

From report at bugs.python.org  Tue Aug 18 14:53:48 2009
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 18 Aug 2009 12:53:48 +0000
Subject: [issue6720] multiprocessing logging
In-Reply-To: <1250540601.66.0.070668154898.issue6720@psf.upfronthosting.co.za>
Message-ID: <1250600028.1.0.272953019224.issue6720@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Christian is managing the back port.

----------
assignee: jnoller -> christian.heimes
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6720>
_______________________________________

From report at bugs.python.org  Tue Aug 18 15:23:34 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 13:23:34 +0000
Subject: [issue1119673] ScrolledText allows Frame.bbox to hide Text.bbox
Message-ID: <1250601814.58.0.657916577277.issue1119673@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This has been fixed on r74507 now.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1119673>
_______________________________________

From report at bugs.python.org  Tue Aug 18 15:29:40 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 13:29:40 +0000
Subject: [issue1250469] Tix: PanedWindow.panes nonfunctional
Message-ID: <1250602180.49.0.0475842346485.issue1250469@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Fix has been committed on r74508.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1250469>
_______________________________________

From report at bugs.python.org  Tue Aug 18 15:33:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 13:33:50 +0000
Subject: [issue1259434] Tix CheckList 'radio' option cannot be changed
Message-ID: <1250602430.47.0.151618364548.issue1259434@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Committed on r74509.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1259434>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:35:17 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 14:35:17 +0000
Subject: [issue1522587] Tix.Grid patch
Message-ID: <1250606117.16.0.800038578325.issue1522587@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

New constants and methods have been commited on r74510. I've added only
the tix commands that are actually supported by tix.

The fixes for some of the methods have been committed on r74511.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1522587>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:41:11 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 18 Aug 2009 14:41:11 +0000
Subject: [issue6723] csv.writer: example does not work
In-Reply-To: <1250599114.63.0.456902579657.issue6723@psf.upfronthosting.co.za>
Message-ID: <1250606471.15.0.899959005331.issue6723@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Thanks for the report.  Fixed for 2.6, 2.7, 3.0, 3.2. Can't seem to check
out a 3.1 branch (tried release31-maint but was rebuffed by svn).

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6723>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:43:20 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Aug 2009 14:43:20 +0000
Subject: [issue6722] collections.namedtuple: confusing example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1250606600.46.0.815760175922.issue6722@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It seems that it is the API you don't like, not the example.

What is your suggested improvement to the docs?

----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6722>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:43:59 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 18 Aug 2009 14:43:59 +0000
Subject: [issue6723] csv.writer: example does not work
In-Reply-To: <1250599114.63.0.456902579657.issue6723@psf.upfronthosting.co.za>
Message-ID: <1250606639.57.0.812548096722.issue6723@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

figured out my checkout problem.  will have 3.1 fixed shortly.

----------
assignee: georg.brandl -> skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6723>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:47:25 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 18 Aug 2009 14:47:25 +0000
Subject: [issue6723] csv.writer: example does not work
In-Reply-To: <1250599114.63.0.456902579657.issue6723@psf.upfronthosting.co.za>
Message-ID: <1250606845.78.0.765290193883.issue6723@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

3.1 corrected as well.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6723>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:47:26 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 14:47:26 +0000
Subject: [issue1356969] Tix.py class HList missing info_bbox,
	info_dragsite and info_dropsite
Message-ID: <1250606846.92.0.535370652875.issue1356969@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Committed on r74517.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1356969>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:48:10 2009
From: report at bugs.python.org (CarGuy37)
Date: Tue, 18 Aug 2009 14:48:10 +0000
Subject: [issue6725] Inconsistency in Documentation: "Name Spaces" vs
	"Namespaces"
In-Reply-To: <1250606890.78.0.538914735097.issue6725@psf.upfronthosting.co.za>
Message-ID: <1250606890.78.0.538914735097.issue6725@psf.upfronthosting.co.za>


New submission from CarGuy37 <tom.macleod at analog.com>:

Why is there an inconsistency in the usage of "Name Spaces" vs "Namespaces"?

After "import this", Python returns "...Namespaces are ..."

I would suggest conjoining the two words and being consistent (9.2 Title
and beginning sentence of the 6th paragraph thereof).

----------
assignee: georg.brandl
components: Documentation
messages: 91696
nosy: CarGuy37, georg.brandl
severity: normal
status: open
title: Inconsistency in Documentation: "Name Spaces" vs "Namespaces"
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6725>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:58:40 2009
From: report at bugs.python.org (Marcin)
Date: Tue, 18 Aug 2009 14:58:40 +0000
Subject: [issue6726] pyuic4.bat has bad path to python.exe and pyuic.py
In-Reply-To: <1250607520.51.0.355882528054.issue6726@psf.upfronthosting.co.za>
Message-ID: <1250607520.51.0.355882528054.issue6726@psf.upfronthosting.co.za>


New submission from Marcin <maar.cz at gmail.com>:

I have found bug in pyuic4.bat. I have installed python to directory
c:\programs. The path to 'python.exe' is c:\programs\python.exe. Content
of file pyuic4.bat is:

@"C:\Python25\python.exe"
"C:\Python25\Lib\site-packages\PyQt4\uic\pyuic.py" %1 %2 %3 %4 %5 %6 %7
%8 %9

In this file, during installation process it must be changed path to
python.exe.

In my example it must be done like that:

@"C:\programs\Python25\python.exe"
"C:\programs\Python25\Lib\site-packages\PyQt4\uic\pyuic.py" %1 %2 %3 %4
%5 %6 %7 %8 %9

----------
components: Demos and Tools
messages: 91697
nosy: maar
severity: normal
status: open
title: pyuic4.bat has bad path to python.exe and pyuic.py
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6726>
_______________________________________

From report at bugs.python.org  Tue Aug 18 16:58:53 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 14:58:53 +0000
Subject: [issue5961] Missing labelside option for Tix option menu (fix
	included)
In-Reply-To: <1241721915.71.0.611768472614.issue5961@psf.upfronthosting.co.za>
Message-ID: <1250607533.56.0.277222015844.issue5961@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Hi Cary,

Where can I find the most up-to-date Tix manual ? Would it be
http://tix.sourceforge.net/man/html/contents.htm ?

I don't know much about Tix so maybe you can help me a bit here. Are all
of these widget specific options considered as static options by Tix ?
If so, shouldn't "command", "disablecallback", "label", "state", "value"
and "variable" be added here as well ?

----------
nosy: +gpolo
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5961>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:13:03 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 18 Aug 2009 15:13:03 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Python reports an import error, even when a valid package exists on
sys.path, if that package is a symlink directory and would otherwise be
importable.

The attached test script demonstrates the limitation on Python 2.6.2 and
3.1.0.

I suspect that the underlying import routines have some assumptions
about the file system that exclude symlinked directories.

----------
components: Interpreter Core, Windows
files: test_import_symlink_package.py
messages: 91699
nosy: jaraco
severity: normal
status: open
title: ImportError when package is symlinked on Windows
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14741/test_import_symlink_package.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:15:53 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 18 Aug 2009 15:15:53 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1250608553.45.0.944099039091.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Can this fix be considered for inclusion in 3.1.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:36:44 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 15:36:44 +0000
Subject: [issue1119673] ScrolledText allows Frame.bbox to hide Text.bbox
Message-ID: <1250609804.81.0.396559996648.issue1119673@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1119673>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:36:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 15:36:50 +0000
Subject: [issue1119673] ScrolledText allows Frame.bbox to hide Text.bbox
In-Reply-To: <1250601814.58.0.657916577277.issue1119673@psf.upfronthosting.co.za>
Message-ID: <ac2200130908180836n72576085ob6b0b23e66a8e1ee@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> This has been fixed on r74507 now.

py3k branch: r74518.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1119673>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:37:06 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 15:37:06 +0000
Subject: [issue1250469] Tix: PanedWindow.panes nonfunctional
Message-ID: <1250609826.84.0.355167634552.issue1250469@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

py3k branch: r74518.

----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1250469>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:37:25 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 15:37:25 +0000
Subject: [issue1259434] Tix CheckList 'radio' option cannot be changed
Message-ID: <1250609845.25.0.255124070023.issue1259434@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

py3k branch: r74518.

----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1259434>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:37:47 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 15:37:47 +0000
Subject: [issue1356969] Tix.py class HList missing info_bbox,
	info_dragsite and info_dropsite
Message-ID: <1250609867.81.0.789069195508.issue1356969@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

py3k branch: r74518.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1356969>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:37:50 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 15:37:50 +0000
Subject: [issue1356969] Tix.py class HList missing info_bbox,
	info_dragsite and info_dropsite
Message-ID: <1250609870.01.0.761754474071.issue1356969@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

py3k branch: r74518.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1356969>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:38:07 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 15:38:07 +0000
Subject: [issue1522587] Tix.Grid patch
Message-ID: <1250609887.35.0.160076705039.issue1522587@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

py3k branch: r74518.

----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1522587>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:38:49 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 15:38:49 +0000
Subject: [issue1356969] Tix.py class HList missing info_bbox,
	info_dragsite and info_dropsite
Message-ID: <1250609929.65.0.819416527468.issue1356969@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1356969>
_______________________________________

From report at bugs.python.org  Tue Aug 18 17:58:08 2009
From: report at bugs.python.org (Yang)
Date: Tue, 18 Aug 2009 15:58:08 +0000
Subject: [issue6728] To avoid hang up in using CGIXMLRPCRequestHandler under
	IIS 7.x
In-Reply-To: <1250611088.83.0.579376687228.issue6728@psf.upfronthosting.co.za>
Message-ID: <1250611088.83.0.579376687228.issue6728@psf.upfronthosting.co.za>


New submission from Yang <student at live.cn>:

The mismatched content length will cause hang up in sys.stdin.read(). 
The reason is probably described in Issue 1214 as well as 1725295.

length = int(os.environ.get('CONTENT_LENGTH', None))
"""Length fix for IIS 7.x to avoid hang up"""
length=length-2

I would appreciate if someone can create a diff or patch file for the 
code above.

----------
components: Library (Lib)
messages: 91707
nosy: sjtuer
severity: normal
status: open
title: To avoid hang up in using CGIXMLRPCRequestHandler under IIS 7.x
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6728>
_______________________________________

From report at bugs.python.org  Tue Aug 18 18:26:37 2009
From: report at bugs.python.org (Cary R.)
Date: Tue, 18 Aug 2009 16:26:37 +0000
Subject: [issue5961] Missing labelside option for Tix option menu (fix
	included)
In-Reply-To: <1241721915.71.0.611768472614.issue5961@psf.upfronthosting.co.za>
Message-ID: <1250612797.5.0.0323144523792.issue5961@psf.upfronthosting.co.za>


Cary R. <cygcary at yahoo.com> added the comment:

That is the manual I am referencing and the last time I looked it was
the most recent.

I'm not to familiar with the Python port of Tix, but I am using the
command, label, state, and variable options and they already work fine.
I could try the other options if that would help.

I needed the labelside functionality so I hacked Tix.py to get it to
work. I mimicked the code from other objects that have a labelside
option. My assumption was that some base class knew how to handle many
of the standard options, but did not know about labelside. It is
possible that there is a better way to handle this (add it to the same
place the others are implemented), but that would have required
understanding the class hierarchy and much more work. At the time I just
needed to get it to work and what I proposed does work and is consistent
with other objects. Since I was not using the other options I did not
check them.

Let me know if there is anything else I can do to help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5961>
_______________________________________

From report at bugs.python.org  Tue Aug 18 18:42:11 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 16:42:11 +0000
Subject: [issue5961] Missing labelside option for Tix option menu (fix
	included)
In-Reply-To: <1250612797.5.0.0323144523792.issue5961@psf.upfronthosting.co.za>
Message-ID: <ac2200130908180941n45abd374xc14796be0b5d630a@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> That is the manual I am referencing and the last time I looked it was
> the most recent.
>

Thanks for clarifying that.

> I'm not to familiar with the Python port of Tix, but I am using the
> command, label, state, and variable options and they already work fine.
> I could try the other options if that would help.
>

Now I see, it is a problem in the Tix manual. Some commands around
there document which options are static and which are not. For
OptionMenu, 'labelside' is an static option but is not described as
such.

Fixed on r74519.

> I needed the labelside functionality so I hacked Tix.py to get it to
> work. I mimicked the code from other objects that have a labelside
> option. My assumption was that some base class knew how to handle many
> of the standard options, but did not know about labelside. It is
> possible that there is a better way to handle this (add it to the same
> place the others are implemented), but that would have required
> understanding the class hierarchy and much more work. At the time I just
> needed to get it to work and what I proposed does work and is consistent
> with other objects. Since I was not using the other options I did not
> check them.
>
> Let me know if there is anything else I can do to help.

It looks like Tix.py might need a review on this area of static
options. Tix's documentation doesn't help much, so it will require
some manual testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5961>
_______________________________________

From report at bugs.python.org  Tue Aug 18 18:42:38 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 18 Aug 2009 16:42:38 +0000
Subject: [issue5961] Missing labelside option for Tix option menu (fix
	included)
In-Reply-To: <1241721915.71.0.611768472614.issue5961@psf.upfronthosting.co.za>
Message-ID: <1250613758.04.0.128067923579.issue5961@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed
type: feature request -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5961>
_______________________________________

From report at bugs.python.org  Tue Aug 18 19:47:47 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Aug 2009 17:47:47 +0000
Subject: [issue6726] pyuic4.bat has bad path to python.exe and pyuic.py
In-Reply-To: <1250607520.51.0.355882528054.issue6726@psf.upfronthosting.co.za>
Message-ID: <1250617667.67.0.0751622257864.issue6726@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please report this to the _PyQt_ maintainers.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6726>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:58:23 2009
From: report at bugs.python.org (Timothy Farrell)
Date: Tue, 18 Aug 2009 18:58:23 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1250621903.32.0.183117804169.issue4953@psf.upfronthosting.co.za>


Timothy Farrell <tfarrell at swgen.com> added the comment:

I thought I'd take a crack at this today.  I soon figured out the real
issue.  It is the email.parser module that handles the decoding of
Multipart/form-data things...and it is also still quote broken w.r.t.
handling Bytes.  So this issue is dependent on
http://bugs.python.org/issue4661 before it can be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Tue Aug 18 20:59:09 2009
From: report at bugs.python.org (Timothy Farrell)
Date: Tue, 18 Aug 2009 18:59:09 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1250621949.43.0.391881777421.issue4661@psf.upfronthosting.co.za>


Changes by Timothy Farrell <tfarrell at swgen.com>:


----------
nosy: +tercero12

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Tue Aug 18 21:48:31 2009
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 18 Aug 2009 19:48:31 +0000
Subject: [issue6724] r74463 causes failures in test_xmlrpc
In-Reply-To: <1250599784.86.0.0936114935604.issue6724@psf.upfronthosting.co.za>
Message-ID: <1250624911.1.0.854243034671.issue6724@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

David, care to just revert r74463? If it breaks tests should be reverted 
until it can be fixed by whomever made the commit.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6724>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:16:41 2009
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 18 Aug 2009 20:16:41 +0000
Subject: [issue6729] Add support for ssize_t
In-Reply-To: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>
Message-ID: <1250626601.03.0.294570676817.issue6729@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

ctypes currently has a datatype c_size_t which corresponds to size_t in
C, but there is no datatype for the C ssize_t.

----------
assignee: theller
components: ctypes
messages: 91713
nosy: Nikratio, theller
severity: normal
status: open
title: Add support for ssize_t
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6729>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:28:55 2009
From: report at bugs.python.org (Maxime Lemonnier)
Date: Tue, 18 Aug 2009 20:28:55 +0000
Subject: [issue6730] dict.fromkeys() should not cross reference mutable value
	by default
In-Reply-To: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>
Message-ID: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>


New submission from Maxime Lemonnier <maxime.lemonnier at gmail.com>:

Consider the following code sample :

keys = ['x', 'y', 'z']
d = dict.fromkeys(keys, [])
d['x'].append('dont')
d['y'].append('mix')
d['z'].append('me!')
print d['x']

>>> ['dont', 'mix', 'me!']

It is very unatural and dangerous to have all dict keys poining to the
same mutable object reference. 

The way it should behave : 
if value is mutable, create a new copy of value for each keys
else, it doesn't matter

----------
components: Interpreter Core
messages: 91714
nosy: maxlem
severity: normal
status: open
title: dict.fromkeys() should not cross reference mutable value by default
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6730>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:34:51 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 18 Aug 2009 20:34:51 +0000
Subject: [issue6730] dict.fromkeys() should not cross reference mutable value
	by default
In-Reply-To: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>
Message-ID: <1250627691.87.0.0175506456056.issue6730@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This behavior will never change. Use collections.defaultdict for your case.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6730>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:48:04 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Aug 2009 20:48:04 +0000
Subject: [issue6730] dict.fromkeys() should not cross reference mutable value
	by default
In-Reply-To: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>
Message-ID: <1250628484.46.0.181833614631.issue6730@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6730>
_______________________________________

From report at bugs.python.org  Tue Aug 18 22:53:02 2009
From: report at bugs.python.org (Maxime Lemonnier)
Date: Tue, 18 Aug 2009 20:53:02 +0000
Subject: [issue6730] dict.fromkeys() should not cross reference mutable value
	by default
In-Reply-To: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>
Message-ID: <1250628782.18.0.231422804744.issue6730@psf.upfronthosting.co.za>


Maxime Lemonnier <maxime.lemonnier at gmail.com> added the comment:

It does not suits my needs.

what if keys are passed as an argument?

I have to add this ugly loop :

for key in keys:
    d[key] = [] 
    

I really think that :
1) The doc should warn about it, since it is a very weird behaviour
2) There could at least be a third argument allowing the user to choose,
with a default value that maintains the current behaviour (for
compatibility, even though I think the default should be a deep copy)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6730>
_______________________________________

From report at bugs.python.org  Tue Aug 18 23:13:40 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Aug 2009 21:13:40 +0000
Subject: [issue6730] dict.fromkeys() should not cross reference mutable value
	by default
In-Reply-To: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>
Message-ID: <1250630020.96.0.328222983381.issue6730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The docs very clearly say the second argument is the value that will be
assigned to the keys.  It doesn't matter whether or not that object is
mutable, it is that object that gets assigned.  This is just the way
that Python works:

>>> a = b = []
>>> a.append(1)
>>> b.append(2)
>>> a
[1, 2]

That is exactly analogous to what you are doing in your example.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6730>
_______________________________________

From report at bugs.python.org  Wed Aug 19 00:25:22 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 18 Aug 2009 22:25:22 +0000
Subject: [issue6731] Non-zero exit status of setup.py when building of
	extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

sharedmods rule of Makefile calls setup.py which doesn't fail even
building of extensions has failed.

----------
components: Build
files: python-non-zero_exit_status_on_failure.patch
keywords: patch
messages: 91719
nosy: Arfrever
severity: normal
status: open
title: Non-zero exit status of setup.py when building of extensions has failed
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14742/python-non-zero_exit_status_on_failure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 01:02:50 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 18 Aug 2009 23:02:50 +0000
Subject: [issue5528] Unable to launch IDLE on Windows
In-Reply-To: <1237588418.03.0.370218080743.issue5528@psf.upfronthosting.co.za>
Message-ID: <1250636570.27.0.741534911972.issue5528@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5528>
_______________________________________

From report at bugs.python.org  Wed Aug 19 01:48:29 2009
From: report at bugs.python.org (KAJIYAMA, Tamito)
Date: Tue, 18 Aug 2009 23:48:29 +0000
Subject: [issue6732] PyInit_shoddy() in shoddy.c does not return anything on
	success
In-Reply-To: <1250639309.85.0.383557872806.issue6732@psf.upfronthosting.co.za>
Message-ID: <1250639309.85.0.383557872806.issue6732@psf.upfronthosting.co.za>


New submission from KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>:

Section 2.1.4, "Subclassing other types", of "Extending and Embedding 
the Python Interpreter" (Release: 3.1, Date: June 26, 2009) has a 
complete list of shoddy.c, in which PyInit_shoddy() does not have a 
return statement at the end to return a pointer to the created "shoddy" 
module on success.  Simply adding the missing "return m;" statement 
would be fine.

----------
assignee: georg.brandl
components: Documentation
messages: 91720
nosy: georg.brandl, kajiyama
severity: normal
status: open
title: PyInit_shoddy() in shoddy.c does not return anything on success
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6732>
_______________________________________

From report at bugs.python.org  Wed Aug 19 02:43:22 2009
From: report at bugs.python.org (fugounashi)
Date: Wed, 19 Aug 2009 00:43:22 +0000
Subject: [issue6733] curses line wrap broken when mixing full- and half-width
	unicode characters
In-Reply-To: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>
Message-ID: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>


New submission from fugounashi <fugounashi+python at gmail.com>:

when printing a full width unicode character near the end of a line when
only a single (half-width) space remains, the character is printed at
the start of the current line rather than the start of the next line. 
the following character is printed in the following space on the next
line as it should be.  same behaviour in both mlterm and xterm

thanks!

python deb 2.5.2-3

----------
messages: 91721
nosy: fugounashi
severity: normal
status: open
title: curses line wrap broken when mixing full- and half-width unicode characters
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6733>
_______________________________________

From report at bugs.python.org  Wed Aug 19 06:25:12 2009
From: report at bugs.python.org (pds)
Date: Wed, 19 Aug 2009 04:25:12 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1250655912.94.0.430747884167.issue6716@psf.upfronthosting.co.za>


pds <pirdirsir at gmail.com> added the comment:

The same problems I reported persist in python-3.1.1.msi, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6716>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:19:03 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 19 Aug 2009 05:19:03 +0000
Subject: [issue6724] r74463 causes failures in test_xmlrpc
In-Reply-To: <1250599784.86.0.0936114935604.issue6724@psf.upfronthosting.co.za>
Message-ID: <1250659143.54.0.787075736732.issue6724@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

hmm apparently the bug i was fixing in r74463 is not actually a bug, the 
httplib module does not support streaming requests in any way so even with 
a new socket buffer being constructed per request, the buffer is 
guaranteed to be empty at the end of completed request.

I'll undo the change and/or fix it to only close the connection if there 
was left over received data in the buffer after the response is finished.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6724>
_______________________________________

From report at bugs.python.org  Wed Aug 19 07:34:22 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 19 Aug 2009 05:34:22 +0000
Subject: [issue6724] r74463 causes failures in test_xmlrpc
In-Reply-To: <1250599784.86.0.0936114935604.issue6724@psf.upfronthosting.co.za>
Message-ID: <1250660062.79.0.0359255575968.issue6724@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

reverted in r74522

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6724>
_______________________________________

From report at bugs.python.org  Wed Aug 19 08:25:10 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Aug 2009 06:25:10 +0000
Subject: [issue6731] Non-zero exit status of setup.py when building of
	extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250663110.87.0.281689498294.issue6731@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It is deliberate that building Python succeeds even if building an
extension has failed.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 08:25:25 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Aug 2009 06:25:25 +0000
Subject: [issue6731] Non-zero exit status of setup.py when building of
	extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250663125.17.0.660988784658.issue6731@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 14:03:24 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 19 Aug 2009 12:03:24 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250683404.91.0.276940761729.issue6731@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

An option of `configure` could be added, whose enabling would change
this behavior.

----------
title: Non-zero exit status of setup.py when building of extensions has failed -> Add option of non-zero exit status of setup.py when building of extensions has failed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 14:34:00 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Aug 2009 12:34:00 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters are
	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250685240.55.0.880064208852.issue6697@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem is actually wider::
    >>> getattr(None, "\udc80")
    Segmentation fault
An idea would be to change _PyUnicode_AsDefaultEncodedString and allow
unpaired surrogates (utf8+surrogateescape, as explained in PEP383), but
I fear the consequences...

The code that fails seems pretty common:
	PyErr_Format(PyExc_AttributeError,
		     "'%.50s' object has no attribute '%.400s'",
		     tp->tp_name, _PyUnicode_AsString(name));
It would be unfortunate to replace all usages of _PyUnicode_AsString to
check the return value.

Martin, what do you think?

----------
nosy: +amaury.forgeotdarc, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed Aug 19 14:50:08 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 19 Aug 2009 12:50:08 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters
	are	passed from command line
In-Reply-To: <1250685240.55.0.880064208852.issue6697@psf.upfronthosting.co.za>
Message-ID: <4A8BF4F2.8020603@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> The problem is actually wider::
>     >>> getattr(None, "\udc80")
>     Segmentation fault
> An idea would be to change _PyUnicode_AsDefaultEncodedString and allow
> unpaired surrogates (utf8+surrogateescape, as explained in PEP383), but
> I fear the consequences...
>
> The code that fails seems pretty common:
> 	PyErr_Format(PyExc_AttributeError,
> 		     "'%.50s' object has no attribute '%.400s'",
> 		     tp->tp_name, _PyUnicode_AsString(name));
> It would be unfortunate to replace all usages of _PyUnicode_AsString to
> check the return value.

The use of _PyUnicode_AsString() is wrong here. There are several
cases where it can fail, e.g. MemoryErrors, embedded NULs, encoding
errors.

The same is true for _PyUnicode_AsStringAndSize(), which is why
I turned them into Python interpreter private APIs before 3.0
shipped.

If you want a fail-safe stringified version of a Unicode object,
your only choice is to create a new API that does error checking,
properly clears the error and then returns a reference to a constant
string, e.g. "<repr-error>".

----------
nosy: +lemburg
title: Python 3.1 segfaults when invalid UTF-8 characters are passed from command line -> Python 3.1 segfaults when invalid UTF-8 characters are	passed from command line

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:18:00 2009
From: report at bugs.python.org (Eric)
Date: Wed, 19 Aug 2009 13:18:00 +0000
Subject: [issue6734] Imap lib implicit conversion from bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>


New submission from Eric <surprising42 at gmail.com>:

using imaplib IMAP4_SSL, would fail at login due to TypeError, implicit
conversion from bytes object to string around line 1068 involving
function "_quote".

My fix:  
def _quote(self, arg):
        #Could not implicitly convert to bytes object to string
        arg = arg.encode('utf-8') #added this line to solve problem
        arg = arg.replace(b'\\', b'\\\\')
        arg = arg.replace(b'"', b'\\"')

        return b'"' + arg + b'"'

----------
components: Library (Lib)
files: imaplib.py
messages: 91729
nosy: surprising42
severity: normal
status: open
title: Imap lib implicit conversion from bytes to string
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14743/imaplib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Wed Aug 19 15:31:14 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Aug 2009 13:31:14 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters
	are	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250688674.95.0.181666584632.issue6697@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Do you suggest to remove all usages of _PyUnicode_AsString() and
_PyUnicode_AsStringAndSize()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed Aug 19 16:02:16 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 19 Aug 2009 14:02:16 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters
	are	passed from command line
In-Reply-To: <1250688674.95.0.181666584632.issue6697@psf.upfronthosting.co.za>
Message-ID: <4A8C05E2.8060101@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Do you suggest to remove all usages of _PyUnicode_AsString() and
> _PyUnicode_AsStringAndSize()?

In the short-term, I suggest that all uses that do not check the
return value get replaced with a new API which implements a failsafe
return value strategy.

In the mid- to long-term, the APIs should probably be removed
altogether.

They look a lot like the PyString APIs using the same names, but unlike
those APIs, they can fail, so the implied straight-forward conversion
of the PyString APIs to the above APIs gives a wrong impression to the
developers.

For error messages, I'd use the repr() of the objects - lone UTF-8
surrogates will not work since they cause issues further down the line
with debugging tools or even stderr terminal displays.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed Aug 19 16:45:56 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 19 Aug 2009 14:45:56 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters
	are	passed from command line
In-Reply-To: <1250194052.29.0.344352855764.issue6697@psf.upfronthosting.co.za>
Message-ID: <1250693156.78.0.179185732942.issue6697@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The %U format seems adequate for this purpose - actually
PyObject_GenericSetAttr uses it already.

Yes, the exception message will contain the same lone UTF-8
surrogates; this is not a problem because sys.stderr uses the
"backslashreplace" error handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed Aug 19 17:10:38 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Aug 2009 15:10:38 +0000
Subject: [issue6734] Imap lib implicit conversion from bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250694638.27.0.379526885682.issue6734@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See issue 1210 for background on the imaplib bytes/string issues.

A quick glance at the imaplib code leaves me confused.  _checkquote,
for example, appears to be mixing string comparisons and byte
comparisons.  Issue 1210 says imaplib _command should only quote
strings, but it does not appear at a quick glance to do any
quoting (the call to _checkquote is commented out).

It looks like the fix that would be consonant with the rest of
the code would be to convert the password to bytes using
the ASCII codec in the login method before calling _quote.

I'm adding Victor as nosy since he did the 1210 patch.

----------
nosy: +haypo, r.david.murray
priority:  -> normal
stage:  -> test needed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Wed Aug 19 17:44:17 2009
From: report at bugs.python.org (Roger Collins)
Date: Wed, 19 Aug 2009 15:44:17 +0000
Subject: [issue5114] 2.5.4.3 / test_threading hangs
In-Reply-To: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>
Message-ID: <1250696657.36.0.982305935186.issue5114@psf.upfronthosting.co.za>


Roger Collins <roger.collins at wpafb.af.mil> added the comment:

I can confirm the same exact issue exists in python2.6 on:
Solaris 5.8 sparc

Killing the bottom process worked for me as well

----------
nosy: +zulrang
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5114>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:20:39 2009
From: report at bugs.python.org (Roger Collins)
Date: Wed, 19 Aug 2009 16:20:39 +0000
Subject: [issue5114] 2.5.4.3 / test_threading hangs
In-Reply-To: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>
Message-ID: <1250698839.79.0.0705863165292.issue5114@psf.upfronthosting.co.za>


Roger Collins <roger.collins at wpafb.af.mil> added the comment:

Platform: Solaris 5.8 sparc
Compiler: gcc version 4.2.4

make test reported back the following on the initial test:
test test_threading failed -- Traceback (most recent call last):
  File
"/tools/webapps/local/src/Python-2.6.2/Lib/test/test_threading.py", line
419, in test_3_join_in_forked_from_thread
    self._run_and_join(script)
  File
"/tools/webapps/local/src/Python-2.6.2/Lib/test/test_threading.py", line
355, in _run_and_join
    self.assertEqual(data, "end of main\nend of thread\n")
AssertionError: '' != 'end of main\nend of thread\n'

**********

Same type of issue further on in the testing:

test_1_join_on_shutdown (test.test_threading.ThreadJoinOnShutdown) ... ok
test_2_join_in_forked_process (test.test_threading.ThreadJoinOnShutdown)
... ok
test_3_join_in_forked_from_thread
(test.test_threading.ThreadJoinOnShutdown) ... 
<hangs here>

$ ps -ef | grep -i 'python'
 xuserx 24669 17424  0 11:36:01 pts/18   5:44 ./python -E -tt
./Lib/test/regrtest.py -l
 xuserx 27539 27528  0 12:00:29 pts/18   0:00
/tools/webapps/local/src/Python-2.6.2/python -c if 1:            import
sys, o
 xuserx 27528 24669  0 12:00:28 pts/18   0:00
/tools/webapps/local/src/Python-2.6.2/python -c if 1:            import
sys, o
 xuserx 27660 29318  0 12:07:16 pts/18   0:00 grep -i python
$ kill 27539
<test continues then reports:>
test_3_join_in_forked_from_thread
(test.test_threading.ThreadJoinOnShutdown) ... FAIL

======================================================================
FAIL: test_3_join_in_forked_from_thread
(test.test_threading.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/tools/webapps/local/src/Python-2.6.2/Lib/test/test_threading.py", line
419, in test_3_join_in_forked_from_thread
    self._run_and_join(script)
  File
"/tools/webapps/local/src/Python-2.6.2/Lib/test/test_threading.py", line
355, in _run_and_join
    self.assertEqual(data, "end of main\nend of thread\n")
AssertionError: '' != 'end of main\nend of thread\n'

I'll keep digging and see if I can find a solution, but know that while
I have extensive programming experience in other languages, I have none
in python (yet).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5114>
_______________________________________

From report at bugs.python.org  Wed Aug 19 18:42:30 2009
From: report at bugs.python.org (Roger Collins)
Date: Wed, 19 Aug 2009 16:42:30 +0000
Subject: [issue5114] 2.5.4.3 and 2.6.2 / test_threading hangs
In-Reply-To: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>
Message-ID: <1250700150.89.0.268672748944.issue5114@psf.upfronthosting.co.za>


Changes by Roger Collins <roger.collins at wpafb.af.mil>:


----------
title: 2.5.4.3 / test_threading hangs -> 2.5.4.3 and 2.6.2 / test_threading hangs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5114>
_______________________________________

From report at bugs.python.org  Wed Aug 19 20:59:18 2009
From: report at bugs.python.org (dontbugme)
Date: Wed, 19 Aug 2009 18:59:18 +0000
Subject: [issue6735] restype pointer to Structure subclass never initialized
In-Reply-To: <1250708358.54.0.249958641719.issue6735@psf.upfronthosting.co.za>
Message-ID: <1250708358.54.0.249958641719.issue6735@psf.upfronthosting.co.za>


New submission from dontbugme <pythonbugsbugmenot at spamavert.com>:

So, say I'm sub-classing ctypes.Structure with a class: MyClass.

I define __init__() in MyClass..

If I explicitly instantiate MyClass(), then the __init__() is properly
executed as expected.

But say I have a CFUNCTYPE where I set it's restype member to a POINTER
to MyClass.. A python MyClass object is obviously instantiated at one
point in time, but it's __init__ is never called. Seems odd to me?

----------
assignee: theller
components: ctypes
messages: 91736
nosy: dontbugme, theller
severity: normal
status: open
title: restype pointer to Structure subclass never initialized
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6735>
_______________________________________

From report at bugs.python.org  Wed Aug 19 21:56:33 2009
From: report at bugs.python.org (Alex Quinn)
Date: Wed, 19 Aug 2009 19:56:33 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1250711793.61.0.401544467767.issue4661@psf.upfronthosting.co.za>


Alex Quinn <aq2009 at alexquinn.org> added the comment:

This bug also prevents the cgi module from handling POST data with 
multipart/form-data.  Consequently, 3.x cannot be readily used to write 
web apps for uploading files.  See #4953:
   http://bugs.python.org/issue4953

----------
nosy: +Alex Quinn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Wed Aug 19 21:57:14 2009
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 19 Aug 2009 19:57:14 +0000
Subject: [issue6735] restype pointer to Structure subclass never initialized
In-Reply-To: <1250708358.54.0.249958641719.issue6735@psf.upfronthosting.co.za>
Message-ID: <1250711834.51.0.575042045527.issue6735@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

This is on purpose.

The idea is that the function call returns an existing pointer to an
existing object, so __init__ (or __new__, IIRC) is never called in this
case.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6735>
_______________________________________

From report at bugs.python.org  Wed Aug 19 22:03:51 2009
From: report at bugs.python.org (Daniel Harding)
Date: Wed, 19 Aug 2009 20:03:51 +0000
Subject: [issue4485] fast swap of "default" Windows python versions
In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za>
Message-ID: <1250712231.61.0.863897436165.issue4485@psf.upfronthosting.co.za>


Changes by Daniel Harding <dharding at gmail.com>:


----------
nosy: +dharding

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4485>
_______________________________________

From report at bugs.python.org  Wed Aug 19 22:05:16 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Aug 2009 20:05:16 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250712316.69.0.227122259587.issue6731@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why is it desirable to have such an option?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 22:09:24 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 19 Aug 2009 20:09:24 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250712564.4.0.807595146151.issue6731@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

This makes it more easily possible for automated systems to detect that
there was a problem with the build.

Checking an exit code is easy.  Grabbing and parsing stdout and stderr
is hard and fragile.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 22:19:26 2009
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 19 Aug 2009 20:19:26 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1250713166.42.0.825626614245.issue4953@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Please, please, please contact the email-sig and help pitch in.  For
many reasons I simply haven't had the cycles to work on this and I don't
see that happening any time soon.  There are folks willing to work on
the package in the email-sig and I will add my $0.02 with design
suggestions, but we really need manpower and motivation to get the email
package into shape.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Wed Aug 19 22:20:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Aug 2009 20:20:06 +0000
Subject: [issue6697] Python 3.1 segfaults when invalid UTF-8 characters
	are	passed from command line
In-Reply-To: <1250685240.55.0.880064208852.issue6697@psf.upfronthosting.co.za>
Message-ID: <4A8C5E73.4060508@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It would be unfortunate to replace all usages of _PyUnicode_AsString to
> check the return value.

I agree with MAL: we do need to check for errors returned from
_PyUnicode_AsString, and it would be best if we created a fail-safe
version of it.

In the specific case (getattr), it might also be useful to create a
result that is unicode-escaped, i.e. with \u escapes for all non-ASCII
non-printable characters.

For _PyUnicode_AsString, I'm uncertain whether supporting half
surrogates is a good idea. Unless there is a compelling reason to
support them, I think we leave that as-is. Your example is not
compelling: I think the unicode string should be escaped, anyway.

The OP's case is also not compelling, we should print an error
message that the source code is incorrectly encoded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6697>
_______________________________________

From report at bugs.python.org  Wed Aug 19 22:26:30 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Aug 2009 20:26:30 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250712564.4.0.807595146151.issue6731@psf.upfronthosting.co.za>
Message-ID: <4A8C5FF2.6000503@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> This makes it more easily possible for automated systems to detect that
> there was a problem with the build.

How do you define "problem" in this context? Why is it a problem if some
extension module did not get built? Perhaps it cannot build correctly
on this system. Is it, or is it not a problem that the module was not
built because header files were lacking that would be available, but
weren't installed on the build machine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 22:27:48 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 19 Aug 2009 20:27:48 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250713668.33.0.0115375875788.issue6731@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

If it's not a problem, then the invoker doesn't need to check the exit
code of setup.py.  Why are you resistant to exposing more information?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 22:34:43 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 19 Aug 2009 20:34:43 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250714083.81.0.501684961965.issue6731@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> If it's not a problem, then the invoker doesn't need to check the exit
> code of setup.py.

Suppose the _tkinter module failed to compile on a given system, how
would you know if this is a problem or not ? setup.py would return 1
because it couldn't be built, but the rest of Python were compiled
successfully.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 23:02:35 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Aug 2009 21:02:35 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250713668.33.0.0115375875788.issue6731@psf.upfronthosting.co.za>
Message-ID: <4A8C6868.2090101@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If it's not a problem, then the invoker doesn't need to check the exit
> code of setup.py.  Why are you resistant to exposing more information?

Because I believe that the information that is being exposed in this
patch is confusing, and will trick people into believing things that
actually don't happen. When they then try to track down the problems,
they will (then rightly) complain that the implemented behavior is
incorrect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Wed Aug 19 23:21:42 2009
From: report at bugs.python.org (Ionut Turturica)
Date: Wed, 19 Aug 2009 21:21:42 +0000
Subject: [issue1550273] Fix numerous bugs in unittest
Message-ID: <1250716902.35.0.223585596638.issue1550273@psf.upfronthosting.co.za>


Ionut Turturica <jonozzz at yahoo.com> added the comment:

I keep trying to repro this on a smaller scale TestSuite but without any
success. The whole test framework has around 300 tests and I can't
really upload it.

In the mean time I changed the TestSuite's __eq__ back to identity.

I will attach the _breadth_first() method that parses the TestSuites.

----------
Added file: http://bugs.python.org/file14744/test_pybug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1550273>
_______________________________________

From report at bugs.python.org  Wed Aug 19 23:29:45 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Aug 2009 21:29:45 +0000
Subject: [issue6734] Imap lib implicit conversion from bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250717385.12.0.568995154159.issue6734@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

IMAP4 protocol uses bytes, not characters. There is no "standard
charset", so you have to encode (manually) your login and password as
bytes. login method prototype:
  IMAP4.login(login: bytes, password: bytes)

You server may use UTF-8, but another server may use ISO-8859-1 or any
other charset.

The documentation should explain why the Python library uses bytes and
not "simply" characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Wed Aug 19 23:39:52 2009
From: report at bugs.python.org (Travis H.)
Date: Wed, 19 Aug 2009 21:39:52 +0000
Subject: [issue5210] zlib does not indicate end of compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1250717992.73.0.125807198097.issue5210@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

Attaching unit test diff

Output of "diff -u test_zlib.py~ test_zlib.py"

----------
Added file: http://bugs.python.org/file14745/zlib_finished_test.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:25:12 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 19 Aug 2009 22:25:12 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250720712.57.0.028083723055.issue6731@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

> When they then try to track down the problems, they will
> (then rightly) complain that the implemented behavior is
> incorrect.

setup.py could optionally fail immediately when building of an
extension has failed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:27:58 2009
From: report at bugs.python.org (Salebona)
Date: Wed, 19 Aug 2009 22:27:58 +0000
Subject: [issue6736] File handling in Python
In-Reply-To: <1250720878.56.0.299301851986.issue6736@psf.upfronthosting.co.za>
Message-ID: <1250720878.56.0.299301851986.issue6736@psf.upfronthosting.co.za>


New submission from Salebona <sallas07 at gmail.com>:

How can I make read a text file from a normal text editor lik 
emicrosoft word or word pad?

----------
components: Windows
messages: 91751
nosy: SallaS07
severity: normal
status: open
title: File handling in Python
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6736>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:29:15 2009
From: report at bugs.python.org (Christopher Egner)
Date: Wed, 19 Aug 2009 22:29:15 +0000
Subject: [issue6737] PEP 372 odict.__eq__ behaves incorrectly
In-Reply-To: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>
Message-ID: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>


New submission from Christopher Egner <cegner at yahoo-inc.com>:

The current definition for odict.__eq__ is
    def __eq__(self, other):
        if isinstance(other, OrderedDict):
            return all(p==q for p, q in  _zip_longest(self.items(),
other.items()))
        return dict.__eq__(self, other)

The current behavior of NotImplemented is:
>>> if( NotImplemented ):
...     print 'foo'
foo
>>> dict.__eq__( {}, None )
NotImplemented
>>> if ( dict.__eq__( {}, None ) ):
...     print 'oops'
oops

The surprising behavior is:
>>> if ( OrderedDict() != None ):
...     print 'okie'
... else:
...     print 'gah!'
gah!

As best I understand it, normally other (in this case None) would be
given the chance to evaluate other.__eq__( OrderedDict() ), but this
doesn't seem to be happening.

----------
components: None
messages: 91752
nosy: cegner
severity: normal
status: open
title: PEP 372 odict.__eq__ behaves incorrectly
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6737>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:35:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 19 Aug 2009 22:35:43 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250720712.57.0.028083723055.issue6731@psf.upfronthosting.co.za>
Message-ID: <4A8C7E3B.4020704@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> When they then try to track down the problems, they will
>> (then rightly) complain that the implemented behavior is
>> incorrect.
> 
> setup.py could optionally fail immediately when building of an
> extension has failed.

What about skipped extensions (i.e. those where building them was
not even attempted?)

Why is it interesting to know that building was attempted, but failed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Thu Aug 20 00:52:24 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Aug 2009 22:52:24 +0000
Subject: [issue6737] PEP 372 odict.__eq__ behaves incorrectly
In-Reply-To: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>
Message-ID: <1250722344.22.0.92534864286.issue6737@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6737>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:15:29 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Aug 2009 23:15:29 +0000
Subject: [issue6737] PEP 372 odict.__eq__ behaves incorrectly
In-Reply-To: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>
Message-ID: <1250723729.03.0.989793518387.issue6737@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I cannot reproduce your final example:

Python 2.7a0 (trunk, Aug  4 2009, 12:07:15)
>>> from collections import OrderedDict
[41375 refs]
>>> if (OrderedDict() != None):
...     print 'okie'
... else:
...     print 'gah'
...
okie

Both are based on OrderedDict.__eq__ defined as:

    def __eq__(self, other):
        '''od.__eq__(y) <==> od==y.  Comparison to another OD is
order-sensitive
        while comparison to a regular mapping is order-insensitive.

        '''
        if isinstance(other, OrderedDict):
            return len(self)==len(other) and \
                   all(p==q for p, q in zip(self.items(), other.items()))
        return dict.__eq__(self, other)

Other questions about your bug report.  
* When you refer to odict, do you mean OrderedDict()?
* Do you understand that NotImplemented only does its magic
  in the context of the == or != operator, and it bypassed
  which you write dict.__eq__ or OrderedDict.__eq__?
* Are you clear that bool(NotImplemented) always evaluates to True?




Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> from collections import OrderedDict
>>> if (OrderedDict() != None):
...	print('Okie')
... else:
...	print('Gah')

Okie
	
Okie

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6737>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:19:58 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 19 Aug 2009 23:19:58 +0000
Subject: [issue6737] PEP 372 odict.__eq__ behaves incorrectly
In-Reply-To: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>
Message-ID: <1250723998.03.0.687561307465.issue6737@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If you need an implementation for OrderedDict that runs on Pythons
before 2.7 or 3.1, use the recipe at:

http://code.activestate.com/recipes/576693/

That code matches what was actually added to the language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6737>
_______________________________________

From report at bugs.python.org  Thu Aug 20 01:53:32 2009
From: report at bugs.python.org (Christopher Egner)
Date: Wed, 19 Aug 2009 23:53:32 +0000
Subject: [issue6737] PEP 372 odict.__eq__ behaves incorrectly
In-Reply-To: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>
Message-ID: <1250726012.7.0.954501370979.issue6737@psf.upfronthosting.co.za>


Christopher Egner <cegner at yahoo-inc.com> added the comment:

I was running the odict.py file from the PEP, figured out that things
were going off the rails at dict.__eq__ and generalised, saw the same
implementation in OrderedDict, I thought the same problem would exist. 
This is what I get for taking a shortcut.

I checked out the activestate recipe mentioned in msg91755 which works.

The odict.py version, here is a literal paste from the pdb prompt (aside
from changing some of the more private data to xxx):
(Pdb) p urlConsolidationArtefact_row_prev
odict.odict([(u'id', 58768L), (u'urlConsolidationRun_id', 22L),
(u'valid', True), (u'validated', False), (u'refererUrl',
u'http://search.yahoo.com/search?y=xxx'), (u'refererUrl_hash',
'\xa60\xe2\xb8D\x7fv\x03\xb1=\xf3{\x15\xc0\xb0)'), (u'url',
u'http://xxx'), (u'url_hash',
'\x00\x00\xc8\xf3\xa3\x0f\x1d\xc2wn\xb4\xc7\xd7\xe1\xca3'),
(u'updatedAt', datetime.datetime(2009, 8, 15, 10, 54, 15)),
(u'createdAt', datetime.datetime(2009, 8, 15, 10, 54, 14))])
(Pdb) p urlConsolidationArtefact_row_prev != None
False
(Pdb) p urlConsolidationArtefact_row_prev == None
False

So there is a problem at least in the odict module provided by 
http://dev.pocoo.org/hg/sandbox/raw-file/tip/odict.py (referenced in the
PEP, once more prominently than now, I think).

Anyhow, I don't really know the details of what python does with
NotImplemented but version you gave doesn't have the same problem, so
I'll gladly use that instead.

If you can confirm that there's no deeper issue here, I'll be glad to
close the bug.

Thanks for the help!

----------
versions:  -Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6737>
_______________________________________

From report at bugs.python.org  Thu Aug 20 02:09:19 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Aug 2009 00:09:19 +0000
Subject: [issue5210] zlib does not indicate end of compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1250726959.32.0.843030729655.issue5210@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Some comments about the patch:
- In zlibmodule.c, the is_finished member should be an int, and converted 
to a PyObject only when requested.
- The test should check that is_finished is False one byte before the 
compressed part, and becomes True when the decompressor reads the last 
compressed byte.  I don't think that dco.flush() is necessary for the 
test.
- Also, the last check could be more precise: assertEquals(y1 + y2, 
HAMLET_SCENE) and assertEquals(dco.unused_data, HAMLET_SCENE)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________

From report at bugs.python.org  Thu Aug 20 02:28:25 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Aug 2009 00:28:25 +0000
Subject: [issue6617] During compiling python 3.1 getting error Undefined
	symbol libintl_bind_textdomain_codeset
In-Reply-To: <1249162677.96.0.181878890277.issue6617@psf.upfronthosting.co.za>
Message-ID: <1250728105.12.0.13223636331.issue6617@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I dont know Solaris, but googling for "libintl_textdomain solaris" shows 
that many other projects have the same issue.
The solution seems to set LDFLAGS=-lintl

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6617>
_______________________________________

From report at bugs.python.org  Thu Aug 20 02:34:23 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Aug 2009 00:34:23 +0000
Subject: [issue6736] File handling in Python
In-Reply-To: <1250720878.56.0.299301851986.issue6736@psf.upfronthosting.co.za>
Message-ID: <1250728463.35.0.800271798824.issue6736@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The issue tracker is not a place to get help.
Please ask your question on the comp.lang.python newsgroup, there are many 
people willing to help you.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6736>
_______________________________________

From report at bugs.python.org  Thu Aug 20 03:25:20 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Aug 2009 01:25:20 +0000
Subject: [issue6737] PEP 372 odict.__eq__ behaves incorrectly
In-Reply-To: <1250720955.06.0.955952600398.issue6737@psf.upfronthosting.co.za>
Message-ID: <1250731520.77.0.900855231803.issue6737@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6737>
_______________________________________

From report at bugs.python.org  Thu Aug 20 08:00:07 2009
From: report at bugs.python.org (Simon Litchfield)
Date: Thu, 20 Aug 2009 06:00:07 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1250748007.39.0.957694337256.issue6444@psf.upfronthosting.co.za>


Simon Litchfield <simon at s29.com.au> added the comment:

>From the manual for logging.handlers.SysLogHandler --

emit(record)
The record is formatted, and then sent to the syslog server. If
exception information is present, it is not sent to the server.

Ideal, for me, would be to have each traceback line logged as an
individual DEBUG message. Maybe that should be an option. For now I'm
using a custom handler to achieve this.

----------
nosy: +s29
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Thu Aug 20 09:32:12 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 20 Aug 2009 07:32:12 +0000
Subject: [issue6738] Wrong doc strings in itertools
In-Reply-To: <1250753532.16.0.563820931893.issue6738@psf.upfronthosting.co.za>
Message-ID: <1250753532.16.0.563820931893.issue6738@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The doc strings of itertools.combinations and
itertools.combinations_with_replacement are wrong: The parameter "r" is
not optional here (like it is for itertools.permutations).

Attached trivial patch.

----------
components: Library (Lib)
files: docstring.patch
keywords: patch
messages: 91761
nosy: hagen
severity: normal
status: open
title: Wrong doc strings in itertools
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14746/docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6738>
_______________________________________

From report at bugs.python.org  Thu Aug 20 10:31:20 2009
From: report at bugs.python.org (CaribbeanCruise)
Date: Thu, 20 Aug 2009 08:31:20 +0000
Subject: [issue6739] IDLE window won't start or show up after assgining new
	key in options v2.5.2 and 3.1.1
In-Reply-To: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>
Message-ID: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>


New submission from CaribbeanCruise <caribbeancruise123 at gmail.com>:

I tried to assign a new key(lctrl+lshift instead of lctrl+F5) for run-
mode in option in v.2.5.2. I tried the new key and it didn't work. And 
then I got lots of messages.
So I killed the IDLE and the rest of python. And run IDLE again, 
background process indicates some activity for 5secs. And then it was 
gone. No IDLE window showed up. 
So I uninstalled the 2.5.2. and installed the v.3.1.1. The installation 
process went ok, but when I starts IDLE. Nothing happens.
I tried and run idle.py in cmd, while I'm a vista user and got this:

Traceback (most recent call last):
  File "C:\Python31\Lib\idlelib\idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Python31\Lib\idlelib\PyShell.py", line 1388, in main
    shell = flist.open_shell()
  File "C:\Python31\Lib\idlelib\PyShell.py", line 277, in open_shell
    self.pyshell = PyShell(self)
  File "C:\Python31\Lib\idlelib\PyShell.py", line 813, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "C:\Python31\Lib\idlelib\OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "C:\Python31\Lib\idlelib\EditorWindow.py", line 135, in __init__
    self.apply_bindings()
  File "C:\Python31\Lib\idlelib\EditorWindow.py", line 961, in 
apply_bindings
    text.event_add(event, *keylist)
  File "C:\Python31\Lib\idlelib\MultiCall.py", line 359, in event_add
    widget.event_add(self, virtual, seq)
  File "C:\Python31\Lib\tkinter\__init__.py", line 1353, in event_add
    self.tk.call(args)
_tkinter.TclError: bad event type or keysym "Shift"

What do I do to get this up and running?

----------
components: IDLE
messages: 91762
nosy: CaribbeanCruise
severity: normal
status: open
title: IDLE window won't start or show up after assgining new key in options v2.5.2 and 3.1.1
type: performance
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6739>
_______________________________________

From report at bugs.python.org  Thu Aug 20 11:03:26 2009
From: report at bugs.python.org (Andrew Brown)
Date: Thu, 20 Aug 2009 09:03:26 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1250759006.39.0.240081468001.issue6641@psf.upfronthosting.co.za>


Andrew Brown <abrown at freemail.gr> added the comment:

I think this bug is just a doc bug. If you check 

http://docs.python.org/library/datetime.html?highlight=strptime#strftime-behavior

and 

http://docs.python.org/library/time.html?highlight=strptime#time.strptime

You can see that the first link lists %z as a valid modifier, while in
the second link  (in footnote 1) it is mentioned as deprecated.

----------
nosy: +abrown

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Thu Aug 20 11:19:41 2009
From: report at bugs.python.org (Max Arnold)
Date: Thu, 20 Aug 2009 09:19:41 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1250759981.87.0.390353791858.issue6444@psf.upfronthosting.co.za>


Max Arnold <lwarxx at gmail.com> added the comment:

Sorry for long delay, I was on vacation.

I have installed sysklogd, metalog and syslog-ng on a virtual machine
and executed test script. First two daemons log exception as single
concatenated line.  Syslog-ng splits it as described in original report.

Do you suggest to file bug report to syslog-ng maintainer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Thu Aug 20 11:34:18 2009
From: report at bugs.python.org (Eric)
Date: Thu, 20 Aug 2009 09:34:18 +0000
Subject: [issue6734] Imap lib implicit conversion from bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250760858.64.0.561782784915.issue6734@psf.upfronthosting.co.za>


Eric <surprising42 at gmail.com> added the comment:

I checked the latest documentation for 3.1.1
(http://docs.python.org/3.1/library/imaplib.html), but I can't find any
reference to needing to encode information myself for the login
procedure. Is there some other documentation you are referring to?

In any case, the error wasn't returned by the server, but by imaplib. If
the arg needs to be encoded for the whole process, then the arg should
be checked for the appropriate type (I think the doc even says "plain
text password"), or an optional encoding argument for the relevant
functions (or a catchall used when connecting to the server?) with a
default encoding attempted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Thu Aug 20 12:27:17 2009
From: report at bugs.python.org (Michal Vyskocil)
Date: Thu, 20 Aug 2009 10:27:17 +0000
Subject: [issue6740] Compounded expressions with lambda functions are
	evaluated incorrectly
In-Reply-To: <1250764037.64.0.603658762072.issue6740@psf.upfronthosting.co.za>
Message-ID: <1250764037.64.0.603658762072.issue6740@psf.upfronthosting.co.za>


New submission from Michal Vyskocil <mvyskocil at suse.cz>:

The compounded expressions with lambda functions are evaluated
incorrectly. The simple expressions, or a named functions are evaluated
good. The problem is only in the evaluation of compounded expressions.
It seems that after evaluate of the first lambda function the
evaluation of whole expression is stopped and not continue (see
cond_error, which may raises the exception during evaluation).

Python 3.1 (r31:73572, Aug 15 2009, 22:04:19)
[GCC 4.4.1 [gcc-4_4-branch revision 149935]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> cond = (lambda x : x == 'foo') or (lambda x : x == 'bar')
>>> cond('foo')
True
>>> cond('bar')
False
>>> c1 = lambda x : x == 'foo'
>>> c1('foo')
True
>>> c2 = lambda x : x == 'bar'
>>> c2('bar')
True
>>> def ham(x): return x == 'foo'
...
>>> def spam(x): return x == 'bar'
...
>>> cond2 = lambda x : ham(x) or spam(x)
>>> cond2('foo')
True
>>> cond2('bar')
True
>>> cond2('ham')
False
>>> cond_error = (lambda x : x == 'foo') or (lambda x : y == 'bar')
>>> cond_error('d')
False

BTW: the same problem exists in Python 2.6.2
Python 2.6.2 (r262:71600, Aug 15 2009, 18:37:04)
[GCC 4.4.1 [gcc-4_4-branch revision 149935]] on linux2
Type "help", "copyright", "credits" or "license" for more information.

----------
messages: 91766
nosy: mvyskocil
severity: normal
status: open
title: Compounded expressions with lambda functions are evaluated incorrectly
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6740>
_______________________________________

From report at bugs.python.org  Thu Aug 20 12:28:38 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Aug 2009 10:28:38 +0000
Subject: [issue6734] Imap lib implicit conversion from bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250764118.67.0.567829701337.issue6734@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I can't find any reference to needing to encode information 
> myself for the login procedure. Is there some other 
> documentation you are referring to?

Exactly, the Python imaplib documentation should be fixed (the doc, not
the code).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Thu Aug 20 12:53:44 2009
From: report at bugs.python.org (Marcin Bachry)
Date: Thu, 20 Aug 2009 10:53:44 +0000
Subject: [issue6734] Imap lib implicit conversion from bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250765624.35.0.102764102532.issue6734@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

It seems most IMAP4 methods accept str as arguments right now (I
checked: list, lsub, myrights, select, status, search, fetch) and
login() is a sole exception. I know the protocol is mostly ascii only,
but still having possibility of using str in the API feels convenient
and reasonable to me. Can't we convert str parameters to login() to
ascii too? It already done in other methods (the _command() method
iterates over args and converts them).

----------
nosy: +marcin.bachry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Thu Aug 20 13:01:04 2009
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 20 Aug 2009 11:01:04 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1250766064.3.0.791530306211.issue1294959@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

both patches assume that everybody uses lib64 for 64bit libs, which is
not true for Debian/Ubuntu. Even the FHS doesn't mandate the use of lib64.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Thu Aug 20 13:13:07 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 20 Aug 2009 11:13:07 +0000
Subject: [issue6722] collections.namedtuple: confusing example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1250766787.83.0.266071588275.issue6722@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

Raymond, sorry if I wasn't clear. I'm fine with the API (haven't used it
yet though, because I was stuck after skimming through its documentation).

I suggest to make *first* example simple (without verbose=True) and to
move an example with verbose=True little furthere. I think it should be
something like this:

Example:

.. doctest::
   :options: +NORMALIZE_WHITESPACE

   >>> Point = namedtuple('Point', 'x y')
   >>> p = Point(11, y=22)     # instantiate with positional or keyword
arguments
   >>> p[0] + p[1]             # indexable like the plain tuple (11, 22)
   33
   >>> x, y = p                # unpack like a regular tuple
   >>> x, y
   (11, 22)
   >>> p.x + p.y               # fields also accessible by name
   33
   >>> p                       # readable __repr__ with a name=value style
   Point(x=11, y=22)
   >>> namedtuple('Point', 'x y', verbose=True) # print class definition
   class Point(tuple):
           'Point(x, y)'
   <BLANKLINE>
           __slots__ = ()
   <BLANKLINE>
           _fields = ('x', 'y')
   <BLANKLINE>
           def __new__(_cls, x, y):
               return _tuple.__new__(_cls, (x, y))
   <BLANKLINE>
           @classmethod
           def _make(cls, iterable, new=tuple.__new__, len=len):
               'Make a new Point object from a sequence or iterable'
               result = new(cls, iterable)
               if len(result) != 2:
                   raise TypeError('Expected 2 arguments, got %d' %
len(result))
               return result
   <BLANKLINE>
           def __repr__(self):
               return 'Point(x=%r, y=%r)' % self
   <BLANKLINE>
           def _asdict(t):
               'Return a new dict which maps field names to their values'
               return {'x': t[0], 'y': t[1]}
   <BLANKLINE>
           def _replace(_self, **kwds):
               'Return a new Point object replacing specified fields
with new values'
               result = _self._make(map(kwds.pop, ('x', 'y'), _self))
               if kwds:
                   raise ValueError('Got unexpected field names: %r' %
kwds.keys())
               return result
   <BLANKLINE>
           def __getnewargs__(self):
               return tuple(self)
   <BLANKLINE>
           x = _property(_itemgetter(0))
           y = _property(_itemgetter(1))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6722>
_______________________________________

From report at bugs.python.org  Thu Aug 20 13:17:46 2009
From: report at bugs.python.org (Alexey Shamrin)
Date: Thu, 20 Aug 2009 11:17:46 +0000
Subject: [issue6722] collections.namedtuple: confusing example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1250767066.76.0.395285172744.issue6722@psf.upfronthosting.co.za>


Alexey Shamrin <shamrin at gmail.com> added the comment:

Roundup broke formatting... I've attached a text file with the proposed
example.

----------
Added file: http://bugs.python.org/file14747/namedtuple_doc_example.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6722>
_______________________________________

From report at bugs.python.org  Thu Aug 20 14:38:32 2009
From: report at bugs.python.org (Lev)
Date: Thu, 20 Aug 2009 12:38:32 +0000
Subject: [issue6741] Garbage collector release method
In-Reply-To: <1250771912.15.0.32080385055.issue6741@psf.upfronthosting.co.za>
Message-ID: <1250771912.15.0.32080385055.issue6741@psf.upfronthosting.co.za>


New submission from Lev <lgardster at gmail.com>:

WinCRT debug detects several memory leaks after calling py_Initialize
(); py_Finalize(); functions. Most of them are garbage collector 
visible python's objects. I suggest to create "release" method in 
garbage collector which will distruct all objects in GC list without 
reference count checking, and call this method at the end of py_Finalize
() function. I think, that it will help to avoid memory leaks after 
calling py_Finalize() function.

----------
components: Interpreter Core
messages: 91772
nosy: gardster
severity: normal
status: open
title: Garbage collector release method
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6741>
_______________________________________

From report at bugs.python.org  Thu Aug 20 15:32:02 2009
From: report at bugs.python.org (damahay123)
Date: Thu, 20 Aug 2009 13:32:02 +0000
Subject: [issue6742] Embedding python into shared library crash on AIX
In-Reply-To: <1250775122.87.0.638132535261.issue6742@psf.upfronthosting.co.za>
Message-ID: <1250775122.87.0.638132535261.issue6742@psf.upfronthosting.co.za>


New submission from damahay123 <hong.zhu at algorithmics.com>:

Hi there,
I'm trying to embedding my python code into a .so on AIX and load it
with my main application. Since there is no libpython2.6.so available on
AIX, I have to link my .so with libpython2.6.a. I have to make some
twist to make it compile. And so far so good until I run my main. My
embedding python .so give me error like the following
Fatal Python error: Interpreter not initialized (version mismatch?)
I check the initialization status by calling Py_IsInitialized and it
said yes. So I'm wondering if this embedding python into .so ever work
on AIX.
I have no problem to do the same thing on linux, solaris since python
has libpython2.6.so on both system. But our system needs the supoort on
AIX. My embedding python is very simple like the following

#include <Python.h>
#include <iostream>

extern "C"
void allocate()
{
    std::cout << " am i ok = " << Py_IsInitialized() << std::endl;
    
    Py_InitializeEx(0);
    std::cout << " am i ok 1 = " << Py_IsInitialized() << std::endl;
    
    PyRun_SimpleString("from time import time, datetime, ctime\n"
                       "print 'Today is',ctime(time())\n");
    Py_Finalize();
}

my main application is also very simple
#include <iostream>
#include <iomanip>
#include <dlfcn.h>
//#include <link.h>
#include <Python.h>

typedef  void (*ALLOCATE)();

int main (int argc, char ** argv)
{
    // parse params to load shared object
    if (argc < 2)
    {
	std::cerr << "Usage: " << argv[0] << " sharedObject(s)" << std::endl;
	return 0;
    }

    //    Py_Initialize();
    
    for (int i = 1; i < argc; ++i)
    {
	void * handle = ::dlopen(argv[i], RTLD_LAZY);
	if (!handle)
	{
	    std::cerr << dlerror() << argv[i] << std::endl;
	
	    return 0;
	}
	
	// Use that handle to locate the symbol.  The symbol must be 
	// demangled so it has to be compiled with extern "C".
	ALLOCATE dlmAllocate = (ALLOCATE) ::dlsym(handle, "allocate");
	if (!dlmAllocate)
	{
	    std::cerr << dlerror() << std::endl;
	    return 0;
	}
    
	dlmAllocate();
    }


    return 0;
}

here is my makefile

CXX := g++

default: DLOpenTest mypython.so

DLOpenTest: DLOpen.C
	$(CXX) -o DLOpenTest DLOpen.C -ldl
-Wl,-bE:/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/lib/python2.6/config/python.exp
-lld -I/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/include/python2.6
-L/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/lib/ -lpython2.6 -lpthread

mypython.so: mypython.C
	$(CXX) -shared -nostartfiles
-I/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/include/python2.6
-L/mnts/cdstools/Python-2.6.2/aix-ppc-5.3/lib/ -lpython2.6 -lpthread -o
mypython.so mypython.C


clean:
	rm *.o DLOpenTest mypython.so

Can someone help me out? Or has anyone even tried same thing on AIX?

NOTE, the issue is not like issue 4434 or 1332869. Please don't reply
this issue with those two number. I've seen them already. It's not helpful

Thanks a log

----------
components: Interpreter Core
messages: 91773
nosy: damahay123
severity: normal
status: open
title: Embedding python into shared library crash on AIX
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6742>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:21:07 2009
From: report at bugs.python.org (Mary Stern)
Date: Thu, 20 Aug 2009 14:21:07 +0000
Subject: [issue6743] pprint.pprint should support no objects to print blank
	lines & allow args
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>


New submission from Mary Stern <marystern at yahoo.com>:

Using print in python 3 I would like to simple "replace" print with
pprint.pprint. However pprint cannot be called with no arguments, so
this cannot currently be done (the error is "TypeError: pprint() takes
at least 1 positional argument (0 given)").

A simple improvement is to allow no object to be passed in and pprint
would then print a newline rather than fail.

Another problem is that if you try this:

 print('hello', True)

and replace print with print, the second arg gets interpreted as the
"stream" parameter.


Both of the above can be fixed (I think) by changing pprint.py as follows:

instead of the current code:
def pprint(object, stream=None, indent=1, width=80, depth=None):

change to this:
def pprint(object='\n', *args, stream=None, indent=1, width=80, depth=None)

----------
messages: 91774
nosy: marystern
severity: normal
status: open
title: pprint.pprint should support no objects to print blank lines & allow args
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:24:47 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Aug 2009 14:24:47 +0000
Subject: [issue6734] Imap lib implicit conversion from bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250778287.42.0.131936132761.issue6734@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It seems most IMAP4 methods accept str as arguments right now (I
> checked: list, lsub, myrights, select, status, search, fetch) and
> login() is a sole exception. I know the protocol is mostly ascii only,
> but still having possibility of using str in the API feels convenient
> and reasonable to me.

Ok, that sounds like a good compromise. Can you write a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:26:46 2009
From: report at bugs.python.org (Mary Stern)
Date: Thu, 20 Aug 2009 14:26:46 +0000
Subject: [issue6743] pprint.pprint should support no objects to print blank
	lines & allow args
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1250778406.16.0.860330712338.issue6743@psf.upfronthosting.co.za>


Mary Stern <marystern at yahoo.com> added the comment:

Sorry: you also need to print out the args! :) .. like this:

def pprint(object='\n', *args, stream=None, indent=1, width=80, depth=None):
    """Pretty-print a Python object to a stream [default is sys.stdout]."""
    printer = PrettyPrinter(
        stream=stream, indent=indent, width=width, depth=depth)
    printer.pprint(object)
    for arg in args:
        printer.pprint(arg)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:50:51 2009
From: report at bugs.python.org (Senthil)
Date: Thu, 20 Aug 2009 14:50:51 +0000
Subject: [issue1424148] urllib.FancyURLopener.redirect_internal looses data on
	POST!
Message-ID: <1250779851.03.0.301472701483.issue1424148@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I agree with John on this ticket. At the outset, this is Not a bug.
And reading through the referenced ticket indicates the design decision
for the behavior.
In summary:
<quote>
This suggests to me that *no* automatic repeat of POST
requests should ever be done, and that in the case of a 302
or 303 response, a POST should be replaced by a GET; this
may also be done for a 301 response -- even though the
standard calls that an error, it admits that it is done by
old clients.
</quote>
That was Guido's point at that time.

The least that could be done is take a call on 301 response, but this
would break the other clients which rely on 'earlier standard behavior
though not compliant with RFC'. 

At the moment, this wont be necessary as it just break clients using
urllib. 

Giorgio's point in rekindling this issue, is not related to urllib
module and specifically w.r.t to redirect_request implementation. So, an
alternate behavior is desired on urllib2's redirects (if they are
observed by existing clients), it could be handled by another request.

So, effectively closing this request.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424148>
_______________________________________

From report at bugs.python.org  Thu Aug 20 16:56:12 2009
From: report at bugs.python.org (Senthil)
Date: Thu, 20 Aug 2009 14:56:12 +0000
Subject: [issue6711] macurl2path has typos that raise AttributeError
In-Reply-To: <1250403940.35.0.572726504822.issue6711@psf.upfronthosting.co.za>
Message-ID: <1250780172.91.0.327074417001.issue6711@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6711>
_______________________________________

From report at bugs.python.org  Thu Aug 20 17:26:47 2009
From: report at bugs.python.org (Senthil)
Date: Thu, 20 Aug 2009 15:26:47 +0000
Subject: [issue2637] urllib.quote() escapes characters unnecessarily and
	contrary to docs
In-Reply-To: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>
Message-ID: <1250782007.98.0.861783170856.issue2637@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

I see adding this information to the docs, might clarify a bit.

"By default, this   function is intended for quoting the path section of
the URL."

This is already present in the function docstring.

If there is no objection, I shall commit the attached patch and close
this issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file14748/issue2637.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2637>
_______________________________________

From report at bugs.python.org  Thu Aug 20 18:12:27 2009
From: report at bugs.python.org (Eric Smith)
Date: Thu, 20 Aug 2009 16:12:27 +0000
Subject: [issue6740] Compounded expressions with lambda functions are
	evaluated incorrectly
In-Reply-To: <1250764037.64.0.603658762072.issue6740@psf.upfronthosting.co.za>
Message-ID: <1250784747.08.0.834744407946.issue6740@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This isn't the right forum to ask for help. You should try
comp.lang.python, where someone would be happy to explain this to you.

Having said that, here's the explanation:

This is not a bug.

Disregarding side effects, the expression:
a = b or c

is essentially the same as:
if b:
 a = b
else:
 a = c

So your code is:
if (lambda x : x == 'foo'):
 cond = (lambda x : x == 'foo')
else:
 cond = (lambda x : x == 'bar')

And since "(lambda x : x == 'foo')" evaluates to True (it's a lambda, so
it's not None), you're really saying:
cond = (lambda x : x == 'foo')

And your examples follow from that.

You can further verify this with your c1 and c2:
>>> cond = c1 or c2
>>> cond
<function <lambda> at 0x00B3EA30>
>>> cond is c1
True

So, you're just setting cond to the first of the 2 lambdas.

----------
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6740>
_______________________________________

From report at bugs.python.org  Thu Aug 20 18:39:36 2009
From: report at bugs.python.org (David House)
Date: Thu, 20 Aug 2009 16:39:36 +0000
Subject: [issue6641] strptime doesn't support %z format ?
In-Reply-To: <1249394677.85.0.527199310346.issue6641@psf.upfronthosting.co.za>
Message-ID: <1250786376.13.0.388008287918.issue6641@psf.upfronthosting.co.za>


David House <dmhouse at gmail.com> added the comment:

Yes and no.

Firstly, %z isn't listed as deprecated in the documentation of the time
module's strftime -- although %Z is (note differing case).

Secondly, I still think the bug is invalid, because the documentation of
datetime.datetime.strptime says it behaves like time.strptime, whose
documentation says "only the directives specified in the documentation
[of strftime()] are supported". Since we're in the time module, that
reference to strftime() means time.strftime(), which doesn't list %z as
a directive.

Finally, there *is* a confusing docs issue, however: the "strftime()
behaviour" section in the datetime module documentation lists %z as a
valid directive, whereas it's not listed in time.strftime. Although
these functions have in theory nothing to do with one another, you would
in practice expect them to support the same directives.

Since in fact the footnote in the documentation of time.strftime() says
%z isn't supported by all ANSI C platforms (despite apparently being
required by the standard), I suggest that %z be removed from the list of
allowed modifiers in the "strftime() behaviour" section in the datetime
module documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6641>
_______________________________________

From report at bugs.python.org  Thu Aug 20 20:29:03 2009
From: report at bugs.python.org (jan matejek)
Date: Thu, 20 Aug 2009 18:29:03 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1250792943.3.0.0671167627457.issue1294959@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

well in our patch, at least, the directory is governed by sys.lib which
is defined through configure.
i don't understand the configure language well enough, but i'd assume
that making it parametrized isn't too hard?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Thu Aug 20 22:41:29 2009
From: report at bugs.python.org (Jessica McKellar)
Date: Thu, 20 Aug 2009 20:41:29 +0000
Subject: [issue6744] calling kevent repr raises a TypeError
In-Reply-To: <1250800889.41.0.974799993123.issue6744@psf.upfronthosting.co.za>
Message-ID: <1250800889.41.0.974799993123.issue6744@psf.upfronthosting.co.za>


New submission from Jessica McKellar <jessica.mckellar at gmail.com>:

kqueue_event_repr uses PyBytes_FromString when every other repr uses
PyUnicode_FromString, and this gets you a "TypeError: __repr__ returned
non-string (type bytes)". The patch swaps in PyUnicode_FromString and
adds a very simple unittest to test_kqueue.

----------
components: Extension Modules
files: kqueue-event-repr.patch
keywords: patch
messages: 91782
nosy: jesstess
severity: normal
status: open
title: calling kevent repr raises a TypeError
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14749/kqueue-event-repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6744>
_______________________________________

From report at bugs.python.org  Thu Aug 20 23:06:41 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 20 Aug 2009 21:06:41 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250802401.21.0.230773786074.issue6731@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

When building of an extension has failed due to external reasons (e.g.
headers from too old version of a Python dependency), user might prefer
to be forced to fix these reasons, than to have Python built without an
extension. If `make` doesn't fail, user might not notice the problem
during building of Python, but some time later during trying to import
some modules. Such behavior is also especially desired in distributions
(like Gentoo) in which packages are automatically built on users'
systems.

Maybe the option could be named --enable-strict-building-of-extensions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Thu Aug 20 23:28:40 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 20 Aug 2009 21:28:40 +0000
Subject: [issue6693] New functions in site.py to get user/global site packages
	paths
In-Reply-To: <1250152318.06.0.31085221368.issue6693@psf.upfronthosting.co.za>
Message-ID: <1250803720.81.0.165701529745.issue6693@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

applied in r74526 and r74529

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6693>
_______________________________________

From report at bugs.python.org  Thu Aug 20 23:35:05 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 20 Aug 2009 21:35:05 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250804105.4.0.0739998689807.issue6731@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Wouldn't be more interesting to add an option where you tell exactly
which modules aren't expected to be compiled successfully ? If any
modules besides those specified are not built, then setup.py returns 1.

I, for instance, don't care if the _bsddb extension doesn't get built
but I do care that some others get compiled successfully.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Thu Aug 20 23:54:53 2009
From: report at bugs.python.org (Trundle)
Date: Thu, 20 Aug 2009 21:54:53 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>


New submission from Trundle <andy-python at hammerhartes.de>:

In Python 3, curses requires a str for addstr() where I think it should
take bytes instead. Otherwise it is impossible to output anything other
than ASCII (which is even more or less stated on top of curses'
documentation).

See the attached script "umlaut2x.py" for Python 2.6: Outputting
umlauts works fine, both in single-byte and multi-byte environments.

The attached script "umlaut3x.py" is the same script translated to
Python 3. Note that the output here always seems to be utf-8, which is
plain wrong.

A quick test where I changed addstr() to take bytes instead of str
confirmed that outputting other characters than ASCII would work then
in Python 3, too. There are perhaps more places where the types are
wrong. If someone confirms this issue and it is desired, I could
provide a patch.

----------
components: Library (Lib)
files: umlaut2x.py
messages: 91786
nosy: Trundle
severity: normal
status: open
title: (curses) addstr() takes str in Python 3
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14750/umlaut2x.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Thu Aug 20 23:55:35 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 20 Aug 2009 21:55:35 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250805335.8.0.174943448929.issue6731@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

> Wouldn't be more interesting to add an option where you tell
> exactly which modules aren't expected to be compiled successfully ?
> If any modules besides those specified are not built, then setup.py
> returns 1.

It's good idea. The option of `configure` could be named
--enable-extensions=ext1,ext2,...

--enable-extensions=all could be also supported and it would mean that
all non-skipped extensions are requested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Thu Aug 20 23:55:45 2009
From: report at bugs.python.org (Trundle)
Date: Thu, 20 Aug 2009 21:55:45 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1250805345.05.0.450897243396.issue6745@psf.upfronthosting.co.za>


Changes by Trundle <andy-python at hammerhartes.de>:


Added file: http://bugs.python.org/file14751/umlaut3x.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Aug 21 00:00:22 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 Aug 2009 22:00:22 +0000
Subject: [issue6741] Garbage collector release method
In-Reply-To: <1250771912.15.0.32080385055.issue6741@psf.upfronthosting.co.za>
Message-ID: <1250805622.48.0.747352782563.issue6741@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you propose a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6741>
_______________________________________

From report at bugs.python.org  Fri Aug 21 00:13:34 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 Aug 2009 22:13:34 +0000
Subject: [issue6742] Embedding python into shared library crash on AIX
In-Reply-To: <1250775122.87.0.638132535261.issue6742@psf.upfronthosting.co.za>
Message-ID: <1250806414.54.0.560814406521.issue6742@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If you get differing results from Py_IsInitialized, my guess is that you
managed to link two different copies of the Python VM into your
application, each with its own set of global variables.

An AIX expert would be required to diagnose this in more detail;
unfortunately, we are not aware of any such expert.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6742>
_______________________________________

From report at bugs.python.org  Fri Aug 21 00:20:10 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 Aug 2009 22:20:10 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250802401.21.0.230773786074.issue6731@psf.upfronthosting.co.za>
Message-ID: <4A8DCC17.1060306@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> When building of an extension has failed due to external reasons (e.g.
> headers from too old version of a Python dependency), user might prefer
> to be forced to fix these reasons, than to have Python built without an
> extension.

Ok - but your patch does not implement that. If the extension fails to
compile because the header files are not installed at all, even with
your patch, there is no error indication. So according to your
requirements, your patch is incorrect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Fri Aug 21 00:22:46 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 20 Aug 2009 22:22:46 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250805335.8.0.174943448929.issue6731@psf.upfronthosting.co.za>
Message-ID: <4A8DCCB3.6050400@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Wouldn't be more interesting to add an option where you tell
>> exactly which modules aren't expected to be compiled successfully ?
>> If any modules besides those specified are not built, then setup.py
>> returns 1.
> 
> It's good idea. The option of `configure` could be named
> --enable-extensions=ext1,ext2,...
> 
> --enable-extensions=all could be also supported and it would mean that
> all non-skipped extensions are requested.

I also thought of such a solution, and could accept it.

However, it is really trivial to implement for anybody invoking an
automatic build of Python: after the build completes, do

python -c 'import ext1,ext2,...' 2>/dev/null

and check the return status - and voila, you know whether your required
modules were built successfully.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Fri Aug 21 00:30:46 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 20 Aug 2009 22:30:46 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1250807446.79.0.776733177841.issue6731@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

> Ok - but your patch does not implement that. If the extension
> fails to compile because the header files are not installed at all,
> even with your patch, there is no error indication.

`make` will return error:

$ cat Makefile
x:
        false
all: x
$ make
false
make: *** [x] Error 1
$ 

Also note that my original patch was created before I slightly changed
my suggestion :) .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:05:01 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 Aug 2009 23:05:01 +0000
Subject: [issue6746] ValueError raised by IDLE during tooltip open on 64-bit
	Centos 5.3
In-Reply-To: <1250809500.9.0.805893080789.issue6746@psf.upfronthosting.co.za>
Message-ID: <1250809500.9.0.805893080789.issue6746@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

Linux (Centos 5.3) 32-bit with Python 2.5.4

1. Start an idle session.
2. enter "help(" at the prompt

The open bracket triggers a traceback in the console:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/qatest/APyE/lib/python2.5/lib-tk/Tkinter.py", line 1414, 
in
__call__
    return self.func(*args)
  File "/home/qatest/APyE/lib/python2.5/idlelib/MultiCall.py", line 
151, in
handler
    r = l[i](event)
  File "/home/qatest/APyE/lib/python2.5/idlelib/CallTips.py", line 55, 
in
try_open_calltip_event
    self.open_calltip(False)
  File "/home/qatest/APyE/lib/python2.5/idlelib/CallTips.py", line 79, 
in
open_calltip
    self.calltip.showtip(arg_text, sur_paren[0], sur_paren[1])
  File "/home/qatest/APyE/lib/python2.5/idlelib/CallTipWindow.py", line 
66, in
showtip
    self.position_window()
  File "/home/qatest/APyE/lib/python2.5/idlelib/CallTipWindow.py", line 
35, in
position_window
    self.parencol))
  File "/home/qatest/APyE/lib/python2.5/lib-tk/Tkinter.py", line 2857, 
in bbox
    self.tk.call((self._w, 'bbox') + args)) or None
  File "/home/qatest/APyE/lib/python2.5/lib-tk/Tkinter.py", line 1030, 
in
_getints
    return tuple(map(getint, self.tk.splitlist(string)))
ValueError: invalid literal for int() with base 10: '(71,'

Upon closing the bracket, another exception is thrown:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/qatest/APy/lib/python2.5/lib-tk/Tkinter.py", line 1414, 
in __call__
    return self.func(*args)
  File "/home/qatest/APy/lib/python2.5/idlelib/MultiCall.py", line 151, 
in handler
    r = l[i](event)
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 55, 
in try_open_calltip_event
    self.open_calltip(False)
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 65, 
in open_calltip
    self._remove_calltip_window()
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 41, 
in _remove_calltip_window
    self.calltip.hidetip()
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTipWindow.py", line 
126, in hidetip
    self.label.destroy()
AttributeError: 'NoneType' object has no attribute 'destroy'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/qatest/APy/lib/python2.5/lib-tk/Tkinter.py", line 1414, 
in __call__
    return self.func(*args)
  File "/home/qatest/APy/lib/python2.5/idlelib/MultiCall.py", line 151, 
in handler
    r = l[i](event)
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 62, 
in refresh_calltip_event
    self.open_calltip(False)
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 65, 
in open_calltip
    self._remove_calltip_window()
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTips.py", line 41, 
in _remove_calltip_window
    self.calltip.hidetip()
  File "/home/qatest/APy/lib/python2.5/idlelib/CallTipWindow.py", line 
126, in hidetip
    self.label.destroy()
AttributeError: 'NoneType' object has no attribute 'destroy'
            

Tix version = 8.4.3
Tcl/Tk version = 8.5.7

This happens only on 64-bit (not 32-bit).

----------
components: IDLE
messages: 91793
nosy: srid
severity: normal
status: open
title: ValueError raised by IDLE during tooltip open on 64-bit Centos 5.3
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6746>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:52:12 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 20 Aug 2009 23:52:12 +0000
Subject: [issue6746] ValueError raised by IDLE during tooltip open on 64-bit
	Centos 5.3
In-Reply-To: <1250809500.9.0.805893080789.issue6746@psf.upfronthosting.co.za>
Message-ID: <1250812332.74.0.173502412136.issue6746@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I can reproduce it here, unfortunately Tcl/Tk 8.5 isn't really supported
by Python 2.5 and the changes required to get this fixed won't be
backported. It was suggested backporting before and it was rejected.

----------
nosy: +gpolo
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6746>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:52:30 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 20 Aug 2009 23:52:30 +0000
Subject: [issue6746] ValueError raised by IDLE during tooltip open on 64-bit
	Centos 5.3
In-Reply-To: <1250809500.9.0.805893080789.issue6746@psf.upfronthosting.co.za>
Message-ID: <1250812350.11.0.659451590578.issue6746@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
components: +Tkinter -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6746>
_______________________________________

From report at bugs.python.org  Fri Aug 21 01:55:24 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 20 Aug 2009 23:55:24 +0000
Subject: [issue6746] ValueError raised by IDLE during tooltip open on 64-bit
	Centos 5.3
In-Reply-To: <1250812332.74.0.173502412136.issue6746@psf.upfronthosting.co.za>
Message-ID: <op.uyzjd3jnbrrvlq@double>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On Thu, 20 Aug 2009 16:52:12 -0700, Guilherme Polo  
<report at bugs.python.org> wrote:

> I can reproduce it here, unfortunately Tcl/Tk 8.5 isn't really supported
> by Python 2.5 and the changes required to get this fixed won't be
> backported. It was suggested backporting before and it was rejected.

Thank you for giving an update. Was it reported as a bug in this tracker?  
Do you know the bug number?

-srid

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6746>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:02:04 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 21 Aug 2009 00:02:04 +0000
Subject: [issue6746] ValueError raised by IDLE during tooltip open on 64-bit
	Centos 5.3
In-Reply-To: <op.uyzjd3jnbrrvlq@double>
Message-ID: <ac2200130908201701w7075fa09i1ff0ef216b207778@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

>> I can reproduce it here, unfortunately Tcl/Tk 8.5 isn't really supported
>> by Python 2.5 and the changes required to get this fixed won't be
>> backported. It was suggested backporting before and it was rejected.
>
> Thank you for giving an update. Was it reported as a bug in this tracker?
> Do you know the bug number?

It was reported here, yes. I was able to find issue4342 which talks
about this, from what I remember it is r59653 which needed to be
backported but wasn't. There was another issue where I pointed out the
fixes that should be applied if someone wanted to use Tcl/Tk 8.5, with
fewer issues, together with Python 2.5 but right now I don't remember
on which issue I wrote this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6746>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:09:46 2009
From: report at bugs.python.org (Thomas Kowaliczek)
Date: Fri, 21 Aug 2009 00:09:46 +0000
Subject: [issue6747] test test_multiprocessing failed
In-Reply-To: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>
Message-ID: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>


New submission from Thomas Kowaliczek <linuxdonald at linuxdonald.de>:

test test_multiprocessing failed -- Traceback (most recent call last):
  File
"/home/LinuxDonald/Downloads/Python-3.1.1/Lib/test/test_multiprocessing.py",
line 1077, in test_number_of_objects
    self.assertEqual(refs, EXPECTED_NUMBER)
AssertionError: 4 != 1

----------
components: Tests
messages: 91797
nosy: LinuxDonald
severity: normal
status: open
title: test test_multiprocessing failed
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6747>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:10:35 2009
From: report at bugs.python.org (Thomas Kowaliczek)
Date: Fri, 21 Aug 2009 00:10:35 +0000
Subject: [issue6748] test test_telnetlib failed
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>


New submission from Thomas Kowaliczek <linuxdonald at linuxdonald.de>:

test test_telnetlib failed -- Traceback (most recent call last):
  File
"/home/LinuxDonald/Downloads/Python-3.1.1/Lib/test/test_telnetlib.py",
line 409, in test_debuglevel
    self._test_debuglevel([a, EOF_sigil], b)
  File
"/home/LinuxDonald/Downloads/Python-3.1.1/Lib/test/test_telnetlib.py",
line 389, in _test_debuglevel
    txt = telnet.read_all()
  File "/home/LinuxDonald/Downloads/Python-3.1.1/Lib/telnetlib.py", line
325, in read_all
    self.fill_rawq()
  File "/home/LinuxDonald/Downloads/Python-3.1.1/Lib/telnetlib.py", line
516, in fill_rawq
    buf = self.sock.recv(50)
socket.error: [Errno 104] Connection reset by peer

----------
components: Tests
messages: 91798
nosy: LinuxDonald
severity: normal
status: open
title: test test_telnetlib failed
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:22:49 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Aug 2009 00:22:49 +0000
Subject: [issue6747] test test_multiprocessing failed
In-Reply-To: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>
Message-ID: <1250814169.62.0.267898381713.issue6747@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6747>
_______________________________________

From report at bugs.python.org  Fri Aug 21 02:23:12 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Aug 2009 00:23:12 +0000
Subject: [issue6747] test test_multiprocessing failed
In-Reply-To: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>
Message-ID: <1250814192.71.0.304460562018.issue6747@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: +Extension Modules -Tests
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6747>
_______________________________________

From report at bugs.python.org  Fri Aug 21 03:02:00 2009
From: report at bugs.python.org (Thomas Kowaliczek)
Date: Fri, 21 Aug 2009 01:02:00 +0000
Subject: [issue6747] test test_multiprocessing failed
In-Reply-To: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>
Message-ID: <1250816520.35.0.870679771636.issue6747@psf.upfronthosting.co.za>


Thomas Kowaliczek <linuxdonald at linuxdonald.de> added the comment:

On my Netbook Fedora 11 32 Bit the test works but not on my NoteBook
Fedora 11 64Bit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6747>
_______________________________________

From report at bugs.python.org  Fri Aug 21 03:18:58 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 21 Aug 2009 01:18:58 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1250817538.1.0.594371212497.issue1755841@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755841>
_______________________________________

From report at bugs.python.org  Fri Aug 21 03:22:12 2009
From: report at bugs.python.org (Senthil)
Date: Fri, 21 Aug 2009 01:22:12 +0000
Subject: [issue735515] urllib / urllib2 should cache 301 redirections
Message-ID: <1250817732.58.0.192008373065.issue735515@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue735515>
_______________________________________

From report at bugs.python.org  Fri Aug 21 06:51:43 2009
From: report at bugs.python.org (Peter Manis)
Date: Fri, 21 Aug 2009 04:51:43 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>


New submission from Peter Manis <peter.manis at gmail.com>:

The zipfile support in 2.6 that allows you pass a zipfile(with __main__.py 
inside) as the "script", does not support encrypted zipfiles.  I view this 
as being a feature that could be useful to some.

----------
components: Library (Lib)
messages: 91800
nosy: manis
severity: normal
status: open
title: Support for encrypted zipfiles when interpreting zipfile as script
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Fri Aug 21 07:35:09 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Aug 2009 05:35:09 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
	building of extensions has failed
In-Reply-To: <1250807446.79.0.776733177841.issue6731@psf.upfronthosting.co.za>
Message-ID: <4A8E3209.5040108@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> `make` will return error:

No it will not. I just tested it: on my Linux system, _bsddb
was not built, yet make reported success even after installing
your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Fri Aug 21 08:15:11 2009
From: report at bugs.python.org (Lev)
Date: Fri, 21 Aug 2009 06:15:11 +0000
Subject: [issue6741] Garbage collector release method
In-Reply-To: <1250771912.15.0.32080385055.issue6741@psf.upfronthosting.co.za>
Message-ID: <1250835311.02.0.494011643733.issue6741@psf.upfronthosting.co.za>


Lev <lgardster at gmail.com> added the comment:

I,m trying to develop this patch now, but I'm facing the challenge 
(wrong ref_count or list corruption in dict objects). If I can solve 
it, I publish patch here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6741>
_______________________________________

From report at bugs.python.org  Fri Aug 21 08:37:24 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Aug 2009 06:37:24 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1250836644.49.0.455490049668.issue6749@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you provide a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Fri Aug 21 08:55:04 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Aug 2009 06:55:04 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
In-Reply-To: <1250608553.45.0.944099039091.issue1578269@psf.upfronthosting.co.za>
Message-ID: <4A8E44C5.5070903@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Can this fix be considered for inclusion in 3.1.2?

I don't think it should be integrated into 3.1. It *is* a new feature.

----------
title: Add os.link() and os.symlink() and os.path.islink()	support for Windows -> Add os.link() and os.symlink() and	os.path.islink() support for Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Aug 21 09:13:57 2009
From: report at bugs.python.org (kai zhu)
Date: Fri, 21 Aug 2009 07:13:57 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1250838837.03.0.608485428191.issue6239@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

i just found this bug independently, but yes its a bug, which i hope 
gets fixed for sake of extension community:

// test.c beg
char s[4] = "ab\xff";
char *foo() { return s; }
// test.c end

$ gcc -fPIC -g -c -Wall test.c
$ gcc -shared test.o -o test.so
$ python3.1 -c "import ctypes; lib = 
ctypes.cdll.LoadLibrary('./test.so'); lib.foo.restype = ctypes.c_char_p; 
lib.foo()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 2: 
unexpected code byte

----------
nosy: +kaizhu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Fri Aug 21 09:15:11 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 21 Aug 2009 07:15:11 +0000
Subject: [issue6444] multiline exception logging via syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1250838911.78.0.980015339999.issue6444@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Do you suggest to file bug report to syslog-ng maintainer?

Yes, I do. Otherwise you can't use it as a drop-in replacement, which
people would expect to be possible.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________

From report at bugs.python.org  Fri Aug 21 09:15:55 2009
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 21 Aug 2009 07:15:55 +0000
Subject: [issue6667] logging config - using of FileHandler's delay argument?
In-Reply-To: <1249638809.81.0.11088299207.issue6667@psf.upfronthosting.co.za>
Message-ID: <1250838955.61.0.304430385344.issue6667@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6667>
_______________________________________

From report at bugs.python.org  Fri Aug 21 09:28:29 2009
From: report at bugs.python.org (Jackson Yang)
Date: Fri, 21 Aug 2009 07:28:29 +0000
Subject: [issue6750] threading issue in __builtins__.print
In-Reply-To: <1250839709.71.0.595068140402.issue6750@psf.upfronthosting.co.za>
Message-ID: <1250839709.71.0.595068140402.issue6750@psf.upfronthosting.co.za>


New submission from Jackson Yang <jackson.yang at augmentum.com>:

# Bug Description
In a multi-threaded environment, the Win32 Python3000 built-in function
"print" may give the output several times.

# How to Reproduce:
import threading
event = threading.Event()
class Test(threading.Thread):
    def __init__(self, ord):
        super().__init__()
        self.ord = ord
    def run(self):
        event.wait()
        print('Hello, world!', self.ord)
threads = tuple(map(Test, range(8)))
tuple(map(lambda thread: thread.start(), threads))
event.set()
tuple(map(lambda thread: thread.join(), threads))
# EOF

# Problem Observed
[The first run, 0 is doubled]
Hello, world! 0
Hello, world! 0
Hello, world! 1
Hello, world! 2
Hello, world! 3
Hello, world! 4
Hello, world! 5
Hello, world! 6
Hello, world! 7

[the second run, 1 and 7 are doubled]
Hello, world! 1
Hello, world! 1
Hello, world! 2
Hello, world! 3
Hello, world! 4
Hello, world! 5
Hello, world! 6
Hello, world! 7
Hello, world! 7
Hello, world! 0

# Expected Result
Each thread gives ONE AND ONLY ONE output.
OR
State this as The Expected Behavior, document it and ask the user to
write something such as critical section.

----------
components: IO
messages: 91807
nosy: nullnil
severity: normal
status: open
title: threading issue in __builtins__.print
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6750>
_______________________________________

From report at bugs.python.org  Fri Aug 21 10:57:57 2009
From: report at bugs.python.org (Juan Javier)
Date: Fri, 21 Aug 2009 08:57:57 +0000
Subject: [issue6751] Default return value in ConfigParser
In-Reply-To: <1250845077.86.0.224640008074.issue6751@psf.upfronthosting.co.za>
Message-ID: <1250845077.86.0.224640008074.issue6751@psf.upfronthosting.co.za>


New submission from Juan Javier <jjdominguezm at yahoo.com>:

I think it is useful, at least for me, to add an argument, default, to
[Safe,Raw]ConfigParser.get that, if present, will be returned if the
methid fails to return the value.

That is, instead of rasing an exception, return default, if present.

It could be done overriding the get method in SafeConfigParser,
something like this:

class SafeConfigParser(ConfigParser):
    def get(self, section, option, raw=False, vars=None, **kwds):
        try:
            return super().get(section, option, raw, vars)
        except Exception as exc:
            if "default" in kwds:
                return kwds["default"]
            raise exc

----------
components: Library (Lib)
messages: 91808
nosy: jjdominguezm
severity: normal
status: open
title: Default return value in ConfigParser
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6751>
_______________________________________

From report at bugs.python.org  Fri Aug 21 10:58:57 2009
From: report at bugs.python.org (rahul)
Date: Fri, 21 Aug 2009 08:58:57 +0000
Subject: [issue6752] -1**2=-1
In-Reply-To: <1250845137.04.0.311672819223.issue6752@psf.upfronthosting.co.za>
Message-ID: <1250845137.04.0.311672819223.issue6752@psf.upfronthosting.co.za>


New submission from rahul <rahulalone1618 at gmail.com>:

what is the reason for this ????

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 91809
nosy: rahul1618
severity: normal
status: open
title: -1**2=-1
type: compile error
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6752>
_______________________________________

From report at bugs.python.org  Fri Aug 21 11:00:22 2009
From: report at bugs.python.org (rahul)
Date: Fri, 21 Aug 2009 09:00:22 +0000
Subject: [issue6752] -1**2=-1
In-Reply-To: <1250845137.04.0.311672819223.issue6752@psf.upfronthosting.co.za>
Message-ID: <1250845222.38.0.24188492064.issue6752@psf.upfronthosting.co.za>


rahul <rahulalone1618 at gmail.com> added the comment:

>>>-1**2
>>>-1 

???

what is reason for this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6752>
_______________________________________

From report at bugs.python.org  Fri Aug 21 11:09:04 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Aug 2009 09:09:04 +0000
Subject: [issue6752] -1**2=-1
In-Reply-To: <1250845137.04.0.311672819223.issue6752@psf.upfronthosting.co.za>
Message-ID: <1250845744.78.0.0263915526219.issue6752@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This very example is in the documentation:
http://docs.python.org/reference/expressions.html#the-power-operator

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6752>
_______________________________________

From report at bugs.python.org  Fri Aug 21 11:56:54 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Aug 2009 09:56:54 +0000
Subject: [issue6739] IDLE window won't start or show up after assgining new
	key in options v2.5.2 and 3.1.1
In-Reply-To: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>
Message-ID: <1250848614.59.0.877052203611.issue6739@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- find your .idlerc directory (probably in %USERPROFILE%)
- edit config-extensions.cfg
- remove the <Control-Shift> binding

- write a patch that refuses invalid keysims.

----------
nosy: +amaury.forgeotdarc
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6739>
_______________________________________

From report at bugs.python.org  Fri Aug 21 12:11:11 2009
From: report at bugs.python.org (Guillaume Delcourt-Petetin)
Date: Fri, 21 Aug 2009 10:11:11 +0000
Subject: [issue6753] Python 3.1.1 test_cmd_line fails on Fedora 11
In-Reply-To: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>
Message-ID: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>


New submission from Guillaume Delcourt-Petetin <gpetetin at gmail.com>:

Just what it says on the label :

[...]
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 618, in runtest_inner
    indirect_test()
  File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/test_cmd_l
    test.support.run_unittest(CmdLineTest)
  File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/support.py
    _run_suite(suite)
  File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/support.py
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File
"/home/Pif/T?l?chargement/Python-3.1.1/Python-3.1.1/Lib/test/test_cmd_l
    self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1222, in <module>
    main()
  File "./Lib/test/regrtest.py", line 425, in main
    testdir, huntrleaks)
  File "./Lib/test/regrtest.py", line 584, in runtest
    testdir, huntrleaks)
  File "./Lib/test/regrtest.py", line 638, in runtest_inner
    print("test", test, "failed --", msg)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in
position 54: ordinal not in range(128)
test test_cmd_line failed -- make: *** [test] Erreur 1

[...]


In my search for similar bugs, I only found a mac OSX/Python 3.0 issue
(http://bugs.python.org/issue4388)

----------
components: Tests
messages: 91813
nosy: Pif
severity: normal
status: open
title: Python 3.1.1 test_cmd_line fails on Fedora 11
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6753>
_______________________________________

From report at bugs.python.org  Fri Aug 21 12:53:16 2009
From: report at bugs.python.org (KAJIYAMA, Tamito)
Date: Fri, 21 Aug 2009 10:53:16 +0000
Subject: [issue6754] Non-existent member 'nb_inplace_divide' in PyNumberMethods
In-Reply-To: <1250851996.63.0.670347243231.issue6754@psf.upfronthosting.co.za>
Message-ID: <1250851996.63.0.670347243231.issue6754@psf.upfronthosting.co.za>


New submission from KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>:

In the "Python/C API Reference Manual", Section "Object Implementation 
Support", Subsection "Number Object Structures" 
(http://docs.python.org/3.1/c-api/typeobj.html#number-object-
structures), the definition of the PyNumberMethods structure has a non-
existent member 'nb_inplace_divide'.  This should be simply omitted.

----------
assignee: georg.brandl
components: Documentation
messages: 91814
nosy: georg.brandl, kajiyama
severity: normal
status: open
title: Non-existent member 'nb_inplace_divide' in PyNumberMethods
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6754>
_______________________________________

From report at bugs.python.org  Fri Aug 21 12:57:23 2009
From: report at bugs.python.org (Marcin Bachry)
Date: Fri, 21 Aug 2009 10:57:23 +0000
Subject: [issue6734] Imap lib implicit conversion from bytes to string
In-Reply-To: <1250687880.61.0.0161540410601.issue6734@psf.upfronthosting.co.za>
Message-ID: <1250852243.01.0.334228431898.issue6734@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

Ok, it think it's good to leave internal _quote() function operating on
bytes and convert password argument in login(). The method now works
with both str and bytes as arguments.

----------
keywords: +patch
Added file: http://bugs.python.org/file14752/imaplib-login.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6734>
_______________________________________

From report at bugs.python.org  Fri Aug 21 13:43:32 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Fri, 21 Aug 2009 11:43:32 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>


New submission from I?igo Serna <inigoserna at gmail.com>:

Currently,there is no a simple way in curses bindings to get the code
associated with a key press of non ascii keystroke (f.e. ?) in terminals
configured with UTF-8 encoding. 

getch returns the code for a wide character byte a byte.
But ncurses library has a proper function to do it: get_wch.

Patch against Python v2.6.2 to provide this missing get_wch method
in the ncurses bindings.

Include a test example and a patch to the documentation as well.

More info and a partial solution without patching python curses module
on this thread:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/67dce30f0a2742a6?fwc=2

----------
components: Extension Modules
messages: 91816
nosy: inigoserna
severity: normal
status: open
title: Patch: new method get_wch for ncurses bindings: accept wide characters (unicode)
type: feature request
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Aug 21 13:44:34 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Fri, 21 Aug 2009 11:44:34 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250855074.61.0.372683516588.issue6755@psf.upfronthosting.co.za>


I?igo Serna <inigoserna at gmail.com> added the comment:

Added patch for the documentation

----------
keywords: +patch
Added file: http://bugs.python.org/file14753/curses.get_wch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Aug 21 13:46:21 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Fri, 21 Aug 2009 11:46:21 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250855181.25.0.484464477151.issue6755@psf.upfronthosting.co.za>


I?igo Serna <inigoserna at gmail.com> added the comment:

Added test example

----------
Added file: http://bugs.python.org/file14754/test_get_wch.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Aug 21 13:53:27 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Fri, 21 Aug 2009 11:53:27 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250855607.11.0.999690477167.issue6755@psf.upfronthosting.co.za>


I?igo Serna <inigoserna at gmail.com> added the comment:

Added missing file: patch against Python v2.6.2

----------
Added file: http://bugs.python.org/file14755/_cursesmodule.get_wch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Aug 21 14:12:01 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 21 Aug 2009 12:12:01 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <4A8E44C5.5070903@v.loewis.de>
Message-ID: <8B473FAE8A08C34C9F5666FD4B0A87B6997EED1F01@hornigold>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In that case, what needs to be done to integrate it into 3.2?

----------
title: Add os.link() and os.symlink() and	os.path.islink() support for Windows -> Add os.link() and os.symlink() and os.path.islink()	support for Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Fri Aug 21 14:14:05 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Fri, 21 Aug 2009 12:14:05 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250856845.83.0.348207114262.issue6755@psf.upfronthosting.co.za>


I?igo Serna <inigoserna at gmail.com> added the comment:

Added patch against Python v3.1.1. 
NOT TESTED!

----------
versions: +Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14756/_cursesmodule.311.get_wch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Aug 21 14:17:01 2009
From: report at bugs.python.org (Tarjei Huse)
Date: Fri, 21 Aug 2009 12:17:01 +0000
Subject: [issue6756] ftplib documentation does not document what the acct
	parameter is used for
Message-ID: <1250857021.21.0.232003333024.issue6756@psf.upfronthosting.co.za>


Changes by Tarjei Huse <tarjei at scanmine.com>:


----------
assignee: georg.brandl
components: Documentation
nosy: georg.brandl, tarjei
severity: normal
status: open
title: ftplib documentation does not document what the acct parameter is used for
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6756>
_______________________________________

From report at bugs.python.org  Fri Aug 21 14:17:59 2009
From: report at bugs.python.org (Tarjei Huse)
Date: Fri, 21 Aug 2009 12:17:59 +0000
Subject: [issue6756] ftplib documentation does not document what the acct
	parameter is used for
In-Reply-To: <1250857079.39.0.656921992491.issue6756@psf.upfronthosting.co.za>
Message-ID: <1250857079.39.0.656921992491.issue6756@psf.upfronthosting.co.za>


New submission from Tarjei Huse <tarjei at scanmine.com>:

Check: 
http://docs.python.org/library/ftplib.html

The ftplib package does not document what the acct parameter is and how
it should be used.

Also: few methods document their return values of exceptions they raise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6756>
_______________________________________

From report at bugs.python.org  Fri Aug 21 14:34:59 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Aug 2009 12:34:59 +0000
Subject: [issue6750] threading issue in __builtins__.print
In-Reply-To: <1250839709.71.0.595068140402.issue6750@psf.upfronthosting.co.za>
Message-ID: <1250858099.98.0.754564433308.issue6750@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The TextIOWrapper class is not thread-safe, because it calls [the
equivalent of] self.buffer.write(self.pending_bytes) before clearing
self.pending_bytes.
Of course the write() function will release the GIL, and another thread
may send the same pending_bytes again.

Patch is attached. Antoine, can you review it?

(_pyio.TextIOWrapper does no buffering.)

----------
assignee:  -> pitrou
keywords: +needs review, patch
nosy: +amaury.forgeotdarc, pitrou
Added file: http://bugs.python.org/file14757/textiowrapper_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6750>
_______________________________________

From report at bugs.python.org  Fri Aug 21 15:02:09 2009
From: report at bugs.python.org (gungor)
Date: Fri, 21 Aug 2009 13:02:09 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1250859729.11.0.20577036745.issue2516@psf.upfronthosting.co.za>


gungor <gungorbasa at gmail.com> added the comment:

I am using Django with python to develope a web application.While I am
trying to syncronize and running the localserver, I get this issue(2516).
problem function is cagri()
Source Code:
from django.db import models
from datetime import datetime
from sets import ImmutableSet

class Randevu(models.Model):
   	def __init__(self):

		saatler=(
	        ('8',(8)),
	        ('9',(9)),
	        ('10',(10)),
	        ('11',(11)),
	        ('13',(13)),
	        ('14',(14)),
	        ('15',(15)),
	        ('16',(16)),
			    )


		ad=models.CharField(max_length=30)
	   	soyad=models.CharField(max_length=30)
	   	tarih=models.DateField()
	   	saat=models.TimeField(choices=saatler)
	   	konu=models.TextField()
	   	email=models.EmailField()
		t=cagri()
		t.cagir(saat)
	#r=Randevu()		
class duzen():
	def duz(saat):
		r=Randevu()
		fil=r.objects.filter(tarih__gte=datetime(2009,8,21))
		for saat in fil:
			if saat==fil.saat:
				error()	
class cagri():
	def cagir(saat):
		d=duzen()
		d.duz(saat)

----------
components:  -Interpreter Core
nosy: +gungorbasa
type: behavior -> compile error
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Aug 21 15:17:00 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Aug 2009 13:17:00 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1250860620.68.0.629200433871.issue2516@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
type: compile error -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Aug 21 15:31:06 2009
From: report at bugs.python.org (gungor)
Date: Fri, 21 Aug 2009 13:31:06 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1250860620.78.0.632871073513.issue2516@psf.upfronthosting.co.za>
Message-ID: <5d3046480908210631x7fd0f8f7rab9fd9c0ec085854@mail.gmail.com>


gungor <gungorbasa at gmail.com> added the comment:

TypeError at /admin/rt/randevu/add/

cagir() takes exactly 1 argument (2 given)

 Request Method: GET  Request URL:
http://127.0.0.1:8000/admin/rt/randevu/add/  Exception Type: TypeError
 Exception
Value:

cagir() takes exactly 1 argument (2 given)

 Exception Location: /home/gungor/rts/../rts/rt/models.py in __init__, line
27  Python Executable: /usr/bin/python  Python Version: 2.6.2  Python
Path: ['/home/gungor/rts',
'/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2',
'/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old',
'/usr/lib/python2.6/lib-dynload', '/usr/lib/python2.6/dist-packages',
'/usr/lib/python2.6/dist-packages/PIL',
'/usr/lib/python2.6/dist-packages/gst-0.10',
'/var/lib/python-support/python2.6',
'/usr/lib/python2.6/dist-packages/gtk-2.0',
'/var/lib/python-support/python2.6/gtk-2.0',
'/usr/local/lib/python2.6/dist-packages']  Server time: Fri, 21 Aug 2009
07:24:43 -0500
2009/8/21 Benjamin Peterson <report at bugs.python.org>

>
> Changes by Benjamin Peterson <benjamin at python.org>:
>
>
> ----------
> type: compile error -> feature request
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2516>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14758/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________
-------------- next part --------------
<span class="gI"></span><br><h1>TypeError at /admin/rt/randevu/add/</h1>
  <pre class="exception_value">cagir() takes exactly 1 argument (2 given)</pre>
  
    <table class="meta"><tbody><tr>
      <th>Request Method:</th>
      <td>GET</td>
    </tr>
    <tr>
      <th>Request URL:</th>
      <td><a href="http://127.0.0.1:8000/admin/rt/randevu/add/">http://127.0.0.1:8000/admin/rt/randevu/add/</a></td>
    </tr>
    <tr>
      <th>Exception Type:</th>
      <td>TypeError</td>
    </tr>
    <tr>
      <th>Exception Value:</th>
      <td><pre>cagir() takes exactly 1 argument (2 given)</pre></td>
    </tr>
    <tr>
      <th>Exception Location:</th>
      <td>/home/gungor/rts/../rts/rt/models.py in __init__, line 27</td>
    </tr>
    <tr>
      <th>Python Executable:</th>
      <td>/usr/bin/python</td>
    </tr>
    <tr>
      <th>Python Version:</th>
      <td>2.6.2</td>
    </tr>
    <tr>
      <th>Python Path:</th>
      <td>[&#39;/home/gungor/rts&#39;,
&#39;/usr/lib/python2.6&#39;, &#39;/usr/lib/python2.6/plat-linux2&#39;,
&#39;/usr/lib/python2.6/lib-tk&#39;, &#39;/usr/lib/python2.6/lib-old&#39;,
&#39;/usr/lib/python2.6/lib-dynload&#39;, &#39;/usr/lib/python2.6/dist-packages&#39;,
&#39;/usr/lib/python2.6/dist-packages/PIL&#39;,
&#39;/usr/lib/python2.6/dist-packages/gst-0.10&#39;,
&#39;/var/lib/python-support/python2.6&#39;,
&#39;/usr/lib/python2.6/dist-packages/gtk-2.0&#39;,
&#39;/var/lib/python-support/python2.6/gtk-2.0&#39;,
&#39;/usr/local/lib/python2.6/dist-packages&#39;]</td>
    </tr>
    <tr>
      <th>Server time:</th>
      <td>Fri, 21 Aug 2009 07:24:43 -0500</td></tr></tbody></table><br><div class="gmail_quote">2009/8/21 Benjamin Peterson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Changes by Benjamin Peterson &lt;<a href="mailto:benjamin at python.org">benjamin at python.org</a>&gt;:<br>
<br>
<br>
----------<br>
type: compile error -&gt; feature request<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue2516" target="_blank">http://bugs.python.org/issue2516</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>

From report at bugs.python.org  Fri Aug 21 15:34:34 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Aug 2009 13:34:34 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1250861674.93.0.0906719327137.issue2516@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Removed file: http://bugs.python.org/file14758/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Aug 21 15:39:31 2009
From: report at bugs.python.org (gungor)
Date: Fri, 21 Aug 2009 13:39:31 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1250861675.0.0.251131721226.issue2516@psf.upfronthosting.co.za>
Message-ID: <5d3046480908210639w5453e00fjb92af1d30f89d754@mail.gmail.com>


gungor <gungorbasa at gmail.com> added the comment:

I don't understand your message.You only send me my error message's xml
version

2009/8/21 Benjamin Peterson <report at bugs.python.org>

>
> Changes by Benjamin Peterson <benjamin at python.org>:
>
>
> Removed file: http://bugs.python.org/file14758/unnamed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2516>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14759/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________
-------------- next part --------------
I don&#39;t understand your message.You only send me my error message&#39;s xml version<br><br><div class="gmail_quote">2009/8/21 Benjamin Peterson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
Changes by Benjamin Peterson &lt;<a href="mailto:benjamin at python.org">benjamin at python.org</a>&gt;:<br>
<br>
<br>
</div>Removed file: <a href="http://bugs.python.org/file14758/unnamed" target="_blank">http://bugs.python.org/file14758/unnamed</a><br>
<div class="im"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
</div><div class="im">&lt;<a href="http://bugs.python.org/issue2516" target="_blank">http://bugs.python.org/issue2516</a>&gt;<br>
</div>_______________________________________<br>
</blockquote></div><br><br clear="all"><br>-- <br><a href="http://www.ral.forumup.com">www.ral.forumup.com</a><br>

From report at bugs.python.org  Fri Aug 21 15:46:56 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Aug 2009 13:46:56 +0000
Subject: [issue6753] Python 3.1.1 test_cmd_line fails on Fedora 11
In-Reply-To: <1250849471.77.0.183054552926.issue6753@psf.upfronthosting.co.za>
Message-ID: <1250862416.53.0.818814678732.issue6753@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Does it happen if you build python from a directory with no accented
letters?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6753>
_______________________________________

From report at bugs.python.org  Fri Aug 21 16:10:25 2009
From: report at bugs.python.org (Guillaume Delcourt-Petetin)
Date: Fri, 21 Aug 2009 14:10:25 +0000
Subject: [issue6753] Python 3.1.1 test_cmd_line fails on Fedora 11
In-Reply-To: <1250862416.53.0.818814678732.issue6753@psf.upfronthosting.co.za>
Message-ID: <2233985d0908210710j14354f16n8d271ccf0880e15a@mail.gmail.com>


Guillaume Delcourt-Petetin <gpetetin at gmail.com> added the comment:

Nope.

2009/8/21 Amaury Forgeot d'Arc <report at bugs.python.org>

>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Does it happen if you build python from a directory with no accented
> letters?
>
> ----------
> nosy: +amaury.forgeotdarc
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6753>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file14760/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6753>
_______________________________________
-------------- next part --------------
Nope.<br><br><div class="gmail_quote">2009/8/21 Amaury Forgeot d&#39;Arc <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Amaury Forgeot d&#39;Arc &lt;<a href="mailto:amauryfa at gmail.com">amauryfa at gmail.com</a>&gt; added the comment:<br>
<br>
Does it happen if you build python from a directory with no accented<br>
letters?<br>
<br>
----------<br>
nosy: +amaury.forgeotdarc<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue6753" target="_blank">http://bugs.python.org/issue6753</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>

From report at bugs.python.org  Fri Aug 21 16:52:54 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 21 Aug 2009 14:52:54 +0000
Subject: [issue6556] "HOME" is not a standard environment variable on Windows
In-Reply-To: <1248379761.36.0.601035706586.issue6556@psf.upfronthosting.co.za>
Message-ID: <1250866374.5.0.361980329725.issue6556@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Fixed, thanks for the feedback all !

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6556>
_______________________________________

From report at bugs.python.org  Fri Aug 21 17:12:45 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 21 Aug 2009 15:12:45 +0000
Subject: [issue6739] IDLE window won't start or show up after assgining new
	key in options v2.5.2 and 3.1.1
In-Reply-To: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>
Message-ID: <1250867565.47.0.251526371262.issue6739@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Here is a patch that changes IDLE to refuse invalid key bindings.

----------
keywords: +patch
nosy: +gpolo
versions: +Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14761/tcl_validation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6739>
_______________________________________

From report at bugs.python.org  Fri Aug 21 17:48:55 2009
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 21 Aug 2009 15:48:55 +0000
Subject: [issue6757] Marshal's documentation incomplete
In-Reply-To: <1250869735.91.0.499827102331.issue6757@psf.upfronthosting.co.za>
Message-ID: <1250869735.91.0.499827102331.issue6757@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

"The following types are supported: None, integers, floating point
numbers, strings, bytes, bytearrays, tuples, lists, sets, dictionaries,
and code objects"

It fails to list bools: True and False

While it states "Not all Python object types are supported; in general,
only objects whose value is independent from a particular invocation of
Python can be written and read by this module." beforehand, it seems
proper to include bools in the list of accepted types

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 91831
nosy: georg.brandl, serprex
severity: normal
status: open
title: Marshal's documentation incomplete
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6757>
_______________________________________

From report at bugs.python.org  Fri Aug 21 17:49:57 2009
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 21 Aug 2009 15:49:57 +0000
Subject: [issue6757] Marshal's documentation incomplete (Bools)
In-Reply-To: <1250869735.91.0.499827102331.issue6757@psf.upfronthosting.co.za>
Message-ID: <1250869797.96.0.668063464555.issue6757@psf.upfronthosting.co.za>


Changes by Demur Rumed <junkmute at hotmail.com>:


----------
title: Marshal's documentation incomplete -> Marshal's documentation incomplete (Bools)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6757>
_______________________________________

From report at bugs.python.org  Fri Aug 21 18:00:18 2009
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 21 Aug 2009 16:00:18 +0000
Subject: [issue6133] LOAD_CONST followed by LOAD_ATTR can be optimized to
	just	be a LOAD_CONST
In-Reply-To: <1243466391.88.0.68447044966.issue6133@psf.upfronthosting.co.za>
Message-ID: <1250870418.93.0.0623761902372.issue6133@psf.upfronthosting.co.za>


Changes by Demur Rumed <junkmute at hotmail.com>:


----------
title: LOAD_CONST followed by LOAD_ATTR can be optimized to just	be a LOAD_COST -> LOAD_CONST followed by LOAD_ATTR can be optimized to just	be a LOAD_CONST

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6133>
_______________________________________

From report at bugs.python.org  Fri Aug 21 18:39:55 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 21 Aug 2009 16:39:55 +0000
Subject: [issue5210] zlib does not indicate end of compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1250872795.31.0.00357520168411.issue5210@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

zlibmodule.c.diff Implements all the suggested features, but I'm not
exactly sure whether it handles reference counts properly.

----------
Added file: http://bugs.python.org/file14762/zlibmodule.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________

From report at bugs.python.org  Fri Aug 21 18:41:10 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 21 Aug 2009 16:41:10 +0000
Subject: [issue5210] zlib does not indicate end of compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1250872870.47.0.525325942464.issue5210@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

Diff to tests

Implements all suggested changes save one:

I wasn't sure how to test that is_finished is clear one byte before the
end of the compressed section.  Instead, I test that it is clear before
I call the compression routine.

----------
Added file: http://bugs.python.org/file14763/test_zlib.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________

From report at bugs.python.org  Fri Aug 21 19:24:04 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Aug 2009 17:24:04 +0000
Subject: [issue6757] Marshal's documentation incomplete (Bools)
In-Reply-To: <1250869735.91.0.499827102331.issue6757@psf.upfronthosting.co.za>
Message-ID: <1250875444.35.0.429532865463.issue6757@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

A number of other things are also missing.

types:complex,frozenset
singletons:StopIteration, Ellipsis

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6757>
_______________________________________

From report at bugs.python.org  Fri Aug 21 19:32:52 2009
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Fri, 21 Aug 2009 17:32:52 +0000
Subject: [issue6090] zipfile DeprecationWarning Python 2.6.2
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1250875972.03.0.208353959905.issue6090@psf.upfronthosting.co.za>


Changes by C?dric Krier <ced at ced.homedns.org>:


----------
nosy: +ced

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6090>
_______________________________________

From report at bugs.python.org  Fri Aug 21 20:49:37 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 21 Aug 2009 18:49:37 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way to
	drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>


New submission from Travis H. <travis+w-python.org at subspacefield.org>:

It should be easier to write network servers and setuid programs in
python.  One of the troublesome issues is that the semantics of the
setuid/getuid-related calls are quite complicated.

There are two papers on this subject that form the background of this
feature request:
http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
http://www.cs.berkeley.edu/~daw/papers/setuid-login08b.pdf

In general, then, the end goal is a safe (portable, secure) way to drop
privileges either temporarily or permanently.

Wagner et. al. have proposed a decent interface, but it's unclear to me
where it should be implemented.

Furthermore, it makes use of the getresuid/setresuid calls (among many
others), which don't appear from their manpages to be standardized by
POSIX, but are available in most modern Unix OSes.  So this leaves me
with two questions; have these functions been standardized, and if not,
where should they be implemented?

I'm willing to do the coding, but need some guidance on where to put the
code.

----------
messages: 91835
nosy: solinym
severity: normal
status: open
title: implement new setuid-related calls and a standard way to drop all privileges
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Fri Aug 21 20:59:33 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 21 Aug 2009 18:59:33 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way to
	drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250881173.64.0.234060523561.issue6758@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

The posixmodule.c seems to have a lot of really complex CPP logic about
what chunks to compile.  If the target is to put the code there, I would
have to be guessing - next to the HAVE_GETEUID looks promising.

But wouldn't it be better to have the configure script check for the
presence of e.g. getresuid and compile it iff it finds it?  So that
sounds like some work with the autoconf script...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Fri Aug 21 21:07:38 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 21 Aug 2009 19:07:38 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1250881658.18.0.672745033062.issue2516@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Fri Aug 21 21:42:08 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 21 Aug 2009 19:42:08 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way to
	drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250883728.23.0.466697473047.issue6758@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

The routines necessary for implementing Wagner's API for dropping
privileges are:

sysconf function: available in os module
_SC_NGROUPS_MAX constant: unsure
abort function: available in os module
getresuid function: needs implementing[1]
getresgid function: needs implementing[1]

[1] Not POSIX but available on Linux, HP/UX, FreeBSD, OpenBSD,
DragonFlyBSD.  Not available on Solaris, AIX, NetBSD, OSX, cygwin.

Since Wagner points out that the non-standard function calls actually
have clearer/better semantics, perhaps the way to do all this is in its
own module, instead of trying to shove it into an existing module..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Fri Aug 21 21:55:10 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 21 Aug 2009 19:55:10 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way to
	drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250884510.59.0.724875046497.issue6758@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Maybe this should just be a third-party module for the time being?  That
removes the question of which stdlib module to add it to for now.  Plus,
since it's not just a straightforward platform API wrapper, it probably
merits separate distribution to see what adoption is like and what the
Python community response is.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:07:43 2009
From: report at bugs.python.org (John P. Speno)
Date: Fri, 21 Aug 2009 20:07:43 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1250885263.49.0.351113107384.issue4010@psf.upfronthosting.co.za>


John P. Speno <spamfilter at macspeno.com> added the comment:

Hi. We encountered this issue on a Solaris 10 while building python 2.6.2.

There's a problem with reptrov's patch from 2009-01-04. The LDFLAGS in the 
Makefile.pre.in patch need to be quoted also. Like so:

LDFLAGS='$(LDFLAGS)'

This allows for multiple flags. Other than that, it works for us.

----------
nosy: +speno

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:07:58 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 21 Aug 2009 20:07:58 +0000
Subject: [issue5210] zlib does not indicate end of compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1250885278.36.0.492433100432.issue5210@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

Figured out how to test is_finished attribute of the zlib module properly.

----------
Added file: http://bugs.python.org/file14764/test_zlib.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:19:02 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Aug 2009 20:19:02 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way to
	drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250885942.63.0.790559251078.issue6758@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If the logic is going to be built on top of the APIs that are already
there, I agree that it would be best to implement this as a separate
module, and upload it to pypi.python.org.

Closing as "won't fix".

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:31:24 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 21 Aug 2009 20:31:24 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way to
	drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250886684.46.0.170564714119.issue6758@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

It would still be nice to have the currently unimplemented platform
wrappers added to the standard library, though.  For example, as solinym
pointed out, getresuid and getresgid are not currently wrapped at all. 
There may be other low-level APIs which may be missing as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:42:43 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Aug 2009 20:42:43 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way
	to	drop all privileges
In-Reply-To: <1250886684.46.0.170564714119.issue6758@psf.upfronthosting.co.za>
Message-ID: <4A8F06C0.2070502@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It would still be nice to have the currently unimplemented platform
> wrappers added to the standard library, though.  For example, as solinym
> pointed out, getresuid and getresgid are not currently wrapped at all. 
> There may be other low-level APIs which may be missing as well.

Ah, ok. A patch for to add these specifically would be easy to add;
contributions are welcome.

----------
title: implement new setuid-related calls and a standard way to drop all privileges -> implement new setuid-related calls and a standard way to	drop all privileges

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:43:45 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Aug 2009 20:43:45 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1250887425.53.0.20898455176.issue6508@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Would you like to work on a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Fri Aug 21 22:44:06 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 21 Aug 2009 20:44:06 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1250887446.99.0.139151357966.issue6508@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Fri Aug 21 23:11:05 2009
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 21 Aug 2009 21:11:05 +0000
Subject: [issue6743] pprint.pprint should support no objects to print blank
	lines & allow args
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1250889065.05.0.58887669858.issue6743@psf.upfronthosting.co.za>


Demur Rumed <junkmute at hotmail.com> added the comment:

I've included a patched version. I went with using a function signature
of def pprint(*object, stream=None, indent=1, width=80, depth=None)

----------
nosy: +serprex
Added file: http://bugs.python.org/file14765/pprint.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________

From report at bugs.python.org  Fri Aug 21 23:28:27 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 21 Aug 2009 21:28:27 +0000
Subject: [issue5210] zlib does not indicate end of compressed stream properly
In-Reply-To: <1234295180.57.0.273384677161.issue5210@psf.upfronthosting.co.za>
Message-ID: <1250890107.94.0.019005014931.issue5210@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Hm, I tried a modified version of your first test, and I found another 
problem with the current zlib library;
starting with the input:
x = x1 + x2 + HAMLET_SCENE    # both compressed and uncompressed data

The following scenario is OK:
dco.decompress(x) # returns HAMLET_SCENE
dco.unused_data   # returns HAMLET_SCENE

But this one:
for c in x:
    dco.decompress(x) # will return HAMLET_SCENE, in several pieces
dco.unused_data   # only one character, the last of (c in x)!

This is a bug IMO: unused_data should accumulate all the extra uncompressed 
data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5210>
_______________________________________

From report at bugs.python.org  Fri Aug 21 23:36:19 2009
From: report at bugs.python.org (=?utf-8?q?R=C3=BCdiger_Blach?=)
Date: Fri, 21 Aug 2009 21:36:19 +0000
Subject: [issue6748] test test_telnetlib failed
In-Reply-To: <1250813435.12.0.0206002518135.issue6748@psf.upfronthosting.co.za>
Message-ID: <1250890579.02.0.158307666435.issue6748@psf.upfronthosting.co.za>


Changes by R?diger Blach <ruediger.blach at hs-wismar.de>:


----------
nosy: +rb09

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6748>
_______________________________________

From report at bugs.python.org  Fri Aug 21 23:48:22 2009
From: report at bugs.python.org (John P. Speno)
Date: Fri, 21 Aug 2009 21:48:22 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1250891302.37.0.393876355832.issue4010@psf.upfronthosting.co.za>


John P. Speno <spamfilter at macspeno.com> added the comment:

Furthermore, there's another bug in setup.py  When extensions are built 
and CPPFLAGS (or other arguments) has multiple arguments, the order of 
the arguments are reversed. This is the wrong behavior. The specified 
directories should be used in the given order.

For example, if CPPFLAGS="-I/one -I/two -I/three", then when an 
extention is build, the order of the compile would be:

cc -I/three -I/two -I/one ...

There's this bit that seems reponsible in setup.py:

                    for directory in reversed(options.dirs):
                        add_dir_to_list(dir_list, directory)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Sat Aug 22 01:10:21 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 21 Aug 2009 23:10:21 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way
	to	drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250896221.99.0.112468457397.issue6758@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

This is my first stab at creating a "privilege" module that implements
the API suggested in the second aforementioned paper.

It is syntactically correct but has some TODO items in it that must be
completed before it will work.

Any suggestions on this code would be greatly appreciated.

----------
Added file: http://bugs.python.org/file14766/privilege.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Sat Aug 22 02:08:24 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 22 Aug 2009 00:08:24 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1250899704.25.0.632078251202.issue1170@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Sat Aug 22 02:16:14 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Aug 2009 00:16:14 +0000
Subject: [issue6743] pprint.pprint should support no objects to print blank
	lines & allow args
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1250900174.38.0.122470667596.issue6743@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Changing the signature of a well-used function is dangerous.
Why not add a function named pprint.print, with the exact same signature 
as __builtin__.print?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________

From report at bugs.python.org  Sat Aug 22 02:30:35 2009
From: report at bugs.python.org (Art Gillespie)
Date: Sat, 22 Aug 2009 00:30:35 +0000
Subject: [issue6518] Enable 'with' statement in ossaudiodev module
In-Reply-To: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
Message-ID: <1250901035.13.0.255191495532.issue6518@psf.upfronthosting.co.za>


Art Gillespie <agillesp at gmail.com> added the comment:

Diff attached

* Added the __enter__ and __exit__ methods to the ossaudio object.
* Updated tests so they pass (attempt to access ossaudio.closed throws
AttributeError instead of TypeError)

My first patch.  Please let me know if I did anything terrifically
stupid. :-)

----------
keywords: +patch
nosy: +agillesp
Added file: http://bugs.python.org/file14767/issue6518.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6518>
_______________________________________

From report at bugs.python.org  Sat Aug 22 04:57:45 2009
From: report at bugs.python.org (Travis H.)
Date: Sat, 22 Aug 2009 02:57:45 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way to
	drop all privileges
In-Reply-To: <4A8F06C0.2070502@v.loewis.de>
Message-ID: <20090822025740.GA11951@subspacefield.org>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

On Fri, Aug 21, 2009 at 08:42:43PM +0000, Martin v. L??wis wrote:
> 
> Martin v. L??wis <martin at v.loewis.de> added the comment:
> 
> > It would still be nice to have the currently unimplemented platform
> > wrappers added to the standard library, though.  For example, as solinym
> > pointed out, getresuid and getresgid are not currently wrapped at all. 
> > There may be other low-level APIs which may be missing as well.
> 
> Ah, ok. A patch for to add these specifically would be easy to add;
> contributions are welcome.

I kind of have two bugs going for the same thing; one is 6758 the other is 6508.

I've posted code that implements the calls using ctypes to
{get,set}res{uid,gid} in issue6758.  It's not quite done.

With regard to putting these calls into the standard library, I'm not
sure where they should go.  If I put them in os, which maps to
posixmodule.c, then I'll be adding non-POSIX calls to something
seemingly only for POSIX calls.

Also the code in there has a lot of conditional CPP logic and
interactions with the configure script.  So that could be a difficult
task to just jump into, since it has been a while since I dealt with
autoconf.

I really would like these routines exposed, but I don't know the best
way to do it and coudl use some guidance.
-- 
Obama Nation | My emails do not have attachments; it's a digital signature
that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john at subspacefield.org to get blacklisted.

----------
title: implement new setuid-related calls and a standard way to	drop all privileges -> implement new setuid-related calls and a standard way to drop all privileges

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Sat Aug 22 05:03:01 2009
From: report at bugs.python.org (Travis H.)
Date: Sat, 22 Aug 2009 03:03:01 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1250910181.83.0.104846763001.issue6508@psf.upfronthosting.co.za>


Travis H. <travis+w-python.org at subspacefield.org> added the comment:

Where would be the best place to put these non-POSIX calls?

I looked at posixmodule.c and it's a mess; much conditional CPP logic
governing what gets compiled, not clear where I should add something
like this there - if I should at all, since these routines are not POSIX
routines.

Perhaps there should be a module called Unix or something?

Also, knowing whether the functions were avaiable at compile time would
be tricky; some Unix OSes have them and others don't.  It sounds like a
job for autoconf to define HAVE_SETRESUID and other CPP definitions like
that so we can compile cleanly and portably...

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Sat Aug 22 08:13:09 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 22 Aug 2009 06:13:09 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1250921589.19.0.538422249522.issue1170@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The patch needs tests before it can be applied. Additionally, I'm not
sure if having a "utf" option is helpful. Is there a reason not to have
unicode support by default?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Sat Aug 22 08:22:02 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Sat, 22 Aug 2009 06:22:02 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>


New submission from Ryan Leslie <rylesny at gmail.com>:

The zipfile.ZipFile.open() behavior with mode 'U' or 'rU' is not quite
as advertised in

http://docs.python.org/library/zipfile.html#zipfile.ZipFile.open

Here is an example:

$ echo -ne "This is an example\r\nWhich demonstrates a problem\r\nwith
ZipFile.open(..., 'U')\r\n" > foo.txt
$ cat -v foo.txt
This is an example^M
Which demonstrates a problem^M
with ZipFile.open(..., 'U')^M
$ zip foo.zip foo.txt
  adding: foo.txt (deflated 1%)
$ python
Python 2.6.2 (r262:71600, Aug 21 2009, 17:52:12)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> open("foo.txt", 'U').read()
"This is an example\nWhich demonstrates a problem\nwith
ZipFile.open(..., 'U')\n"
>>> from zipfile import ZipFile
>>> ZipFile("foo.zip").open("foo.txt", 'U').read()
"This is an example\r\nWhich demonstrates a problem\r\nwith
ZipFile.open(..., 'U')\r\n"
>>>

The open() method was added here:

http://bugs.python.org/issue1121142

The cause is that the universal newline implementation is specific to
readline(), which also implements readlines() and next() as well.
Support was never added for read(), which is independent.

Note that test_zipfile.UniversalNewlineTests.readTest() passes. This is
suspect because it's explicitly coded to *not* expect translation of new
line sequences.

----------
components: Library (Lib)
messages: 91854
nosy: ryles
severity: normal
status: open
title: zipfile.ZipExtFile.read() is missing universal newline support
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Sat Aug 22 09:07:27 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Aug 2009 07:07:27 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1250924847.01.0.231364353483.issue6508@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, just put it near the numerous set_XXXuid functions, protected with a 
HAVE_SETRESUID macro (you will have to modify configure.in as well)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Sat Aug 22 09:20:09 2009
From: report at bugs.python.org (kai zhu)
Date: Sat, 22 Aug 2009 07:20:09 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1250925609.49.0.813798806834.issue6239@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

wrote an extension application which relies on the patch (works after 
applying patch to python 3.1.1).

it converts png images to colorized ascii-art on ansi-compatible 
terminal.  requires the patch b/c a ctype function returns a c-string w/ 
ansi-escape characters.

>>> import ctypes
>>> lib = ctypes.cdll.LoadLibrary("_asciiporn.so")
>>> lib.img_read(b"foo.png") // load png image
>>> lib.asc_itp(4, 16)       // ascii-rize algorithm
>>> lib.asc_str.restype = ctypes.c_char_p
>>> print( lib.asc_str() )   // prints out ansi-colorized ascii-art

hopefully, this is more motivation to commit the patch to trunk

----------
Added file: http://bugs.python.org/file14768/_asciiporn.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Sat Aug 22 09:22:09 2009
From: report at bugs.python.org (kai zhu)
Date: Sat, 22 Aug 2009 07:22:09 +0000
Subject: [issue6239] c_char_p return value returns string, not bytes
In-Reply-To: <1244477249.92.0.44777371921.issue6239@psf.upfronthosting.co.za>
Message-ID: <1250925729.19.0.506601972116.issue6239@psf.upfronthosting.co.za>


Changes by kai zhu <kaizhu256 at gmail.com>:


Added file: http://bugs.python.org/file14769/_asciiporn.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6239>
_______________________________________

From report at bugs.python.org  Sat Aug 22 09:27:03 2009
From: report at bugs.python.org (Shashank)
Date: Sat, 22 Aug 2009 07:27:03 +0000
Subject: [issue5007] urllib2 HTTPS connection failure (BadStatusLine Exception)
In-Reply-To: <1232408710.01.0.641128080754.issue5007@psf.upfronthosting.co.za>
Message-ID: <1250926023.29.0.51590316103.issue5007@psf.upfronthosting.co.za>


Shashank <shashank.sunny.singh at gmail.com> added the comment:

Works fine for me in 2.6 but fails as said by OP on 2.5.
(I came across this in the course of my work and am submitting a change
in a bug for the first time, pardon me if something is inappropriate :)

I used this modified codeblock:

----------
import cookielib
import urllib2

cookiejar = cookielib.LWPCookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookiejar))
url = 'https://www.orange.sk/'
req = urllib2.Request(url, None)
s=opener.open(req)
print s.read();

-------------------

2.6 gives a complete HTML page but 2.5 raises httplib.BadStatusLine
exception.

----------
nosy: +shashank

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5007>
_______________________________________

From report at bugs.python.org  Sat Aug 22 09:48:52 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 22 Aug 2009 07:48:52 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1250910181.83.0.104846763001.issue6508@psf.upfronthosting.co.za>
Message-ID: <4A8FA2E0.8070008@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Where would be the best place to put these non-POSIX calls?
> 
> I looked at posixmodule.c and it's a mess; much conditional CPP logic
> governing what gets compiled, not clear where I should add something
> like this there - if I should at all, since these routines are not POSIX
> routines.

Don't worry about that - the POSIX module is the right place, despite
it's name.

> Perhaps there should be a module called Unix or something?

That wouldn't reduce the need to remove CPP logic. I personally don't
find that CPP logic very messy - most of it is fairly clear (perhaps
with popen being the exception).

> Also, knowing whether the functions were avaiable at compile time would
> be tricky; some Unix OSes have them and others don't.

I don't understand. When you compile for a specific Unix, it either has
them or not, right? So you *can* test at compile time, and easily so
(the same way it test for about 20 other functions).

> It sounds like a
> job for autoconf to define HAVE_SETRESUID and other CPP definitions like
> that so we can compile cleanly and portably...

Correct - you need to change configure.in as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Sat Aug 22 12:40:33 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 22 Aug 2009 10:40:33 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>


New submission from Chris Rebert <pybugs at rebertia.com>:

>From what I've seen on several c.l.p threads, some people have a tough
time figuring the correct 'args' argument to subprocess.Popen's
constructor. In an effort to cut down on such discussions in the future,
I've written the attached docs patch to better explain the subject.

I'm not an rst/Sphinx guru and thus was unable to actually test the
patch, so there might be some (hopefully minor) formatting errors.

----------
assignee: georg.brandl
components: Documentation
files: subprocess.rst.patch
keywords: patch
messages: 91859
nosy: cvrebert, georg.brandl
severity: normal
status: open
title: patch to subprocess docs to better explain Popen's 'args' argument
versions: Python 2.6
Added file: http://bugs.python.org/file14770/subprocess.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6760>
_______________________________________

From report at bugs.python.org  Sat Aug 22 13:01:58 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 22 Aug 2009 11:01:58 +0000
Subject: [issue5365] add conversion table to time module docs
In-Reply-To: <1235561043.91.0.296999855786.issue5365@psf.upfronthosting.co.za>
Message-ID: <1250938918.07.0.805519069708.issue5365@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Added string conversions to table for good measure.

----------
status: closed -> open
Added file: http://bugs.python.org/file14771/table.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5365>
_______________________________________

From report at bugs.python.org  Sat Aug 22 13:04:55 2009
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 22 Aug 2009 11:04:55 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1250939095.55.0.855185125708.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6760>
_______________________________________

From report at bugs.python.org  Sat Aug 22 13:06:24 2009
From: report at bugs.python.org (Senthil)
Date: Sat, 22 Aug 2009 11:06:24 +0000
Subject: [issue5007] urllib2 HTTPS connection failure (BadStatusLine Exception)
In-Reply-To: <1232408710.01.0.641128080754.issue5007@psf.upfronthosting.co.za>
Message-ID: <1250939184.59.0.690700048466.issue5007@psf.upfronthosting.co.za>


Changes by Senthil <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5007>
_______________________________________

From report at bugs.python.org  Sat Aug 22 14:02:16 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Aug 2009 12:02:16 +0000
Subject: [issue6688] Optimize PyBytes_FromObject.
In-Reply-To: <1250026477.34.0.625583102893.issue6688@psf.upfronthosting.co.za>
Message-ID: <1250942536.59.0.243129612521.issue6688@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Nice improvement!
Beware that _PyObject_LengthHint may set an exception, though.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6688>
_______________________________________

From report at bugs.python.org  Sat Aug 22 14:51:57 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 22 Aug 2009 12:51:57 +0000
Subject: [issue6758] implement new setuid-related calls and a standard way to
	drop all privileges
In-Reply-To: <1250880577.62.0.941118593261.issue6758@psf.upfronthosting.co.za>
Message-ID: <1250945517.11.0.540822228212.issue6758@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I hope you'll also write some unit tests for privilege.py (actually, I
hope you'll do test driven development on it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6758>
_______________________________________

From report at bugs.python.org  Sat Aug 22 14:59:16 2009
From: report at bugs.python.org (CaribbeanCruise)
Date: Sat, 22 Aug 2009 12:59:16 +0000
Subject: [issue6739] IDLE window won't start or show up after assgining new
	key in options v2.5.2 and 3.1.1
In-Reply-To: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>
Message-ID: <1250945956.96.0.78418650139.issue6739@psf.upfronthosting.co.za>


CaribbeanCruise <caribbeancruise123 at gmail.com> added the comment:

Thanks for the help.

I removed that external row and now it's up and running again :D May I 
please have an explanation on what causes that behavior and why that 
solution on that file worked?

I'm just a n00b/beginner level on programming and I will someday try to 
understand that patch, how I can write that patch and put it in place to 
make it work.

Thank you very much for the help and guidance.

----------
status: open -> pending
versions: +Python 2.5 -Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6739>
_______________________________________

From report at bugs.python.org  Sat Aug 22 15:40:28 2009
From: report at bugs.python.org (Joshua Bronson)
Date: Sat, 22 Aug 2009 13:40:28 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1250948428.77.0.446601961748.issue6626@psf.upfronthosting.co.za>


Changes by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sat Aug 22 19:13:59 2009
From: report at bugs.python.org (Stephen Fairchild)
Date: Sat, 22 Aug 2009 17:13:59 +0000
Subject: [issue6761] Class calling
In-Reply-To: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>
Message-ID: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>


New submission from Stephen Fairchild <signupaddress at bethere.co.uk>:

From:
http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy

"Class instances
    Class instances are described below. Class instances are callable
only when the class has a __call__() method; x(arguments) is a shorthand
for x.__call__(arguments)."

The following program demonstrates otherwise regarding that last statement. 

def call(self):
    print "inserted __call__ in object of class A"

class A(object):
    def __call__(self):
        print "__call__ method in class A"
        
x = A()               # Equates: x = type(A).__call__(A)
x.__call__ = call

x()                   # Calls the method of class A.
x.__call__(x)         # Calls function "call".
type(x).__call__(x)   # The correct longhand of x() IMHO


If I were to rephrase the documentation:
"Class instances
    Class instances are described below. Class instances are callable
only when the class has a __call__() method; x(arguments) is a shorthand
for type(x).__call__(x, arguments)."

----------
assignee: georg.brandl
components: Documentation
messages: 91864
nosy: georg.brandl, onlyme
severity: normal
status: open
title: Class calling
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6761>
_______________________________________

From report at bugs.python.org  Sat Aug 22 19:16:55 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 22 Aug 2009 17:16:55 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1250961415.53.0.144912946443.issue2698@psf.upfronthosting.co.za>


Hagen F?rstenau <hfuerstenau at gmx.net> added the comment:

Shouldn't r73896 be backported to the 3.1 branch? I still get "Unable to
find vcvarsall.bat" with Python 3.1.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Sat Aug 22 19:38:17 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 22 Aug 2009 17:38:17 +0000
Subject: [issue6739] IDLE window won't start or show up after assgining new
	key in options v2.5.2 and 3.1.1
In-Reply-To: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>
Message-ID: <1250962697.9.0.314598932798.issue6739@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Please, understand that the bug tracker is a place to provide help and
not to seek for help. The c.l.p newsgroup (more on
http://www.python.org/community/lists/) is a more appropriate place to
continue this discussion.

Nevertheless, the attached patch was generated from python trunk so if
you want to apply it by hand you will need to check what file it changed
(first lines on it) and then check line offsets (@@ ... @@) to know
where to hand-apply each hunk. Applying any patch this way may cause
more trouble than anything else, be careful.

----------
status: pending -> open
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6739>
_______________________________________

From report at bugs.python.org  Sat Aug 22 19:49:31 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 22 Aug 2009 17:49:31 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250963371.92.0.736108929413.issue6755@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
nosy: +gpolo
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Sat Aug 22 20:13:33 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 22 Aug 2009 18:13:33 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250964813.17.0.12907606098.issue6755@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Have you looked into issue700921 already ? It seems a lot of discussion
was generated there, but no patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Sat Aug 22 20:23:25 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Sat, 22 Aug 2009 18:23:25 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1250965405.17.0.998425320029.issue6755@psf.upfronthosting.co.za>


I?igo Serna <inigoserna at gmail.com> added the comment:

Thanks for the pointer, haven't seen anything when I searched for get_wch.

The patch provided here only adds this get_wch function, because as A.M.
Kuchling explained in issue700921, it's possible to use wide chars now,
the only feature missing is get_wch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Sat Aug 22 20:26:06 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Sat, 22 Aug 2009 18:26:06 +0000
Subject: [issue700921] Wide-character curses
Message-ID: <1250965566.87.0.0827574256025.issue700921@psf.upfronthosting.co.za>


I?igo Serna <inigoserna at gmail.com> added the comment:

In issue6755 I provide a patch to support get_wch, which is the only
wide chars related feature I miss in current bindings (as python v2.6.2
or v3.1.1).

----------
nosy: +inigoserna

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue700921>
_______________________________________

From report at bugs.python.org  Sat Aug 22 20:31:43 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 22 Aug 2009 18:31:43 +0000
Subject: [issue700921] Wide-character curses
Message-ID: <1250965903.07.0.430472189705.issue700921@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Closing this in favour of issue6755, it has been a long time since any
discussion took place here that I believe it is better to continue
somewhere else related to this.

----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue700921>
_______________________________________

From report at bugs.python.org  Sat Aug 22 20:31:52 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 22 Aug 2009 18:31:52 +0000
Subject: [issue700921] Wide-character curses
Message-ID: <1250965912.37.0.780008006395.issue700921@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue700921>
_______________________________________

From report at bugs.python.org  Sat Aug 22 21:12:20 2009
From: report at bugs.python.org (Mintaka)
Date: Sat, 22 Aug 2009 19:12:20 +0000
Subject: [issue6762] strange string representation of  xrange in print
In-Reply-To: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>
Message-ID: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>


New submission from Mintaka <mintaka at post.cz>:

String representation of xrange return keyword with value.

foo = xrange(5)
print foo
>>> xrange(5)
foo.__str__() 
>>> xrange(5)

I think, that expected result should be somethink like this:
>>> <xrange object at 0x00AFB970>

----------
components: Interpreter Core
messages: 91871
nosy: mintaka
severity: normal
status: open
title: strange string representation of  xrange in print
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6762>
_______________________________________

From report at bugs.python.org  Sat Aug 22 21:14:15 2009
From: report at bugs.python.org (Mintaka)
Date: Sat, 22 Aug 2009 19:14:15 +0000
Subject: [issue6762] strange string representation of  xrange in print
In-Reply-To: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>
Message-ID: <1250968455.9.0.725585074622.issue6762@psf.upfronthosting.co.za>


Changes by Mintaka <mintaka at post.cz>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6762>
_______________________________________

From report at bugs.python.org  Sat Aug 22 21:48:01 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 22 Aug 2009 19:48:01 +0000
Subject: [issue6762] strange string representation of  xrange in print
In-Reply-To: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>
Message-ID: <1250970481.5.0.875567065855.issue6762@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

For types where it's possible, the str or repr returns a string that can
be passed to eval:

>>> for i in eval(str(xrange(5))):
...   print i
... 
0
1
2
3
4

xrange (and list, and tuple, and others) fall into this category.

----------
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6762>
_______________________________________

From report at bugs.python.org  Sat Aug 22 22:07:44 2009
From: report at bugs.python.org (Rogi)
Date: Sat, 22 Aug 2009 20:07:44 +0000
Subject: [issue6498] Py_Main() does not return on SystemExit
In-Reply-To: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
Message-ID: <1250971664.23.0.182233266824.issue6498@psf.upfronthosting.co.za>


Rogi <rogi at linuxmail.org> added the comment:

bump

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6498>
_______________________________________

From report at bugs.python.org  Sat Aug 22 22:15:37 2009
From: report at bugs.python.org (Raphaela)
Date: Sat, 22 Aug 2009 20:15:37 +0000
Subject: [issue6498] Py_Main() does not return on SystemExit
In-Reply-To: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
Message-ID: <1250972137.9.0.347067867837.issue6498@psf.upfronthosting.co.za>


Raphaela <rakeka_moore at hotmail.com> added the comment:

bump =op

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6498>
_______________________________________

From report at bugs.python.org  Sat Aug 22 22:35:05 2009
From: report at bugs.python.org (Mintaka)
Date: Sat, 22 Aug 2009 20:35:05 +0000
Subject: [issue6762] strange string representation of  xrange in print
In-Reply-To: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>
Message-ID: <1250973305.47.0.233720721584.issue6762@psf.upfronthosting.co.za>


Mintaka <mintaka at post.cz> added the comment:

Thanks for clarification. I compared it with iter([0,1,2,3,4]).__str__()
which behaviour seems to me closer then list or tuple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6762>
_______________________________________

From report at bugs.python.org  Sat Aug 22 23:17:22 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Sat, 22 Aug 2009 21:17:22 +0000
Subject: [issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
In-Reply-To: <1242858324.92.0.20433040915.issue6075@psf.upfronthosting.co.za>
Message-ID: <1250975842.5.0.838970848903.issue6075@psf.upfronthosting.co.za>


Changes by Kevin Walzer <wordtech at users.sourceforge.net>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6075>
_______________________________________

From report at bugs.python.org  Sat Aug 22 23:26:37 2009
From: report at bugs.python.org (Leonardo Santagada)
Date: Sat, 22 Aug 2009 21:26:37 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>


New submission from Leonardo Santagada <santagada at gmail.com>:

Python 2.6.2 (and the maint branch if using old mimetypes.py) crash
(with a bus error) on mac os x (10.5.7 & 10.5.8) with the file I posted.
The problem appears to be in the allocation of memory by the GC.

What I do is I call mimetypes.guess_type in more than one thread at the
same time, then I guess what is happening is this:

1. The first thread to run notices mimetypes.inited is false so it call
its init funtion.
2. Somehow the first thread loses the gil while still executing the init
3. Another thread tries to execute guess_type as it is already inited it
calls itself, in vain as the init still hasn't exchanged it value for
the new function so it goes into recursion
4. Somehow the allocator fails during the recursion

here is the final pieces of my stack trace (its a very long sequence of
recursions into guess_type):

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0xb0000ffc
[Switching to process 61544 thread 0x117]
0x96912122 in szone_malloc ()

#0  0x96912122 in szone_malloc ()
#1  0x969120d8 in malloc_zone_malloc ()
#2  0x9691206c in malloc ()
#3  0x0006f32c in PyObject_Malloc (nbytes=376) at Objects/obmalloc.c:913
913             return (void *)malloc(nbytes);
#4  0x0006fe61 in _PyObject_DebugMalloc (nbytes=360) at
Objects/obmalloc.c:1347
1347            p = (uchar *)PyObject_Malloc(total);
#5  0x00149b13 in _PyObject_GC_Malloc (basicsize=344) at
Modules/gcmodule.c:1351
1351            g = (PyGC_Head *)PyObject_MALLOC(
#6  0x00149c24 in _PyObject_GC_NewVar (tp=0x193500, nitems=5) at
Modules/gcmodule.c:1383
1383            PyVarObject *op = (PyVarObject *) _PyObject_GC_Malloc(size);
#7  0x00048a06 in PyFrame_New (tstate=0x33df30, code=0x473148,
globals=0x48e380, locals=0x0) at Objects/frameobject.c:642
642                         f = PyObject_GC_NewVar(PyFrameObject,
&PyFrame_Type,
#8  0x00100816 in PyEval_EvalCodeEx (co=0x473148, globals=0x48e380,
locals=0x0, args=0x374fb4, argcount=2, kws=0x374fbc, kwcount=0,
defs=0x4a6f9c, defcount=1, closure=0x0) at Python/ceval.c:2755
2755            f = PyFrame_New(tstate, co, globals, locals);

----------
components: Interpreter Core
messages: 91876
nosy: santagada
severity: normal
status: open
title: Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Sat Aug 22 23:58:20 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 22 Aug 2009 21:58:20 +0000
Subject: [issue6764] os.path.join should call os.path.normpath on result
In-Reply-To: <1250978300.82.0.388700146975.issue6764@psf.upfronthosting.co.za>
Message-ID: <1250978300.82.0.388700146975.issue6764@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

os.path.join has very basic behavior in the handling of '..'

>>> import os
>>> os.path.join('/foo', '..')
'/foo/..'

For some usecases (comparing paths for example) this is not useful and
you have to manually call normpath on the results:

>>> os.path.normpath(os.path.join('/foo', '..'))
'/'

Because of this code gets littered with annoyingly long chained calls
which are a pain to both read and write.

Is there any problem with join always calling normpath on it's result?

----------
components: Library (Lib)
keywords: easy
messages: 91877
nosy: michael.foord
severity: normal
status: open
title: os.path.join should call os.path.normpath on result
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6764>
_______________________________________

From report at bugs.python.org  Sun Aug 23 00:21:51 2009
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 22 Aug 2009 22:21:51 +0000
Subject: [issue6762] strange string representation of  xrange in print
In-Reply-To: <1250968340.58.0.478477907223.issue6762@psf.upfronthosting.co.za>
Message-ID: <1250979711.25.0.131331828334.issue6762@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur with Eric.  The eval(repr(obj)) should be made to work when
possible.  We do this with itertools.count() and other places where it
makes sense.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6762>
_______________________________________

From report at bugs.python.org  Sun Aug 23 00:36:29 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 22 Aug 2009 22:36:29 +0000
Subject: [issue6764] os.path.join should call	os.path.normpath on result
In-Reply-To: <1250978300.82.0.388700146975.issue6764@psf.upfronthosting.co.za>
Message-ID: <4A9072EA.5080501@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is there any problem with join always calling normpath on it's result?

Yes. If /usr/local/bin was a symlink to /net/x86, then
/usr/local/bin/../lib might not be /usr/local/lib, but /net/lib. So
calling normpath in the presence of symlinks might be incorrect.

----------
nosy: +loewis
title: os.path.join should call os.path.normpath on result -> os.path.join should call	os.path.normpath on result

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6764>
_______________________________________

From report at bugs.python.org  Sun Aug 23 00:37:43 2009
From: report at bugs.python.org (Art Gillespie)
Date: Sat, 22 Aug 2009 22:37:43 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1250980663.85.0.513462627882.issue6759@psf.upfronthosting.co.za>


Art Gillespie <agillesp at gmail.com> added the comment:

Patch for both zipfile.py and test_zipfile.py attached.

* The universal newline logic is now in read instead of readline.
* UniversalNewlineTests.read_test changed to check for \n rather than
unchanged eol.

----------
keywords: +patch
nosy: +agillesp
type:  -> behavior
Added file: http://bugs.python.org/file14772/issue6759_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Sun Aug 23 00:48:41 2009
From: report at bugs.python.org (Michael Foord)
Date: Sat, 22 Aug 2009 22:48:41 +0000
Subject: [issue6764] os.path.join should call	os.path.normpath on result
In-Reply-To: <1250978300.82.0.388700146975.issue6764@psf.upfronthosting.co.za>
Message-ID: <1250981321.09.0.841385311093.issue6764@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Damn. :-)

Detecting the case where the normpath'd location is the same means
hitting the filesystem - and the current version just does string
manipulation so it doesn't seem like an acceptable change.

Still, compared to other languages the file handling in Python (spread
across os, os.path, shutil, stat) is clunky and verbose. Fixing that
means duplicating this functionality which makes it unlikely that we'll
get it in the standard library.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6764>
_______________________________________

From report at bugs.python.org  Sun Aug 23 01:58:27 2009
From: report at bugs.python.org (Jessica McKellar)
Date: Sat, 22 Aug 2009 23:58:27 +0000
Subject: [issue2560] removal of stale code from myreadline.c
In-Reply-To: <1207447225.31.0.495506522061.issue2560@psf.upfronthosting.co.za>
Message-ID: <1250985507.8.0.130158591353.issue2560@psf.upfronthosting.co.za>


Jessica McKellar <jessica.mckellar at gmail.com> added the comment:

Here's an updated patch against trunk that has 8 space tabs and doesn't
remove some of the existing comments like the other patch did. I checked
that the patch applies and that re-building doesn't error.

----------
nosy: +jesstess
versions: +Python 3.2
Added file: http://bugs.python.org/file14773/myreadline-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2560>
_______________________________________

From report at bugs.python.org  Sun Aug 23 02:46:28 2009
From: report at bugs.python.org (Joshua Bronson)
Date: Sun, 23 Aug 2009 00:46:28 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1250988388.3.0.904396768631.issue6763@psf.upfronthosting.co.za>


Changes by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Sun Aug 23 04:16:00 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Aug 2009 02:16:00 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1250993760.07.0.150487875991.issue6763@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Seems like issue 6626 could be helpful here.

----------
nosy: +r.david.murray
priority:  -> high
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Sun Aug 23 04:17:03 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Aug 2009 02:17:03 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1250993823.44.0.0647030756625.issue6763@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jrus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Sun Aug 23 04:17:37 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Aug 2009 02:17:37 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1250993857.78.0.0232317383417.issue6626@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 6763.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6626>
_______________________________________

From report at bugs.python.org  Sun Aug 23 04:49:24 2009
From: report at bugs.python.org (Leonardo Santagada)
Date: Sun, 23 Aug 2009 02:49:24 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1250995764.44.0.834678741987.issue6763@psf.upfronthosting.co.za>


Leonardo Santagada <santagada at gmail.com> added the comment:

Well, the mimetypes module from 2.6 maintenance branch make this problem
not show up with mimetypes.guess_type, but I still think this is a bug
because pure python code should not crash the interpreter right?

I'm attaching the file I mentioned, I hope this counts as a test (it
needs the mimetypes module from python 2.6.2). I can probably extract
just the needed functions from the old mimetypes module if requested.

----------
Added file: http://bugs.python.org/file14774/threadboom.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Sun Aug 23 05:09:25 2009
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 23 Aug 2009 03:09:25 +0000
Subject: [issue6739] IDLE window won't start or show up after assgining new
	key in options v2.5.2 and 3.1.1
In-Reply-To: <1250757080.7.0.965993936336.issue6739@psf.upfronthosting.co.za>
Message-ID: <1250996965.28.0.646565057181.issue6739@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


----------
stage: needs patch -> 
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6739>
_______________________________________

From report at bugs.python.org  Sun Aug 23 13:56:17 2009
From: report at bugs.python.org (steve21)
Date: Sun, 23 Aug 2009 11:56:17 +0000
Subject: [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

$ python3.1
Python 3.1 (r31:73572, Jul  6 2009, 21:21:12) 
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log10(1000)
3.0
>>> math.log(1000, 10)
2.9999999999999996

You would expect the results to be the same.
Internally math.log() could call math.log10() when base==10. That would
ensure they are consistent.

----------
components: Library (Lib)
messages: 91886
nosy: steve21
severity: normal
status: open
title: math.log, log10 inconsistency
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6765>
_______________________________________

From report at bugs.python.org  Sun Aug 23 14:25:47 2009
From: report at bugs.python.org (Daniel Harding)
Date: Sun, 23 Aug 2009 12:25:47 +0000
Subject: [issue4485] fast swap of "default" Windows python versions
In-Reply-To: <1228207919.66.0.730717066553.issue4485@psf.upfronthosting.co.za>
Message-ID: <1251030347.72.0.954643670926.issue4485@psf.upfronthosting.co.za>


Daniel Harding <dharding at gmail.com> added the comment:

I have created a script that does essentially what Mark Tolonen
suggests.  When it is provided a script to run, it looks for a #! line
and if it exists, attempts to use that to determine which version of
python.exe to use.  It also has the ability to install itself as the
default command for running .py files in the Windows registry.

Feedback welcome.

----------
Added file: http://bugs.python.org/file14775/python_runner.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4485>
_______________________________________

From report at bugs.python.org  Sun Aug 23 17:22:53 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Aug 2009 15:22:53 +0000
Subject: [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251040973.02.0.949878652648.issue6765@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Well, that's floating-point arithmetic for you.  log(x, y) simply computes 
log(x)/log(y) behind the scenes; since both log computations and the 
floating-point division can introduce errors, the result will frequently 
not be correctly rounded.

I don't really see the benefit of special-casing log(x, 10).  In what 
circumstances does it matter that log(x, 10) != log10(x)?  I could 
understand people being upset that log(10**n, 10) doesn't return n 
exactly, but that's what log10 is there for.

See also the discussion in issue 3724.

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6765>
_______________________________________

From report at bugs.python.org  Sun Aug 23 19:46:30 2009
From: report at bugs.python.org (Carlos)
Date: Sun, 23 Aug 2009 17:46:30 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>


New submission from Carlos <carlosdf at gmail.com>:

It's not possible to modify a dict inside a dict using a manager from 
multiprocessing.

Ex:

from multiprocessing import Process,Manager

def f(d):
    d['1'] = '1'
    d['2']['1'] = 'Try To Write'

if __name__ == '__main__':
    manager = Manager()

    d = manager.dict()

    d['2'] = manager.dict()

    print d

    p = Process(target=f, args=(d,))
    p.start()
    p.join()

    print d

    d['2'] = 5
    print d

The output Under Windows 7 (32 Bits) / Python 2.6.2 (32 Bits) is:

{'2': {}}
{'1': '1', '2': {}}
{'1': '1', '2': 5}

The output is the same if you change "d['2'] = manager.dict()" to 
"d['2'] = dict()"

----------
messages: 91889
nosy: carlosdf
severity: normal
status: open
title: Cannot modify dictionaries inside dictionaries using Managers from multiprocessing
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Sun Aug 23 20:59:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Aug 2009 18:59:19 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1251053959.24.0.836666449021.issue6766@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Sun Aug 23 21:18:04 2009
From: report at bugs.python.org (Joe)
Date: Sun, 23 Aug 2009 19:18:04 +0000
Subject: [issue6767] Python as zip package
In-Reply-To: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>
Message-ID: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>


New submission from Joe <us3r07 at web.de>:

It would be nice, if you could offer the Windows version also as a zi
package, besides the msi installer.

----------
components: Windows
messages: 91890
nosy: Joe
severity: normal
status: open
title: Python as zip package
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6767>
_______________________________________

From report at bugs.python.org  Sun Aug 23 21:19:53 2009
From: report at bugs.python.org (Joe)
Date: Sun, 23 Aug 2009 19:19:53 +0000
Subject: [issue6767] Python as zip package
In-Reply-To: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>
Message-ID: <1251055193.13.0.790978536109.issue6767@psf.upfronthosting.co.za>


Joe <us3r07 at web.de> added the comment:

I meant as a zip archive package

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6767>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:02:35 2009
From: report at bugs.python.org (Daniel Keysers)
Date: Sun, 23 Aug 2009 21:02:35 +0000
Subject: [issue6768] asyncore file_wrapper leaking file descriptors?
In-Reply-To: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>
Message-ID: <1251061355.88.0.439878311774.issue6768@psf.upfronthosting.co.za>


New submission from Daniel Keysers <dkeysers at gmail.com>:

I'm not very experienced in Python, but while tracking down an issue 
with a "too many open files" error I think I found a missing resource 
release in asyncore's file_wrapper. Since Rev. 64062 added the os.dup() 
in __init__ this class reads as follows:

if os.name == 'posix':
    import fcntl

    class file_wrapper:
        # Here we override just enough to make a file
        # look like a socket for the purposes of asyncore.
        # The passed fd is automatically os.dup()'d

        def __init__(self, fd):
            self.fd = os.dup(fd)

        def recv(self, *args):
            return os.read(self.fd, *args)

        def send(self, *args):
            return os.write(self.fd, *args)

        read = recv
        write = send

        def close(self):
            os.close(self.fd)

        def fileno(self):
            return self.fd


I think that a "def __del__(self): self.close()" or a variant thereof 
would solve the problem I was seeing since it would release the file 
descriptor acquired in __init__ by os.dup(). But since I don't know why 
the os.dup() was added in the first place I'm not sure if there aren't 
any arguments against this release. Any comment appreciated!

----------
components: Library (Lib)
messages: 91892
nosy: keysers
severity: normal
status: open
title: asyncore file_wrapper leaking file descriptors?
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6768>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:17:29 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 23 Aug 2009 21:17:29 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1251062249.72.0.654097569767.issue6749@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Some (supportive) discussion on python-dev at
http://mail.python.org/pipermail/python-dev/2009-August/091324.html .

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:19:17 2009
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 23 Aug 2009 21:19:17 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1251062357.9.0.452755110091.issue6749@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:42:05 2009
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Sun, 23 Aug 2009 21:42:05 +0000
Subject: [issue1875] "if 0: return" not raising SyntaxError
In-Reply-To: <1200768950.55.0.245752373825.issue1875@psf.upfronthosting.co.za>
Message-ID: <1251063725.04.0.36053285528.issue1875@psf.upfronthosting.co.za>


Changes by Lino Mastrodomenico <l.mastrodomenico at gmail.com>:


----------
nosy: +mastrodomenico

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1875>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:47:50 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 23 Aug 2009 21:47:50 +0000
Subject: [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251064070.27.0.959094629663.issue6765@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6765>
_______________________________________

From report at bugs.python.org  Sun Aug 23 23:48:44 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 23 Aug 2009 21:48:44 +0000
Subject: [issue6767] Python as zip package
In-Reply-To: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>
Message-ID: <1251064124.66.0.814723339055.issue6767@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why would you want to have such a thing?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6767>
_______________________________________

From report at bugs.python.org  Mon Aug 24 00:20:13 2009
From: report at bugs.python.org (ivank)
Date: Sun, 23 Aug 2009 22:20:13 +0000
Subject: [issue6769] in xmlrpclib.py: NameError: global name 'HTTPSConnection'
	is not defined
In-Reply-To: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>
Message-ID: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>


New submission from ivank <ivan at ludios.org>:

Line 1491 of xmlrpclib.py should be

self._connection = host, httplib.HTTPSConnection(chost, None, **(x509 or
{}))

instead of

self._connection = host, HTTPSConnection(chost, None, **(x509 or {}))

  File
"/opt/Python-latest/lib/python2.7/site-packages/bzrlib/plugins/launchpad/lp_registration.py",
line 166, in send_request
    result = method(*method_params)
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1224, in
__call__
    return self.__send(self.__name, args)
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1570, in
__request
    verbose=self.__verbose
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1264, in
request
    return self.single_request(host, handler, request_body, verbose)
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1284, in
single_request
    h = self.make_connection(host)
  File "/opt/Python-latest/lib/python2.7/xmlrpclib.py", line 1491, in
make_connection
    self._connection = host, HTTPSConnection(chost, None, **(x509 or {}))
NameError: global name 'HTTPSConnection' is not defined

bzr 1.15 on python 2.7a0 (linux2)


I think this has been broken for around two weeks, maybe more. I don't
know if this is broken in 3.x.

----------
components: Library (Lib)
messages: 91895
nosy: ivank
severity: normal
status: open
title: in xmlrpclib.py: NameError: global name 'HTTPSConnection' is not defined
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6769>
_______________________________________

From report at bugs.python.org  Mon Aug 24 00:28:21 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 23 Aug 2009 22:28:21 +0000
Subject: [issue6769] in xmlrpclib.py: NameError: global name 'HTTPSConnection'
	is not defined
In-Reply-To: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>
Message-ID: <1251066501.4.0.634395798935.issue6769@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +krisvale
priority:  -> normal
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6769>
_______________________________________

From report at bugs.python.org  Mon Aug 24 01:46:39 2009
From: report at bugs.python.org (Peter Manis)
Date: Sun, 23 Aug 2009 23:46:39 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1251071199.81.0.217309523248.issue6749@psf.upfronthosting.co.za>


Peter Manis <peter.manis at gmail.com> added the comment:

I don't think I will be able to provide a patch.  If I am correct this 
would live in Modules/zipimport.c and I do not have enough experience in 
C/C++ to add in the feature.  If in the end zipimport ends up using 
Lib/zipfile.py then I can work on adding the feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Mon Aug 24 03:05:32 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 24 Aug 2009 01:05:32 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1251075932.67.0.0659537823242.issue6749@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The decryption provided by the zipfile module is for the worthless
32-bit crc based "encryption" of zipfiles.  I think promoting the use of
that is a bad idea.

zipfile can be used by people to get their data out of such files.  We
should not encourage them to put it and/or their code into such a stupid
format.

-1 on supporting this.

Anyways as to implementation details, yes you'd need a way to accept a
key on the command line (or prompt for it using getpass?) and pass it to
the import mechanism at import time.  For zip files with only the
contained file data "encrypted" (the only thing the zipfile module
supports) a zip file could be checked for __init__.py and .py files
without decrypting first so that a password is only prompted for when
such a module is imported.

Again I don't see value in that.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Mon Aug 24 03:18:43 2009
From: report at bugs.python.org (Radiant)
Date: Mon, 24 Aug 2009 01:18:43 +0000
Subject: [issue6770] PDF download links of docs for 3.1.1 are broken
In-Reply-To: <1251076723.7.0.569922214039.issue6770@psf.upfronthosting.co.za>
Message-ID: <1251076723.7.0.569922214039.issue6770@psf.upfronthosting.co.za>


New submission from Radiant <newyorkdude999 at yahoo.com>:

At this time I cannot download any of the PDF documentation files for
Python 3.1.1 because I get the "Not Found" error for all four of them.
I'm referring to the files linked at
http://docs.python.org/3.1/download.html

----------
assignee: georg.brandl
components: Documentation
messages: 91898
nosy: Radiant, georg.brandl
severity: normal
status: open
title: PDF download links of docs for 3.1.1 are broken
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6770>
_______________________________________

From report at bugs.python.org  Mon Aug 24 04:01:57 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 24 Aug 2009 02:01:57 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1251079317.83.0.613030540168.issue6749@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

You would also run in to the usual problems with any form of DRM: the
password *will* exist in memory in order for zipimport to be able to use
it, so anyone that really wants the password will be able to get hold of it.

It also isn't as simple as just providing a single password - there can
be multiple zip files on sys.path, so how is Python meant to know which
password goes with which zipfile?

Another -1 here.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Mon Aug 24 04:04:22 2009
From: report at bugs.python.org (steve21)
Date: Mon, 24 Aug 2009 02:04:22 +0000
Subject: [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251079462.94.0.0327266370214.issue6765@psf.upfronthosting.co.za>


steve21 <steve872929-bv at yahoo.com.au> added the comment:

Mark,
"... that's what log10 is there for". That would be a good point if the
documentation said that. However, all the docs for log10 say is:

math.log10(x)
    Return the base-10 logarithm of x.

So we have a python function log10() which looks like it is redundant
since we can use log(a, 10) instead. But it actually functions
differently to log(a, 10), and the Python user would never know this
from looking at the documentation.

I think Tim Peters missed one important guideline in his "The Zen of
Python". The principle of least astonishment (or surprise) - when two
elements of an interface conflict, or are ambiguous, the behaviour
should be that which will least surprise the human user or programmer at
the time the conflict arises.

Its easy for the python developer to ignore this guideline. They know
the implementation, and are rarely surprised by inconsistent behaviour
since they have seen it before, or even created it without documenting it.

If Python functions are inconsistent then I think they should either be
made consistent, or if that's not possible they should be clearly
documented as being inconsistent.

The docs for log(x[, base]) could be improved to say:
"this function preserves the consistency of log(a,b) == log(a)/log(b)
but breaks consistency with log(a,10) == log10(a)"

The docs for log10(x) could be improved to say:
"this function gives the correct result for powers of 10,
but breaks consistency with log(a,10) == log10(a)"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6765>
_______________________________________

From report at bugs.python.org  Mon Aug 24 04:26:05 2009
From: report at bugs.python.org (Peter Manis)
Date: Mon, 24 Aug 2009 02:26:05 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1251080765.22.0.00571906447411.issue6749@psf.upfronthosting.co.za>


Peter Manis <peter.manis at gmail.com> added the comment:

My thinking behind this was not to be the ultimate security against 
someone getting the source, but more of a very high wall to keep out the 
majority of people.

It seems like the best way to determine what file should be decrypted 
and when a password should be prompted is to look at the header of the 
zip file where it defines the encryption information as the zip file is 
loaded.  Taking that approach would allow someone, if they wanted, to 
put multiple encrypted zip files in the path and be prompted for each 
one.  That is not my planned usage of it, but someone else may have a 
use for that.

Could someone point me in the right direction on where this 
functionality would live if implemented?  In the event there is enough 
votes to prevent it from being added I would like to try to work on it 
so I can patch my own installations of Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Mon Aug 24 08:21:04 2009
From: report at bugs.python.org (Joe)
Date: Mon, 24 Aug 2009 06:21:04 +0000
Subject: [issue6767] Python as zip package
In-Reply-To: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>
Message-ID: <1251094864.83.0.56255476089.issue6767@psf.upfronthosting.co.za>


Joe <us3r07 at web.de> added the comment:

Because, I don't need/want an installation. I only need the files whith
its directory structure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6767>
_______________________________________

From report at bugs.python.org  Mon Aug 24 09:33:56 2009
From: report at bugs.python.org (steve21)
Date: Mon, 24 Aug 2009 07:33:56 +0000
Subject: [issue6771] documentation/implementation error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>


New submission from steve21 <steve872929-bv at yahoo.com.au>:

The documentation and implementation disagree.

Documentation:
"Module curses.wrapper
    Convenience function to ensure proper terminal setup and resetting
on application entry and exit.
...

15.10. curses.wrapper ? Terminal handler for curses programs

This module supplies one function, wrapper() ...

curses.wrapper.wrapper(func, ...)
    Wrapper function that initializes curses ..
"

Implementation:
$ python3.1
Python 3.1.1 (r311:74480, Aug 24 2009, 14:50:57)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses.wrapper as cw
>>> cw.wrapper
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'function' object has no attribute 'wrapper'


The 'curses.wrapper.wrapper' function no longer exists.
The 'curses.wrapper' module no longer exists, the module is now a function.

The problem is the line
  from curses.wrapper import wrapper
in curses/__init__.py - curses has clobbered its own namespace and made
the curses.wrapper module inaccessible.

Instead of this tortuous sequence of module hiding and namespace
clobbering it would be simpler to just place the curses.wrapper.wrapper
function in curses/__init__.py and do away with the need for the
curses.wrapper single-function-module.
And update the docs so:
  references to the curses.wrapper module are removed
  the function curses.wrapper.wrapper(func, ...) becomes
               curses.wrapper.(func, ...)

----------
components: Library (Lib)
messages: 91903
nosy: steve21
severity: normal
status: open
title: documentation/implementation error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________

From report at bugs.python.org  Mon Aug 24 09:40:39 2009
From: report at bugs.python.org (Mintaka)
Date: Mon, 24 Aug 2009 07:40:39 +0000
Subject: [issue6772] Missing alias  utf-8 in  Standard Encodings list.
In-Reply-To: <1251099639.65.0.386311489493.issue6772@psf.upfronthosting.co.za>
Message-ID: <1251099639.65.0.386311489493.issue6772@psf.upfronthosting.co.za>


New submission from Mintaka <mintaka at post.cz>:

On page 
http://docs.python.org/dev/3.0/library/codecs.html#standard-encodings
(and on the pages for older versions too)
in the table with review, is missing higly used alias "utf-8"

On that row is only:
Codec 	Aliases 	Languages
utf_8 	U8, UTF, utf8 	all languages
And probably there should be:
utf_8 	U8, UTF, utf8, utf-8 	all languages

----------
assignee: georg.brandl
components: Documentation
messages: 91904
nosy: georg.brandl, mintaka
severity: normal
status: open
title: Missing alias  utf-8 in  Standard Encodings list.
versions: Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6772>
_______________________________________

From report at bugs.python.org  Mon Aug 24 09:44:13 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 24 Aug 2009 07:44:13 +0000
Subject: [issue6772] Missing alias  utf-8 in  Standard Encodings list.
In-Reply-To: <1251099639.65.0.386311489493.issue6772@psf.upfronthosting.co.za>
Message-ID: <1251099853.2.0.762790979607.issue6772@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

>From the quoted page:

"""
Notice that spelling alternatives that only differ in case or use a
hyphen instead of an underscore are also valid aliases.
"""

----------
nosy: +lemburg
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6772>
_______________________________________

From report at bugs.python.org  Mon Aug 24 09:55:18 2009
From: report at bugs.python.org (Mintaka)
Date: Mon, 24 Aug 2009 07:55:18 +0000
Subject: [issue6772] Missing alias  utf-8 in  Standard Encodings list.
In-Reply-To: <1251099639.65.0.386311489493.issue6772@psf.upfronthosting.co.za>
Message-ID: <1251100518.0.0.0758208625411.issue6772@psf.upfronthosting.co.za>


Mintaka <mintaka at post.cz> added the comment:

True, but this one is much more used then others. So frequently, that
look like other names are aliases. Maybe it is good reason to mention it
explicitly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6772>
_______________________________________

From report at bugs.python.org  Mon Aug 24 10:12:56 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 08:12:56 +0000
Subject: [issue6005] Bug in socket example
In-Reply-To: <1242137945.24.0.461546436751.issue6005@psf.upfronthosting.co.za>
Message-ID: <1251101576.67.0.252609297067.issue6005@psf.upfronthosting.co.za>


Nicolas Dumazet <nicdumz at gmail.com> added the comment:

I'm including a patch which replaces send by sendall in the examples in
both socket and socketserver.

----------
keywords: +patch
nosy: +nicdumz
Added file: http://bugs.python.org/file14776/socket.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6005>
_______________________________________

From report at bugs.python.org  Mon Aug 24 10:16:08 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 24 Aug 2009 08:16:08 +0000
Subject: [issue6767] Python as zip package
In-Reply-To: <1251055084.86.0.380611427173.issue6767@psf.upfronthosting.co.za>
Message-ID: <1251101768.64.0.367340336507.issue6767@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah, for that, run "msiexec /a pythonXY.msi TARGETDIR=K:\". This just
unpacks the MSI file, without installing anything. See

http://www.python.org/download/releases/2.4/msi/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6767>
_______________________________________

From report at bugs.python.org  Mon Aug 24 10:22:15 2009
From: report at bugs.python.org (Colin Alston)
Date: Mon, 24 Aug 2009 08:22:15 +0000
Subject: [issue1117601] os.path.exists returns false negatives in MAC
	environments.
Message-ID: <1251102135.06.0.915245179771.issue1117601@psf.upfronthosting.co.za>


Colin Alston <colin.alston at gmail.com> added the comment:

I also hit upon this issue and IMHO returning False in a "permission
denied" scenario is less than obvious behaviour. 

It also means I have no way to catch this edge case in my own code
immediately, I have to implement far larger logic to check now if False
means the file doesn't exist, or if the user doesn't have access to the
file. 

os.path.exists should absolutely raise a Permission exception.

----------
nosy: +cda32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1117601>
_______________________________________

From report at bugs.python.org  Mon Aug 24 10:36:05 2009
From: report at bugs.python.org (Piotr Foltyn)
Date: Mon, 24 Aug 2009 08:36:05 +0000
Subject: [issue6773] subprocess issue on Win 7 x64
In-Reply-To: <1251102965.83.0.35212908562.issue6773@psf.upfronthosting.co.za>
Message-ID: <1251102965.83.0.35212908562.issue6773@psf.upfronthosting.co.za>


New submission from Piotr Foltyn <piotr.foltyn at displaylink.com>:

The sample code presented below produces error (screenshot available in 
attachment) on Windows 7 RC x64 with latest version of Python 2.6 
installed. Both 32bit and 64bit versions of Python 2.6 are affected by 
this issue. Python 3 executes this code flawlessly.
The problem seems to be related to stdout redirection. If the "stdout = 
PIPE" is omitted in the first statement of main() function, code 
executes properly but we don't have access to the processes output. If 
the line "Popen(["dir"], stdout = PIPE, shell = True)" is changed to 
"sin, sout = os.popen2(["dir"])" and os module is imported everything 
works fine. It doesn't matter what command is executed ("dir", "bcedit", 
"mspaint" etc)


import sys
from subprocess import Popen, PIPE
from multiprocessing import Process

def myProcess():
    Popen(["dir"], shell = True) # ERROR :(

def main():
    Popen(["dir"], stdout = PIPE, shell = True)
    Process(target = myProcess).start()
    return 0

if __name__ == "__main__":
    sys.exit(main())

----------
components: Library (Lib), Windows
files: Win7RCx64.jpg
messages: 91910
nosy: tesla
severity: normal
status: open
title: subprocess issue on Win 7 x64
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14777/Win7RCx64.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6773>
_______________________________________

From report at bugs.python.org  Mon Aug 24 10:44:42 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 24 Aug 2009 08:44:42 +0000
Subject: [issue6769] in xmlrpclib.py: NameError: global name 'HTTPSConnection'
	is not defined
In-Reply-To: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>
Message-ID: <1251103482.06.0.858260549832.issue6769@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Kristjan, can you take a look?

----------
assignee:  -> krisvale
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6769>
_______________________________________

From report at bugs.python.org  Mon Aug 24 10:45:21 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 08:45:21 +0000
Subject: [issue6774] socket.shudown documentation: on some platforms,
	closing one half closes the other half
In-Reply-To: <1251103521.34.0.917057608479.issue6774@psf.upfronthosting.co.za>
Message-ID: <1251103521.34.0.917057608479.issue6774@psf.upfronthosting.co.za>


New submission from Nicolas Dumazet <nicdumz at gmail.com>:

I had a bad time understanding what happens in Mac OS X after a shutdown
call: after calling shutdown(SH_WR) on side A, a corresponding
shutdown(SH_RD) on side B would raise a socket.error: socket is not
connected.
It is quite surprising when you are used to sockets in Linux, which
expect you to shut one end, and then the other one.

It turns out that under Mac OS X, a shutdown call closes the connection
on the other half. And the only mention I could find of this behavior
was here, r68611 :
http://svn.python.org/view/python/trunk/Lib/test/test_socket.py?r1=64125&r2=68611&pathrev=68611

I think that the documentation should specify that (surprising)
behavior: I attached a patch explaining that detail.


Thanks!

----------
assignee: georg.brandl
components: Documentation
files: socketshutdown.patch
keywords: patch
messages: 91912
nosy: georg.brandl, nicdumz
severity: normal
status: open
title: socket.shudown documentation: on some platforms, closing one half closes the other half
type: behavior
Added file: http://bugs.python.org/file14778/socketshutdown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6774>
_______________________________________

From report at bugs.python.org  Mon Aug 24 11:02:18 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 09:02:18 +0000
Subject: [issue6775] readme: correct python.org/community/lists url
In-Reply-To: <1251104538.03.0.409360254575.issue6775@psf.upfronthosting.co.za>
Message-ID: <1251104538.03.0.409360254575.issue6775@psf.upfronthosting.co.za>


New submission from Nicolas Dumazet <nicdumz at gmail.com>:

README shows http://www.python.org/community/lists.html as an URL for
mailing list details, but it should be
http://www.python.org/community/lists/

Attaching a patch.

----------
assignee: georg.brandl
components: Documentation
files: readme-url-mls.patch
keywords: patch
messages: 91913
nosy: georg.brandl, nicdumz
severity: normal
status: open
title: readme: correct python.org/community/lists url
Added file: http://bugs.python.org/file14779/readme-url-mls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6775>
_______________________________________

From report at bugs.python.org  Mon Aug 24 13:34:48 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 24 Aug 2009 11:34:48 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1251113688.62.0.66627179959.issue4879@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Gregory, please revert your change (74463).
There is no "extra data" after the response, since such data can only 
be generated as a result of a new "request".

Your change has disabled the HTTP/1.1 keepalive capability, causing 
test failurres in xmlrpc.  Also showing perhaps that we need test cases 
for keepalive in regular httplib.py testsuite.

If you think there are problems, you a new defect should be created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Mon Aug 24 13:42:45 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 24 Aug 2009 11:42:45 +0000
Subject: [issue6769] in xmlrpclib.py: NameError: global name 'HTTPSConnection'
	is not defined
In-Reply-To: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>
Message-ID: <1251114165.39.0.293120553529.issue6769@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Thanks, that's a silly bug.  fixed in revision 74543.
Perhaps we need a https regression test in the test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6769>
_______________________________________

From report at bugs.python.org  Mon Aug 24 13:43:40 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 24 Aug 2009 11:43:40 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1251114220.96.0.353147163131.issue6499@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Any news on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Mon Aug 24 14:55:51 2009
From: report at bugs.python.org (Vlastimil Brom)
Date: Mon, 24 Aug 2009 12:55:51 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1251118551.67.0.263524283717.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I'd like to add some detail to the previous msg91473

The current behaviour of the character properties looks a bit 
surprising sometimes:

>>> 
>>> regex.findall(ur"\p{UppercaseLetter}", u"QW\p{UppercaseLetter}as")
[u'Q', u'W', u'U', u'L']
>>> regex.findall(ur"\p{Uppercase Letter}", u"QW\p{Uppercase Letter}as")
[u'\\p{Uppercase Letter}']
>>> regex.findall(ur"\p{Uppercase???Letter}", u"QW\p
{Uppercase???Letter}as")
[u'\\p{Uppercase\xc4\xc4\xc4Letter}']
>>> regex.findall(ur"\p{UppercaseQQQLetter}", u"QW\p
{UppercaseQQQLetter}as")

Traceback (most recent call last):
  File "<pyshell#34>", line 1, in <module>
    regex.findall(ur"\p{UppercaseQQQLetter}", u"QW\p
{UppercaseQQQLetter}as")
...
  File "C:\Python26\lib\regex.py", line 1178, in _parse_property
    raise error("undefined property name '%s'" % name)
error: undefined property name 'UppercaseQQQLetter'
>>> 

i.e. potential property names consisting only from the ascii-letters  
(+ _, -) are looked up and either used or an error is raised,
other names (containing whitespace or non-ascii letters) aren't treated 
as a special expression, hence, they either match their literal value 
or simply don't match (without errors).

Is this the intended behaviour? 
I am not sure whether it is maybe defined somewhere, or there are some 
de-facto standards for this...
I guess, the space in the property names might be allowed (unless there 
are some implications for the parser...), otherwise the fallback 
handling of invalid property names as normal strings is probably the 
expected way.
vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Aug 24 15:09:47 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 Aug 2009 13:09:47 +0000
Subject: [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251119387.15.0.404650783256.issue6765@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> If Python functions are inconsistent then I think they should either 
be
> made consistent, or if that's not possible they should be clearly
> documented as being inconsistent.

I think 'inconsistent' is a bit strong for what happens here.  In my 
view, the expressions log10(x) and log(x, 10) behave consistently:  they 
both give (good) floating-point approximations to the base-10 logarithm 
of x.  However, since they use slightly different methods to get those 
approximations, the approximations are not identical.

Would you also say that atan2(y, x) is inconsistent with atan(y/x)  (for 
positive x, y, say), because they give minutely different results in 
some cases?

> The docs for log10(x) could be improved to say:
> "this function gives the correct result for powers of 10,
> but breaks consistency with log(a,10) == log10(a)"

I find this unnecessarily negative.  I propose instead to leave the log 
documentation as it is, and add something like the following to the 
log10 documentation, as an explanation of why log10 is still valuable in 
the presence of the two-argument log function:

"""Since this function directly wraps the platform log10 function, 
``log10(x)`` will usually (depending on the platform) be faster and more 
accurate than the mathematically equivalent ``log(x, 10)``."""

Note that historically, the two-argument version of math.log appeared 
long after math.log10 did;  this might help explain the apparent 
redundancy.  (I'd actually argue that the two-argument log should not 
have been added in the first place:  it doesn't wrap a standard C math 
function, and it's really no different from log(x)/log(y), except that 
having it as a built-in library function gives the illusion that it 
might be more accurate than it actually is.  However, that's academic 
now.)

One possible 'fix' for this situation does occur to me:  instead of 
computing log(x, y) internally as log(x)/log(y), compute it as 
log10(x)/log10(y).  This at least doesn't involve extensive changes or 
additions to the code.  I don't think it really makes any practical 
difference, except perhaps in reducing the number of bug reports like 
this one.  And it won't help make log2(x) == log(x, 2) if/when the C99 
log2 function is added to the math library, either.  I'd be -0 on making 
this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6765>
_______________________________________

From report at bugs.python.org  Mon Aug 24 15:25:12 2009
From: report at bugs.python.org (Tim Peters)
Date: Mon, 24 Aug 2009 13:25:12 +0000
Subject: [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251120312.02.0.934825141861.issue6765@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

I wasn't keen to add the 2-argument log() extension either.  However, I
bet it would help if the docs for that were changed to explain that
log(x, base) is just a convenient shorthand for computing
log(x)/log(base), and therefore may be a little less accurate than a
function that directly computed the logarithm wrt the given base.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6765>
_______________________________________

From report at bugs.python.org  Mon Aug 24 15:58:53 2009
From: report at bugs.python.org (Stephen Fairchild)
Date: Mon, 24 Aug 2009 13:58:53 +0000
Subject: [issue6761] Class calling
In-Reply-To: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>
Message-ID: <1251122333.91.0.191125385315.issue6761@psf.upfronthosting.co.za>


Stephen Fairchild <signupaddress at bethere.co.uk> added the comment:

On further reading it seems my objections only apply to new style classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6761>
_______________________________________

From report at bugs.python.org  Mon Aug 24 16:55:43 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2009 14:55:43 +0000
Subject: [issue6761] Class calling
In-Reply-To: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>
Message-ID: <1251125743.41.0.272422739212.issue6761@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

FYI, all special methods are (now) looked up on the type for new style
classes.  Your suggested rewrite makes things more confusing, IMO
(partly because to make it accurate it would need to be something like
type(x).__call__(x, *args, **kw), which doesn't really make the sentence
clearer).

So far I haven't thought of a rewording I like.  The best I've come up
with is "x(arguments) invokes the __call__ method, passing it the
arguments."  This leaves it to other parts of the language spec to
explain how __call__ gets resolved.

Whatever we decide to do, section 3.4.4 will need a similar update.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6761>
_______________________________________

From report at bugs.python.org  Mon Aug 24 17:03:39 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2009 15:03:39 +0000
Subject: [issue6761] Class calling
In-Reply-To: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>
Message-ID: <1251126219.54.0.30087239753.issue6761@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For some reason the 3.2 docs don't contain the sentence you reference,
but they do have the same mistake in section 3.4.4.  Which is even more
of a mistake in 3.x, since there are only new style classes there.

----------
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6761>
_______________________________________

From report at bugs.python.org  Mon Aug 24 17:13:45 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 15:13:45 +0000
Subject: [issue6776] A few tests are failing when zlib is not supported
In-Reply-To: <1251126825.28.0.687144384207.issue6776@psf.upfronthosting.co.za>
Message-ID: <1251126825.28.0.687144384207.issue6776@psf.upfronthosting.co.za>


New submission from Nicolas Dumazet <nicdumz at gmail.com>:

test_distutils, test_zipfile, test_gzip and test_zimport are not
completely safe when zlib module is not available.

I've uploaded a patch on Rietveld which solves the issue here:
http://codereview.appspot.com/111041
Those are my first steps with Rietveld, please let me know if I can
improve something :)

Thanks,
Nicolas.

----------
components: Tests
messages: 91923
nosy: nicdumz
severity: normal
status: open
title: A few tests are failing when zlib is not supported
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6776>
_______________________________________

From report at bugs.python.org  Mon Aug 24 17:56:42 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2009 15:56:42 +0000
Subject: [issue6776] A few tests are failing when zlib is not supported
In-Reply-To: <1251126825.28.0.687144384207.issue6776@psf.upfronthosting.co.za>
Message-ID: <1251129402.88.0.972579466022.issue6776@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue 6026, where patch activity has already
occurred.  Thanks for working on this, and please review that case and
see if all of the issues you found are addressed there.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> test_(zipfile|zipimport|gzip|distutils|sqlite) fail if zlib is not available

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6776>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:12:44 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Aug 2009 17:12:44 +0000
Subject: [issue6775] readme: correct python.org/community/lists url
In-Reply-To: <1251104538.03.0.409360254575.issue6775@psf.upfronthosting.co.za>
Message-ID: <1251133964.38.0.753963329385.issue6775@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74544.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6775>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:15:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Aug 2009 17:15:04 +0000
Subject: [issue6772] Missing alias  utf-8 in  Standard Encodings list.
In-Reply-To: <1251099639.65.0.386311489493.issue6772@psf.upfronthosting.co.za>
Message-ID: <1251134104.07.0.224410468747.issue6772@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I made a compromise in r74545: 'utf-8' is now used as an example to
demonstrate the statement Marc-Andre cited.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6772>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:20:06 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 17:20:06 +0000
Subject: [issue6026] test_(zipfile|zipimport|gzip|distutils|sqlite) fail if
	zlib is not available
In-Reply-To: <1242349106.59.0.466065396405.issue6026@psf.upfronthosting.co.za>
Message-ID: <1251134406.97.0.447265198341.issue6026@psf.upfronthosting.co.za>


Nicolas Dumazet <nicdumz at gmail.com> added the comment:

Great, I don't know how I missed that bug.

It looks really similar to the patch I had written at
http://codereview.appspot.com/111041

So your patch looks correct to me, and does solve the issue locally.

----------
nosy: +nicdumz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6026>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:20:49 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Aug 2009 17:20:49 +0000
Subject: [issue6725] Inconsistency in Documentation: "Name Spaces" vs
	"Namespaces"
In-Reply-To: <1250606890.78.0.538914735097.issue6725@psf.upfronthosting.co.za>
Message-ID: <1251134449.48.0.166031114325.issue6725@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74546.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6725>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:22:12 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Aug 2009 17:22:12 +0000
Subject: [issue6718] ValueError in 21.17.4.2. SocketServer.UDPServer Example
In-Reply-To: <1250527704.81.0.852484951369.issue6718@psf.upfronthosting.co.za>
Message-ID: <1251134532.9.0.488968500493.issue6718@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74547.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6718>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:25:11 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Aug 2009 17:25:11 +0000
Subject: [issue6677] Place the term "delete" within the documentation for
	os.remove() and os.rmdir()
In-Reply-To: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>
Message-ID: <1251134711.86.0.307659354889.issue6677@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74548.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6677>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:26:20 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Aug 2009 17:26:20 +0000
Subject: [issue6660] Desire python.org documentation link to user contribution
	wiki (per function)
In-Reply-To: <1249580984.63.0.922866340136.issue6660@psf.upfronthosting.co.za>
Message-ID: <1251134780.84.0.61421556038.issue6660@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

At the moment, I still have to review and merge the SoC branch, so don't
expect visible changes to happen within a few weeks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:41:35 2009
From: report at bugs.python.org (Mike Cowperthwaite)
Date: Mon, 24 Aug 2009 17:41:35 +0000
Subject: [issue6677] Place the term "delete" within the documentation for
	os.remove() and os.rmdir()
In-Reply-To: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>
Message-ID: <1251135695.82.0.310991538302.issue6677@psf.upfronthosting.co.za>


Mike Cowperthwaite <mikec at lathropengineering.com> added the comment:

Thanks, but the bug requested a similar change for "rmdir" as well.

Is it not possible to backport the change to the 2.x branch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6677>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:47:12 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 24 Aug 2009 17:47:12 +0000
Subject: [issue6776] A few tests are failing when zlib is not supported
In-Reply-To: <1251126825.28.0.687144384207.issue6776@psf.upfronthosting.co.za>
Message-ID: <1251136032.48.0.61657382743.issue6776@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6776>
_______________________________________

From report at bugs.python.org  Mon Aug 24 19:49:09 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Aug 2009 17:49:09 +0000
Subject: [issue6677] Place the term "delete" within the documentation for
	os.remove() and os.rmdir()
In-Reply-To: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>
Message-ID: <1251136149.98.0.781020438686.issue6677@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

True. Fixed in r74550.

The changes will be ported to all maintained branches soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6677>
_______________________________________

From report at bugs.python.org  Mon Aug 24 20:04:02 2009
From: report at bugs.python.org (Mike Cowperthwaite)
Date: Mon, 24 Aug 2009 18:04:02 +0000
Subject: [issue6677] Place the term "delete" within the documentation for
	os.remove() and os.rmdir()
In-Reply-To: <1249924192.93.0.340979032094.issue6677@psf.upfronthosting.co.za>
Message-ID: <1251137042.01.0.113186517383.issue6677@psf.upfronthosting.co.za>


Mike Cowperthwaite <mikec at lathropengineering.com> added the comment:

Very good.  Thank you, Georg.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6677>
_______________________________________

From report at bugs.python.org  Mon Aug 24 20:57:25 2009
From: report at bugs.python.org (Radiant)
Date: Mon, 24 Aug 2009 18:57:25 +0000
Subject: [issue6770] PDF download links of docs for 3.1.1 are broken
In-Reply-To: <1251076723.7.0.569922214039.issue6770@psf.upfronthosting.co.za>
Message-ID: <1251140245.59.0.862468241.issue6770@psf.upfronthosting.co.za>


Radiant <newyorkdude999 at yahoo.com> added the comment:

The files in question are accessible at this time. I can only hope that
the issue doesn't recur.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6770>
_______________________________________

From report at bugs.python.org  Mon Aug 24 21:08:59 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 Aug 2009 19:08:59 +0000
Subject: [issue6770] PDF download links of docs for 3.1.1 are broken
In-Reply-To: <1251076723.7.0.569922214039.issue6770@psf.upfronthosting.co.za>
Message-ID: <1251140939.9.0.807938095483.issue6770@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6770>
_______________________________________

From report at bugs.python.org  Mon Aug 24 21:48:17 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 24 Aug 2009 19:48:17 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1251143297.52.0.781044336921.issue6721@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I've started a project to patch this and similar messes up for Python
2.4 and later here:

 http://code.google.com/p/python-atfork/

I'd like to take ideas or implementations from that when possible for
future use in the python standard library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Mon Aug 24 21:50:34 2009
From: report at bugs.python.org (Christoph Zwerschke)
Date: Mon, 24 Aug 2009 19:50:34 +0000
Subject: [issue6777] Python 2.6 tutorial still recommends using
	Exception.message attribute
In-Reply-To: <1251143434.18.0.260436581702.issue6777@psf.upfronthosting.co.za>
Message-ID: <1251143434.18.0.260436581702.issue6777@psf.upfronthosting.co.za>


New submission from Christoph Zwerschke <cito at online.de>:

The Python 2.6.2 tutorial says at the end of secton 8.3
(http://docs.python.org/tutorial/errors.html#handling-exceptions):

"But use of .args is discouraged. Instead, the preferred use is to pass 
a single argument to an exception (which can be a tuple if multiple 
arguments are needed) and have it bound to the message attribute."

It seems this is not true any more, the idea has been retracted so that 
it's now the other way around again: .args can still be used, 
but .message is deprecated (see http://www.python.org/dev/peps/pep-
0352/#retracted-ideas).

The examples classes in section 8.5 of the Tutorial, using the .message 
attribute should be also adapted because they raise a 
DeprecationWarning in Python 2.6.2.

----------
assignee: georg.brandl
components: Documentation
messages: 91937
nosy: cito, georg.brandl
severity: normal
status: open
title: Python 2.6 tutorial still recommends using Exception.message attribute
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6777>
_______________________________________

From report at bugs.python.org  Mon Aug 24 22:56:51 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 24 Aug 2009 20:56:51 +0000
Subject: [issue6749] Support for encrypted zipfiles when interpreting zipfile
	as script
In-Reply-To: <1250830303.29.0.377270089004.issue6749@psf.upfronthosting.co.za>
Message-ID: <1251147411.06.0.6150249035.issue6749@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The people who do not know how to get over that wall would be equally
stumped if presented with tokenized .pyc or .pyo files.  No fake
encryption needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6749>
_______________________________________

From report at bugs.python.org  Mon Aug 24 22:58:43 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 24 Aug 2009 20:58:43 +0000
Subject: [issue4879] Allow buffering for HTTPResponse
In-Reply-To: <1231411436.11.0.236061918484.issue4879@psf.upfronthosting.co.za>
Message-ID: <1251147523.68.0.588775616319.issue4879@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Already reverted in

r74522 | gregory.p.smith | 2009-08-18 22:33:48 -0700 (Tue, 18 Aug 2009)

for that reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4879>
_______________________________________

From report at bugs.python.org  Mon Aug 24 22:59:18 2009
From: report at bugs.python.org (kaashif)
Date: Mon, 24 Aug 2009 20:59:18 +0000
Subject: [issue6778] False positives given through bisect module (binary
	search)
In-Reply-To: <1251147558.19.0.488929549089.issue6778@psf.upfronthosting.co.za>
Message-ID: <1251147558.19.0.488929549089.issue6778@psf.upfronthosting.co.za>


New submission from kaashif <musharraf.azeem at gmail.com>:

I tried Python's bisect module on a large word list (words.txt contained
in http://www.greenteapress.com/thinkpython/swampy/swampy.1.1.zip)

If I search for something like 'musefully', 'museful' will come up as a
match. Maybe that's a feature... but seems to me like a bug.

Too much optimization going on here it seems, to such an extent that
false positives are given.

Here's the code I tried:

import bisect

fin = open('words.txt')
t = []

for line in fin:
    t.append(line.strip())

print(bisect.bisect(t,'musefully'))

----------
components: Extension Modules
files: words.txt
messages: 91940
nosy: kaashif
severity: normal
status: open
title: False positives given through bisect module (binary search)
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14780/words.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6778>
_______________________________________

From report at bugs.python.org  Mon Aug 24 23:25:11 2009
From: report at bugs.python.org (Samuel Quiring)
Date: Mon, 24 Aug 2009 21:25:11 +0000
Subject: [issue6779] NotImplementedError on for statement
In-Reply-To: <1251149111.84.0.211191712144.issue6779@psf.upfronthosting.co.za>
Message-ID: <1251149111.84.0.211191712144.issue6779@psf.upfronthosting.co.za>


New submission from Samuel Quiring <sam.quiring at windriver.com>:

I have the following for statement:

                lenc = len(children)
                for ic in range(lenc):
                    print "ic: ", ic
                    child = children[ic]
                    print "  -", ic, child.__class__.__name__
                    print "XXX"
            except:
                try:
                    exctype, value = sys.exc_info()[:2]
                    print "exception", exctype, value
                    traceback.print_exc()
                    print range(lenc)
                except:
                    print "exception X"
            print "loop done"

When I execute it, I get the following output:

  - count changed, old: -1 new: 4
ic:  0
  - 0 XGRect
XXX
ic:  1
  - 1 PanelEntry
XXX
ic:  2
  - 2 ScrollView
XXX
ic:  3
  - 3 CloseButton
XXX
exception <type 'exceptions.NotImplementedError'> method not implemented
Traceback (most recent call last):
  File "/home/stpuser/prizm/lib/python2.6/libprizm/pui/atspi.py", line
187, in _get_n_children
    for ic in range(lenc):
NotImplementedError: method not implemented
[0, 1, 2, 3]
loop done


Why am I getting the NotImplementedError exception?  This looks like a
bug to me (I am pretty new to Python).

----------
components: None
messages: 91941
nosy: sbq
severity: normal
status: open
title: NotImplementedError on for statement
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6779>
_______________________________________

From report at bugs.python.org  Mon Aug 24 23:33:13 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 24 Aug 2009 21:33:13 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

The `startswith` method accepts both string and tuple (not list). Yet 
the error message suggests that it expects (only) a character buffer 
object.

In Python-2.6:

>>> "foo".startswith(['fo', 'df'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected a character buffer object

In Python-3.x, the error message is different:

>>> "foo".startswith(["fo"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'list' object to str implicitly

Aside: why not try to convert 'list' object to tuple?

----------
components: Library (Lib)
messages: 91942
nosy: srid
severity: normal
status: open
title: startswith error message is incomplete
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Tue Aug 25 00:11:54 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Aug 2009 22:11:54 +0000
Subject: [issue6730] dict.fromkeys() should not cross reference mutable value
	by default
In-Reply-To: <1250627335.2.0.623159685079.issue6730@psf.upfronthosting.co.za>
Message-ID: <1251151914.23.0.988257619818.issue6730@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'll add a bit of explanation as well:

> I have to add this ugly loop :
> 
> for key in keys:
>    d[key] = [] 
 
With a defaultdict, you don't -- you just use d[key], and if not already
present, the entry will be initialized with an empty list.

> I really think that :
> 1) The doc should warn about it, since it is a very weird behaviour

It is not weird in Python.  Implicit copies are never made, partly
because it's very hard to implement it correctly for every object.

> 2) There could at least be a third argument allowing the user to choose,
> with a default value that maintains the current behaviour (for
> compatibility, even though I think the default should be a deep copy)

The interface of a fundamental type like "dict" will not be changed
lightly. Usually, when a change is made, it is to add a feature that is
often requested by lots of users -- I've never seen someone request this
before.  And as we've seen, it can easily be written either using a
simple loop, or a defaultdict, depending on the exact use-case.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6730>
_______________________________________

From report at bugs.python.org  Tue Aug 25 00:29:39 2009
From: report at bugs.python.org (kee nethery)
Date: Mon, 24 Aug 2009 22:29:39 +0000
Subject: [issue6660] Desire python.org documentation link to user contribution
	wiki (per function)
In-Reply-To: <1251134780.84.0.61421556038.issue6660@psf.upfronthosting.co.za>
Message-ID: <7D3962DE-9D15-4FD3-A72D-31C371AAC649@kagi.com>


kee nethery <kee at kagi.com> added the comment:

No problem. I can parse text in an automated manner very easily. So if  
you need someone to take the doc files and add in wiki URLs for each  
section, I can do that. Happy to volunteer. Worst case is you look at  
what I do and reject it. Best case ... I actually do what you need.
Thanks, Kee

On Aug 24, 2009, at 10:26 AM, Georg Brandl wrote:

>
> Georg Brandl <georg at python.org> added the comment:
>
> At the moment, I still have to review and merge the SoC branch, so  
> don't
> expect visible changes to happen within a few weeks.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6660>
> _______________________________________

-------------------------------------------------
I check email roughly 2 to 3 times per business day.
Kagi main office: +1 (510) 550-1336

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6660>
_______________________________________

From report at bugs.python.org  Tue Aug 25 00:43:31 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2009 22:43:31 +0000
Subject: [issue6778] False positives given through bisect module (binary
	search)
In-Reply-To: <1251147558.19.0.488929549089.issue6778@psf.upfronthosting.co.za>
Message-ID: <1251153811.49.0.477660617582.issue6778@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's not a match, it's an insertion point.  The bisect module doesn't
have a method that can be used directly to determine if an item is not
in the list.  Take a careful look at the example, especially the second
part.

If you think it should have such a method, that would be an enhancement
request.

----------
nosy: +r.david.murray, rhettinger
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6778>
_______________________________________

From report at bugs.python.org  Tue Aug 25 00:51:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Aug 2009 22:51:15 +0000
Subject: [issue6779] NotImplementedError on for statement
In-Reply-To: <1251149111.84.0.211191712144.issue6779@psf.upfronthosting.co.za>
Message-ID: <1251154275.32.0.179321569955.issue6779@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The bug tracker is not a place to get help debugging your code.  Your
code is not a complete example, and is doing odd things with try/except
and the printing of errors which may well be masking what is really
going on, so I can't begin to evaluate whether or not you've found a
real bug, but it seems unlikely.  Please post your question to
python-list (or perhaps even python-tutor), and if it turns out you do
have a real bug, reopen this ticket.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6779>
_______________________________________

From report at bugs.python.org  Tue Aug 25 01:10:53 2009
From: report at bugs.python.org (Nicolas Dumazet)
Date: Mon, 24 Aug 2009 23:10:53 +0000
Subject: [issue5851] Add a stream parameter to gc.set_debug
In-Reply-To: <1240813443.12.0.48308121403.issue5851@psf.upfronthosting.co.za>
Message-ID: <1251155453.7.0.562790066175.issue5851@psf.upfronthosting.co.za>


Nicolas Dumazet <nicdumz at gmail.com> added the comment:

Sure, I'd be happy to contribute a patch.

I uploaded a patch on Rietveld, at http://codereview.appspot.com/110078

Let me know how it looks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5851>
_______________________________________

From report at bugs.python.org  Tue Aug 25 02:21:50 2009
From: report at bugs.python.org (Jessica McKellar)
Date: Tue, 25 Aug 2009 00:21:50 +0000
Subject: [issue6744] calling kevent repr raises a TypeError
In-Reply-To: <1250800889.41.0.974799993123.issue6744@psf.upfronthosting.co.za>
Message-ID: <1251159710.16.0.193760167233.issue6744@psf.upfronthosting.co.za>


Jessica McKellar <jessica.mckellar at gmail.com> added the comment:

Added a tiny example to generate the error, repeated here. Just:

from select import kevent

if __name__ == '__main__':
    ev = kevent(1)
    print(repr(ev))

----------
Added file: http://bugs.python.org/file14781/kevent-repr-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6744>
_______________________________________

From report at bugs.python.org  Tue Aug 25 11:23:32 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Aug 2009 09:23:32 +0000
Subject: [issue6780] startswith error message is incomplete
In-Reply-To: <1251149593.57.0.654081758843.issue6780@psf.upfronthosting.co.za>
Message-ID: <1251192212.35.0.362418346989.issue6780@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In the examples you used byte strings for Py2 and Unicode strings for
Py3. On Py3 the same example with byte strings gives an error similar to
the one raised by Py2:

>>> b"foo".startswith([b"fo"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected an object with the buffer interface
(vs. Py2's expected a character buffer object)

The error raised by Py2 with Unicode strings is more or less the same of
Py3 too:

>>> u"foo".startswith([u"fo", u"df"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: coercing to Unicode: need string or buffer, list found
(vs. Py3's Can't convert 'list' object to str implicitly)

If I understood correctly the C code in /Objects/unicodeobject.c, this
is because startswith checks if the 'prefix' is a tuple and, if not, it
assumes that is a Unicode string. The 'prefix' is then converted to
Unicode by PyUnicode_FromObject and if it's a list or some other object
the error "Can't convert 'list' object to str implicitly" / "coercing to
Unicode: need string or buffer, list found" is raised.

I agree that a more explicit error message would be better, something
like: "'prefix' must be a character buffer object or a tuple, not 'list'".

> Aside: why not try to convert 'list' object to tuple?

If the support for lists is added, it should probably be extended to all
the iterables, but strings are iterables too, so that will create some
problem. It could be checked if 'prefix' is a string and if not assume
that is an iterable of strings, but I don't know if it's worth doing it.

----------
components: +Interpreter Core -Library (Lib)
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6780>
_______________________________________

From report at bugs.python.org  Tue Aug 25 12:49:23 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Aug 2009 10:49:23 +0000
Subject: [issue6744] calling kevent repr raises a TypeError
In-Reply-To: <1250800889.41.0.974799993123.issue6744@psf.upfronthosting.co.za>
Message-ID: <1251197363.82.0.247053214014.issue6744@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> christian.heimes
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6744>
_______________________________________

From report at bugs.python.org  Tue Aug 25 13:24:14 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Aug 2009 11:24:14 +0000
Subject: [issue6738] Wrong doc strings in itertools
In-Reply-To: <1250753532.16.0.563820931893.issue6738@psf.upfronthosting.co.za>
Message-ID: <1251199454.32.0.088586632637.issue6738@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6738>
_______________________________________

From report at bugs.python.org  Tue Aug 25 13:27:36 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Aug 2009 11:27:36 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1251199656.52.0.360372212142.issue6701@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +krisvale
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Tue Aug 25 13:37:20 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Aug 2009 11:37:20 +0000
Subject: [issue6738] Wrong doc strings in itertools
In-Reply-To: <1250753532.16.0.563820931893.issue6738@psf.upfronthosting.co.za>
Message-ID: <1251200240.88.0.62479645373.issue6738@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6738>
_______________________________________

From report at bugs.python.org  Tue Aug 25 13:37:37 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Aug 2009 11:37:37 +0000
Subject: [issue6662] HTMLParser.HTMLParser doesn't handle malformed charrefs
In-Reply-To: <1249608310.39.0.325559183765.issue6662@psf.upfronthosting.co.za>
Message-ID: <1251200257.81.0.966717059204.issue6662@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Confirmed on Python3.1 too.

----------
nosy: +ezio.melotti
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6662>
_______________________________________

From report at bugs.python.org  Tue Aug 25 14:29:25 2009
From: report at bugs.python.org (benlbroussard)
Date: Tue, 25 Aug 2009 12:29:25 +0000
Subject: [issue6781] even exponentiation of negative numbers
In-Reply-To: <1251203365.27.0.467156127603.issue6781@psf.upfronthosting.co.za>
Message-ID: <1251203365.27.0.467156127603.issue6781@psf.upfronthosting.co.za>


New submission from benlbroussard <benlbroussard at gmail.com>:

Negative one squared should be one, but is negative one sometimes.

pow(-1, 2) = 1
-1 ** 2 = -1
-1 ^ 2 = -1

The ** and ^ operators aren't working like expected, and the pow()
documentation is incorrect since it says "The two-argument form pow(x,
y) is equivalent to using the power operator: x**y."

----------
components: None
messages: 91951
nosy: benlbroussard
severity: normal
status: open
title: even exponentiation of negative numbers
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6781>
_______________________________________

From report at bugs.python.org  Tue Aug 25 14:35:10 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 Aug 2009 12:35:10 +0000
Subject: [issue6781] even exponentiation of negative numbers
In-Reply-To: <1251203365.27.0.467156127603.issue6781@psf.upfronthosting.co.za>
Message-ID: <1251203710.03.0.64386610935.issue6781@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is not a bug:

-1 ** 2 is parsed as -(1 ** 2), not (-1) ** 2.  Take a look at:

http://docs.python.org/reference/expressions.html#the-power-operator

In -1 ^ 2, ^ is the bitwise exclusive-or operator, not the power operator.

pow(x, y) is indeed equivalent to x**y:

Python 2.6.2 (r262:71600, Aug 22 2009, 17:53:25) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = -1
>>> y = 2
>>> x ** y
1
>>> pow(x, y)
1
>>>

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6781>
_______________________________________

From report at bugs.python.org  Tue Aug 25 15:03:54 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 Aug 2009 13:03:54 +0000
Subject: [issue6781] even exponentiation of negative numbers
In-Reply-To: <1251203365.27.0.467156127603.issue6781@psf.upfronthosting.co.za>
Message-ID: <1251205434.38.0.294671031967.issue6781@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

By the way, I get -1 ^ 2 == -3, not -1:

>>> -1 ^ 2
-3

If you're getting -1 instead, then that *is* a bug!  Are you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6781>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:29:11 2009
From: report at bugs.python.org (victor)
Date: Tue, 25 Aug 2009 15:29:11 +0000
Subject: [issue6782] Scoping of variables in closures
In-Reply-To: <1251214151.84.0.540608749633.issue6782@psf.upfronthosting.co.za>
Message-ID: <1251214151.84.0.540608749633.issue6782@psf.upfronthosting.co.za>


New submission from victor <bitto001 at uwp.edu>:

I can't tell if this is "feature" or a "bug" but either way this
behavior struck me as strange.
"""
def func():
  x = 5
  def inc():
    temp = x + 1 # when inc() is execute, this line fails
    x = temp
    return x
  return inc

i = func()
i() # will raise error
"""
It says that x referenced before defined (when computing x + 1). It
seems that the fact that x is assigned in the local inc() that it
shadows the outer x.
Even stranger is that if you remove the the assignment of "x = temp"
there is no error; suggesting the assignment to x anywhere in the inner
function shadows the entire function. 

This is not the expected behavior, so I thought it may be bug.

----------
components: Interpreter Core
messages: 91954
nosy: bitfort
severity: normal
status: open
title: Scoping of variables in closures
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6782>
_______________________________________

From report at bugs.python.org  Tue Aug 25 17:44:48 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2009 15:44:48 +0000
Subject: [issue6782] Scoping of variables in closures
In-Reply-To: <1251214151.84.0.540608749633.issue6782@psf.upfronthosting.co.za>
Message-ID: <1251215088.43.0.379028378796.issue6782@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's feature.

In python 3 you can use the 'nonlocal' keyword to access the variable in
the outer scope for assignment.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6782>
_______________________________________

From report at bugs.python.org  Tue Aug 25 18:40:27 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Aug 2009 16:40:27 +0000
Subject: [issue6782] Scoping of variables in closures
In-Reply-To: <1251214151.84.0.540608749633.issue6782@psf.upfronthosting.co.za>
Message-ID: <1251218427.06.0.625985010512.issue6782@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6782>
_______________________________________

From report at bugs.python.org  Tue Aug 25 21:26:33 2009
From: report at bugs.python.org (Cherniavsky Beni)
Date: Tue, 25 Aug 2009 19:26:33 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1251228393.07.0.153914119169.issue6755@psf.upfronthosting.co.za>


Cherniavsky Beni <cben at users.sf.net> added the comment:

Nice.  2 questions:

1. Why not change getch() to always use get_wch()?
2. I think you also want fix getkey() / introduce get_wkey().

----------
nosy: +cben

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Tue Aug 25 21:33:40 2009
From: report at bugs.python.org (PJ McNerney)
Date: Tue, 25 Aug 2009 19:33:40 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1251228820.95.0.650873379522.issue3329@psf.upfronthosting.co.za>


PJ McNerney <pjmcnerney at gmail.com> added the comment:

Has the ability to set the memory allocator been added to Python 2.7/3.1?

Thanks,
PJ

----------
nosy: +pjmcnerney
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Tue Aug 25 21:35:41 2009
From: report at bugs.python.org (Yuv Gre)
Date: Tue, 25 Aug 2009 19:35:41 +0000
Subject: [issue6783] Add a builtin method to 'int' for base/radix conversion
In-Reply-To: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>
Message-ID: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>


New submission from Yuv Gre <ubershmekel at gmail.com>:

In javascript and java each number has a toString method which allows 
for easy string representation in different bases. If the function int(x[, base]) exists as a builtin, the inverse should at least be 
somewhere in the standard library. Personally I believe a "to_string" 
method would work but would defeat "There should be one way to do it". 
Perhaps a method called "radix" or "base_convert" which requires a base 
to convert parameter won't take the place of str(number).

Here are a few possible implementations:
http://code.activestate.com/recipes/222109/
http://code.activestate.com/recipes/111286/
http://pastebin.com/f54dd69d6

----------
components: Interpreter Core, Library (Lib)
messages: 91958
nosy: ubershmekel
severity: normal
status: open
title: Add a builtin method to 'int' for base/radix conversion
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6783>
_______________________________________

From report at bugs.python.org  Tue Aug 25 21:45:27 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 Aug 2009 19:45:27 +0000
Subject: [issue6783] Add a builtin method to 'int' for base/radix conversion
In-Reply-To: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>
Message-ID: <1251229527.75.0.362782701449.issue6783@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This seems like the sort of idea that should be floated on the python-
ideas mailing list or comp.lang.python first, both to find out what 
support there is and to pin down precise semantics.

We already have int to string conversions in bases 2, 8, 10 and 16;  what 
are the use-cases for conversions in other bases?

----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6783>
_______________________________________

From report at bugs.python.org  Tue Aug 25 21:53:37 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 25 Aug 2009 19:53:37 +0000
Subject: [issue6783] Add a builtin method to 'int' for base/radix conversion
In-Reply-To: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>
Message-ID: <1251230017.16.0.431793916744.issue6783@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See http://mail.python.org/pipermail/python-dev/2006-January/059789.html 
for a previous related discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6783>
_______________________________________

From report at bugs.python.org  Tue Aug 25 22:01:47 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Aug 2009 20:01:47 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1251230507.46.0.610009683024.issue1068268@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Wed Aug 26 03:30:48 2009
From: report at bugs.python.org (Sophia K. Cheng)
Date: Wed, 26 Aug 2009 01:30:48 +0000
Subject: [issue4625] IDLE won't open anymore, .idlerc unaccessible
In-Reply-To: <1237537598.93.0.229594697808.issue4625@psf.upfronthosting.co.za>
Message-ID: <C6BA0876.18E0%sophia.cheng@gmail.com>


Sophia K. Cheng <sophia.cheng at gmail.com> added the comment:

Thanks!!  This worked perfectly!  Finally got around to trying this out
today.

Sincerely,
Sophia

On 3/20/09 4:26 AM, "Timothy Zhang" <report at bugs.python.org> wrote:

> 
> Timothy Zhang <zt at live.cn> added the comment:
> 
> I meet the same problem and have it fixed. I use Python 2.5.2 on Windows XP.
> 
> This is my solution:
> 1. Choose "Tool->Folder Option" in your explorer menu, then click "View"
> tab, uncheck "use simple file sharing(recommended)".
> 2. Right click on "C:\Documents and Settings\<YourName>\.idlerc" folder,
> then click "property", you got the folder property dialog
> 3. Click "Safety" tab, you may found there's only "System" user in the
> list. Click "Add" and add type your username, then click "OK".
> 4. Select your name in the list, enable all the permissions in the box
> below.
> 
> Now this problem should be fixed. Hope this works.
> 
> ----------
> nosy: +timium
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4625>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4625>
_______________________________________

From report at bugs.python.org  Wed Aug 26 04:07:01 2009
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 26 Aug 2009 02:07:01 +0000
Subject: [issue6783] Add a builtin method to 'int' for base/radix conversion
In-Reply-To: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>
Message-ID: <1251252421.48.0.2392502533.issue6783@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6783>
_______________________________________

From report at bugs.python.org  Wed Aug 26 06:44:46 2009
From: report at bugs.python.org (Ryan Leslie)
Date: Wed, 26 Aug 2009 04:44:46 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1251261886.79.0.822743960093.issue6759@psf.upfronthosting.co.za>


Ryan Leslie <rylesny at gmail.com> added the comment:

Hi Art,

Thanks for working on this. I've taken a look at the patch.

The fix to read_test looks correct. Of course, I would consider a more
descriptive variable name than 'b'.

The changes to read() are an improvement, but I think we need to be
careful when we replace "\r\n" with "\n". Basically, we've turned two
characters into one and are now potentially one character short of
'size' bytes. This doesn't match the behavior of file.read().

Another thing to work out is the lack of the 'newlines' attribute,
discussed in PEP 278.

I've noted that bz2 seems to do a pretty good job with universal newline
handling: python/trunk/Modules/bz2module.c.

It's in C, however, and I don't think there's actually anything in the
library doing UL in pure Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Wed Aug 26 09:36:14 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Aug 2009 07:36:14 +0000
Subject: [issue6659] buffer c-api: memoryview object documentation
In-Reply-To: <1249560456.01.0.11537088321.issue6659@psf.upfronthosting.co.za>
Message-ID: <1251272174.05.0.125154023023.issue6659@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r74551.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6659>
_______________________________________

From report at bugs.python.org  Wed Aug 26 11:54:55 2009
From: report at bugs.python.org (Daniel Svensson)
Date: Wed, 26 Aug 2009 09:54:55 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1251280495.28.0.471457158905.issue4892@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

A typical use case would be for a server to receive a connection, and
then send that connection over to another process that does the actual
work. This used to work with pyprocessing, and the support seems to be
available in multiprocessing.c -> multiprocessing_sendfd, but not used.

----------
nosy: +dsvensson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Wed Aug 26 12:51:52 2009
From: report at bugs.python.org (Daniel Svensson)
Date: Wed, 26 Aug 2009 10:51:52 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1251283912.45.0.887928229609.issue4892@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

And to be clear, I have enabled connection pickling by issuing:

multiprocessing.allow_connection_pickling()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Wed Aug 26 13:56:13 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Wed, 26 Aug 2009 11:56:13 +0000
Subject: [issue6784] bytw/unicode string incompatibilities between python2 and
	and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>


New submission from RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de>:

i just noticed that there are some slight differences of the
bytestring/unicodestring pickles between python2/3 using the protocols
0, 1 and 2

the first things i noticed are:

a str from python2 is unpickled as unicode in python3
(fails for byte strings that don't fit whats expected for unicode)


a bytes instance from python3 is pickled as custom class in protocols <3

i'll write a script to try all combinations of protocols and string
variations and transfer directions

----------
components: None
messages: 91966
nosy: RonnyPfannschmidt
severity: normal
status: open
title: bytw/unicode string incompatibilities between python2 and and python3
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Wed Aug 26 14:12:25 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Wed, 26 Aug 2009 12:12:25 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251288745.33.0.967083668657.issue6784@psf.upfronthosting.co.za>


Changes by RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de>:


----------
title: bytw/unicode string incompatibilities between python2 and and python3 -> byte/unicode pickle incompatibilities between python2 and and python3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Wed Aug 26 14:19:47 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 Aug 2009 12:19:47 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251289187.17.0.692791518606.issue6784@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why are you reporting this here? If you think there is a bug, can you
propose an alternative behavior that you would consider correct?

The changes you mentioned are all deliberate.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Wed Aug 26 14:30:20 2009
From: report at bugs.python.org (Daniel Svensson)
Date: Wed, 26 Aug 2009 12:30:20 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1251289820.8.0.915023353308.issue4892@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

When reverting this commit stuff works:

http://svn.python.org/view/python/trunk/Lib/multiprocessing/reduction.py?r1=64257&r2=65016

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Wed Aug 26 14:33:48 2009
From: report at bugs.python.org (Daniel Svensson)
Date: Wed, 26 Aug 2009 12:33:48 +0000
Subject: [issue4892] Sending Connection-objects over multiprocessing
	connections fails
In-Reply-To: <1231501567.81.0.886406215073.issue4892@psf.upfronthosting.co.za>
Message-ID: <1251290028.35.0.973441831444.issue4892@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

Ehm.. completly broken url in prev message.. Revision 65016, "Apply
Amaury's patch to multiprocessing for issue 3125, removes the copy_reg
and replaces it with ForkingPickler.register(), which should resolve the
conflict with the global registry/ctypes" is what I'm refering to.
Without this patch, the reducers/rebuilders are properly registered in
the pickler that connection.h (srsly, code in header files?) later uses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4892>
_______________________________________

From report at bugs.python.org  Wed Aug 26 14:42:25 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Wed, 26 Aug 2009 12:42:25 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251290545.78.0.374378309455.issue6784@psf.upfronthosting.co.za>


RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

the basic behavior i want to see for all protocols <= 2

1. python 2 string maps to python3 byte-string
2. python 2 unicode maps to python3 string
3. python 3 string map to python 2 unicode 
4. python 3 bytestring maps to python 2 string

anything else is is confusing and may break
for example one can't unpickle '\xFF' in python3 if it was pickled in
python2

note that these changes seem irrelevant for protocol 3 as python2.x
doesn't support it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Wed Aug 26 15:05:37 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Aug 2009 13:05:37 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1251291937.03.0.0138468919576.issue6759@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The python version of the io module does (_pyio.py).

I've set the stage to 'test needed' because the test needs to be turned
into a unit test.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Wed Aug 26 15:51:33 2009
From: report at bugs.python.org (Evan)
Date: Wed, 26 Aug 2009 13:51:33 +0000
Subject: [issue6785] IncompleteRead / BadStatus when parsing
	http://peakoil.mobi
In-Reply-To: <1251294693.63.0.748199046509.issue6785@psf.upfronthosting.co.za>
Message-ID: <1251294693.63.0.748199046509.issue6785@psf.upfronthosting.co.za>


New submission from Evan <evanphelan at gmail.com>:

(I'm brand new to Python.org, apologies in advance if this has been
recorded elsewhere or is not a bug)

I've a simple script which fetching a url using httplib/urllib2 and then
simply searches the HTML for a string. Works on every URL I've tried
apart from the url http://peakoil.mobi where, for some reason, I get the
following:

Traceback (most recent call last):
  File "C:\Python26\lib\threading.py", line 524, in __bootstrap_inner
    self.run()
  File "test.py", line 59, in run
    html = response.read()
  File "C:\Python26\lib\socket.py", line 327, in read
    data = self._sock.recv(rbufsize)
  File "C:\Python26\lib\httplib.py", line 518, in read
    return self._read_chunked(amt)
  File "C:\Python26\lib\httplib.py", line 564, in _read_chunked
    raise IncompleteRead(value)
IncompleteRead: <html><head>

<title></title></head>
<!-- Redirection Services ASH01WRED02 H1 -->
<frameset rows='100%, *' frameborder=no framespacing=0 border=0>
<frame src="http://peakoil.com/modules.php?name=AvantGo" name=mainwindow
framebo
rder=no framespacing=0 marginheight=0 marginwidth=0></frame>
</frameset>
<noframes>
<h2>Your browser does not support frames.  We recommend upgrading your
browser.<
/h2><br><br>
<center>Click <a
href="http://peakoil.com/modules.php?name=AvantGo">here</a> to
enter the site.</center>
</noframes></html>

Exception in thread 1:
Traceback (most recent call last):
  File "C:\Python26\lib\threading.py", line 524, in __bootstrap_inner
    self.run()
  File "test.py", line 51, in run
    response = urllib2.urlopen(req)
  File "C:\Python26\lib\urllib2.py", line 124, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\Python26\lib\urllib2.py", line 383, in open
    response = self._open(req, data)
  File "C:\Python26\lib\urllib2.py", line 401, in _open
    '_open', req)
  File "C:\Python26\lib\urllib2.py", line 361, in _call_chain
    result = func(*args)
  File "C:\Python26\lib\urllib2.py", line 1130, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "C:\Python26\lib\urllib2.py", line 1103, in do_open
    r = h.getresponse()
  File "C:\Python26\lib\httplib.py", line 951, in getresponse
    response.begin()
  File "C:\Python26\lib\httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "C:\Python26\lib\httplib.py", line 355, in _read_status
    raise BadStatusLine(line)
BadStatusLine

----------
messages: 91972
nosy: kmoon
severity: normal
status: open
title: IncompleteRead / BadStatus when parsing http://peakoil.mobi
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6785>
_______________________________________

From report at bugs.python.org  Wed Aug 26 17:47:55 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Wed, 26 Aug 2009 15:47:55 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1251301675.56.0.708897695595.issue6755@psf.upfronthosting.co.za>


I?igo Serna <inigoserna at gmail.com> added the comment:

Q. Why not change getch() to always use get_wch()?

This could break backwards compatibility.
There are some code out there that may use getch() to get the bytes
stream one by one and build the wide char.
In fact I'm using this trick to get unicode chars by now.
Look the thread link in first comment to find the implementation I've
developed for my app. Other people are using similar approaches too.


Q. I think you also want fix getkey() / introduce get_wkey().

In my own experience get_wkey isn't be as useful when dealing with wide
chars. But, of course, that's only my use cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Wed Aug 26 18:13:22 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Wed, 26 Aug 2009 16:13:22 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1251303202.76.0.288694338941.issue6755@psf.upfronthosting.co.za>


I?igo Serna <inigoserna at gmail.com> added the comment:

Btw, I don't know if this is the best place to comment it but as it is
somehow related with ncurses...

Other functions I miss a lot are wcwidth() and wcswidth(). 

These functions return the real width (read, cells length in screen) for
unicode strings. 

An example to clarify the issue: one simple Chinese character could need
2 cells on screen, thus len(chinese_unicode_string) won't return the
real screen width needed to show the string.

i.e., len(chinese_unicode_string) != wcswidth(chinese_unicode_string)


Those functions are included into not so old glibc versions (2.2+?), at
least on my Linux systems.

Sadly enough, python doesn't bind them, afaik.
I've tried ctypes but don't work for me (don't know the reason), so I've
written some replacements.

Please look at these files: 

* test_ucs2w.py: benchmarks to different implementations. Most of them,
pure python. Please consider only ucs2w_1x, other are only experiments.

* ucs2w.c: C extension implementation


I think Python could benefit from having these functions in the standard
library. Surely, most simple way should be to bind glibc functions, but
don't know if they exist on other platforms such as MacOS X or Windows.

Neither do I know where they fit... perhaps in unicodedata module.


What do you think? who is the person to convince? (please, don't ask me
to write a PEP, my English is not good enough).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Wed Aug 26 18:14:17 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Wed, 26 Aug 2009 16:14:17 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1251303257.25.0.931809495605.issue6755@psf.upfronthosting.co.za>


Changes by I?igo Serna <inigoserna at gmail.com>:


Added file: http://bugs.python.org/file14782/test_ucs2w.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Wed Aug 26 18:14:45 2009
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Wed, 26 Aug 2009 16:14:45 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1251303285.46.0.417060164235.issue6755@psf.upfronthosting.co.za>


Changes by I?igo Serna <inigoserna at gmail.com>:


Added file: http://bugs.python.org/file14783/ucs2w.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Wed Aug 26 19:03:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Aug 2009 17:03:45 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1251306225.59.0.95143095967.issue6755@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For the title concern of this patch I'm adding akuchling as nosy.

Judging by your post your English probably is good enough to write a PEP
(the PEP editors should help with fine tuning it, at least in theory).
However, I doubt a PEP would be necessary.

As for where to raise the (new) issue...given that these functions are
independent of curses, I'd say open a new issue.  If you do that, I'd
suggest making lemburg nosy on the issue, as he is the original author
of the unicodedata module and many other unicode things in python.

I'm setting the stage to test needed since your test case isn't a unit
test.  I have no idea (never having worked with curses) how hard a unit
test would be to write.  Nor have I reviewed the patch, for the same reason.

----------
nosy: +akuchling, r.david.murray
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Wed Aug 26 19:08:16 2009
From: report at bugs.python.org (Art Gillespie)
Date: Wed, 26 Aug 2009 17:08:16 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1251306496.64.0.543083947444.issue6759@psf.upfronthosting.co.za>


Art Gillespie <agillesp at gmail.com> added the comment:

Hi Ryan,

Thanks for the feedback.

I've attached a new patch that fixes the read(nbytes) behavior--It will
now always return the requested number of bytes regardless of newline
replacement.  There's now a unit test for this as well.

I also added the newlines attribute per PEP 278 and a corresponding test.

I'm not sure I understood David's comment that read_test needed to be
turned into a unit test:  it's called by several of the unit tests
(test_read_stored, test_read_deflated, et. al.) in that class.

----------
Added file: http://bugs.python.org/file14784/issue6759_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Wed Aug 26 19:32:05 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Aug 2009 17:32:05 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1251307925.34.0.601610428141.issue6759@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My apologies, I misread the patch.

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Wed Aug 26 20:01:18 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 26 Aug 2009 18:01:18 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2
	and	and python3
In-Reply-To: <1251290545.78.0.374378309455.issue6784@psf.upfronthosting.co.za>
Message-ID: <4A95786B.4050906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> the basic behavior i want to see for all protocols <= 2
> 
> 1. python 2 string maps to python3 byte-string

That would not be good. Many people create pickles in 2.x where the
string type really represents characters, more often so than they want
it to represent bytes. Giving them bytes on unpickling will likely
cause more problems than the current approach.

> 2. python 2 unicode maps to python3 string

That's the case, right?

> 3. python 3 string map to python 2 unicode 

That's also the case, AFAICT.

> 4. python 3 bytestring maps to python 2 string

Hmm. This may be indeed a mistake. Until r61467, bytes were saved
with the (BIN)STRING code; not sure why this was changed.

----------
title: byte/unicode pickle incompatibilities between python2 and and python3 -> byte/unicode pickle incompatibilities between python2 and	and python3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Wed Aug 26 20:17:36 2009
From: report at bugs.python.org (James)
Date: Wed, 26 Aug 2009 18:17:36 +0000
Subject: [issue6786] readline and zero based indexing
In-Reply-To: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>
Message-ID: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

why is it that the zeroth readline history item is seemingly always
none. I would expect this to support zero-based indexing in python, but
perhaps I have missed some detail in readline somewhere. Cheers,
_J


james at work:~$ python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:24:49) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.get_history_item(0)
>>> readline.get_history_item(0) is None
True
>>> 
james at work:~$

----------
components: Extension Modules
messages: 91979
nosy: purpleidea
severity: normal
status: open
title: readline and zero based indexing
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6786>
_______________________________________

From report at bugs.python.org  Wed Aug 26 20:18:04 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Wed, 26 Aug 2009 18:18:04 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2
	and	and python3
In-Reply-To: <4A95786B.4050906@v.loewis.de>
Message-ID: <1251310680.24112.9.camel@localhost>


RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

Since it breaks for anything non-ascii, its not that helpfull after all
and since python2 strings are encoding-unaware there is no way to fix
it.

It might be preferable to supply unpicklers that are cappable of
coercing if the user really wants wants coercing.

yup
> 
> > 3. python 3 string map to python 2 unicode 
> 
> That's also the case, AFAICT.
yup
> 
> > 4. python 3 bytestring maps to python 2 string
> 
> Hmm. This may be indeed a mistake. Until r61467, bytes were saved
> with the (BIN)STRING code; not sure why this was changed.
Python 3 is indeed evil there.

b'\x80\x02c__builtin__\nbytes\nq\x00]q\x01\x85q\x02Rq\x03.'

I'm convinced that a 1:1 mapping of python2 string from/to python3
bytestrings is the least surprising behaviour and will keep surprising
errors away when needing to communicate between different python
versions.

It just has bitten me, and i suspect will will get others, too.
Unpickle that completely fails in the face of encodings is not desirable
at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Wed Aug 26 20:55:45 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 26 Aug 2009 18:55:45 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1251312945.41.0.52656749646.issue6759@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for working on this.

Comments on patch:

(1) I think you should retain the full "ugly check" comment explaining
how the \r\n spanning a buffer is handled.  I think that's a helpful
explanation for a non-obvious piece of code.

(2) Your code for setting the newlines attributes and the tests for it
look wrong to me.  The attribute is supposed to list all separators
seen.  I think your code is going to set it to ('\r\n', '\r') when the
separators are just '\r\n', and your test doesn't check to make sure
newlines gets set to _only_ what was seen.  (Nor does it check for the
case of actual mixed line endings...a test for which would require some
additional test hackery since the existing test code didn't try to test
mixed line end files either.)

(3) Sorry for being dense, but I don't understand your code to adjust
the number of bytes in the read method or the test that tests it.  I
haven't tried to play with it, but it looks odd to me that you'd be
adding '2', since I would think that the read could cover more than one
line...or am I misunderstanding how 'read(n)' works (which is entirely
possible)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Thu Aug 27 00:14:25 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Aug 2009 22:14:25 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1251324865.41.0.782088544143.issue6755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

inigoserna>> Other functions I miss a lot are wcwidth() and wcswidth()

I wrote a patch to implement unicode.width() method:
http://bugs.python.org/file13357/unicode_width.patch

It's part of the issue #2382 (SyntaxError cursor shifted if multibyte
character is in line)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Thu Aug 27 00:18:59 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Aug 2009 22:18:59 +0000
Subject: [issue6498] Py_Main() does not return on SystemExit
In-Reply-To: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
Message-ID: <1251325139.61.0.211749546872.issue6498@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you propose a patch fixing this issue?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6498>
_______________________________________

From report at bugs.python.org  Thu Aug 27 00:22:23 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Aug 2009 22:22:23 +0000
Subject: [issue6518] Enable 'with' statement in ossaudiodev module
In-Reply-To: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
Message-ID: <1251325343.65.0.218559136273.issue6518@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@agillesp: a Python function should never return NULL without setting an
error. oss_self() have to call a PyErr_(...) function to set an error.
And I would prefer the name "oss_enter" than the unusual name "oss_self".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6518>
_______________________________________

From report at bugs.python.org  Thu Aug 27 00:28:54 2009
From: report at bugs.python.org (Joseph Malicki)
Date: Wed, 26 Aug 2009 22:28:54 +0000
Subject: [issue4684] sys.exit() exits program when non-daemonic threads are
	still running
In-Reply-To: <1229536748.7.0.859607140582.issue4684@psf.upfronthosting.co.za>
Message-ID: <1251325734.68.0.229374683971.issue4684@psf.upfronthosting.co.za>


Joseph Malicki <jmalicki at gmail.com> added the comment:

It seems like this was introduced by the fix for Issue 1566280.

Note that the threading module docs clear state:

"A thread can be flagged as a ?daemon thread?. The significance of this
flag is that the entire Python program exits when only daemon threads
are left. The initial value is inherited from the creating thread. The
flag can be set through the daemon property."

This behavior violates it.

The WaitForThreading() fix in Py_Main works only if sys.exit() is not
called, which disagrees with the documentation.

----------
nosy: +jmalicki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4684>
_______________________________________

From report at bugs.python.org  Thu Aug 27 00:42:36 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Aug 2009 22:42:36 +0000
Subject: [issue6733] curses line wrap broken when mixing full- and half-width
	unicode characters
In-Reply-To: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>
Message-ID: <1251326556.71.0.359796233697.issue6733@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you write a short example reproducing the bug?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6733>
_______________________________________

From report at bugs.python.org  Thu Aug 27 00:44:02 2009
From: report at bugs.python.org (Art Gillespie)
Date: Wed, 26 Aug 2009 22:44:02 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1251326642.55.0.183387208504.issue6759@psf.upfronthosting.co.za>


Art Gillespie <agillesp at gmail.com> added the comment:

Hi David,

Thanks for the review.  Patch attached.

(1)  I've moved that comment to the check's new location.

(2)  Fixed the bug and added tests for only one separator.  Also added
test data and tests for mixed eol files.

(3)  I changed this so that when the file is opened with universal
newline support, read(size) makes multiple calls to _do_read until size
bytes are read or EOF is reached.

----------
Added file: http://bugs.python.org/file14785/issue6759_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Thu Aug 27 00:55:24 2009
From: report at bugs.python.org (Art Gillespie)
Date: Wed, 26 Aug 2009 22:55:24 +0000
Subject: [issue6518] Enable 'with' statement in ossaudiodev module
In-Reply-To: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
Message-ID: <1251327324.89.0.626691999372.issue6518@psf.upfronthosting.co.za>


Art Gillespie <agillesp at gmail.com> added the comment:

Hi Victor,

I copied both the return NULL behavior in oss_exit and the oss_self
naming from Objects/fileobject.c:

http://paste.pocoo.org/show/136451/

Should they be changed there as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6518>
_______________________________________

From report at bugs.python.org  Thu Aug 27 01:29:22 2009
From: report at bugs.python.org (Todd Whiteman)
Date: Wed, 26 Aug 2009 23:29:22 +0000
Subject: [issue3210] subprocess.Popen does not release process handles if
	process cannot be started
In-Reply-To: <1214493762.8.0.246296591489.issue3210@psf.upfronthosting.co.za>
Message-ID: <1251329362.94.0.250466311266.issue3210@psf.upfronthosting.co.za>


Todd Whiteman <twhitema at yahoo.com.au> added the comment:

Is this a duplicate of this already fixed issue: issue5179 ?

----------
nosy: +twhitema

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3210>
_______________________________________

From report at bugs.python.org  Thu Aug 27 01:33:25 2009
From: report at bugs.python.org (Art Gillespie)
Date: Wed, 26 Aug 2009 23:33:25 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1251329605.28.0.71909563964.issue6759@psf.upfronthosting.co.za>


Art Gillespie <agillesp at gmail.com> added the comment:

Just found another bug in the code that sets the newlines attribute. 
Please disregard issue6759_3.diff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Thu Aug 27 02:59:15 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Aug 2009 00:59:15 +0000
Subject: [issue4684] sys.exit() exits program when non-daemonic threads are
	still running
In-Reply-To: <1229536748.7.0.859607140582.issue4684@psf.upfronthosting.co.za>
Message-ID: <1251334755.41.0.774000859839.issue4684@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Attached is a version of your program that calls sys.exit from a thread
other than the main one.  That sys.exit does not cause python to shut
down.  Exiting the main program by "falling off the end" does not result
in Python shutdown (pass an arbitrary argument to the example program to
see this). 

So what we have here, I believe, is a documentation problem, and I've
updated the issue to reflect that.  Please note in particular the last
two caveats in the 'thread' docs; I don't consider these adequate
documentation, but they do seem to be relevant to the issue at hand.

Does this make sense to you?

Note that issue 6634 should also be addressed in any update to the
relevant areas of the documentation.

----------
assignee:  -> georg.brandl
components: +Documentation -None
nosy: +georg.brandl, r.david.murray
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 3.0
Added file: http://bugs.python.org/file14786/threading_exit_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4684>
_______________________________________

From report at bugs.python.org  Thu Aug 27 03:12:31 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Aug 2009 01:12:31 +0000
Subject: [issue6787] thread docs contain an incorrect link in a reference to
	the 'exit' method
In-Reply-To: <1251335550.97.0.247554365962.issue6787@psf.upfronthosting.co.za>
Message-ID: <1251335550.97.0.247554365962.issue6787@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In the Caveats section of the thread docs reference is made to the
'exit' method.  The link generated, instead of being to the exit method
in the thread module, is to the exit 'constant' section 4.

----------
assignee: georg.brandl
components: Documentation
messages: 91992
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: thread docs contain an incorrect link in a reference to the 'exit' method
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6787>
_______________________________________

From report at bugs.python.org  Thu Aug 27 04:17:33 2009
From: report at bugs.python.org (Joseph Malicki)
Date: Thu, 27 Aug 2009 02:17:33 +0000
Subject: [issue4684] sys.exit() exits program when non-daemonic threads are
	still running
In-Reply-To: <1229536748.7.0.859607140582.issue4684@psf.upfronthosting.co.za>
Message-ID: <1251339453.42.0.0596362079559.issue4684@psf.upfronthosting.co.za>


Joseph Malicki <jmalicki at gmail.com> added the comment:

Is it actually just documentation?  Before Python 2.5, things worked
according to the documentation, and nothing in the revisions that
changed the behavior suggested this change in behavior was intentional.

Moving the WaitForThreadShutdown() from Modules/main.c to Py_Finalize()
would also fix this problem - I wonder why that wasn't the original
change, as it more closely mirrors how Python 2.4 worked, and the
documentation suggests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4684>
_______________________________________

From report at bugs.python.org  Thu Aug 27 05:57:30 2009
From: report at bugs.python.org (Art Gillespie)
Date: Thu, 27 Aug 2009 03:57:30 +0000
Subject: [issue6759] zipfile.ZipExtFile.read() is missing universal newline
	support
In-Reply-To: <1250922122.86.0.650490470964.issue6759@psf.upfronthosting.co.za>
Message-ID: <1251345450.45.0.552463118646.issue6759@psf.upfronthosting.co.za>


Art Gillespie <agillesp at gmail.com> added the comment:

Latest patch attached.

* Fixed the code that populates the newlines attribute.  I think I've
covered all the cases...

* Found another deviation from file object behavior in this module: 
Calling read with a negative size parameter does not always return the
remainder of the file as described in
http://docs.python.org/library/stdtypes.html#file.read  I went ahead and
fixed this--please let me know if I should open a separate issue and
submit a separate patch.

* Added more tests for mixed eol files, calling read with a negative
size parameter, reading a file with only crlfs

----------
Added file: http://bugs.python.org/file14787/issue6759_4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6759>
_______________________________________

From report at bugs.python.org  Thu Aug 27 06:17:09 2009
From: report at bugs.python.org (Ryan McGuire)
Date: Thu, 27 Aug 2009 04:17:09 +0000
Subject: [issue6788] codecs.open on Win32 does not force binary mode
In-Reply-To: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>
Message-ID: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>


New submission from Ryan McGuire <python.org at enigmacurry.com>:

Opening a UTF-8 encoded file with unix newlines ("\n") on Win32:

codecs.open("whatever.txt","r","utf-8").read()

replaces the newlines ("\n") with CR+LF ("\r\n").

The docs specifically say that :

"Files are always opened in binary mode, even if no binary mode was
specified. This is done to avoid data loss due to encodings using 8-bit
values. This means that no automatic conversion of '\n' is done on
reading and writing."

And yet, opening the file with an explicit binary mode resolves the
situation:

codecs.open("whatever.txt","rb","utf-8").read()

This reads the file with the original newlines unmodified.

The implementation of codecs.open and the documentation are out of sync.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 91995
nosy: EnigmaCurry, georg.brandl
severity: normal
status: open
title: codecs.open on Win32 does not force binary mode
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6788>
_______________________________________

From report at bugs.python.org  Thu Aug 27 09:03:23 2009
From: report at bugs.python.org (Yuv Gre)
Date: Thu, 27 Aug 2009 07:03:23 +0000
Subject: [issue6783] Add a builtin method to 'int' for base/radix conversion
In-Reply-To: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>
Message-ID: <1251356603.21.0.925481894937.issue6783@psf.upfronthosting.co.za>


Yuv Gre <ubershmekel at gmail.com> added the comment:

Use case - 'hashing' a counter for example like video ID's in youtube. 
One could use a regular int internally and publish a shorter 62-base id 
for links.

Guido said on http://mail.python.org/pipermail/python-dev/2006-
January/059923.html
"I think we ought to let this sit for a while and come back to it in a
few week's time. Is 'base' really the right name? It could just as
well be considered a conversion in the other direction. In common
usage, 'base' and 'radix' are about synonymous (except no-one uses
radix). Pethaps the 2nd argument should not be a keyword argument?

Also, this discussion made me wonder if conversions using other bases
than 10 should even be built-ins. A library module seems a more
appropriate place"

I'm hoping 182 weeks of clarity could help iron this issue out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6783>
_______________________________________

From report at bugs.python.org  Thu Aug 27 09:18:18 2009
From: report at bugs.python.org (Ayman)
Date: Thu, 27 Aug 2009 07:18:18 +0000
Subject: [issue6789] ftplib storelines does not honor strings returned in
	fp.readline
In-Reply-To: <1251357498.06.0.267830127898.issue6789@psf.upfronthosting.co.za>
Message-ID: <1251357498.06.0.267830127898.issue6789@psf.upfronthosting.co.za>


New submission from Ayman <ayman.alsairafi at gmail.com>:

in ftplibs.storlines, a call is done on what should be a Text stream:
fp.readline()
This would work in pre 3.x as it returns bytes but now that readlines
returns a string, the call at lines 477 would fail:

  File "C:\Python31\lib\ftplib.py", line 477, in storlines
    if buf[-1] in B_CRLF: buf = buf[:-1]
TypeError: Type str doesn't support the buffer API

The readline call should then be encoded().

----------
components: Library (Lib)
messages: 91997
nosy: aymanhs
severity: normal
status: open
title: ftplib storelines does not honor strings returned in fp.readline
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6789>
_______________________________________

From report at bugs.python.org  Thu Aug 27 10:13:28 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Thu, 27 Aug 2009 08:13:28 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2
	and	and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251360808.63.0.119401688468.issue6784@psf.upfronthosting.co.za>


RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

its even worse

python3:
>>> import pickle
>>> pickle.dumps(b'', protocol=2)
b'\x80\x02c__builtin__\nbytes\nq\x00]q\x01\x85q\x02Rq\x03.'

python2.6:
>>> import pickle
>>> pickle.loads('\x80\x02c__builtin__\nbytes\nq\x00]q\x01\x85q\x02Rq\x03.')
'[]'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Thu Aug 27 11:36:45 2009
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 27 Aug 2009 09:36:45 +0000
Subject: [issue6788] codecs.open on Win32 does not force binary mode
In-Reply-To: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>
Message-ID: <4A9653AA.70700@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ryan McGuire wrote:
> 
> New submission from Ryan McGuire <python.org at enigmacurry.com>:
> 
> Opening a UTF-8 encoded file with unix newlines ("\n") on Win32:
> 
> codecs.open("whatever.txt","r","utf-8").read()
> 
> replaces the newlines ("\n") with CR+LF ("\r\n").
> 
> The docs specifically say that :
> 
> "Files are always opened in binary mode, even if no binary mode was
> specified. This is done to avoid data loss due to encodings using 8-bit
> values. This means that no automatic conversion of '\n' is done on
> reading and writing."
> 
> And yet, opening the file with an explicit binary mode resolves the
> situation:
> 
> codecs.open("whatever.txt","rb","utf-8").read()
> 
> This reads the file with the original newlines unmodified.
> 
> The implementation of codecs.open and the documentation are out of sync.

The implementation looks like this:

    if encoding is not None and \
       'b' not in mode:
        # Force opening of the file in binary mode
        mode = mode + 'b'

in both Python 2 and 3, so I'm not sure what could be causing
this.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6788>
_______________________________________

From report at bugs.python.org  Thu Aug 27 13:53:55 2009
From: report at bugs.python.org (fugounashi)
Date: Thu, 27 Aug 2009 11:53:55 +0000
Subject: [issue6733] curses line wrap broken when mixing full- and half-width
	unicode characters
In-Reply-To: <1250642602.2.0.807698027943.issue6733@psf.upfronthosting.co.za>
Message-ID: <1251374035.98.0.926030746912.issue6733@psf.upfronthosting.co.za>


fugounashi <fugounashi+python at gmail.com> added the comment:

thanks for looking into it

this should do it:

#! /usr/bin/python
import locale
locale.setlocale(locale.LC_ALL, '')
code = locale.getpreferredencoding()
import curses
def main(stdscr):
    stdscr.erase()
    stdscr.move(0, 0)
    for i in range(0,stdscr.getmaxyx()[1] - 1):
        stdscr.addstr(".");
    stdscr.addstr(u"\u3007\u3007".encode(code));
    stdscr.refresh()
curses.wrapper(main)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6733>
_______________________________________

From report at bugs.python.org  Thu Aug 27 15:29:31 2009
From: report at bugs.python.org (Ryan McGuire)
Date: Thu, 27 Aug 2009 13:29:31 +0000
Subject: [issue6788] codecs.open on Win32 does not force binary mode
In-Reply-To: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>
Message-ID: <1251379771.65.0.00299378193389.issue6788@psf.upfronthosting.co.za>


Ryan McGuire <python.org at enigmacurry.com> added the comment:

Uploading a doctest for this. 

The tests are successful on Linux using Python 2.6
They fail on Win32 with Python 2.6

----------
Added file: http://bugs.python.org/file14788/codecs_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6788>
_______________________________________

From report at bugs.python.org  Thu Aug 27 15:53:42 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Aug 2009 13:53:42 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2
	and	and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251381222.77.0.543410640096.issue6784@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem with trying to solve the following issue:
   "a bytes instance from python3 is pickled as custom class in
protocols <3"
is that if we pickle bytes from Python 3 as a 2.x str in protocol <= 2,
unpickling it using Python 3 will yield a str (unicode), not a bytes
object. Therefore the whole chain (pickling then unpickling) will not be
idempotent.

----------
components: +Library (Lib) -None
nosy: +alexandre.vassalotti, gvanrossum, pitrou
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Thu Aug 27 16:55:22 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Thu, 27 Aug 2009 14:55:22 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2
	and	and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251384922.24.0.125968542143.issue6784@psf.upfronthosting.co.za>


RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

unpickle of any non-ascii string from python2 will break
the only way out would be to ensure text strings and a single defined
encoding (at that point storing unicode strings in any case seems more
practical)

also byte-strings stored as python2 str would break

and since i pass around binary strings as parts of objects, its just
completely broken for me

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Thu Aug 27 17:07:40 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Aug 2009 15:07:40 +0000
Subject: [issue3143] development docs waste a lot of horizontal space on left
	nav bar
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251385660.69.0.659097135603.issue3143@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I just did a quick test about making the sidebar collapsible.
Add these lines at the end of default.css to see how the page might look
like with the sidebar collapsed:

/* collapse the sidebar */
div.sphinxsidebar {
    /* border: 3px solid red; */
    width: 1em !important;
}
/* hide the content of the sidebar */
div.sphinxsidebarwrapper {
    display: none;
}
/* expand the page to use the sidebar space */
div.bodywrapper{
    /* border: 3px solid blue; */
    margin-left: 1em !important;
}

A "<<" / ">>" button has to be added (via JS) to collapse and restore
the sidebar. The CSS properties have to be changed via JS too, the users
without JS won't notice any difference at all.
When the sidebar is collapsed, it is possible to make it appear again
clicking anywhere on the 1em-wide collapsed sidebar on the left (and not
only on the ">>").
The sidebar could be hidden completely by placing the "<<" / ">>" button
or an "Hide/Show sidebar" link in the top-left corner, but I don't know
exactly where (before the small python icon? just under it in a
"floating box"?).

The WebDeveloper plug-in of Firefox can be used to see the changes on
the fly (CSS -> Edit CSS -> paste the code at the end of default.css),
otherwise you can edit the CSS manually.
Feedback and comments appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Thu Aug 27 17:23:28 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Aug 2009 15:23:28 +0000
Subject: [issue3143] development docs waste a lot of horizontal space on left
	nav bar
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251386608.42.0.759802012123.issue3143@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a screenshot of the result.
I also made the top bar fixed as described in #4965, so it's always
visible even if the user scrolled till the middle of the page (this is
not related to this issue and will be addressed in #4965 though).

----------
Added file: http://bugs.python.org/file14789/nosidebar.gif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Thu Aug 27 17:36:39 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Aug 2009 15:36:39 +0000
Subject: [issue3143] development docs waste a lot of horizontal space on left
	nav bar
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251387399.17.0.117418290002.issue3143@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Another screenshot that shows the page with and without the sidebar,
with a "photoshopped" "<<" / ">>" button.

----------
Added file: http://bugs.python.org/file14790/visible-vs-hidden.gif

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Thu Aug 27 17:42:11 2009
From: report at bugs.python.org (Art Gillespie)
Date: Thu, 27 Aug 2009 15:42:11 +0000
Subject: [issue5148] gzip.open breaks with  'U' flag
In-Reply-To: <1233709542.39.0.638969424034.issue5148@psf.upfronthosting.co.za>
Message-ID: <1251387731.11.0.429526624961.issue5148@psf.upfronthosting.co.za>


Art Gillespie <agillesp at gmail.com> added the comment:

The problem appears to be that the gzip module simply doesn't support
universal newlines yet.

I'm currently working on the zipfile module's universal newline support
(issue6759) so if nobody else is working on this, I'll do it.

I'm not sure if file object's open() behavior when presented with 'rUb'
is correct or not.

>>> f = open("test.txt", "w").write("blah\r\nblah\rblah\nblah\r\n")
>>> f = open("test.txt", "rUb")
>>> f.read()
'blah\nblah\nblah\nblah\n'

Since 'U' and 'b' are conceptually mutually exclusive on platforms where
'b' matters, I can see this being confusing.

----------
nosy: +agillesp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5148>
_______________________________________

From report at bugs.python.org  Thu Aug 27 18:43:13 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 27 Aug 2009 16:43:13 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1251391393.64.0.485701939568.issue5329@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


Added file: http://bugs.python.org/file14791/os-popen-list.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5329>
_______________________________________

From report at bugs.python.org  Thu Aug 27 18:44:58 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 27 Aug 2009 16:44:58 +0000
Subject: [issue5329] os.popen2 and os.popen3 in python 2.6 incompatible with
	os.popen* in python 2.5
In-Reply-To: <1235121245.47.0.613044216429.issue5329@psf.upfronthosting.co.za>
Message-ID: <1251391498.88.0.0787233269087.issue5329@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Attached os-popen-list.patch which includes all of the earlier
os-popen.diff and adds tests which fail without this patch and pass with
it.  They also pass on Python 2.5.  The patch is against the Python 2.6
maintenance branch, but presumably it should be applied to trunk as well.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5329>
_______________________________________

From report at bugs.python.org  Thu Aug 27 19:54:11 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 27 Aug 2009 17:54:11 +0000
Subject: [issue6499] Can't import xmlrpclib,
	DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1251395651.36.0.778138179569.issue6499@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Not yet, the machine I was using to work on this is currently broken and
I couldn't test the new test_docxmlrpc yet. Once I've fixed the machine
and tried it I'll let you know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:04:42 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 27 Aug 2009 19:04:42 +0000
Subject: [issue6783] Add a builtin method to 'int' for base/radix conversion
In-Reply-To: <1251228941.52.0.551451692653.issue6783@psf.upfronthosting.co.za>
Message-ID: <1251399882.01.0.7841686268.issue6783@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I'm hoping 182 weeks of clarity could help iron this issue out.

:-)

I really think should bring this up on the python-ideas mailing list[1];  
it's much more likely to get resolved one way or the other if you do.

[1] http://mail.python.org/mailman/listinfo/python-ideas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6783>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:04:43 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Aug 2009 19:04:43 +0000
Subject: [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1251399883.41.0.276907909433.issue6508@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:12:04 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 27 Aug 2009 19:12:04 +0000
Subject: [issue6787] thread docs contain an incorrect link in a reference to
	the 'exit' method
In-Reply-To: <1251335550.97.0.247554365962.issue6787@psf.upfronthosting.co.za>
Message-ID: <1251400324.89.0.770960323448.issue6787@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74555, thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6787>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:15:15 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Thu, 27 Aug 2009 19:15:15 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2
	and	and python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251400515.75.0.651565476439.issue6784@psf.upfronthosting.co.za>


RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

in case the actual behavior is not supposed to change

how about a way to declare one wants exact 1:1 mapping between py2<>py3,
so str<>bytes and unicode<>str will work for sure

something like load/dump(..., encoding=bytes) just crossed my mind

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Thu Aug 27 21:57:26 2009
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 27 Aug 2009 19:57:26 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1251403046.72.0.428600418729.issue6243@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Andrew - do you still feel responsible for curses?

----------
assignee:  -> akuchling
nosy: +akuchling, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6243>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:08:03 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 27 Aug 2009 21:08:03 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2
	and	and python3
In-Reply-To: <1251400515.75.0.651565476439.issue6784@psf.upfronthosting.co.za>
Message-ID: <4A96F5AF.3010806@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> how about a way to declare one wants exact 1:1 mapping between py2<>py3,
> so str<>bytes and unicode<>str will work for sure

In a sense, that's already possible. Inherit from _Pickler/_Unpickler,
and replace the dispatch dict with a different mapping.

I wouldn't object to supporting this with an option, though, assuming it
was properly documented and implemented for both pickle and _pickle
(probably along with pickletools).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:08:19 2009
From: report at bugs.python.org (Jake McGuire)
Date: Thu, 27 Aug 2009 21:08:19 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>


New submission from Jake McGuire <jake at youtube.com>:

As of Python 2.6 you can no longer pass an array to 
httplib.HTTPConnection.send.

Issue1065257 added code to httplib to attempt to determine whether a 
file-like object was passed to certain methods (e.g. send), and to 
stream the data if so.

The patch uses "hasattr(obj, 'read')" as a proxy for "is a file-like 
object".

array.array objects have a method called "read" that is almost entirely 
disanalogous to the "read" method on a file-like object.

Hilarity ensues.

----------
messages: 92015
nosy: jakemcguire
severity: normal
status: open
title: httplib and array do not play together well
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:14:03 2009
From: report at bugs.python.org (andrew cooke)
Date: Thu, 27 Aug 2009 21:14:03 +0000
Subject: [issue3058] Let SimpleXMLRPCServer pass client_address to called
	functions.
In-Reply-To: <1212855971.92.0.424447915547.issue3058@psf.upfronthosting.co.za>
Message-ID: <1251407643.57.0.234338995525.issue3058@psf.upfronthosting.co.za>


andrew cooke <andrew at acooke.org> added the comment:

Came here wondering how best to solve this myself.

I already subclass the request handler to do client validation (password
etc) and it stuck me that a simpler solution would be to use thread
local storage.

This avoids having to modify dispatch.  The disadvantage is that this
uses a single global scope.  I don't think it's a better solution than
that suggested by samwyse for a final solution, but I thought I'd note
it here because it's a simpler alternative for people needing to add a
work-around, and I suspect many people aren't aware of the possibility.

>>> import _threading_local ; help(_threading_local)

If this wouldn't work (maybe I've misunderstood the server threading?)
then I'd appreciate someone correcting me.  Thanks.

----------
nosy: +acooke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3058>
_______________________________________

From report at bugs.python.org  Thu Aug 27 23:34:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Aug 2009 21:34:19 +0000
Subject: [issue6790] httplib and array do not play together well
In-Reply-To: <1251407299.25.0.631458654442.issue6790@psf.upfronthosting.co.za>
Message-ID: <1251408859.27.0.612745144156.issue6790@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That method of array.array has been deprecated since 1.5.1 according to
the docs.  Too bad nobody finished the job and removed it.

Perhaps array.array could be special cased in the relevant code until
the method can actually be removed.

----------
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6790>
_______________________________________

From report at bugs.python.org  Fri Aug 28 00:21:34 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 27 Aug 2009 22:21:34 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1251411694.02.0.359273637028.issue6275@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Committed this much more harmless patch to the trunk as revision 74556

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Fri Aug 28 00:31:56 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Aug 2009 22:31:56 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1251412316.62.0.405236215253.issue6745@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

First, make sure that your Python3 build uses libncursesw and not
libncurses, because libncursesw supports unicode, whereas libncurses
doesn't... On UNIX, use the following command to check this:

ldd $(./python -c "import _curses; print(_curses.__file__)")|grep curses

> Note that the output here always seems to be utf-8, 
> which is plain wrong.

Yes, addstr() always uses utf8 to convert unicode to bytes. It's wrong
if the terminal uses a different charset. But I'm not sure that using
bytes is a better idea: since you would like to print characters,
unicode is the right type.

An idea would be to use a configurable charset. Eg. add a 'charset'
attribute to a window (or to the module).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Aug 28 00:34:06 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Aug 2009 22:34:06 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1251412446.26.0.323174344431.issue6745@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #4787

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Aug 28 00:59:27 2009
From: report at bugs.python.org (Trundle)
Date: Thu, 27 Aug 2009 22:59:27 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1251413967.78.0.78727647797.issue6745@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

Yes, it uses a version of ncurses which supports wide characters, I
checked that.

I agree that using bytes instead may not be the preferred solution in
Python 3. The point is, currently, it is broken if the user does not
use an utf-8 environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Aug 28 01:14:31 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 27 Aug 2009 23:14:31 +0000
Subject: [issue6654] Add "path" to the xmrlpc dispatcher method
In-Reply-To: <1249507000.5.0.428139109569.issue6654@psf.upfronthosting.co.za>
Message-ID: <1251414871.79.0.599091941618.issue6654@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

After a short discussion on python-dev 
(http://mail.python.org/pipermail/python-dev/2009-August/091069.html) 
there were no objections.  On python-ideas there were no responses.  
Commited as revision 74558

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6654>
_______________________________________

From report at bugs.python.org  Fri Aug 28 01:15:39 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Aug 2009 23:15:39 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1251414939.38.0.685243467659.issue6745@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't really understand because your example, umlaut3x.py, works
correctly on my computer (py3k, ubunty jaunty).

> The point is, currently, it is broken if the user 
> does not use an utf-8 environment.

So the problem is that the charset is hardcoded to utf8. You would like
to be able to change that. Or better, than Python guess your terminal
charset. Right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Aug 28 01:46:23 2009
From: report at bugs.python.org (Trundle)
Date: Thu, 27 Aug 2009 23:46:23 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1251416783.55.0.0666482622587.issue6745@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

Of course it works for you. As you stated in issue #4787, your locale
is 'fr_FR.UTF-8'.

And I don't want Python to guess my terminal's encoding. I want Python
to respect my locale. Which is 'de_DE at euro', and not utf-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Aug 28 02:00:00 2009
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Aug 2009 00:00:00 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1251417600.68.0.212799094179.issue6745@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a first patch to add a method setcharset() to the window class.

Using my patch, you can fix your example by adding the line:

   screen.setcharset(<your charset>)

before addstr().

It's an initial hack to fix the issue. Next steps are:
 - use something better than utf8 as the default charset, maybe
locale.getpreferredencoding()
 - copy the charset on new window creation?

----------
keywords: +patch
Added file: http://bugs.python.org/file14792/curses_charset.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Aug 28 05:38:16 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 28 Aug 2009 03:38:16 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251430696.04.0.0312716055724.issue3143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
title: development docs waste a lot of horizontal space on left nav bar -> Make the left sidebar in the doc collapsible
Added file: http://bugs.python.org/file14793/sidebar.js

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Fri Aug 28 05:51:56 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 28 Aug 2009 03:51:56 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251431516.51.0.558531622655.issue3143@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a first attempt to make the sidebar collapsible.
The sidebar.js file is the JS script I did, the sidebar.zip file
contains a couple of pages taken from the doc with the sidebar scripts
already included in a <script>.

If you want to try it just extract the files, open the *.html with a
browser and it should work.

This is not supposed to be the final version, I tested it only on FF3
(where it seems to work fine) and on IE6 (where it is as broken as you
would expect). This is also the first time I use JQuery, so any comments
and suggestions are welcomed (both about the code and the result).

----------
priority: low -> normal
Added file: http://bugs.python.org/file14794/sidebar.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Fri Aug 28 10:32:52 2009
From: report at bugs.python.org (sumar)
Date: Fri, 28 Aug 2009 08:32:52 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>


New submission from sumar <m.sucajtys at gmail.com>:

During writing some code I discovered some behaviour of httplib. When we
connect to host, which doesn?t respond with status line, but it just
sending data, httplib may consume more and more memory, becouce when we
execute
h = httplib.HTTPConnection(?host?)
h.conect()
h.request(?GET?, ?/?)
r = h.getresponse()
httplib tries to read one line from host. If host doesn?t send new line
character (?\n?), httplib reads more and more data. On my tests httplib
could consume all of 4GB of memory and the python process was killed by
oom_killer.
The resolution is to limit maximum amount of data read on getting
response. I have performed some test:
I received 3438293 from hosts located in the network. The longest valid
response line is
HTTP/1.1 500 ( The specified Secure Sockets Layer (SSL) port is not
allowed. ISA Server is not configured to allow SSL requests from this
port. Most Web browsers use port 443 for SSL requests.  )\r\n
and it has 197 characters.
In RFC2616 in section 6.1 we have:
?The first line of a Response message is the Status-Line, consisting of
the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP characters.
No CR or LF is allowed except in the final CRLF sequence.
       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
(..)The Reason-Phrase is intended to give a short textual description of
the Status-Code.?
So limiting maximum status line length to 256 characters is a solution
of this problem. It doesn?t break compatibility withc RFC 2616.

My patch was written originally on python2.4, but I?ve tested it on
python2.6:
[ms at host python2.6]$ patch --dry-run -i /home/ms/httplib.patch
patching file httplib.py
Hunk #1 succeeded at 209 (offset 54 lines).

----------
components: Library (Lib)
files: httplib.patch
keywords: patch
messages: 92027
nosy: m.sucajtys
severity: normal
status: open
title: httplib read status memory usage
type: resource usage
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14795/httplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Fri Aug 28 10:52:20 2009
From: report at bugs.python.org (erluk)
Date: Fri, 28 Aug 2009 08:52:20 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>


New submission from erluk <erluk at pargalaxy.de>:

An installer for source-only modules created using distutils
(bdist_wininst) will only detect 32bit installations of Python on 64bit
Windows machines.

Expected behaviour:
The installer lists 32bit and 64bit installations of Python on the machine.

----------
assignee: tarek
components: Distutils
messages: 92028
nosy: erluk, tarek
severity: normal
status: open
title: Distutils-based installer does not detect 64bit versions of Python
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Fri Aug 28 11:38:22 2009
From: report at bugs.python.org (Miles Kaufmann)
Date: Fri, 28 Aug 2009 09:38:22 +0000
Subject: [issue5468] urlencode does not handle "bytes",
	and could easily handle alternate encodings
In-Reply-To: <1236696316.6.0.478633045289.issue5468@psf.upfronthosting.co.za>
Message-ID: <1251452302.28.0.326117583475.issue5468@psf.upfronthosting.co.za>


Miles Kaufmann <milesck at umich.edu> added the comment:

I've attached a patch that provides similar functionality to Dan Mahn's 
urlencode(), as well as providing encoding and errors parameters to 
parse_qs and parse_qsl, updating the documentation to reflect the added 
parameters, and adding test cases.  The implementation of urlencode() is 
not the same as dmahn's, and has a more straightforward control flow and 
less code duplication than the current implementation.

(For the tests, I tried to match the style of the file I was adding to 
with regard to (expect, result) order, which is why it's inconsistent.)

----------
keywords: +patch
versions: +Python 3.2
Added file: http://bugs.python.org/file14796/urllib_parse.py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5468>
_______________________________________

From report at bugs.python.org  Fri Aug 28 11:38:54 2009
From: report at bugs.python.org (RonnyPfannschmidt)
Date: Fri, 28 Aug 2009 09:38:54 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251452334.49.0.915316147796.issue6784@psf.upfronthosting.co.za>


Changes by RonnyPfannschmidt <Ronny.Pfannschmidt at gmx.de>:


----------
title: byte/unicode pickle incompatibilities between python2 and	and python3 -> byte/unicode pickle incompatibilities between python2 and python3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Fri Aug 28 11:43:04 2009
From: report at bugs.python.org (sumar)
Date: Fri, 28 Aug 2009 09:43:04 +0000
Subject: [issue6791] httplib read status memory usage
In-Reply-To: <1251448372.35.0.316865122555.issue6791@psf.upfronthosting.co.za>
Message-ID: <1251452584.45.0.583651946034.issue6791@psf.upfronthosting.co.za>


sumar <m.sucajtys at gmail.com> added the comment:

I've also check patch against code in svn tree:
wget http://svn.python.org/projects/python/trunk/Lib/httplib.py
patch -p0 -i httplib.patch --dry-run
patching file httplib.py
Hunk #1 succeeded at 209 (offset 54 lines).
Hunk #2 succeeded at 303 (offset 10 lines).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6791>
_______________________________________

From report at bugs.python.org  Fri Aug 28 11:59:54 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 09:59:54 +0000
Subject: [issue6793] decimal.py: div_nearest ==> _div_nearest
In-Reply-To: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>
Message-ID: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

--- a-decimal.py        2009-08-28 11:48:45.000000000 +0200
+++ b-decimal.py        2009-08-28 11:49:47.000000000 +0200
@@ -4845,7 +4845,7 @@
         log_tenpower = f*M # exact
     else:
         log_d = 0  # error < 2.31
-        log_tenpower = div_nearest(f, 10**-p) # error < 0.5
+        log_tenpower = _div_nearest(f, 10**-p) # error < 0.5
 
     return _div_nearest(log_tenpower+log_d, 100)

----------
components: Library (Lib)
messages: 92031
nosy: skrah
severity: normal
status: open
title: decimal.py: div_nearest ==> _div_nearest
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6793>
_______________________________________

From report at bugs.python.org  Fri Aug 28 12:15:04 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 10:15:04 +0000
Subject: [issue6794] decimal.py: incorrect results in NaN comparisons
In-Reply-To: <1251454504.69.0.93743560426.issue6794@psf.upfronthosting.co.za>
Message-ID: <1251454504.69.0.93743560426.issue6794@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi,

I believe the following comparisons aren't correct:

1:

Decimal("-sNaN63450748854172416").compare_total(Decimal("-sNaN911993"))
==> Decimal('1')

Should be: Decimal('-1') (checked against decNumber)


2:
Decimal("NaN1222222222222").compare_total_mag(Decimal("-NaN999999"))
==> Decimal('-1')

Should be: Decimal('1') (checked against decNumber)

----------
components: Library (Lib)
messages: 92032
nosy: skrah
severity: normal
status: open
title: decimal.py: incorrect results in NaN comparisons

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6794>
_______________________________________

From report at bugs.python.org  Fri Aug 28 12:18:20 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 28 Aug 2009 10:18:20 +0000
Subject: [issue6794] decimal.py: incorrect results in NaN comparisons
In-Reply-To: <1251454504.69.0.93743560426.issue6794@psf.upfronthosting.co.za>
Message-ID: <1251454700.14.0.59096113843.issue6794@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +marketdickinson
priority:  -> normal
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6794>
_______________________________________

From report at bugs.python.org  Fri Aug 28 12:23:03 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 28 Aug 2009 10:23:03 +0000
Subject: [issue6793] decimal.py: div_nearest ==> _div_nearest
In-Reply-To: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>
Message-ID: <1251454983.04.0.0292198705463.issue6793@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is already fixed in the trunk.

----------
nosy: +ezio.melotti, marketdickinson
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6793>
_______________________________________

From report at bugs.python.org  Fri Aug 28 12:28:27 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 10:28:27 +0000
Subject: [issue6795] decimal.py: minor issues && usability
In-Reply-To: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
Message-ID: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi,

a couple of minor issues:

1:
>>> c = getcontext()
>>> c.traps[InvalidOperation] = False
>>> Decimal("NaN").__int__()
Decimal('NaN')

I think the return value should be None.


2:
>>> c = getcontext()
>>> c.traps[InvalidOperation] = False
>>> Decimal("NaN").__long__()
Traceback (most recent call last):
...
RuntimeError: maximum recursion depth exceeded in cmp


3:
>>> setcontext(8)
>>> getcontext()
8

This is just a usability issue, perhaps a type check could be performed.

----------
components: Library (Lib)
messages: 92034
nosy: skrah
severity: normal
status: open
title: decimal.py: minor issues && usability

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6795>
_______________________________________

From report at bugs.python.org  Fri Aug 28 13:24:15 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Aug 2009 11:24:15 +0000
Subject: [issue6794] decimal.py: incorrect results in NaN comparisons
In-Reply-To: <1251454504.69.0.93743560426.issue6794@psf.upfronthosting.co.za>
Message-ID: <1251458655.0.0.844027921064.issue6794@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> marketdickinson
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6794>
_______________________________________

From report at bugs.python.org  Fri Aug 28 14:03:12 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 28 Aug 2009 12:03:12 +0000
Subject: [issue6275] let unittest.assertRaises() return the exception object
	caught
In-Reply-To: <1244842994.31.0.225778913715.issue6275@psf.upfronthosting.co.za>
Message-ID: <1251460992.77.0.333486705115.issue6275@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Cool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6275>
_______________________________________

From report at bugs.python.org  Fri Aug 28 14:33:48 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Aug 2009 12:33:48 +0000
Subject: [issue6795] decimal.py: minor issues && usability
In-Reply-To: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
Message-ID: <1251462828.6.0.103783934865.issue6795@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> marketdickinson
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6795>
_______________________________________

From report at bugs.python.org  Fri Aug 28 14:51:34 2009
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Aug 2009 12:51:34 +0000
Subject: [issue6793] decimal.py: div_nearest ==> _div_nearest
In-Reply-To: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>
Message-ID: <1251463894.06.0.421313335986.issue6793@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +26backport
resolution: fixed -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6793>
_______________________________________

From report at bugs.python.org  Fri Aug 28 15:44:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Aug 2009 13:44:58 +0000
Subject: [issue6794] decimal.py: incorrect results in NaN comparisons
In-Reply-To: <1251454504.69.0.93743560426.issue6794@psf.upfronthosting.co.za>
Message-ID: <1251467098.92.0.100788510901.issue6794@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report!  I've applied a quick fix in the trunk in r74564; 
merged to other branches in r74565 (release26-maint), r74566 (py3k) and 
r74567 (release31-maint).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6794>
_______________________________________

From report at bugs.python.org  Fri Aug 28 15:45:14 2009
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Aug 2009 13:45:14 +0000
Subject: [issue6793] decimal.py: div_nearest ==> _div_nearest
In-Reply-To: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>
Message-ID: <1251467114.17.0.670995793906.issue6793@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, it is also fixed in 2.6 maintenance. I was hoping it could go into
2.5 maintenance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6793>
_______________________________________

From report at bugs.python.org  Fri Aug 28 15:46:18 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Aug 2009 13:46:18 +0000
Subject: [issue6793] decimal.py: div_nearest ==> _div_nearest
In-Reply-To: <1251453594.44.0.819159397261.issue6793@psf.upfronthosting.co.za>
Message-ID: <1251467178.08.0.358356096619.issue6793@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's a security-fixes only policy in place for the 2.5 branch, so I'm 
afraid this isn't going to happen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6793>
_______________________________________

From report at bugs.python.org  Fri Aug 28 16:27:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 28 Aug 2009 14:27:01 +0000
Subject: [issue6795] decimal.py: minor issues && usability
In-Reply-To: <1251455307.6.0.293968499648.issue6795@psf.upfronthosting.co.za>
Message-ID: <1251469621.38.0.248001245965.issue6795@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the reports.

Issue 1. If this is going to be changed, I'd rather see 
int(Decimal('nan')) raise ValueError (just as int(float('nan')) does) 
than return None.

Conversions from Decimal to native integers lie outside the scope of the 
standard, so there's not much help there.  However, precisely *because* 
they lie outside the standard, it seems wrong to be raising a Decimal 
exception (Decimal.InvalidContext) here.  It's also inconsistent with 
the treatment of infinities:  int(Decimal('infinity')) currently gives 
an OverflowError.

Given the lack of guidance from the decimal standard, the next place to 
turn is probably IEEE 754.  IEEE 754-2008, section 5.8 ("Details of 
conversions from floating-point to integer formats") says: 

"""When a NaN or infinite operand cannot be represented in the 
destination format and this cannot otherwise be indicated, the invalid 
operation exception shall be signaled."""

As far as I can tell, when the invalid-operation trap is disabled, the 
return value is undefined in this case (see 7.2(i) in IEEE 754-2008).

But in Python this error condition *can* 'otherwise be indicated', by 
raising a suitable Python exception.  So I propose changing the decimal 
module in 2.7 and 3.2 so that int(Decimal('nan')) and 
long(Decimal('nan')) raise ValueError.

Raymond, Facundo:  any thoughts on this?


Issue 2. A clear bug; will fix.  Thanks.


Issue 3. I can't see how this could cause any real problems, since you'd 
get an error as soon as you tried to use a bogus context.  Further, an 
explicit typecheck goes against Python's duck-typing philosophy:  a 
suitably crazy and misguided person ought to be able to create their own 
'quacks like a context' class, not necessarily inheriting from 
Decimal.Context, and pass this into setcontext in place of a real 
context.  I'm -0 on changing this.

----------
nosy: +facundobatista, rhettinger
priority:  -> normal
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6795>
_______________________________________

From report at bugs.python.org  Fri Aug 28 20:04:53 2009
From: report at bugs.python.org (Keith Campbell)
Date: Fri, 28 Aug 2009 18:04:53 +0000
Subject: [issue6796] invalid print in tkinter\test\test_ttk\test_widgets.py
In-Reply-To: <1251482693.78.0.0973789349285.issue6796@psf.upfronthosting.co.za>
Message-ID: <1251482693.78.0.0973789349285.issue6796@psf.upfronthosting.co.za>


New submission from Keith Campbell <keithc at mitre.org>:

Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART 
================================
>>> 
>>> ================================ RESTART 
================================
>>> 
Traceback (most recent call last):
  File "C:\Python31\Lib\tkinter\test\test_ttk\test_widgets.py", line 4, 
in <module>
    from test.support import requires, run_unittest
  File "c:\spring2000\o7python\lib\test.py", line 33
    print 'Main process exiting.'
                                ^
SyntaxError: invalid syntax

----------
components: Tkinter
messages: 92040
nosy: keithc
severity: normal
status: open
title: invalid print in tkinter\test\test_ttk\test_widgets.py
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6796>
_______________________________________

From report at bugs.python.org  Fri Aug 28 21:08:25 2009
From: report at bugs.python.org (Rogi)
Date: Fri, 28 Aug 2009 19:08:25 +0000
Subject: [issue6498] Py_Main() does not return on SystemExit
In-Reply-To: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
Message-ID: <1251486505.16.0.201242552769.issue6498@psf.upfronthosting.co.za>


Rogi <rogi at linuxmail.org> added the comment:

I will try to fix and submit a patch. Just a second =op

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6498>
_______________________________________

From report at bugs.python.org  Fri Aug 28 22:11:41 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Aug 2009 20:11:41 +0000
Subject: [issue6765] math.log, log10 inconsistency
In-Reply-To: <1251028577.65.0.346592203273.issue6765@psf.upfronthosting.co.za>
Message-ID: <1251490301.77.0.806122455977.issue6765@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Reopening as doc issue. This is at least the second time this issue has
been reported (see #3724), with some agreement on doc tweak, but not done.

Specific suggestions for math module doc, 9.2.2:

math.log(x[, base]) 
Return the logarithm of x to the given base. 

add: ", calculated as log(x)/log(base)" before period.

[This could be removed if better method ever implemented.]

math.log10(x) 
Return the base-10 logarithm of x.

add: "This is usually more accurate than log(x, 10)."

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl, tjreedy
resolution: invalid -> 
status: closed -> open
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6765>
_______________________________________

From report at bugs.python.org  Fri Aug 28 22:15:08 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Aug 2009 20:15:08 +0000
Subject: [issue6771] Curses.wrapper: documentation/implementation error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <1251490508.96.0.0175810656798.issue6771@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: documentation/implementation error -> Curses.wrapper: documentation/implementation error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________

From report at bugs.python.org  Fri Aug 28 22:32:17 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Aug 2009 20:32:17 +0000
Subject: [issue6786] readline and zero based indexing
In-Reply-To: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>
Message-ID: <1251491537.52.0.867771966638.issue6786@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please ask questions on, for instance, the python-list (c.l.p).

If you find evidence that this is actually a bug, please supply.
Else, close (or change to doc issue -- see below).

My *guess* is that history lists are 1-based and Python conforms to that.
If so, the doc should mention that. But I do not know.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6786>
_______________________________________

From report at bugs.python.org  Fri Aug 28 22:56:26 2009
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 28 Aug 2009 20:56:26 +0000
Subject: [issue6054] tarfile normalizes arcname
In-Reply-To: <1242663597.58.0.136129786751.issue6054@psf.upfronthosting.co.za>
Message-ID: <1251492986.38.0.569462853801.issue6054@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I have done some research in order to find a suitable behaviour for
tarfile. I wrote a script to test to what extent all the different tar
implementations transform input pathnames. The results can be found at
http://www.gustaebel.de/lars/tarfile/wwgtd.html.

My conclusion is the following: tarfile now does no pathname
transformation whatsoever except for converting absolute to relative
paths (to stay backwards compatible). This way tarfile is closer to
POSIX, applies less magic and gives more responsibility to the user.

Fixed in r74571 (trunk) and r74573 (py3k). Thanks for your report.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6054>
_______________________________________

From report at bugs.python.org  Fri Aug 28 23:34:33 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 28 Aug 2009 21:34:33 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1251495273.01.0.792888567031.issue6792@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Unfortunately, I don't think this is possible. When creating the
installer, you have to make a choice whether to make it a 32-bit or a
64-bit MSI file - whether or not you have any architecture dependency.

At least, can't think of an easy way to solve it.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Fri Aug 28 23:49:58 2009
From: report at bugs.python.org (Jonathan Windle)
Date: Fri, 28 Aug 2009 21:49:58 +0000
Subject: [issue6797] When Beginning Expression with Lookahead Assertion I get
	no Matches
In-Reply-To: <1251496198.81.0.453692564995.issue6797@psf.upfronthosting.co.za>
Message-ID: <1251496198.81.0.453692564995.issue6797@psf.upfronthosting.co.za>


New submission from Jonathan Windle <jonathanwindle at gmail.com>:

Example Code:
import re
re.findall(r"(?![a-z0-9])0(?![a-z0-9])", "a0a 0 0 b0b")

The above code returns an empty list. I expect to get ['0', '0'] returned.

If I remove "(?![a-z0-9])" from the beginning of the expression string 
findall returns values as expected.

----------
components: Regular Expressions
messages: 92046
nosy: jwindle
severity: normal
status: open
title: When Beginning Expression with Lookahead Assertion I get no Matches
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6797>
_______________________________________

From report at bugs.python.org  Sat Aug 29 00:36:55 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 28 Aug 2009 22:36:55 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1251499015.9.0.284917102833.issue4970@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Sorry about the late response; have been busy of late.

I believe this error ("Unknown signal 32") appears consistently in 
3.0.1, 3.1rc1, 3.1 and 3.1.1. It appears only on Linux x86. (64-bit has 
failures of different kind..)

I am attaching the entire log file.

I don't have much time to investigate into this relatively less-
important issue in detail, but if you need any further information .. 
please let me know. I will be happy to provide.

----------
Added file: http://bugs.python.org/file14797/apy3.1.1-linux-x86-apytest.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Sat Aug 29 00:37:51 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 28 Aug 2009 22:37:51 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1251499071.55.0.284357783354.issue4970@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

.. and here are the machine details:

apy at gila:~> uname -a
Linux gila 2.4.21-297-default #1 Sat Jul 23 07:47:39 UTC 2005 i686 i686 
i386 GNU/Linux
apy at gila:~> cat /etc/*release
LSB_VERSION="1.3"
DISTRIB_ID="SuSE"
DISTRIB_RELEASE="9.0"
DISTRIB_DESCRIPTION="SuSE Linux 9.0 (i586)"
SuSE Linux 9.0 (i586)
VERSION = 9.0
apy at gila:~>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Sat Aug 29 00:39:47 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 28 Aug 2009 22:39:47 +0000
Subject: [issue4970] test_os causes delayed failure on x86 gentoo buildbot:
	Unknown signal 32
In-Reply-To: <1232190585.86.0.270883273991.issue4970@psf.upfronthosting.co.za>
Message-ID: <1251499187.98.0.89609242417.issue4970@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

libc used is of version 2.3.2.

***

apy at gila:~> ldd rrun/tmp/autotest/ActivePython-3.1.1.2-linux-x86/
INSTALLDIR/bin/python3
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4002f000)
        libdl.so.2 => /lib/libdl.so.2 (0x40080000)
        libutil.so.1 => /lib/libutil.so.1 (0x40083000)
        libm.so.6 => /lib/i686/libm.so.6 (0x40086000)
        libc.so.6 => /lib/i686/libc.so.6 (0x400aa000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
apy at gila:~> /lib/i686/libc.so.6 
GNU C Library stable release version 2.3.2 (20030827), by Roland 
McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 3.3.1 (SuSE Linux).
Compiled on a Linux 2.6.0-test3 system on 2003-09-23.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.10 by Xavier Leroy
        NoVersion patch for broken glibc 2.0 binaries
        BIND-8.2.3-T5B
        libthread_db work sponsored by Alpha Processor Inc
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
pthread library is compiled with floating stack support enabled.
Report bugs using the `glibcbug' script to <bugs at gnu.org>.
apy at gila:~>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4970>
_______________________________________

From report at bugs.python.org  Sat Aug 29 01:52:05 2009
From: report at bugs.python.org (Robert Kern)
Date: Fri, 28 Aug 2009 23:52:05 +0000
Subject: [issue6798] Argument for sys.settrace() callbacks documented
	incorrectly
In-Reply-To: <1251503525.6.0.896923124912.issue6798@psf.upfronthosting.co.za>
Message-ID: <1251503525.6.0.896923124912.issue6798@psf.upfronthosting.co.za>


New submission from Robert Kern <robert.kern at gmail.com>:

The final 'arg' argument of the sys.settrace() callback is documented to
be None for the 'c_return' and 'c_exception' events, but it appears to
be the function object itself. Additionally, the 'return' event's
argument may be None if the 'return' event is being generated because of
an exception. These errors also exist in the Py_tracefunc documentation
in the C API. The latter error is not particularly important for the
Python API, but in the C API the argument may be a NULL pointer.

I am happy to make the corrections if someone will confirm that my
analysis is correct.

----------
assignee: georg.brandl
components: Documentation
messages: 92050
nosy: georg.brandl, robert.kern
severity: normal
status: open
title: Argument for sys.settrace() callbacks documented incorrectly
type: behavior
versions: Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6798>
_______________________________________

From report at bugs.python.org  Sat Aug 29 02:10:11 2009
From: report at bugs.python.org (Paul Tarjan)
Date: Sat, 29 Aug 2009 00:10:11 +0000
Subject: [issue6799] mimetypes does not give cannonical extension for
	guess_extension with text/plain
In-Reply-To: <1251504611.25.0.614751141151.issue6799@psf.upfronthosting.co.za>
Message-ID: <1251504611.25.0.614751141151.issue6799@psf.upfronthosting.co.za>


New submission from Paul Tarjan <python at paulisageek.com>:

>>> import mimetypes

>>> mimetypes.guess_extension("text/plain")
'.ksh'

most others are correct, it is just this one is quite wrong. I would
recommend changing it to .txt . 

>>> mimetypes.guess_all_extensions("text/plain")
['.ksh', '.pl', '.c', '.bat', '.h', '.txt', '.asc', '.text', '.pot', '.brf']

----------
components: Library (Lib)
messages: 92051
nosy: ptarjan
severity: normal
status: open
title: mimetypes does not give cannonical extension for guess_extension with text/plain
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6799>
_______________________________________

From report at bugs.python.org  Sat Aug 29 03:43:23 2009
From: report at bugs.python.org (Mark Lodato)
Date: Sat, 29 Aug 2009 01:43:23 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1251510203.17.0.589920548128.issue6247@psf.upfronthosting.co.za>


Mark Lodato <itsr0y at hotmail.com> added the comment:

I would also like to voice support for including argparse in the
standard library.  It seems silly to deny a module from being added just
because we already have two inferior ones.  Argparse adds so many new
(and badly needed!) features that it would be very difficult to make a
backwards-compatible wrapper around ArgumentParser.  It would be much
easier, and less error-prone, to leave optparse as-is and just add this
module in addition.

If the problem is having a third module clutter up the module list,
here's a simple solution: rename the existing optparse to _optparse,
rename argparse to optparse, and in (the new) optparse, from _optparse
import *.  Done.  Now you have a backwards-compatible OptionParser
(which ought to be deprecated), and the new ArgumentParser.  Would this
solution work?

----------
nosy: +marklodato

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Sat Aug 29 03:59:01 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Aug 2009 01:59:01 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1251511141.3.0.252864560979.issue6247@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

we should never pretend an old module doesn't exist.  leave optparse as
optparse.  argparse can come in under its own name.

we can mark getopt and optparse as deprecated at some point and remove
them in 10 years :)

+1 on inclusion btw.  It looks like it'll obsolete a bunch of crappy
argument parsing code that exists in some projects i work on but I
haven't had time to clean them up and switch.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Sat Aug 29 05:19:48 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Sat, 29 Aug 2009 03:19:48 +0000
Subject: [issue6800] os.exec* raises "OSError: [Errno 45] Operation not
	supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>


New submission from Reid Kleckner <rnk at mit.edu>:

The test case is attached.  On Mac OS X (and presumably FreeBSD, which
has the same behavior) when you try to exec from a process that has any
other threads in it, you get an OSError, "Operation not supported". 
Here's the output on my MacBook:

Traceback (most recent call last):
  File "daemon_exec.py", line 16, in <module>
    main()
  File "daemon_exec.py", line 13, in main
    os.execl('echo', 'hello world')
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.py",
line 312, in execl
    execv(file, args)
OSError: [Errno 45] Operation not supported

And on my Linux box:

hello world

Here's a similar bug that OCaml had to deal with:
http://caml.inria.fr/mantis/view.php?id=4666

I think it's reasonable for Python to declare this to be a limitation of
the OS, but considering that the other thread could be a daemon thread
that the user doesn't really care about, I think it would be reasonable
for Python to kill the other threads in the process before execing. 
That's what happens on Linux, anyway.

I ran into this problem while trying to add a persistent background
compilation thread to unladen swallow, and wondered if having any other
threads would trigger the same exception.

It's tempting to just write this off, but I figured it should be
documented or left open as a low priority defect.

----------
assignee: ronaldoussoren
components: Macintosh
files: daemon_exec.py
messages: 92054
nosy: rnk, ronaldoussoren
severity: normal
status: open
title: os.exec* raises "OSError: [Errno 45] Operation not supported" in a multithreaded application
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14798/daemon_exec.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6800>
_______________________________________

From report at bugs.python.org  Sat Aug 29 05:40:58 2009
From: report at bugs.python.org (trash80)
Date: Sat, 29 Aug 2009 03:40:58 +0000
Subject: [issue2204] document ConfigParser behaviour when a file has same
	section multiple times
In-Reply-To: <1204236720.35.0.634026900248.issue2204@psf.upfronthosting.co.za>
Message-ID: <1251517258.67.0.979304782705.issue2204@psf.upfronthosting.co.za>


trash80 <trash80 at trash80.org> added the comment:

I am using configparser after combining 3 or so ini files, I would like
to merge similar sections rather than throwing an exception.  Right now
I have to make sure the ini files all have unique sections, but I would
like to able to use same section names, then combine the files and have
the sections merged.  Even merging the variables within sections would
be nice.

Throwing an exception, imho, is no the right direction.  Even in same
name sections are in the same file, the variables where introduced for a
reason.

Or maybe a trigger option ie action=merge or action=flag.

----------
nosy: +trash80
versions: +Python 3.0 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2204>
_______________________________________

From report at bugs.python.org  Sat Aug 29 06:49:29 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Aug 2009 04:49:29 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1251521369.76.0.950031022683.issue6247@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm +1 on inclusion one way or another as well.  I haven't made time to
do anything other than a cursory code review, but as an end user I find
the module fits my needs much better than optparse.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Sat Aug 29 06:57:53 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 29 Aug 2009 04:57:53 +0000
Subject: [issue6800] os.exec* raises "OSError: [Errno 45] Operation not
	supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1251521873.74.0.136945203144.issue6800@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The issue with execv seems to be resolved on OSX 10.6, and hence the 
problem will go away by itself in the future.

But until OSX 10.5 and earlier have died of this is a valid issue.

My gut feeling is that I'm -1 on killing all threads in os.execv because 
it is unclear if that is a save thing to do (what if the system starts a 
number of threads in the background, killing one of them might crash your 
application before we get around to killing another one).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6800>
_______________________________________

From report at bugs.python.org  Sat Aug 29 07:13:34 2009
From: report at bugs.python.org (Reid Kleckner)
Date: Sat, 29 Aug 2009 05:13:34 +0000
Subject: [issue6800] os.exec* raises "OSError: [Errno 45] Operation not
	supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1251522814.24.0.573402765358.issue6800@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

Supposedly this bug also affects FreeBSD, but I can't verify it.  I'd
say the problem isn't going away, at least not for that platform, but I
don't feel like it's worth bending over backwards to deal with it either.

As far as it concerns unladen swallow, we'll bring down our background
thread by another means.  Unfortunately, there's no way to join
pythreads, so I have to add a hack that just retries the execv call if
errno == EOPNOTSUPP with an eventual timeout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6800>
_______________________________________

From report at bugs.python.org  Sat Aug 29 09:15:40 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Aug 2009 07:15:40 +0000
Subject: [issue6800] os.exec* raises "OSError: [Errno 45] Operation not
	supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1251530140.59.0.5685574922.issue6800@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

There is no OS level API to kill threads.  Python does not kill threads. 

When you exec, your entire process should be replaced by the OS, threads
shouldn't matter they should simply disappear just as the rest of your
process state does.

This is an OS problem.

Most macosx users will only ever use the python that apple feeds them so
I don't see what point working around this in Python would have given
that snow leopard (10.6) appears to fix this.

Feel free to contribute patches with appropriate autoconf magic and
ifdefs surrounding them if you feel otherwise.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6800>
_______________________________________

From report at bugs.python.org  Sat Aug 29 09:16:09 2009
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Aug 2009 07:16:09 +0000
Subject: [issue6800] os.exec* raises "OSError: [Errno 45] Operation not
	supported" in a multithreaded application
In-Reply-To: <1251515988.29.0.608870203555.issue6800@psf.upfronthosting.co.za>
Message-ID: <1251530169.84.0.183424383528.issue6800@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6800>
_______________________________________

From report at bugs.python.org  Sat Aug 29 09:31:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 29 Aug 2009 07:31:54 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251531114.13.0.262113822493.issue3143@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a new version. Now it works with all the major browsers and it's
more usable.

I tested it on the following browsers, and I didn't notice any problem/bug:
Firefox 2.0/3.0/3.5;
Internet Explorer 6/7/8;
Opera 9.64;
Chrome 2.0;
Konqueror 4.2.2;
Seamonkey 1.1;

I also tested it on a Nokia 5800, where the sidebar normally takes more
than half of the screen or about 1/3 if the phone is in landscape mode
(its screen resolution is 640x360, the sidebar is 230px).
With the built-in browser it works fine, but it's quite slow (8-9
seconds to collapse and a few more seconds to expand).
With Opera Mini it has some problem: when the sidebar is collapsed the
page is reloaded and the only way to expand it again is to use the
'back' button.

A few things could be improved:
  * Add some "effects" to the button on hover (to show that it is
clickable) and on click (to show that it was clicked);
  * Remember the position of the sidebar (collapsed/expanded) in all the
pages of the doc (using a cookie?);
  * Make it faster (although I think that most of the time is spent
rendering the page, so there's probably nothing to do).

----------
Added file: http://bugs.python.org/file14799/sidebar.js

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Sat Aug 29 09:32:34 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 29 Aug 2009 07:32:34 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251531154.67.0.905699813788.issue3143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file14794/sidebar.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Sat Aug 29 09:33:05 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 29 Aug 2009 07:33:05 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251531185.36.0.393163135781.issue3143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file14800/sidebar.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Sat Aug 29 09:44:48 2009
From: report at bugs.python.org (Alexander Stanley)
Date: Sat, 29 Aug 2009 07:44:48 +0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1251531888.45.0.287133698547.issue2057@psf.upfronthosting.co.za>


Changes by Alexander Stanley <lexi at swixel.net>:


----------
nosy: +swixel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
_______________________________________

From report at bugs.python.org  Sat Aug 29 13:22:15 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Aug 2009 11:22:15 +0000
Subject: [issue6750] threading issue in __builtins__.print
In-Reply-To: <1250839709.71.0.595068140402.issue6750@psf.upfronthosting.co.za>
Message-ID: <1251544935.25.0.570622644275.issue6750@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks ok to me.
It should be noted that TextIOWrapper was not designed to be thread-safe
at all (neither the Python nor the C version); but admittedly it is more
common to write() than to read() from multiple threads, so fixing this
particular case makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6750>
_______________________________________

From report at bugs.python.org  Sat Aug 29 13:34:32 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Aug 2009 11:34:32 +0000
Subject: [issue6799] mimetypes does not give cannonical extension for
	guess_extension with text/plain
In-Reply-To: <1251504611.25.0.614751141151.issue6799@psf.upfronthosting.co.za>
Message-ID: <1251545672.26.0.625835904945.issue6799@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is quite a reasonable request indeed.

----------
nosy: +pitrou
priority:  -> normal
stage:  -> needs patch
versions:  -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6799>
_______________________________________

From report at bugs.python.org  Sat Aug 29 14:15:39 2009
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 29 Aug 2009 12:15:39 +0000
Subject: [issue6797] When Beginning Expression with Lookahead Assertion I get
	no Matches
In-Reply-To: <1251496198.81.0.453692564995.issue6797@psf.upfronthosting.co.za>
Message-ID: <1251548139.16.0.592318649627.issue6797@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

"(?![a-z0-9])" is a negative lookahead, so "(?![a-z0-9])0" is saying
that the next character shouldn't be any of [a-z0-9], yet it should
match "0". Hence, no matches.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6797>
_______________________________________

From report at bugs.python.org  Sat Aug 29 15:07:36 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Aug 2009 13:07:36 +0000
Subject: [issue6797] When Beginning Expression with Lookahead Assertion I get
	no Matches
In-Reply-To: <1251496198.81.0.453692564995.issue6797@psf.upfronthosting.co.za>
Message-ID: <1251551256.39.0.205353885183.issue6797@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, MRAB!  Closing as invalid.

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6797>
_______________________________________

From report at bugs.python.org  Sat Aug 29 15:31:03 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 29 Aug 2009 13:31:03 +0000
Subject: [issue6801] symmetric_difference_update documentation fix
In-Reply-To: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>
Message-ID: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

the symmetric_difference_update also accepts |

----------
assignee: tarek
components: Documentation
messages: 92065
nosy: tarek
severity: normal
status: open
title: symmetric_difference_update documentation fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6801>
_______________________________________

From report at bugs.python.org  Sat Aug 29 20:55:12 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Aug 2009 18:55:12 +0000
Subject: [issue6713] Integer & Long types: Performance improvement of 1.6x to
	2x for base 10 conversions
In-Reply-To: <1250444749.02.0.599405992694.issue6713@psf.upfronthosting.co.za>
Message-ID: <1251572112.58.0.191053019614.issue6713@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6713>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:20:32 2009
From: report at bugs.python.org (Mattias Stahre)
Date: Sat, 29 Aug 2009 20:20:32 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1251577232.64.0.102956217486.issue6245@psf.upfronthosting.co.za>


Mattias Stahre <mattias.stahre at gmail.com> added the comment:

Is there any progress on this?

----------
nosy: +plux
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:30:58 2009
From: report at bugs.python.org (Joshua Root)
Date: Sat, 29 Aug 2009 20:30:58 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>


New submission from Joshua Root <josh+python at root.id.au>:

Building Python 2.6.2 on Mac OS X 10.6 (final version, 10A432) fails. Full 
build transcript is attached.

Other system details: Xcode 3.2, hardware is MacPro1,1

----------
assignee: ronaldoussoren
components: Build, Macintosh
files: py26-snowleopard.log
messages: 92067
nosy: jmr, ronaldoussoren
severity: normal
status: open
title: build fails on Snow Leopard
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14801/py26-snowleopard.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:32:05 2009
From: report at bugs.python.org (mike bayer)
Date: Sat, 29 Aug 2009 20:32:05 +0000
Subject: [issue6245] Add "intel" universal architecture on OSX
In-Reply-To: <1244496939.41.0.183119086713.issue6245@psf.upfronthosting.co.za>
Message-ID: <1251577925.23.0.0345288928408.issue6245@psf.upfronthosting.co.za>


Changes by mike bayer <mike_mp at zzzcomputing.com>:


----------
nosy: +zzzeek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6245>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:44:00 2009
From: report at bugs.python.org (Dan Haffey)
Date: Sat, 29 Aug 2009 20:44:00 +0000
Subject: [issue6803] Context manager docs refer to contextlib.contextmanager
	as contextlib.contextfactory
In-Reply-To: <1251578640.37.0.48672021847.issue6803@psf.upfronthosting.co.za>
Message-ID: <1251578640.37.0.48672021847.issue6803@psf.upfronthosting.co.za>


New submission from Dan Haffey <dhaffey at gmail.com>:

The documentation at
http://docs.python.org/library/stdtypes.html#context-manager-types
refers to the contextlib.contextmanager decorator as
contextlib.contextfactory.

----------
assignee: georg.brandl
components: Documentation
files: doc-stdtypes-contextmanagement.patch
keywords: patch
messages: 92068
nosy: dhaffey, georg.brandl
severity: normal
status: open
title: Context manager docs refer to contextlib.contextmanager as contextlib.contextfactory
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14802/doc-stdtypes-contextmanagement.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6803>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:46:36 2009
From: report at bugs.python.org (Bryan Blackburn)
Date: Sat, 29 Aug 2009 20:46:36 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251578796.94.0.917168684978.issue6802@psf.upfronthosting.co.za>


Changes by Bryan Blackburn <blb at users.sourceforge.net>:


----------
nosy: +blb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sat Aug 29 22:46:44 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Aug 2009 20:46:44 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1251578804.36.0.535744071928.issue1023290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The patch looks great!  Some comments:

- I think the type check for length_obj in long_tobytes should be more 
lenient:  I'd suggest a PyIndex_Check and PyNumber_AsSsize_t conversion 
instead of the PyLong_Check.  Or just use 'n' instead of 'O' in the 
PyArg_Parse* format;  this uses PyNumber_Index + PyLong_AsSsize_t, which 
amounts to the same thing (or at least I *think* it does).

- I like the pickle changes, but I think they should be committed 
separately.  (Unless they're somehow required for the rest of the patch 
to function correctly?)

- Stylistic nit:  There's some inconsistency in the NULL checks in the 
patch: "if (args != NULL)" versus "if (is_signed_obj)".  PEP 7 doesn't 
say anything about this, but the prevailing style in this file is for an 
explicit '== NULL' or '!= NULL'.

- I'm getting one failing test:

test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_long.py", line 1285, in test_frombytes
    self.assertRaises(TypeError, int.frombytes, "", 'big')
AssertionError: TypeError not raised by frombytes

This obviously has to do with issue 6687; as mentioned in that issue, 
I'm not sure that this should be an error.  How about just removing this 
test for now, pending a decision on that issue?

- Nice docs (and docstrings)!

On the subject of backporting to 2.7, I haven't seen any objections, so 
I'd say we should go for it.  (One argument for not backporting new 
features is to provide incentive for people to upgrade, but I can't 
realistically see this addition as a significant 'carrot'.)  I'm happy 
to do the backport, and equally happy to leave it to Alexandre if he's 
interested.

Leaving the bikeshedding until last:

Method names: I'm +0 on adding the extra underscore.  Python's already a 
bit inconsistent (e.g., float.fromhex and float.hex).  Also, at the time 
the float.fromhex and float.hex names were being discussed, 'hex' seemed 
to be preferred over 'tohex';  I wonder whether we should have int.bytes 
instead of int.to_bytes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Sat Aug 29 23:01:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Aug 2009 21:01:06 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251579666.16.0.715475132431.issue6802@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +marketdickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sat Aug 29 23:07:40 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 29 Aug 2009 21:07:40 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251580060.86.0.299574731404.issue6802@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This also applies to trunk, py3k and release31-maint.

----------
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sat Aug 29 23:44:40 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 29 Aug 2009 21:44:40 +0000
Subject: [issue6804] IDLE: Detect Python files even if name doesn't end in .py
In-Reply-To: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>
Message-ID: <1251582280.35.0.0143459273436.issue6804@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

A Python source file name doesn't necesarily end 
in .py/.pyw; on Linux, scripts usually have no 
extension but are recognized by its shebang line. 
Windows uses file type associations: .py files are of 
type Python.File, and .pyc files are Python.NoConFile.

This patch makes IDLE recognize as a Python source 
(and colorize) any file of those types, regardless of 
extension.

http://permalink.gmane.org/
gmane.comp.python.general/636011

----------
components: IDLE
files: EditorWindow.diff
keywords: patch
messages: 92071
nosy: gagenellina
severity: normal
status: open
title: IDLE: Detect Python files even if name doesn't end in .py
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14803/EditorWindow.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6804>
_______________________________________

From report at bugs.python.org  Sat Aug 29 23:56:09 2009
From: report at bugs.python.org (Eric Smith)
Date: Sat, 29 Aug 2009 21:56:09 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251582969.95.0.935842978353.issue6802@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 00:04:38 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Sat, 29 Aug 2009 22:04:38 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1251583478.72.0.685430439679.issue6784@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

Note that this is also a documentation issue: "The pickle 
serialization format is guaranteed to be backwards compatible across 
Python releases."

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +gagenellina, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sun Aug 30 01:23:33 2009
From: report at bugs.python.org (Erik S. LaBianca)
Date: Sat, 29 Aug 2009 23:23:33 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251588213.17.0.632761659414.issue6802@psf.upfronthosting.co.za>


Changes by Erik S. LaBianca <erik.labianca at gmail.com>:


----------
nosy: +easel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 01:26:09 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 29 Aug 2009 23:26:09 +0000
Subject: [issue6750] threading issue in __builtins__.print
In-Reply-To: <1250839709.71.0.595068140402.issue6750@psf.upfronthosting.co.za>
Message-ID: <1251588369.98.0.446298024473.issue6750@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

fixed with r74581, r74582 and r74583 (in: trunk, py3k and release31-maint)

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6750>
_______________________________________

From report at bugs.python.org  Sun Aug 30 03:10:03 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Aug 2009 01:10:03 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251594603.44.0.537605375277.issue6802@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 03:41:15 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Aug 2009 01:41:15 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251596475.6.0.142917612816.issue6802@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

For those trying to debug this, to silence the math.h warnings, set 
MACOSX_DEPLOYMENT_TARGET to 10.6 or something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 03:45:13 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 30 Aug 2009 01:45:13 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251596713.17.0.0799859940303.issue6802@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

3k and trunk compile fine for me. Clean snow leopard install. My first 
suggestion is nuking macports.

----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 04:20:23 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 30 Aug 2009 02:20:23 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251598823.47.0.369375562698.issue6802@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

2.6.2 maint compiles fine too - again, with a clean install of Snow 
Leopard, no macports.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 04:33:42 2009
From: report at bugs.python.org (Joshua Root)
Date: Sun, 30 Aug 2009 02:33:42 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251599622.8.0.646150490207.issue6802@psf.upfronthosting.co.za>


Joshua Root <josh+python at root.id.au> added the comment:

Note that this problem appears to be x86_64-specific (caused by "-
arch_only i386"), and only happens if you configure with --enable-
framework.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 04:35:19 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 30 Aug 2009 02:35:19 +0000
Subject: [issue6805] Should be URL for documentation of current release of
	Python 3 (without version)
In-Reply-To: <1251599719.58.0.439749940017.issue6805@psf.upfronthosting.co.za>
Message-ID: <1251599719.58.0.439749940017.issue6805@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

There should be a standard URL on the web site to reach the
documentation of the current stable release of Python 3.

http://docs.python.org leads to the documentation for Python 2.
I can get to Python 3.1 documentation, but I have to specify 3.1 in the
URL: http://docs.python.org/3.1
That means that I cannot publish material on the web or in hardcopy that
refers generically to the documentation of a particular module via URL
without specifying a version, and that version will be obsolete before
long. I don't know what the URL should be -- perhaps docs.python.org/3/
would be sufficient.

This is one level up from the current arrangement in which specifying
3.1 actually currently gives me the 3.1.1 documentation.

----------
assignee: georg.brandl
components: Documentation
messages: 92078
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Should be URL for documentation of current release of Python 3 (without version)
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6805>
_______________________________________

From report at bugs.python.org  Sun Aug 30 04:58:54 2009
From: report at bugs.python.org (dmw)
Date: Sun, 30 Aug 2009 02:58:54 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251601134.27.0.774935750022.issue6802@psf.upfronthosting.co.za>


Changes by dmw <david at humblehacker.com>:


----------
nosy: +dmw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 06:35:14 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Aug 2009 04:35:14 +0000
Subject: [issue6806] test_platform fails under Snow Leopard
In-Reply-To: <1251606907.25.0.605162883353.issue6806@psf.upfronthosting.co.za>
Message-ID: <1251606907.25.0.605162883353.issue6806@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

test.platform fails under Snow Leopard because the golden input for the OS 
version, sw_vers, reports Snow Leopard as '10.6' while 
platform.mac_ver()[0] (which uses gestalt.gestalt()) return '10.6.0'.

Best solution might be to tweak the test to append a '0' when sw_vers 
returns a value that is short a micro version.

----------
components: Library (Lib)
keywords: easy
messages: 92079
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_platform fails under Snow Leopard
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6806>
_______________________________________

From report at bugs.python.org  Sun Aug 30 06:37:23 2009
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 30 Aug 2009 04:37:23 +0000
Subject: [issue6563] inserting None into sys.modules does not raise
	ImportError with importlib
In-Reply-To: <1248459115.79.0.0648644877351.issue6563@psf.upfronthosting.co.za>
Message-ID: <1251607043.02.0.00197320025404.issue6563@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed in py3k with r74584 & 3.1 w/ r74586.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6563>
_______________________________________

From report at bugs.python.org  Sun Aug 30 07:40:25 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Aug 2009 05:40:25 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251610825.03.0.65181911467.issue3143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file14800/sidebar.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Sun Aug 30 07:42:55 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Aug 2009 05:42:55 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251610975.47.0.243432081382.issue3143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file14793/sidebar-old.js

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Sun Aug 30 07:43:00 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Aug 2009 05:43:00 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251610980.05.0.294905209958.issue3143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file14799/sidebar.js

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Sun Aug 30 07:57:51 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Aug 2009 05:57:51 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251611871.01.0.00136678894904.issue3143@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This should be the final version, these are the things I improved:
  * added a per-browser/per-session cookie to save the position of the
sidebar during a single session. When the browser is closed the position
is reset and the cookie deleted;
  * added an effect on hover and a better vertical centering of the '<<'
/ '>>';
  * fixed some bugs.

I also tried to make it faster (with no appreciable results).

I tested it on the aforementioned browsers and it seems to work fine, so
if there are no comments on the code or on the final result, the script
is ready to go in.

----------
Added file: http://bugs.python.org/file14804/sidebar.js

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Sun Aug 30 07:59:34 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 30 Aug 2009 05:59:34 +0000
Subject: [issue3143] Make the left sidebar in the doc collapsible
In-Reply-To: <1213894130.5.0.901866798504.issue3143@psf.upfronthosting.co.za>
Message-ID: <1251611974.76.0.947956598471.issue3143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file14805/sidebar.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3143>
_______________________________________

From report at bugs.python.org  Sun Aug 30 08:48:48 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 30 Aug 2009 06:48:48 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251614928.65.0.284113926166.issue6802@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

As Jeese points out, there are suspicious signs of MacPorts in the log: 
"/opt/local/bin/ginstall -c -d -m 755 Python.framework/Versions/2.6"

Try removing all /opt/local entries from your $PATH and try again with
  export MACOSX_DEPLOYMENT_TARGET=10.6

----------
nosy: +nad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 08:50:49 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 30 Aug 2009 06:50:49 +0000
Subject: [issue6806] test_platform fails under Snow Leopard
In-Reply-To: <1251606907.25.0.605162883353.issue6806@psf.upfronthosting.co.za>
Message-ID: <1251615049.83.0.167852138718.issue6806@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6806>
_______________________________________

From report at bugs.python.org  Sun Aug 30 09:28:16 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 30 Aug 2009 07:28:16 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251614928.65.0.284113926166.issue6802@psf.upfronthosting.co.za>
Message-ID: <A5621C7C-DAFE-4D34-A221-B54A2DDBB621@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The default value for the -arch flag changed in SL. It used to be the  
same as the output of the arch command (i386 on intel systems) and now  
is x86-64.

I'll create a patch for configure to automaticly detect the right value.

As a workaround you can build a universal build (--enable- 
universalsdk=/)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 10:33:52 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Aug 2009 08:33:52 +0000
Subject: [issue6805] Should be URL for documentation of current release of
	Python 3 (without version)
In-Reply-To: <1251599719.58.0.439749940017.issue6805@psf.upfronthosting.co.za>
Message-ID: <1251621232.17.0.0504971195325.issue6805@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The "current" 3k docs are at docs.python.org/py3k.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6805>
_______________________________________

From report at bugs.python.org  Sun Aug 30 10:35:08 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Aug 2009 08:35:08 +0000
Subject: [issue6803] Context manager docs refer to contextlib.contextmanager
	as contextlib.contextfactory
In-Reply-To: <1251578640.37.0.48672021847.issue6803@psf.upfronthosting.co.za>
Message-ID: <1251621308.16.0.388228988421.issue6803@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r74588.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6803>
_______________________________________

From report at bugs.python.org  Sun Aug 30 12:59:16 2009
From: report at bugs.python.org (pds)
Date: Sun, 30 Aug 2009 10:59:16 +0000
Subject: [issue6807] No such file or directory: 'msisupport.dll' in msi.py
In-Reply-To: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>
Message-ID: <1251629956.22.0.252677555531.issue6807@psf.upfronthosting.co.za>


New submission from pds <pirdirsir at gmail.com>:

Investigating the issue #6716 I reported earlier, I've been trying to
build Windows MSI installer package of Python 3.1 on my own.
I checked out the svn source, built things with Visual C++ 2008 Express
Edition, and tried to make MSI package in Tools\msi directory.
When I run Tools\msi\msi.py in Tools\msi directory, the following error
occurs:

Traceback (most recent call last):
  File "msi.py", line 178, in <module>
    if msilib.pe_type(dll_path) != msilib.pe_type("msisupport.dll"):
  File "E:\python31svnbuild\Tools\msi\msilib.py", line 665, in pe_type
    header = open(path, "rb").read(1000)
IOError: [Errno 2] No such file or directory: 'msisupport.dll'

It seems that msilib.pe_type("msisupport.dll") is called before
msisupport.dll is created.
I read msi.py and learned that msilib.pe_type("msisupport.dll") (line
178) is executed before os.system("nmake /nologo /c /f msisupport.mak")
(line 372) is executed in add_ui(), which is called at line 1299.
So I made a patch to make msi.py to see if the file "msisupport.dll"
exists, and if it does, check if the dll is for the correct architecture.

----------
components: Installation
files: patch.txt
messages: 92086
nosy: pds
severity: normal
status: open
title: No such file or directory: 'msisupport.dll' in msi.py
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14806/patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6807>
_______________________________________

From report at bugs.python.org  Sun Aug 30 13:52:02 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Aug 2009 11:52:02 +0000
Subject: [issue6801] symmetric_difference_update documentation fix
In-Reply-To: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>
Message-ID: <1251633122.17.0.311820137524.issue6801@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r74590.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6801>
_______________________________________

From report at bugs.python.org  Sun Aug 30 16:25:57 2009
From: report at bugs.python.org (Joshua Root)
Date: Sun, 30 Aug 2009 14:25:57 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251642357.82.0.707223178729.issue6802@psf.upfronthosting.co.za>


Joshua Root <josh+python at root.id.au> added the comment:

Noting for completeness that:
 * 3.0.1 behaves the same as 3.1.1 (works without --enable-framework).
 * 2.5.4 fails with 'cc1: error: unrecognized command line option "-Wno-
long-double"'. Once this is removed from the configure script, it then 
fails in mactoolboxglue.c due to missing Carbon functions, whether or 
not it was configured with --enable-framework. Using --disable-toolbox-
glue and not using --enable-framework allows the build to succeed. Using 
--disable-toolbox-glue and --enable-framework causes a failure involving 
struct rusage in posixmodule.c. Adding "#define _DARWIN_C_SOURCE" to 
pyconfig.h fixes this, but then there's the same "file is not of 
required architecture" failure seen in later versions.
 * 2.4.6 behaves the same as 2.5.4 apart from not needing the 
_DARWIN_C_SOURCE addition.
 * None of the failures are affected by /opt/local/bin's presence or 
absence in my PATH.

----------
versions: +Python 2.4, Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 16:45:50 2009
From: report at bugs.python.org (R. David Murray)
Date: Sun, 30 Aug 2009 14:45:50 +0000
Subject: [issue6801] symmetric_difference_update documentation fix
In-Reply-To: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>
Message-ID: <1251643550.6.0.7623064455.issue6801@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, so in r74578 Tarek added the pipe but didn't update this case, and
in r74590 Georg deleted the pipe that Tarek added...

----------
nosy: +r.david.murray
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6801>
_______________________________________

From report at bugs.python.org  Sun Aug 30 16:54:43 2009
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 30 Aug 2009 14:54:43 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251644083.12.0.680590249919.issue6802@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I'll note I am not doing framework builds, however people have run into 
problems with non framework builds and macports/old versions of gettext.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 17:40:58 2009
From: report at bugs.python.org (Tom Morse)
Date: Sun, 30 Aug 2009 15:40:58 +0000
Subject: [issue6808] python 3.1 documentation tutorial classes
In-Reply-To: <1251646858.69.0.964592229296.issue6808@psf.upfronthosting.co.za>
Message-ID: <1251646858.69.0.964592229296.issue6808@psf.upfronthosting.co.za>


New submission from Tom Morse <thomas.morse at snet.net>:

Thank you for the most excellent documentation and notes on classes in
python:
http://docs.python.org/3.1/tutorial/classes.html

I found the following minor typos and provide feedback on the above web
page:

1. Where "unpacked again" occurs there is no reference to any first
unpacking so that was confusing to me.  I had the impression that if
"again" was omitted it was vaguely understandable.

2. Typo: where "of instances of c" occurs, "of c" should be "of C"

----------
assignee: georg.brandl
components: Documentation
messages: 92091
nosy: georg.brandl, tom_morse
severity: normal
status: open
title: python 3.1 documentation tutorial classes
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6808>
_______________________________________

From report at bugs.python.org  Sun Aug 30 19:48:55 2009
From: report at bugs.python.org (Mitchell Hashimoto)
Date: Sun, 30 Aug 2009 17:48:55 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251654535.23.0.217898290505.issue6802@psf.upfronthosting.co.za>


Changes by Mitchell Hashimoto <xmitchx at gmail.com>:


----------
nosy: +mitchellh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 20:15:59 2009
From: report at bugs.python.org (Preston Kutzner)
Date: Sun, 30 Aug 2009 18:15:59 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251656159.23.0.201553174166.issue6802@psf.upfronthosting.co.za>


Changes by Preston Kutzner <pkutzner+python at gmail.com>:


----------
nosy: +grdnwsl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 21:43:27 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 30 Aug 2009 19:43:27 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251661407.5.0.880355426216.issue6802@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch (configure-in-sl.patch) fixes the build issue on SL,
I haven't committed the patch yet because it needs testing on 10.5/10.4.

NOTE: the patch touches configure.in without also patching configure. 
Therefore you need to run 'autoconf' after applying the patch.

NOTE2: the patch is for the trunk (2.7), I'll port the patch to the other 
branches (2.6, 3.2 and 3.1) after testing it on 10.5.

----------
keywords: +patch
resolution:  -> accepted
Added file: http://bugs.python.org/file14807/configure-in-sl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Sun Aug 30 23:04:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 30 Aug 2009 21:04:47 +0000
Subject: [issue6801] symmetric_difference_update documentation fix
In-Reply-To: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>
Message-ID: <1251666287.14.0.877771519368.issue6801@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Oops, that was a bit uncoordinated :)

I saw the new bug report in my inbox, and decided to look at what might
be wrong despite the somewhat meager description, and already saw the
"fixed" version and fixed it again.

Anyway. I think the unfixed, and now reverted, version is the better
one, first because the description talks about "either" and "both"
implying only two sets participating, and second because the method form
also supports only one argument, indicating that the case of multiple
sets or'ed together as the second operand of ^ is not a common one.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6801>
_______________________________________

From report at bugs.python.org  Mon Aug 31 00:30:45 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 30 Aug 2009 22:30:45 +0000
Subject: [issue6801] symmetric_difference_update documentation fix
In-Reply-To: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>
Message-ID: <1251671445.28.0.690691935424.issue6801@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Well, in that case I don't understand how it is different from
difference_update() ?

The doc says : 

set -= other | ...

suggesting that you can pipe several sets with -=,
exactly like what you can do with ^=.

The same applies with |=.

In other words, this whole section is unclear in 
what "other" is, and why we have "others" sometimes.
(eg a set or a several sets piped together for example)

----------
assignee: tarek -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6801>
_______________________________________

From report at bugs.python.org  Mon Aug 31 02:37:12 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Aug 2009 00:37:12 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1251679032.24.0.484990647778.issue6526@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Turns out the failure is because I have simply been opening bytecode 
files for writing using _io.FileIO(..., 'w') which just uses the OS's 
default permissions. Guess that won't cut it anymore. =)

So does this mean I am expected to chmod the bytecode file to have 
matching read and write bits to the source but no execution bits 
regardless of the source file? And what about writing new bytecode 
files? I am not about to ignore permissions and simply write over files 
just because I can as someone could have set them independently of 
Python to be read-only.

Let me know that I am doing the right thing, David.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Mon Aug 31 03:12:25 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Aug 2009 01:12:25 +0000
Subject: [issue6526] importlib.import_module affects permissions of .pyc files
	subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1251681145.85.0.561744572721.issue6526@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the problem with asking me what the right thing to do is that I
think the old behavior of just using the default os umask makes the most
sense.  I think we should figure out who made the original change in
behavior and ask them what the right thing is to do and why.  I'll see
if I can dig up the 'who' tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________

From report at bugs.python.org  Mon Aug 31 07:32:25 2009
From: report at bugs.python.org (Daniel Black)
Date: Mon, 31 Aug 2009 05:32:25 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1251696745.98.0.214959739945.issue5639@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

patch against TRUNK (2.7) with self tests and doco. Essentially the same
code as pdp with a SSLv2 check before using the SNI extension.

Contains some spacing cleanups that where highlighted by vim.

----------
nosy: +grooverdan
Added file: http://bugs.python.org/file14808/python-HEAD-74602-ssl_client_sni.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Mon Aug 31 07:33:11 2009
From: report at bugs.python.org (Daniel Black)
Date: Mon, 31 Aug 2009 05:33:11 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1251696791.7.0.165905193493.issue5639@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

py3k version

----------
Added file: http://bugs.python.org/file14809/python-3K-74602-ssl_client_sni.path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Mon Aug 31 07:33:32 2009
From: report at bugs.python.org (Daniel Black)
Date: Mon, 31 Aug 2009 05:33:32 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1251696812.52.0.0697228929423.issue5639@psf.upfronthosting.co.za>


Changes by Daniel Black <daniel at cacert.org>:


----------
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Mon Aug 31 07:43:53 2009
From: report at bugs.python.org (Daniel Black)
Date: Mon, 31 Aug 2009 05:43:53 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1251697433.33.0.187217043681.issue5639@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

current self tests cannot fully test the existence of the SNI extension
as there is no server side support.

This client script run with argument sni.velox.ch will show the "Great!
Your client ....its ClientHello: sni.velox.ch" on the output.

----------
nosy: +janssen
type:  -> feature request
Added file: http://bugs.python.org/file14810/pytest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Mon Aug 31 08:04:14 2009
From: report at bugs.python.org (Daniel Black)
Date: Mon, 31 Aug 2009 06:04:14 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1251698654.46.0.450709750915.issue5639@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

The small deficiency with these patches is that the specified
server_hostname is almost always the hostname that is used in the socket
pair of connect. Is it appropriate to grab the hostname value and use it
in the SNI extension header?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Mon Aug 31 08:33:37 2009
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 31 Aug 2009 06:33:37 +0000
Subject: [issue6788] codecs.open on Win32 does not force binary mode
In-Reply-To: <1251346629.44.0.734409123127.issue6788@psf.upfronthosting.co.za>
Message-ID: <1251700417.5.0.122334252694.issue6788@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think your test is invalid: it creates the file in "w" mode, so \n are 
written as two bytes \r\n on the disk.
codecs.open just reads them back.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6788>
_______________________________________

From report at bugs.python.org  Mon Aug 31 08:38:48 2009
From: report at bugs.python.org (Andrew Liu)
Date: Mon, 31 Aug 2009 06:38:48 +0000
Subject: [issue6809] Python string.lstrip bug?
In-Reply-To: <1251700728.18.0.0769627143448.issue6809@psf.upfronthosting.co.za>
Message-ID: <1251700728.18.0.0769627143448.issue6809@psf.upfronthosting.co.za>


New submission from Andrew Liu <mushywushy at gmail.com>:

A simple lstrip on the following causes an extra character to be
stripped, as per the below. Tried on 2.6.1 and on 2.4.3, as below.

Python 2.6.1 (r261:67515, Feb 27 2009, 02:54:13)
[GCC 4.3.2 20081105 (Red Hat 4.3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "contact_work_phone_no"
>>> a.lstrip("contact")
'_work_phone_no'
>>> a.lstrip("contact_")
'work_phone_no'
>>> a = "contact_city"
>>> a.lstrip("contact_")
'ity'
>>> a.lstrip("con")
'tact_city'
>>> a.lstrip("contact")
'_city'
>>> a.lstrip("contact_")
'ity'
>>>


Python 2.4.3 (#1, Mar 14 2007, 19:01:42)
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "contact_city"
>>> a.lstrip("contact_")
'ity'
>>>

----------
components: Build
messages: 92102
nosy: mushywushy
severity: normal
status: open
title: Python string.lstrip bug?
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6809>
_______________________________________

From report at bugs.python.org  Mon Aug 31 08:40:42 2009
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 31 Aug 2009 06:40:42 +0000
Subject: [issue6801] symmetric_difference_update documentation fix
In-Reply-To: <1251552662.92.0.431748034273.issue6801@psf.upfronthosting.co.za>
Message-ID: <1251700842.07.0.0229939704561.issue6801@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> Well, in that case I don't understand how it is different from
> difference_update() ?

It's different from difference_update because that takes multiple
arguments. The operator form shows an equivalent and therefore shows how
to write an equivalent of the method with multiple arguments.

> suggesting that you can pipe several sets with -=,
> exactly like what you can do with ^=.

Of course you can put multiple or'ed sets on the right of ^=, but then
you can put every expression there.

> In other words, this whole section is unclear in 
> what "other" is, and why we have "others" sometimes.
< (eg a set or a several sets piped together for example)

I've fixed two other descriptions in r74603, it should be consistent now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6801>
_______________________________________

From report at bugs.python.org  Mon Aug 31 08:58:20 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 31 Aug 2009 06:58:20 +0000
Subject: [issue6809] Python string.lstrip bug?
In-Reply-To: <1251700728.18.0.0769627143448.issue6809@psf.upfronthosting.co.za>
Message-ID: <1251701900.85.0.744271429699.issue6809@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is not a bug:  the argument to lstrip effectively specifies a set 
of characters to be removed;  in your example, 'c' is in that set, so 
the 'c' at the beginning of city gets removed.  'i' is not in that set, 
so it stays. 

lstrip(...)
    S.lstrip([chars]) -> string or unicode
    
    Return a copy of the string S with leading whitespace removed.
    If chars is given and not None, remove characters in chars instead.

----------
nosy: +marketdickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6809>
_______________________________________

From report at bugs.python.org  Mon Aug 31 09:26:05 2009
From: report at bugs.python.org (Daniel Black)
Date: Mon, 31 Aug 2009 07:26:05 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1251703565.58.0.268215248058.issue2973@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

The changeset that changed the definitions is here:
http://cvs.openssl.org/chngview?cn=12024 (2004-Mar-14 23:15:13 (UTC))

As you can see there is no easy identifier in the changeset (i'm not
sure how portable an ifdef on a typedef is (possible
asn1_const_ctx_st/ASN1_const_CTX)).

The patch i've done goes of then next OPENSSL_VERSION_NUMBER change
which occurred here
http://cvs.openssl.org/filediff?f=openssl/crypto/opensslv.h&v1=1.36.2.35&v2=1.36.2.36
(2004/03/17 11:40:44) ~3 days later.

Same patch applies to p3k

----------
keywords: +patch
nosy: +grooverdan
versions: +Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14811/issue2973-D2I_PARAMETER_2_TYPE.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2973>
_______________________________________

From report at bugs.python.org  Mon Aug 31 09:32:06 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Mon, 31 Aug 2009 07:32:06 +0000
Subject: [issue6810] add link to the documentation of signal.signal
In-Reply-To: <1251703923.28.0.662509969708.issue6810@psf.upfronthosting.co.za>
Message-ID: <1251703923.28.0.662509969708.issue6810@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:

in http://docs.python.org/library/signal.html#signal.signal the reader
is referred to "see the reference manual section on the standard type
hierarchy". It would be generous if we will supply a link like
"http://docs.python.org/reference/datamodel.html"

BTW: it would be even more generous if the page
http://docs.python.org/reference/datamodel.html will include anchors to
specific paragraphs/items, so we could even refer to 
http://docs.python.org/reference/datamodel.html#frame, for example (the
#frame anchor doesn't exist now)

Thanks in advance !

----------
assignee: georg.brandl
components: Documentation
messages: 92106
nosy: Yinon, georg.brandl
severity: normal
status: open
title: add link to the documentation of signal.signal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6810>
_______________________________________

From report at bugs.python.org  Mon Aug 31 09:39:20 2009
From: report at bugs.python.org (Daniel Black)
Date: Mon, 31 Aug 2009 07:39:20 +0000
Subject: [issue3212] ssl module - should test for a wrong cert
In-Reply-To: <1214505254.08.0.113211233471.issue3212@psf.upfronthosting.co.za>
Message-ID: <1251704360.62.0.209119767669.issue3212@psf.upfronthosting.co.za>


Daniel Black <daniel at cacert.org> added the comment:

Is fixed in p3k Mon Sep 8 16:45:19 2008 UTC
http://svn.python.org/view/python/branches/py3k/Lib/test/test_ssl.py?r1=65837&r2=66311

----------
nosy: +grooverdan
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3212>
_______________________________________

From report at bugs.python.org  Mon Aug 31 16:30:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 31 Aug 2009 14:30:58 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251729058.27.0.090500768542.issue6802@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The patch works for me.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Mon Aug 31 16:54:30 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 31 Aug 2009 14:54:30 +0000
Subject: [issue6297] Added Misc/python.pc to 'distclean' Rule
In-Reply-To: <1245266060.76.0.919616953037.issue6297@psf.upfronthosting.co.za>
Message-ID: <1251730470.18.0.51456440185.issue6297@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch.

Applied in r74604 (trunk), r74605 (py3k), r74606 (release31-maint).

----------
assignee: georg.brandl -> marketdickinson
components: +Build -Documentation
nosy: +marketdickinson
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6297>
_______________________________________

From report at bugs.python.org  Mon Aug 31 18:45:46 2009
From: report at bugs.python.org (Senthil)
Date: Mon, 31 Aug 2009 16:45:46 +0000
Subject: [issue2637] urllib.quote() escapes characters unnecessarily and
	contrary to docs
In-Reply-To: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>
Message-ID: <1251737146.02.0.214393399128.issue2637@psf.upfronthosting.co.za>


Senthil <orsenthil at gmail.com> added the comment:

Fixed and 
Committed revision 74608 - trunk
Committed revision 74609 - py3k

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2637>
_______________________________________

From report at bugs.python.org  Mon Aug 31 19:31:11 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 31 Aug 2009 17:31:11 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251739871.92.0.172596147543.issue6802@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With the patch installed, no regressions were seen running my standard set 
of OSX installer builds/installs/regtests on 10.4 and 10.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Mon Aug 31 20:58:53 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Aug 2009 18:58:53 +0000
Subject: [issue6811] add a filename argument to marshal.load*
In-Reply-To: <1251745133.13.0.463652094911.issue6811@psf.upfronthosting.co.za>
Message-ID: <1251745133.13.0.463652094911.issue6811@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

For compatibility w/ import, importlib needs the ability to set 
code.co_filename to the actual location of the bytecode used to create a 
module and not the path embedded in the marshal data. But since 
co_filename is read-only it can't be done at the moment.

The idea is to add an optional argument to marshal.load* that takes a 
string representing the file path that co_filename should be set to, 
overriding what is in the marshal data.

A long-term perk of this is that eventually this argument can become 
required for marshal.loads() and the file path embedded in the marshal 
data can be removed entirely. marshal.load() would infer its path from 
file.name.

This was all discussed on python-dev; 
http://mail.python.org/pipermail/python-dev/2009-August/091460.html

----------
assignee: brett.cannon
components: Extension Modules
messages: 92113
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: add a filename argument to marshal.load*
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6811>
_______________________________________

From report at bugs.python.org  Mon Aug 31 21:06:46 2009
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 31 Aug 2009 19:06:46 +0000
Subject: [issue6811] add a filename argument to marshal.load*
In-Reply-To: <1251745133.13.0.463652094911.issue6811@psf.upfronthosting.co.za>
Message-ID: <1251745606.87.0.747103180251.issue6811@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6811>
_______________________________________

From report at bugs.python.org  Mon Aug 31 21:14:12 2009
From: report at bugs.python.org (Jason Montleon)
Date: Mon, 31 Aug 2009 19:14:12 +0000
Subject: [issue6802] build fails on Snow Leopard
In-Reply-To: <1251577858.73.0.298646060395.issue6802@psf.upfronthosting.co.za>
Message-ID: <1251746052.28.0.981856496448.issue6802@psf.upfronthosting.co.za>


Changes by Jason Montleon <monty19 at hotmail.com>:


----------
nosy: +xaoslaad

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6802>
_______________________________________

From report at bugs.python.org  Mon Aug 31 23:44:39 2009
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 31 Aug 2009 21:44:39 +0000
Subject: [issue992389] attribute error after non-from import
Message-ID: <1251755079.04.0.0643343796981.issue992389@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

The key distinction between this and a "bad" circular import is that
this is lazy.  You may list the import at the top of your module, but
you never touch it until after you've finished importing yourself (and
they feel the same about you.)

An ugly fix could be done today for module imports by creating a proxy
that triggers the import upon the first attribute access.  A more
general solution could be done with a lazyimport statement, triggered
when the target module finishes importing; only problem there is the
confusing error messages and other oddities if you reassign that name.

----------
nosy: +Rhamphoryncus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________

From report at bugs.python.org  Mon Aug 31 23:51:22 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 31 Aug 2009 21:51:22 +0000
Subject: [issue992389] attribute error after non-from import
Message-ID: <1251755482.09.0.34250609401.issue992389@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have done a lazy importer like you describe, Adam, and it does help 
solve this issue. And it does have the problem of import errors being 
triggered rather late and in an odd spot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________

From report at bugs.python.org  Mon Aug 31 23:57:17 2009
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 31 Aug 2009 21:57:17 +0000
Subject: [issue992389] attribute error after non-from import
Message-ID: <1251755837.09.0.287472125966.issue992389@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

It'd probably be sufficient if we raised "NameError: lazy import 'foo'
not yet complete".  That should require a set of what names this module
is lazy importing, which is checked in the failure paths of module
attribute lookup and global/builtin lookup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________