[issue1954] SocketServer.ForkingMixIn creates a zombie

[Ralf Schmitt]

New submission from Ralf Schmitt:

collect_children is only called in process_request, so at least the last
process forked is not collected. This could be handled by calling
collect_children every X seconds or by handling SIGCHLD.

--
messages: 61773
nosy: schmir
severity: normal
status: open
title: SocketServer.ForkingMixIn creates a zombie

__
Tracker <[EMAIL PROTECTED]>

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

[issue1926] NNTPS support in nntplib

[Bill Janssen]

Bill Janssen added the comment:

Yeah, it took me a couple of months to do a reasonable test case for the SSL
code.

Perhaps we could test against an existing NNTP server?  Like Google's?

Bill

On Jan 27, 2008 6:59 PM, Ray Chason <[EMAIL PROTECTED]> wrote:

>
> Ray Chason added the comment:
>
> It seems that I, or whoever writes any future test_nntplib.py, would
> have to understand how existing tests such as test_smtplib.py work.  It
> looks like that one is setting up some kind of miniature mail server and
> accepting a connection on localhost -- neat trick, binding a server
> socket to port 0 so it still works if you have a real mail server running.
>
> Anyway, getting good coverage isn't something I can bang out in an
> afternoon.  Class NNTPBase and its derivatives (I'm talking post-patch
> of course) have lots of methods and I want to cover them as well as
> possible.
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

Added file: http://bugs.python.org/file9309/unnamed

__
Tracker <[EMAIL PROTECTED]>

__Yeah, it took me a couple of months to do a reasonable test case for the SSL 
code.Perhaps we could test against an existing NNTP server?  Like 
Google's?BillOn Jan 27, 2008 6:59 
PM, Ray Chason [EMAIL PROTECTED]> 
wrote:
Ray Chason added the comment:It seems that I, 
or whoever writes any future test_nntplib.py, would
have to understand how existing tests such as test_smtplib.py work. 
 Itlooks like that one is setting up some kind of miniature mail 
server andaccepting a connection on localhost -- neat trick, binding a 
server
socket to port 0 so it still works if you have a real mail server 
running.Anyway, getting good coverage isn't something I can bang 
out in anafternoon.  Class NNTPBase and its derivatives (I'm 
talking post-patch
of course) have lots of methods and I want to cover them as well 
aspossible.__Tracker [EMAIL PROTECTED]>
http://bugs.python.org/issue1926>__

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

[issue1952] test_select.py converted to unittest

[Christian Heimes]

Changes by Christian Heimes:


--
keywords: +patch
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1953] gc.compact_freelists

[Christian Heimes]

New submission from Christian Heimes:

The patch implements gc.compact_freelists() which calls PyInt and
PyFloat_CompactFreeList(). I've moved the code from the _Fini methods to
the _CompactFreeList() methods.

The patch also moves the clear type cache function to gc.clear_type_cache().

--
assignee: nnorwitz
components: Extension Modules, Interpreter Core
files: trunk_compact_freelist.patch
keywords: patch
messages: 61771
nosy: nnorwitz, tiran
priority: normal
severity: normal
status: open
title: gc.compact_freelists
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9308/trunk_compact_freelist.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Ismail Donmez]

Ismail Donmez added the comment:

Hah strlen in a loop, a nice beginner mistake but its 5.30 AM here so
please excuse me, Guido your version of course is way better. But with
that version compiler issues 

Modules/_csv.c:969: warning: assuming signed overflow does not occur when 
simplifying conditional to constant

again, strlen() just fooled that optimization it seems. So there should
be another way to optimize this loop.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1948] Cant open python gui using VISTA

[safe alattar]

safe alattar added the comment:

I made a search for the hidden folder 'idlerc' and got back no results : (

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Guido van Rossum]

Guido van Rossum added the comment:

> for (i = 0; i < strlen(field) ; i++) {

This looks inefficient.  Why not

 for (i = 0; field[i] != '\0'; i++) {

???

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Ismail Donmez]

Ismail Donmez added the comment:

For xmlparse.c compiler says :

Modules/expat/xmlparse.c:5337: warning: assuming signed overflow does
not occur when simplifying conditional to constant

Its impossible for j to overflow here due to name[i] check but I am not
sure what gcc is optimizing here.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Ismail Donmez]

Ismail Donmez added the comment:

