[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[C. Titus Brown via Python-Dev]

Hi all,

as a moderator of python-ideas, I’ve asked postmaster to place python-ideas 
into emergency moderation. (I do not have the tools to do so myself.) I’m 
willing to review messages individually as needed.

best,
—titus

> On Jun 29, 2020, at 9:24 AM, Abdur-Rahmaan Janhangeer  
> wrote:
> 
> Threads like these are meaningless, does not provide any learning
> value and is nowhere near the single vs double quote thread.
> 
> It opens the gap for people who are not concerned about development
> jump in the game shifting the focus away while nurturing a culture of thrash
> I mean you tend to ignore threads from python-dev and python-ideas which 
> is not probably why you subscribed in the first place
> 
> This is not the first time i am saying that you can fly around the world on 
> official
> Python mailing lists. But it's regrettable that it's the first time i am 
> seeing people
> telling that they should educate others and things like that. It can be based 
> on the
> argument and circle around it but personal attacks are off limit
> 
> If this was a Github issue, i don't think you list moderators would have 
> dragged it
> around that much. Worst case scenario, someone would have been pinged and 
> the issue taken care of. A PR or closing and you are done.
> 
> I raised the issue of closing a mail thread before and the impractical nature 
> of 
> it was discussed but maybe warnings and continued posting after the warning
> results in ban can be enforced
> 
> And it's annoying that it got dragged to two mailing lists. I respect Python 
> people
> and i am always eager to follow some C code discussions, deprecating this C 
> API
> etc. It's a new world for me.
> 
> Maybe active list members should sign a convention or a vetting process can 
> be setup
> before we can discuss it on the lists. Not ideal but might be useful.
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> compileralchemy | blog 
> github
> Mauritius
> 
> 
> On Mon, Jun 29, 2020 at 8:11 PM David Mertz  wrote:
> The commit message is simply silly. It introduces numerous contentious and 
> false claims that have nothing whatsoever to do with the small wording 
> change. It misunderstands how language, culture, history, and indeed white 
> supremacism, work.
> 
> I would recommend amending the commit message.
> 
> The underlying change itself is reasonable, and to my mind a small 
> improvement. There was unnecessary specificity in using Strunk and White as 
> reference, and not, say, William Zinsser's _On Writing Well_, which is almost 
> as well known. In the concrete, it would be exceedingly rare for these to 
> provide conflicting advice on a specific code comment.
> 
> On Mon, Jun 29, 2020 at 7:34 AM Richard Damon  
> wrote:
> On 6/29/20 6:22 AM, Nathaniel Smith wrote:
> > and describes the
> > old text as a "relic", which is another way of saying that the
> > problems were only there by historical accident, rather than by anyone
> > intentionally keeping it there. 
> 
> I would say that say that I have seen the term "relic" being used as a
> 'weaponized' word to imply that the old thing WAS there intentionally as
> a repressive measure. I am not saying that this usage was intended to be
> used that way, but just as the old wording was taken as offensive to
> some due to implication, I can see that message as offensive to others
> due to implication, all because some people are easy to offend.
> 
> -- 
> Richard Damon
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/6EN5RNF5CFDKCF3ZYQV53XH5KTBCSAQ6/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> -- 
> The dead increasingly dominate and strangle both the living and the 
> not-yet born.  Vampiric capital and undead corporate persons abuse 
> the lives and control the thoughts of homo faber. Ideas, once born, 
> become abortifacients against new conceptions.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/AMH7WMUOOZ4KAFYPVZO2BA5AQLWTCDR6/
> Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/B426T6LT3TAFJHDNWBBAEWPTZKAFEM2K/
> Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Possibly off-topic] Python-Announce floods and delays

[C. Titus Brown]

On Mon, Jul 08, 2019 at 03:27:50PM -0400, Jonathan Goble wrote:
> (I don't know the best list to post this to, so if this is not it,
> please forgive me and point me in the right direction. Thanks.)
> 
> So my inbox, and probably many of yours, was flooded this afternoon
> with a dozen-plus emails from the Python-Announce list. I understand
> that this list requires every email to be manually approved by a
> moderator. The problem is that this is done infrequently. Prior to
> today, the last round of approvals was June 26, almost two weeks ago.
> This is not an atypical delay; on the contrary, it seems that
> moderators only look at the queue once every one to two weeks.
> 
> There are several problems with these delays:
> 
> 1. They result in floods of emails, with a large number of emails in a
> short period of time. This makes inbox management difficult on the
> days that approvals are done. Before you argue that "it's fine if you
> have the right tools configured in the right way", consider that there
> are probably many people who are subscribed to Python-Announce who
> have no interest in and are not subscribed to any of the actual
> discussion lists where such tools are most beneficial. Complex tool
> configurations should not be a requirement for managing incoming
> emails from what is essentially (to those people) a notification-only
> mailing list. These people would be better served by frequent
> approvals several times a week, allowing them to get fewer emails at
> one time, but in a more timely manner.
> 
> 2. Speaking of a more timely manner, the lengthy delays result in
> redundant and outdated emails going through after the point where they
> are no longer relevant. One such issue exemplified by today's set of
> approvals (and seen on previous occasions before) is an announcement
> of a new release of a PyPI package not being approved until after
> there has already been a subsequent release to that same package. In
> this case I am referring to the pytest 5.0.0 announcement sent to the
> list on June 28 (according to the headers), followed by the pytest
> 5.0.1 announcement sent to the list on July 5. Neither was approved
> and delivered to subscribers until today.
> 
> 3. More importantly in terms of delays, on July 3 an announcement was
> sent to the list regarding the impending switch of EuroPython ticket
> rates to the late registration rate on July 6. This is an example of a
> time-sensitive announcement that needs to not be delayed. Instead, the
> email was not approved and delivered to subscribers until today, July
> 8, after the conference has already begun, and not in time for list
> subscribers to react and avoid the late registration rates.
> 
> Is there a solution to this that would enable moderators to approve
> more frequently? I understand that they are probably volunteers and
> need to find spare time to wade through the queue, but if approvals
> are done more frequently (even daily), then it will consume much less
> time on each occasion. It would go from a task requiring an entire
> hour (as it apparently did today based on the delivery timestamps) to
> something that can be done on a coffee break.

I already help moderate python-ideas and would be happy to help moderate
announce.

best,
--titus
-- 
C. Titus Brown, ctbr...@ucdavis.edu
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SJIXMHD734APMOANNTFHE7QDNHZZXO6U/

[Python-Dev] Re: Annoying user on GitHub

[C. Titus Brown]

> On Jul 2, 2019, at 9:09 AM, Steve Dower  wrote:
> 
> On 02Jul2019 0840, Mariatta wrote:
>> I've used the "Report abuse" feature on GitHub for such situations. Most of 
>> the time I see the user suspended, and the associated comments deleted.
>> Our GitHub admins can delete comments too.
>> On Tue, Jul 2, 2019, 1:42 AM Victor Stinner > > wrote:
>>Hi,
>>Sometimes, I get an email notification about strange comments
>>(unrelated
>>or make no sense) on commits made 6 months ago if not longer.
>>Usually, I
>>go to the user profile page and I click on "Block or report user":
>>"Report abuse". I'm not sure what happens in this case. I never checks
>>if these strange comments are removed by GitHub.
> 
> Maybe there's also a way to automatically lock conversations on commits and 
> old issues?
> 
> Obviously we can lock them manually, but simply disallowing conversation in 
> places where we don't want to have to pay attention to will force people 
> towards the places where we are paying attention.

Hi Steve et al.,

I think this is eminently do-able via the GitHub API. Happy to put together a 
script if people are interested. Is there a repo being used for github magic?

(I did a lot of this on a recent project - 
http://ivory.idyll.org/blog/2019-github-project-reporting.html - the PyGithub 
package is excellent.)

best,
—titus

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KGJ4DXRDZ2F5FBXGNOUYE5BKA55UV7RX/

Re: [Python-Dev] Snakebite build slaves and developer SSH/GPG public keys

[C. Titus Brown]

On Thu, Aug 23, 2012 at 11:09:14AM +0200, Giampaolo Rodol? wrote:
  For committers on other Python projects like Buildbot, Django and
  Twisted that may be reading this -- yes, the plan is to give you
  guys Snakebite access/slaves down the track too.  I'll start looking
  into that after I've finished setting up the remaining slaves for
  Python.  (Setting up a keys repo will definitely help (doesn't have
  to be hg -- feel free to use svn/git/whatever, just try and follow
  the same layout).)
 
 This is so great!
 I've been looking forward to this for a long time and kept visiting
 the site every now and then to see if there was any progress.
 I'd surely use this for psutil if you'll let me.
 Also, at some point I would suggest to introduce the possibility to
 donate some money in order to help supporting what I think must be a
 pretty complex infrastructure requiring a lot of resources, both in
 terms of hardware and time/labor.

Don't forget the heavy Xanax requirements on the part of the technical owner of
the space.  Dunno if Trent will put up any pictures but I'm dreading the day
that building maintenance gives me a call asking what the heck I've done
to the windows, drains, and power.

--titus
___
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] GitHub mirror (Was: Bitbucket mirror?)

[C. Titus Brown]

On Thu, Jul 05, 2012 at 03:49:52PM +0300, Petri Lehtinen wrote:
 anatoly techtonik wrote:
  On the subject. Is there a mirror of CPython on GitHub?
 
 https://github.com/akheron/cpython
 
  changes to repository (and allows anonymous to do this). I've made
  more than a dozen proposal for fixing docs, because as a matter of
  fact - filling a bug AND explaining why docs are wrong, why they need
  to be fixed, what should be added - all of this is a way *much easier*
  (and less time consuming!) than just fixing them. Unfortunately.
 
 You won't get any changes in to CPython by creating pull requests. We
 use http://bugs.python.org/ for that, sorry.

Question -- is there a reason to abide by this rule for docs?  That is, if we
could get a sympathetic core dev to look at pull requests for docs as part of 
a streamlined process, would it cause problems?

(What I'm really asking is whether or the bugs.python.org process is
considered critical for potentially minor doc changes and additions.)

thanks,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[C. Titus Brown]

On Tue, Mar 13, 2012 at 05:22:45AM +0200, Eli Bendersky wrote:
 On Tue, Mar 13, 2012 at 05:07, R. David Murray rdmur...@bitdance.com wrote:
  I don't like any of the suggested wordings. ?I have no problem with
  us recommending other modules, but most of the Python libraries are
  perfectly functional (not leaky or some other pejorative), they just
  aren't as capable as the wiz-bang new stuff that's available on PyPI.
 
 
  +1 to David's comment, and -0 on the proposal as a whole.
 
 The suggested wordings are simply offensive to those modules  their
 maintainers specifically, and to Python generally.
 
 Personally, I think an intelligent user should realize that a
 language's standard library won't provide all the latest and shiniest
 gadgets. Rather, it will focus on providing stable tools that have
 withstood the test of time and can serve as a basis for building more
 advanced tools. That intelligent user should also be aware of PyPI
 (and the main Python page makes it prominent enough), so I see no
 reason explicitly pointing to it in the documentation of several
 modules.

I see the point, but as a reasonably knowledgeable Python programmer
(intelligent? who knows...) I regularly discover nifty new modules
that replace stdlib modules.  It'd be nice to have pointers in the
docs, although that runs the risk of having the pointers grow stale,
too.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[C. Titus Brown]

On Tue, Mar 13, 2012 at 05:42:55AM +0200, Eli Bendersky wrote:
 On Tue, Mar 13, 2012 at 05:25, C. Titus Brown c...@msu.edu wrote:
  I see the point, but as a reasonably knowledgeable Python programmer
  (intelligent? who knows...) I regularly discover nifty new modules
  that replace stdlib modules. ?It'd be nice to have pointers in the
  docs, although that runs the risk of having the pointers grow stale,
  too.
 
 
 Exactly. It's not the job of the core developers to keep track of the
 latest and greatest gadgets and to diligently update the docs when
 something new comes out. Note that the latest and coolest changes
 frequently, so this may mean different recommendations between 3.x.y
 and 3.x.y+1, which is even more confusing.
 
 Wasn't a PyPI recommendation / voting system discussed a while ago?
 *That* would be much more appropriate than officially endorsing
 specific modules by pointing to them in the standard documentation.

I feel like there's a middle ground where stable, long-term go-to modules could
be mentioned, though.  I don't spend a lot of time browsing PyPI, but I suspect
almost everyone spends a certain amount of time in the Python docs (which is a
testimony to their quality IMO).  So I'm in favor of conservative link-outs
but without any deprecating language.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] #include Python.h

[C. Titus Brown]

On Sun, Jan 29, 2012 at 05:59:51PM +, Andrea Crotti wrote:
 On 01/29/2012 05:22 PM, Oleg Broytman wrote:
 Hello.

 We are sorry but we cannot help you. This mailing list is to work on
 developing Python (adding new features to Python itself and fixing bugs);
 if you're having problems learning, understanding or using Python, please
 find another forum. Probably python-list/comp.lang.python mailing list/news
 group is the best place; there are Python developers who participate in it;
 you may get a faster, and probably more complete, answer there. See
 http://www.python.org/community/ for other lists/news groups/fora. Thank
 you for understanding.


 I wrote here because I thought it was the best place, but I understand
 this point of view, I can ask on python or python-core for example..

python-dev isn't that inappropriate, IMO, but probably the best place to
go with this discussion is python-ideas.  Could you repost over there?

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Buildbot for AIX

