Re: [Python-Dev] Automated Python testing (was Re: status of development documentation)

[skip]

Brett> As in some machine I might personally have left on?  That would
Brett> require a static IP which I don't know how common that will be.

Nah, just use dyndns.org.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] deque alternative (was: Linked lists)

[Josiah Carlson]

Tim Peters <[EMAIL PROTECTED]> wrote:
> Like Phillip Eby, I use 2-tuples for this when I feel the need
> (usually during a backtracking graph search, to keep track of paths
> back to the root in a space-efficient way), and am happy with that.

Then there's the whole Python list with append() and pop().  It takes a
method resolution and function call, but at least in Python 2.3, it is a
hair faster...

 - Josiah

>>> if 1:
... t = time.time()
... a = tuple()
... for i in xrange(100):
... a = (i, a)
... for i in xrange(100):
... i,a = a
... print time.time()-t
...
3.2858583
>>> if 1:
... t = time.time()
... a = []
... for i in xrange(100):
... a.append(i)
... for i in xrange(100):
... i = a.pop()
... print time.time()-t
...
3.0232943

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] file() vs open(), round 7

[Aahz]

Guido sez in 
http://mail.python.org/pipermail/python-dev/2004-July/045921.html
that it is not correct to recommend using ``file()`` instead of
``open()``.  However, because ``open()`` currently *is* an alias to
``file()``, we end up with the following problem (verified in current
HEAD) where doing ``help(open)`` brings up the docs for ``file()``:

>>> help(open)
Help on class file in module __builtin__:

class file(object)
 |  file(name[, mode[, buffering]]) -> file object
 |
 |  Open a file.  The mode can be 'r', 'w' or 'a' for reading (default),
[...]
 |  Note:  open() is an alias for file().

This is confusing.  I suggest that we make ``open()`` a factory function
right now.  (I'll submit a bug report (and possibly a patch) after I get
agreement.)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"Don't listen to schmucks on USENET when making legal decisions.  Hire
yourself a competent schmuck."  --USENET schmuck (aka Robert Kern)
___
Python-Dev mailing list
Python-Dev@python.org
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 (was Re: status of development documentation)

[Jean-Paul Calderone]

On Sun, 25 Dec 2005 16:54:44 -0800, Brett Cannon <[EMAIL PROTECTED]> wrote:
>On 12/25/05, Tim Peters <[EMAIL PROTECTED]> wrote:
>> [Tim]
>> >> Take a look at:
>> >>
>> >> http://buildbot.zope.org/
>> >>
>> >> That runs code from:
>> >>
>> >> http://buildbot.sourceforge.net/
>> >>
>> >> Someone sets up a "buildbot master" (that's what the Zope URL points
>> >> at), and then any number of people can volunteer to set up their boxes
>> >> as "buildbot slaves".
>>
>> [Brett]
>> > As in some machine I might personally have left on?
>>
>> Slaves have to be powered on to work, yes ;-)
>>
>> > That would require a static IP which I don't know how common that
>> > will be.
>>
>> Spend a few minutes skimming the buildbot docs -- I'm not an expert,
>> but it's a real system in real use, and they have solutions for the
>> obvious problems.  In this case, while the master passes out commands
>> to run and collects status, a slave _initiates_ communication with the
>> master.  A static IP for the master is good for that, but I figure the
>> slave can keep participating happily then for just as long as it can
>> keep a socket connection open with the master.
>>
>
>OK, so it is a pull from the slave side, not a push on the master side.
>
> [snip]
>
>See, that is what threw me; thinking that when the master knows a
>change happens it pushes out to the slaves.  I guess the master notes
>that there is a reason to do a new run and that is what the slaves are
>constantly checking with the master about.

The whole world isn't HTTP.  There is not necessarily any correlation 
between the party which initiates the TCP connection and the party 
which instigates a run.  Slaves connect to the master when they come 
online.  The master uses that connection to push commands to the slaves 
at the appropriate time.

Buildbot also supports having multiple slaves perform runs (or "builds", 
in buildbot terminology) for a particular configuration.  This means 
that several people can cooperate to give full coverage for a particular 
platform, even if none of them can leave a machine on 24/7.  You really 
do want 24/7 coverage for a supported platform, because utility declines 
rather rapidly as you fall short of this.  Developers tend to have an 
amazing knack for committing broken changes when the slave which would 
have noticed them is offline :)

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Build failure and problem on Windows