_sre.c case is the most interesting one , compiler says :

./Modules/_sre.c:1002: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1069: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1086: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1143: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1185: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1214: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1238: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1251: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1277: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1291: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1308: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1395: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1408: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c: In function 'sre_umatch':
./Modules/_sre.c:1002: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1069: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1086: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1143: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1185: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1214: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1238: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1251: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1277: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1291: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1308: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1395: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1408: warning: assuming signed overflow does not occur
when simplifying conditional to constant

all lines refer to : RETURN_ON_ERROR(ret);

My investigation :

On line 1002 we got RETURN_ON_ERROR(ret); but ret is already 0 and not
set to anything this if will always be false.

Same for line 1069, ret is still zero there. Maybe I am missing
something here?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Ismail Donmez]

Ismail Donmez added the comment:

Neal,

I'll try to answer your questions one by one, first with _csv.c compiler
issues :

Modules/_csv.c:969: warning: assuming signed overflow does not occur
when simplifying conditional to constant

There is a check inside loop like this:

   if (c == '\0')
   break;

Instead of this if we do the check in the for :

+   for (i = 0; i < strlen(field) ; i++) {

and remove the if check compiler no longer issues a warning also csv
test passes with this. Attached patch implements this optimization.

Guido, you don't have to shout, you know noone pays me per python
bugreport I create :)

Added file: http://bugs.python.org/file9307/csv.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1926] NNTPS support in nntplib

[Ray Chason]

Ray Chason added the comment:

It seems that I, or whoever writes any future test_nntplib.py, would
have to understand how existing tests such as test_smtplib.py work.  It
looks like that one is setting up some kind of miniature mail server and
accepting a connection on localhost -- neat trick, binding a server
socket to port 0 so it still works if you have a real mail server running.

Anyway, getting good coverage isn't something I can bang out in an
afternoon.  Class NNTPBase and its derivatives (I'm talking post-patch
of course) have lots of methods and I want to cover them as well as
possible.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Guido van Rossum]

Guido van Rossum added the comment:

Don't create new bug reports!

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Neal Norwitz]

Neal Norwitz added the comment:

On Jan 27, 2008 6:45 PM, Ismail Donmez <[EMAIL PROTECTED]> wrote:
>
> Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk.

I just tried with =1, =2, =3, and no =.  All the same result:  no warning.

Ismail, thanks for going through all this effort.  It's very helpful.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Ismail Donmez]

Ismail Donmez added the comment:

To Neal,

Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk.

To Guido,

I'll check _csv.c issue closely. Shall I create the new bug reports or
will reviewers will do so and CC me maybe?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Neal Norwitz]

Neal Norwitz added the comment:

I just added -Wstrict-overflow to the code in sysmodule.c
(sys_getframe) and tried with gcc 4.2.1.  It doesn't warn.  I wonder
if 4.3 is more picky or warns when it shouldn't?

Unless if I changed the code so it doesn't work:

typedef struct {int ref;} PyObject;
typedef struct { PyObject* f_back; } PyFrameObject;
int PyArg_ParseTuple(PyObject*, const char*, int*);

PyObject *
sys_getframe(PyFrameObject *f, PyObject *self, PyObject *args)
{
int depth = -1;

if (!PyArg_ParseTuple(args, "|i:_getframe", &depth))
return 0;

while (depth > 0 && f != 0) {
f = (PyFrameObject*)f->f_back;
--depth;
}
return (PyObject*)f;
}

Compiled with:
gcc-4.2.1-glibc-2.3.2/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-gcc
-Wstrict-overflow -c xx.c

produced no warnings.  This is not a stock gcc 4.2.1, so that could
also be an issue.  Did I run it correctly.  Is there anything else I
need to do?  If you run the code above with gcc 4.3, does it produce a
warning?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Guido van Rossum]

Guido van Rossum added the comment:

Unfortunately I have no time to work on this myself, but in order to
make progress I recommend checking in things piecemeal so that the same
changes don't get reviewed over and over again.  I propose that each
submit reference this bug ("Partial fix for issue #1621" I'd suggest)
and that the submits are recorded here (e.g. "fixed  in rXXX
(2.5.2), rYYY (2.6)").  Then hopefully only a few hard cases will remain.

With Neal, I don't see what the warning in _csv is about. What condition
is being turned into a constant? Is the compiler perhaps rearranging the
code so as to insert "if (field[0] == '\0') goto XXX;" in front of the
for-loop where XXX jumps into the middle of the condition in the
if-statement immediately following the for-loop, and skipping that
if-block when breaking of the loop later? That would be clever, and
correct, and I'm not sure if making i unsigned is going to help -- in
fact it might make the compiler decide it can't use that optimization...

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Ismail Donmez]

Ismail Donmez added the comment:

Thanks for the through review! I will add -Wsign-compare and fix new
warnings.
Btw current state is with the patch -fwrapv is not needed and no
regressions.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1621] Do not assume signed integer overflow behavior

[Neal Norwitz]

Neal Norwitz added the comment:

I'm just starting to look at the patch.  The first one changes i to
unsigned in Modules/_csv.c.  Hopefully most of them are like this.  The
code is fine as it is.  There is no reliance on overflow AFAICT.  It's
just that the breaking condition from the loop is not in the for (...).
 I think this change is fine to avoid a warning.  Just pointing out that
in this one case, it's not a real problem.

Change to heapq doesn't seem needed.  I looked at the warning generated
from this and it's if (!n).  This seems to indicate the compiler thinks
that n could be negative.  That should not be possible.  It came from
PyList_GET_SIZE.  We had verified the object was already a list.  So
this value should be between 0 and PY_SSIZE_T_MAX.  We check for 0, so
it might be > 0.  After decrementing n, it should be between 0 and
PY_SSIZE_T_MAX-1.  Of course, the compiler can't know the value can't be
negative (or PY_SSIZE_T_MIN) which would cause an underflow.

Change to hotshot should avoid a cast, so it's slightly better with this
approach.  Although with the change to size_t, the cast in flush_data
can be removed (just after the fwrite).

I don't see the reason to need for the change in sre.c, but I'm pretty
sure there are other overflows.

audioop definitely looks needed.
cPickle looks necessary.
expat/xmlparse.c is interesting--not sure if it's really necessary.  In
practice this probably can't be reached.
gc can't really overflow given that NUM_GENERATIONS is 3 and not likely
to grow much more. :-)

