[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...

[Marc-Andre Lemburg]

Marc-Andre Lemburg m...@egenix.com added the comment:

Martin v. Löwis wrote:
 
 Martin v. Löwis mar...@v.loewis.de added the comment:
 
 As per 
 
 http://mail.python.org/pipermail/python-dev/2010-December/106374.html
 
 I think this checkin should be reverted, as it's breaking the language 
 moratorium.

I've asked Guido. We may have to revert the addition of the new
methods and then readd them for 3.3, but I don't really see
them as difficult to implement for the other Python implementations,
since they are just interfaces to the codec sub-system.

The readdition of the codecs and changes to support them in the
codec system do not fall under the moratorium, since they are
stdlib changes.

--

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

[issue10615] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne pyt...@jf.hanne.name added the comment:

 Traditionally, MingW-compiled Python binaries would often be
binary-incompatible

I don't plan to distribute a MinGW compiled package as an alternative to the 
official MSVC based build. In my particular use case, I compile everything into 
a single exe and put the Lib/*.py files into a single zip file. The result is a 
two-file Python distribution which doesn't need an installation. If somebody is 
interested, I can elaborate, but this would be off-topic here.

As for the reproducibility issue: The configure/Makefile system coming with 
Python simply doesn't support creating a Windows build. I hope it's clear that 
the patch is NOT about creating a Windows installer. If this is a requirement 
for getting my patch in, please let me know so I can stop wasting my time!

Whatsoever, if you simply want to reproduce that my compile (!) fixes work, 
please follow these steps:
- Start a MinGW shell and cd into the Python source tree
- CFLAGS=-IPC -IPython ./configure
- Remove the created pyconfig.h and replace PC/pyconfig.h with the manually 
modified version I'm attaching
- Modify the Makefile:
-- Remove pwdmodule.c from the MODOBJS variable
-- Add to the MODOBJS variable: PC/dl_nt.o PC/import_nt.o
-- Remove the LIBOBJS variable assigment
-- Edit the # Build the interpreter paragraph: Add PC/empty.o to the rule 
dependencies *AND* after ...$(SYSLIBS) $(LDLAST)
- Modify PC/empty.c: Add #include Python.h as first line; replace 'return 
0;' by 'wchar_t *wargv[] = { Lpython.exe, NULL }; return Py_Main(1, wargv);'
- Run make
- Add the the full path to the Lib directory to your PYTHONPATH

--
Added file: http://bugs.python.org/file19952/pyconfig.h

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

[issue10615] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne pyt...@jf.hanne.name added the comment:

As promised, here comes the list of modules which successfully compile with 
MinGW:


./Python-3.1.3/PC/import_nt.o
./Python-3.1.3/PC/_subprocess.o
./Python-3.1.3/PC/dl_nt.o
./Python-3.1.3/PC/msvcrtmodule.o
./Python-3.1.3/PC/winreg.o
./Python-3.1.3/Parser/pgen.o
./Python-3.1.3/Parser/grammar1.o
./Python-3.1.3/Parser/parser.o
./Python-3.1.3/Parser/listnode.o
./Python-3.1.3/Parser/parsetok.o
./Python-3.1.3/Parser/tokenizer.o
./Python-3.1.3/Parser/printgrammar.o
./Python-3.1.3/Parser/myreadline.o
./Python-3.1.3/Parser/firstsets.o
./Python-3.1.3/Parser/metagrammar.o
./Python-3.1.3/Parser/grammar.o
./Python-3.1.3/Parser/acceler.o
./Python-3.1.3/Parser/node.o
./Python-3.1.3/Parser/bitset.o
./Python-3.1.3/Python/getcompiler.o
./Python-3.1.3/Python/codecs.o
./Python-3.1.3/Python/pystrtod.o
./Python-3.1.3/Python/pyfpe.o
./Python-3.1.3/Python/getargs.o
./Python-3.1.3/Python/modsupport.o
./Python-3.1.3/Python/getopt.o
./Python-3.1.3/Python/formatter_unicode.o
./Python-3.1.3/Python/mysnprintf.o
./Python-3.1.3/Python/pyctype.o
./Python-3.1.3/Python/sysmodule.o
./Python-3.1.3/Python/errors.o
./Python-3.1.3/Python/pymath.o
./Python-3.1.3/Python/pythonrun.o
./Python-3.1.3/Python/pystrcmp.o
./Python-3.1.3/Python/pystate.o
./Python-3.1.3/Python/getversion.o
./Python-3.1.3/Python/_warnings.o
./Python-3.1.3/Python/Python-ast.o
./Python-3.1.3/Python/frozen.o
./Python-3.1.3/Python/getcopyright.o
./Python-3.1.3/Python/asdl.o
./Python-3.1.3/Python/pyarena.o
./Python-3.1.3/Python/importdl.o
./Python-3.1.3/Python/compile.o
./Python-3.1.3/Python/dtoa.o
./Python-3.1.3/Python/getplatform.o
./Python-3.1.3/Python/traceback.o
./Python-3.1.3/Python/ceval.o
./Python-3.1.3/Python/mystrtoul.o
./Python-3.1.3/Python/thread.o
./Python-3.1.3/Python/symtable.o
./Python-3.1.3/Python/structmember.o
./Python-3.1.3/Python/future.o
./Python-3.1.3/Python/graminit.o
./Python-3.1.3/Python/peephole.o
./Python-3.1.3/Python/marshal.o
./Python-3.1.3/Python/import.o
./Python-3.1.3/Python/bltinmodule.o
./Python-3.1.3/Python/dynload_win.o
./Python-3.1.3/Python/ast.o
./Python-3.1.3/Modules/sha512module.o
./Python-3.1.3/Modules/socketmodule.o
./Python-3.1.3/Modules/expat/xmltok.o
./Python-3.1.3/Modules/expat/xmlrole.o
./Python-3.1.3/Modules/expat/xmlparse.o
./Python-3.1.3/Modules/_csv.o
./Python-3.1.3/Modules/_randommodule.o
./Python-3.1.3/Modules/errnomodule.o
./Python-3.1.3/Modules/_weakref.o
./Python-3.1.3/Modules/arraymodule.o
./Python-3.1.3/Modules/symtablemodule.o
./Python-3.1.3/Modules/zipimport.o
./Python-3.1.3/Modules/sha256module.o
./Python-3.1.3/Modules/mmapmodule.o
./Python-3.1.3/Modules/_ctypes/_ctypes_test.o
./Python-3.1.3/Modules/_ctypes/libffi/src/prep_cif.o
./Python-3.1.3/Modules/_ctypes/libffi/src/x86/ffi.o
./Python-3.1.3/Modules/_ctypes/libffi/src/x86/win32.o
./Python-3.1.3/Modules/_ctypes/callbacks.o
./Python-3.1.3/Modules/_ctypes/stgdict.o
./Python-3.1.3/Modules/_ctypes/_ctypes.o
./Python-3.1.3/Modules/_ctypes/callproc.o
./Python-3.1.3/Modules/_ctypes/malloc_closure.o
./Python-3.1.3/Modules/_ctypes/cfield.o
./Python-3.1.3/Modules/operator.o
./Python-3.1.3/Modules/posixmodule.o
./Python-3.1.3/Modules/md5module.o
./Python-3.1.3/Modules/timemodule.o
./Python-3.1.3/Modules/_functoolsmodule.o
./Python-3.1.3/Modules/datetimemodule.o
./Python-3.1.3/Modules/cmathmodule.o
./Python-3.1.3/Modules/zlibmodule.o
./Python-3.1.3/Modules/_threadmodule.o
./Python-3.1.3/Modules/itertoolsmodule.o
./Python-3.1.3/Modules/_lsprof.o
./Python-3.1.3/Modules/_tkinter.o
./Python-3.1.3/Modules/getbuildinfo.o
./Python-3.1.3/Modules/_collectionsmodule.o
./Python-3.1.3/Modules/_localemodule.o
./Python-3.1.3/Modules/_io/iobase.o
./Python-3.1.3/Modules/_io/bytesio.o
./Python-3.1.3/Modules/_io/stringio.o
./Python-3.1.3/Modules/_io/_iomodule.o
./Python-3.1.3/Modules/_io/textio.o
./Python-3.1.3/Modules/_io/bufferedio.o
./Python-3.1.3/Modules/_io/fileio.o
./Python-3.1.3/Modules/_struct.o
./Python-3.1.3/Modules/_codecsmodule.o
./Python-3.1.3/Modules/selectmodule.o
./Python-3.1.3/Modules/rotatingtree.o
./Python-3.1.3/Modules/sha1module.o
./Python-3.1.3/Modules/unicodedata.o
./Python-3.1.3/Modules/parsermodule.o
./Python-3.1.3/Modules/xxsubtype.o
./Python-3.1.3/Modules/_heapqmodule.o
./Python-3.1.3/Modules/audioop.o
./Python-3.1.3/Modules/_multiprocessing/win32_functions.o
./Python-3.1.3/Modules/_multiprocessing/semaphore.o
./Python-3.1.3/Modules/_multiprocessing/pipe_connection.o
./Python-3.1.3/Modules/_multiprocessing/multiprocessing.o
./Python-3.1.3/Modules/_multiprocessing/socket_connection.o
./Python-3.1.3/Modules/_bisectmodule.o
./Python-3.1.3/Modules/gcmodule.o
./Python-3.1.3/Modules/_sre.o
./Python-3.1.3/Modules/_json.o
./Python-3.1.3/Modules/mathmodule.o
./Python-3.1.3/Modules/signalmodule.o
./Python-3.1.3/Modules/pyexpat.o
./Python-3.1.3/Modules/binascii.o
./Python-3.1.3/Modules/_pickle.o
./Python-3.1.3/Objects/unicodeobject.o
./Python-3.1.3/Objects/enumobject.o
./Python-3.1.3/Objects/codeobject.o

[issue8194] Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2

[Dirkjan Ochtman]

Dirkjan Ochtman dirk...@ochtman.nl added the comment:

Can we get a decision on this? It's kind of sad that this regression wasn't 
fixed in 2.7.1.

--
nosy: +djc

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

[issue10638] PyArg_ParseTuple: refcount in nested tuples

[Armin Rigo]

New submission from Armin Rigo ar...@users.sourceforge.net:

There is an issue in PyArg_ParseTuple() when using nested tuple arguments: it 
accepts a pure Python tuple-like argument, but it cannot work properly because 
PyArg_ParseTuple() is supposed to return borrowed references to the objects.  
For example, here is an attack on functools.partial().__setstate__(), which is 
written using

PyArg_ParseTuple(args, (), ...)

Running crasher.py crashes a debug build of Python, for me with Fatal Python 
error: _functoolsmodule.c:158 object at 0x9011748 has negative ref count 
-606348322.

The only way I can see to fix the crasher is to restrict the kind of argument 
that can be passed to mean a nested tuple.  To be paranoid, it should only 
allow real tuples; a bit more flexibly, lists probably work ok too.

--
components: Interpreter Core
files: crasher.py
messages: 123466
nosy: arigo
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple: refcount in nested tuples
Added file: http://bugs.python.org/file19953/crasher.py

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

[issue10638] PyArg_ParseTuple: refcount in nested tuples

[Georg Brandl]

Georg Brandl ge...@python.org added the comment:

Duplicate of #6083?

--
nosy: +georg.brandl

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

[issue10638] PyArg_ParseTuple: refcount in nested tuples

[Armin Rigo]

Armin Rigo ar...@users.sourceforge.net added the comment:

Indeed.

--
resolution:  - duplicate
status: open - closed

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

[issue10516] Add list.clear() and list.copy()

[Boštjan Mejak]

Boštjan Mejak bostjan.me...@gmail.com added the comment:

mapp_methods ?   Don't you mean map_methods ?

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

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10516
___span class=Apple-style-span style=font-family: arial, sans-serif; 
font-size: 13px; border-collapse: collapse; mapp_methods ?   Don#39;t you 
mean /spanspan class=Apple-style-span style=font-family: arial, 
sans-serif; font-size: 13px; border-collapse: collapse; map_methods ?/span
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10516] Add list.clear() and list.copy()

[Georg Brandl]

Georg Brandl ge...@python.org added the comment:

No, he means mapp_methods.  Why don't you simply look at the file?

--

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

[issue8194] Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

Even if the change may be straightforward, it requires a test.

--
stage:  - unit test needed
versions: +Python 3.1

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

[issue10634] Windows timezone changes not reflected by time.localtime

[Brian Curtin]

Changes by Brian Curtin cur...@acm.org:


--
nosy: +brian.curtin

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

[issue10634] Windows timezone changes not reflected by time.localtime

[Eric Pruitt]

Eric Pruitt eric.pru...@gmail.com added the comment:

Is there a way to force the time module to be reinitialized? I had no success 
experimenting with reload and del, but I assume that has something to do with 
the module being CRT based.

--

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

[issue6697] Check that _PyUnicode_AsString() result is not NULL

[Alexander Belopolsky]

Alexander Belopolsky belopol...@users.sourceforge.net added the comment:

What is the status of this issue?  A grep for _PyUnicode_AsString quickly 
revealed a crash:

 from xml.etree.cElementTree import *
 e = Element('a')
 getattr(e, '\uD800')
Segmentation fault

I don't think this is the only one.

--
nosy: +belopolsky

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

[issue6697] Check that _PyUnicode_AsString() result is not NULL

[Alexander Belopolsky]

Alexander Belopolsky belopol...@users.sourceforge.net added the comment:

Another crash:

 from datetime import *
 datetime.now(timezone(timedelta(0), '\uD800')).strftime('%Z')
Segmentation fault

--

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

[issue10615] Trivial mingw compile fixes

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc amaur...@gmail.com added the comment:

Thanks for the explanations! These instructions should be turned into a patch.
Some questions already:
- Why is the generated pyconfig.h not good enough? Could we modify the 
./configure script instead?
- the empty.c should remain empty... Why not use PC/WinMain.c instead?
- why is a WinMain required when python.c is supposed to define a main()?
Is the final binary a console application or a Windows application?

--

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

[issue10639] reindent.py converts newlines to platform default

[Jason R. Coombs]

New submission from Jason R. Coombs jar...@jaraco.com:

When reindent.py runs, it will convert the line endings for each file it 
converts to the default line ending for the platform on which reindent.py runs. 
It would be better if reindent.py would retain line endings of the source file. 
Attached is a patch that addresses this issue.

--
components: Demos and Tools
files: reindent-autonewline.patch
keywords: patch
messages: 123476
nosy: jaraco
priority: normal
severity: normal
status: open
title: reindent.py converts newlines to platform default
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19955/reindent-autonewline.patch

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

[issue10639] reindent.py converts newlines to platform default

[Jason R. Coombs]

Changes by Jason R. Coombs jar...@jaraco.com:


Removed file: http://bugs.python.org/file19955/reindent-autonewline.patch

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

[issue10639] reindent.py converts newlines to platform default

[Jason R. Coombs]

Jason R. Coombs jar...@jaraco.com added the comment:

Merged the patch with the latest trunk.

--
Added file: http://bugs.python.org/file19956/reindent-autonewline.patch

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

[issue10639] reindent.py converts newlines to platform default

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

Looks good.

--
nosy: +eric.araujo
stage:  - patch review
type:  - behavior
versions: +Python 2.7

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

[issue6697] Check that _PyUnicode_AsString() result is not NULL

[Alexander Belopolsky]

Alexander Belopolsky belopol...@users.sourceforge.net added the comment:

One of the uses of problematic uses of PyUnicode_GetSize() is in Macintosh 
Gestalt interface:



/* Convert a 4-char string object argument to an OSType value */
static int
convert_to_OSType(PyObject *v, OSType *pr)
{
uint32_t tmp;
if (!PyUnicode_Check(v) || PyUnicode_GetSize(v) != 4) {
PyErr_SetString(PyExc_TypeError,
OSType arg must be string of 4 chars);
return 0;
}
memcpy((char *)tmp, _PyUnicode_AsString(v), 4);
*pr = (OSType)ntohl(tmp);
return 1;
}

(Modules/_gestalt.c:41)

This function seems to require a bytes, not str argument as interpreting 4 
UTF-8 bytes as an int makes little sense.

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

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

[issue10516] Add list.clear() and list.copy()

[Boštjan Mejak]

Boštjan Mejak bostjan.me...@gmail.com added the comment:

mapp_methods looks like a typo. you know -- mapp_...? isn't map_... correct?

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

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10516
___mapp_methods looks like a typo. you know -- mapp_...? isn#39;t map_... correct?
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10548] Error in setUp not reported as expectedFailure (unittest)