[Tim Peters]

[Thomas Heller]
>>> Building the svn trunk on Windows fails because Python\pyarena.c is
>>> missing in the pythoncore.vcproj file (I'm not yet up to speed with svn,
>>> otherwise I would have checked in a fix for this myself).
>>>
>>> Worse, when running the built exe it segfaults in Py_GetBuildInfo(),
>>> because it is picking up somehow a definition of #define BUILD 'b' (from
>>> cPickle.c? Could that be?)

[also Thomas Heller]
>> I should have known better, but BUILD is defined in the MSVC project
>> file as BUILD=60.

[Thomas Heller again]
> I've committed a fix for both (Hope these comments aren't off-topic
> nowadays for python-dev).

Not at all, according to me.  Nobody appears to be paying attention to
Python under VC 7.1 these days, but what you did here certainly helped
me when I got some time for it this weekend!  Thank you.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] deque alternative (was: Linked lists)

[Tim Peters]

[Martin Blais]
> ...
> Also, there is something incredibly elegant and simple and compact
> about the cons cell, maybe all we need is a good simple cons cell type
> and a nice interface on it, so you get both single-linked lists and
> trees at the same time...

The first "cons cell" C extension for Python I know about was written in 1994:

http://www.python.org/search/hypermail/python-1994q2/0110.html

There have been others, but the audience for them appears so small
that none catch on.

Like Phillip Eby, I use 2-tuples for this when I feel the need
(usually during a backtracking graph search, to keep track of paths
back to the root in a space-efficient way), and am happy with that.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] deque alternative (was: Linked lists)

[Aahz]

On Sun, Dec 25, 2005, Martin Blais wrote:
>
> I still haven't had time to cook a proper reply to Guido, but one
> thing I see is that many ppl on the list seem to think that because
> there aren't many use cases (that they can see), therefore there isn't
> much use for a list collection type.  

Please take this to comp.lang.python

Side note: nobody AFAICT has suggested that you drop this -- only that
getting a built-in is extremely unlikely.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"Don't listen to schmucks on USENET when making legal decisions.  Hire
yourself a competent schmuck."  --USENET schmuck (aka Robert Kern)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] deque alternative (was: Linked lists)

[Phillip J. Eby]

At 09:10 PM 12/25/2005 -0500, Martin Blais wrote:
>I still haven't had time to cook a proper reply to Guido, but one
>thing I see is that many ppl on the list seem to think that because
>there aren't many use cases (that they can see), therefore there isn't
>much use for a list collection type.  I would instead argue that
>because the list type has never been available, people have gotten
>used not to use them, and therefore settle with arrays and do not see
>a need for them.

Since I routinely use 2-item tuples (twoples?) as cons cells when I 
actually need a linked list, I think I'm in a good position to say that 
this isn't true.  Certainly it's not true for me.

Since Python effectively has single-character operations for both consing 
and car/cdr (a ',' on the right or left sides of an assignment statement 
respectively), as well as trivial truth testing for () as a "nil", suggests 
to me that anybody who wants a lispy list can easily have one.  For any 
application where such a structure excels (like shared sublists/trees and 
recursive traversals), it's so darn easy to use them in Python that I don't 
think anything special is needed.

Honestly, ISTM that the One Obvious Way to do lispy lists in Python is to 
just use two-tuples, with no special library functions.  Sequence packing 
and unpacking is extremely fast in Python, too, probably faster than any 
method calls to a more heavyweight builtin type could be.

Thus, I'm -1 on creating another cons type.  Why do this:

 foo = cons(bar, None)
 car_foo = foo.car
 cdr_foo = foo.cdr

when you can just do this:

 foo = bar, ()

 car_foo, cdr_foo = foo

How much simpler can you get?

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] deque alternative (was: Linked lists)

[Martin Blais]