[C. Titus Brown]

On Mon, Nov 08, 2010 at 06:50:32PM +0100, Antoine Pitrou wrote:
  However running 2 different slaves per host in order to distinguish xlc 
  and gcc would be OK; though I would appreciate if they could run 
  sequentially rather than in parallel as that would limit the host load.
 
 If there are two separate slaves, I can't think of any simple way to run
 builds sequentially. Perhaps you can assign both of them to a single CPU
 (assuming AIX allows that).

You can specify a slave lock to do this, in buildbot:

http://buildbot.net/buildbot/docs/0.8.1/Interlocks.html

One the neat things that a master/slave system like buildbot provides...

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[C. Titus Brown]

On Sun, Nov 07, 2010 at 09:32:33PM -0500, Scott Dial wrote:
 On 11/7/2010 7:09 PM, Martin v. L?wis wrote:
  Luckily, the problems that we faced 2.5 years ago when I came up with
  the idea of Snakebite are still just as ever present today ;-)
  
  Is this bashing of existing infrastructure really necessary?
  People (like me) might start bashing about vaporware and how
  a bird in the hand is worth two in the bush. Cooperate, don't
  confront.
 
 +1 Respect your (software) elders.
 
 The Snaketbite rhetoric has always been less than generous with regard
 to Buildbot, but Buildbot has been providing an infinitely more useful
 service to the community for much longer than Snakebite has for those
 2.5 years.

Yes, yes, I agree that some graciousness is a good idea.

Oh, wait... you're not helping.

Anyway, I think buildbot is a good local optimum for python-dev, largely
because it's maintained by someone who cares enough to do it well.  And, if
Trent had been talking about buildbot only, MvL's comment would be more than
fair.  But Trent, and I, and others, have talked about quite a bit more than
buildbot being the problem. Things like enabling *and maintaining* easy EC2
spin-up with buildbot, or providing SSH key access, or making a 'try' server
available and maintaining it, would be clearly beneficial.  And that's some of
what Trent has been talking about providing.  It turns out it's hard to do
without lots and lots of time and money.  If you truly think it's not useful,
I'd be interested in hearing your opinions, because we've spent an ungodly
amount of the above on it.

In the larger context, I worry very much that we're settling for a rather
suboptimal support setup (on svn, and on cont integration, and on some other
aspects of Python infrastructure) because the current maintainers are so
overloaded and few others are stepping up to bear burdens.  This is a big
concern of at least some people in the PSF.  But it's not an easy problem to
solve - quelle surprise.  And I'm not in a personal position to help, so I've
basically tried to shut up about it :).

As for buildbot, I've been pretty hard on buildbot myself, and I'm happy to
justify it to others -- I've done so in public fora so I'm sure you can find
the records, if you care to look.  But it's not really very relevant to this
conversation, especially since Trent has always been interested in building off
the buildbot setup rather than replacing it.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Cleaning-up the new unittest API

[C. Titus Brown]

On Tue, Nov 02, 2010 at 05:28:43PM +0900, Stephen J. Turnbull wrote:
 C. Titus Brown writes:
 
   p.s. Seriously?  I can accept that there's a rational minimalist argument
   for this feature,
 
 It is a feature, even if you aren't gonna need it.  I want it.wink
 
 Many programmers do know that sets are partially ordered by inclusion,
 preordered by size, and (in Python) totally ordered by memory address.
 There's nothing wrong with not knowing that -- these are rather
 abstract mathematical concepts.  But it's very useful that sorted() or
 .sort() use =, and it's very useful that Python so often obeys simple
 consistent rules, and it would be quite confusing to those who do
 understand that in Python the set type is partially ordered by
 inclusion if sorted() used some other relation to order collections
 of sets.
 
 It's not so hard to change this:

[ ... ]

 If there were an obvious way to compare sets for use in sorting, that
 way would very likely be the most useful definition for =, too.  But
 there isn't, really (it's pretty obvious that comparing memory
 addresses is implausible, but otherwise, there are lots of candidates
 that are at least sometimes useful).  Do you think otherwise?  If so,
 what do you propose for the OOWTDI of sorting a collection of sets?

I don't have one...

   but arguing that it's somehow the responsibility of a programmer to
   *expect* this seems kind of whack.
 
 I don't quite agree that everyone should expect exactly the
 implemented behavior, but I do think it's a Python *programmer's*
 responsibility to refrain from expecting something else in this case.

...but, as someone who has to figure out how to teach stuff to CSE undergrads
(and biology grads) I hate the statement ...any programmer should
expect this... because (unless you're going to disqualify a huge swathe of
people from being programmers) it's *just not true*.  I don't expect Python
to cater to the lowest common denominator but we should be mindful of our
audience, too.

I think Python has a great advantage in not being too surprising much of the
time, which helps quite a bit with learning. I hope people keep that in mind
for future features.

cheers,
--t
-- 
C. Titus Brown, c...@msu.edu
___
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] Cleaning-up the new unittest API

[C. Titus Brown]

On Mon, Nov 01, 2010 at 02:37:33PM -0400, Terry Reedy wrote:
 On 10/31/2010 10:55 PM, Michael Foord wrote:

 fact that sets / frozensets can't be sorted in the standard Python way
 (their less than comparison adheres to the set definition). This is
 something that will probably surprise many Python developers:

 Any programmer who sorts (or uses functions that depend on proper  
 sorting) should know and respect the difference between partial orders,  
 such as set inclusion, and total orders, such as lex order of sequences.  
 So I am surprised by the above claim ;-).

Huh.  Count me out.  I guess I don't live up to your standards.

--titus

p.s. Seriously?  I can accept that there's a rational minimalist argument
for this feature, but arguing that it's somehow the responsibility of
a programmer to *expect* this seems kind of whack.
-- 
C. Titus Brown, c...@msu.edu
___
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] Continuing 2.x

[C. Titus Brown]

On Fri, Oct 29, 2010 at 06:57:54PM +0200, Martin v. L?wis wrote:
  Infrastructure sounds to me like code for money.
 
 No, it's rather volunteer time. Of course, people keep proposing
 that this should be replaced by hired time that gets paid from
 donations, but all such proposals so far got stuck at implementation
 details (i.e. it's actual work that nobody has done).
 
  How much of the
  PSF's money, for instance, comes from organizations whose primary
  interest is still Python2?  How many of them are only or principally
  only interested in Python3?  Then again, how much of the PSF's budget
  goes toward infrastructure?
 
 The first two questions are difficult to answer: the PSF doesn't
 maintain records of what Python versions are of primary interest
 to sponsor members. A significant portion of the donations comes
 from the conference surplus (being saved for the also-likely risk
 of a massive conference loss); in this case, it's even difficult to
 identify the donors (as you can't really attribute the surplus to
 being from, say, attendee fees, as opposed to conference sponsors).
 
 As for the budget that goes into infrastructure: you'll find the details
 in the treasurer reports, but it is comparatively minor and goes
 primarily into hardware purchases. Connectivity and colocation is
 donated by companies who may not have an actual interest in Python
 at all (e.g. XS4ALL, which do this out of a general support for
 free software and in positive recollection of their former employee
 Thomas Wouters).

I'd just like to add my 2c that AFAICT the volunteer effort that goes into
Python, and in particular into python-dev and the infrastructure foo,
absolutely *dwarfs* all other aspects of official Python and PSF (including
$$ in all forms).

So, good job, -dev guys!

But they're already pretty overwhelmed.  Independent of talk, unless there's a
proposal to continue 2.x that actually involves someone *new* stepping up to
put in hugely substantial and ridiculously large amounts of seriously expert
time, I don't see the point of talking about it.

cheers,
--titus

p.s. I would be happy to enter into discussions on how to clone Martin and
others, though.  I just need some epithelial cells, I think.  And about $20 bn
dollars, and relocation to Israel (which I think has the best combination of
tech and human use guidelines for cloning).  Martin's permission is not
*strictly* necessary but should probably be obtained, too.

p.p.s.  The PSF isn't foolish enough to let me speak for them, in case
anyone is wondering.

-- 
C. Titus Brown, c...@msu.edu
___
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] query: docstring formatting in python distutils code

[C. Titus Brown]

Hi all,

over on the fellowship o' the packaging mailing list, one of our GSoC students
(merwok) asked about how much formatting info should go into Python stdlib
docstrings.  Right now the stdlib docstrings are primarily text, AFAIK; but
with the switch to Sphinx for the official Python docs, should we permit
ReST-general and/or Sphinx-specific markup in docstrings?

Hmm, I don't actually see that the stdlib docstrings are imported into the
Python documentation anywhere, so maybe the use of Sphinx isn't that
relevant.  But how about ReST in general?

See

http://sphinx.pocoo.org/markup/index.html

for sphinx-specific markup constructs.

thanks,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] query: docstring formatting in python distutils code

[C. Titus Brown]

On Wed, Jul 07, 2010 at 09:36:10PM +0530, Shashwat Anand wrote:
 On Wed, Jul 7, 2010 at 9:24 PM, C. Titus Brown c...@msu.edu wrote:
 
  Hi all,
 
  over on the fellowship o' the packaging mailing list, one of our GSoC
  students
  (merwok) asked about how much formatting info should go into Python stdlib
  docstrings.  Right now the stdlib docstrings are primarily text, AFAIK; but
  with the switch to Sphinx for the official Python docs, should we permit
  ReST-general and/or Sphinx-specific markup in docstrings?
 
  Hmm, I don't actually see that the stdlib docstrings are imported into the
  Python documentation anywhere, so maybe the use of Sphinx isn't that
  relevant.  But how about ReST in general?
 
 So will we be able to use .__docs__ within python interpretor, which is
 quite handy feature.
  print(os.getcwd.__doc__)
 getcwd() - path
 
 Return a string representing the current working directory.
 Also some python interpretors like bpython uses it ; a snapshot here -  h
 ttp://cl.ly/c5bb3be4a01d9d44732f
 So will it be ok to break them ?

I don't understand...

Frist, you can already use

help(os.getcwd)

to get the same result.

Second, what would we be breaking?  We'd be making the straight text
representation a bit more cluttered in return for adding certain kinds
of meta-information into the markup.  I think it's a judgement call...

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] query: docstring formatting in python distutils code

[C. Titus Brown]

On Wed, Jul 07, 2010 at 05:09:40PM +0100, Michael Foord wrote:
 On 07/07/2010 17:06, Shashwat Anand wrote:
 On Wed, Jul 7, 2010 at 9:24 PM, C. Titus Brown c...@msu.edu  
 mailto:c...@msu.edu wrote:

 Hi all,

 over on the fellowship o' the packaging mailing list, one of our
 GSoC students
 (merwok) asked about how much formatting info should go into
 Python stdlib
 docstrings.  Right now the stdlib docstrings are primarily text,
 AFAIK; but
 with the switch to Sphinx for the official Python docs, should we
 permit
 ReST-general and/or Sphinx-specific markup in docstrings?

 Hmm, I don't actually see that the stdlib docstrings are imported
 into the
 Python documentation anywhere, so maybe the use of Sphinx isn't that
 relevant.  But how about ReST in general?


 So will we be able to use .__docs__ within python interpretor, which  
 is quite handy feature.
  print(os.getcwd.__doc__)
 getcwd() - path

 Return a string representing the current working directory.
 Also some python interpretors like bpython uses it ; a snapshot here -  
  http://cl.ly/c5bb3be4a01d9d44732f
 So will it be ok to break them ?

 Using ReST won't *break* these tools, but may make the output less  
 readable.

 I would say that the major use of docstrings is for interactive help -  
 so interactive readability should be *the most important* (but perhaps  
 not only) factor when considering how to format standard library 
 docstrings.

OK.

I guess docutils isn't in the stdlib (should it be?) or else we could modify
'help' to use it to prepare a straight text formatting.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[C. Titus Brown]

On Thu, Jul 01, 2010 at 09:31:13AM -0500, Daniel Stutzbach wrote:
 On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik techto...@gmail.comwrote:
 
  4. Even if I make patch in my Mercurial clone - you still can't pull
  it and I have to attach it to tracker. No gain.
 
 
 Was there ever any discussion about hosting the central repository on a site
 such as bitbucket or github?  I tried searching the python-dev archives but
 was unable to find much.

We discussed this briefly at the Python language summit at PyCon '10, the
discussion intersected and/or merged with the whole infrastructure discussion,
got borg-ified by that, and I think discussions continue(d) on pydotorg-www in
general.

Personally I think it makes a great deal of sense to pay someone to manage
this for us, but there were concerns about customizability and control that
warrant further investigation.  Since it's DVCS, it's much easier to change
the official repo, but it still incurs costs in terms of documentation,
workflow changes, etc.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] FHS compliance of Python installation

[C. Titus Brown]

On Sat, Jun 26, 2010 at 10:25:28PM +0200, Matthias Klose wrote:
 On 25.06.2010 02:54, Ben Finney wrote:
 James Y Knightf...@fuhm.net  writes:

 Really, python should store the .py files in /usr/share/python/, the
 .so files in /usr/lib/x86_64- linux-gnu/python2.5-debug/, and the .pyc
 files in /var/lib/python2.5- debug. But python doesn't work like that.

 +1

 So who's going to draft the ???Filesystem Hierarchy Standard compliance???
 PEP? :-)

 This has nothing to do with the FHS.  The FHS talks about data, not code.

Really?  It has some guidelines here for object files, etc., at least as
of 2004.