[holger krekel]

Changes by holger krekel holger.kre...@gmail.com:


--
nosy: +hpk

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

[issue10516] Add list.clear() and list.copy()

[Brian Curtin]

Brian Curtin cur...@acm.org added the comment:

No, and please do not clutter this issue with any perceived typo discussions.

--
nosy: +brian.curtin

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

[issue10516] Add list.clear() and list.copy()

[Éric Araujo]

Changes by Éric Araujo mer...@netwok.org:


Removed file: http://bugs.python.org/file19954/unnamed

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

[issue10516] Add list.clear() and list.copy()

[Éric Araujo]

Changes by Éric Araujo mer...@netwok.org:


Removed file: http://bugs.python.org/file19957/unnamed

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

[issue6697] Check that _PyUnicode_AsString() result is not NULL

[Alexander Belopolsky]

Alexander Belopolsky belopol...@users.sourceforge.net added the comment:

I am attaching a patch that fixes several instances of unchecked 
_PyUnicode_AsString() result.  Not all fixes are completely trivial, so I would 
appreciate a review.

I did not attempt to fix Modules/_gestalt.c because I would like to hear from 
Ronald first.  (See my previous comment.)

The patch doe not have the unit tests yet, but I reported some test cases above 
and these should be easy to convert to unit tests.

