Re: [Python-Dev] Partial function application 'from the right'

2009-02-06 Thread Xavier Morel 

On 5 Feb 2009, at 23:54 , Steven D'Aprano wrote:

Raymond Hettinger wrote:

The arguments for and against the patch could be brought against  
partial()

itself, so I don't understand the -1's at all.


Quite so, but that doesn't justify adding more capabilities to  
partial().

I concur with Collin.  Lever arguments are a road to bloat.


One person's "bloat" is another person's rich and complete toolbox.

> "In for a penny, in for a pound" is not a language design principle.

Neither are "slippery slope" arguments.

One of the real problems with partial() and its variants is that  
they provide almost no advantage over an equivalent lambda.


How about speed? I don't have a recent version of Python here to  
test, but my recollection is that partial is significantly faster  
than lambda. And even if it currently isn't, there could be (is?)  
more opportunity to optimize partial.


I guess that the voting on this is going to be fall along functional  
lines: those who like functional languages will vote +1 on partial  
and co, and those who don't will vote -1.


While I don't dislike partial(), I'd rather see one good use-case  
for partial_right() to be removed: built-ins that don't accept  
keywords. From Ben North's post starting this thread:


"I find 'functools.partial' useful, but occasionally I'm unable to  
use it because it lacks a 'from the right' version.  E.g., to create  
a function which splits a string on commas, you can't say


  # Won't work when called:
  split_comma = partial(str.split, sep = ',')

and to create a 'log to base 10' function, you can't say

  # Won't work when called:
  log_10 = partial(math.log, base = 10.0)

because str.split and math.log don't take keyword arguments."

Wouldn't a `flip` function (reverse the order of the function's  
arguments) be more flexible and general than a `partial_right` one?


Your first case would become

  # we're not ignoring any argument, so we have to provide `maxsplit`
  split_comma = partial(flip(str.split), None, ',')

and the second one would yield

  log_10 = partial(flip(math.log), 10.0)

and if we only want to fill-in the rightmost argument, we can flip the  
result to get the original order back:


  split_5 = flip(partial(flip(str.split), 5))

While better kwargs support would be even better, there probably  
always will be kwarg-less functions/methods, so the ability to  
partially apply from the right stays interesting.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] negative PyLong integer -> unsigned integer, TypeError or OverflowError?

2009-02-06 Thread Lisandro Dalcin 
While hacking on Cython to make it recognize 'size_t' as a pre-defined
C integral type, I've found somethig that seems to be (pretty small)
inconsistency.

At Objects/longobject.c, you should see that in almost all cases
OverflowError is raised when a unsigned integral is requested from a
negative PyLong. However, See this one:

int
_PyLong_AsByteArray(PyLongObject* v,
   unsigned char* bytes, size_t n,
   int little_endian, int is_signed)
{
<...>
   if (!is_signed) {
   PyErr_SetString(PyExc_TypeError,
   "can't convert negative long to unsigned");
   return -1;
   }
<...>
}

Does it make sense to change that code to raise OverflowError?


-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] negative PyLong integer -> unsigned integer, TypeError or OverflowError?

2009-02-06 Thread Mark Dickinson 
On Fri, Feb 6, 2009 at 9:04 PM, Lisandro Dalcin  wrote:
> At Objects/longobject.c, you should see that in almost all cases
> OverflowError is raised when a unsigned integral is requested from a
> negative PyLong. However, See this one:
> [...]
>   if (!is_signed) {
>   PyErr_SetString(PyExc_TypeError,
>   "can't convert negative long to unsigned");
>   return -1;
>   }

I agree that TypeError seems wrong here.

Please could you file a bug report at bugs.python.org?

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Are property descriptors intended to be immutable?

2009-02-06 Thread Curt Hagenlocher 
...because they're not quite :).  Should I file this as a bug report?
(I get the same results under 2.6 and 3.0.)

PS C:\Program Files (x86)\CCP\EVE> C:\Python25\python.exe
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class x(object):
... @property
... def foo(self): return 1
...
>>> inst = x()
>>> inst.foo
1
>>> x.foo.__init__(lambda self: 2)
>>> inst.foo
2
>>> ^Z

--
Curt Hagenlocher
[email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] negative PyLong integer -> unsigned integer, TypeError or OverflowError?

2009-02-06 Thread Lisandro Dalcin 
Done, http://bugs.python.org/issue5175