http://www.pathname.com/fhs/pub/fhs-2.3.html

A quick scan suggests /usr/lib is the right place to look:

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Anyone can do patch reviews

[C. Titus Brown]

On Tue, Apr 27, 2010 at 03:23:19PM -0400, Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Antoine Pitrou wrote:
  Tres Seaver tseaver at palladion.com writes:
  This is an excellent set of guidelines.  The only drawback I see here is
  that the current VCS situation makes doing the review more tedious than
  it should be, especially for non-committers.  Or maybe the Hg mirrors
  are truly up-to-date and working?  Last I looked, they were lagging or
  unavailable.
  
  If you only a review a patch (rather than say maintain and evolve it), 
  there's
  no point in using hg rather than SVN.
 
 Hmm, it feels exactly the other way around to me:  working with the DVCS
 tools while reviewiing a patch allows me to be more productive (e.g.,
 using 'bzr shelve' or the equivalent hg subcommand).
 
 Making a local branch / clone for each issue also feels more natural
 than working in a read-only SVN checkout.

+1.  I find it to be an excellent way to muck around with patches and
make my own changes / diffs / etc. for a review process.  (Not that I
do any Python reviews, note.  But it's a great technique in general.)

It's also fantastically simple and esay to interact with patches that are
branches on someone's bitbucket or github repo; much better than uploading and
downloading patch files while in the middle of a discussion.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Fwd: Broken link to download (Mac OS X)

[C. Titus Brown]

On Wed, Apr 14, 2010 at 06:33:03AM -0400, Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Martin v. L?wis wrote:
  Tres Seaver wrote:
  Steve Holden wrote:
  Why is it unavoidable that the Mac build will languish behind others?
  Are we supporting MacOs or aren't we? If we are, why isn't the creation
  of the build a part of the release process?
  Clearly it's not a priority given that nobody has seen fit to (or had
  time to) reply to this mail in three weeks.
  Maybe the PSF should make it a priority by funding acquisition of the
  appropriate proprietary hardware (Mac / Windows) for the release
  manager.  Otherwise the avaialbility of binaries is going to lag source
  releases forever.
  
  Tres,
  
  can you be more explicit? How would such hardware help (whom specifically)?
 
 I assumed that creation of installer binaries for a release depends on
 having the release manager or a lieutenant have access to the given
 platform (Windows, OS/X) and tools,  For instance, the RM or lieutenant
 might only have access to such a platform part-time (e.g., only while at
 work, or only at home).  In such a case, providing additional hardware
 could expedite creation of the binaries.

As with Windows, I personally find that building Python with all the associated
libraries is blocked on getting the right libraries installed, not on
getting the compilers (which are available to us for free) ... but I'm sure
that easy access to hardware is an issue, too.

I can provide command-line access to a Mac OS X machine but I'm not sure that's
enough.  Let me know if anyone wants that.

Separately, I'd be happy to put forward a proposal to the PSF to fund RMs and
their lieutenants with a Mac or a PC, whichever they needed to keep things
moving.  It's the least we can do, IMO, and hardware is just not that
expensive compared to the dedication of the volunteers.  If Georg, Benjamin,
Martin, or Ronald are interested, please just tell me (or Steve, or the PSF
board, or ...) what you want and I'll work on getting it funded.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Fwd: Broken link to download (Mac OS X)

[C. Titus Brown]

On Wed, Apr 14, 2010 at 07:36:25AM +0200, Martin v. L?wis wrote:
  In a wider sense of to support, MacOS is certainly supported by
  Python. There is everything in the source code that you need to make
  Python run on a Mac. Just download the sources and compile them yourself.
 
  And yet we don't regard the Windows release as complete until you have
  built the binaries (for which service you deserve many thanks, by the way).
 
 This phenomenon exists for a lot of other systems, as well. For example,
 we also support Solaris, but stopped providing Solaris binaries since
 Python 1.5 (when I last built binaries for Das Python-Buch). People
 still can get Solaris binaries from ActiveState or Sunfreeware; Sun also
 ships Python as part of the system.

I personally think the Mac is pretty important, as one of the big three
consumer operating systems...

  Is the Mac platform one on which users will be happy to compile from
  source? I know its users are savvier than Windows users, and have a
  better tool set available to them, but they still seem to expect
  downloadable installers.
 
 The major difference in the do it yourself attitude is that Mac user
 get a compiler for free, as part of the operating system release,
 whereas for Windows, they have to pay for it (leaving alone VS Express
 for the moment).

Actually, I think the more pernicious factor is that a version of Python comes
pre-installed on Mac OS X, which means the up-front demand is lower
for a pre-compiled version.  This is problematic, though, because that
version of Python only gets upgraded with full releases of Mac OS X
(which are not very well correlated with releases of Python, of course).
So we have lots of Python installs out there that, in the absence of
a precompiled binary version, can't be upgraded without installing
the developer tools.

 However, the real difference is motivation for contribution to open
 source projects. You normally contribute to scratch an itch.
 Unfortunately, these binaries don't come out such a motiviation. So the
 release manager roles are either altruistic, or rely on extrinsic
 motivations (money, reputation).

I don't know what to do about motivation but if there are barriers that
we can lower, please let me know.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

[C. Titus Brown]

On Thu, Apr 15, 2010 at 12:47:50AM +1000, Nick Coghlan wrote:
 Martin v. L?wis wrote:
  Wasn't that problem fixed weeks ago?  The installer image has been 
  available there since several days after the release.  And the link 
  seems fine now.
  
  The inherent problem remains. There is no binary for 2.7b1, for example.
  The last binaries produced in the 2.7 testing process were for 2.7a2.
 
 I seem to recall there was some issue (aside from the current lack of a
 reliable OS X buildbot) that prevented us from regularly grabbing the
 head of the tree and using it to automatically build the Windows and Mac
 installers (to check that the installers could actually be created,
 preventing a repeat of the Mac situation with 2.7b1).
 
 Am I misremembering the discussion from last time this topic came up?

Making the Windows binary build process automatic and robust is challenging
if you hate Windows (like I do).  Martin also made the point that it's
been broken forever, so people don't seem to care :).  ISTR Martin just
makes them manually.

It's on my TODO list to robustify this process.

OTOH, my Mac automated builds/tests are working just fine.  I could produce
nightly binaries from those easily enough:

http://lyorn.idyll.org/ctb/pb-dev/p/python/

Just need to figure out the magic doohickey commands... will add to list.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Fwd: Broken link to download (Mac OS X)

[C. Titus Brown]

On Wed, Apr 14, 2010 at 09:37:34AM -0700, Bill Janssen wrote:
 Michael Foord fuzzy...@voidspace.org.uk wrote:
 
   Isn't that just a matter of having the recipe written down somewhere?
  
  
  Yes, that would be nice. :-) Preferably a recipe that doesn't involve
  Macports or Fink which some of us are allergic to.
 
 Yes, ditto the MacPorts/Fink allergy.
 
 All we need is a script, right?  The released branches should be built
 automatically every night anyway, just for regression testing.

Please pass it along to me, when you get it working... I build python2.7
nightly on Mac OS X, but just at the command line.

see:

http://lyorn.idyll.org/ctb/pb-dev/p/python/

http://lyorn.idyll.org/ctb/pb-dev/p/python/show_all

(the Windows build is flaky for me, so the 'show_all' shows mostly
Windows builds).

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Fwd: Broken link to download (Mac OS X)

[C. Titus Brown]

On Wed, Apr 14, 2010 at 06:52:46PM +0200, Michael Foord wrote:
 On 14/04/2010 18:49, Steve Holden wrote:
 Bill Janssen wrote:

 Michael Foordfuzzy...@voidspace.org.uk  wrote:

  
 Isn't that just a matter of having the recipe written down somewhere?

  
 Yes, that would be nice. :-) Preferably a recipe that doesn't involve
 Macports or Fink which some of us are allergic to.

 Yes, ditto the MacPorts/Fink allergy.

 All we need is a script, right?  The released branches should be built
 automatically every night anyway, just for regression testing.

 Perhaps we should take this up on Mac-Python?

  
 Please do, and let me know if resources of some kind would help.


 A Mac buildbot would *definitely* be useful and I know some of the  
 Python-dev crew would like access to a Mac OS X machine for trying out  
 fixes when none of the core Mac maintainers are around. A couple of  
 co-located, or otherwise hosted, Mac boxes would be very useful.

 The obvious question is who would hold the keys (maintain the buildbot)?  
 I don't know if Ronald has the spare capacity to do this (?). If someone  
 will help me with the initial setup I can otherwise volunteer.

We have some space in our machine room, and some sysadmins that like open
source.  I will ask them if they are willing to do physical maintenance (profs
wisely aren't allowed access to the machine room).  That would really be
ideal... I will report back to interested people.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Code coverage metrics

[C. Titus Brown]

On Tue, Apr 06, 2010 at 10:36:14PM +0300, anatoly techtonik wrote:
 On Tue, Apr 6, 2010 at 7:31 PM, Georg Brandl g.bra...@gmx.net wrote:
 
  Where can I find public reports with Python tests code coverage?
 
  Here:
 
  http://coverage.livinglogic.de/
 
  Thank you. What is the status of getting these stats on python.org?
 
  Wouldn't status imply that there is a plan to do so?
 
 It is not that hard to create that plan given that there is a fair
 amount of developers who care about code coverage.

Anatoly,

nonetheless, I don't know of any plan :).

I keep on shaving yaks when trying to get test coverage posted somewhere;
it's actually not a trivial problem to set it up automatically and
reliably, in my experience.  If you are interested in volunteering to
help, I'm sure it would be appreciated -- I suspect the right place to
start would be get test coverage running reproducibly and reliably on
your own machines and posted somewhere; then you could ask for permissions
to post it somewhere on *.python.org.  (I don't see why we care where it's
posted, but that's what you asked about.)

I keep on running into technical barriers in getting cross-platform code
coverage analysis working, which would be quite valuable; it's easy to
get it working once, but to keep it working is a maintenance task that
involves regular effort, again, in my experience.

best,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] GSoC 2010 is on -- projects?

[C. Titus Brown]

On Wed, Mar 31, 2010 at 05:41:47PM +0900, Stephen J. Turnbull wrote:
 anatoly techtonik writes:
 
   I would vote for allowing student work on community infrastructure
   tasks. Tracker, Wiki, Web site management tools are all outdated and
   everybody who cares agrees that they've seen a better tools.

[ munch ]

 I would recommend changing the tools only if *current* maintainers are
 either planning to step down (and so we face the problem of how to
 support maintenance in the future in any case), or are willing to
 supervise (ie, the people who will come back and fix problems in the
 future find the proposed improvements to be real improvements).  Eg,
 MvL should be intimately involved in any move to use different
 software for the tracker.  If the GSoC student(s) is (are) willing to
 work within the constraints of the existing software (ie, incremental
 improvements), then the constraints on mentors could be substantially
 relaxed to any of the senior folks who have recently contributed in
 those areas.

Agreed.

It'd be great to have students work on prototyping improvements, with an
eye to making changes that can then be evaluated in terms of maintainability,
extensibility, etc.  Having them actually change the infrastructure itself
seems to me like a bad idea :)

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] GSoC 2010 is on -- projects?

[C. Titus Brown]

On Mon, Mar 29, 2010 at 10:40:06AM +0300, anatoly techtonik wrote:
 I would vote for allowing student work on community infrastructure
 tasks. Tracker, Wiki, Web site management tools are all outdated and
 everybody who cares agrees that they've seen a better tools.

As long as it's programming, it's allowed by Google.  So let's find a good
student or two, and outline a few good projects!

I do worry that that kind of work is difficult to evaluate, and requires really
great communication on both sides...

--titus
___
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] GSoC 2010 is on -- projects?

[C. Titus Brown]

On Sat, Mar 20, 2010 at 12:00:48AM +0100, Martin v. L?wis wrote:
  Whether this is worth weeks of work or not will depend on a given
  student's knowledge about Python 3, and I'd suspect that the GSoC would
  be an opportunity for a number of applicant to actually learn the
  intricacies of Python 3.
  Developing Python 3-specific features could be used to increase the
  amount of work on the project, but I am uncertain of whether this is
  worth a full GSoC.
 
 I'd say this would definitely make a GSoC project; any non-trivial
 porting will be.

Sounds good to me.  Line up a good student and bob's your uncle.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] GSoC 2010 is on -- projects?

[C. Titus Brown]

Hi all,

once again, the PSF has been accepted as a mentoring foundation for the Google
Summer of Code!  This year, we're going to emphasize python 3 porting, so
please think of projects you'd like to see tackled.

Please submit ideas for projects as soon as possible, as students will be able
to start applying soon.  You can add them to this page:

   http://wiki.python.org/moin/SummerOfCode/2010

You can subscribe to the mentors list here,

   http://mail.python.org/mailman/listinfo/soc2010-mentors

and the general discussion list (students included) here:

   http://mail.python.org/mailman/listinfo/soc2010-general

thanks,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] GSoC 2010 is on -- projects?

[C. Titus Brown]

On Thu, Mar 18, 2010 at 10:13:42PM -0500, Benjamin Peterson wrote:
 2010/3/18 C. Titus Brown c...@msu.edu:
  Hi all,
 
  once again, the PSF has been accepted as a mentoring foundation for the 
  Google
  Summer of Code! ??This year, we're going to emphasize python 3 porting, so
  please think of projects you'd like to see tackled.
 
 This is not completely to the exclusion of other, projects, though,
 correct? For example, I think building a 64 bit PyPy backend would be
 a very worthy task.