--
assignee: ronaldoussoren - belopolsky
keywords: +needs review
stage: needs patch - patch review
Added file: http://bugs.python.org/file19958/issue6697.diff

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

[issue3446] center, ljust and rjust are inconsistent with unicode parameters

[Alexander Belopolsky]

Alexander Belopolsky belopol...@users.sourceforge.net added the comment:

As a feature request for 2.x, I think this should be rejected.

Any objections?

The behavior part seem to have been fixed.

--
assignee:  - belopolsky
nosy: +belopolsky
resolution:  - rejected
status: open - pending
type: behavior - feature request

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

[issue2857] add codec for java modified utf-8

[Alexander Belopolsky]

Alexander Belopolsky belopol...@users.sourceforge.net added the comment:

 TCL only uses the codec for internal represenation. You might want to
 interface to TCL at the C level and use the codec there, but is that
 really a good reason to include the codec in the Python stdlib ?

I wonder if tkinter should use this encoding.

--
nosy: +belopolsky

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

[issue10548] Error in setUp not reported as expectedFailure (unittest)

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

I would expect this code to report an error of some sort, not pass as an 
expected failure.  The expected failure should be in the test case *only*, not 
in the setup or teardown methods.  That is, I don't think this is a bug, I 
think it is a feature that allows one to debug one's test infrastructure.

