[issue10151] Docs: can globals() be updated?

[Thomas Guettler]

New submission from Thomas Guettler :

Hi,

the documentation of "globals()" is missing a note if you can update
the dictionary:

http://docs.python.org/library/functions.html?highlight=globals#globals

For "locals()" it is documented:
http://docs.python.org/library/functions.html?highlight=locals#locals

--
assignee: d...@python
components: Documentation
messages: 119192
nosy: d...@python, guettli
priority: normal
severity: normal
status: open
title: Docs: can globals() be updated?
versions: Python 2.7

___
Python tracker 

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

[issue10128] multiprocessing.Pool throws exception with __main__.py

[Ask Solem]

Changes by Ask Solem :


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

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I don't think that a command line option and an environment variable
> is pratical for an OS distributor.

Environment variables are probably the most practical for OS vendors,
since they can simply set them in /etc/profile.d (Mandriva does that
with PYTHONDONTWRITEBYTECODE :-/).

If it's an env variable, though, it should be clear that it's
CPython-specific, so I'm not sure how to call it.
CPYTHONNOSEGFAULTHANDLER?

--

___
Python tracker 

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

[issue10092] calendar does not restore locale properly

[Boštjan Mejak]

Boštjan Mejak  added the comment:

>>> import calendar
>>> calendar.LocaleTextCalendar(locale='fr_FR').formatmonthname(2010,10,10)
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python27\lib\calendar.py", line 522, in formatmonthname
with TimeEncoding(self.locale) as encoding:
  File "C:\Python27\lib\calendar.py", line 489, in __enter__
self.oldlocale = _locale.setlocale(_locale.LC_TIME, self.locale)
  File "C:\Python27\lib\locale.py", line 531, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting

Is it just my machine or is this a common thing on most machines? If I do a 
test and I try to set a locale with the setlocale() method, I get this 
"locale.Error: unsupported locale setting". So I gather that the method 
setlocale() is broken and we should fix it before fixing the 
Locale{Text,HTML}Calendar ones.


The way setlocale() is implemented, is this:

def setlocale(category, value=None):
""" setlocale(integer,string=None) -> string.
Activates/queries locale processing.
"""
if value not in (None, '', 'C'):
raise Error, '_locale emulation only supports "C" locale'
return 'C'


Please note that the online documentation documents its API like this:
locale.setlocale(category[, locale])  See 
http://docs.python.org/library/locale.html#locale.setlocale

So you can see that the implementation differs from the documentation in that 
it documents the 2nd argument as 'locale' where in the implementation there is 
'value'. If that's a bug, I don't know.

Anyway, please fix the implementation. I found out some very interesting 
thing... Note the line  "if value not in (None, '', 'C')"  in the 
implementation. This is the faulty thing in the function because NoneType is 
not iterable.

Test it for yourself in the interpreter:
>>> value = None
>>> value not in None
Traceback (most recent call last):
  File "", line 1, in 
TypeError: argument of type 'NoneType' is not iterable

So this setlocale() always raises an error. Please fix this.

Of course, this is valid:
>>> value = None
>>> value is not None
False

No error here. So try to combine this into a workable patch. Thanks.

--

___
Python tracker 

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

[issue10092] calendar does not restore locale properly

[Georg Brandl]

Georg Brandl  added the comment:

Bostjan, both your points are invalid.  First, the locale settings that a 
machine supports vary greatly.  "fr_FR" doesn't need to be a valid setting on 
your machine.

Second, "val in None" will always fail.  "val in (None, ...)" will succeed, 
since you're testing membership in the given tuple that includes None.

--

___
Python tracker 

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

[issue10151] Docs: can globals() be updated?

[Georg Brandl]

Georg Brandl  added the comment:

It is documented, however, that globals() returns the dictionary of a module, 
which can be modified.  For locals(), the situation is quite more complicated, 
which is why the warning there is warranted.

--
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue10092] calendar does not restore locale properly

[Tim Golden]

Tim Golden  added the comment:

Boštjan, the code segment you quote is the *fallback* if the
C module hasn't been built for some reason. The module simply
calls through to the underlying C Library. I notice you're
running on Windows, so this is a useful MS page:

http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx

and you can see there that a call of setlocale (LC_ALL, "English")
is valid (of "French" if you prefer):

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale (locale.LC_ALL, "French")
'French_France.1252'
>>>

--
nosy: +tim.golden

___
Python tracker 

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

[issue10152] symtable.c: ste_tmpname uninitialized

[Stefan Krah]

New submission from Stefan Krah :

Found by Valgrind:

==3947== Use of uninitialised value of size 8
==3947==at 0x5716D13: _itoa_word (in /lib/libc-2.8.90.so)
==3947==by 0x5719F53: vfprintf (in /lib/libc-2.8.90.so)
==3947==by 0x5743239: vsnprintf (in /lib/libc-2.8.90.so)
==3947==by 0x4956AF: PyOS_vsnprintf (mysnprintf.c:74)
==3947==by 0x495661: PyOS_snprintf (mysnprintf.c:47)
==3947==by 0x49FC1E: symtable_new_tmpname (symtable.c:1092)
==3947==by 0x4A2CE6: symtable_handle_comprehension (symtable.c:1648)
==3947==by 0x4A2F7C: symtable_visit_listcomp (symtable.c:1673)
==3947==by 0x4A1C63: symtable_visit_expr (symtable.c:1363)
==3947==by 0x4A07C5: symtable_visit_stmt (symtable.c:1178)
==3947==by 0x4A0BBE: symtable_visit_stmt (symtable.c:1200)
==3947==by 0x4A08D4: symtable_visit_stmt (symtable.c:1187)



The patch fixes the issue (unless the intent was to use somewhat randomized 
tmpnames).

--
files: ste_tmpname.patch
keywords: patch
messages: 119198
nosy: skrah
priority: normal
severity: normal
status: open
title: symtable.c: ste_tmpname uninitialized
Added file: http://bugs.python.org/file19293/ste_tmpname.patch

___
Python tracker 

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

[issue10152] symtable.c: ste_tmpname uninitialized

[Stefan Krah]

Changes by Stefan Krah :


--
stage:  -> patch review
type:  -> behavior
versions: +Python 3.2

___
Python tracker 

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

[issue6864] IDLE 2.6.1 locks up on Mac OS 10.6

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Richard: I don't understand your message. What abort are you talking about?

--

___
Python tracker 

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

[issue1349106] email.Generator does not separate headers with "\r\n"

[Malcolm Box]

Malcolm Box  added the comment:

David: Great to see a patch for this.

You're right of course, 8bit isn't binary - I meant binary.  The main place 
this shows up is when you're using MIME not in email (e.g. on the web), where 
binary transport is entirely possible.

This fix should mean that the MIME libraries are much more usable in non-email 
environments.  Thanks.

--

___
Python tracker 

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

[issue10153] Memory leak in pythonrun.c

[Stefan Krah]

New submission from Stefan Krah :

Found by Valgrind, patch attached:

==4921== 24 bytes in 1 blocks are definitely lost in loss record 419 of 2,694
==4921==at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4921==by 0x417F06: _PyObject_New (object.c:244)
==4921==by 0x520C4E: PyFile_NewStdPrinter (fileobject.c:364)
==4921==by 0x499438: Py_InitializeEx (pythonrun.c:281)
==4921==by 0x49951E: Py_Initialize (pythonrun.c:322)
==4921==by 0x4B2579: Py_Main (main.c:587)
==4921==by 0x417D6B: main (python.c:51)

--
components: Interpreter Core
files: pythonrun.patch
keywords: patch
messages: 119201
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Memory leak in pythonrun.c
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19294/pythonrun.patch