On 12/25/05, Christian Tismer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Python's philosophy about (built-in) data types, inherited from ABC,
> > is to offer a few powerful clearly distinct choices rather than lots
> > of alternatives with overlapping usages. This reduces the time it
> > takes to choose a data type and reduces the risk of picking the wrong
> > type. (You seem to be indicating that this is indeed what's happening
> > to you in Lisp. :-)
>
> Speaking about the new dequeue type, I have the impression that
> this reasoning applies there a bit, too?
> Dequeues of course have applications, and I saw them used,
> especially by newcomers to the language. So I like their
> functionality.
>
> But actually, I'm not so convinced if we need to introduce
> a new datatype. How about an extension to normal lists
> that does a little tracking of use-cases and decides about
> changing its implementation upon the presence of inserts/deletes
> at the lower end of the list?
>
> I'm btw. not sure if this raises an implicit/explicitiness issue.
> My question is if it is necessary to put the burden about explicitly
> choosing a specialized two-ended list on the programmer, or if it
> is simple enough to make lists just do the right thing, if lists
> are used in a dequeue-style manner. Or is this maybe too much magic
> happening?

IMO it's a little bit too much magic.  Plus, if you pass these
instances around e.g. between libraries, how could you determine with
certainty the usage patterns without analysing the entire codebase?  I
think the user has to be involved.

A problem I see now is that there is no way for me to
indicate--whether there currently exists or not an appropriate data
type with the desired characteristic-- whether I want an array (Python
list) or a real list, both of which are really, really basic
fundamental kinds of data structures with very different complexity
characteristics.  The source code I write does not carry this
information and therefore if in the future it would become available
there won't be an easy way to convert code to take advantage of this. 
This choice, is being made in the programmer's head, but the
distinction blurred in the source code because lists are just not
there.

I still haven't had time to cook a proper reply to Guido, but one
thing I see is that many ppl on the list seem to think that because
there aren't many use cases (that they can see), therefore there isn't
much use for a list collection type.  I would instead argue that
because the list type has never been available, people have gotten
used not to use them, and therefore settle with arrays and do not see
a need for them.  When all you have is a hammer, everything seems to
be a nail.  When you don't have lists, you make do with arrays and you
think it's ok (and it pretty much is, in the sense that Python, at
least compared to C/LISP, is very slow, so it for the kinds of things
you use it for, it does not matter all that much).  When you're used
to having lists available, you miss being able to express that the
data structure you want should have the characteristics of a list,
with the intended performance characteristics.  Being able to select
between a list and an array is like having a bit more vocabulary in
natural languages.

I would agree with the use case condition if we were talking about a
very domain-specific collection type, but we're talking about lists
here... it's really fundamental stuff...

Also, there is something incredibly elegant and simple and compact
about the cons cell, maybe all we need is a good simple cons cell type
and a nice interface on it, so you get both single-linked lists and
trees at the same time...

(more after the xmas thing has passed)
___
Python-Dev mailing list
Python-Dev@python.org
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 (was Re: status of development documentation)

[Brett Cannon]

On 12/25/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim]
> >> Take a look at:
> >>
> >> http://buildbot.zope.org/
> >>
> >> That runs code from:
> >>
> >> http://buildbot.sourceforge.net/
> >>
> >> Someone sets up a "buildbot master" (that's what the Zope URL points
> >> at), and then any number of people can volunteer to set up their boxes
> >> as "buildbot slaves".
>
> [Brett]
> > As in some machine I might personally have left on?
>
> Slaves have to be powered on to work, yes ;-)
>
> > That would require a static IP which I don't know how common that
> > will be.
>
> Spend a few minutes skimming the buildbot docs -- I'm not an expert,
> but it's a real system in real use, and they have solutions for the
> obvious problems.  In this case, while the master passes out commands
> to run and collects status, a slave _initiates_ communication with the
> master.  A static IP for the master is good for that, but I figure the
> slave can keep participating happily then for just as long as it can
> keep a socket connection open with the master.
>

OK, so it is a pull from the slave side, not a push on the master side.

