Re: [Python-Dev] Buildbot questions
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, what the > precise buildbot incantation would be, I don't know. 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... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automated Python testing
"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, mwh -- well, take it from an old hand: the only reason it would be easier to program in C is that you can't easily express complex problems in C, so you don't. -- Erik Naggum, comp.lang.lisp ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
> 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... > print self.x + a + b > > Foo(10).bar(20, 30) # ...but only two explicit parameters > #is presented > > This document proposes to change this, as the next example shows: > > Example 2 (Python 3.0): > --- > > class Foo: > def __init__(x): # 1: Implicit self > .x = x # 2: Brief form of: self.x = x > def bar(a, b): # 3: Two arguments... > print .x + a + b > > Foo(10).bar(20, 30) # ...and exactly two parameters In my case, I think that the problem of _self_ is mainly in the method definition. It's a little "hard" to understand why you have to use myFunction(self, otherArgs) when you create a class method. But the use of self in the code of the method is a good thing because it allow you to clearly say that you are working on a class property. In my case, I would like to have the following syntax in Python 3.0 : class Foo: def __init__(x): self.x = x def bar(a, b): print self.x + a + b My 0.2€ ;) -- Fabien SCHWOB ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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... > print .x + a + b > > f = Foo(10).bar # We agree this accepts 2 arguments > f = Foo.bar # How many arguments does f accept? > f = Foo.__dict__["bar"] # How many arguments does it accept now? I think this might return things very similar to what are returned now. The only reasonable alternative I can think of is that Foo.bar would return something that simply could not be called until it was bound, so this: inst = Foo() f = Foo.bar print f(inst, 1, 2) would have to be translated to this this: inst = Foo() f = Foo.bar meth = bind(f, inst) print meth(1, 2) It seems clear given the rest of the proposal that this second form will work, it's just a question of whether the first form will work at all. Personally I find the first form is rather uncommon anyway, and 50% of the time I write it it's a bug. So the more explicit second form would be fine with me. Well... it becomes more complex for decorators, I guess: def printargs(func): def replacement(*args, **kw): print args, kw return func(*args, **kw) return replacement class Foo: @printargs def null(a): pass What is printargs going to print? Will it even work? I'd guess you'd have to do: def printargs(func): def replacement(*args, **kw): print args, kw return bind(func, self)(*args, **kw) return replacement But what does that do if you apply printargs to a function that isn't a method? I generally have found it awkard to apply decorators to both methods and functions, except when the decorators pass through all the arguments unchanged (as printargs does). But I don't know if this is an improvement; I guess it depends on what bind(func, self) does outside of a method invocation. I think self should be undefined in that case. Well, I guess you could do: def printargs(func): def replacement(*args, **kw): print args, kw try: bound = bind(func, self, class) except NameError: try: bound = bind(func, None, class) except NameError: bound = func return bound(*args, **kw) return replacement Ugh. > The answer to the first question *has* to be 3, or we lose too much > functionality - but that's seriously surprising (the method appears to > require > two arguments when its defined, but actually requires 3 due to its being > retrieved from a class). And it still requires that a distinction be made > between instance, class and static methods in order to control the signature > of the retrieved method. > > However, that answer creates its own problems - what if we have a 3-argument > function that does exactly what we want our method to do? We'd need some way > of signalling to the class that the function should be left alone when being > retrieved from the class, but have the first argument bound automatically > when > being retrieved from an instance. > > This is where the "Explicit is better than implicit" and "Practicality beats > purity" *both* kick in in favour of explicit self and class_ parameters - the > signature of the retrieved function is exactly what the source code says it > is, because there aren't any implicit parameters getting slipped into the > parameter list when you aren't looking. > > As I see it, the real issue is that people are often coming from a Java or > C++ > background where you can't manipulate functions and classes as first-class > objects - the idea that the instance method signature could be written to > describe the signature of the unbound method returned by "Foo.bar" rather > than > the bound method returned by "Foo().bar" is an entirely foreign concept. I disagree; I'm 100% comfortable and have internalized Python's use of an explicit self parameter, but it still doesn't feel more explicit or practical than the traditional way of writing out methods in other languages. I'm inclined to say that this might be too substantial of a change to Python, but I don't think the current way method definitions work is particular elegant, and it hasn't really grown on me over all these years. I still frequently spell method signatures incorrectly. And I can't explain the current situation to a new user, except to say "this is just the way it is", because the explanation only makes sense when you are much further into the language. And don't get me started on the error messages when you get the parameter count wrong... (As an aside directed at the original PEP, I think d
Re: [Python-Dev] Buildbot questions
[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 incantation would be, I don't know. (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 what they are doing. 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. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Compiler warnings for 64-bit portability problems
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): remark #1682: implicit conversion of a 64-bit integral type to a
smaller integral type (potential portability problem)
return x;
^
If you just want the latter warning, pass -Wp64.
Regards,
Martin
P.S. In case you want to install it on a Debian AMD64 system,
here is the procedure:
1. register at
https://registrationcenter.intel.com/EvalCenter/EvalForm.aspx?ProductID=408
2. download and unpack the l_cc_c_9.0.030 tarfile.
3. don't try alien, it won't work.
4. don't try the Intel install.sh, it won't work
(atleast, it didn't work for me)
5. Instead, install with 'rpm -i --nodeps *.em64t.rpm'
6. edit /opt/intel/cce/9.0/bin/icc, replacing all
occurrences of with /opt/intel/cce/9.0
7. Put the *.lic file that Intel sent you into
/opt/intel/cce/9.0/bin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Draft proposal: Implicit self in Python 3.0
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 keep things simple, it should have the same number of positional arguments no matter how you retrieve it -- think of self and cls as keyword arguments that we currently write in an odd manner. >class Foo: >def __init__(x): # 1: Implicit self >.x = x # 2: Brief form of: self.x = x >def bar(a, b): # 3: Two arguments... >print .x + a + b >f = Foo(10).bar # We agree this accepts 2 arguments >f = Foo.bar # How many arguments does f accept? >f = Foo.__dict__["bar"] # How many arguments does it accept now? > The answer to the first question *has* to be 3, > or we lose too much functionality No, it should be 2. If you use it as a staticmethod, there isn't any problem. If you really want a method outside of its context, then pass self (or cls) as a keyword. f(4,5,self=Foo(10)) (I also think we could use class as the keyword, since class=expression is different from class Name: but that is a separate question.) If you like having self at the front -- well, wasn't the "keywords must be last" restriction likely to go away even before python 3.0? > ... a Java or C++ background where > you can't manipulate functions and classes as > first-class objects - the idea that the instance > method signature could be written to describe > the signature of the unbound method returned > by "Foo.bar" rather than the bound method > returned by "Foo().bar" is an entirely foreign > concept. I find it sort of strange that the signatures are different in the first place. I prefer the one without boilerplate. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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, Armin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 the question "How many > positional arguments does the function have if I retrieve it from the class, > rather than from an instance?" (this is the common concern for almost all > proposals to remove the explicit self and class_ slots). In this case, the function always (!!!) has fixed number of positional arguments equal to number of positional parameters inside the function definition: >>> def func(a, b): ... print class, self, a, b ... >>> class Foo: ... bar = func ... >>> instance = Foo() >>> func(1, 2) # there are 2 arguments None None 1 2 # <- class and self both equal to None >>> Foo.bar(1, 2) # 2 arguments again!! None 1 2# <- self is equal to None >>> instance.bar(1, 2) # 2 arguments always!!! 1 2 Nick Coghlan wrote: > To sum the proposal up in my own words: >Eliminate the need for explicit class and self slots in class > and instance methods by implicitly providing those slots on all > functions. Yes, I think, it is what I mean. With my proposal, 'self' is no longer the first explicit or implicit positional argument (!), instead, it is 'pseudo-argument', the value of which is equal to function's 'im_self' attribute. Any function contains two special read-only attributes: 'im_class' and 'im_self', and values of this attributes are accessible inside function body as values of 'class' and 'self' pseudo-arguments. Any function has this attributes, for ordinary function their values are set to 'None'. Example: >>> # Python 3.0 >>> def f(): return class, self >>> f() (None, None) There is new built-in function: bind(old_function, self_, class_=None) -> new_function The result is the new function with the same code object which the old function had, but with different im_class and im_self attributes values. - If both self_ and class_ arguments are None, then 'im_class' and 'im_self' attributes of new function is set to equal to None. - If self_ is not None, then class_ must be None or self_.__class__. 'im_self' attribute of new function is set to self_, and im_class attribute is set to self_.__class__ - If self_ is None but class_ is not None, then 'im_self' attribute is set to None, and 'im_class' attribute is set to class_ Consider this expression (extraction of a method from a class): x = Foo.bar This expression is equivalent of: x = bind(Foo.__dict__["bar"], None, Foo) After this, x.im_class is Foo and x.im_self is None The type.__getattribute__ contains implementation of this Consider next expression (extraction of a method from an instance): y = instance.bar This expression is equivalent of: y = bind(instance.__class__.__dict__["bar"], instance) After this, y.im_class is instance.__class__ and y.im_self is instance. The object.__getattribute__ is responsible for this Ian Bicking wrote: > Well... it becomes more complex for decorators, I guess: > >def printargs(func): >def replacement(*args, **kw): >print args, kw >return func(*args, **kw) >return replacement >class Foo: >@printargs >def null(a): pass > > What is printargs going to print? Will it even work? I'd guess you'd > have to do: > >def printargs(func): >def replacement(*args, **kw): >print args, kw >return bind(func, self)(*args, **kw) >return replacement I think, it should be: def printargs(func): def replacement(*args, **kw): print args, kw return bind(func, self, class)(*args, **kw) return replacement Yep, the code in decorators will be more complicated than it is today. I did not get it before... > I guess it depends on what bind(func, self) does outside of > a method invocation. I think self should be undefined in that case. 'self' will be None in that case. Any function has 'self' pseudo-argument, but in a plain function (not a method) 'self' and 'class' both equal to None. -- Best regards, Alexandermailto:[EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 discussion to comp.lang.python. Yes please. This won't change. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
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 what they are doing. I know how to set up full vs. incremental *builders*; they would appear in different lanes in the Waterfall, and they would operate on different build directories. I don't think I want additional lanes to the Waterfall. > 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? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
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) such things is that there is a potential for abuse. Of course, in this case, we could wait for the abuse to happen. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Automated Python testing
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 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
> > 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 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", which
we sometimes want.
The current problem with this is that I don't know if the build step
objects have access to a local data store -- so it could, say, count how
many builds have been done to know to clobber every tenth one. The
current code just chooses to clobber for any build on Sunday. Not a very
satisfying solution.
Brian,
Is there a way for build steps to maintain some state?
clipped from the build master's master.cfg -
...
class SVNEx(step.SVN):
"""A SVN Source build step that adds the ability for the Source
"mode" to be a combination of "update" and "clobber". This is useful if
your general just want to update the source tree from source code
control,
but occassionally want to clobber and start fresh.
To use this functionality use mode="update_and_clobber_occassionally".
To control when "occassionally" is now override the "should_clobber"
method. The default implementation is currently hardcoded to
"every Sunday". (This is a HACK. Perhaps there should be constructor
options to clobber every Nth time or to have cron-like arguments -- see
"Nightly" in scheduler.py. I don't know if "steps" have access to a
local
data store to be able to do this -- e.g. keep a counter.)
Ideally this would be an option of the base "Source" class in
buildbot/process/step.py.
"""
def __init__(self, **kwargs):
if kwargs.has_key("mode") \
and kwargs["mode"] == "update_and_clobber_occassionally":
self.update_and_clobber_occassionally = True
kwargs["mode"] = "update"
else:
self.update_and_clobber_occassionally = False
step.SVN.__init__(self, **kwargs)
def should_clobber(self):
from datetime import date
is_sunday = date.today().weekday() == 6 # it is Sunday
from twisted.python import log
log.msg("should_clobber? %s", (is_sunday and "yes" or "no"))
return is_sunday
def startVC(self, *args, **kwargs):
if self.update_and_clobber_occassionally:
if self.should_clobber():
self.args["mode"] = "clobber"
else:
self.args["mode"] = "update"
step.SVN.startVC(self, *args, **kwargs)
python_factory = factory.GNUAutoconf(
s(SVNEx, svnurl="http://svn.python.org/projects/python/trunk";,
mode="update_and_clobber_occassionally"),
test=["make", "test"], # use `make testall`?
)
# Then use python_factory as something like so:
#c['builders'] = [
#{'name': "linux-x86",
# 'slavename': "...",
# 'builddir': "python",
# 'factory': python_factory,
# },
#...
#]
clipped from the build master's master.cfg -
Cheers,
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
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", which > we sometimes want. Ah, but that would require changes to the slaves, right? I would prefer a solution that avoids that. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
[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 we usually want, and "clobber", which > > we sometimes want. > > Ah, but that would require changes to the slaves, right? I would > prefer a solution that avoids that. I don't think so. In my little test setup I didn't have to make any change to the slave. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PEP: Using ssize_t as the index type
[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 lose that completely. > > I still hope I can write a C parser some day that does > ParseTuple/BuildValue checking. 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 is harder. http://www.tortall.net/mu/static/fmtcheck.py?raw - it takes a list of directories to os.walk for c source files. Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PEP: Using ssize_t as the index type
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 is harder. Perhaps you could use Synopsis to parse the C code? http://synopsis.fresco.org/ I'm hoping to look into this more. IIRC, it generates an AST from the C source which you can iterate over to find problems. It's got Python APIs. I was hoping it could provide the basis for a static analysis tool to help find local memory (ref) leaks among other things. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
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 of known users. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0
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 discussed there again and again or elsewhere on the web ( e.g. in Bruce Eckels blog on Artima )? Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