On Fri, Feb 6, 2009 at 6:25 PM, Mark Dickinson  wrote:
> On Fri, Feb 6, 2009 at 9:04 PM, Lisandro Dalcin  wrote:
>> At Objects/longobject.c, you should see that in almost all cases
>> OverflowError is raised when a unsigned integral is requested from a
>> negative PyLong. However, See this one:
>> [...]
>>   if (!is_signed) {
>>   PyErr_SetString(PyExc_TypeError,
>>   "can't convert negative long to unsigned");
>>   return -1;
>>   }
>
> I agree that TypeError seems wrong here.
>
> Please could you file a bug report at bugs.python.org?
>
> Mark
>



-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Are property descriptors intended to be immutable?

2009-02-06 Thread Guido van Rossum 
On Fri, Feb 6, 2009 at 2:44 PM, Curt Hagenlocher  wrote:
> ...because they're not quite :).  Should I file this as a bug report?
> (I get the same results under 2.6 and 3.0.)
>
> PS C:\Program Files (x86)\CCP\EVE> C:\Python25\python.exe
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
 class x(object):
> ... @property
> ... def foo(self): return 1
> ...
 inst = x()
 inst.foo
> 1
 x.foo.__init__(lambda self: 2)
 inst.foo
> 2
 ^Z

No, this is just how it works. I hope they aren't documented as immuable?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Missing operator.call

2009-02-06 Thread Greg Ewing 

Guido van Rossum wrote:


Why is "call expr" a more enticing syntax than "yield *expr" ?


I was thinking it would read better when you're
using generators as lightweight threads, and you
want the one-level-deep nature of generators to
be hidden as much as possible.

The fact that yielding is going on is not of
interest in that situation -- it's just an
implementation detail. What you really want to
express is calling another function, but without
losing your status of coroutine-ness.

Another way of thinking about it is that it
allows you to abstract out a chunk of code from
a generator that contains a 'yield' and put it
into another function, and then call it in
a way that resembles an ordinary function call
as closely as possible.

Maybe 'call' isn't the best word for that, but
I haven't thought of anything better so far.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Partial function application 'from the right'

2009-02-06 Thread Nick Coghlan 
Ben North wrote:
> Hi,
> 
> My reading of the most recent set of emails on this topic is that the
> balance of opinion is against adding a 'partial_right' or 'partial.skip'
> feature.  I still think such a feature would be of real use, although I
> can see the arguments against adding it.  Is the conclusion 'no thanks',
> then?

There's a partial.skip patch on the tracker already:
http://bugs.python.org/issue1706256

While it has been rejected, chiming in still wouldn't hurt (in case we
ever decide to revisit the idea).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r69314 - sandbox/trunk/dbm_sqlite/alt/dbdict.py

2009-02-06 Thread Nick Coghlan 
raymond.hettinger wrote:
> Author: raymond.hettinger
> Date: Thu Feb  5 23:04:00 2009
> New Revision: 69314
> 
> Log:
> Can't get tempfile to reliably delete on error and persist otherwise.

You work on Windows, don't you Raymond?

What you were trying (setting tf.delete after the file was already open
 but before it was closed) would actually work on non-Windows platforms,
since the delete flag is only checked in the close() method.

On Windows, however, the tempfile code uses the _os.O_TEMPORARY flag at
creation time to tell *Windows* to delete the file when it gets closed.
In that case, writing to the delete attribute has no effect (since the
flag has already been set)

Perhaps the windows special casing should be removed so that the delete
flag on named temporary files can be effectively written to on all
platforms?

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Missing operator.call

2009-02-06 Thread Stephen J. Turnbull 
Greg Ewing writes:

 > The fact that yielding is going on is not of
 > interest in that situation -- it's just an
 > implementation detail. What you really want to
 > express is calling another function, but without
 > losing your status of coroutine-ness.

But doesn't "yield" in the sense of "yield the right of way" mean
exactly that?  Or am I not understanding what you mean by retain
status as a coreoutine?

I don't know if this is an argument for or against using "yield" in
this context.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Missing operator.call

2009-02-06 Thread Greg Ewing 

Stephen J. Turnbull wrote:

Greg Ewing writes:

 > The fact that yielding is going on is not of
 > interest in that situation

But doesn't "yield" in the sense of "yield the right of way" mean
exactly that?


I've no problem with using 'yield' when actually
giving up control. But the code making the call doesn't
think of itself as yielding. The called code may
want to yield, but the caller doesn't care about
that. It just wants to make the callee do its thing,
whatever it is.

Ideally the caller would be able to use a normal
function call, but Python generators don't work
that way. The next best thing is a slightly
different form of call syntax.

--
Greg

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Missing operator.call