Right -- emphasize only ;).  Good projects + good students + good mentors are
always welcome (and, actually, we'd like to focus on good students -- better
that something get done than that something particularly relevant get chosen
but NOT done by a poor student).

thanks,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] /trunk test_distutils failing on Mac OS X 10.5

[C. Titus Brown]

Hi all,

/trunk test_distutils is failing with the following error on Mac OS X 10.5:

Here's the error:

test_distutils
test test_distutils failed -- Traceback (most recent call last):
File
/private/tmp/tmp8UfLPT/python27/Lib/distutils/tests/test_sdist.py,
line 342, in test_make_distribution_owner_group 
self.assertEquals(member.gid, os.getgid())
AssertionError: 0 != 20

It has been a problem for over a week, perhaps longer.  I've filed it as:

http://bugs.python.org/issue7408

... So why am I posting this to python-dev?

I went to double-check this on the buildbots and noticed that there
aren't any Mac OS X buildbots.  I would be happy to give one or two
people remote access to my Mac OS X 10.5 iMac if someone wanted to
set up a buildbot and/or debug this issue further.

Tarek, I can give you access immediately through your lyorn account, too.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] /trunk test_distutils failing on Mac OS X 10.5

[C. Titus Brown]

On Sun, Nov 29, 2009 at 07:28:50PM +0100, Martin v. L?wis wrote:
  I went to double-check this on the buildbots and noticed that there
  aren't any Mac OS X buildbots. 
 
 That's not true, see
 
 http://www.python.org/dev/buildbot/builders/x86 osx.5 trunk

Ahh!  Sorry, was searching for 'mac' somewhere in the string.

Those tests are also broken but in different areas from mine.  Again,
if people would like shell access, just ask.

best,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] /trunk test_distutils failing on Mac OS X 10.5

[C. Titus Brown]

On Sun, Nov 29, 2009 at 06:43:50PM +, Mark Dickinson wrote:
 On Sun, Nov 29, 2009 at 6:36 PM, C. Titus Brown c...@msu.edu wrote:
  On Sun, Nov 29, 2009 at 07:28:50PM +0100, Martin v. L?wis wrote:
  That's not true, see
 
  http://www.python.org/dev/buildbot/builders/x86 osx.5 trunk
 
  Ahh! ??Sorry, was searching for 'mac' somewhere in the string.
 
  Those tests are also broken but in different areas from mine. ??Again,
  if people would like shell access, just ask.
 
 I think that buildbot is running OS X 10.6 (despite its name).  It
 would definitely be useful to have an OS X 10.5 buildbot as well,
 since there are significant differences:  most obviously, the
 default build on 10.6 is an LP64 build.
 
 I'm not seeing the test_distutils failure you report on my own
 10.5 machine, for some reason.

Yes, neither is Tarek... I'll see if I can track down why.  I don't
think I installed anything other than the minimum necessary to build
Python, but that's a bit worrisome.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Building a Windows MSI for Python /trunk

[C. Titus Brown]

On Thu, Nov 26, 2009 at 09:54:35AM +0100, Martin v. L?wis wrote:
  First, the script that finds  builds the external dependencies has two
  minor problems.
  
   * it puts Tcl in tcl-8.*, and Tk in tk-8.*, but msi.py looks for them in
 tcl8.* and tk8.* to grab the license text.  I changed the glob strings
 appropriately and that seemed to work.
 
 Not sure what it is that put it there; perhaps you are referring to
 the Tools/buildbot scripts?

Yes, sorry, Tools/buildbot/external*.bat, as in the diff.

 Unfortunately, the naming convention that these scripts establish
 doesn't quite work, as Tix would fail to build under these conventions.
 So in my own checkout, I manually renamed the trees, and that's what
 msi.py refers to.

OK, thanks!

   * Tix isn't downloaded/installed/built automatically like everything else,
 and msi.py looks for its license file, too.  I just removed the
 Tix reference.  I can't figure out how to build Tix appropriately; any
 tips?
 
 See above. I keep forgetting how to build Tix; one set of command lines
 is in PCbuild/build_tkinter.py.

Ok, thanks!

  Second, the buildmsi.bat file refers to python26a3.hhp instead of
  python27a0.hhp.
 
 Yes, that script hasn't been updated for a long time, ever since we
 stopped having automated builds.
 
 Ideally, the script would find the Python version on its own.

Right...

  Third, I could not get _tkinter to build properly, although it wasn't fatal
  to the endeavor.  It couldn't find ..\..\tcltk\lib\tcl85.lib, although
  tcl85g.lib existed.
 
 You'll need to build release versions of Tcl/Tk/Tix.

Yes, I saw a reference to that online, but I wasn't sure if that was the
problem -- is the naming convention really that 'tcl85g.lib' is the debug
lib!?

  Oh, and there were a bunch of missing commands that (as a non-Windows 
  xpert) I
  had to figure out with google -- things like nasm/nasmw, for example.  Are
  these documented somewhere, or would it be helpful to document them?
 
 See PCbuild/readme.txt.

OK, thanks.

  I'd love to get this build process working completely automatically and
  100% correctly, too.
  
  Hat tip to Trent Nelson, who helped me figure out where the scripts are
  and what other things I needed...
 
 Feel free to submit patches. There may be a misunderstanding, though, in
 that buildmsi.bat isn't actually used for anything, and isn't meant to
 be run by users, but instead by build slaves.

Well, yes, although wouldn't we want the scripts to run without any user
editing, for the build slaves?

 One consequence is that these scripts build in debug mode (perhaps
 except for buildmsi), whereas end users would typically want to build in
 release mode.

Right.

Is there a reason the buildbot builds were stopped? I've added binary
file uploads to pony-build, so that platform-specific files can be
uploaded to build results -- see, e.g.

http://lyorn.idyll.org/ctb/pb-dev/p/python/10768/files/

or

http://lyorn.idyll.org/ctb/pb-dev/p/pygr/10805/files/

and I thought daily -latest builds for Python latest on Windows and Mac would
be a good demo...

Incidentally, the pony-build results  file upload scripts can be used from
within buildbot, if people are interested.

 Another consequence is that different committers actually use different
 procedures. Trent created much of the Tools/buildbot setup, so he is
 obviously in favor of that strategy. Christian Heimes created
 PCbuild/build_tkinter, so he would probably prefer to use that instead.
 When I took over Windows builds from Tim Peters, PCbuild/readme.txt
 was the official reference, and I try to stick to that.

OK, I see.  Thanks!  So if I can bring the scripts into concordance with
that it might be valuable?

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Building a Windows MSI for Python /trunk

[C. Titus Brown]

Hi all,

I got an MSI build working on my WinXP VM just now, and I wanted to
touch base with whomever it is that is maintaining this (wonderful!)
set of scripts...

I ran into three problems, and I managed to figure out two of them; the third
wasn't fatal.  Note, the diff of my fixed checkout is attached.

First, the script that finds  builds the external dependencies has two
minor problems.

 * it puts Tcl in tcl-8.*, and Tk in tk-8.*, but msi.py looks for them in
   tcl8.* and tk8.* to grab the license text.  I changed the glob strings
   appropriately and that seemed to work.

 * Tix isn't downloaded/installed/built automatically like everything else,
   and msi.py looks for its license file, too.  I just removed the
   Tix reference.  I can't figure out how to build Tix appropriately; any
   tips?

Second, the buildmsi.bat file refers to python26a3.hhp instead of
python27a0.hhp.

Third, I could not get _tkinter to build properly, although it wasn't fatal
to the endeavor.  It couldn't find ..\..\tcltk\lib\tcl85.lib, although
tcl85g.lib existed.

Oh, and there were a bunch of missing commands that (as a non-Windows xpert) I
had to figure out with google -- things like nasm/nasmw, for example.  Are
these documented somewhere, or would it be helpful to document them?  I think I
had to install:

 - Microsoft HTML Help Compiler
 - cygwin with make and python2.5 to build the docs
 - nasm (and copy nasm.exe to nasmw.exe)
 - cabarc

Errm, and the 'buildmsi.bat' file has 'build' misspelled as 'buold' ;)

I'd love to get this build process working completely automatically and
100% correctly, too.

Hat tip to Trent Nelson, who helped me figure out where the scripts are
and what other things I needed...

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
Index: Tools/msi/msi.py
===
--- Tools/msi/msi.py	(revision 76532)
+++ Tools/msi/msi.py	(working copy)
@@ -875,9 +875,8 @@
 for name, pat, file in ((bzip2,bzip2-*, LICENSE),
   (Berkeley DB, db-*, LICENSE),
   (openssl, openssl-*, LICENSE),
-  (Tcl, tcl8*, license.terms),
-  (Tk, tk8*, license.terms),
-  (Tix, tix-*, license.terms)):
+  (Tcl, tcl-8*, license.terms),
+  (Tk, tk-8*, license.terms)):
 out.write(\nThis copy of Python includes a copy of %s, which is licensed under the following terms:\n\n % name)
 dirs = glob.glob(srcdir+/../+pat)
 if not dirs:
Index: Tools/buildbot/buildmsi.bat
===
--- Tools/buildbot/buildmsi.bat	(revision 76532)
+++ Tools/buildbot/buildmsi.bat	(working copy)
@@ -9,7 +9,7 @@
 
 @rem build the documentation
 bash.exe -c 'cd Doc;make PYTHON=python2.5 update htmlhelp'
-%ProgramFiles%\HTML Help Workshop\hhc.exe Doc\build\htmlhelp\python26a3.hhp
+%ProgramFiles%\HTML Help Workshop\hhc.exe Doc\build\htmlhelp\python27a0.hhp
 
 @rem buold the MSI file
 cd PC
___
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] Possible language summit topic: buildbots

[C. Titus Brown]

On Fri, Oct 30, 2009 at 04:21:06PM +, Antoine Pitrou wrote:
 
 Hello,
 
 Sorry for the little redundancy, I would like to underline Jean-Paul's
 suggestion here:
 
 Le Sun, 25 Oct 2009 14:05:12 +, exarkun a ??crit??:
  I think that money can help in two ways in this case.
  
  First, there are now a multitude of cloud hosting providers which will 
  operate a slave machine for you.  BuildBot has even begun to support 
  this deployment use-case by allowing you to start up and shut down vms 
  on demand to save on costs.  Amazon's EC2 service is supported out of 
  the box in the latest release.
 
 I'm not a PSF member, but it seems to me that the PSF could ask Amazon 
 (or any other virtual machine business anyway) to donate a small number
 of permanent EC2 instances in order to run buildslaves on.

[ ... ]

I'm happy to provide VMs or shell access for Windows (XP, Vista, 7); Linux
ia64; Linux x86; and Mac OS X.  Others have made similar offers.  The
architectures supported by the cloud services don't really add anything
(and generally don't have Mac OS X support, AFAIK).

What we really need (IMO) is someone to dig into the tests to figure out which
tests fail randomly and why, and to fix them on specific architectures that
most of us don't personally use.  This is hard work that is neither glamorous
nor popular.

I think the idea of paying a dedicated developer to make the CPython+buildbot
tests reliable is better, although I would still be -0 on it (I don't think
the PSF should be paying for this kind of thing at all).

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Possible language summit topic: buildbots

[C. Titus Brown]

On Fri, Oct 30, 2009 at 05:41:39PM +0100, Antoine Pitrou wrote:
 Le vendredi 30 octobre 2009 ?? 09:31 -0700, C. Titus Brown a ??crit :
  [ ... ]
  
  I'm happy to provide VMs or shell access for Windows (XP, Vista, 7); Linux
  ia64; Linux x86; and Mac OS X.  Others have made similar offers.  The
  architectures supported by the cloud services don't really add anything
  (and generally don't have Mac OS X support, AFAIK).
 
 Well these VMs would have to run buildslaves on them, then. Are you
 ready to host some and connect them to the current buildbot
 infrastructure?
 (VMs without buildslaves are less interesting IMO)

No, I'm not willing to spend the time to install and maintain buildbot. But
I'm happy to give the necessary access to those who are interested and
willing.

(...and let me tell you, getting these !#%!#$! Windows VMs up and running
already took an immense amount of effort ;)

  What we really need (IMO) is someone to dig into the tests to figure out 
  which
  tests fail randomly and why, and to fix them on specific architectures that
  most of us don't personally use.  This is hard work that is neither 
  glamorous
  nor popular.
 
 I'm sure some of us are ready to do so (*). The situation has already
 improved quite a lot in the recent times. But fixing platform- or,
 worse, setup-specific issues often requires shell access to the target
 system, otherwise you spend too much time trying fixes on the SVN and
 waiting for the buildbot to react.
 
 (*) After all, if we weren't, we wouldn't even care about buildbots,
 we'd be content with running the test suite on our own machines

I look forward to it!

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] [TIP] Possible language summit topic: buildbots

[C. Titus Brown]

On Fri, Oct 30, 2009 at 11:42:30AM -0500, Olemis Lang wrote:
 On Sun, Oct 25, 2009 at 9:13 AM,  exar...@twistedmatrix.com wrote:
  On 12:48 pm, c...@msu.edu wrote:
 
  [snip]
 
  The most *exciting* part of pony-build, apart from the always-riveting
  spectacle of titus rediscovering problems that buildbot solved 5 years
  ago,
  is the loose coupling of recording server to the build slaves and build
  reporters. ?My plan is to enable a simple and lightweight XML-RPC and/or
  REST-ish interface for querying the recording server from scripts or other
  Web
  sites. ?This has Brett aquiver with anticipation, I gather -- no more
  visual
  inspection of buildbot waterfall pages ;)
 
  BuildBot has an XML-RPC interface. ?So Brett can probably do what he wants
  with BuildBot right now.
 
 ... but pony-build follows a different model