--
nosy: +r.david.murray

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

[issue8194] Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2

[Martin v . Löwis]

Martin v. Löwis mar...@v.loewis.de added the comment:

Kristjan, can you take a look?

--
nosy: +krisvale

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

[issue10634] Windows timezone changes not reflected by time.localtime

[Martin v . Löwis]

Martin v. Löwis mar...@v.loewis.de added the comment:

What needs reinitialization is not the time module, but the CRT. This is not 
possible without starting a completely new process.

--

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

[issue10615] Trivial mingw compile fixes

[Martin v . Löwis]

Martin v. Löwis mar...@v.loewis.de added the comment:

 As for the reproducibility issue: The configure/Makefile system
 coming with Python simply doesn't support creating a Windows build. I
 hope it's clear that the patch is NOT about creating a Windows
 installer. If this is a requirement for getting my patch in, please
 let me know so I can stop wasting my time!

That's why I was asking what the patch achieves - it was not clear
at all what the objective is. Not supporting the build of an installer
is fine (although that probably wouldn't be difficult). However, if
the patch doesn't manage to make configure;make work, it's IMO
useless. Having make install work in some form would be desirable.

--

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

[issue9333] Expose a way to enable os.symlink on Windows

[Brian Curtin]

Brian Curtin cur...@acm.org added the comment:

I'll come up with a patch to make the attribute always available, but raise 
OSError when the privilege is not held.

--
resolution: fixed - 

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

[issue10516] Add list.clear() and list.copy()

[Boštjan Mejak]

Boštjan Mejak bostjan.me...@gmail.com added the comment:

Why mapp_methods, why not map_methods? Any reason for this?

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

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10516
___Why mapp_methods, why not map_methods? Any reason for this?
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10516] Add list.clear() and list.copy()

[Eric Smith]

Changes by Eric Smith e...@trueblade.com:


Removed file: http://bugs.python.org/file19959/unnamed

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

[issue10453] Add -h/--help option to compileall

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:

r86611 has introduced a regression:

$ mkdir dir1 dir2
$ python3.1 -m compileall dir1 dir2
Listing dir1 ...
Listing dir2 ...
$ python3.2 -m compileall dir1 dir2
usage: compileall.py [-h] [-l] [-f] [-q] [-b] [-d DESTDIR] [-x REGEXP]
 [-i FILE]
 [FILE|DIR]
compileall.py: error: unrecognized arguments: dir2

--
nosy: +Arfrever

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

[issue10548] Error in setUp not reported as expectedFailure (unittest)

[holger krekel]

holger krekel holger.kre...@gmail.com added the comment:

FWIW i tend to agree and would probably prefer setup/teardown to result in an 
error rather than be subsumed in an expected-to-fail marked test.  I guess if 
one regards setup/teardown as a place to implement pre/post-conditions than the 
changes suggested by Michael make more sense.  I'd like to see a more real 
use case / user than the abstract case provided here.

--

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

[issue10516] Add list.clear() and list.copy()

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

1) Obviously because they’re mapping methods, not map methods.

2) Again, opening up the file and looking through it for some seconds or 
minutes would have allowed you to understand it.

3) Again, this is not the right place to discuss this.

4) Again, please do not send HTML email to this tracker.

--

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

[issue10453] Add -h/--help option to compileall

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

Whoops, a nargs='?' should have been '*'.  Who wants to write the test?

--

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

[issue10453] Add -h/--help option to compileall

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

I'm working on it.

--

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

[issue10453] Add -h/--help option to compileall

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

Let me be more helpful, just in case.  This is the offending line:
parser.add_argument('compile_dest', metavar='FILE|DIR', nargs='?')

--

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

[issue10453] Add -h/--help option to compileall

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

Here's the test.  The fix isn't as simple as making it nargs='*', though.

--
Added file: http://bugs.python.org/file19960/compileall_multidir_test.diff

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

[issue10640] SystemError on pickling bytes = 4GB

[Hagen Fürstenau]

New submission from Hagen Fürstenau ha...@zhuliguan.net:

Pickling a bytes object of length = 2**32 results in a SystemError: error 
return without exception set.

If pickling large bytes objects isn't supported, this should be documented and 
a helpful exception be raised.

--
components: Library (Lib)
messages: 123499
nosy: hagen
priority: normal
severity: normal
status: open
title: SystemError on pickling bytes = 4GB
versions: Python 3.1

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

[issue10453] Add -h/--help option to compileall

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

Here is a fix.  This is not finished, though, because I see that I did not do 
an adequate review of the original patch.  There are still bugs in the -d and 
-i handling that need both tests and fixes.

--
Added file: http://bugs.python.org/file19961/compileall_multidir.diff

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

[issue10640] SystemError on pickling bytes = 4GB

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

I suspect this is a duplicate of issue 9614, or rather a subset of that issue.

--
nosy: +alexandre.vassalotti, amaury.forgeotdarc, janglin, pitrou, r.david.murray

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

I just tried using script_helper in a new test, so I have a couple of comments.

I don't see stdout and stderr being conflated, it looks to me like they are 
returned separately, at least by the assert methods.

The assert methods return results, which is unlike other assert methods.  This 
is very useful, even essential, and I wouldn't want to give it up.  That 
conflicts with the current unittest conventions, though.

It would be a big help if 'err' were returned with the refcount line removed if 
it is there, which would make tests using the methods return the same 'err' 
regardless of whether they are run under a debug build or not.