2009-02-06 Thread Antoine Pitrou 
Greg Ewing  canterbury.ac.nz> writes:
> 
> I've no problem with using 'yield' when actually
> giving up control. But the code making the call doesn't
> think of itself as yielding. The called code may
> want to yield, but the caller doesn't care about
> that. It just wants to make the callee do its thing,
> whatever it is.

Sorry for saying that, but the more I read your explanations, the less I
understand them. In any case, using such a generic word as "call" for
generator-specific semantics looks highly confusing to me.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Missing operator.call

2009-02-06 Thread Guido van Rossum 
On Fri, Feb 6, 2009 at 3:20 AM, Greg Ewing  wrote:
> Stephen J. Turnbull wrote:
>>
>> Greg Ewing writes:
>>
>>  > The fact that yielding is going on is not of
>>  > interest in that situation
>>
>> But doesn't "yield" in the sense of "yield the right of way" mean
>> exactly that?
>
> I've no problem with using 'yield' when actually
> giving up control. But the code making the call doesn't
> think of itself as yielding. The called code may
> want to yield, but the caller doesn't care about
> that. It just wants to make the callee do its thing,
> whatever it is.
>
> Ideally the caller would be able to use a normal
> function call, but Python generators don't work
> that way. The next best thing is a slightly
> different form of call syntax.

The more I read your motivation the less comfortable I am with using
"call" for this purpose. It differs in so many details from a regular
call that you're doing your potential users a terrible disservice by
trying to pretend that it is something which it isn't, or that it
isn't something which it is. Those differences may not seem relevant
when sketching a solution, but they come back to haunt you when
debugging, for example.

It would be way too confusing to have "a different form of call" with
totally different semantics that nevertheless used the same
*terminology* as is used for regular calls. Imagine the confusion
happens when a newbie (maybe someone coming from Fortran :-) writes
"call foo(x)" instead of just "foo(x)" and their program totally
breaks. "But you told me to call foo" will be their rightful excuse.

You could go on, but so could I. A -1 it is.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] regrtest hangs on test_tk_guionly

2009-02-06 Thread Eric Smith 
In the trunk, test_tk_guionly hangs if I run it through regrtest. This 
is on a Fedora Core 6 box, without X installed.


If I run test_tk_guionly directly, it exits saying there's no DISPLAY 
set, which is what I'd expect:


--8<--
[trunk]$ ./python Lib/test/test_ttk_guionly.py
Traceback (most recent call last):
  File "Lib/test/test_ttk_guionly.py", line 11, in 
raise test_support.TestSkipped("ttk not available: %s" % msg)
test.test_support.TestSkipped: ttk not available: no display name and no 
$DISPLAY environment variable

[29788 refs]
--8<--


If I run regrtest with (or without) -v, it hangs without any output from 
test_tk_guionly:


--8<--
...
OK
test_transformer
Test multiple targets on the left hand side. ... ok

--
Ran 1 test in 0.020s

OK
test_ttk_guionly

--8<--


I'm not seeing a problem in the py3k branch. There, test_tk_guionly is 
skipped:


--8<--
test_ttk_guionly
test_ttk_guionly skipped -- ttk not available: no display name and no 
$DISPLAY environment variable

--8<--

I'm not sure how to further isolate this, since I can't duplicate it 
when running the test by itself. I'm mostly curious if anyone else is 
seeing this problem. If it's just me, I'll just switch to a Mac, where 
the problem doesn't occur (if for no other reason, because ttk is not 
available). If others are seeing a problem, I'll spend some time 
isolating it.


Is anyone else seeing this problem?

Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] regrtest hangs on test_tk_guionly

2009-02-06 Thread Guilherme Polo 
On Fri, Feb 6, 2009 at 1:14 PM, Eric Smith  wrote:
> In the trunk, test_tk_guionly

test_ttk_guionly, right ?

> hangs if I run it through regrtest. This is on
> a Fedora Core 6 box, without X installed.
>

Does it hang if you run it alone through regrtest, or, together with
all the other tests ?