I'd rather not get into discussions of why my vaporware is going to be
way, way better than anything anyone else could possibly do -- that's
flamebait and not very friendly, in the end.  Let's just say that I'm wasting
my own time on it to scratch my own itch and leave it at that!

thanks,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Possible language summit topic: buildbots

[C. Titus Brown]

On Fri, Oct 30, 2009 at 04:49:51PM +, Paul Moore wrote:
 2009/10/30 C. Titus Brown c...@msu.edu:
  On Fri, Oct 30, 2009 at 04:21:06PM +, Antoine Pitrou wrote:
 
  Hello,
 
  Sorry for the little redundancy, I would like to underline Jean-Paul's
  suggestion here:
 
  Le Sun, 25 Oct 2009 14:05:12 +, exarkun a ??crit??:
   I think that money can help in two ways in this case.
  
   First, there are now a multitude of cloud hosting providers which will
   operate a slave machine for you. ?BuildBot has even begun to support
   this deployment use-case by allowing you to start up and shut down vms
   on demand to save on costs. ?Amazon's EC2 service is supported out of
   the box in the latest release.
 
  I'm not a PSF member, but it seems to me that the PSF could ask Amazon
  (or any other virtual machine business anyway) to donate a small number
  of permanent EC2 instances in order to run buildslaves on.
 
  [ ... ]
 
  I'm happy to provide VMs or shell access for Windows (XP, Vista, 7); Linux
  ia64; Linux x86; and Mac OS X. ?Others have made similar offers. ?The
  architectures supported by the cloud services don't really add anything
  (and generally don't have Mac OS X support, AFAIK).
 
 As Antione pointed out, it's not clear (at least, it isn't to me) what
 that leaves to be done.

Great!  We've solved the problem ;)

 As a counter-offer: Given remote access to however many Windows VMs
 you want to provide, I'll get them up and running with buildslaves on
 them. If that requires software such as Visual Studio, I have copies
 via the MSDN licenses that I am happy to provide.

I, too, have MSDN licenses, and I have functioning build environments
on all of the VMs (I think -- I've only tested Win XP currently:

http://lyorn.idyll.org/ctb/pb-dev/python/detail?result_key=8276

)

I also have an OS X 10.5 machine that I can let you into through a firewall;
it's building Python 2.7 quite nicely:

http://lyorn.idyll.org/ctb/pb-dev/python/detail?result_key=8229

 Once things are up and running, I'll be prepared to do basic care and
 feeding of the buildslave, but as my time is limited, it would be nice
 if others would pitch in to help.

I would be somewhat unhappy about giving more than three or four people
admin access, but am prepared to lie back and think of England.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Cloud build slaves (was Re: Possible language summit topic: buildbots)

[C. Titus Brown]

On Fri, Oct 30, 2009 at 04:58:29PM -, exar...@twistedmatrix.com wrote:
 On 04:31 pm, c...@msu.edu wrote:
 On Fri, Oct 30, 2009 at 04:21:06PM +, Antoine Pitrou wrote:

 Hello,

 Sorry for the little redundancy, I would like to underline Jean-Paul's
 suggestion here:

 Le Sun, 25 Oct 2009 14:05:12 +, exarkun a ??crit??:
  I think that money can help in two ways in this case.
 
  First, there are now a multitude of cloud hosting providers which  
 will
  operate a slave machine for you.  BuildBot has even begun to support
  this deployment use-case by allowing you to start up and shut down  
 vms
  on demand to save on costs.  Amazon's EC2 service is supported out  
 of
  the box in the latest release.

 I'm not a PSF member, but it seems to me that the PSF could ask Amazon
 (or any other virtual machine business anyway) to donate a small  
 number
 of permanent EC2 instances in order to run buildslaves on.

 [ ... ]

 I'm happy to provide VMs or shell access for Windows (XP, Vista, 7);  
 Linux
 ia64; Linux x86; and Mac OS X.

 Okay, let's move on this.  Martin has, I believe, said that potential  
 slave operators only need to contact him to get credentials for new  
 slaves.  Can you make sure to follow up with him to get slaves running  
 on these machines?  Or would you rather give out access to someone else  
 and have them do the build slave setup?

I think we crossed threads here; I can provide the VMs, and access to them,
but I won't (empirically, don't have the regular time available to ;) maintain
buildbot buildslaves.

You or Antoine or others are welcome to contact me off-list.  Just give me an
account name and ssh key, and I'll give you login access via tunneled Remote
Desktop to the Windows machines.

 Others have made similar offers.

 I'll similarly encourage them to take action, then.  Do you happen to  
 remember who?

Every few months this thread seems to pop up and then fizzles when people
realize the level of work and attention involved (- he says cynically) in
exploiting the offer of resources; I hope that anyone interested in
offering resources will pop their head up again to look around.

 I hope everyone is on board with the idea of fixing bugs in CPython,  
 either in the actual implementation of features or in the tests for  
 those features.  That being the case, the discussion of whether or not  
 the PSF should try to fund such a task is perhaps best discussed on the  
 PSF members list.

Sure.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Possible language summit topic: buildbots

[C. Titus Brown]

On Sun, Oct 25, 2009 at 08:54:46AM +, Mark Dickinson wrote:
 Would it be worth spending some time discussing the buildbot situation
 at the PyCon 2010 language summit?  In the past, I've found the
 buildbots to be an incredibly valuable resource;  especially when
 working with aspects of Python or C that tend to vary significantly
 from platform to platform (for me, this usually means floating-point,
 and platform math libraries, but there are surely many other things it
 applies to).  But more recently there seem to have been some
 difficulties keeping a reasonable number of buildbots up and running.
 A secondary problem is that it can be awkward to debug some of the
 more obscure test failures on buildbots without having direct access
 to the machine.  From conversations on IRC, I don't think I'm alone in
 wanting to find ways to make the buildbots more useful.
 
 So the question is: how best to invest time and possibly money to
 improve the buildbot situation (and as a result, I hope, improve the
 quality of Python)?  What could be done to make maintenance of build
 slaves easier?  Or to encourage interested third parties to donate
 hardware and time?  Are there good alternatives to Buildbot that might
 make a difference? What do other projects do?
 
 These are probably the wrong questions;  I'm hoping that a discussion
 would help produce the right questions, and possibly some answers.

[ x-posting to testing-in-python; please redirect followups to one list or
the other! ]

Hi Mark,

a few bits of information...

---

I have a set of VM machines running some core build archs -- Linux, Mac OS X,
Win XP, Win Vista, and Win 7 -- that I am going to dedicate to this purpose.
I am happy to give out remote admin access to a few people.  This
infrastructure is also going to increase slowly as I build up my lab's internal
network.

I'm giving Tarek an account on my Linux box later today to serve as a build
slave for Distribute.

--

More machines, and more esoteric machines, will be coming online as Snakebite
unfolds.  Trent Nelson (Snakepit master) has been finishing up some consulting
work and is going to dedicate his time to it starting in November.  This means
more 64 bit, bigmem, and weird archs, with full login access.

---

I've also been working on a buildbot alternative that I'm calling pony-build.
pony-build is based on a client-push architecture in which client machines
do builds and push results to the master, which then acts as a record-keeper
rather than a slave driver.  The result is a less coordinated but (AFAICT) much
less fragile continuous integration system.  I'm hoping to give a talk at PyCon
on the differences, and there will be a sprint on pony-build + pyhton-dev at
PyCon, regardless.

The current status of pony-build is functional but ugly inside.  In
particular, the data model is horrible, and the internal API needs much
more fleshing out.  Nonetheless, my server has been running for two months
or so, and you can look at the results here,

http://lyorn.idyll.org/ctb/pb-dev/

The most fully-fleshed out set of build clients is for pygr,

http://lyorn.idyll.org/ctb/pb-dev/pygr/

but you can view daily build results for Python 2.7 at

http://lyorn.idyll.org/ctb/pb-dev/python/

with an exhaustive list here

http://lyorn.idyll.org/ctb/pb-dev/python/show_all

(and why the heck am I sorting in reverse date order, anyway?!)

The most interesting (?) part of pony-build right now is the client
config, which I'm struggling to make simple and potentially universal
enough to serve under buildbot as well:

http://github.com/ctb/pony-build/blob/master/client/build-cpython

(see 'commands' list).

The most *exciting* part of pony-build, apart from the always-riveting
spectacle of titus rediscovering problems that buildbot solved 5 years ago,
is the loose coupling of recording server to the build slaves and build
reporters.  My plan is to enable a simple and lightweight XML-RPC and/or
REST-ish interface for querying the recording server from scripts or other Web
sites.  This has Brett aquiver with anticipation, I gather -- no more visual
inspection of buildbot waterfall pages ;)

--

If you're interested in bashing on, contributing to, or helping figure out
what color the pony-build main screen should be, contact me off-list; I'm
reluctant to spam up python-dev or testing-in-python.

That having been said, the results of taking it and trying it out -- you can
post results to my own recording server at 

http://lyorn.idyll.org/ctb/pb-dev/xmlrpc

-- would be most welcome.

Once I fix the data model, code collaboration will be much more feasible,
too.

---

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Possible language summit topic: buildbots

[C. Titus Brown]

On Sun, Oct 25, 2009 at 07:32:52PM +0100, Martin v. L?wis wrote:
  I've been trying to get some feedback about firing up buildbots on Cloud
  Servers for a while now and haven't had much luck.  I'd love to find a
  way of having buildbots come to life, report to the mother ship, do the
  build, then go away 'till next time they're required.
 
 I'm not quite sure whom you have been trying to get feedback from, and
 can't quite picture your proposed setup from above description.
 
 In any case, ISTM that your approach isn't compatible with how buildbot
 works today (not sure whether you are aware of that): a build slave
 needs to stay connected all the time, so that the build master can
 trigger a build when necessary.

Hi Martin,

it shouldn't be difficult to cobble together a build script that spins up a
buildslave on EC2 and runs the tests there; I wrote something similar a
few years ago for an infrequently connected home machine.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] BDFL pronouncement?

[C. Titus Brown]

On Fri, Oct 09, 2009 at 01:56:42PM -0700, Guido van Rossum wrote:
 On Fri, Oct 9, 2009 at 1:50 PM, Georg Brandl g.bra...@gmx.net wrote:
  Chris Withers schrieb:
  Guido van Rossum wrote:
  I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
  Distribute is mature and in widespread use. IOW I support Tarek's fork
  and suggest nobody hold their breath waiting for setuptools 0.7.
 
  Well, if this was the BDFL pronouncement that a lot of people have taken
  it to be, does that allow Martin von Lewis to give the keys to
  http://pypi.python.org/pypi/setuptools to the distribute developers,
  so we can get on and use the original setuptools name without all the
  confusion and hackery needed to make distribute work?
 
  That's absurd. ?There's a certain area where Guido can make pronouncements,
  but third-party packages is not it. ?Even if they're hosted on python.org
  infrastructure.
 
 Right.

Is that a pronouncement?

:)

GvR, the self-limiting BDFL.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] thinking about 2.7 / buildbots / testing

[C. Titus Brown]

On Thu, Sep 24, 2009 at 12:23:31AM -0400, David Lyon wrote:
 On Wed, 23 Sep 2009 15:13:55 -, exar...@twistedmatrix.com wrote:
 
  I would also personally recommend that this person first (well, after 
  tracking down all the slave operators and convincing them to bring their 
  slaves back online) acquire shell access to all of the slave machines so 
  that the owners of the slave hosts themselves no longer need to be the 
  gating factor for most issues.
 
 Depends on where the machines are. There are good tools do check all
 automatically. Nagios is one.
 
 Anyway, this would suite my work schedule for the next 12 months.
 
 Do we already have the machines? or do they need to be acquired?

Hi David,

as Brett leaked, I am developing software towards making this buildbot
dilemma easier to deal with.  It's not really ready for primetime yet;
I'll send you a link off-list.

I am also (physically) hosting Snakebite, which Trent Nelson will be
tackling over the next few months.

And, finally, I now have Windows VMs (XP, Vista, 7) and a Mac OS X box
that I can dedicate to Python purposes.  I even have a student that will
be monitoring those boxes.  I am happy to give you access to these
machines if you want to set up buildbot on them; buildbot is compatible
with my own endeavors, so that would actually help me out ;)

I will be buying more/better/bigger Linux hardware over the next few
months, too, and I am happy to slice that off to provide more VMs --
basically whatever x86-based platforms people think are needed.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] FWD: Front Runner Program

[C. Titus Brown]

On Thu, Sep 10, 2009 at 08:11:55AM -0700, Aahz wrote:
- I'm still no-mail on python-dev, forwarding as FYI
-
- - Forwarded message from Eric Albrecht eric.albre...@nichecubed.com 
-
- 
- From: Eric Albrecht eric.albre...@nichecubed.com
- To: webmas...@python.org webmas...@python.org
- Date: Thu, 10 Sep 2009 10:48:11 -0400
- Subject: Front Runner Program 
- 
- Regarding: Windows 7 Compatibility for Python Application.

