Guido van Rossum wrote:
>>Yuk! This has been discussed again and again already. *Please* move
>>this discussion to comp.lang.python.
>
>
> Yes please. This won't change.
Then simply reject the PEP and the discussion can be stopped on
comp.lang.python too. Or why do you think it should be dis
On Saturday 07 January 2006 10:01, Martin v. Löwis wrote:
> The problem with irc-enabling (or web-enabling) such things is that
> there is a potential for abuse. Of course, in this case, we could
> wait for the abuse to happen.
That would be my vote. Worst comes to worst, we lock it down to a list
On 1/6/06, Michael Urman <[EMAIL PROTECTED]> wrote:
>
> I put together a non-parsing checker last month to help me feel more
> secure after http://python.org/sf/1365916. It's awful code, but the
> simple things are easy to change or extend. Fixing the false positives
> and other misinterpretations
[I just noticed that I sent this mail to just Martin when I meant it
for the list. Sorry Martin!]
On 1/5/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> More precisely, the printf style of function calling, and varargs
> functions. ISO C is pretty type safe, but with varargs functions,
> you lo
[Martin v. Loewis wrote]
> Trent Mick wrote:
> > I think I'm part of the way there with the following. I've subclassed
> > the "SVN" source build step to add support for new source mode:
> > "update_and_clobber_occassionally". Basically it (hackily) changes the
> > source type btwn "update", which
Trent Mick wrote:
> I think I'm part of the way there with the following. I've subclassed
> the "SVN" source build step to add support for new source mode:
> "update_and_clobber_occassionally". Basically it (hackily) changes the
> source type btwn "update", which we usually want, and "clobber", whi
> > To wipe out the build occassionally you could (presumably) add a
> > starting step to the Python 'builder' (in the build master.cfg) to
> > rm -rf $builddir
> > every, say, Sunday night.
>
> Sure, that would be the idea. How to formulate it?
I think I'm part of the way there with the fol
Michael Hudson wrote:
> #python-dev on freenode is ready and waiting should you decide to
> activate this :)
Ok, I added "him"; "his" nick is py-bb. Commands include "hello",
"status", "version". "force" is disabled.
Regards,
Martin
___
Python-Dev maili
Anthony Baxter wrote:
> At least with the way Twisted is set up, the buildbot also sits in an
> IRC channel and sends updates there. It can also be controlled from
> there. Is this worth doing? A 'force clean build' command could be
> added...
The problem with irc-enabling (or web-enabling) suc
Trent Mick wrote:
> (Still learning my buildbot mojo.) One idea would be to do what
> Mozilla's Tinderbox does: they have one set of builds that are
> incremental and one set that are full. Actually looking around on
> tinderbox.mozilla.org I could only find incremental builds so I'm not
> sure wha
On 1/6/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote:
> > There are three different peculiarity in Python 2.x
> > in respect of 'self' method argument:
>
> Yuk! This has been discussed again and again already. *Please* move
> this
Hello!
Ian Bicking wrote:
> (As an aside directed at the original PEP, I think discussion of leaving
> self out of expressions, e.g., ".x" for "self.x", should be separate
> from the rest of this PEP).
Yes, I'm fully agree.
Nick Coghlan wrote:
> The main concern I have is with the answer to th
Hi Alexander,
On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote:
> There are three different peculiarity in Python 2.x
> in respect of 'self' method argument:
Yuk! This has been discussed again and again already. *Please* move
this discussion to comp.lang.python.
A bientot,
Nick Coghlan wrote:
>Eliminate the need for explicit class and self
>slots in class and instance methods by
>implicitly providing those slots on all functions.
> How many positional arguments does the function
> have if I retrieve it from the class, rather than from
> an instance?
To
I just found that the intel compiler (icc 9.0)
also supports compiler warnings for portability
problems.
For the file
#include
int foo(size_t x)
{
return x;
}
it says (with -Wall)
a.c(3): remark #1418: external definition with no prior declaration
int foo(size_t x)
^
a.c(5):
[Martin v. Loewis wrote]
> I would like to do this in buildbot, but I'm not sure how to
> (i.e. wipe the build occasionally, but not every time).
>
> For example, I could imagine completely cleaning the build directory
> every time the build number % 10 == 0. Still, what the precise
> buildbot inc
Nick Coghlan wrote:
[...]
> Under the proposal being discussed, things become far less clear:
>
> class Foo:
> def __init__(x): # 1: Implicit self
> .x = x # 2: Brief form of: self.x = x
> def bar(a, b): # 3: Two arguments...
>
> Example 1 (Python 2.x):
> ---
>
> class Foo:
> def __init__(self, x): # 1: Explicit 'self' argument
> self.x = x # 2: 'self' must be used explicitly
> def bar(self, a, b): # 3: There are three arguments...
> p
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Currently, my buildbot isn't connected to IRC at all. If I ever
> enable that aspect, I'll use allowForce=False again to disable
> remotely invoking builds.
#python-dev on freenode is ready and waiting should you decide to
activate this :)
Cheers,
On Friday 06 January 2006 18:39, Martin v. Löwis wrote:
> I would like to do this in buildbot, but I'm not sure how to
> (i.e. wipe the build occasionally, but not every time).
>
> For example, I could imagine completely cleaning the build
> directory every time the build number % 10 == 0. Still, w
20 matches
Mail list logo
