Re: [Python-3000] Import system questions to be considered for Py3k

2006-07-17 Thread Nick Coghlan
A couple I accidentally left off my original list: Rationalise *.pkg and *.pth files - site.py processes *.pth files in the site-packages directory (the exact location being platform dependent) and adds things to sys.path as per the documentation of the site modu

Re: [Python-3000] Import system questions to be considered for Py3k

2006-07-17 Thread Frank Wierzbicki
> [1] http://www.jython.org/docs/registry.html > On the new Jython website the same content is here: http://www.jython.org/Project/userguide.html#the-jython-registry Though I don't think there are any changes to this content. -Frank ___ Python-3000 mai

[Python-3000] callable()

2006-07-17 Thread Andrew Koenig
I note in PEP 3000 the proposal to remove callable(), with the comment "just call the object and catch the exception." I think that's a bad idea, because it takes away the ability to separate the callability test from the first call. As a simple example, suppose you're writing a function that you

Re: [Python-3000] callable()

2006-07-17 Thread Calvin Spealman
I second that removal of callable() would be a bad idea. There are too many cases where it is not feasable to "just call the object and catch the exception". In the cases where the call would not happen until later than the test for callability, it would require then that any state changes caused b

Re: [Python-3000] callable()

2006-07-17 Thread Fernando Perez
Calvin Spealman wrote: > I second that removal of callable() would be a bad idea. There are too > many cases where it is not feasable to "just call the object and catch the > exception". In the cases where the call would not happen until later than > the test for callability, it would require then

Re: [Python-3000] callable()

2006-07-17 Thread Alex Martelli
On 7/17/06, Andrew Koenig <[EMAIL PROTECTED]> wrote: > I note in PEP 3000 the proposal to remove callable(), with the comment "just > call the object and catch the exception." > > I think that's a bad idea, because it takes away the ability to separate the > callability test from the first call. A

Re: [Python-3000] callable()

2006-07-17 Thread Collin Winter
On 7/17/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > [proposal for a type annotations-based version of callable()] To weigh in from the function/type annotations side of things, the consensus has been that Python 3000's function annotations are only a way to map parameter names to some arbitrary

Re: [Python-3000] callable()

2006-07-17 Thread Josiah Carlson
"Alex Martelli" <[EMAIL PROTECTED]> wrote: > > On 7/17/06, Andrew Koenig <[EMAIL PROTECTED]> wrote: > > I note in PEP 3000 the proposal to remove callable(), with the comment "just > > call the object and catch the exception." > > > > I think that's a bad idea, because it takes away the ability t

Re: [Python-3000] callable()

2006-07-17 Thread Baptiste Carvello
> If 'callable' is to stay, then in order to pull its weight it needs to > grow to provide a way to check "callable with the following signature" > -- at the very least in terms of numbers and names of arguments, > though (if py3k does gain some syntax for specifying argument types) > it might do m

Re: [Python-3000] callable()

2006-07-17 Thread Calvin Spealman
On 7/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: "Alex Martelli" <[EMAIL PROTECTED]> wrote:>> On 7/17/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:> > I note in PEP 3000 the proposal to remove callable(), with the comment "just > > call the object and catch the exception."> >> > I think that's

Re: [Python-3000] set literals

2006-07-17 Thread Michael Chermside
Guido writes: > I've also sometimes thought of unifying dicts and sets by implementing > set operations on the keys of dicts only. [... much discussion ...] > I'm still very much undecided but I don't want to rule this out for > py3k. Perhaps I'll write up a PEP and see how it flies. Playing w

Re: [Python-3000] set literals

2006-07-17 Thread Guido van Rossum
Hm. Your objections seem to be purely from a performance tuning POV. I think that if we agree that API-wise this is an improvement (fewer things to learn, set literals problem solved, and dicts grow some useful new methods) we should make a decision to do it and damn the tuning (I trust Raymond wil

Re: [Python-3000] set literals

2006-07-17 Thread CM
On 7/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: Hm. Your objections seem to be purely from a performance tuning POV. Ithink that if we agree that API-wise this is an improvement (fewerthings to learn, set literals problem solved, and dicts grow someuseful new methods) we should make a decis

Re: [Python-3000] set literals

2006-07-17 Thread Jack Diederich
On Mon, Jul 17, 2006 at 02:54:14PM -0700, Guido van Rossum wrote: > Hm. Your objections seem to be purely from a performance tuning POV. I > think that if we agree that API-wise this is an improvement (fewer > things to learn, set literals problem solved, and dicts grow some > useful new methods) w