> If I run test_tk_guionly directly, it exits saying there's no DISPLAY set,
> which is what I'd expect:
>
> --8<--
> [trunk]$ ./python Lib/test/test_ttk_guionly.py
> Traceback (most recent call last):
>  File "Lib/test/test_ttk_guionly.py", line 11, in 
>raise test_support.TestSkipped("ttk not available: %s" % msg)
> test.test_support.TestSkipped: ttk not available: no display name and no
> $DISPLAY environment variable
> [29788 refs]
> --8<--
>
>
> If I run regrtest with (or without) -v, it hangs without any output from
> test_tk_guionly:
>
> --8<--
> ...
> OK
> test_transformer
> Test multiple targets on the left hand side. ... ok
>
> --
> Ran 1 test in 0.020s
>
> OK
> test_ttk_guionly
> 
> --8<--
>
>
> I'm not seeing a problem in the py3k branch. There, test_tk_guionly is
> skipped:
>
> --8<--
> test_ttk_guionly
> test_ttk_guionly skipped -- ttk not available: no display name and no
> $DISPLAY environment variable
> --8<--
>
> I'm not sure how to further isolate this, since I can't duplicate it when
> running the test by itself. I'm mostly curious if anyone else is seeing this
> problem. If it's just me, I'll just switch to a Mac, where the problem
> doesn't occur (if for no other reason, because ttk is not available). If
> others are seeing a problem, I'll spend some time isolating it.
>
> Is anyone else seeing this problem?
>

I've noticed it, it is on http://bugs.python.org/issue5122

The second part of the issue description is actually unrelated to the
problem (or at least I'm almost sure it is), so you may discard it. I
wasn't able to duplicate it here, but I could try installing fedora
here to try reproducing and see if I can solve it.

> Eric.


-- 
-- Guilherme H. Polo Goncalves
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] regrtest hangs on test_tk_guionly

2009-02-06 Thread Eric Smith 

Guilherme Polo wrote:

On Fri, Feb 6, 2009 at 1:14 PM, Eric Smith  wrote:

In the trunk, test_tk_guionly


test_ttk_guionly, right ?


Right, sorry.


hangs if I run it through regrtest. This is on
a Fedora Core 6 box, without X installed.



Does it hang if you run it alone through regrtest, or, together with
all the other tests ?


It does not hang:
[trunk]$ ./python Lib/test/regrtest.py test_ttk_guionly
test_ttk_guionly
test_ttk_guionly skipped -- ttk not available: no display name and no 
$DISPLAY environment variable

1 test skipped:
test_ttk_guionly
1 skip unexpected on linux2:
test_ttk_guionly



I've noticed it, it is on http://bugs.python.org/issue5122

The second part of the issue description is actually unrelated to the
problem (or at least I'm almost sure it is), so you may discard it. I
wasn't able to duplicate it here, but I could try installing fedora
here to try reproducing and see if I can solve it.


Unfortunately I can't give you access to this machine. Maybe 
http://www.snakebite.org/ will be able to help.


If you think my issue is related to 5122, I'll reply to that issue and 
move the discussion there. I can test on a Fedora 10 box, too.


Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: IDLE on a Mac

2009-02-06 Thread ringhome 



Begin forwarded message:


From: [email protected]
Date: Feb 06, 2009 8:11:23 AM GMT-07:00
To: [email protected]
Subject: IDLE on a Mac

This mailing list is closed now. Please use [email protected]
instead.


From: ringhome 
Date: Feb 06, 2009 8:11:19 AM GMT-07:00
To: [email protected]
Subject: IDLE on a Mac


Hi.   First, I'd like to say how wonderful 3.0 is.  I'm using it at  
work, and it it indispensable.


I am, however, having a small difficulty at home on my Mac.   Not  
willing to wait for a nice, pre-packaged bundle, I went and  
downloaded the files and built 3.0 myself.  The issue comes from  
launching the IDLE.app from the Mac GUI versus a Terminal Shell.   
From the GUI, IDLE launches fine, but the FILE dropdown menu only  
has "Recent Files" in it.  No way to create new one, save, etc.


The README pages say to write to you if we're not sure if something  
is a feature or a bug So, here I am.  :)


Thanks.




___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] regrtest hangs on test_tk_guionly

2009-02-06 Thread Guilherme Polo 
On Fri, Feb 6, 2009 at 1:14 PM, Eric Smith  wrote:
> If it's just me, I'll just switch to a Mac, where the problem
> doesn't occur (if for no other reason, because ttk is not available). If
> others are seeing a problem, I'll spend some time isolating it.

If you move to Mac then you may end with an abort :)
See 
http://www.python.org/dev/buildbot/all/OS%20X%20x86%20trunk/builds/99/step-test/0

I tried asking emailing noller to ask what tcl is installed on that
mac but I got no answer, so in this case the buildslave serves me no
purpose. Apparently it doesn't happen all the time (after a change on
how the tcl interpreter was being created in the tests) but it still
happens sometimes. I also opened an issue for this, see:
http://bugs.python.org/issue5120, I ended up closing it after checking
that this noller buildslave stopped aborting but it still happens from
time to time.