> If a slave goes away (network problem; powered off; whatever), that's
> fine too.  The master can't talk to it then, and the slave's column in
> the master's display will say the slave is offline.  Or, if it's been
> so long that all info about the slave has "scrolled off" the display,
> the column will just say "none" above it.  You can see a couple
> examples of that in the
>
> http://buildbot.zope.org
>
> display today, for some Windows slaves that have gone missing in action.
>
> > then again I am willing to bet that the Python community is big enough
> > that people who do have machines that are idle enough that we should
> > be able to get good coverage.  Wonder if we would have to worry about
> > result pollution from someone who thought it was funny to send in
> > false negatives?
>
> I wouldn't worry about it.  For one thing, while anyone can volunteer
> to participate, the buildbot master's admin has to set up config info
> for each specific slave they want to _allow_ to participate.  It's
> more like a moderated mailing list that way ;-)  A slave also needs to
> know a password (which the master's admin emails (for example) to the
> slave's admin if the former wants the latter to participate).
>
> ...
>
> >> One downside is that we seem unable to get an in-house Windows
> >> buildbot slave to work reliably, and so far don't even know whether that's
> >> because of Windows, the buildbot code, or flakiness in our internal
> >> network.  It seems quite reliable on Linux, though.
>
> > Well, it is written in Python so *someone* here should either be able
> > to fix it or properly blame it on Windows.  =)
>
> Yup!
>
> > The idea of the PSF paying to have some machines set up to run
> > consistent tests has come up multiple times.
>
> A brilliant part of the buildbot approach is that a sub-community
> claiming to care about a  platform (major or not) can put a bit of
> resource where their mouth is by offering part-time use of a box to
> run the checkout/build/test dance.  That way platform experts who
> presumably care about their platform are in charge of all aspects of
> setting their platform up.  No centralized "compile farm" can work as
> well, unless it has enough money to buy machines-- and expert
> caretakers --for umpteen off-the-wall OS variations.
>

I guess if someone complains about wanting better support for platform
X we could then say that we don't have a buildbot slave for it and if
they want to help the situation they can get one set up.  =)

> > I know Neal has said he would be willing to host the machines at his
> > house before (but I think this may have been before his relocation to
> > California).
>
> Looks like he's already running automated tests:
>
> http://docs.python.org/dev/results/
>
> The various steps there could be defined as buildbot actions, and then
> run on any number of boxes "whenever something changes".
>

See, that is what threw me; thinking that when the master knows a
change happens it pushes out to the slaves.  I guess the master notes
that there is a reason to do a new run and that is what the slaves are
constantly checking with the master about.

> > This whole situation of going two months without knowing that a major
> > platform is broken shows that this is a real problem and ignoring it is
> > probably not a good thing.  =)
>
> It's generally true that the sooner you find out something has broken,
> the easier it is to repair it.  For "minor" platforms, I'd say we have
> no idea whether the trunk has regressed wrt 2.4.2.  There's simply no
> way to know without trying it.
>

Right.  Part of the reason AIX, I am sure, keeps breaking.

> > If we ask for volunteer machines we could offer to put up company or
> > personal names on the buildbot page of those who have volunteered CPU
> > cycles.  I am sure that will help motivat

Re: [Python-Dev] status of development documentation

[Aahz]

On Sun, Dec 25, 2005, Tim Peters wrote:
>
> So, Merry Christmas to all, and there's no longer any reason to
> deprive yourself of the joy of upgrading to Windows ;-)

Much Grass!  I already upgraded to Windows, but it's turned off in favor
of my Linux box and iBook.

Yesterday I decided to try doing an svn checkout for the first time.  Has
anyone ever tried doing that from the top?  There's more than 18GB of
stuff, and it never actually completes.  (I'm mostly mentioning this as
FYI/FYA -- I'm doing it to exercise my new computer.)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"Don't listen to schmucks on USENET when making legal decisions.  Hire
yourself a competent schmuck."  --USENET schmuck (aka Robert Kern)
___
Python-Dev mailing list
Python-Dev@python.org
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 (was Re: status of development documentation)

[Tim Peters]

[Tim]
>> Take a look at:
>>
>> http://buildbot.zope.org/
>>
>> That runs code from:
>>
>> http://buildbot.sourceforge.net/
>>
>> Someone sets up a "buildbot master" (that's what the Zope URL points
>> at), and then any number of people can volunteer to set up their boxes
>> as "buildbot slaves".

[Brett]
> As in some machine I might personally have left on?

Slaves have to be powered on to work, yes ;-)

> That would require a static IP which I don't know how common that
> will be.

Spend a few minutes skimming the buildbot docs -- I'm not an expert,
but it's a real system in real use, and they have solutions for the
obvious problems.  In this case, while the master passes out commands
to run and collects status, a slave _initiates_ communication with the
master.  A static IP for the master is good for that, but I figure the
slave can keep participating happily then for just as long as it can
keep a socket connection open with the master.