I think the names of the two assert functions should follow the current unit 
test conventions (assertPythonRunOK and asssertPythonRunNotOK, perhaps?)

--
nosy: +r.david.murray

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

[R. David Murray]

Changes by R. David Murray rdmur...@bitdance.com:


--
nosy: +michael.foord

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr added the comment:

 I just tried using script_helper in a new test, so I have a couple of
 comments.
 
 I don't see stdout and stderr being conflated, it looks to me like
 they are returned separately, at least by the assert methods.

That's because I wrote the assert methods since this issue was opened :)

 It would be a big help if 'err' were returned with the refcount line
 removed if it is there, which would make tests using the methods
 return the same 'err' regardless of whether they are run under a debug
 build or not.

Indeed.

 I think the names of the two assert functions should follow the
 current unit test conventions (assertPythonRunOK and
 asssertPythonRunNotOK, perhaps?)

Well, they are functions, not methods, so I don't think they have to
follow the other convention.

--

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

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr added the comment:

 The problem of avoiding interfering with application level handlers
 while having unraisable errors visible by default is probably the
 biggest reason past attempts to get the standard library using the
 logging module internally haven't gained much traction :P

Isn't it a problem that the logging module should be designed to make
easy to fix or work around?

--

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

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

Wow, I didn't realize that's how logging worked.  My understanding was a module 
should just get a logger and log messages, and if the application didn't do any 
setup beforehand, the first logging call would cause messages to be written to 
stdout (or stderr) in a default format.  In fact, I thought that I had observed 
that behavior in the past, but I just tested it and you are right, it complains 
about not having a handler.  

This definitely seems like a logging bug to me.  IMO the only thing a module 
should need to do is call getlogger with its qualified name and log messages.

--
nosy: +r.david.murray

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

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr added the comment:

 Wow, I didn't realize that's how logging worked.  My understanding was
 a module should just get a logger and log messages, and if the
 application didn't do any setup beforehand, the first logging call
 would cause messages to be written to stdout (or stderr) in a default
 format.  In fact, I thought that I had observed that behavior in the
 past,

So have I. Did something change?

And does test_logging really have to change the whole logging setup,
rather than only what it needs to check for? Or can't it restore stuff
afterwards?

--

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

[issue10548] Error in setUp not reported as expectedFailure (unittest)

[Michael Foord]

Michael Foord mich...@voidspace.org.uk added the comment:

(made slightly redundant by Holger's comment but I'll continue anyway)

I think the issue is that setUp / tearDown are used for two different purposes.

The first is setting up and tearing down test infrastructure - where you do 
want to see to errors.

The other is for asserting pre and post conditions. If these are expected to 
fail (for whatever reason) then it may be perfectly reasonable to mark them as 
expectedFailure.

The fact that it was reported as a bug, and also that Antoine has requested 
being able to skip in a tear down (separate issue) shows that people are doing 
this.

So on the one hand - a small proportion of tests are marked expectedFailure and 
a very small subset of those might have a test infrastructure setup error. On 
the other hand for people who want setUp to test pre-conditions and want 
expectedFailure to work here will be completely unable to do this. It seems 
like not having consistent behaviour for expectedFailure will be more of a 
problem for those who want it than having it would be for those who don't need 
it.

As expectedFailure is not intended to be widely used anyway I would rather have 
consistency. It also allows the implementation to be simplified by unifying 
skip / expected fail / exception handling for all of setUp / tearDown / 
testMethod / cleanUp.

--

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

[issue8194] Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2

[Senthil Kumaran]

Senthil Kumaran orsent...@gmail.com added the comment:

I think, the file-like object behavior can be brought back. No need to handling 
gzipped file object in the patch, if the earlier behavior was not handling it. 
There is a separate issue to keep track of handling gzip encoded content in 
httplib.  I shall try to get this moving.

--

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

[issue10641] kill_python sometimes fails to kill processes on buildbots

[David Bolen]

New submission from David Bolen db3l@gmail.com:

On the XP and Win7 buildbots, kill_python sometimes fails to kill hung 
processes.  I caught one instance recently and gathered some information though 
not yet enough to identify the issue.  I can say that no processes are killed 
and no error messages displayed.  I think that implies either a process 
ownership-related snapshot failure (which can exit without error) or a failure 
to identify the processes.

I noticed issue10136 and considered it might be related, but in testing I found 
cases where the exact same usage of kill_python as this failing case worked 
fine, whereas if it was a path mismatch problem I would expect it to fail 
consistently. 

I have attached a log showing the hung processes, attempt to use kill_python, 
and final successful operation with the pskill utility.

In this case it was important to restore the buildbot quickly, but if I can 
catch it again I'll try to add some debugging code to kill_python first.

One thing that confused me along the way is that kill_python is only run at the 
beginning of a build and not as part of the clean process.  So there are cases 
where I have hung processes around, but they turn out to be killable when the 
next build starts.  I'm wondering if kill_python shouldn't perhaps be used on 
every clean operation too.

-- David

--
components: Build
files: kill_python.log
messages: 123510
nosy: db3l
priority: normal
severity: normal
status: open
title: kill_python sometimes fails to kill processes on buildbots
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19964/kill_python.log

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

[issue8194] Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2

[Kristján Valur Jónsson]

Kristján Valur Jónsson krist...@ccpgames.com added the comment:

The patch looks fine to me.  If it runs and everyone is happy, by all means 
lets put it in.

(I agree that the zlib stuff _should_ be handled elsewhere, but for reasons of 
expediency it was put into this module)

--

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

[issue10626] test_concurrent_futures implicitly installs a logging handler on import

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

Actually, I take it back. The default state of logging appears to do the right 
thing with no special handler installed - both the .critical() and .exception() 
messages are written out to stderr by default, so the futures tests pass even 
after Brian's patch is applied.

So I think removing the handler installation code is the right thing to do, 
even if (as it turns out) it doesn't fix the test failure.

I also thought of a more minimal way to reproduce the test failure that makes 
it clear pydoc isn't really involved:

  ./python -m test test_concurrent_futures test_logging test_concurrent_futures