___
Python tracker 

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

[issue10152] symtable.c: ste_tmpname uninitialized

[Stefan Krah]

Changes by Stefan Krah :


--
components: +Interpreter Core

___
Python tracker 

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

[issue10149] Data truncation in expat parser

[R. David Murray]

R. David Murray  added the comment:

For other reviewers, I'm reposting just his python program as a text file.

Maciek: I myself don't know enough about expat to comment, but is it possible 
you have an issue similar to issue 10026?

--
nosy: +r.david.murray
Added file: http://bugs.python.org/file19295/xml-parse-revisions.py

___
Python tracker 

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

[issue10152] symtable.c: ste_tmpname uninitialized

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

___
Python tracker 

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

[issue7473] Compile error when building a 3-way universal framework when a 2-way universal framework is present

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I've verified that the patch does not cause problems when building the OSX 
installer.

That patch should be applied, with a short comment that explains why the code 
block is disabled for framework builds.

--
versions:  -Python 2.6

___
Python tracker 

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

[issue10128] multiprocessing.Pool throws exception with __main__.py

[Michael Olson]

Michael Olson  added the comment:

Ummm, I think I've been unclear on where I was making changes, I changed 
lib\multiprocessing\forking.py to fix the issue.

Patch attached.

--
keywords: +patch
resolution: invalid -> 
status: closed -> open
Added file: http://bugs.python.org/file19296/issue10128.patch

___
Python tracker 

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

[issue10128] multiprocessing.Pool throws exception with __main__.py

[Michael Olson]

Michael Olson  added the comment:

As a note, I didn't attach a patch at first because I was fairly sure I was 
kludging it into submission, but at least this makes it clear as to what I did.

v/r
-- Michael Olson

--

___
Python tracker 

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

[issue7473] Compile error when building a 3-way universal framework when a 2-way universal framework is present

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Committed the fix for 3.2 in r85744, for 2.7 in r85745 and for 3.1 in r85746

BTW. The installer does mention which architectures are supported, both in a 
README on the disk image and in one of the readme screens in the installer.

--
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue763708] Failures in test_macostools for --enable-unicode=ucs4

[Ronald Oussoren]

Changes by Ronald Oussoren :


Removed file: http://bugs.python.org/file13487/issue763708.patch

___
Python tracker 

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

[issue763708] Failures in test_macostools for --enable-unicode=ucs4

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I've attached a new patch that works for me.

The new patch doesn't try to warn when running the configure script, but bails 
out when you run make by using an '#error' in pymacconfig.h.

(Removing 2.6 because that's in security-fix-only mode and 3.1 because this 
issue only affects 2.x)

--
keywords:  -26backport, needs review, patch
versions:  -Python 2.6, Python 3.1
Added file: http://bugs.python.org/file19297/issue763708.patch

___
Python tracker 

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

[issue3367] Uninitialized value read in parsetok.c

[Stefan Krah]

Stefan Krah  added the comment:

I can still reproduce it in py3k just by hitting Ctrl-D in the interactive
interpreter:


$ valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python 
==16724== Memcheck, a memory error detector
==16724== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==16724== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==16724== Command: ./python
==16724== 
Python 3.2a3+ (py3k:85735M, Oct 20 2010, 14:19:24) 
[GCC 4.2.4 (Ubuntu 4.2.4-3ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
==16724== Conditional jump or move depends on uninitialised value(s)
==16724==at 0x4F4DB7: parsetok (parsetok.c:198)
==16724==by 0x4F4B03: PyParser_ParseFileFlagsEx (parsetok.c:100)
==16724==by 0x49C8FB: PyParser_ASTFromFile (pythonrun.c:1884)
==16724==by 0x49AAC6: PyRun_InteractiveOneFlags (pythonrun.c:1124)
==16724==by 0x49A7B8: PyRun_InteractiveLoopFlags (pythonrun.c:1035)
==16724==by 0x49A677: PyRun_AnyFileExFlags (pythonrun.c:1004)
==16724==by 0x4B1EDE: run_file (main.c:296)
==16724==by 0x4B293E: Py_Main (main.c:681)
==16724==by 0x417D6B: main (python.c:51)
==16724== 
==16724== 
==16724==  Attach to debugger ? --- [Return/N/n/Y/y/C/c]  y
==16724== starting debugger with cmd: /usr/bin/gdb -nw /proc/16725/fd/1014 16725
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Attaching to program: /proc/16725/fd/1014, process 16725
0x004f4db7 in parsetok (tok=0x6c705d0, g=0x80bac0, start=256, 
err_ret=0x7fefffee0, flags=0x7fe1c) at Parser/parsetok.c:198
198 if (a >= tok->line_start)
(gdb)

--
nosy: +skrah
resolution: fixed -> 
status: closed -> open
versions: +Python 3.2 -Python 2.6, Python 3.0

___
Python tracker 

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

[issue6864] IDLE 2.6.1 locks up on Mac OS 10.6

[Richard]

Richard  added the comment:

Sorry to be obscure, Ronald. I mistook my configuration problem, described 
below for the original problem. But I can reproduce the problem with opening an 
existing file under IDLE, which is a segmentation fault. When opening a new 
window, I get a blank screen but no >>> prompt.

I should have done this before on my two boxes. It shows pretty clearly that 
the abort trap problem in 2.6.x is my configuration problem. On the development 
box, I have mutliple Pythons, with varying degrees of IDLE success; on the 
production box I have only the factory installed 2.6.1 with no IDLE problem 
other than the one originally reported. Both boxes are under 10.6.4.

Development:
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
$ /usr/bin/idle2.6
CGColor with 1 components
Abort trap
# This is probably due to paths crossed with 2.6.6
$ sudo /usr/bin/idle2.6
2010-10-20 10:12:16.329 Python[11954:1707] 
__CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs
2010-10-20 10:12:31.868 Python[11954:1707] 
__CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs
0
#IDLE works, otherwise, except for the segmentation issue

Production:
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
#IDLE works, except for the segmentation issue

for completeness:

Development:
Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
$ idle3
Floating point exception

Development:
Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
** IDLE can't import Tkinter.  Your Python may not be configured for Tk. **

Development:
Python 2.6.6 (r266:84292, Aug 28 2010, 10:17:47) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
#IDLE hangs

--

___
Python tracker 

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

[issue9670] Exceed Recursion Limit in Thread

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The attached patch explicitly sets the minimal stack size to about 704K, which 
is the minimal size where 'def f(): f()' doesn't cause a buserror when run in a 
thread.

--
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19298/issue9670.patch

___
Python tracker 

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

[issue6763] Crash on mac os x leopard in mimetypes.guess_type (or PyObject_Malloc)

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I'm closing this as a duplicate of #9670, that is: too deep recursion in a 
thread doesn't trigger the appropriate exception but causes a hard crash 
instead.

I have attached a patch to that issue (but haven't applied it yet, I'd like 
someone else too look at the patch as well).

BTW. I don't think this issue is serious enough to warrant a backport to 2.6.

--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

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

[issue9047] Python 2.7rc2 includes -isysroot twice on each gcc command line

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Marc-Andre: does the current HEAD of the 2.7 and 3.2 branches work for you?

The build still has duplicate flags, but that doesn't seem to cause problems on 
my machines. If it also doesn't cause problems on your machines I'd prefer to 
close this issue as won't fixed because cleaning up the duplicate flags is 
non-trivial.

--

___
Python tracker 

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

[issue10154] locale.normalize strips "-" from UTF-8, which fails on Mac

[Stephen Hansen]

New submission from Stephen Hansen :

In the course of investigating issue10092, Georg discovered that the behavior 
of locale.normalize() on Mac is bad.

Basically, "en_US.UTF-8" is how the "correct" locale string should be spelled 
on the Mac. If you drop the dash, it fails: which locale.normalize does, so you 
can't pass the return value of the function to setlocale, even though that's 
what its documented to be for.

If that isn't clear, this should demonstrate (from /branches/py3k):


Top-2:build pythonbuildbot$ ./python.exe
Python 3.2a3+ (py3k:85631, Oct 17 2010, 06:45:22) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
[51767 refs]
>>> locale.normalize("en_US.UTF-8")
'en_US.UTF8'
[51770 refs]
>>> locale.setlocale(locale.LC_TIME, 'en_US.UTF8')
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/pythonbuildbot/test/build/Lib/locale.py", line 538, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
[51816 refs]
>>> locale.setlocale(locale.LC_TIME, 'en_US.UTF-8')
'en_US.UTF-8'
[51816 refs]

The precise same behavior exists on my stock/system Python 2.6, too, fwiw. (Not 
that it can be fixed on 2.6, but maybe 2.7?)

--
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 119213
nosy: ixokai, ronaldoussoren
priority: normal
severity: normal
status: open
title: locale.normalize strips "-" from UTF-8, which fails on Mac
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue9670] Exceed Recursion Limit in Thread

[Leonardo Santagada]

Leonardo Santagada  added the comment:

Why not make it bigger so it doesn't crash for much bigger functions?

--
nosy: +santagada

___
Python tracker 

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

[issue9022] TypeError in wsgiref.handlers when using CGIHandler

[And Clover]

And Clover  added the comment:

Yes, CGIHandler is broken in 3.0-3.1; wsgiref in general has been in limbo 
until the whole issue of py3k-WSGI is sorted. This seems to be happening now in 
PEP .

Attached patch to make CGIHandler use the byte interfaces for stdin/stdout, 
which allows the write calls to work and provides byte streams to the WSGI 
application as required by PEP .

--
keywords: +patch
nosy: +aclover
Added file: http://bugs.python.org/file19299/issue9022.patch

___
Python tracker 

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

[issue10154] locale.normalize strips "-" from UTF-8, which fails on Mac

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This patch solves the immediate failure:

Index: Lib/locale.py
===
--- Lib/locale.py   (revision 85743)
+++ Lib/locale.py   (working copy)
@@ -396,6 +396,9 @@
 else:
 encoding = defenc
 #print 'found encoding %r' % encoding
+if sys.platform == 'darwin' and encoding == 'UTF8':
+encoding = 'UTF-8'
+
 if encoding:
 return langname + '.' + encoding
 else:

I'm not happy about hardcoding this specific exception though, there should be 
a better solution than this.

Ronald

--
Added file: http://bugs.python.org/file19300/smime.p7s

___
Python tracker 

___

smime.p7s
Description: S/MIME cryptographic signature
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9670] Exceed Recursion Limit in Thread