If a slave goes away (network problem; powered off; whatever), that's
fine too.  The master can't talk to it then, and the slave's column in
the master's display will say the slave is offline.  Or, if it's been
so long that all info about the slave has "scrolled off" the display,
the column will just say "none" above it.  You can see a couple
examples of that in the

http://buildbot.zope.org

display today, for some Windows slaves that have gone missing in action.

> then again I am willing to bet that the Python community is big enough
> that people who do have machines that are idle enough that we should
> be able to get good coverage.  Wonder if we would have to worry about
> result pollution from someone who thought it was funny to send in
> false negatives?

I wouldn't worry about it.  For one thing, while anyone can volunteer
to participate, the buildbot master's admin has to set up config info
for each specific slave they want to _allow_ to participate.  It's
more like a moderated mailing list that way ;-)  A slave also needs to
know a password (which the master's admin emails (for example) to the
slave's admin if the former wants the latter to participate).

...

>> One downside is that we seem unable to get an in-house Windows
>> buildbot slave to work reliably, and so far don't even know whether that's
>> because of Windows, the buildbot code, or flakiness in our internal
>> network.  It seems quite reliable on Linux, though.

> Well, it is written in Python so *someone* here should either be able
> to fix it or properly blame it on Windows.  =)

Yup!

> The idea of the PSF paying to have some machines set up to run
> consistent tests has come up multiple times.

A brilliant part of the buildbot approach is that a sub-community
claiming to care about a  platform (major or not) can put a bit of
resource where their mouth is by offering part-time use of a box to
run the checkout/build/test dance.  That way platform experts who
presumably care about their platform are in charge of all aspects of
setting their platform up.  No centralized "compile farm" can work as
well, unless it has enough money to buy machines-- and expert
caretakers --for umpteen off-the-wall OS variations.

> I know Neal has said he would be willing to host the machines at his
> house before (but I think this may have been before his relocation to
> California).

Looks like he's already running automated tests:

http://docs.python.org/dev/results/

The various steps there could be defined as buildbot actions, and then
run on any number of boxes "whenever something changes".

> This whole situation of going two months without knowing that a major
> platform is broken shows that this is a real problem and ignoring it is
> probably not a good thing.  =)

It's generally true that the sooner you find out something has broken,
the easier it is to repair it.  For "minor" platforms, I'd say we have
no idea whether the trunk has regressed wrt 2.4.2.  There's simply no
way to know without trying it.

> If we ask for volunteer machines we could offer to put up company or
> personal names on the buildbot page of those who have volunteered CPU
> cycles.  I am sure that will help motivate companies and people to
> install the software on a spare machine.

Finding volunteers has been surprisingly (to me) difficult.  Most (but
not all) of the machines you see on the Zope page are ZC-internal
boxes, and, e.g., a Mac OS box is still missing.

> Heck, I would have no problem giving a specific company sole sponsorship
> kudos if they gave us boxes that covered enough core operating systems.

Cool too.

> Maybe this is something to bring up at the PSF meeting and to hash out
> at the sprints?

It primarly takes someone with access to "a python.org machine" to
volunteer to install and play admin for a buildbot master.  A
committee wouldn't actually help with that ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/

Re: [Python-Dev] Automated Python testing (was Re: status of development documentation)

[Fred L. Drake, Jr.]

On Sunday 25 December 2005 15:23, Brett Cannon wrote:
 > As in some machine I might personally have left on?  That would
 > require a static IP which I don't know how common that will be.  But

Only buildbot masters are required to have resolvable names (not necessarily 
static, though it helps; dynamic DNS is fine if the name propogation to the 
slaves is fast).  The slaves do not need to be reachable from the buildbot 
master, since the slave is responsible for contacting the master.


  -Fred

-- 
Fred L. Drake, Jr.   
___
Python-Dev mailing list
Python-Dev@python.org
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 (was Re: status of development documentation)

[Brett Cannon]

On 12/25/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> Take a look at:
>
> http://buildbot.zope.org/
>
> That runs code from:
>
> http://buildbot.sourceforge.net/
>
> Someone sets up a "buildbot master" (that's what the Zope URL points
> at), and then any number of people can volunteer to set up their boxes
> as "buildbot slaves".