The first execution of the test will pass, the second will fail (both with and 
without Brian's patch to remove the handler installation).

Adding Vinay to the nosy list - I suspect Antoine is right that the logging 
tests are leaving existing loggers in a slightly unhealthy state. A better 
save/restore in regrtest.py might be a place to start, but I don't know the 
internals of the logging package well enough to improve on what I already added.

--
nosy: +vinay.sajip

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

[issue10626] Bad interaction between test_logging and test_concurrent_futures

[Nick Coghlan]

Changes by Nick Coghlan ncogh...@gmail.com:


--
title: test_concurrent_futures implicitly installs a logging handler on import 
- Bad interaction between test_logging and test_concurrent_futures

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

[issue10548] Error in setUp not reported as expectedFailure (unittest)

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

I have to say that it would never have occurred to me to assert a pre or post 
condition and an expected failure where I expected the pre or post condition to 
fail, but if you've got a real use case and it would make the code simpler, I 
suppose I have no serious objection.  I don't use expected failure myself.  
Just make sure you document it well, since it is not a behavior I would expect 
when using expected failure, and I'm sure there will be others like me.

--

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

[issue1571170] Some numeric characters are still not recognized

[Alexander Belopolsky]

Alexander Belopolsky belopol...@users.sourceforge.net added the comment:

Is there anything in this issue that is not addressed by #1571184?  It looks 
like this was originally reported on SF where bug reports and patches had 
separate ids, so this is probably a duplicate of #1571184.

--
nosy: +belopolsky

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

[issue10487] http.server - doesn't process Status: header from CGI scripts

[Glenn Linderman]

Glenn Linderman v+pyt...@g.nevcal.com added the comment:

Just to mention, with the added code from issue 10482, I was able to get a 
3-stream functionality working great in http.server and also backported it to 
2.6 CGIHTTPServer... and to properly process the Status: header on stdout.

Works very well in 2.6; Issue 8077 prevents form processing from working in 
3.2a4, but otherwise it is working there also, and the experience in 2.6 
indicates that once issue 8077 is resolved, it should work in 3.2 also.

--

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

OK, fine on the convention, but I'd still like a more memorable name for 
assert_python_failure.  I've been working on this issue off and on today, and 
I've had to look up that name at least four times.  I can remember 
assert_python_ok, but I can't remember whether its inverse is 
assert_python_fails, assert_python_bad, or what.  For some reason I haven't 
guessed 'failure' even once so far :)  (I know it's not assert_python_not_ok 
because I remember it isn't parallel...)

--

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

[issue10482] subprocess and deadlock avoidance

[Glenn Linderman]

Glenn Linderman v+pyt...@g.nevcal.com added the comment:

Looking at the code the way I've used it in my modified server.py:

stderr = []
stderr_thread = threading.Thread(target=self._readerthread,
 args=(p.stderr, stderr))
stderr_thread.daemon = True
stderr_thread.start()

self.log_message(writer: %s % str( nbytes ))
stdin_thread = threading.Thread(target=self._writerthread,
args=(self.rfile, p.stdin, nbytes))
stdin_thread.daemon = True
stdin_thread.start()

and later

stderr_thread.join()
stdin_thread.join()

p.stderr.close()
p.stdout.close()

if stderr:
stderr = stderr[ 0 ].decode(UTF-8)

It seems like this sort of code (possibly passing in the encoding) could be 
bundled back inside subprocess (I borrowed it from there).

It also seems from recent discussion on npopdev that the cheat-sheet how to 
replace other sys and os popen functions would be better done as wrapper 
functions for the various cases.  Someone pointed out that the hard cases 
probably aren't cross-platform, but that currently the easy cases all get 
harder when using subprocess than when using the deprecated facilities.  They 
shouldn't.  The names may need to be a bit more verbose to separate the various 
use cases, but each use case should remain at least as simple as the prior 
function.

So perhaps instead of just  subprocess.PIPE  to select particular handling for 
stdin, stdout, and stderr, subprocess should implement some varieties to handle 
attaching  different types of reader and writer threads to the handles... of 
course, parameters need to come along for the ride too: maybe the the 
additional variations would be object references with parameters supplied, 
instead of just a manifest constant like .PIPE.

--

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

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Matthew Barnett]

Matthew Barnett pyt...@mrabarnett.plus.com added the comment:

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

It includes additional checks against pathological regexes.

--
Added file: http://bugs.python.org/file19965/issue2636-20101207.zip

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

[issue10642] site.py crashes on python startup due to defective .pth file

[Donald Wallace Rouse II]

New submission from Donald Wallace Rouse II python-bugs-as92...@dwr2.org:

Python 2.7 programs crash on startup due to a defective third-party package 
installed in site-packages.

starting python 2.7 yields the following error message:
Traceback (most recent call last):
  File /usr/lib64/python2.7/site.py, line 554, in module
main()
  File /usr/lib64/python2.7/site.py, line 537, in main
known_paths = addsitepackages(known_paths)
  File /usr/lib64/python2.7/site.py, line 316, in addsitepackages
addsitedir(sitedir, known_paths)
  File /usr/lib64/python2.7/site.py, line 192, in addsitedir
addpackage(sitedir, name, known_paths)
  File /usr/lib64/python2.7/site.py, line 162, in addpackage
exec line
  File string, line 1, in module
KeyError: 'zope'

A similar message appears when starting python2.7 interactively, but it then 
proceeds to the prompt (doesn't crash).

In the file .../python2.7/site.py, at about line 162, in the function 
addpackage, you have an
unprotected exec line:
if line.startswith((import , import\t)):
exec line

If the execution of the line fails, python generates an uncaught exception.
This places python at the mercy of bugs in third-party software.

The exec line should be bracketed by try/except to catch such errors:
if line.startswith((import , import\t)):
try:
exec line
except:
pass
continue

Note 1: I am not sure whether this is a Distutils bug or Distutils2 bug (or 
even something else like Extension Modules), so I'm filing it under 
Distutils2. If this is incorrect, please forward to the proper place. Thanks.

Note 2: Here is where I initially reported this problem: 
http://bugs.gentoo.org/show_bug.cgi?id=347565

--
assignee: tarek
components: Distutils2
messages: 123519
nosy: dwr2, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: site.py crashes on python startup due to defective .pth file
type: crash
versions: Python 2.7

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

[issue10630] dict_proxy.keys() / values() / items() are lists

[Benjamin Peterson]

Benjamin Peterson benja...@python.org added the comment:

r87107

--
nosy: +benjamin.peterson
resolution:  - fixed
status: open - closed

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

[issue10482] subprocess and deadlock avoidance

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

Or various incarnations of functools.partial applied to subprocess.Popen.

--

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

[issue5587] vars() no longer has a useful __repr__

[Daniel Urban]

Daniel Urban urban.dani...@gmail.com added the comment:

Okay, I found it :-) Here is a new patch, now with a test.

