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.
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 way to get the actual
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
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 (modelled
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's currently
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 contains the
decorator
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
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.
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
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 just
[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
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 restarted the
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
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
worn
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 just
[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 functional.
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 vague).
[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 functools for a different
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
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 code in
[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
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 *
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 (though functools is
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
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
functools due to the
[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
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 whatever.
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 environment
[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
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 suggested as a
30 matches
Mail list logo