-- 
-- Guilherme H. Polo Goncalves
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] regrtest hangs on test_tk_guionly

2009-02-06 Thread Guilherme Polo 
On Fri, Feb 6, 2009 at 1:34 PM, Eric Smith  wrote:
> If you think my issue is related to 5122, I'll reply to that issue and move
> the discussion there. I can test on a Fedora 10 box, too.

Eric, I've followed the "amd64 gentoo trunk" buildslave and noticed it
took a very long time on test_tcl (or test_ttk_guionly) and then ended
up getting the error described in the issue. As I see, the test hanged
and buildslave decided to quit.


-- 
-- Guilherme H. Polo Goncalves
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: IDLE on a Mac

2009-02-06 Thread Ned Deily 
In article <[email protected]>,
 ringhome  wrote:
> > I am, however, having a small difficulty at home on my Mac.   Not  
> > willing to wait for a nice, pre-packaged bundle, I went and  
> > downloaded the files and built 3.0 myself.  The issue comes from  
> > launching the IDLE.app from the Mac GUI versus a Terminal Shell.   
> > From the GUI, IDLE launches fine, but the FILE dropdown menu only  
> > has "Recent Files" in it.  No way to create new one, save, etc.
> >
> > The README pages say to write to you if we're not sure if something  
> > is a feature or a bug So, here I am.  :)

Definitely not a feature!  There are a few known problems with 3.x IDLE 
on OS X.  I'm in the final stages of testing several patches which, 
among other things should solve that problem.  In general, the issue 
tracker at  is the place to file bugs.  Check 
back in a couple of days.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2009-02-06 Thread Python tracker 

ACTIVITY SUMMARY (01/30/09 - 02/06/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2364 open (+44) / 14630 closed (+16) / 16994 total (+60)

Open issues with patches:   793

Average duration of open issues: 698 days.
Median duration of open issues:  10 days.

Open Issues Breakdown
   open  2341 (+44)
pending23 ( +0)

Issues Created Or Reopened (61)
___

"if 0: return" not raising SyntaxError   02/02/09
   http://bugs.python.org/issue1875reopened amaury.forgeotdarc
   patch, needs review 

Incorrect documentation for PyErr_BadInternalCall01/30/09
CLOSED http://bugs.python.org/issue5112created  md5i  
   

2.5.4.3 / test_posix failing on HPUX systems 01/30/09
   http://bugs.python.org/issue5113created  andreask  
   

2.5.4.3 / test_threading hangs   01/30/09
   http://bugs.python.org/issue5114created  andreask  
   

Extend subprocess.kill to be able to kill process groups 01/31/09
   http://bugs.python.org/issue5115created  erickt
   patch   

expose _CrtSetReportMode via the msvcrt module   01/31/09
   http://bugs.python.org/issue5116created  mhammond  
   patch, patch, needs review  

os.path.relpath problem with root directory  01/31/09
   http://bugs.python.org/issue5117created  eliben
   patch   

'%.2f' % 2.545 doesn't round correctly   01/31/09
CLOSED http://bugs.python.org/issue5118created  Ultrasick 
   

wide character parameter handling in ctypes  01/31/09
CLOSED http://bugs.python.org/issue5119created  jaraco
   

Disabling test_ttk_guionly on mac01/31/09
CLOSED http://bugs.python.org/issue5120created  gpolo 
   

PyRun_InteractiveLoop disagrees with documentation?  02/01/09
   http://bugs.python.org/issue5121created  bkuhn 
   

test_tcl and test_ttk_guionly don't like each other  02/01/09
   http://bugs.python.org/issue5122created  gpolo 
   patch   

Virus found in python-3.0.msi02/01/09
CLOSED http://bugs.python.org/issue5123created  hlqyq 
   

IDLE - pasting text doesn't delete selection 02/01/09
   http://bugs.python.org/issue5124created  weeble
   

Strange locale problem with Python 3 02/01/09
   http://bugs.python.org/issue5125created  retoo 
   

Space character returns false from isprintable() method  02/01/09
   http://bugs.python.org/issue5126created  dlfjessup 
   patch   

UnicodeEncodeError - I can't even see license02/02/09
   http://bugs.python.org/issue5127created  bupjae
   patch   

compileall: consider ctime   02/02/09
   http://bugs.python.org/issue5128created  gagern
   patch   

indentation in IDLE 2.6 different from IDLE 2.5, 2.4 or vim  02/02/09
   http://bugs.python.org/issue5129created  sy12  
   

Obsolete reference to "unicode" in glossary