--
Added file: http://bugs.python.org/file19966/issue5587b.diff

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

[issue10615] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne pyt...@jf.hanne.name added the comment:

- Why is the generated pyconfig.h not good enough? Could we modify the 
./configure script instead?
Probably setup.py needs to be extended; I did not have a deep look into the 
build system though

- the empty.c should remain empty... Why not use PC/WinMain.c instead?
It seems to be that MinGW does not support the wWinMain unicode entry point; 
the empty.c hack is just to show that it's actually linking

- why is a WinMain required when python.c is supposed to define a 
main()?
Good question; probably just a question of linker flags; I will have a look if 
my time permits

- Is the final binary a console application or a Windows application?
A Console application; creating a GUI application is easily done with the 
-mwindows gcc flag, but then you will have no Python console when not using 
idle or similar

--

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

[issue10643] OSX proxy exceptions parse bug in urllib (crash)

[wojas]

New submission from wojas pyt...@m.wojas.nl:

On OSX (tested with 10.6), urllib will fail to parse the proxy exceptions 
configuration if no netmask is specified.

On my system the following entries have been added to the proxy exception list: 
'127.0.0.1' and 'localhost'. The traceback in included below.

The problem:
 * In 'm = re.match(r(\d+(?:\.\d+)*)(/\d+)?, value)' the netmask is optional
 * But 'mask = int(m.group(2)[1:])' implicitly assumes it exists.

This can be fixed by using 32 as a default netmask if none is specified, see 
attached patch: 'mask = int(m.group(2)[1:]) if m.group(2) else 32'

TRACEBACK:

  File 
/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py, line 
203, in open
return self._mech_open(url, data, timeout=timeout)
  File 
/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py, line 
230, in _mech_open
response = UserAgentBase.open(self, request, data)
  File /Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_opener.py, 
line 188, in open
req = meth(req)
  File /Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_http.py, 
line 316, in http_request
self.rfp.read()
  File /Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_http.py, 
line 242, in read
f = self._opener.open(req)
  File 
/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py, line 
203, in open
return self._mech_open(url, data, timeout=timeout)
  File 
/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_mechanize.py, line 
230, in _mech_open
response = UserAgentBase.open(self, request, data)
  File /Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_opener.py, 
line 193, in open
response = urlopen(self, req, data)
  File 
/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py, 
line 344, in _open
'_open', req)
  File 
/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py, 
line 332, in _call_chain
result = func(*args)
  File 
/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py, 
line 666, in lambda
meth(r, proxy, type))
  File 
/Users/wojas/dev/ds/lib/python2.6/site-packages/mechanize/_urllib2_fork.py, 
line 678, in proxy_open
if req.get_host() and self._proxy_bypass(req.get_host()):
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.py,
 line 1407, in proxy_bypass
return proxy_bypass_macosx_sysconf(host)
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib.py,
 line 1379, in proxy_bypass_macosx_sysconf
mask = int(m.group(2)[1:])
TypeError: 'NoneType' object is unsubscriptable

--
components: Extension Modules
files: urllib-osx-proxy-patch.diff
keywords: patch
messages: 123524
nosy: wojas
priority: normal
severity: normal
status: open
title: OSX proxy exceptions parse bug in urllib (crash)
versions: Python 2.6
Added file: http://bugs.python.org/file19967/urllib-osx-proxy-patch.diff

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

[issue10643] OSX proxy exceptions parse bug in urllib (crash)

[wojas]

wojas pyt...@m.wojas.nl added the comment:

Forgot to set bug type (crash).

--
type:  - crash

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

[issue10615] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne pyt...@jf.hanne.name added the comment:

 However, if the patch doesn't manage to make configure;make work, it's IMO 
 useless.
No, it's not, for two reasons:
- Embedding Python by just compiling/linking all the .c files in seems to be a 
major feature to me; so fixing compilation is useful for its own
- The win32 build system has never used configure;make, but a Visual Studio 
project file; so why require it for a MinGW build?!

 Having make install work in some form would be desirable.
It would be a nice to have. But there is one thing: The patch in its current 
form is trivial and next to impossible to break anything, yet I'm sure it's 
useful for a number of people. It's a result of work done within the company 
I'm working for. Submitting the patch does not have an immediate benefit for my 
company, it only will save me a (short!) amount of time because I will not to 
have to re-apply the patch for every new Python release. This time saving is 
the only justification for spending some working time to try to get it into the 
official tree.

As I have the feeling that all the discussion (which for the major part I used 
my spare time already...) is taking too much time, I will stop doing it as part 
of my job. As I'm privately interested in open source projects, I will continue 
to have a look at fixing configure;make for MinGW; but given my very limited 
spare time, this might take some weeks...

--

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

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Zach Dwiel]

Zach Dwiel zdw...@gmail.com added the comment:

Here is the terminal log of what happens when I try to install and then import 
regex.  Any ideas what is going on?

