[issue6632] Include more fullwidth chars in the decimal codec

[Antoine Pitrou]

Antoine Pitrou  added the comment:

On the specific point of:

>   2.1 some languages/alphabets use other chars (e.g. a comma or other
>   symbols) instead of the decimal point.

I think it's not the job of the float() constructor to support it.
Depending on the country, the comma has different meanings when put in a
number (thousands separator or decimal separator). Ditto for the point,
but using a point as decimal separator is the accepted standard for
non-localized computer I/O.

More generally, I think the fact that int(), float() et al. support
non-ASCII decimal digits should be seen as a convenience rather than a
willingness to accomodate the broadest set possible of inputs. Which
means, we should only add support for new formats only if it's sensible,
safe and non-ambiguous to do so.

I also agree with Marc-André's argument that the Unicode spec should be
a good guide here.

--
nosy: +pitrou

___
Python tracker 

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

[issue6645] multiprocessing build fails on AIX - /dev/urandom (or equivalent) not found

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> jnoller
nosy: +jnoller
priority:  -> normal
stage:  -> needs patch
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

[issue5737] add Solaris errnos

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Martin, what do you think?

--
nosy: +loewis, pitrou

___
Python tracker 

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

[issue6603] Compilation error if configuref --with-computed-gotos

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I can't reproduce here (using gcc 4.3.2). Have you tried `make
distclean`? Is it a fresh checkout?

--
nosy: +pitrou

___
Python tracker 

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

[issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed

[Antoine Pitrou]

Antoine Pitrou  added the comment:

If your patch really fixes the issue, it is probably a compiler problem.
Does IBM have a user group or support line to which you can take this?

--
nosy: +pitrou

___
Python tracker 

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

[issue6594] json C serializer performance tied to structure depth on some systems

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm not sure there's anything we should do about this. Some
architectures are unreasonably slow at some things, and the old SPARC
implementations are a niche nowadays. I suppose you may witness the same
kinds of slowdowns if you use cPickle rather than json.

(I'm looking for the "abysmally low" priority setting :-))

--
assignee:  -> bob.ippolito
nosy: +bob.ippolito, pitrou
versions: +Python 2.7, Python 3.2 -Python 2.6

___
Python tracker 

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

[issue1436346] yday in datetime module

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Some comments:
- since there is already a weekday() method, the new method should be
called yearday() rather than yday()
- ditto for fromyday(): fromyearday() would be better
- Modules/datetimemodule.c should only be indented with tabs, but your
patch indents it with spaces in some places
- the algorithm in date_fromyday() looks suboptimal: if you repeatedly
call days_in_month(), you shouldn't have to call days_before_month() at
the end, you can compute it by yourself

I haven't tested the patch yet.

Marc-André, do you have any take on the principle of this?

--
nosy: +lemburg
stage: test needed -> patch review

___
Python tracker 

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

[issue4997] xml.sax.saxutils.XMLGenerator should write to io.RawIOBase.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

You shouldn't remove the defaulting behaviour for `out`, but use
`sys.stdout.buffer` instead.

Bonus points if you add a test so that this kind of bug doesn't go
unnoticed again.

PS: it's ironic that the default encoding here is iso-8859-1. This piece
of code is really getting old.

--
nosy: +pitrou

___
Python tracker 

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

[issue6501] Fatal LookupError: unknown encoding: cp0 on Windows embedded startup.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Graham, is the workaround ok for you or do you think this is something
Python itself should handle?

--
nosy: +pitrou

___
Python tracker 

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

[issue1524938] PEP MemoryError with a lot of available memory gc not called

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm not sure what we should do anyway. Your program will first swap out
and thrash before the MemoryError is raised. Invoking the GC when memory
allocation fails would avoid the MemoryError, but not the massive
slowdown due to swapping.

--

___
Python tracker 

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

[issue1436346] yday in datetime module

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou  added the comment:
> 
> Some comments:
> - since there is already a weekday() method, the new method should be
> called yearday() rather than yday()
> - ditto for fromyday(): fromyearday() would be better
> - Modules/datetimemodule.c should only be indented with tabs, but your
> patch indents it with spaces in some places
> - the algorithm in date_fromyday() looks suboptimal: if you repeatedly
> call days_in_month(), you shouldn't have to call days_before_month() at
> the end, you can compute it by yourself
> 
> I haven't tested the patch yet.
> 
> Marc-André, do you have any take on the principle of this?

mxDateTime uses attributes for such things, ie. .day_of_week,
.day_of_year, .days_in_month. No idea, why the datetime module
chose to implement access to this static information as method.

I've never had a request for a way to construct a date by
giving the year and day of the year - probably because it's
just too easy to do by hand:

217
>>> Date(2009, 1, 1) + (217 - 1)


--

___
Python tracker 

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

[issue1436346] yday in datetime module

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Hmm, looks like there's a bug in roundup's email interface... the code
snippet should have read:

>>> from mx.DateTime import *
>>> today().day_of_year
217
>>> Date(2009, 1, 1) + (217 - 1)


--

___
Python tracker 

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

[issue6625] UnicodeEncodeError on pydoc's CLI

[Christoph Burgmer]

Christoph Burgmer  added the comment:

Here is a diff for test/test_pydoc.py (against Python2.6) which though
doesn't trigger due to how Python handles output encoding. This test
here will pass, but pydoc will still fail:

$ pydoc test/pydoc_mod.py > /dev/null
Traceback (most recent call last):
  File "/usr/bin/pydoc", line 5, in 
pydoc.cli()
  File "/usr/lib/python2.5/pydoc.py", line 2226, in cli
help.help(arg)
  File "/usr/lib/python2.5/pydoc.py", line 1691, in help
else: doc(request, 'Help on %s:')
  File "/usr/lib/python2.5/pydoc.py", line 1482, in doc
pager(title % desc + '\n\n' + text.document(object, name))
  File "/usr/lib/python2.5/pydoc.py", line 1300, in pager
pager(text)
  File "/usr/lib/python2.5/pydoc.py", line 1398, in plainpager
sys.stdout.write(plain(text))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in
position 936: ordinal not in range(128)

--
Added file: 
http://bugs.python.org/file14656/pydoc_unicode_testcase_notworking.diff

___
Python tracker 

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

[issue6629] seek doesn't properly handle file buffer, leads to silent data corruption

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is an initial patch. Could you try it on your workload?

--
keywords: +patch
Added file: http://bugs.python.org/file14657/issue6629.patch

___
Python tracker 

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

[issue6501] Fatal LookupError: unknown encoding: cp0 on Windows embedded startup.

[Graham Dumpleton]

Graham Dumpleton  added the comment:

Python should be as robust as possible and thus should be fixed, but I am 
happy with using the workaround so if this is more a question of what 
priority to mark this, I wouldn't see it as being urgent.

--

___
Python tracker 

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

[issue6647] warnings.catch_warnings is not thread-safe

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Any function whose purpose is to mutate global (non thread-local) state
is inherently "thread-unsafe". The only reasonable possibility is to
document it as such.

--
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl, pitrou

___
Python tracker 

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

[issue6645] multiprocessing build fails on AIX - /dev/urandom (or equivalent) not found

[Jesse Noller]

Jesse Noller  added the comment:

Without access to an AIX machine, and even with it (I'm not an AIX guy by 
any stretch) it's going to be virtually impossible for me to fix this. A 
patch would be appreciated.

--

___
Python tracker 

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

[issue6629] seek doesn't properly handle file buffer, leads to silent data corruption

[Karoly Lorentey]

Karoly Lorentey  added the comment:

The patch does fix my issue, thank you.

--

___
Python tracker 

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

[issue6648] codecs documentation does not mention surrogateescape

[Nikolaus Rath]

New submission from Nikolaus Rath :

On http://docs.python.org/3.1/library/codecs.html it says that


Possible values for errors are 'strict' (raise an exception in case of
an encoding error), 'replace' (replace malformed data with a suitable
replacement marker, such as '?'), 'ignore' (ignore malformed data and
continue without further notice), 'xmlcharrefreplace' (replace with the
appropriate XML character reference (for encoding only)) and
'backslashreplace' (replace with backslashed escape sequences (for
encoding only)) as well as any other error handling name defined via
register_error().
-

shouldn't the 'surrogateescape' error handler from
http://docs.python.org/3.1/library/os.html#file-names-command-line-arguments-and-environment-variables
be mentioned here as well?

--
assignee: georg.brandl
components: Documentation
messages: 91321
nosy: Nikratio, georg.brandl
severity: normal
status: open
title: codecs documentation does not mention surrogateescape
type: behavior
versions: Python 3.1

___
Python tracker 

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

[issue6649] idlelib/rpc.py missing exit status on exithook

[Guilherme Polo]

New submission from Guilherme Polo :

SocketIO.exithook on idlelib/rpc.py is missing the exit status, this is
a minor issue since both client and server used on IDLE override this
method to do something else.

--
components: IDLE
files: missing_exitstatus.diff
keywords: patch
messages: 91322
nosy: gpolo
priority: low
severity: normal
status: open
title: idlelib/rpc.py missing exit status on exithook
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14658/missing_exitstatus.diff

___
Python tracker 

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

[issue2710] error: (10035, 'The socket operation could not complete without blocking')

[Guilherme Polo]

Guilherme Polo  added the comment:

I just tried writing tests for it, but I don't know idlelib/rpc.py
enough yet. You can see this first attempt at:
http://svn.python.org/view?view=rev&revision=74320

I started trying to test rpc.RPCClient together with run.main but it
seemed too high level. Then I moved to try to test rpc.SocketIO
directly, but it seems I'm doing wrong things there. Most of times
SocketIOTest will fail by raising ValueError which then causes the
server process to finish and either cause a "Connection reset by peer",
"Broken pipe" or nothing (these are on Linux, on Windows I would expect
to get "An existing connection was forcibly closed by the remote host").
Sometimes it also succeeds.

--
versions: +Python 2.7, Python 3.1 -Python 3.0

___
Python tracker 

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

[issue6650] sre_parse contains a confusing generic error message

[Torne Wuff]

New submission from Torne Wuff :

sre_parse raises an exception with the message "syntax error" - very
generic and confusing - in the case where something that looks like a
lookbehind assertion is invalid.

>>> import re
>>> re.match('(?.*)', 'foo')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/re.py", line 137, in match
return _compile(pattern, flags).match(string)
  File "/usr/lib/python2.5/re.py", line 241, in _compile
raise error, v # invalid expression
sre_constants.error: syntax error

This example is a typo for '(?P.*)' :)

This is the only case in sre_parse where the message "syntax error" is
used - the others are much more descriptive. Attached patch changes it
to "bad lookbehind assertion type: %s" for python 2.x head; should be
applied to 3.x also.

--
components: Regular Expressions
files: sre_error_msg.diff
keywords: patch
messages: 91324
nosy: torne
severity: normal
status: open
title: sre_parse contains a confusing generic error message
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 
3.1, Python 3.2
Added file: http://bugs.python.org/file14659/sre_error_msg.diff

___
Python tracker 

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

[issue6603] Compilation error if configuref --with-computed-gotos

[Artur Frysiak]

Artur Frysiak  added the comment:

reproduced on fresh checkout from
http://svn.python.org/projects/python/branches/py3k (rev. 74321)

$ gcc --version|head -n 1
gcc (PLD-Linux) 4.4.1 20090724 (release)

--

___
Python tracker 

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

[issue6594] json C serializer performance tied to structure depth on some systems

[Shawn]

Shawn  added the comment:

As I mentioned, there's also noticeable performance penalties on recent
SPARC systems, such as Niagra T1000, T2000, etc.  The degradation is
just less obvious (a 10-15 second penalty instead of a 20 or 30 second
penalty).  While x86 enjoys no penalty at all (in my testing so far).

Here's an example of the data structure:

{
  "packages":{
"package-name-1":{
  "publisher":"publisher-name-1",
  "versions":[
[
  "0.5.11,5.11-0.86:20080422T230436Z",
  {
"depend":{
  "require":[
{
  "fmri":"foo"
},   
{
  "fmri":"bar"
}
  ],   
  "optional":[
{
  "fmri":"baz"
},   
{
  "fmri":"quux"
}
  ]
}
  }
],   
  ]
}
  }
}

Now imagine that there are 45,000 package-name-x entries in the
structure above, and that basically replicates what I'm writing.

If I turn the above structure into a list of lists instead, the penalty
is significantly reduced (halved at least).  If I flatten the stack even
farther, the penalty is essentially gone.  The greater the depth of the
data structure, the greater the penalty.

As for priority, I wouldn't call this "end of the world", but it does
create some unfortunate surprises for developers that rely on the json
module.  Given the long service lifetimes of SPARC systems (due to cost
:)), I suspect this would be of benefit for a long time to come.

--

___
Python tracker 

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

[issue6651] Py3k's posixpath.relpath not compatible with ntpath.relpath

[Erick Tryzelaar]

New submission from Erick Tryzelaar :

It looks like Python 3.x's relpath isn't compatible between posixpath
and ntpath. In posixpath.relpath, the start keyword defaults to None,
but ntpath.relpath, the start keyword defaults to curdir.

Interestingly enough, 2.6 and 2.7 have a different implementation of
posixpath.relpath, where it explicitly sets the start to equal curdir,
just like ntpath does.

--
components: Library (Lib)
messages: 91327
nosy: erickt
severity: normal
status: open
title: Py3k's posixpath.relpath not compatible with ntpath.relpath
type: performance
versions: Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6594] json C serializer performance tied to structure depth on some systems

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Are you sure that recursion depth is the issue?  Have you tried the same
number and kind of objects listed serially (unnested)?  This would help
rule-out memory allocation issues and would instead confirm that it has
something to do with the C stack.

It would be helpful if you uploaded your test data strings and timing
suite.  Are you able to run a C profile so we can tell where the hotspot
is?  Can you run PyYAML over the same data to see if it is similarly
afflicted (yaml is a superset of json).

Also, try timing a repr() serialization of the same data,
x=repr(rootobj).  The repr code also uses recursion and it has to build
a big string in memory.  It has to visit every node, so it will reveal
whether memory cache misses are the culprit.  

Try your timings with GC turned-off so that we can rule that out.

Do you have some option to compile with an alternate memory allocator
(such as dlmalloc).  A crummy memory allocator may be the issue since
serialization entails creating many small strings, then joining and
resizing them.

Also, try serializing to /dev/null so that we can exclude fileio issues
(buffering and whatnot).

Sorry for all the requests, but there are many possible culprits and I
think it unlikely that recursion is the cause (much of the code in
Python works recursively -- everything from repr to gc -- so if that
were the problem, everything would run slower, not just json serialization).

--
assignee: bob.ippolito -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue6633] No handlers could be found for logger

[Vinay Sajip]

Vinay Sajip  added the comment:

1) It's not appropriate to document NullHandler at the point you
describe, as that's the API for Handlers. However, it is documented at

http://docs.python.org/library/logging.html#configuring-logging-for-a-library

I will check that NullHandler is added to documentation where the
available handler classes are listed.

2) Unlikely to be backported to 2.5, as it's a new feature (2.5
documentation tells how to create the class in user's own code).

3) NullHandler was placed in the main logging package along with the
other "elementary" handlers which are likely to be of most general use -
the handlers.py module is intended for more specialised handlers.

--
status: open -> closed

___
Python tracker 

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

[issue6652] missing cmath functions

[Phillip M. Feldman]

New submission from Phillip M. Feldman :

The online documentation describes functions cmath.phase and
cmath.polar, but when I try to import these, I get "cannot import name"
errors.

--
assignee: georg.brandl
components: Documentation
messages: 91330
nosy: georg.brandl, pfeld...@verizon.net
severity: normal
status: open
title: missing cmath functions
versions: Python 2.5

___
Python tracker 

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

[issue6652] missing cmath functions

[Georg Brandl]

Georg Brandl  added the comment:

These functions are new in Python 2.6; they do not appear in the Python
2.5 docs.

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

___
Python tracker 

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

[issue6653] Potential memory leak in multiprocessing

[Jesse Noller]

New submission from Jesse Noller :

I have example code to show this. It creates a system-wide memory leak 
on Linux/Unix (present until the next reboot), unless the last statement 
in the target of mp.Process ensures a manual clean up of the globals.

The problem is line 353 in multiprocessing/forking.py. The function 
exit() is defined as os._exit on Linux and ExitProcess on Windows, none 
of which allows normal clean up.

>>> help(os._exit)
Help on built-in function _exit in module nt:

_exit(...)
   _exit(status)

   Exit to the system with specified status, without normal exit 
processing.


The problem is fixed if line 353 in forking.py is changed from

exit(exitcode)

to

sys.exit(exitcode)




Test run without bugfix:

G:\DEVELO~1\SHARED~2>python test.py
open handle to 569f439b24e24fc8a547b81932616066
[[ 0.  0.  0.  0.]
 [ 0.  0.  0.  0.]]
open handle to 0582d4b161c546f582c1c96e7bd0c39d
open handle to 569f439b24e24fc8a547b81932616066
modified array
closed handle to 569f439b24e24fc8a547b81932616066
[[ 1.  1.  1.  0.]
 [ 1.  1.  1.  0.]]
closed handle to 569f439b24e24fc8a547b81932616066


You can see here that opening and closing of handles are unmatched. This 
is on Windows, where the kernel ensures the clean-up, so it may not 
matter. But on Unix this would have created a permament (system wide) 
memory leak! What is happening here is globals not being cleaned up due 
to the use of os._exit instead of sys.exit.


Test run with bugfix:

G:\DEVELO~1\SHARED~2>python test.py
open handle to 930778d27b414253bc329f2b70adaa05
[[ 0.  0.  0.  0.]
 [ 0.  0.  0.  0.]]
open handle to 3f6cebf8c5de413685bb770d02ae9666
open handle to 930778d27b414253bc329f2b70adaa05
modified array
closed handle to 930778d27b414253bc329f2b70adaa05
closed handle to 3f6cebf8c5de413685bb770d02ae9666
[[ 1.  1.  1.  0.]
 [ 1.  1.  1.  0.]]
closed handle to 930778d27b414253bc329f2b70adaa05



Now all allocations and deallocations are matched.


Regards,
Sturla Molden

--
files: test.zip
messages: 91332
nosy: jnoller
severity: normal
status: open
title: Potential memory leak in multiprocessing
Added file: http://bugs.python.org/file14660/test.zip

___
Python tracker 

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

[issue6653] Potential memory leak in multiprocessing

[Jesse Noller]

Jesse Noller  added the comment:

Additional comments from Sturla:

Hello Jesse,

Yes there is a bug in multiprocessing.

Diagnosis:

- Processes created by multiprocessing (mp.Process or mp.Pool) exit in a 
way that prevents the Python interpreter from running deallocation code 
for all extension objects (only the locals are cleaned up). Resources 
allocated by extension objects referenced in globals may leak 
permanently.

Sub-processes seem to commit an ungraceful suicide on exit. If the 
kernel cleans up after a non-graceful exit this is ok. But if the kernel 
do not, as in the case of System V IPC objects, we have a permanent 
resource leak. This is very similar to the reason why manually killing 
threads is prohibited in Python.

I have example code to show this. It creates a system-wide memory leak 
on Linux/Unix (present until the next reboot), unless the last statement 
in the target of mp.Process ensures a manual clean up of the globals.

--

___
Python tracker 

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

[issue6653] Potential memory leak in multiprocessing

[Jesse Noller]

Changes by Jesse Noller :


--
assignee:  -> jnoller

___
Python tracker 

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

[issue6653] Potential memory leak in multiprocessing

[Jesse Noller]

Jesse Noller  added the comment:

> Calling os.exit in a child process may be dangerous. It can cause 
> unflushed buffers to be flushed twice: once in the parent and once in 
> the child. 

I assume you mean sys.exit. If this is the case, multiprocessing needs 
a mechanism to chose between os._exit and sys.exit for child 
processes. Calling os._exit might also be dangerous because it could 
prevent necessary clean-up code from executing  (e.g. in C 
extensions). I had a case where shared memory on Linux (System V IPC) 
leaked due to os._exit. The deallocator for my extension type never 
got to execute in child processes. The deallocator was needed to 
release the shared segment when its reference count dropped to 0. 
Changing to sys.exit solved the problem. On Windows there was no leak, 
because the kernel did the reference counting.

--

___
Python tracker 

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

[issue6653] Potential memory leak in multiprocessing

[Jesse Noller]

Jesse Noller  added the comment:

> In the future please use the bug tracker to file and track bugs with, 
> so things are not as lossy. 


Ok, sorry :) 
Also see Piet's comment here. He has a valid case against sys.exit in 
some cases. Thus it appears that both ways of shutting down child 
processes might be dangerous: If we don't want buffers to flush we 
have to use os._exit. If we want clean-up code to execute we have to 
use sys.exit. If we want both we are screwed. :(

--

___
Python tracker 

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

[issue6605] smtplib.SMTP.sendmail() rejected after quit(), connect() sequence, no HELO

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
resolution:  -> duplicate
status: open -> closed
superseder:  -> smtplib doesn't clear helo/ehlo flags on quit

___
Python tracker 

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

[issue6633] No handlers could be found for logger

[James]

James  added the comment:

very well,
i didn't notice the
http://docs.python.org/library/logging.html#configuring-logging-for-a-library
and i thank you for your time and efforts!

cheers,
_J

--

___
Python tracker 

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

[issue6654] Add "path" to the xmrlpc dispatcher method

[Kristján Valur Jónsson]

New submission from Kristján Valur Jónsson :

I've created http://codereview.appspot.com/100046 on Rietveld:
by passing the "path" component of the xmlrpc request to the dispatch 
method, it
becomes possible to dispatch differently according to this.  This patch 
provides
that addition.  Additionally, it provides an MultiPathXMLRPCDispatcher 
mixin
class and a MultiPathXMLRPCServer that uses it, to have multiple 
dispatchers for
different paths.
This allows a single server port to serve different XMLRPC servers as
differentiated by the HTTP path.  A test is also preovided.

I've also prophylacticly emailed this to phython-ideas.

--
components: Library (Lib)
messages: 91337
nosy: krisvale
severity: normal
status: open
title: Add "path" to the xmrlpc dispatcher method
type: feature request
versions: Python 2.7

___
Python tracker 

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

[issue2333] Backport set and dict comprehensions

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

Here is a patch to backport dict and set comprehensions to the trunk.

The patch preserves the Python 3.x's syntax and semantics of the
feature. Although this makes dict and set comprehensions is inconsistent
with list comprehension, I believe this is reasonable since the backport
aimed to improve the compatibility of Python 2.x with Python 3.x.

The patch also adds support for dict and set comprehensions to the
'compiler' package. However, the support is quirky and use the list
comprehension semantics of Python 2.x. This allowed me to keep the patch
simple and to keep myself sane ;-).

Finally, the patch changes the name of the following syntax nodes:
'gen_expr', 'gen_iter', 'gen_if', and 'testlist_gexp'. I don't know if
we have compatibility requirements for this; so I don't know if this is
an issue.

--
keywords: +patch
nosy: +alexandre.vassalotti
stage:  -> patch review
title: Backport dict comprehensions -> Backport set and dict comprehensions
Added file: 
http://bugs.python.org/file14661/backport_dict_and_set_comprehension.diff

___
Python tracker 

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

[issue2334] Backport set comprehensions

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti :


--
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Backport set and dict comprehensions

___
Python tracker 

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

[issue2333] Backport set and dict comprehensions

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti :


--
dependencies: +Backport set literals

___
Python tracker 

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

[issue5736] Add the iterator protocol to dbm modules

[Christopher Lee]

Christopher Lee  added the comment:

Another reason this issue is really important, is that the lack of a
consistent iter() interface for dbm.* makes shelve iteration not
scalable; i.e. trying to iterate on a Shelf will run self.dict.keys() to
load the entire index into memory.  This seems contrary to a primary
purpose of shelve, namely to store the index on-disk so as to avoid
having to keep the whole index in memory.  

I suspect that for most users, shelve is the main way they will access
the dbm.* interfaces.  Therefore, fixing the dbm.* interfaces so that
shelve is scalable seems like an important need.

Once dbm and gdbm support the iterator protocol, it will be trivial to
add an __iter__() method to shelve.Shelf, that simply returns
iter(self.dict).

--
nosy: +foobaron

___
Python tracker 

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

[issue2345] Using an exception variable outside an 'except' clause should raise a Py3K warning

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

Brett, could you provide an example of "an exception bound to a variable"?

--
nosy: +alexandre.vassalotti
priority: critical -> normal
stage:  -> test needed

___
Python tracker 

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

[issue2345] Using an exception variable outside an 'except' clause should raise a Py3K warning

[Brett Cannon]

Brett Cannon  added the comment:

try:
raise Exception("I should not be seen")
except Exception, exc:
pass

print exc

--

___
Python tracker 

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

[issue6045] Fix dbm interfaces

[Christopher Lee]

Christopher Lee  added the comment:

I suspect that for most users, shelve is the main way they will access
the dbm.* interfaces.  Based on that, the dict methods that are really
needed on dbm.* objects are just: __iter__, __len__, __getitem__,
__setitem__, __delitem__, __contains__, has_key, and keys.  

Note: Issue 5736 aims to make dbm.* support the iterator protocol, which
would be crucial for making shelve iteration scalable (currently,
iterating on a Shelf will call self.dict.keys(), loading the entire
index into memory!).

The dbm.* docs could also explicitly tell users who want a *complete*
dict interface to create a class that inherits from both dbm and
UserDict.DictMixin / MutableMapping.

--
nosy: +foobaron

___
Python tracker 

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

[issue6645] multiprocessing build fails on AIX - /dev/urandom (or equivalent) not found

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

I suppose multiprocessing invokes `os.random` somewhere. And os.random 
fails on AIX for obvious reasons:

>>> os.urandom(10)
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/srid/ActivePythonEE-2.6.2.3-aix-powerpc64/i/lib/python2.6/
os.py", line 755, in urandom
raise NotImplementedError("/dev/urandom (or equivalent) not found")
NotImplementedError: /dev/urandom (or equivalent) not found
>>> 

Why should multiprocessing require `urandom` at all? Can't it fallback 
to os.random, if os.urandom is unavailable?

try:
os.urandom(10)
except NotImplementedError:
urandom = os.urandom
else:
urandom = os.random

--

___
Python tracker 

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

[issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

Update: posixmodule.c too has the same problem. Attaching similar patch 
for this:

--- python/Modules/posixmodule.c.orig   2009-08-05 09:47:07.0 
-0700
+++ python/Modules/posixmodule.c2009-08-05 09:48:46.0 
-0700
@@ -6451,7 +6451,7 @@
return NULL;
 
/* Sanitize mode.  See fileobject.c */
-   mode = PyMem_MALLOC(strlen(orgmode)+3);
+   mode = PyMem_MALLOC(3+strlen(orgmode));

--
keywords: +patch
Added file: http://bugs.python.org/file14662/aix2.patch

___
Python tracker 

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

[issue6600] MemoryError in AiX 64-bit build - PyMem_MALLOC failed

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

It does appear that this problem occurs wherever `strlen` is used .. 
and given that strlen is a macro on AIX, I suspect the problem is with 
the macro definition itself.

I will see if wrapping the arguments to PyMem_MALLOC in parenthesis 
would help. And/or investigate the problem further.

As for your belief that it might be a compiler bug, I will wait till 
investigating the actual cause of the problem before drawing any 
conclusions. Till then, there is no reason to commit the current 
(experimental/workaround) patches to Python.

--

___
Python tracker 

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

[issue6600] MemoryError in AiX 64-bit - PyMem_MALLOC fails in open/fdopen

[Sridhar Ratnakumar]

Changes by Sridhar Ratnakumar :


--
title: MemoryError in AiX 64-bit build - PyMem_MALLOC failed -> MemoryError in 
AiX 64-bit - PyMem_MALLOC fails in open/fdopen

___
Python tracker 

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

[issue4660] multiprocessing.JoinableQueue task_done() issue

[Jesse Noller]

Jesse Noller  added the comment:

Fix checked into python trunk with r74326, 26 maint w/ r74327

--

___
Python tracker 

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

[issue4660] multiprocessing.JoinableQueue task_done() issue

[Jesse Noller]

Jesse Noller  added the comment:

I used the protected JoinableQueue put method suggested by Brian.

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

[issue6064] Add "daemon" argument to threading.Thread constructor

[Jesse Noller]

Changes by Jesse Noller :


--
assignee:  -> jnoller

___
Python tracker 

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

[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti :


--
nosy: +alexandre.vassalotti
stage:  -> patch review

___
Python tracker 

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

[issue6655] etree iterative find[text]

[Dj Gilcrease]

New submission from Dj Gilcrease :

I recently converted a project from using a custom  implementation of 
xml.dom.minidom to using EelemntTree that comes with python2.5+ and 
found myself wishing for a find(tag_or_path) method that would do so 
iteratively instead of just on the current elements direct children. 
This is possible with the code as written;

looking_for = None
for el in etree.getiterator(tag_or_path):
looking_for = el
break

I have to do this type of action so often in my code that I just decided 
to grab the python implementation of etree that came with py2.6 and 
include it with my app and patch in an iter_find method as the instant 
break for loop is just asking for maintenance issues down the road what 
I forget why I was breaking on the first loop no matter what.

--
components: XML
files: ElementTree.py.patch
keywords: patch
messages: 91348
nosy: Digitalxero
severity: normal
status: open
title: etree iterative find[text]
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14663/ElementTree.py.patch

___
Python tracker 

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

[issue6655] etree iterative find[text]

[Dj Gilcrease]

Dj Gilcrease  added the comment:

second patch file

--
Added file: http://bugs.python.org/file14664/ElementPath.py.patch

___
Python tracker 

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