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
> [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
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
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
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
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
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
"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
> 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
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
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
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
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
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
14 matches
Mail list logo