As in some machine I might personally have left on?  That would
require a static IP which I don't know how common that will be.  But
then again I am willing to bet that the Python community is big enough
that people who do have machines that are idle enough that we should
be able to get good coverage.  Wonder if we would have to worry about
result pollution from someone who thought it was funny to send in
false negatives?

>  From time to time the buildbot master asks the
> slaves to do the checkout/build/test dance (or any other code dance
> you like), the slaves report results back to the master, and the
> master displays the slaves' results.
>
> If you look at the 2nd-leftmost column, you can see that the master
> knows when checkins have been done.  Checkins can trigger asking the
> slaves to run tests, and if the tests fail on some slave the master
> can send email saying so, including the list of checkins ("the
> blamelist") done since the last time that slave ran tests:
>
> The guilty developer can be identified and harassed without human
> intervention.
>
> :-)
>
> This really helps at Zope Corp.  One downside is that we seem unable
> to get an in-house Windows buildbot slave to work reliably, and so far
> don't even know whether that's because of Windows, the buildbot code,
> or flakiness in our internal network.  It seems quite reliable on
> Linux, though.

Well, it is written in Python so *someone* here should either be able
to fix it or properly blame it on Windows.  =)

The idea of the PSF paying to have some machines set up to run
consistent tests has come up multiple times.  I know Neal has said he
would be willing to host the machines at his house before (but I think
this may have been before his relocation to California).  This whole
situation of going two months without knowing that a major platform is
broken shows that this is a real problem and ignoring it is probably
not a good thing.  =)

If we ask for volunteer machines we could offer to put up company or
personal names on the buildbot page of those who have volunteered CPU
cycles.  I am sure that will help motivate companies and people to
install the software on a spare machine.  Heck, I would have no
problem giving a specific company sole sponsorship kudos if they gave
us boxes that covered enough core operating systems.

Maybe this is something to bring up at the PSF meeting and to hash out
at the sprints?

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NotImplemented reaching top-level

[Brett Cannon]

On 12/25/05, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Reinhold,
>
> On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote:
> > > that nobody fully understands the convoluted code paths of abstract.c
> > > any more :-(
> >
> > Time for a rewrite?
>

Maybe.  Also realize we will have a chance to clean it up when Python
3 comes around since the classic class stuff will be ripped out.  That
way we might have a chance to streamline the code.

> Of course, speaking of a rewrite, PyPy does the "right thing" in these
> two areas.  Won't happen to CPython, though.  There are too much
> backward-compatibility issues with the PyTypeObject structure; I think
> we're doomed with patching the bugs as they show up.
>
> Looking up in the language reference, I see no mention of NotImplemented
> in the page about __add__, __radd__, etc.  I guess it's a documentation
> bug as well, isn't it?  The current code base tries to implement the
> following behavior: Returning NotImplemented from any of the binary
> special methods (__xxx__, __rxxx__, __ixxx__) makes Python proceed as if
> the method was not defined in the first place.
>

This is what I always assumed the behaviour was supposed to be, so I
am quite happy to go with that.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Automated Python testing (was Re: status of development documentation)

[Tim Peters]

Take a look at:

http://buildbot.zope.org/

That runs code from:

http://buildbot.sourceforge.net/

Someone sets up a "buildbot master" (that's what the Zope URL points
at), and then any number of people can volunteer to set up their boxes
as "buildbot slaves".  From time to time the buildbot master asks the
slaves to do the checkout/build/test dance (or any other code dance
you like), the slaves report results back to the master, and the
master displays the slaves' results.

If you look at the 2nd-leftmost column, you can see that the master
knows when checkins have been done.  Checkins can trigger asking the
slaves to run tests, and if the tests fail on some slave the master
can send email saying so, including the list of checkins ("the
blamelist") done since the last time that slave ran tests:

The guilty developer can be identified and harassed without human
intervention.

:-)

This really helps at Zope Corp.  One downside is that we seem unable
to get an in-house Windows buildbot slave to work reliably, and so far
don't even know whether that's because of Windows, the buildbot code,
or flakiness in our internal network.  It seems quite reliable on
Linux, though.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NotImplemented reaching top-level

[Nick Coghlan]

Armin Rigo wrote:
> Hi Reinhold,
> 
> On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote:
>>> that nobody fully understands the convoluted code paths of abstract.c
>>> any more :-(
>> Time for a rewrite?
> 
> Of course, speaking of a rewrite, PyPy does the "right thing" in these
> two areas.  Won't happen to CPython, though.  There are too much
> backward-compatibility issues with the PyTypeObject structure; I think
> we're doomed with patching the bugs as they show up.
> 
> Looking up in the language reference, I see no mention of NotImplemented
> in the page about __add__, __radd__, etc.  I guess it's a documentation
> bug as well, isn't it?  The current code base tries to implement the
> following behavior: Returning NotImplemented from any of the binary
> special methods (__xxx__, __rxxx__, __ixxx__) makes Python proceed as if
> the method was not defined in the first place.
> 
> If we agree on this, I could propose a doc fix, a test, and appropriate
> bug fixes.

That sounds like the right definition to me (I believe this behaviour is what 
Raymond and Facundo were aiming for with the last round of updates to Decimal).

Regards,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] status of development documentation

[skip]

Tim> So, Merry Christmas to all, and there's no longer any reason to
Tim> deprive yourself of the joy of upgrading to Windows ;-)