$ python setup.py install
running install
running build
running build_py
creating build
creating build/lib.linux-i686-2.6
copying Python2/regex.py - build/lib.linux-i686-2.6
copying Python2/_regex_core.py - build/lib.linux-i686-2.6
running build_ext
building '_regex' extension
creating build/temp.linux-i686-2.6
creating build/temp.linux-i686-2.6/Python2
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c Python2/_regex.c -o 
build/temp.linux-i686-2.6/Python2/_regex.o
Python2/_regex.c:109: warning: ‘struct RE_State’ declared inside parameter list
Python2/_regex.c:109: warning: its scope is only this definition or 
declaration, which is probably not what you want
Python2/_regex.c:110: warning: ‘struct RE_State’ declared inside parameter list
Python2/_regex.c:538: warning: initialization from incompatible pointer type
Python2/_regex.c:539: warning: initialization from incompatible pointer type
Python2/_regex.c:679: warning: initialization from incompatible pointer type
Python2/_regex.c:680: warning: initialization from incompatible pointer type
Python2/_regex.c:1217: warning: initialization from incompatible pointer type
Python2/_regex.c:1218: warning: initialization from incompatible pointer type
Python2/_regex.c: In function ‘try_match’:
Python2/_regex.c:3153: warning: passing argument 1 of 
‘state-encoding-at_boundary’ from incompatible pointer type
Python2/_regex.c:3153: note: expected ‘struct RE_State *’ but argument is of 
type ‘struct RE_State *’
Python2/_regex.c:3184: warning: passing argument 1 of 
‘state-encoding-at_default_boundary’ from incompatible pointer type
Python2/_regex.c:3184: note: expected ‘struct RE_State *’ but argument is of 
type ‘struct RE_State *’
Python2/_regex.c: In function ‘search_start’:
Python2/_regex.c:3535: warning: assignment from incompatible pointer type
Python2/_regex.c:3581: warning: assignment from incompatible pointer type
Python2/_regex.c: In function ‘basic_match’:
Python2/_regex.c:3995: warning: assignment from incompatible pointer type
Python2/_regex.c:3996: warning: assignment from incompatible pointer type
Python2/_regex.c: At top level:
Python2/unicodedata_db.h:241: warning: ‘nfc_first’ defined but not used
Python2/unicodedata_db.h:448: warning: ‘nfc_last’ defined but not used
Python2/unicodedata_db.h:550: warning: ‘decomp_prefix’ defined but not used
Python2/unicodedata_db.h:2136: warning: ‘decomp_data’ defined but not used
Python2/unicodedata_db.h:3148: warning: ‘decomp_index1’ defined but not used
Python2/unicodedata_db.h:: warning: ‘decomp_index2’ defined but not used
Python2/unicodedata_db.h:4122: warning: ‘comp_index’ defined but not used
Python2/unicodedata_db.h:4241: warning: ‘comp_data’ defined but not used
Python2/unicodedata_db.h:5489: warning: ‘get_change_3_2_0’ defined but not used
Python2/unicodedata_db.h:5500: warning: ‘normalization_3_2_0’ defined but not 
used
Python2/_regex.c: In function ‘basic_match’:
Python2/_regex.c:4106: warning: ‘info.captures_count’ may be used uninitialized 
in this function
Python2/_regex.c:4720: warning: ‘info.captures_count’ may be used uninitialized 
in this function
Python2/_regex.c: In function ‘splitter_split’:
Python2/_regex.c:8076: warning: ‘result’ may be used uninitialized in this 
function
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
build/temp.linux-i686-2.6/Python2/_regex.o -o build/lib.linux-i686-2.6/_regex.so
running install_lib
copying build/lib.linux-i686-2.6/_regex.so - 
/usr/local/lib/python2.6/dist-packages
copying build/lib.linux-i686-2.6/_regex_core.py - 
/usr/local/lib/python2.6/dist-packages
copying build/lib.linux-i686-2.6/regex.py - 
/usr/local/lib/python2.6/dist-packages
byte-compiling /usr/local/lib/python2.6/dist-packages/_regex_core.py to 
_regex_core.pyc
byte-compiling /usr/local/lib/python2.6/dist-packages/regex.py to regex.pyc
running install_egg_info
Writing /usr/local/lib/python2.6/dist-packages/regex-0.1.20101123.egg-info
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
 import regex
Traceback (most recent call last):
  File stdin, line 1, in module
  File 
/usr/local/lib/python2.6/dist-packages/regex-0.1.20101207-py2.6-linux-i686.egg/regex.py,
 line 273, in module
from _regex_core import *
  File 
/usr/local/lib/python2.6/dist-packages/regex-0.1.20101207-py2.6-linux-i686.egg/_regex_core.py,
 line 54, in module
import _regex
ImportError: 
/usr/local/lib/python2.6/dist-packages/regex-0.1.20101207-py2.6-linux-i686.egg/_regex.so:
 undefined symbol: max

--
nosy: +zdwiel
type: feature request - compile error
versions: +Python 2.6 -Python 3.2

___
Python tracker rep...@bugs.python.org

[issue8194] Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2

[Senthil Kumaran]

Senthil Kumaran orsent...@gmail.com added the comment:

Instead of tossing around the GzipDecoding code from one method to another 
(which would in turn change the return value from those methods), I thought is 
appropriate to do a change in parse_response itself, so that it verifies that 
it is a http response (new kind) before attempting header retrieval. If it an 
old kind of response (a file object), it does not do a getheader call.

This is committed in r87111 for release27-maint. I shall merge this into other 
branches.

This does not change any return value from the methods.

- Tests look bit more involved than I expected. The correct way to test this 
would be to create a FakeTransport object which exhibited the previous older 
behavior of getting the response via http.getfile method. 

The Fakesocket and Transport tests are not actually testing the response. So I 
could not exercise the response part.(Perhaps this is reason it was not 
caught in the first place). The request part are exercised properly.

If someone has a patch for the tests to exercise response of Fakesocket object 
and Transport class tests, welcome. Otherwise I shall try to come up with one 
and add this case too.

--
assignee:  - orsenthil

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

[issue8194] Incompatible API change in xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2

[Senthil Kumaran]

Senthil Kumaran orsent...@gmail.com added the comment:

This issue is not applicable to release31-maint.

--
resolution:  - fixed
versions:  -Python 3.1

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

[issue10615] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne pyt...@jf.hanne.name added the comment:

Two corrections for the configure;make workaround:
- WRONG: Remove the created pyconfig.h and replace PC/pyconfig.h with the 
manually modified version I'm attaching
- CORRECT: Remove PC/pyconfig.h and replace the created pyconfig.h with the 
manually modified version I'm attaching
- Modules/config.c needs to modified as well:
-- Replace PyInit_posix by PyInit_nt (two occurences), posix by nt (in 
_PyImport_Inittab)
-- Remove '{pwd, PyInit_pwd},' in _PyImport_Inittab

--

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