[Ronald Oussoren]

Ronald Oussoren  added the comment:

On 20 Oct, 2010, at 17:41, Leonardo Santagada wrote:

> 
> Leonardo Santagada  added the comment:
> 
> Why not make it bigger so it doesn't crash for much bigger functions?

I don't mind making it bigger, but a larger size does come with a cost: the 
larger the initial stack size the less threads you can have without trashing 
the system (or running out of address space on a 32-bit build). 

I'm fine with increasing it to 1M, which is a nice round number build not 
larger. 

BTW. I haven't looked up the default stack size for the main thread on OSX.

Ronald
> 
> --
> nosy: +santagada
> 
> ___
> Python tracker 
> 
> ___

--
Added file: http://bugs.python.org/file19301/smime.p7s

___
Python tracker 

___

smime.p7s
Description: S/MIME cryptographic signature
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10154] locale.normalize strips "-" from UTF-8, which fails on Mac

[Ronald Oussoren]

Changes by Ronald Oussoren :


Removed file: http://bugs.python.org/file19300/smime.p7s

___
Python tracker 

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

[issue10089] Add support for arbitrary -X options

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a simpler version without comma-separated pairs.

--
Added file: http://bugs.python.org/file19302/xopts3.patch

___
Python tracker 

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

[issue9670] Exceed Recursion Limit in Thread

[Leonardo Santagada]

Leonardo Santagada  added the comment:

The default stack size in osx is 8MB. I think it is a safer bet, and no one is 
supposed to be using more than like 40-50 threads anyway (specially in 32 bit 
only systems limited to 8 cores).

Is there a user case for hundreds/thousands of threads in python?

--

___
Python tracker 

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

[issue10155] Add fixups for encoding problems to wsgiref

[And Clover]

New submission from And Clover :

Currently wsgiref's CGIHandler makes a WSGI environ from the CGI environ 
without changes.

Unfortunately the CGI environ is wrong in a number of common circumstances:

- on Windows, the native environ is Unicode, and different servers choose 
different decodings for HTTP bytes to store in the environ (most notably for 
PATH_INFO);

- on Windows with Python 2.x, os.environ is read from the Unicode native 
environ using the ANSI encoding, which will lose/mangle non-ASCII characters;

- on Posix with Python 3.x, os.environ is read from a native bytes environ 
using the filesystemencoding which is probably not ISO-8859-1.

- on IIS, PATH_INFO inappropriately includes SCRIPT_NAME unless a hidden, 
rarely-used, and problematic config option is applied.

Previously, it was not clear in PEP 333 what was supposed to happen with 
headers and encodings, especially under Python 3. PEP  clears this up. 
These patches add fixups to wsgiref to try to generate the nearest to a 
'correct' environ as per PEP  as possible for the current platform and 
server software.

They also fix simple_server to use the correct encoding for PATH_INFO, and 
include the fix for issue 9022, correspondingly updating the simple_server demo 
app and tests to conform to PEP 's expectation that headers will be 
ISO-8859-1-decoded Unicode strings. The test_bytes_validation test is removed: 
as I understand it, it's no long allowed to use byte string headers/status.

--
components: Library (Lib)
files: wsgiref-patches-3.2a3.patch
keywords: patch
messages: 119220
nosy: aclover
priority: normal
severity: normal
status: open
title: Add fixups for encoding problems to wsgiref
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file19303/wsgiref-patches-3.2a3.patch

___
Python tracker 

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

[issue10155] Add fixups for encoding problems to wsgiref

[And Clover]

And Clover  added the comment:

(patch for Python 2.x, for what it's worth)

--
Added file: http://bugs.python.org/file19304/wsgiref-patches-2.7.patch

___
Python tracker 

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

[issue9670] Exceed Recursion Limit in Thread

[R. David Murray]

R. David Murray  added the comment:

It would be nice if we could expand this fix to include FreeBSD, which as I 
understand it has the same problem.

--

___
Python tracker 

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

[issue4388] test_cmd_line fails on MacOS X

[STINNER Victor]

STINNER Victor  added the comment:

> One solution would be to duplicate the UTF-8 decoder for OSX,
> incorporating surrogate escape. This should be much shorter 
> than the full UTF-8 codec, and perhaps at least utf8_code_length 
> could be shared.

Good idea, implemented in the attached patch [osx_utf8_cmdline-3.patch]. I 
tested the patch on x86 Snow Leopard 3.x and it looks like it fixes the 
test_cmd_line failure (I modified some tests to remove manually LC_ALL, 
LC_CTYPE and LANG environment variables).

--
Added file: http://bugs.python.org/file19305/osx_utf8_cmdline-3.patch

___
Python tracker 

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

[issue4388] test_cmd_line fails on MacOS X

[STINNER Victor]

STINNER Victor  added the comment:

_Py_DecodeUTF8_surrogateescape() is a simplified version of 
PyUnicode_DecodeUTF8Stateful():
 - no "consumed" argument
 - only support surrogateescape error handler
 - no optimization
 - don't resize the buffer at exit

Hum, resize the buffer is maybe a good idea to not waste memory.

--

___
Python tracker 

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

[issue10092] calendar does not restore locale properly

[Boštjan Mejak]

Boštjan Mejak  added the comment:

Thank you so much for your answer. The
locale.setlocale(category=locale.LC_NUMERIC,
locale="Slovenian")  works like a charm in my application. Now the 'n'
format specifier works as I want. But tell me whether the 'n' format
specifier can be forced to round the float to just one decimal place. I know
that the 'f' format specifier does that by specifying ".1f", but 'f' is not
locale-aware. I have set the 'n' format specifier in my application like
".3n", which is okay if the returned number is two integers and one decimal,
but is not okay if the returned number is one integer and two decimals,
because I want just one decimal, always. How can I make that by using the
'n' format specifier?

On Wed, Oct 20, 2010 at 11:37 AM, Tim Golden  wrote:

>
> Tim Golden  added the comment:
>
> Boštjan, the code segment you quote is the *fallback* if the
> C module hasn't been built for some reason. The module simply
> calls through to the underlying C Library. I notice you're
> running on Windows, so this is a useful MS page:
>
> http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx
>
> and you can see there that a call of setlocale (LC_ALL, "English")
> is valid (of "French" if you prefer):
>
> Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import locale
> >>> locale.setlocale (locale.LC_ALL, "French")
> 'French_France.1252'
> >>>
>
> --
> nosy: +tim.golden
>
> ___
> Python tracker 
> 
> ___
>

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

___
Python tracker 

___Thank you so much for your answer. The  locale.setlocale(category=locale.LC_NUMERIC,
 locale="Slovenian")  works like a charm in my application. Now the 
'n' format specifier works as I want. But tell me whether the 
'n' format specifier can be forced to round the float to just one 
decimal place. I know that the 'f' format specifier does that by 
specifying ".1f", but 'f' is not locale-aware. I have set the 
'n' format specifier in my application like ".3n", which is 
okay if the returned number is two integers and one decimal, but is not okay if 
the returned number is one integer and two decimals, because I want just one 
decimal, always. How can I make that by using the 'n' format 
specifier?

On Wed, Oct 20, 2010 at 11:37 AM, Tim 
Golden rep...@bugs.python.org> wrote:


Tim Golden m...@timgolden.me.uk> added the comment:

Boštjan, the code segment you quote is the *fallback* if the
C module hasn't been built for some reason. The module simply
calls through to the underlying C Library. I notice you're
running on Windows, so this is a useful MS page:

http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx"; 
target="_blank">http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx

and you can see there that a call of setlocale (LC_ALL, "English")
is valid (of "French" if you prefer):

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or 
"license" for more information.
>>> import locale
>>> locale.setlocale (locale.LC_ALL, "French")
'French_France.1252'
>>>

--
nosy: +tim.golden

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue10092>
___


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

[issue10156] Memory leak (r70459)

[Stefan Krah]

New submission from Stefan Krah :

This is one of two remaining "definitely lost" leaks in py3k. It started
to appear in r70459. How to reproduce:

make distclean && ./configure OPT="-O0 -g" --without-pymalloc && make

valgrind --leak-check=full --suppressions=Misc/valgrind-python.supp ./python > 
VGOUT 2>&1

Then search for 'definitely'. This leak is not present in release-2.7.


==2058== 56 bytes in 1 blocks are definitely lost in loss record 918 of 2,136
==2058==at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==2058==by 0x4167DE: _PyObject_New (object.c:243)
==2058==by 0x42C278: _PyUnicode_New (unicodeobject.c:341)
==2058==by 0x4306BD: PyUnicodeUCS2_DecodeUTF8Stateful (unicodeobject.c:2100)
==2058==by 0x430671: PyUnicodeUCS2_DecodeUTF8 (unicodeobject.c:2065)
==2058==by 0x42C8F7: PyUnicodeUCS2_FromStringAndSize (unicodeobject.c:541)
==2058==by 0x42C973: PyUnicodeUCS2_FromString (unicodeobject.c:559)
==2058==by 0x50B432: PyDict_SetItemString (dictobject.c:2088)
==2058==by 0x4258DF: PyType_Ready (typeobject.c:3844)
==2058==by 0x517B64: PyStructSequence_InitType (structseq.c:522)
==2058==by 0x4F3B4F: _PyFloat_Init (floatobject.c:1905)
==2058==by 0x4813CE: Py_InitializeEx (pythonrun.c:217)

--
components: Interpreter Core
messages: 119226
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Memory leak (r70459)
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue10157] Memory leak (r70152)

[Stefan Krah]

New submission from Stefan Krah :

This is one of two remaining "definitely lost" leaks in py3k. It first
appeared in r70152. How to reproduce:

make distclean && ./configure OPT="-O0 -g" --without-pymalloc && make

valgrind --leak-check=full --suppressions=Misc/valgrind-python.supp ./python > 
VGOUT 2>&1

Then search for 'definitely'. This leak is not present in release-2.7.


==25233== 106 (56 direct, 50 indirect) bytes in 1 blocks are definitely lost in 
loss record 1,432 of 2,121
==25233==at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==25233==by 0x4167AE: _PyObject_New (object.c:243)
==25233==by 0x42C1C4: _PyUnicode_New (unicodeobject.c:341)
==25233==by 0x430562: PyUnicodeUCS2_DecodeUTF8Stateful 
(unicodeobject.c:2036)
==25233==by 0x430516: PyUnicodeUCS2_DecodeUTF8 (unicodeobject.c:2001)
==25233==by 0x479F81: r_object (marshal.c:726)
==25233==by 0x47A03E: r_object (marshal.c:745)
==25233==by 0x47A720: r_object (marshal.c:873)
==25233==by 0x47AF4B: PyMarshal_ReadObjectFromString (marshal.c:1053)
==25233==by 0x47AE2A: PyMarshal_ReadLastObjectFromFile (marshal.c:1012)
==25233==by 0x471C5B: read_compiled_module (import.c:823)
==25233==by 0x47230C: load_source_module (import.c:1043)

--
assignee: amaury.forgeotdarc
components: Interpreter Core
messages: 119227
nosy: amaury.forgeotdarc, benjamin.peterson, pitrou, skrah
priority: normal
severity: normal
status: open
title: Memory leak (r70152)
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue10157] Memory leak (r70152)

[Stefan Krah]

Changes by Stefan Krah :


--
assignee: amaury.forgeotdarc -> 

___
Python tracker 

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

[issue10121] test_multiprocessing stuck in test_make_pool if run in a loop

[Sandro Tosi]

Sandro Tosi  added the comment:

just for the reference, the loop I ran was:

 while date ; do ./python Lib/test/regrtest.py -v test_multiprocessing ; done

--

___
Python tracker 

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

[issue10157] Memory leak (r70152)

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +haypo

___
Python tracker 

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

[issue10156] Memory leak (r70459)

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +haypo

___
Python tracker 

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

[issue10149] Data truncation in expat parser

[Maciek J]

Maciek J  added the comment:

Hm... It turns out that there is a "buffer_text" attribute:
http://docs.python.org/library/pyexpat.html#xml.parsers.expat.xmlparser.buffer_text
And setting this attribute to "True" seems to solve the problem.

It solves my problem, but docs are still very confusing. I see two things that 
should be fixed:
1. In CharacterDataHandler description it should be explicitly noted that data 
may be chunked even if it is short(!).
2. Description of buffer_text attribute should contain a notice that data may 
also be arbitrary chunked if this is set to False. My data _was_not_ chunked at 
new line characters (as the description suggest). It was chunked in the middle 
of a sentence (there were no whitespace in it!).