Merry Christmas to you as well Tim.  Hopefully the bad-mood elf left after
seeing how happy you were to have figured out the build problems...  Oh, and
I'll get right on that Windows thing.  Where can I download that again?


Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] status of development documentation

[Tim Peters]

Santa sent me a bad-mood elf overnight, apparently just to motivate me ;-)

Since it's 2+ months after the fact, I doubt we'll ever know exactly
what went wrong here.  In outline:

Rev 39758 (the AST merge) left pythoncore.vcproj in an unusable state.
 That's the VC 7.1 project file that defines what goes into the core
Python DLL on Windows, and it was checked in with conflict markers
embedded.  VC couldn't load the resulting mess, so the Python DLL
couldn't be built anymore.

In rev 39791, MarkH removed the conflict markers and added
parsermodule.c (which had somehow gotten lost during the merge). 
Python then compiled again under VC7.1.  But looks like he didn't run
the tests -- or, like me, just assumed that all the test failures he
saw were universally-known breakage from the then-still-early days of
the AST merge (since most were obviously failures to compile
correctly, that was a tempting assumption).

It sat there then for two months.

As things turn out, rev 39758 also damaged pythoncore.vcproj in other,
non-syntactic ways:

- It removed tokenizer.c from the core DLL, but that's the correct
runtime tokenizer
  code.

- It added pgen.c and tokenizer_pgen.c to the core DLL.  The former is useless
  in the core DLL (I think), and including the latter was just wrong.

RaymondH would not have noticed anything wrong because he still runs
with VC6, and the AST merge didn't muck with _those_ project files.

Anyway, after removing pgen.c and tokenizer_pgen.c, and adding
tokenizer.c, test_builtin and test_pep263 pass again.  In fact, all
the -uall tests pass again (yippee!):

264 tests OK.
38 tests skipped:
test__locale test_aepack test_al test_applesingle test_bsddb185
test_cd test_cl test_commands test_crypt test_curses test_dbm
test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp
test_hashlib_speed test_imgfile test_ioctl test_linuxaudiodev
test_macfs test_macostools test_mhlib test_nis test_openpty
test_ossaudiodev test_plistlib test_poll test_posix test_pty
test_pwd test_resource test_scriptpackages test_signal
test_sunaudiodev test_threadsignals test_timing
Those skips are all expected on win32.

So, Merry Christmas to all, and there's no longer any reason to
deprive yourself of the joy of upgrading to Windows ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NotImplemented reaching top-level

[Armin Rigo]

Hi Reinhold,

On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote:
> > that nobody fully understands the convoluted code paths of abstract.c
> > any more :-(
> 
> Time for a rewrite?

Of course, speaking of a rewrite, PyPy does the "right thing" in these
two areas.  Won't happen to CPython, though.  There are too much
backward-compatibility issues with the PyTypeObject structure; I think
we're doomed with patching the bugs as they show up.

Looking up in the language reference, I see no mention of NotImplemented
in the page about __add__, __radd__, etc.  I guess it's a documentation
bug as well, isn't it?  The current code base tries to implement the
following behavior: Returning NotImplemented from any of the binary
special methods (__xxx__, __rxxx__, __ixxx__) makes Python proceed as if
the method was not defined in the first place.

If we agree on this, I could propose a doc fix, a test, and appropriate
bug fixes.


A bientot,

Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] status of development documentation