Thanks, Aahz!

I don't see a Windows 7 buildbot up here:

http://www.python.org/dev/buildbot/all/

but I confess that I'm bad at reading these pages.  Has anyone tried
compiling either trunk or py3k on Win 7?  Would this be useful?

My recently acquired* MSDN account has led me to getting XP up and
running in a VM, and I would be happy to try other Windows OSes of
interest.

--titus

* acquired courtesy of Snakebite/Trent Nelson.
--
C. Titus Brown, c...@msu.edu
___
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] Snakebite (was: Re: py3k buildbots)

[C. Titus Brown]

On Fri, Jun 05, 2009 at 11:26:34AM +0200, Thomas Heller wrote:
- Antoine Pitrou schrieb:
-  Hello
-  
-  Only one of the py3k buildbots seems up:
-  http://www.python.org/dev/buildbot/3.x.stable/
- 
- Maybe they are waiting for the snakebite network ;-) (what's up with it, 
anyway?).

We're still getting the machines set up.  It turns out delivering power
and A/C to a wide variety of architectures is more complicated than it
may sound ;)

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)

[C. Titus Brown]

On Thu, Jun 04, 2009 at 11:03:22AM -0400, Alexander Belopolsky wrote:
- On Thu, Jun 4, 2009 at 6:20 AM, Paul Moore p.f.mo...@gmail.com wrote:
- ...
-  I could still argue that there are downsides (need to take action to
-  set myself as nosy on an issue, possibly setting up a new mail filter,
-  housekeeping cruft, the fact that people don't quote in the same way
-  on tracker items) that make tracker discussions less attractive to me,
-  but it's very personal things.
- 
- How hard would it be to set up a bot that will subscribe to python-dev
- and archive messages that have [issue] in the subject under
- appropriate roundup ticket?  This way if discussion started on
- roundup, it would only take adding python-dev in CC to bring it to the
- larger python-dev audience and adding issue number to the python-dev
- thread subject will be all it takes to archive new messages on
- roundup.  This would not solve a problem of linking threads that start
- on python-dev before a ticket is opened, but with some proper
- conventions this problem can be solved as well.

In my experience this kind automated stuff is too fragile to work
reliably  specifically over time, which is what we would want -- fire
and forget.

Is there a good python-dev archive search mechanism (other than to
google python-dev term ;) out there?  Wouldn't that help?

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)

[C. Titus Brown]

On Thu, Jun 04, 2009 at 05:54:23PM +0200, Martin v. L?wis wrote:
-  Is there a good python-dev archive search mechanism (other than to
-  google python-dev term ;) out there?  Wouldn't that help?
- 
- I would add site:mail.python.org into the google query, but apart from
- that: what's wrong with google search?

It generally points you towards the right messages in the python-dev
archives, but those are kept by month and the threading doesn't always
work well.  Sometimes conversations span many months, and threading can
be an immense help for understanding the discussion.

Something like MarkMail (as Dirkjan mentioned) may have a better
interface.  I'll give it a try.

thanks,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Google Summer of Code/core Python projects - RFC

[C. Titus Brown]

On Sat, Apr 11, 2009 at 12:21:18PM +0200, Mario wrote:
-  He says vague things about patches too, but I'm not sure what.  If he
-  wanted to make that into a 'patchbot' that just applied every patch in
-  isolation and ran 'make  make test' and posted results in the
-  tracker I'd be a happy camper.
- 
- Jack, how about you write that idea down on the wiki page mentioned in the
- proposal, along with the use case? Following that, I'll see if I can do
- anything about it to make it a reality.

We had a GSoC student two years back who worked on something like this;
his name is Michal Kwiatkowski.  He probably has the code working
somewhere.

It's a nontrivial problem if you want to do it properly with VMs etc.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Google Summer of Code/core Python projects - RFC

[C. Titus Brown]

On Sat, Apr 11, 2009 at 08:13:35AM +0200, Martin v. L?wis wrote:
-  2x keyring package -- see
-  
http://tarekziade.wordpress.com/2009/03/27/pycon-hallway-session-1-a-keyring-library-for-python/.
-  The poorer one of these will probably be axed unless Tarek gives it
-  strong support.
- 
- I don't think these are good core projects. Even if the students come
- up with a complete solution, it shouldn't be integrated with the
- standard library right away. Instead, it should have a life outside the
- standard library, and be considered for inclusion only if the user
- community wants it.

Tarek has said he can put it into distutils on a trial basis, although
I'm sure that'll depend on what the student comes up with.

I'm using core projects as a shorthand for projects that directly
address the core development environment, the stdlib, and priorities of
committers on python-dev.  Tarek is a committer, and it sounded like
you, Jim, and Georg were all interested in this project, too -- that
pushes it well into core territory IMO.

- I'm also skeptical that this is a good SoC project in the first place.
- Coming up with a wrapper for, say, Apple Keychain, could be a good
- project. Coming up with a unifying API for all keychains is out of
- scope, IMO; various past attempts at unifying APIs have demonstrated
- that creating them is difficult, and might require writing a PEP
- (whose acceptance then might not happen within a summer).

Well, that's a more unassailable argument and one I agree with ;).

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Google Summer of Code/core Python projects - RFC

[C. Titus Brown]

Hi all,

this year we have 10-12 GSoC applications that I've put in the relevant
to core Python development category.  These projects, if mentors etc
are found, are *guaranteed* a slot under the PSF GSoC umbrella.  As
backup GSoC admin and general busybody, I've taken on the work of
coordinating these as a special subgroup within the PSF GSoC, and I
thought it would be good to mention them to python-dev.

Note that all of them have been run by a few different committers,
including Martin, Tarek, Benjamin, and Brett, and they've been obliging
enough to triage a few of them.  Thanks, guys!

Here's what's left after that triage.  Note that except for the four at
the top, these have all received positive support from *someone* who is
a committer and I don't think we need to discuss them here -- patches
etc. can go through normal python-dev channels during the course of the
summer.

I am looking for feedback on the first four, though.  Can these
reasonably be considered core priorites for Python?  Remember, this
costs us something in the sense of preferring these over Python
subprojects like (random example) Cython, NumPy, PySoy, Tahoe, Gajim,
etc.

---

Questionable core:

2x port NumPy to py3k -- NumPy is a major Python module and porting it
to py3k fits with Guido's request that more stuff get ported.
To be clear, I don't think anyone expects all of NumPy to get
ported this summer, but these students will work through issues
associated with porting big chunks o' code to py3k.

One medium/strong proposal, one medium/weak proposal.

Comments/thoughts?

2x improve testing tools for py3k -- variously focus on improving test
coverage and testing wrappers.

One proposes to provide a nice wrapper to make nose and py.test
capable of running the regrtests, which (with no change to
regrtest) would let people run tests in parallel, distribute or
run tests across multiple machines (including Snakebite), tag
and run subsets of tests with personal and/or public tags, and
otherwise take advantage of many of the nice features of nose
and py.test.

The other proposes to measure  increase the code coverage of
the py3k tests in both Python and C, integrate across multiple
machines, and otherwise provide a nice set of integrated reports
that anyone can generate on their own machines.  This proposal,
in particular, could move smoothly towards the effort to produce
a Python-wide test suite for CPython/IronPython/PyPy/Jython.
(This wasn't integrated into the proposal because I only found
out about it after the proposals were due.)

I personally think that both testing proposals are good, and
they grew out of conversations I had with Brett, who thinks that
the general ideas are good.  So, err, I'm looking for pushback,
I guess ;).  I can expand on these ideas a bit if people are
interested.

Both proposals are medium at least, and I've personally been
positively impressed with the student interaction.

Comments/thoughts?

---

Unquestionably core by my criteria above:

3to2 tool -- 'nuff said.

subprocess improvement -- integrating, testing, and proposing some of
the various subprocess improvements that have passed across this
list  the bug tracker

IDLE/Tkinter patch integration  improvement -- deal with ~120 tracker
issues relating to IDLE and Tkinter.

roundup VCS integration / build tools to support core development --
a single student proposed both of these and has received some
support.  See http://slexy.org/view/s2pFgWxufI for details.

sphinx framework improvement -- support for per-paragraph comments and
user/developer interface for submitting/committing fixes 

2x keyring package -- see
http://tarekziade.wordpress.com/2009/03/27/pycon-hallway-session-1-a-keyring-library-for-python/.
The poorer one of these will probably be axed unless Tarek gives it
strong support.

--

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Google Summer of Code/core Python projects - RFC

[C. Titus Brown]

On Fri, Apr 10, 2009 at 05:53:23PM -0300, Guilherme Polo wrote:
- 
-  IDLE/Tkinter patch integration  improvement -- deal with ~120 tracker
-  ? ? ? ?issues relating to IDLE and Tkinter.
- 
- 
- Is it important, for the discussion, to mention that it also involves
- testing this area (idle and tkinter), Titus ? I'm considering this
- more important than just dealing with the tracker issues.

What, I tell you that your app is going to be accepted and we shouldn't
argue about it, and you want to argue about it? ;)

--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] GSoC (was Re: PyDict_SetItem hook)

[C. Titus Brown]

On Sat, Apr 04, 2009 at 06:28:01AM -0700, Aahz wrote:
- On Fri, Apr 03, 2009, Collin Winter wrote:
- 
-  I don't believe that these are insurmountable problems, though. A
-  great contribution to Python performance work would be an improved
-  version of PyBench that corrects these problems and offers more
-  precise measurements. Is that something you might be interested in
-  contributing to? As performance moves more into the wider
-  consciousness, having good tools will become increasingly important.
- 
- GSoC work?

Alas, it's too late to submit new proposals; the deadline was
yesterday.

The next Google gives us money to wrangle students into doing
development project will probably be GHOP for highschool students, in
the winter, although it has not been announced and may not happen.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] graphics maths types in python core?

[C. Titus Brown]

Hi all,

we're having a discussion over on the GSoC mailing list about basic
math types, and I was wondering if there is any history that we should
be aware of in python-dev.  Has this been brought up before and
rejected?  Should the interested projects work towards a consensus and
maybe write up a PEP?

(The proximal issue is whether or not this is of direct relevance to the
python core and hence should be given priority.)

tnx,
-titus

Rene Dudfield wrote:

- there's seven graphics math type proposals which would be a good project
- for the graphics python using projects -- especially if they can get
- into python.
-
- It would be great if one of these proposals was accepted to work towards
- getting these simple types into python.
-
- Otherwise we'll be doomed to have each project implement vec2, vec3,
- vec4, matrix3/4, quaternion (which has already happened many times) -
- and continue to have interoperability issues.
-
- The reason why just these basic types, and not full blown numpy is that
- numpy is never planned to get into python.  Numpy doesn't want to tie
- it's development into pythons development cycle.  Whereas a small set of
- types  can be implemented and stabalised for python more easily.
-
- Also, it's not image, or 3d format types -- since those are also a way
- larger project.

-- 
C. Titus Brown, c...@msu.edu
___
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] core python tests (was: Re: PyDict_SetItem hook)

[C. Titus Brown]

On Fri, Apr 03, 2009 at 07:00:43PM +0100, Michael Foord wrote:
- Collin Winter wrote:
- On Fri, Apr 3, 2009 at 10:28 AM, Michael Foord
- fuzzy...@voidspace.org.uk wrote:
-   
- Collin Winter wrote:
- 
- As part of the common standard library and test suite that we agreed
- on at the PyCon language summit last week, we're going to include a
- common benchmark suite that all Python implementations can share. This
- is still some months off, though, so there'll be plenty of time to
- bikeshed^Wrationally discuss which benchmarks should go in there.
- 
-   
- Where is the right place for us to discuss this common benchmark and test
- suite?
- 
- As the benchmark is developed I would like to ensure it can run on
- IronPython.
- 
- The test suite changes will need some discussion as well - Jython and
- IronPython (and probably PyPy) have almost identical changes to tests that
- currently rely on deterministic finalisation (reference counting) so it
- makes sense to test changes on both platforms and commit a single 
- solution.
- 
- 
- I believe Brett Cannon is the best person to talk to about this kind
- of thing. I don't know that any common mailing list has been set up,
- though there may be and Brett just hasn't told anyone yet :)
- 
- Collin
-   
- Which begs the question of whether we *should* have a separate mailing list.
- 
- I don't think we discussed this specific point in the language summit - 
- although it makes sense. Should we have a list specifically for the test 
- / benchmarking or would a more general implementations-sig be appropriate?
- 
- And is it really Brett who sets up mailing lists? My understanding is 
- that he is pulling out of stuff for a while anyway, so that he can do 
- Java / Phd type things... ;-)

'tis a sad loss for both Python-dev and the academic community...

I vote for a separate mailing list -- 'python-tests'? -- but I don't
know exactly how splintered to make the conversation.  It probably
belongs at python.org but if you want me to host it, I can.

N.B. There are a bunch of GSoC projects to work on or with the CPython
test framework (increase test coverage, write plugins to make it
runnable in nose or py.test, etc.).  I don't know that the students
should be active participants in such a list, but the mentors should at
least try to stay in the loop so that we don't completely waste our time.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] More GSoC - make sure you list your projects!

[C. Titus Brown]

Hi all,

just a quick note -- anyone who has an idea for a core Python Google
Summer of Code project, has not had that project panned on this list ;),
and is willing to act as a CONTACT for students who want to apply (not
necessarily a mentor!) should make sure that those ideas are posted on
the wiki, at