--

___
Python tracker 

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

[issue10149] Data truncation in expat parser

[R. David Murray]

Changes by R. David Murray :


--
assignee:  -> d...@python
components: +Documentation -XML
nosy: +d...@python
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

___
Python tracker 

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

[issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

[David Watson]

David Watson  added the comment:

I was looking at the MSDN pages linked to above, and these two
pages seemed to suggest that Unicode characters appearing in DNS
names represented UTF-8 sequences, and that Windows allowed such
non-ASCII byte sequences in the DNS by default:

http://msdn.microsoft.com/en-us/library/ms724220%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms682032%28v=VS.85%29.aspx

(See the discussion of DNS_ERROR_NON_RFC_NAME in the latter.)
Can anyone confirm if this is the case?

The BSD-style gethostname() function can't be returning UTF-8,
though, or else the "Nötkötti" example above would have been
decoded successfully, given that Python currently uses
PyUnicode_FromString().

Also, if GetComputerNameEx() only offers a choice of DNS names or
NetBIOS names, and both are byte-oriented underneath (that was my
reading of the "Computer Names" page), then presumably there
shouldn't be a problem with mapping the result to a bytes
equivalent when necessary?

--

___
Python tracker 

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

[issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Also, if GetComputerNameEx() only offers a choice of DNS names or
> NetBIOS names, and both are byte-oriented underneath (that was my
> reading of the "Computer Names" page), then presumably there
> shouldn't be a problem with mapping the result to a bytes
> equivalent when necessary?

They aren't byte-oriented underneath.It depends on whether use
GetComputerNameA or GetComputerNameW whether you get bytes or Unicode.
If bytes, they are converted as if by WideCharToMultiByte using
CP_ACP, which in turn will introduce question marks and the like
for unconvertable characters.

--
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names -> 
socket,  PEP 383: Mishandling of non-ASCII bytes in host/domain names

___
Python tracker 

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

[issue1467929] %-formatting and dicts

[Vetoshkin Nikita]

Changes by Vetoshkin Nikita :


Removed file: http://bugs.python.org/file19271/issue1467929_py3k.diff

___
Python tracker 

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

[issue1467929] %-formatting and dicts

[Vetoshkin Nikita]

Vetoshkin Nikita  added the comment:

Updated patch: some tests added.

--
Added file: http://bugs.python.org/file19307/issue1467929_py3k.diff

___
Python tracker 

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

[issue10158] BadInternalCall running test_multiprocessing

[Bob Halley]

New submission from Bob Halley :

For reasons not germane to this bug report, I was running a modified Python 2.7 
where PyTrash_UNWIND_LEVEL in Include/object.h had been defined to 10 instead 
of 50.

With such a python, running test_multiprocessing causes a BadInternalCall to be 
triggered at line 903 of weakrefobject.c.

test_finalize (__main__.WithProcessesTestFinalize) ... Process Process-18:
Traceback (most recent call last):
  File "/Users/halley/src/release27-maint/Lib/multiprocessing/process.py", line 
229, in _bootstrap
util._run_after_forkers()
  File "/Users/halley/src/release27-maint/Lib/multiprocessing/util.py", line 
125, in _run_after_forkers
items = list(_afterfork_registry.items())
  File "/Users/halley/src/release27-maint/Lib/weakref.py", line 116, in items
for key, wr in self.data.items():
SystemError: Objects/weakrefobject.c:903: bad argument to internal function

I'm running the head of the release27-maint branch, but the problem occurs with 
the released 2.7 too.

The trigger for the error is that object->ob_refcount is 1.

I stuck an abort() into the code just before the BadInternalCall, and looked at 
the core.  The ob_type is a Semaphore, and the last bit of the call chain is:

(gdb) bt
#0  0x7fff8791c3d6 in __kill ()
#1  0x7fff879bc972 in abort ()
#2  0x00010007eb05 in PyObject_ClearWeakRefs (object=) at Objects/weakrefobject.c:903
#3  0x00010006c949 in subtype_dealloc (self=0x10070a150) at 
Objects/typeobject.c:952
#4  0x00010005341b in _PyTrash_destroy_chain () at Objects/object.c:2435
#5  0x00010003bfaf in listiter_next (it=0x1006db8d0) at 
Objects/listobject.c:2917
#6  0x0001000b9f16 in PyEval_EvalFrameEx (f=0x1013b91a0, throwflag=) at Python/ceval.c:2496
#7  0x0001000c0966 in PyEval_EvalFrameEx (f=0x1013bcc40, throwflag=) at Python/ceval.c:4098
#8  0x0001000c0966 in PyEval_EvalFrameEx (f=0x10137a500, throwflag=) at Python/ceval.c:4098
#9  0x0001000c0966 in PyEval_EvalFrameEx (f=0x101374aa0, throwflag=) at Python/ceval.c:4098
#10 0x0001000c1826 in PyEval_EvalCodeEx (co=0x10065d1b0, globals=, locals=, args=0x100708458, argcount=2, kws=0x0, 
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#11 0x000100037580 in function_call (func=0x100678488, arg=0x100708440, 
kw=0x0) at Objects/funcobject.c:526
#12 0x000163e2 in PyObject_Call (func=0x100678488, arg=0x100708440, 
kw=0x0) at Objects/abstract.c:2529
#13 0x0001000177bd in instancemethod_call (func=0x100678488, 
arg=0x100708440, kw=0x0) at Objects/classobject.c:2578
#14 0x000163e2 in PyObject_Call (func=0x100704780, arg=0x1006f17d0, 
kw=0x0) at Objects/abstract.c:2529
#15 0x000100071a38 in slot_tp_init (self=, args=0x1006f17d0, kwds=0x0) at Objects/typeobject.c:5651
#16 0x00010006ee75 in type_call (type=0x10130bd10, args=0x1006f17d0, 
kwds=0x0) at Objects/typeobject.c:726
#17 0x000163e2 in PyObject_Call (func=0x10130bd10, arg=0x1006f17d0, 
kw=0x0) at Objects/abstract.c:2529

Note that the trashcan function _PyTrash_destroy_chain() is involved.

I don't understand this code well enough to have figured out what's going wrong 
yet.  I worry that there's some subtle interaction with weakrefs, subtyped 
objects, and the trashcan, but maybe it's something simpler!

Regards,

/Bob

--
components: Interpreter Core
messages: 119233
nosy: rthalley
priority: normal
severity: normal
status: open
title: BadInternalCall running test_multiprocessing
type: crash
versions: Python 2.7

___
Python tracker 

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

[issue10157] Memory leak (r70152)

[Stefan Krah]

Stefan Krah  added the comment:

I tracked it down to r68683, which is still a large commit.

--

___
Python tracker 

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

[issue10152] symtable.c: ste_tmpname uninitialized

[Benjamin Peterson]

Benjamin Peterson  added the comment:

r85757

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

___
Python tracker 

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

[issue10158] BadInternalCall running test_multiprocessing

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> jnoller
nosy: +jnoller

___
Python tracker 

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

[issue10154] locale.normalize strips "-" from UTF-8, which fails on Mac

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren  added the comment:
> 
> This patch solves the immediate failure:
> 
> Index: Lib/locale.py
> ===
> --- Lib/locale.py (revision 85743)
> +++ Lib/locale.py (working copy)
> @@ -396,6 +396,9 @@
>  else:
>  encoding = defenc
>  #print 'found encoding %r' % encoding
> +if sys.platform == 'darwin' and encoding == 'UTF8':
> +encoding = 'UTF-8'
> +
>  if encoding:
>  return langname + '.' + encoding
>  else:
> 
> I'm not happy about hardcoding this specific exception though, there should 
> be a better solution than this.