[Nick Coghlan]

Brett Cannon wrote:
> On 12/23/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>> On 12/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> So for at least the time being they go up nightly
>>> (http://www.trentm.com/python).  I don't know what Trent did to make that
>>> happen, but he did it fairly quickly.  I doubt it would be hard to replicate
>>> on the docs server.
>> I couldn't let Trent have all the fun.
>>
>> http://docs.python.org/dev/
>>
> 
> Cool!  Thanks to Trent for sparking Neal, and thanks to Neal for
> feeling the fire under our arses for getting this done.

Indeed - thanks folks.

>> And hopefully of interest to many here:
>>
>> http://docs.python.org/dev/results/
>>
>> These are the results of svn update, configure, build, test, install
>> and the doc run.
>> Run on the PSFs box and updated every 12 hours.  I currently have it
>> send mail to me if there are any test failures.  I will probably
>> update that to python-checkins or maybe even python-dev depending on
>> what people think.  I'm not likely to be around much for the rest of
>> the year, so I don't want to turn it on just yet.
>>
> 
> python-checkins seems the most reasonable.  But I would have no
> problem with it going to python-dev.

If the message gets sent to python-checkins, then it should be fairly easy to 
identify candidate culprits (especially if the script is designed to send the 
email anytime the update actually retrieves new files from the repository, 
even if the tests all pass).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] deque alternative (was: Linked lists)

[Christian Tismer]

Guido van Rossum wrote:

> Python's philosophy about (built-in) data types, inherited from ABC,
> is to offer a few powerful clearly distinct choices rather than lots
> of alternatives with overlapping usages. This reduces the time it
> takes to choose a data type and reduces the risk of picking the wrong
> type. (You seem to be indicating that this is indeed what's happening
> to you in Lisp. :-)

Speaking about the new dequeue type, I have the impression that
this reasoning applies there a bit, too?
Dequeues of course have applications, and I saw them used,
especially by newcomers to the language. So I like their
functionality.

But actually, I'm not so convinced if we need to introduce
a new datatype. How about an extension to normal lists
that does a little tracking of use-cases and decides about
changing its implementation upon the presence of inserts/deletes
at the lower end of the list?

I'm btw. not sure if this raises an implicit/explicitiness issue.
My question is if it is necessary to put the burden about explicitly
choosing a specialized two-ended list on the programmer, or if it
is simple enough to make lists just do the right thing, if lists
are used in a dequeue-style manner. Or is this maybe too much magic
happening?

merry christmas -- chris

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NotImplemented reaching top-level

[Reinhold Birkenfeld]

Armin Rigo wrote:
> Hi Facundo,
> 
> On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote:
>> >>> d += 1.2
>> >>> d
>> NotImplemented
> 
> The situation appears to be a mess.  Some combinations of specific
> operators fail to convert NotImplemented to a TypeError, depending on
> old- or new-style-class-ness, although this is clearly a bug (e.g. in an
> example like yours but using -= instead of +=, we get the correct
> TypeError.)
> 
> Obviously, we need to write some comprehensive tests about this.  But
> now I just found out that the old, still-pending SF bug #847024 about
> A()*5 in new-style classes hasn't been given any attention; my theory is
> that nobody fully understands the convoluted code paths of abstract.c
> any more :-(

Time for a rewrite?

Reinhold

-- 
Mail address is perfectly valid!

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NotImplemented reaching top-level

[Armin Rigo]

Hi Facundo,

On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote:
> >>> d += 1.2
> >>> d
> NotImplemented

The situation appears to be a mess.  Some combinations of specific
operators fail to convert NotImplemented to a TypeError, depending on
old- or new-style-class-ness, although this is clearly a bug (e.g. in an
example like yours but using -= instead of +=, we get the correct
TypeError.)

Obviously, we need to write some comprehensive tests about this.  But
now I just found out that the old, still-pending SF bug #847024 about
A()*5 in new-style classes hasn't been given any attention; my theory is
that nobody fully understands the convoluted code paths of abstract.c
any more :-(


A bientot,

Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com