I stopped looking at this point.  It looks like some of these are really
needed.  Others are not possible given other invariants (the compiler
can't know about).  I like the idea of silencing compiler warnings. 
However, I fear this may generate a different problem.  Namely
signed/unsigned mismatches.

What happens if you add this warning:  -Wsign-compare
I think we got rid of most of those before (probably not true as much
for Modules/*.c).  I think this introduces many more.  Would it be
possible to come up with a patch that doesn't introduce more warnings
w/-Wsign-compare?

One potential issue with this patch is that while the additions might
have guaranteed semantics, we might have other problems when doing:

   size_t value = PyXXX_Size();
   if (value < 0) ...

I'm hoping that if we can use both -Wstrict-overflow and
-Wsign-conversion, eliminate all warnings, resulting in better code. 
(You could also try building with g++.  The core used to work without
warnings.  The modules still had a ways to go.)

Also what is the current state?  What has been implemented and what else
needs to be done?  Perhaps we should make other bug report(s) to address
other tangents that were discussed in this thread.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1952] test_select.py converted to unittest

[Giampaolo Rodola']

Changes by Giampaolo Rodola':


Added file: http://bugs.python.org/file9306/test_select.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue1952] test_select.py converted to unittest

[Giampaolo Rodola']

New submission from Giampaolo Rodola':

In attachment.

--
components: Tests
files: test_select.diff
messages: 61756
nosy: giampaolo.rodola
severity: minor
status: open
title: test_select.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9305/test_select.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue1951] test_wave.py converted to unittest

[Giampaolo Rodola']

Giampaolo Rodola' added the comment:

Sorry but I realized right now by reading Lib/test/readme.txt that the
test scripts are required to have a global "test_main()" function
defined hence the "main()" function I defined in my patch should be
renamed in "test_main()".

__
Tracker <[EMAIL PROTECTED]>

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

[issue1951] test_wave.py converted to unittest

[Giampaolo Rodola']

New submission from Giampaolo Rodola':

In attachment.

--
components: Tests
files: test_wave.diff
messages: 61754
nosy: giampaolo.rodola
severity: minor
status: open
title: test_wave.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9304/test_wave.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

[Alexandre Vassalotti]

Changes by Alexandre Vassalotti:


--
title: Potential Overflow due to incorrect usage of PyUnicode_AsString. -> 
Potential overflows due to incorrect usage of PyUnicode_AsString.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1950] Potential Overflow due to incorrect usage of PyUnicode_AsString.

[Alexandre Vassalotti]

New submission from Alexandre Vassalotti:

I have found a few instances of the following pattern in Py3k: 

   char buf[MAX];
   len = PyUnicode_GET_SIZE(str);
   if (len >= MAX)
   /* return error */
   strcpy(buf, PyUnicode_AsString(str));

which could overflow if str contains non-ASCII characters. These were
probably introduced during the PyString -> PyUnicode transition. Anyway,
I got a patch that fixes (hopefully) most of these bugs.

--
assignee: alexandre.vassalotti
components: Interpreter Core
files: unicode_string_overflow.patch
keywords: patch
messages: 61753
nosy: alexandre.vassalotti
priority: normal
severity: normal
status: open
title: Potential Overflow due to incorrect usage of PyUnicode_AsString.
type: security
versions: Python 3.0
Added file: http://bugs.python.org/file9303/unicode_string_overflow.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1949] test_ntpath.py converted to unittest

[Giampaolo Rodola']

Changes by Giampaolo Rodola':


--
title: test_ntpath.py rewriting -> test_ntpath.py converted to unittest

__
Tracker <[EMAIL PROTECTED]>

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

[issue1949] test_ntpath.py rewriting

[Christian Heimes]

Christian Heimes added the comment:

The patch looks fine but I've no time to review it properly.

--
keywords: +easy, patch
nosy: +tiran
priority:  -> normal
resolution:  -> accepted
type:  -> rfe

__
Tracker <[EMAIL PROTECTED]>

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

[issue1948] Cant open python gui using VISTA

[Christian Heimes]

Christian Heimes added the comment:

I assume you are talking about Python 2.5.1 on Windows Vista? Yes, there
is a solution. You have to unhide the folder .idlerc in your USERPROFILE
directory and remove its content.

--
assignee:  -> kbk
components: +IDLE
nosy: +kbk, tiran
priority:  -> high
type:  -> crash
versions: +Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1949] test_ntpath.py rewriting

[Giampaolo Rodola']

Changes by Giampaolo Rodola':


Added file: http://bugs.python.org/file9302/test_ntpath.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue1949] test_ntpath.py rewriting

[Giampaolo Rodola']

New submission from Giampaolo Rodola':

Since I noticed that test_ntpath.py (unlike test_genericpath.py,
test_macpath.py and test_posixpath.py) does NOT use unittest for doing
tests I tried to rewrite it.
The patch in attachment does that leaving the original tests unchanged.

Tested successfully by having used python 2.6 (current trunk) on Windows
XP and Linux Ubuntu.

--
components: Tests
files: test_ntpath.diff
messages: 61750
nosy: giampaolo.rodola
severity: normal
status: open
title: test_ntpath.py rewriting
versions: Python 2.6
Added file: http://bugs.python.org/file9301/test_ntpath.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue1948] Cant open python gui using VISTA

[safe alattar]

New submission from safe alattar:

I need help opening the python gui (IDLE). On XP I had no issues. On
Vista nothing occurs when I try to open IDLE. If there is a solution to
this, please let me know in a user friendly manner (Im new to this!) Thanks.

--
messages: 61749
nosy: needhelpasap
severity: normal
status: open
title: Cant open python gui using VISTA

__
Tracker <[EMAIL PROTECTED]>

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

[issue1947] Exception exceptions.AttributeError '_shutdown' in

[shore.cloud]

shore.cloud added the comment:

I will,sorry

2008/1/28, Christian Heimes <[EMAIL PROTECTED]>:
>
>
> Christian Heimes added the comment:
>
> Next time please set type, component and version
>
> --
> components: +Library (Lib)
> nosy: +tiran
> priority:  -> low
> type:  -> behavior
> versions: +Python 2.5
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

Added file: http://bugs.python.org/file9300/unnamed

__
Tracker <[EMAIL PROTECTED]>

__I will,sorry 
2008/1/28, Christian Heimes [EMAIL PROTECTED]>:
Christian Heimes added the 
comment:Next time please set type, component and 
version--
components: +Library (Lib)nosy: +tiranpriority:  -> 
lowtype:  -> behaviorversions: +Python 
2.5__Tracker [EMAIL PROTECTED]>
http://bugs.python.org/issue1947>__

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

[issue1943] improved allocation of PyUnicode objects

[Antoine Pitrou]

Antoine Pitrou added the comment:

I know it's not the place to discuss #1629305, but the join() solution
is not always faster. Why? Because 1) there's the list contruction and
method call overhead 2) ceval.c has some bytecode hackery to try and
make plain concatenations somewhat less slow.

As for cStringIO, I actually observed in some experiments that it was
slower than the other alternatives, at least for short strings. All in
all, choosing between the three idioms is far from obvious and needs
case-by-case analysis.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1947] Exception exceptions.AttributeError '_shutdown' in

[Christian Heimes]

Christian Heimes added the comment:

Next time please set type, component and version

--
components: +Library (Lib)
nosy: +tiran
priority:  -> low
type:  -> behavior
versions: +Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1941] 2.6 stdlib using with statement