Could you tell me the values of localename, code, langname and encoding
at that step in the process ?

We may need to add an locale_encoding_alias from 'UTF8' to 'UTF-8',
since the version with the hyphen is what the C lib uses.

--
nosy: +lemburg
title: locale.normalize strips "-" from UTF-8, which fails on Mac -> 
locale.normalize strips "-" from UTF-8,which fails on Mac

___
Python tracker 

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

[issue10156] Memory leak (r70459)

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The stack corresponds to the allocation of type(sys.float_info).__doc__.

Why would only this object appear as a memory leak?  It is certainly not 
deallocated, but all other types are in the same situation.
For example, sys.int_info is very similar, and happens to be defined in r70459. 
Why doesn't it appear in the report?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue10156] Memory leak (r70459)

[Stefan Krah]

Stefan Krah  added the comment:

To add to the mystery, the leak disappears if the key value is not
interned in PyDict_SetItemString:


Index: Objects/dictobject.c
===
--- Objects/dictobject.c(revision 70459)
+++ Objects/dictobject.c(working copy)
@@ -2088,7 +2088,6 @@
kv = PyUnicode_FromString(key);
if (kv == NULL)
return -1;
-   PyUnicode_InternInPlace(&kv); /* XXX Should we really? */
err = PyDict_SetItem(v, kv, item);
Py_DECREF(kv);
return err;

--

___
Python tracker 

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

[issue10156] Memory leak (r70459)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Stefan Krah wrote:
> 
> Stefan Krah  added the comment:
> 
> To add to the mystery, the leak disappears if the key value is not
> interned in PyDict_SetItemString:

I'm not sure how you determine what is a leak and what not.
Interned Unicode objects stay alive until the interpreter
is finalized.

Are you suggesting that the finalization does not free the
interned Unicode strings or not all of them ?

> Index: Objects/dictobject.c
> ===
> --- Objects/dictobject.c(revision 70459)
> +++ Objects/dictobject.c(working copy)
> @@ -2088,7 +2088,6 @@
> kv = PyUnicode_FromString(key);
> if (kv == NULL)
> return -1;
> -   PyUnicode_InternInPlace(&kv); /* XXX Should we really? */
> err = PyDict_SetItem(v, kv, item);
> Py_DECREF(kv);
> return err;

--
nosy: +lemburg

___
Python tracker 

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

[issue10159] rlcompleter's tests depend on dict order

[Andreas Stührk]

New submission from Andreas Stührk :

Some tests in test_rlcompleter make assumptions about the order of the list of 
names that the completion methods of a Completer object return. That order is 
not guaranteed and will break when running the tests under e.g. PyPy.

The attached patch against py3k branch tries to fix that.

--
components: Tests
files: test_rlcompleter_order.patch
keywords: patch
messages: 119240
nosy: Trundle
priority: normal
severity: normal
status: open
title: rlcompleter's tests depend on dict order
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19308/test_rlcompleter_order.patch

___
Python tracker 

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

[issue10156] Memory leak (r70459)

[Stefan Krah]

Stefan Krah  added the comment:

Marc-Andre Lemburg  wrote:
> I'm not sure how you determine what is a leak and what not.
> Interned Unicode objects stay alive until the interpreter
> is finalized.
> 
> Are you suggesting that the finalization does not free the
> interned Unicode strings or not all of them ?

No, Valgrind's "definitely lost" category means that all pointers
to an allocated region have been lost, so it would not be possible
to free the area. [1]

There are hundreds of "possibly lost" warnings as well, but I did
not report those.

My experience is that Valgrind is usually correct with "definitely
lost", see e.g. #10153. That said, of course it _could_ be a false
alarm.

[1] Last category from:

   http://mail.python.org/pipermail/python-dev/2002-October/029758.html

--

___
Python tracker 

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

[issue4388] test_cmd_line fails on MacOS X

[STINNER Victor]

STINNER Victor  added the comment:

I commited my patch to Python 3.2 (r85765), with a specific test in 
test_cmd_line. Reopen the issue if the bug is not fixed.

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

___
Python tracker 

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

[issue10159] rlcompleter's tests depend on dict order

[Ned Deily]

Ned Deily  added the comment:

The patch looks good to me.

--
nosy: +ned.deily, pitrou
stage:  -> patch review

___
Python tracker 

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

[issue10155] Add fixups for encoding problems to wsgiref

[And Clover]

And Clover  added the comment:

(same again for branch PJ Eby's wsgiref svn: same as previous 2.7 patch aside 
from the line numbers)

--
Added file: http://bugs.python.org/file19309/wsgiref-patches-eby2692.patch

___
Python tracker 

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

[issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

[David Watson]

David Watson  added the comment:

> > Also, if GetComputerNameEx() only offers a choice of DNS names or
> > NetBIOS names, and both are byte-oriented underneath (that was my
> > reading of the "Computer Names" page), then presumably there
> > shouldn't be a problem with mapping the result to a bytes
> > equivalent when necessary?
> 
> They aren't byte-oriented underneath.It depends on whether use
> GetComputerNameA or GetComputerNameW whether you get bytes or Unicode.
> If bytes, they are converted as if by WideCharToMultiByte using
> CP_ACP, which in turn will introduce question marks and the like
> for unconvertable characters.

Sorry, I didn't mean how Windows constructs the result for the
"A" interface - I was talking about Python code being able to map
the result from the Unicode interface to the form used in the
protocol (e.g. DNS).  I believe the proposal is to use the DNS
name, so since the DNS is byte oriented, I would have thought
that the Unicode "DNS name" result would always have a bytes
equivalent that the DNS resolver code would use - perhaps its
UTF-8 encoding?

--
title: socket,  PEP 383: Mishandling of non-ASCII bytes in host/domain names -> 
socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

___
Python tracker 

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

[issue10158] BadInternalCall running test_multiprocessing

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Does it happen when compiled in debug mode? There may be asserts that will give 
a better (or earlier) error message.

Some thoughts: the '_PyTrash_delete_later' chain can only contain a limited set 
of objects: lists, frames... (which code contain the Py_TRASHCAN_SAFE_BEGIN 
macro)... and the stack dumps suggests (subtype_dealloc) that it is also an 
instance of a user-defined class.  The only candidate I see is the class 
'multiprocessing.managers.ProcessLocalSet', which inherits from 'set'.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue10155] Add fixups for encoding problems to wsgiref

[Ned Deily]

Changes by Ned Deily :


--
nosy: +pje

___
Python tracker 

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

[issue10160] operator.attrgetter slower than lambda after adding dotted names ability

[Christos Georgi ou]

New submission from Χρήστος Γεωργίου (Christos Georgiou) 
:

(Discovered in that StackOverflow answer: 
http://stackoverflow.com/questions/3940518/3942509#3942509 ; check the comments 
too)

operator.attrgetter in its simplest form (i.e. with a single non-dotted name) 
needs more time to execute than an equivalent lambda expression.

Attached file so3940518.py runs a simple benchmark comparing: a list 
comprehension of plain attribute access; attrgetter; and lambda. I will append 
sample benchmark times at the end of the comment.

Browsing Modules/operator.c, I noticed that the dotted_getattr function was 
using PyUnicode_Check and (possibly) splitting on dots on *every* call of the 
attrgetter, which I thought to be most inefficient.

I changed the py3k-daily-snapshot source to make the PyUnicode_Check calls in 
the attrgetter_new function; also, I modified the algorithm to pre-parse the 
operator.attrgetter functions for possible dots in the names, in order for the 
dotted_getattr function to become speedier.