http://wiki.python.org/moin/SummerOfCode/2009

Without a contact and a link on the wiki page, students won't have any
idea that the project exists...

I will endeavor to find mentors for as many of the core Python projects
as possible, once we have a clearer sense of how many applicants we have
and how many applications are good.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] GSoC: Core Python development tools

[C. Titus Brown]

On Mon, Mar 23, 2009 at 10:26:54PM +1000, Nick Coghlan wrote:
- C. Titus Brown wrote:
-  On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote:
-  I do think you should be prepared for pushback from python-dev on any
-  such ideas ;).  Don't get too ambitious about writing up *your* way of
-  fixing things, but rather make sure you and the students are prepared to
-  adapt to what people on python-dev think.  Mind you, ultimately the
-  people doing the work should make the decisions, but input from
-  python-dev is usually pretty useful even when it's contradictory!
- 
- Everything I've seen from Daniel so far seems to be about either making
- things we already do more efficient, or else providing additional
- features in ways that don't make the tools any more confusing for others
- already used to a particular way of doing things. So he seems to be
- navigating this particular minefield pretty well so far.
- 
- Then again, I may be a little biased - some of the recent bug tracker
- changes are things I had wished for in the past, but never chipped in
- any code to help make them happen :)

Oh, I heartily endorse his suggestions! I just want to make sure that we
make maximum use of students (and their code doesn't get tossed at the
end of the summer, which has serious morale consequences ;)

--t
-- 
C. Titus Brown, c...@msu.edu
___
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] GSoC: Core Python development tools

[C. Titus Brown]

On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote:
- Even if neither is considered worthy, I'll keep them on my to-do list
- and hope to slowly and hackishly work towards both proposals' goals.
- Barring feedback saying that they're out of scope, stupid and
- downright offensive, I'll post details on each to this thread very
- soon.

Given the relative paucity of core Python GSoC ideas, I think you should
go for both of these, *especially* if you have a mentor up front.  So,
write 'em up, add 'em to the GSoC page, and let's see who we get...
If we get good applications for both, then I think we can fund both of
them.

I do think you should be prepared for pushback from python-dev on any
such ideas ;).  Don't get too ambitious about writing up *your* way of
fixing things, but rather make sure you and the students are prepared to
adapt to what people on python-dev think.  Mind you, ultimately the
people doing the work should make the decisions, but input from
python-dev is usually pretty useful even when it's contradictory!

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Core projects for Summer of Code

[C. Titus Brown]

On Fri, Mar 20, 2009 at 03:18:00PM -0700, average wrote:
-  Summer of Code is ramping up. ?Every year the common complaint is that not
-  enough Python core projects get proposed by students, and of course a big
-  reason for that is often the only encouragement we offer prospective
-  students is a link to the PEP index.
- 
-  The challenge is finding project ideas for them that could reasonably 
occupy
-  them for the entire Summer and which the results of their work can be
-  demonstrated. ?They're being paid for specific projects so Spend the 
Summer
-  fixing bugs on the tracker is a no-go, and Google has outlined that Summer
-  of Code is about code, not documentation.
- 
- Improve doctest by allowing it to be aware of nested test scopes such
- that a variable defined at class-level scope (i.e. the variable b
- defined at the class-level doctest  b=Bag(abacab)) can be
- used in method-level scopes without re-defining it every time for
- each method's doctest (each method would reset the given variable (if
- used) to its original state rather than live mutated between
- equal-level scopes).
- 
- Would be a great improvement for doctest in my opinion--both in
- ease-of-use, and reduction of redundant, error-prone (did you define
- your test variable the same in each method?) code)--as well as other
- benefits.
- 
- Appreciate any consideration...

Hi Marcos,

my primary concern here would be that the student would do all this work
and then python-dev would reject it for incorporation into core!  Plus
it's probably not a summer-long project.

If, however, you wanted to suggest a general gather disparate doctest
features and integrate them, for consideration for the core project, I
would definitely recommend posting that as a possible project on the
Python GSoC site.  I know that zope has done some good doctest stuff,
for example; the 'testing-in-python' list would be a good place to go
for finding out more.

Note, you don't have to offer to be the mentor to post it, but it would
help ;)

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] [snakebite] Re: snakebite for GSoC?

[C. Titus Brown]

On Fri, Mar 20, 2009 at 07:37:40AM +, Trent Nelson wrote:
- 
- On Thu, Mar 19, 2009 at 10:32:03AM -0700, ajaksu wrote:
-  Does anyone have good ideas for assigning students to snakebite? Is it
-  too early?
- 
- Perhaps a little too early, python-dev@ won't know anything about
- Snakebite yet as I haven't publicly announced it there ;-)  Watch
- this space closer to PyCon.

I do have a snakebite-motivated project, listed here:

  http://ivory.idyll.org/blog/mar-09/gsoc-projects.html

(#7)

Right now an independent study student is building something, but he
can't work on it over the summer, so continuing it in various ways could
be a GSoC project.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] Core projects for Summer of Code

[C. Titus Brown]

On Wed, Mar 18, 2009 at 09:24:25PM +, Antoine Pitrou wrote:
- Rather than performance, I think some more interesting areas would be 
related to
- some of the standard library modules. For instance, the unittest module could
- welcome some new features (test discovery, support for skipped tests, 
probably
- others that I'm forgetting about). Since this is pure Python stuff not 
needing
- any deep experience with the interpreter's internals, it would be appropriate
- for an outsider.

Hi Antoine,

interesting idea -- but I've seen too many arguments about what the
*right* functionality to add to unittest would be to want to give it to
a student.  I think a student would probably not be willing or able to
fight the battles necessary to get his/her changes into the core...

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
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] RELEASED Python 3.0 final

[C. Titus Brown]

On Sat, Dec 06, 2008 at 06:03:55AM -, [EMAIL PROTECTED] wrote:
- On 01:47 am, [EMAIL PROTECTED] wrote:
- In spite of Python being a programming language, there is a difference
- between 'casual user of the language' and 'library developer'; 3.0 is
- certainly a must for all actual library developers, and I'm sure most 
- of
- them know about 3.0 by now. We're talking about first impressions for 
- people
- without that knowledge.
- 
- Well if most library developers already know 3.0 by now, I would hope
- they aren't going to sit on their hands, and solve the issues at hand!
- 
- The best thing for 3.0 adoption would be a 3.0 welcoming committee.  A 
- group of hackers wandering from one popular open source library to 
- another, writing patches for 3.x compatibility issues.  There must be 
- lots of people who care about 3.x adoption, and this is probably the 
- most effective way they can reach that goal.

Does anyone smell a few GSoC projects?  (And maybe GHOP if Google
decides to run it again; no word yet.)

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Using Cython for standard library?

[C. Titus Brown]

- I would love to see the option to write the lower levels in something
- other than C, but obviously any choice would have to be a good one.
- Otherwise, we end up stuck or with lots of different languages all
- being used and making understanding the full codebase harder. For
- example, I've wondered if RPython would ever reach the point it could
- be considered in the same way, but I don't think it would be wise to
- consider both. So, the question I see isn't if Cython should be
- allowed for standard library modules, but if the landscape of such
- solutions is at a point that any of them is ready to be committed to.

What is the situation twixt Pyrex and Cython?  As I understand it,
Cython is a non-backwards-compatible fork of Pyrex, forked for the usual
reasons [0].  Have many or most people switched to Cython, or is there
still a respectable community using Pyrex, or ...?

I'm involved in a project that depends on Pyrex and there was no clear
reason for us to switch to Cython.  I've also seen criticisms of
Cython's maturity level (which presumably also apply to Pyrex).  I'd be
interested in hearing about that...

...or is switching to Cython/Pyrex/foo a non-starter?

cheers,
--titus

[0] Which is to say: a variety of reasons, many of which are obviously
arguable, otherwise the Pyrex maintainer would have quit maintaining
Pyrex :).  But let's not go into them!
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Looking for VCS usage scenarios

[C. Titus Brown]

- Sticking with a dvcs implemented in Python makes the best sense,  
- especially when you consider the plugin architecture.  When we  
- selected a new tracker, we didn't make implementation in Python a  
- requirement, but instead a high hurdle.  Meaning, if a tracker wasn't  
- written in Python it had to be way better than those written in Python.

I worry about the idea of hacking in any way, shape or form, on the
version control system used to maintain the Python source code.  I place
VCSes at the compiler- or OS-level of the toolchain, because you have
the option of fundamentally screwing up the entire project by playing
with them.

So from that perspective it's better to keep it *out* of Python to
remove the temptation to hack :)

- As for dvcs, I think git would have to show overwhelming advantage  
- over bzr or hg to be considered.

I personally have found git very, very powerful and good, albeit
difficult to learn.  It is guaranteed to scale (unless Python gets to be
significantly bigger and more active than Linux, at any rate) and it has
a large, very technically capable, and supported user community already.

I think there are reasons why git should be at least strongly
considered.

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Looking for VCS usage scenarios

[C. Titus Brown]

On Mon, Nov 03, 2008 at 10:05:15AM -0800, Brett Cannon wrote:
- I have yet to have met anyone who thinks git is great while having
- used another DVCS as extensively (and I mean I have never found
- someone who has used two DVCSs extensively).

git is great!  I'm switching to it from darcs for all my future
projects.

(darcs, of course, is kind of a low bar: it has some scalability issues,
and it is feature-poor relative to hg and bzr in patch cherry-picking,
esp.)

:)

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Thu, Sep 04, 2008 at 03:23:22PM +0200, Jesus Cea wrote:
- -BEGIN PGP SIGNED MESSAGE-
- Hash: SHA1
- 
- Brett Cannon wrote:
-  Related but tangential question that we were discussing on the pygr[0]
-  mailing list -- what is the official word on a scalable object store
-  in Python?  We've been using bsddb, but is there an alternative?  And
-  what if bsddb is removed?
-  
-  Beyond shelve there are no official plans to add a specific object store.
- 
- If you are storing million of objects, you'd better use a transactional
- storage, able to survive diskfulls or code/computer crashes.

We're using a write-once-read-many pattern of access, and it is simply a
cache of a separate file (that remains around), so no, we don't better
use a transactional storage :).

- I will maintain bsddb as a separate (downloadable via PYPI) package
- whatever the fate of bsddb in Python stardard library be. So bsddb is a
- pretty safe bet, even if you need to install it separately.

Since I/we want to distribute pygr to end-users, this is really not a
pleasant prospect.  Also often the installation of Python itself goes
much more smoothly than the installation of separately compiled binary
packages, for all the obvious reasons (compiler/OS versions, lib
versions, etc. etc.)

- Compared to sqlite, you don't need to know SQL, you can finetuning (for
- example, using ACI instead of ACID, deciding store by store), and you
- can do replication and distributed transactions (useful, for example, if
- your storage is bigger than a single machine capacity, like my case). If
- you combine Berkeley DB with Durus, for example, all of this is
- abstracted and you simply use regular python objects.

I agree.  I like bsddb for just this reason and I'd like to continue
being able to use it!  I think that there are many reasons why having
such a thing in the stdlib is really useful and I also think it's worth
exploring the ramifications of taking it out...

--t
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Thu, Sep 04, 2008 at 10:29:10AM -0400, Tony Nelson wrote:
- At 6:10 AM -0500 9/4/08, [EMAIL PROTECTED] wrote:
-  Related but tangential question that we were discussing on the
-  pygr[0] mailing list -- what is the official word on a scalable
-  object store in Python?  We've been using bsddb, but is there an
-  alternative?  And what if bsddb is removed?
- 
- Brett Beyond shelve there are no official plans to add a specific
- Brett object store.
- 
- Unless something has changed while I wasn't looking, shelve requires a
- concrete module under the covers: bsddb, gdbm, ndbm, dumbdbm.  It's just a
- thin layer over one of them that makes it appear as if you can have keys
- which aren't strings.
- 
- I thought that all that was happening was that BSDDB was becoming a
- separate project.  If one needs BSDDB with Python2.6, one installs it.
- Aren't there other parts of Python that require external modules, such as
- Tk?  Using Tk requires installing it.  Such things are normally packaged by
- each distro the same way as Python is packaged (yum install tk bsddb).
- 
- Shipping an application to end users is a different problem.  Such packages
- should include a private copy of Python as well as of any dependent
- libraries, as tested.

Why?  On Mac OS X, for example, Python comes pre-installed -- not sure
if it comes with Tk yet, but the next version probably will.  On Windows
there's a handy few-click installer that installs Tk.  Is there some
reason why I shouldn't be relying on those distributions??

Requiring users to install anything at all imposes a barrier to use.
That barrier rises steeply in height the more packages (with versioning
issues, etc.) are needed.  This also increases the tech support burden
dramatically.

I'm happy to be told that bsddb is too much of a maintenance burden for
Python 2.6/3.0 to have -- especially since it's gone from 3.0 now ;) --
but I don't think the arguments that *it won't matter that it's not
there* have been very credible.  There's a BIG difference between things
that come with Python and things that are add-ons.

Right now, I'm teaching an intro programming course using Python.  It
doesn't seem like the students are going to need to install *anything*
other than base Python in order to play with full networking libraries 
sqlite databases, among other features.  And, for me and for them,
that's really great.

I don't think the convenience of batteries *included* should be
underestimated.