[Benjamin Peterson]

Benjamin Peterson added the comment:

Today, I carefully looked through every change in my patching. I asked
myself "Does this do the same things in the same order as the original?"
and "Could exceptions cause the code to function differently?" They only
changes were when the block which used the file was not in a try finally
block so if an exception were raised, it the file would be closed. The
with statement of course removes this problem. So, I do believe the
patch is "semantically neutral." I would, however, not mind if another
set of eyes examined it.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1867] patch for pydoc to work in py3k

[Georg Brandl]

Georg Brandl added the comment:

Done in r60366, thanks!

__
Tracker <[EMAIL PROTECTED]>

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

[issue1943] improved allocation of PyUnicode objects

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Agreed, those optimizations do make the implementation more complicated.
It's also not clear whether they would really be worth it.

#1629305 only provided speedups for the case where you write s += 'abc'.
The usual idiom for this is to use a list and then concatenate in one
go. If you want a really fast approach, you'd use cStringIO or perhaps
the bufferarray. I don't think that optimizing for just one particular
use case warrants making the code more complicated or changing the C
interface radically.

In your case, I think that closing the door for being able to easily
extend the type implement at the C is the main argument against it. The
speedups are only marginal and can also be achieved (to some extent) by
tuning the existing implementation's parameters.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1947] Exception exceptions.AttributeError '_shutdown' in

[shore.cloud]

New submission from shore.cloud:

Exception exceptions.AttributeError: '_shutdown' in 
 ignored

--
files: thread1.py
messages: 61742
nosy: Mr Shore
severity: normal
status: open
title: Exception exceptions.AttributeError '_shutdown' in http://bugs.python.org/file9299/thread1.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue1943] improved allocation of PyUnicode objects

[Antoine Pitrou]

Antoine Pitrou added the comment:

All of those proposals are much heavier to implement; they also make the
unicode type more complicated and difficult to maintain probably (while
turning it into a PyVarObject actually shortens the implementation a
bit). In any case, it's not something I want to tackle.

The reason that I mentioned #1629305 was that it was such an
optimization which complicated the unicode type while bringing very
significant speedups.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1943] improved allocation of PyUnicode objects

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

I don't really see the connection with #1629305. 

An optimization that would be worth checking is hooking up the
Py_UNICODE pointer to interned Unicode objects if the contents match
(e.g. do a quick check based on the hash value and then a memcmp). That
would save memory and the call to the pymalloc allocator.

Another strategy could involve a priority queue style cache with the aim
of identifying often used Unicode strings and then reusing them. 

This could also be enhanced using an offline approach: you first run an
application with an instrumented Python interpreter to find the most
often used strings and then pre-fill the cache or interned dictionary on
the production Python interpreter at startup time.

Coming from a completely different angle, you could also use the
Py_UNICODE pointer to share slices of a larger data buffer. A Unicode
sub-type could handle this case, keeping a PyObject* reference to the
larger buffer, so that it doesn't get garbage collected before the
Unicode slice.

Regarding memory constrained environments: these should simply switch
off all free lists and pymalloc. OTOH, even mobile phones come with
gigabytes of RAM nowadays, so it's not really worth the trouble, IMHO.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1946] re.search hangs on this

[Israel Tsadok]

New submission from Israel Tsadok:

import re
re.search(r'a(b[^b]*b|[^c])*cxxx',
'abbcacacabbcabbcacabbcacac')

