Raymond Hettinger wrote:
>> In PEP 356, there is even a suggestion to "add builtin @deprecated
>> decorator?".
>
> Restraint please.
Well, that sentence wasn't meant in the sense of "we should add it" but
in the sense of "why shouldn't we put it in functools _if_ we add it, when
it's even sugges
[Tim]
>> Setup is hellish,
[Trent]
> Agreed, though I have everything going with my own testing buildbot
> master (everything for the trunk build that is). My only remaining
> problem is that I can't connect to python.org's master. (Following up
> with Martin.)
Looks like that got fixed.
>> The
Trent Mick wrote:
> Adding the /useenv means that one's PATH actually gets through. This is
> important for the _ssl.vproj build. It calls build_ssl.py which tries to
> find a Perl to use. Without "/useenv" Visual Studio is getting a PATH
> from somewhere else (presumably from its internal environm
Steven Elliott wrote:
> The important difference between builtins and globals is that with
> builtins both the compiler and the runtime can enumerate all
> references
> to builtins in a single consistent way. That is "True" can always be
> builtin #3 and "len" can always be builtin #17, or whate
[Tim Peters wrote]
> Setup is hellish
Any objections to:
Index: Tools/buildbot/build.bat
===
--- build.bat (revision 42982)
+++ build.bat (working copy)
@@ -1,3 +1,3 @@
@rem Used by the buildbot "compile"
On 3/12/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Nick Coghlan]
> > I agree it makes sense to have "decorator", "memoize", "deprecated" and
> > "partial" all being members of the same module, whether the name be
> > "functools" or "functional" (although I have a slight preference for
> >
> In PEP 356, there is even a suggestion to "add builtin @deprecated
> decorator?".
Restraint please. Go easy on the decorator additions.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
Nick Coghlan wrote:
> Alex Martelli wrote:
>> On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote:
>> ...
>>> memoize seems to fit into functools fairly well, though deprecated not
>>> so much. functools is similarly named to itertools, another module
>>> that
>>> is kind of vague in scope (thou
Joe Smith wrote:
> LISP was a disaster to use, so I doubt your language would have been any
> worse.
At least Lisp would let you say
(* 4 a c)
and not force you to write
(* (* 4 a) c)
My language would not have been so forgiving,
unless you were willing to define a bunch of
different *
[Tim Peters wrote]
> Setup is hellish,
Agreed, though I have everything going with my own testing buildbot
master (everything for the trunk build that is). My only remaining
problem is that I can't connect to python.org's master. (Following up
with Martin.)
> The second-worst part was figuring o
Steven Elliott wrote:
> a pyc file referencing a global in a module may
> have been compiled with a different version of that module (that is
> "some_module.some_global" can't compiled to single fixed index since
> stuff may shift around in "some_module").
Not sure I quite follow that. Since the
Guido van Rossum wrote:
> I don't see why everything that doesn't make sense to be shadowed
> ought to become a keyword.
That wasn't the reason. I was thinking it
would be nice if one could use True and False
instead of 1 and 0 in the knowledge that it
wasn't costing a couple of dictionary lookup
[Nick Coghlan]
> I agree it makes sense to have "decorator", "memoize", "deprecated" and
> "partial" all being members of the same module, whether the name be
> "functools" or "functional" (although I have a slight preference for
> "functools" due to the parallel with "itertools").
I like "functoo
Alex Martelli wrote:
> On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote:
> ...
>> memoize seems to fit into functools fairly well, though deprecated not
>> so much. functools is similarly named to itertools, another module
>> that
>> is kind of vague in scope (though functools is much more va
[Ian Bicking]
>> memoize seems to fit into functools fairly well, though deprecated not
>> so much. functools is similarly named to itertools, another module
>> that
>> is kind of vague in scope (though functools is much more vague).
>> partial would make just as much sense in functools as in func
On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote:
...
> memoize seems to fit into functools fairly well, though deprecated not
> so much. functools is similarly named to itertools, another module
> that
> is kind of vague in scope (though functools is much more vague).
> partial would make j
On 3/11/06, Joe Smith <[EMAIL PROTECTED]> wrote:
> Well the original was almost certainly a tongue-in-cheek reference to LISP.
> LISP was a disaster to use, so I doubt your language would have been any
> worse.
> The way one identifies a lisp programmer is to find the person whose paren
> keys have
Georg Brandl wrote:
>> Also, I thought we were trying to move away from modules that shared a name
>> with one of their public functions or classes. As it is, I'm not even sure
>> that a name like "decorator" gives the right emphasis.
>
> I thought about "decorators" too, that would make "decora
Tim Peters wrote:
>>It seems like the buildbot needs even more hand-holding on Windows:
>>it apparently doesn't survive a master stop/start cycle. While the
>>Unix buildbots reconnect, the Windows one doesn't.
>
>
> What makes us believe that?
The slave was reported as "idle" just before I resta
[Martin v. Löwis]
> It seems like the buildbot needs even more hand-holding on Windows:
> it apparently doesn't survive a master stop/start cycle. While the
> Unix buildbots reconnect, the Windows one doesn't.
What makes us believe that? My box was hibernating from 03:12 to
11:54 EST today, and c
Tim Peters wrote:
>>I believe I documented it many moons ago. I don't think CurrentVersion was
>>ever implemented (or possibly was for a very short time before being
>>removed). The "registered modules" concept was misguided and AFAIK is not
>>used by anyone - IMO it should be deprecated (if not
On 3/12/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
Staticmethods are for the rare case where you needdynamic class-based dispatch but don't have an instance around.Actually, I would argue that's what classmethods are for, not staticmethods. You may not envision a desire for having the class in the m
Hi Nicolas,
On Thu, Mar 02, 2006 at 01:55:03AM -0500, Nicolas Fleury wrote:
> (...) A use case is not hard to
> imagine, especially a private static method called only to build a class
> attribute.
Uh. I do this all the time, and the answer is simply: don't make that a
staticmethod. Staticme
Hi Ben,
On Mon, Feb 27, 2006 at 06:50:28PM -0500, Ben Cartwright wrote:
> > It seems to me that str.count is awfully slow. Is there some reason
> > for this?
stringobject.c could do with a good clean-up. It contains very similar
algorithms multiple times, in slightly different styles and with
d
Nick Coghlan wrote:
> Georg Brandl wrote:
>> Hi,
>>
>> to underlay my proposals with facts, I've written a simple decorator
>> module containing at the moment only the "decorator" decorator.
>>
>> http://python.org/sf/1448297
>>
>> It is implemented as a C extension module _decorator which conta
Nick Coghlan wrote:
> Georg Brandl wrote:
>> Hi,
>>
>> to underlay my proposals with facts, I've written a simple decorator
>> module containing at the moment only the "decorator" decorator.
Sorry, I forgot the initial comment which was meant to be "Thanks for moving
this proposal forward" :)
It
Georg Brandl wrote:
> Hi,
>
> to underlay my proposals with facts, I've written a simple decorator
> module containing at the moment only the "decorator" decorator.
>
> http://python.org/sf/1448297
>
> It is implemented as a C extension module _decorator which contains the
> decorator object (mo
Hi,
to underlay my proposals with facts, I've written a simple decorator
module containing at the moment only the "decorator" decorator.
http://python.org/sf/1448297
It is implemented as a C extension module _decorator which contains the
decorator object (modelled after the functional.partial ob
Thomas Wouters wrote:
> On 3/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Thomas Heller wrote:
>>> BTW: The buildbot reports ctypes test failures on the gentoo amd64
>> machine:
>>>
>> http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0
>>> Is there a wa
Tim Peters wrote:
> That would be great. A dupe of WinXP would also be great: I'm not
> going to keep my buildbot slave up all the time, or anywhere near all
> the time.
It seems like the buildbot needs even more hand-holding on Windows:
it apparently doesn't survive a master stop/start cycle. W
30 matches
Mail list logo