The only “drawback” is that now operator.attrgetter raises a TypeError on 
creation, not on subsequent calls of the attrgetter object; this shouldn't be a 
compatibility problem. However, I obviously had to update both 
Doc/library/operator.rst and Lib/test/test_operator.py .

I am not sure whether I should attach a zip/tar file with both the attachments 
(the sample benchmark and the diff); so I'll attach the diff in a further 
comment.

On the Ubuntu server 9.10 where I made the changes, I ran the so3940518.py 
sample benchmark before and after the changes.

Run before the changes (third column is seconds, less is better):

list comp 0.40925 100
map attrgetter 1.3897 100
map lambda 1.0098 100

Run after the changes:

list comp 0.40036 100
map attrgetter 0.5196 100
map lambda 0.96 100

--
assignee: d...@python
components: Documentation, Library (Lib), Tests
files: so3940518.py
messages: 119247
nosy: d...@python, tzot
priority: normal
severity: normal
status: open
title: operator.attrgetter slower than lambda after adding dotted names ability
versions: Python 3.2
Added file: http://bugs.python.org/file19310/so3940518.py

___
Python tracker 

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

[issue10161] unittest: use ascii() instead of repr() to display values on error

[STINNER Victor]

New submission from STINNER Victor :

On a failure, unittest does its best to display values. But sometimes, the 
output doesn't help me. Example:

FAIL: test_listdir (test.test_pep277.UnicodeFileTests)
--
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_pep277.py", 
line 157, in test_listdir
self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_18608_tmp/ ̈́ΎΫ'
'@test_18608_tmp/ẛ῁῍῎῏῝῞῟῭'
Items in the second set but not the first:
'@test_18608_tmp/ ̈́ΥΎ̈'
'@test_18608_tmp/ẛ῁῍῎᾿῾῾῾῁̀́͂̀'
'@test_18608_tmp/΅ϒϓ̈'

This is a test on unicode filenames. I would prefer to see non-ASCII characters 
as \xHH or \u than strange characters or boxes.

Do you think that it is a good idea to replace calls to repr() by ascii() in 
the unittest library?

In Python2, repr(unicode) escapes all non-ASCII characters. But in Python3, 
only control characters and surrogates are escaped. So the output depends on 
the terminal encoding.

Write non-ASCII characters in a backtrace may also raise a new error if the 
terminal is unable to a character. Raise an error while printing an error is 
just horrible :-)

--

Attached patch is a try to replace repr() by ascii() in the unittest module. 
But I don't know this library, so don't trust the patch :-)

--
components: Library (Lib), Unicode
files: unittest_ascii.patch
keywords: patch
messages: 119248
nosy: haypo
priority: normal
severity: normal
status: open
title: unittest: use ascii() instead of repr() to display values on error
versions: Python 3.2
Added file: http://bugs.python.org/file19311/unittest_ascii.patch

___
Python tracker 

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

[issue10160] operator.attrgetter slower than lambda after adding dotted names ability

[Christos Georgi ou]

Χρήστος Γεωργίου (Christos Georgiou)  added the 
comment:

Here comes the diff to Modules/operator.c, Doc/library/operator.rst and 
Lib/test/test_operator.py . As far as I could check, there are no leaks, but a 
more experienced eye in core development could not hurt. Also, obviously 
test_operatory.py passes all tests.

Should this be accepted, I believe it should be backported to 2.7 (at least). I 
can do that, just let me know.

--
keywords: +patch
Added file: http://bugs.python.org/file19312/issue10160.diff

___
Python tracker 

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

[issue10160] operator.attrgetter slower than lambda after adding dotted names ability

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee: d...@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue10160] operator.attrgetter slower than lambda after adding dotted names ability

[Christos Georgi ou]

Changes by Χρήστος Γεωργίου (Christos Georgiou) :


Removed file: http://bugs.python.org/file19312/issue10160.diff

___
Python tracker 

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

[issue10160] operator.attrgetter slower than lambda after adding dotted names ability

[Christos Georgi ou]

Χρήστος Γεωργίου (Christos Georgiou)  added the 
comment:

Newer version of the diff, since I forgot some "if(0) fprintf" debug calls that 
shouldn't be there.

--
Added file: http://bugs.python.org/file19313/issue10160.diff

___
Python tracker 

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

[issue10160] operator.attrgetter slower than lambda after adding dotted names ability

[Christos Georgi ou]

Χρήστος Γεωργίου (Christos Georgiou)  added the 
comment:

An explanation to the changes.

The old code kept the operator.itemgetter arguments in the ag->attr member. If 
the argument count (ag->nattrs) was 1, the single argument was kept; if more 
than 1, a tuple of the original arguments was kept.

On every attrgetter_call call, if ag->nattrs was 1, dotted_getattr was called 
with the plain ag->attr as attribute name; if > 2, dotted_getattr was called 
for every one of the original arguments.

Now, ag->attr is always a tuple, containing either dotless strings or tuples of 
dotless strings:

operator.attrgetter("name1", "name2.name3", "name4")

stores ("name1", ("name2", "name3"), "name4") in ag->attr.

dotted_getattr accordingly chooses based on type (either str or tuple, ensured 
by attrgetter_new) whether to do a single access or a recursive one.

--

___
Python tracker 

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

[issue7828] chr() and ord() documentation for wide characters

[STINNER Victor]

Changes by STINNER Victor :


--
components: +Unicode

___
Python tracker 

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

[issue10162] mimetypes read_windows_registry should tolerate permissions errors

[And Clover]

New submission from And Clover :

It is relatively common to have keys in the HKEY_CLASSES_ROOT MIME database 
that are not readable to all users, typically written by third-party 
applications. (My WinXP test box has a dozen, for apps like Flash, Silverlight 
and Java.)

Currently, initialising mimetypes causes Python to try to read them all, and if 
the user running Python doesn't have permission to read a key (in particular, 
if the user is a low-privilege daemon user such as IUSR_...), the script that 
caused mimetypes to be called will error out.

This patch moves the try-block around the call to OpenKey as well as 
QueryValueEx, allowing the key to be skipped if unreadable.

--
components: Library (Lib)
files: mimetypes-patch-3.2a3.patch
keywords: patch
messages: 119252
nosy: aclover
priority: normal
severity: normal
status: open
title: mimetypes read_windows_registry should tolerate permissions errors
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file19314/mimetypes-patch-3.2a3.patch

___
Python tracker 

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

[issue10162] mimetypes read_windows_registry should tolerate permissions errors

[And Clover]

And Clover  added the comment:

(same against 2.7 branch)

--
Added file: http://bugs.python.org/file19315/mimetypes-patch-2.7.patch

___
Python tracker 

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

[issue9167] argv double encoding on OSX

[STINNER Victor]

STINNER Victor  added the comment:

I just closed #4388 with r85765 (Python 3.2): always use UTF-8 to decode the 
command line arguments on Mac OS X, not the locale encoding.

I suppose that it does fix this issue. Can someone check that?

--

___
Python tracker 

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

[issue8776] Bytes version of sys.argv

[STINNER Victor]

STINNER Victor  added the comment:

Since r85765 (issue #4388), always use UTF-8 to decode the command line 
arguments on Mac OS X, not the locale encoding. Which means that the 
pseudo-code becomes:

 if os.name != 'nt':
 if sys.platform == 'darwin':
encoding = 'utf-8'
 else:
encoding = locale.getpreferredencoding()
 sys.argvb = [arg.decode(encoding, 'surrogateescape') for arg in sys.argv]

sys.argvb should be synchronized with sys.argv, as os.environb with os.environ.

--

___
Python tracker 

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

[issue10142] Support for SEEK_HOLE/SEEK_DATA

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Jesús, can you attach a patch (with the appropriate #ifdefs)?

--

___
Python tracker 

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

[issue10092] calendar does not restore locale properly

[Boštjan Mejak]

Boštjan Mejak  added the comment:

Please respond...

On Wed, Oct 20, 2010 at 7:05 PM, Boštjan Mejak wrote:

>
> Boštjan Mejak  added the comment:
>
> Thank you so much for your answer. The
> locale.setlocale(category=locale.LC_NUMERIC,
> locale="Slovenian")  works like a charm in my application. Now the 'n'
> format specifier works as I want. But tell me whether the 'n' format
> specifier can be forced to round the float to just one decimal place. I
> know
> that the 'f' format specifier does that by specifying ".1f", but 'f' is not
> locale-aware. I have set the 'n' format specifier in my application like
> ".3n", which is okay if the returned number is two integers and one
> decimal,
> but is not okay if the returned number is one integer and two decimals,
> because I want just one decimal, always. How can I make that by using the
> 'n' format specifier?
>
> On Wed, Oct 20, 2010 at 11:37 AM, Tim Golden 
> wrote:
>
> >
> > Tim Golden  added the comment:
> >
> > Boštjan, the code segment you quote is the *fallback* if the
> > C module hasn't been built for some reason. The module simply
> > calls through to the underlying C Library. I notice you're
> > running on Windows, so this is a useful MS page:
> >
> > http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx
> >
> > and you can see there that a call of setlocale (LC_ALL, "English")
> > is valid (of "French" if you prefer):
> >
> > Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
> > (Intel)] on win32
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import locale
> > >>> locale.setlocale (locale.LC_ALL, "French")
> > 'French_France.1252'
> > >>>
> >
> > --
> > nosy: +tim.golden
> >
> > ___
> > Python tracker 
> > 
> > ___
> >
>
> --
> Added file: http://bugs.python.org/file19306/unnamed
>
> ___
> Python tracker 
> 
> ___
>

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

___
Python tracker 

___Please respond...On Wed, Oct 20, 2010 at 7:05 
PM, Boštjan Mejak rep...@bugs.python.org> 
wrote:

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

Thank you so much for your answer. The
locale.setlocale(category=locale.LC_NUMERIC,
locale="Slovenian")  works like a charm in my application. Now the 
'n'
format specifier works as I want. But tell me whether the 'n' format
specifier can be forced to round the float to just one decimal place. I know
that the 'f' format specifier does that by specifying ".1f", 
but 'f' is not
locale-aware. I have set the 'n' format specifier in my application 
like
".3n", which is okay if the returned number is two integers and one 
decimal,
but is not okay if the returned number is one integer and two decimals,
because I want just one decimal, always. How can I make that by using the
'n' format specifier?

On Wed, Oct 20, 2010 at 11:37 AM, Tim Golden rep...@bugs.python.org> wrote:

>
> Tim Golden m...@timgolden.me.uk> added the 
comment:
>
> Boštjan, the code segment you quote is the *fallback* if the
> C module hasn't been built for some 
reason. The module simply
> calls through to the underlying C Library. I notice you're
> running on Windows, so this is a useful MS page:
>
> http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx"; 
target="_blank">http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx
>
> and you can see there that a call of setlocale (LC_ALL, 
"English")
> is valid (of "French" if you prefer):
>
> Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or 
"license" for more information.
> >>> import locale
> >>> locale.setlocale (locale.LC_ALL, "French")
> 'French_France.1252'
> >>>
>
> --
> nosy: +tim.golden
>
> ___
> Python tracker rep...@bugs.python.org>
> http://bugs.python.org/issue10092>
> ___
>

--
Added file: http://bugs.python.org/file19306/unnamed"; 
target="_blank">http://bugs.python.org/file19306/unnamed

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue10092>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/pyth

[issue10160] operator.attrgetter slower than lambda after adding dotted names ability

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for noticing this.  I wasn't aware that it had slowed down after dotted 
name support had been added.

Since it is a mild performance issue, I'm lowering the priority.  Will take a 
further look when I get the chance.  A first look at the patch shows that it is 
bigger than I expected.  Isn't it possible to check for a dot on construction 
and just record the boolean so that a fast, non-splitting path can be used.

I'm reluctant to make the code volume grow much for this function.  It is 
already a bit voluminous for the minor convenience it offers.

--
priority: normal -> low
stage:  -> patch review
type:  -> performance

___
Python tracker 

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

[issue10158] BadInternalCall running test_multiprocessing

[R. David Murray]

Changes by R. David Murray :


--
nosy: +asksol

___
Python tracker 

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

[issue10092] calendar does not restore locale properly

[R. David Murray]

R. David Murray  added the comment:

The bug tracker is not an appropriate place to get help on using Python.  
Please ask your question on a forum where you are more likely to get help, such 
as python-list.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue10155] Add fixups for encoding problems to wsgiref

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
nosy: +orsenthil

___
Python tracker 

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

[issue9022] TypeError in wsgiref.handlers when using CGIHandler

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
nosy: +orsenthil

___
Python tracker 

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

[issue10162] mimetypes read_windows_registry should tolerate permissions errors

[Ned Deily]

Changes by Ned Deily :


--
components: +Windows
nosy: +brian.curtin, tim.golden

___
Python tracker 

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

[issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Sorry, I didn't mean how Windows constructs the result for the
> "A" interface - I was talking about Python code being able to map
> the result from the Unicode interface to the form used in the
> protocol (e.g. DNS).  I believe the proposal is to use the DNS
> name

I disagree with the proposal - it should return whatever
name gethostname from winsock.dll returns (which I expect
to be the netbios name).

> so since the DNS is byte oriented, I would have thought
> that the Unicode "DNS name" result would always have a bytes
> equivalent that the DNS resolver code would use - perhaps its
> UTF-8 encoding?

No no no. When Microsoft calls it the DNS name, they don't actually
mean that it has to do anything with DNS. In particular, it's not
byte-oriented.

--
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names -> 
socket,  PEP 383: Mishandling of non-ASCII bytes in host/domain names

___
Python tracker 

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

[issue10160] operator.attrgetter slower than lambda after adding dotted names ability

[Alex]

Alex  added the comment:

Voice of ignorance here: why can't this be implemented in the "naive" way one 
might in Python, use the existing string splitting algorithms of stringlib, but 
just leave it in __new__.

--
nosy: +alex

___
Python tracker 

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

[issue9167] argv double encoding on OSX

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Thank you. I'll check, but probably only sometime next week.

--

___
Python tracker 

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

[issue4111] Add Systemtap/DTrace probes

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I've the same question as Jesús Cea Avión: what is needed to get this in 3.2?  
This would IMHO be a useful feature.

--

___
Python tracker 

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

[issue10160] operator.attrgetter slower than lambda after adding dotted names ability

[Christos Georgi ou]

Χρήστος Γεωργίου (Christos Georgiou)  added the 
comment:

Modules/operator.c grows by ~70 lines, most of it the setup code for ag->attr; 
also I loop twice over the args of attrgetter_new, choosing fast code that runs 
once per attrgetter creation than temporary data.

Alex's suggestion to make use of Python-level functions to shorten the code of 
attrgetter_new could obviously work to decrease the source lines. I don't know 
how fast I would produce such a version if requested, though.

Whatever the way attrgetter_new sets up the data, I would suggest that you keep 
the logic changes in general, i.e. set-up in attrgetter_new and keep a thinner 
dotted_getattr , since it avoids running the same checks and splitting over and 
over again for every attrgetter_call invocation.

--

___
Python tracker 

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