perl seems to handle this just fine.

(The original problem was trying to translate some html to text:
re.sub(r'])*>(.*?)', r'\1\n')

This hanged on several files. Changing [^>] to [^">] resolved my
problem, but the general case remains.)

This might be a dupe of http://bugs.python.org/issue1297193

--
components: Regular Expressions
messages: 61739
nosy: itsadok
severity: normal
status: open
title: re.search hangs on this
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1943] improved allocation of PyUnicode objects

[Antoine Pitrou]

Antoine Pitrou added the comment:

With KEEPALIVE_SIZE_LIMIT = 200, the pybench runtime is basically the
same as with my patched version. stringbench remains a bit faster though
(~8%).

You say that RAM size is cheaper than CPU power today, which is true but
misses one part of the picture: the importance of CPU caches, and thus
of working set size. There are also probably people wanting to use
Python in memory-constrained environments (embedded).

I understand the argument about possible optimizations with an external
buffer, but are such optimizations likely to be implemented? (see
#1590352 and #1629305). If they really are, then I'm happy with the
unicode type remaining a plain PyObject!

__
Tracker <[EMAIL PROTECTED]>

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

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

[Mark Dickinson]

Mark Dickinson added the comment:

I noticed that the ability to type Rational("2.3") has been added (and I 
think this is a very useful addition).  One minor nit:  would it make 
sense to have Rational("2.") and Rational(".3") also work?  These strings 
work for float() and Decimal(), and 2. and .3 work as float literals, so 
it would seem to make sense to allow this for Rational as well.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1945] Document back ported C functions

[Christian Heimes]

New submission from Christian Heimes:

Document the C functions which were back ported from py3k in r60283.

--
components: Documentation
keywords: easy
messages: 61736
nosy: tiran
priority: normal
severity: normal
status: open
title: Document back ported C functions
type: rfe
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue1944] Documentation for PyUnicode_AsString (et al.) missing.

[Christian Heimes]

Changes by Christian Heimes:


--
priority:  -> normal
type:  -> rfe

__
Tracker <[EMAIL PROTECTED]>

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

[issue1943] improved allocation of PyUnicode objects

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Your microbenchmark is biased towards your patched version. The
KEEPALIVE_SIZE_LIMIT will only cut in when you deallocate and then
reallocate Unicode objects. The free list used for Unicode objects is
also limited to 1024 objects - which isn't all that much. You could tune
 MAX_UNICODE_FREELIST_SIZE as well.

Regarding memory usage: this is difficult to measure in Python, since
pymalloc will keep memory chunks allocated even if they are not in use
by Python. However, this is a feature of pymalloc and not specific to
the Unicode implementation. It can be tuned in pymalloc. To get more
realistic memory measurements, you'd have to switch off pymalloc
altogether and then create a separate process that consumes lots of
memory to force the OS to have it allocate only memory that's really
needed to the process you're running for memory measurements. Of course,
keeping objects alive in a free list will always use more memory than
freeing them altogether and returning the memory to the OS. It's a
speed/space tradeoff. The RAM/CPU costs ratio has shifted a lot towards
RAM nowadays, so using more RAM is usually more efficient than using
more CPU time.

Regarding resize: you're right - the string object is a PyVarObject as
well and couldn't be changed at the time due to backwards compatibility
reasons. You should also note that when I added Unicode to Python 1.6,
it was a new and not commonly used type. Codecs were not used much
either, so there was no incentive to make resizing strings work better.
Later on, other optimizations were added to the Unicode implementation
that caused the PyUnicode_Resize() API to also require being able to
change the object address. Still, in the common case, it doesn't change
the object address.

The reason for using an external buffer for the Unicode object was to be
able to do further optimizations, such as share buffers between Unicode
objects. We never ended up using this, though, but there's still a lot
of room for speedups and more memory efficiency because of this design.

Like I already mentioned, PyObjects are also easier to extend at C level
- adding new variables to the object at the end is easy with PyObjects.
It's difficult for PyVarObjects, since you always have to take the
current size of the object into account and you always have to use
indirection to get at the extra variables due to the undefined offset of
the variables.

How much speedup do you get when you compare the pybench test with
KEEPALIVE_SIZE_LIMIT = 200 compared to your patched version ?

__
Tracker <[EMAIL PROTECTED]>

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