--t
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Thu, Sep 04, 2008 at 11:01:35AM -0400, Tony Nelson wrote:
- At 7:37 AM -0700 9/4/08, C. Titus Brown wrote:
- On Thu, Sep 04, 2008 at 10:29:10AM -0400, Tony Nelson wrote:
-  ...
- - Shipping an application to end users is a different problem.  Such 
packages
- - should include a private copy of Python as well as of any dependent
- - libraries, as tested.
- 
- Why?  On Mac OS X, for example, Python comes pre-installed -- not sure
- if it comes with Tk yet, but the next version probably will.  On Windows
- there's a handy few-click installer that installs Tk.  Is there some
- reason why I shouldn't be relying on those distributions??
- 
- Yes.  An application is tested with one version of Python and one version
- of its libraries.  When MOSX updates Python or some other library, you are
- relying on their testing of your application.  Unless you are Adobe or
- similarly large they didn't do that testing.  Perhaps you have noticed the
- threads about installing a new Python release over the Python that came
- with an OS, and how bad an idea that is?  This is the same issue, from the
- other side.

I have to say I've never had problems with a stock install of Python on
either Mac OS X or Windows (shockingly enough :).  I think this is good
advice for applications that rely on external libraries, but I just
don't see any problems with relying on Python 2.5 to contain all the
things that normally come with Python 2.5.  It seems like you're
pushing a pretty sharp dichotomy (trichotomy?) --

 - Python library/core developers should compile it all.

 - Python app developers can rely on what they install from binaries
   themselves, but not rely on it to be present on anyone else's machine
   or OS.

 - End users should be given a complete clean install of Python in a
   different location for each application they're using, even if those
   applications depend only on the stdlib.

This seems surprisingly complicated to me (and unnecessary, in my
limited experience) -- but it does validate my decade-old decision to
avoid writing end-user applications in Python, sadly enough.  It ends up
being less work to distribute and support a C/C++ app on Windows and Mac
OS X, for crikey's sake!

--t
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Thu, Sep 04, 2008 at 07:01:47PM +0200, Jesus Cea wrote:
- -BEGIN PGP SIGNED MESSAGE-
- Hash: SHA1
- 
- C. Titus Brown wrote:
-  Since I/we want to distribute pygr to end-users, this is really not a
-  pleasant prospect.  Also often the installation of Python itself goes
-  much more smoothly than the installation of separately compiled binary
-  packages, for all the obvious reasons (compiler/OS versions, lib
-  versions, etc. etc.)
- 
- I agree. I can check the library with Solaris 10 and several flavors of
- Linux, but I'm particularly worried about Windows support. I'm unable to
- provide precompiled libs, and 99.999% of windows users don't know what a
- compiler thing is, let alone being able to compile anything by themselves.

I believe I might be able to help you with this.  More off-list, in a
few weeks; if anyone else needs full Windoze access, Watch This Space, as
they say.

(Yes, I know access is not enough -- you really want someone to be
paying attention on Windows, too.  I'm working on a project or two
there; access to large quantities of talented students is opening up
some ideas :)

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Wed, Sep 03, 2008 at 04:41:32PM -0700, Raymond Hettinger wrote:
- I think this should be deferred to Py3.1. 
- 
- This decision was not widely discussed and 
- I think it likely that some users will
- be surprised and dismayed.  The release
- candidate seems to be the wrong time to
- yank this out (in part because of the surprise
- factor) and in part because I think the change
- silently affects shelve performance so that the
- impact may be significantly negative but not
- readily apparent.

Related but tangential question that we were discussing on the pygr[0]
mailing list -- what is the official word on a scalable object store
in Python?  We've been using bsddb, but is there an alternative?  And
what if bsddb is removed?

It would be very nice to have a moderately scalable (thousands to
millions, if not billions) cross-platform object store backend
distributed with Python.

sqlite could be one choice, but I haven't used it much yet, so I don't
know.

thanks,
--titus

[0] Python graph database for bioinformatics, 

http://code.google.com/p/pygr
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Unittest PEP do's and don'ts (BDFL pronouncement)

[C. Titus Brown]

On Wed, Jul 16, 2008 at 02:03:29PM -0700, Raymond Hettinger wrote:
- - self.assert_(func(x) in result_set)
- + self.assertIn(func(x), result_set)
- 
- Yawn.  The gain is zero.  Actually, it's negative because the second
- doesn't read as nicely as the pure python expression.

People are proposing these craptastic methods because 'assert' doesn't
do good reporting by default.  Maybe we can fix that instead??

- The run_tests function for running collections of tests. Almost every 
- project I've worked on has had an ad-hoc imnplementation of this, 
- collecting test modules and turning them into a suitable collection for 
- use with unittest.
- 
- Now, that's more like it.Propose more cool stuff like this and
- the module really will be improved.

At this point I might suggest taking a look at the nose and py.test
discovery rules and writing a simple test discovery system to find 
wrap 'test_' functions/classes and doctests in a unittest wrapper.

Many people use nose and py.test (which use remarkably similar test
discovery procedures, note) and the basic algorithm is pretty well
worked out.  And, since nose wraps such tests in unittests anyway, it
can be made entirely compatible with pre-existing TestRunner
derivatives.

This steers a middle ground between trying to co-opt py.test and nose
entirely (which no one would be happy with) and leaving the existing
(and hideous, IMO) unittest as the only standard option.  It also
helps out people who want to take advantage of some of the niftier
py.test/nosetests features during development but *also* want clean
test code that uses a standard library module.

Let me know if I should expand on this proposal...

Paranthetically, wrt unittest, the world seems to be divided into two
kinds of people : those who find the current API uninspiring but ok, and
those who absolutely hate it.  Has anyone said that they *love* the
current unittest API with all of its boilerplate?  If not, then I think
that says something, no?

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Unittest PEP do's and don'ts (BDFL pronouncement)

[C. Titus Brown]

On Wed, Jul 16, 2008 at 02:15:29PM -0700, C. Titus Brown wrote:
- At this point I might suggest taking a look at the nose and py.test
- discovery rules and writing a simple test discovery system to find 
- wrap 'test_' functions/classes and doctests in a unittest wrapper.
- 
- Many people use nose and py.test (which use remarkably similar test
- discovery procedures, note) and the basic algorithm is pretty well
- worked out.  And, since nose wraps such tests in unittests anyway, it
- can be made entirely compatible with pre-existing TestRunner
- derivatives.

Sorry for the second message, but... let's compare:

test_sort.py:
 #! /usr/bin/env python
 import unittest
 class Test(unittest.TestCase):
  def test_me(self):
 seq = [ 5, 4, 1, 3, 2 ]
 seq.sort()
 self.assertEqual(seq, [1, 2, 3, 4, 5])

 if __name__ == '__main__':
unittest.main()

with

test_sort2.py :

 def test_me():
seq = [ 5, 4, 1, 3 2 ]
seq.sort()
assert seq == [1, 2, 3, 4, 5]

The *only value* that unittest adds here is in the 'assertEqual'
statement, which (I think) returns a richer error message than 'assert'.

If I could run the second program by doing

unittest.discover_tests('test_sort2.py')

I would be a very happy man... right now it requires installing nose or
py.test.

cheers,
--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Unittest PEP do's and don'ts (BDFL pronouncement)

[C. Titus Brown]

On Wed, Jul 16, 2008 at 10:37:46PM +0100, Michael Foord wrote:
- test_sort2.py :
- 
-  def test_me():
- seq = [ 5, 4, 1, 3 2 ]
- seq.sort()
- assert seq == [1, 2, 3, 4, 5]
- 
- The *only value* that unittest adds here is in the 'assertEqual'
- statement, which (I think) returns a richer error message than 'assert'.
- 
- But if you exclude the import and class definition (two lines), then the 
- test methods themselves are identical - except with unittest you have 
- the advantage of the 'assertEquals' error collecting and reporting.
- 
- The boilerplate at the end is useful for running the test file in 
- isolation, but you don't include anything comparable in the second example.

You omit import and class definition (two lines), as well as 'self' in
every function definition.  And don't forget the multiple levels of
indentation -- that's a fair amount of gratuitous typing  boilerplate,
IMO.

With nose and py.test you always have a test runner and you can run the
tests with

nosetests test_sort2.py

which to my mind is better than having it be the default __main__
function, anyway.

- If I could run the second program by doing
- 
- unittest.discover_tests('test_sort2.py')
- 
- I would be a very happy man... right now it requires installing nose or
- py.test.
- 
- What about if you could run all tests in a project (of the first kind) with:
- 
- tests = unittest.discover_tests('path/', filter='*test.py')
- unittest.run_tests(tests)
- 
- (or even just the first line).

I would very much like that, although I think some sensible defaults
would let you omit the filter and path in obvious cases (test_*.py and
cwd, basically).

I think the exact test discovery behavior is solved in similar ways by the
py.test and nose folks, and the GCD of these solutions would provide a
good baseline for unittest.  Having *one* Python-general way to name
your test files and test functions/classes that is also compatible
across nose, py.test, and unittest would be a real gain for Python, IMO.

You could even set the default unittest __main__ to run the
discover_tests function, e.g.

python -m unittest [directory [filter]]

or some such...

cheers,
--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[C. Titus Brown]

On Tue, Jul 15, 2008 at 03:00:30PM +0100, Richard Thomas wrote:
- On Tue, Jul 15, 2008 at 2:48 PM, Ben Finney [EMAIL PROTECTED] wrote:
-  So far I have precedent and tradition and positive admonition looks
-  better in support of preferring the 'assert*' names. Are there any
-  others?
- 
- I've been told by a couple of non-programmers that failUnless is
- more intuitive than assert if only for the reason that its unclear
- what assert might do. This is similar to one of the arguments raised
- in the PEP, but considered from the point of view of someone new to
- test frameworks it could be all the more important.

Maybe this is an unnecessarily hard line, but if someone doesn't know
what assert does, then they should go look up the keyword -- it's
part of Python (and present in C, C++, Perl, and PHP as well).  So
unless the person is new to Python AND testing, they should know it.

- On another note, while I understand that consistency is a good thing
- is it really that important in test suites? Obviously the unittest
- module itself should be internally consistent but why not provide
- people using the all the synonyms they might want? I can see people
- just wrapping TestCase to add the synonyms back in.

While I don't have a strong position on the assert* vs fail*, I think
consistency and simplicity in test suites is at least as important as in
code: if you have to work hard to understand and debug your test suites,
you've done something seriously wrong in building your tests.

Tests should be as simple as possible, and no simpler.

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Proposed unittest changes

[C. Titus Brown]

On Mon, Jul 14, 2008 at 09:37:30PM -0700, Raymond Hettinger wrote:
- From: Michael Foord [EMAIL PROTECTED]
- Maybe Python needs a good mocking module in the standard library. There 
- are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
- 
- -1
- 
- This comes up occassionally and gets shot down.
- http://bugs.python.org/issue708125
- 
- Mock objects mean different things to different people.
- Some expect more simulated behavior and others want less.
- It's rare to find agreement about general purpose mock objects and 
- frameworks.
- Mock libraries create their own complexities and burdens on a programmer's 
- memory.
- It's often easier to create a small special case mock object
- than to remember how to configure a general purpose one.
- And, afaict, there is no fan club for some particular python mock
- object library -- it seems to only come up in general discussions
- about possibilities for growing the unittest module, and almost
- never comes up in the context of solving a real problem that
- hasn't already be addressed in some other way.

Also see:

http://lists.idyll.org/pipermail/testing-in-python/2007-November/000406.html

 associated thread, for those interested in the variety of mock
libraries...

cheers,
--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Python FAQ: Why doesn't Python have a with statement?

[C. Titus Brown]

On Wed, Jun 18, 2008 at 10:55:32PM -0700, Alex Martelli wrote:
- On Wed, Jun 18, 2008 at 9:58 PM, Cesare Di Mauro [EMAIL PROTECTED] wrote:
-  Very very, interesting. Thanks. :)
- 
-  Somebody thinks that Python is unsuitable to implement a DSL: IMO your 
example prove the contrary. :D
- 
- As long as you're willing to do the DSL within the strictures of
- Python syntax, it's OK - not quite as flexible as LISP or Scheme or
- even Ruby, but better than most;-).  I did design and implement DSLs
- in Python (mostly specialized class trees with suitable metaclasses,
- decorators c) in many jobs in my recent past, I'll admit -- it never
- feels as free-flowing as Scheme did back when I used THAT, but, close
- enough to make my jobs successful!-)

It's pretty easy to put a simple syntax remapper around Python, too;
this is what twill does.  So, for example, this:

--
setlocal username your username
setlocal password your password

go http://www.slashdot.org/
formvalue 1 unickname $username
formvalue 1 upasswd $password
submit

code 200 # make sure form submission is correct!
--

translates very directly to

---
setlocal('username', '...')
setlocal('password', '...')

go('http://www.slashdot.org/')
formvalue('1', 'unickname', username)
formvalue('1', 'upasswd', password)
submit()

code('200')
---

which is DSL-ish enough for me...

More generally, I've never understood why some people insist that
certain features make Ruby better for DSLs -- are code blocks really
that important to DSLs?  Or is it just the lack of parens??

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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] Addition of pyprocessing module to standard lib.

[C. Titus Brown]

On Tue, May 13, 2008 at 09:23:02PM -0400, Tom Pinckney wrote:
- Why not use MPI? It's cross platform, cross language and very widely  
- supported already. And there're Python bindings already.

MPI requires far more setup than the pyprocessing module does; it's by
no means plug  play.

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
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