Re: [Python-Dev] question

[Senthil Kumaran]

Hello,

Please ask the support questions at:

http://groups.google.com/group/comp.lang.python

This group is for developing python.


On Wed, Aug 4, 2010 at 12:13 PM, Sarah Hasanlo Nikfar
 wrote:
> hi
> i face with problem when i run one sample on cygwin:
> please help me
>
> Exception happened during processing of request from ('127.0.0.1', 49154)
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.5/SocketServer.py", line 222, in
> handle_request
>     self.process_request(request, client_address)
>   File "/usr/local/lib/python2.5/SocketServer.py", line 241, in
> process_request
>     self.finish_request(request, client_address)
>   File "/usr/local/lib/python2.5/SocketServer.py", line 254, in
> finish_request
>     self.RequestHandlerClass(request, client_address, self)
>   File "/usr/local/lib/python2.5/SocketServer.py", line 522, in __init__
>     self.handle()
>   File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 316, in handle
>     self.handle_one_request()
>   File "/usr/local/lib/python2.5/BaseHTTPServer.py", line 310, in
> handle_one_req
> uest
>     method()
>   File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 46, in do_GET
>     self.copyfile(f, self.wfile)
>   File "/usr/local/lib/python2.5/SimpleHTTPServer.py", line 175, in copyfile
>     shutil.copyfileobj(source, outputfile)
>   File "/usr/local/lib/python2.5/shutil.py", line 29, in copyfileobj
>     fdst.write(buf)
>   File "/usr/local/lib/python2.5/socket.py", line 274, in write
>     self.flush()
>   File "/usr/local/lib/python2.5/socket.py", line 261, in flush
>     self._sock.sendall(buffer)
> error: (113, 'Software caused connection abort')
>
> ___
> 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/orsenthil%40gmail.com
>
>



-- 
Senthil
___
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] Windows

[Tim Golden]

On 04/08/2010 02:08, Steve Holden wrote:

It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.

I wonder if anyone can think of a way we can get some Windows skillz
into the group that could assist at ties like this. Some brainstorming
might find a way through.


My own problem is just the amount of ramp-up time (as a proportion of
my own available time) to get hold of a problem even when I see it.
(Speaking here in the more general sense of fixing Windows-related
Python bugs).

As one who has benefitted from the MSDN largesse I am certainly conscious of
the responsibility to contribute benefits back to the Python community.
On the basis that I'm far more likely to watch a buildbot which I actually
administer, I have recently nudged my sysadmins here to see if they can
make good on their promise to find me a spare server to use as a buildbot.

I have watched the buildbot pages occasionally, especially when I see
Windows-related commits going in, but several times "red" buildbots
have turned out to be -- apparently -- environmental / local issues
unrelated to commits. Obviously I could/should have contacted the
buildbot owner to at least inform him or her that something was amiss.
But somehow at that point one's technical enthusiasm for fixing a
problem diminishes when it's not clear that there *is* a problem.
(Grumble, grumble, mutter, mutter... :) )

While we'd certainly benefit from more Windows skills, we'd probably
benefit more from people who have more *time* to look at Windows
issues. OK; to propose something concrete: I'll write a blog post
and advertise on python-win32 to ask for Windows people who perhaps
might at least be interested in contributing time. I will also
advertise (and maybe enhance) Brian Curtin's how-to doc on Windows
Python core development... which I can't quite lay my hands on at
the moment. Hopefully we can lower the perceived entry-bar for
contribution at different levels.

TJG
___
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] Windows

[Tim Golden]

On 04/08/2010 05:34, Mark Hammond wrote:

On 4/08/2010 11:08 AM, Steve Holden wrote:

It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.

I wonder if anyone can think of a way we can get some Windows skillz
into the group that could assist at ties like this. Some brainstorming
might find a way through.


I never go looking at the buildbots to look for problems - maybe some
way of explicitly bringing such failures to peoples attention would be
good


Agree with that. This page looks hopeful:

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

with Atom/RSS feeds and an XML-RPC interface. I've subscribed to the
RSS feeed which is -- from my perspective -- quite noisy. One could
do something with the xml-rpc according to this:

  http://buildbot.net/buildbot/docs/0.7.11/#XMLRPC-server

but does anyone know how easy it would be use setup a mail notifier
to go to a specific Python mailing list on failure? I've looked at
mail.python.org and Googled around and I can't see something which
already does this, but I'm very happy to be wrong...

There seems to be some previous discussion:

  http://mail.python.org/pipermail/python-dev/2006-October/069617.html

but no sign of an outcome.

TJG
___
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] Looking after the buildbots (in general)

[Antoine Pitrou]

On Tue, 03 Aug 2010 21:08:31 -0400
Steve Holden  wrote:
> It's a little disappointing to discover that despite the relatively
> large number of developers who have received MSDN licenses from
> Microsoft, none if us have the time to make sure that the buildbots are
> green for the 2.6.6 release.

I think the issue is that many core developers don't have the reflex
to check buildbot state after they commit some changes (or at least
on a regular, say weekly, basis), and so gradually the buildbots have
a tendency to turn from green to red, one after another.

>From time to time, a couple of "motivated" core developers (David, Ezio,
Mark, Florent...) try to fix the situation by diagnosing all pending
buildbot issues. It's a time-consuming task (because it's harder to
diagnose problems when you aren't the one who introduced them), and it's
somehow thankless and unmotivating (you'd rather work on your own
issues rather than fix bugs introduced by others).

Windows only exacerbates the problem because the aforementioned
"motivated" core developers aren't necessary knowledgeable enough to
write a fix, or even understand the problem.

I would advocate a system were people are encouraged to take
responsibility of the problems they introduce when committing changes.
Of course, there are sometimes situations where it's not possible
(triggering platform-specific oddities, for example).

Regards

Antoine.


___
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] Windows

[Ezio Melotti]

 On 04/08/2010 11.36, Tim Golden wrote:

On 04/08/2010 05:34, Mark Hammond wrote:

On 4/08/2010 11:08 AM, Steve Holden wrote:

It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.

I wonder if anyone can think of a way we can get some Windows skillz
into the group that could assist at ties like this. Some brainstorming
might find a way through.


I never go looking at the buildbots to look for problems - maybe some
way of explicitly bringing such failures to peoples attention would be
good


Agree with that. This page looks hopeful:

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

with Atom/RSS feeds and an XML-RPC interface. I've subscribed to the
RSS feeed which is -- from my perspective -- quite noisy. One could
do something with the xml-rpc according to this:

  http://buildbot.net/buildbot/docs/0.7.11/#XMLRPC-server

but does anyone know how easy it would be use setup a mail notifier
to go to a specific Python mailing list on failure? I've looked at
mail.python.org and Googled around and I can't see something which
already does this, but I'm very happy to be wrong...

There seems to be some previous discussion:

  http://mail.python.org/pipermail/python-dev/2006-October/069617.html

but no sign of an outcome.

TJG
___
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/ezio.melotti%40gmail.com




FWIW there's also http://code.google.com/p/bbreport/source/checkout
We were planning to use bbreport to create weekly summary and mail them 
to python-dev, but someone should write some code (I could do that but 
it's quite low in my to-do list) and make it run once a week.


Best Regards,
Ezio Melotti
___
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 after the buildbots (in general)

[Dirkjan Ochtman]

On Wed, Aug 4, 2010 at 11:16, Antoine Pitrou  wrote:
> I would advocate a system were people are encouraged to take
> responsibility of the problems they introduce when committing changes.
> Of course, there are sometimes situations where it's not possible
> (triggering platform-specific oddities, for example).

They might not be able to diagnose the problems, or fix them, but I
think they should still take responsibility until handed over
explicitly to someone else who knows the failing platform, right?

It should be relatively straightforward to have some process send
email to authors of checkins that have created new failures.

Cheers,

Dirkjan
___
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 after the buildbots (in general)

[Nick Coghlan]

On Wed, Aug 4, 2010 at 7:42 PM, Dirkjan Ochtman  wrote:
> On Wed, Aug 4, 2010 at 11:16, Antoine Pitrou  wrote:
>> I would advocate a system were people are encouraged to take
>> responsibility of the problems they introduce when committing changes.
>> Of course, there are sometimes situations where it's not possible
>> (triggering platform-specific oddities, for example).
>
> They might not be able to diagnose the problems, or fix them, but I
> think they should still take responsibility until handed over
> explicitly to someone else who knows the failing platform, right?
>
> It should be relatively straightforward to have some process send
> email to authors of checkins that have created new failures.

I believe that was the original intent, but the buildbot set generated
too many false alarms (due to flaky tests which would fail
intermittently) so it was never implemented.

However, I believe the 3.x tests have had most of that flakiness
eliminated (dropping bsddb helped greatly on that front), so it should
be feasible to restore that feature for the stable buildbot set on the
Py3k branch.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] (Windows) buildbots on 3.x

[Paul Moore]

On 3 August 2010 20:30, Barry Warsaw  wrote:
> Brian is looking at Windows now (the buildbots are
> a sad and sorry story).

There seems to be something distinctly wrong with the 3.x buildbots. A
lot of test failures and timeouts. At first I assumed it was my
buildslave going flaky (again :-() but it only affects the 3.x branch,
and it seems to be hitting more than just my slave. From what I'm
seeing, it's often test_io that's getting stalled and then sitting
round until it times out. (But as I say, it's not obviously related to
problems on my box as it's happening to others - see
http://www.python.org/dev//buildbot/builders/x86%20XP-4%203.x/builds/2652
for example - and it's not happening on other branches).

I haven't had time to look into it (and probably won't in the next few
days) but it might be worth a look at some point if anyone has the
time & inclination.

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

Re: [Python-Dev] Windows

[Steve Holden]

On 8/4/2010 3:49 AM, Tim Golden wrote:
> On 04/08/2010 02:08, Steve Holden wrote:
>> It's a little disappointing to discover that despite the relatively
>> large number of developers who have received MSDN licenses from
>> Microsoft, none if us have the time to make sure that the buildbots are
>> green for the 2.6.6 release.
>>
>> I wonder if anyone can think of a way we can get some Windows skillz
>> into the group that could assist at ties like this. Some brainstorming
>> might find a way through.
> 
> My own problem is just the amount of ramp-up time (as a proportion of
> my own available time) to get hold of a problem even when I see it.
> (Speaking here in the more general sense of fixing Windows-related
> Python bugs).
> 
> As one who has benefitted from the MSDN largesse I am certainly
> conscious of
> the responsibility to contribute benefits back to the Python community.
> On the basis that I'm far more likely to watch a buildbot which I actually
> administer, I have recently nudged my sysadmins here to see if they can
> make good on their promise to find me a spare server to use as a buildbot.
> 
> I have watched the buildbot pages occasionally, especially when I see
> Windows-related commits going in, but several times "red" buildbots
> have turned out to be -- apparently -- environmental / local issues
> unrelated to commits. Obviously I could/should have contacted the
> buildbot owner to at least inform him or her that something was amiss.
> But somehow at that point one's technical enthusiasm for fixing a
> problem diminishes when it's not clear that there *is* a problem.
> (Grumble, grumble, mutter, mutter... :) )
> 
> While we'd certainly benefit from more Windows skills, we'd probably
> benefit more from people who have more *time* to look at Windows
> issues. OK; to propose something concrete: I'll write a blog post
> and advertise on python-win32 to ask for Windows people who perhaps
> might at least be interested in contributing time. I will also
> advertise (and maybe enhance) Brian Curtin's how-to doc on Windows
> Python core development... which I can't quite lay my hands on at
> the moment. Hopefully we can lower the perceived entry-bar for
> contribution at different levels.
> 
Thanks, Tim. When I said "more Windows skillz" I should, of course, have
said "more people with time to apply their Windows skillz". I imagine if
we get some new blood in we can get them access to MSDN licenses should
they be needed.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

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

Re: [Python-Dev] (Windows) buildbots on 3.x

[Richard Jones]

On Wed, Aug 4, 2010 at 8:48 PM, Paul Moore  wrote:
> On 3 August 2010 20:30, Barry Warsaw  wrote:
>> Brian is looking at Windows now (the buildbots are
>> a sad and sorry story).
>
> There seems to be something distinctly wrong with the 3.x buildbots. A
> lot of test failures and timeouts. At first I assumed it was my
> buildslave going flaky (again :-() but it only affects the 3.x branch,
> and it seems to be hitting more than just my slave. From what I'm
> seeing, it's often test_io that's getting stalled and then sitting
> round until it times out.

I'm also quite confused by the test_smtpd failures that pop up on some
of the test runs that I've had absolutely no luck reproducing locally
under OS X or Solaris.


  Richard
___
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 after the buildbots (in general)

[Steve Holden]

On 8/4/2010 6:08 AM, Nick Coghlan wrote:
> On Wed, Aug 4, 2010 at 7:42 PM, Dirkjan Ochtman  wrote:
>> On Wed, Aug 4, 2010 at 11:16, Antoine Pitrou  wrote:
>>> I would advocate a system were people are encouraged to take
>>> responsibility of the problems they introduce when committing changes.
>>> Of course, there are sometimes situations where it's not possible
>>> (triggering platform-specific oddities, for example).
>>
>> They might not be able to diagnose the problems, or fix them, but I
>> think they should still take responsibility until handed over
>> explicitly to someone else who knows the failing platform, right?
>>
>> It should be relatively straightforward to have some process send
>> email to authors of checkins that have created new failures.
> 
> I believe that was the original intent, but the buildbot set generated
> too many false alarms (due to flaky tests which would fail
> intermittently) so it was never implemented.
> 
> However, I believe the 3.x tests have had most of that flakiness
> eliminated (dropping bsddb helped greatly on that front), so it should
> be feasible to restore that feature for the stable buildbot set on the
> Py3k branch.

I think that would be good, and an attractive extra benefit of the work
that's gone into the tests recently. The point of having the buildbots
was to alert people to when one of their changes breaks a build they
weren't able to test on. Indeed I seem to remember at one time I used to
see "blame" emails, which were not always accurate (I haven't been
subscribed to checkins for a while due to volume of other mail). That's
a heavy load to carry for a new developer, so having defined people to
go to for help on strange platforms would be useful. Assuming, of
course, that such people can be identified.

I'm well aware that developers have limits on the time they can spend on
Python. There's no blame here, just a wish to improve the process and
ensure that the Windows platform doesn't become the "poor relation".

Thanks to everyone for the positive responses.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

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

Re: [Python-Dev] [python-committers] (Windows) buildbots on 3.x

[Antoine Pitrou]

Le mercredi 04 août 2010 à 21:43 +1000, Richard Jones a écrit :
> On Wed, Aug 4, 2010 at 8:48 PM, Paul Moore  wrote:
> > On 3 August 2010 20:30, Barry Warsaw  wrote:
> >> Brian is looking at Windows now (the buildbots are
> >> a sad and sorry story).
> >
> > There seems to be something distinctly wrong with the 3.x buildbots. A
> > lot of test failures and timeouts. At first I assumed it was my
> > buildslave going flaky (again :-() but it only affects the 3.x branch,
> > and it seems to be hitting more than just my slave. From what I'm
> > seeing, it's often test_io that's getting stalled and then sitting
> > round until it times out.
> 
> I'm also quite confused by the test_smtpd failures that pop up on some
> of the test runs that I've had absolutely no luck reproducing locally
> under OS X or Solaris.

It happens when running test_smtplib before test_smtpb:

$./python -m test.regrtest -v test_smtplib test_smtpd

== CPython 3.2a1+ (py3k:83711M, Aug 4 2010, 13:23:20) [GCC 4.4.3]
==   Linux-2.6.33.5-desktop-2mnb-x86_64-with-mandrake-2010.1-Official
==   /home/antoine/py3k/__svn__/build/test_python_13320
[1/2] test_smtplib
testBasic1 (test.test_smtplib.GeneralTests) ... ok
testBasic2 (test.test_smtplib.GeneralTests) ... ok
testLocalHostName (test.test_smtplib.GeneralTests) ... ok
testTimeoutDefault (test.test_smtplib.GeneralTests) ... ok
testTimeoutNone (test.test_smtplib.GeneralTests) ... ok
testTimeoutValue (test.test_smtplib.GeneralTests) ... ok
testBasic (test.test_smtplib.DebuggingServerTests) ... ok
testHELP (test.test_smtplib.DebuggingServerTests) ... ok
testNOOP (test.test_smtplib.DebuggingServerTests) ... ok
testNotImplemented (test.test_smtplib.DebuggingServerTests) ... ok
testRSET (test.test_smtplib.DebuggingServerTests) ... ok
testSecondHELO (test.test_smtplib.DebuggingServerTests) ... ok
testSend (test.test_smtplib.DebuggingServerTests) ... ok
testVRFY (test.test_smtplib.DebuggingServerTests) ... ok
testNonnumericPort (test.test_smtplib.NonConnectingTests) ... ok
testNotConnected (test.test_smtplib.NonConnectingTests) ... ok
testFailingHELO (test.test_smtplib.BadHELOServerTests) ... ok
testAUTH_CRAM_MD5 (test.test_smtplib.SMTPSimTests) ... ok
testAUTH_LOGIN (test.test_smtplib.SMTPSimTests) ... ok
testAUTH_PLAIN (test.test_smtplib.SMTPSimTests) ... ok
testBasic (test.test_smtplib.SMTPSimTests) ... ok
testEHLO (test.test_smtplib.SMTPSimTests) ... ok
testEXPN (test.test_smtplib.SMTPSimTests) ... ok
testVRFY (test.test_smtplib.SMTPSimTests) ... ok

--
Ran 24 tests in 0.107s

OK
[2/2] test_smtpd
test_process_message_unimplemented (test.test_smtpd.SMTPDServerTest) ... FAIL
test_DATA_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_EHLO_not_implemented (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_HELO (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_HELO_bad_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_HELO_duplicate (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_MAIL_chevrons (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_MAIL_missing_from (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_MAIL_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_NOOP (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_NOOP_bad_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_QUIT (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_QUIT_arg_ignored (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_RCPT_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_RSET (test.test_smtpd.SMTPDChannelTest) ... ERROR
test_RSET_syntax (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_attribute_deprecations (test.test_smtpd.SMTPDChannelTest) ... ok
test_bad_state (test.test_smtpd.SMTPDChannelTest) ... ok
test_broken_connect (test.test_smtpd.SMTPDChannelTest) ... ok
test_data_dialog (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_data_transparency_section_4_5_2 (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_manual_status (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_missing_data (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_multiple_RCPT (test.test_smtpd.SMTPDChannelTest) ... ERROR
test_need_MAIL (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_need_RCPT (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_nested_MAIL (test.test_smtpd.SMTPDChannelTest) ... FAIL
test_server_accept (test.test_smtpd.SMTPDChannelTest) ... ok

==
ERROR: test_RSET (test.test_smtpd.SMTPDChannelTest)
--
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_smtpd.py", line 212, in 
test_RSET
self.assertEqual(self.server.messages[0],
IndexError: list index out of range

==
ERROR: test_multiple_RCPT (test.test_smtpd.SMTPDChannelTest)
--
Traceback (most recent 

Re: [Python-Dev] [python-committers] (Windows) buildbots on 3.x

[Richard Jones]

On Wed, Aug 4, 2010 at 10:05 PM, Antoine Pitrou  wrote:
> It happens when running test_smtplib before test_smtpb:

Aha! Thanks for the clue. I've checked in a fix.


  Richard
___
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] #2651 - KeyError does not round trip strings

[Łukasz Langa]

Hi guys,
there's this 2 year old bug about making strings passed to KeyError round trip:

http://bugs.python.org/issue2651

There are three things I like you to present opinions on.



0. The moratorium.

Based on the old 2.x patch there I created a new one for py3k. It's been 
reviewed and it was actually quite close to it being committed when Georg 
reminded us that there's this moratorium situation. So, please -1 that change 
here or on the issue if you think it should be stopped until the moratorium 
ends. Georg, Antoine and Michael Foord seem to be +1 on it despite the 
moratorium. (guys, please correct me if I'm wrong)



1. The patch makes KeyError behave analogically to IOError so that the first 
arg is now a message and the second is the actual key.

>>> raise KeyError("Key not found", "a Scotsman on a horse")
Traceback (most recent call last):
...
KeyError: 'Key not found: a Scotsman on a horse'

This is backwards incompatible (which has been addressed for the stdlib in the 
patch). Now, for non-empty e.args, the key is stored in e.args[-1] whereas it 
used to in e.args[0]. We could swap the args to make it backwards compatible 
but then we lose consistency with IOError and the issue on the tracker was 
originally targetting consistency.



2. Some people suggest adding e.key to KeyError. I like the idea but in my 
opinion currently it is not implementable in a reliable way.

a) if the party raising the exception does not pass any arguments, what would 
the expected behaviour of e.key be? `None` is a valid key so returning this can 
be misleading.

b) if the party raising the exception passes one argument, how do we know it's 
a key and not a message? Take for instance "Set is empty" and such. Presenting 
e.key = "Set is empty" is just wrong.

c) if the party raising the exception passes two arguments, we already know 
which one is the key. So in this case it would work well but at the same time 
it would be somewhat redundant.

Antoine and Michael Foord suggest that we simply do a "best-effort thing" and 
present `None` if no args are passed and always treat the only argument as a 
key. It would be consistent with what's IOError is doing at the moment. I'm on 
the fence here myself.

-- 
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

___
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] #2651 - KeyError does not round trip strings

[Antoine Pitrou]

On Wed, 4 Aug 2010 15:39:16 +0200
Łukasz Langa  wrote:
> 1. The patch makes KeyError behave analogically to IOError so that the first 
> arg is now a message and the second is the actual key.
> 
> >>> raise KeyError("Key not found", "a Scotsman on a horse")
> Traceback (most recent call last):
> ...
> KeyError: 'Key not found: a Scotsman on a horse'

I suppose you mean
  KeyError: Key not found: 'a Scotsman on a horse'
?

> This is backwards incompatible (which has been addressed for the stdlib in 
> the patch). Now, for non-empty e.args, the key is stored in e.args[-1] 
> whereas it used to in e.args[0]. We could swap the args to make it backwards 
> compatible but then we lose consistency with IOError and the issue on the 
> tracker was originally targetting consistency.

I don't think consistency with IOError is very important. IOError and
KeyError have basically nothing in common.

> 2. Some people suggest adding e.key to KeyError. I like the idea but in my 
> opinion currently it is not implementable in a reliable way.
> 
> a) if the party raising the exception does not pass any arguments, what would 
> the expected behaviour of e.key be? `None` is a valid key so returning this 
> can be misleading.
> 
> b) if the party raising the exception passes one argument, how do we know 
> it's a key and not a message? Take for instance "Set is empty" and such. 
> Presenting e.key = "Set is empty" is just wrong.

As per your patch, all builtins will have been converted to the two
argument form, though, and arguably they are the most common source of
KeyErrors.

> c) if the party raising the exception passes two arguments, we already know 
> which one is the key. So in this case it would work well but at the same time 
> it would be somewhat redundant.

What do you mean? You can certainly use e.args[-1] but it's an ugly and
highly unintuitive notation. I wish the args stuff could die peacefully.

Regards

Antoine.


___
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] #2651 - KeyError does not round trip strings

[Fred Drake]

2010/8/4 Łukasz Langa :
> 1. The patch makes KeyError behave analogically to IOError so that the first
> arg is now a message and the second is the actual key.

I agree with Antoine; there's no point to this.

> 2. Some people suggest adding e.key to KeyError. I like the idea but in my
> opinion currently it is not implementable in a reliable way.

This is interesting and useful.

I'd be really happy to see e.key be present if the key is known
(because it was specifically provided to the constructor:
KeyError(key=...)), or not present if the key isn't known.  (The idea
is much less interesting if code can't distinguish between the
key-is-known and the key-not-known cases.)

The runtime and standard library should be adjusted to provide the key
whenever possible, of course.

Though I doubt this would break anything, we've lived without this
long enough that the it doesn't represent a sufficient failing that
the moratorium should be broken.  It can wait.


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
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-checkins] r83704 - in python/branches/release26-maint: Lib/asyncore.py Misc/ACKS Misc/NEWS

[Barry Warsaw]

Hi Giampaolo,

Now that we're in quasi-freeze for 2.6.6 final, this is the kind of change I'd
like to review before backporting.  In this case, I'll let it through, but
please check with me first next time.

And thanks for your work!
-Barry

On Aug 04, 2010, at 10:58 AM, giampaolo.rodola wrote:

>Author: giampaolo.rodola
>Date: Wed Aug  4 10:58:38 2010
>New Revision: 83704
>
>Log:
>Merged revisions 83703 via svnmerge from 
>svn+ssh://python...@svn.python.org/python/branches/release27-maint
>
>
>  r83703 | giampaolo.rodola | 2010-08-04 10:35:25 +0200 (mer, 04 ago
> 2010) | 1 line 
>  fix issue #2944: asyncore doesn't handle connection refused
> correctly (patch by Alexander Shigin)
>
>
>
>Modified:
>   python/branches/release26-maint/   (props changed)
>   python/branches/release26-maint/Lib/asyncore.py
>   python/branches/release26-maint/Misc/ACKS
>   python/branches/release26-maint/Misc/NEWS
>
>Modified: python/branches/release26-maint/Lib/asyncore.py
>==
>--- python/branches/release26-maint/Lib/asyncore.py(original)
>+++ python/branches/release26-maint/Lib/asyncore.pyWed Aug  4
>10:58:38 2010 @@ -422,8 +422,11 @@
> self.handle_read()
> 
> def handle_connect_event(self):
>-self.connected = True
>+err = self.socket.getsockopt(socket.SOL_SOCKET,
>socket.SO_ERROR)
>+if err != 0:
>+raise socket.error(err, _strerror(err))
> self.handle_connect()
>+self.connected = True
> 
> def handle_write_event(self):
> if self.accepting:
>
>Modified: python/branches/release26-maint/Misc/ACKS
>==
>--- python/branches/release26-maint/Misc/ACKS  (original)
>+++ python/branches/release26-maint/Misc/ACKS  Wed Aug  4
>10:58:38 2010 @@ -817,3 +817,4 @@
> Peter Åstrand
> Jesse Noller
> Fredrik Håård
>+Alexander Shigin
>
>Modified: python/branches/release26-maint/Misc/NEWS
>==
>--- python/branches/release26-maint/Misc/NEWS  (original)
>+++ python/branches/release26-maint/Misc/NEWS  Wed Aug  4
>10:58:38 2010 @@ -89,6 +89,8 @@
> Library
> ---
> 
>+- Issue #2944: asyncore doesn't handle connection refused correctly.
>+
> - Issue #8447: Make distutils.sysconfig follow symlinks in the path to
>   the interpreter executable.  This fixes a failure of
> test_httpservers on OS X.


signature.asc
Description: PGP signature
___
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] Drive suffix

[Rob Cliffe]

Is there a way of determining the suffix used after a drive letter to denote a 
drive, e.g. on Windows the ":" in r"C:\Dir\Subdir\File.Ext" ?  Or is the colon 
so universal that it is considered unnecessary?  Should it be in the os module 
somewhere (as far as I can tell, it isn't, although every other kind of file 
path component separator seems to be) ?
Best wishes
Rob Cliffe___
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] Windows

[Barry Warsaw]

On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:

>It's a little disappointing to discover that despite the relatively
>large number of developers who have received MSDN licenses from
>Microsoft, none if us have the time to make sure that the buildbots are
>green for the 2.6.6 release.

Should note that I did try to build Python using my MSDN license for Windows 7
and Visual Studio 2010.  I only had an hour or so to attempt it, and did not
succeed, though I think I got as far as trying to properly situate various
dependent libraries (sqlite, ssl).

If anybody's successfully navigated the twisty maze, would you be able to
write something up on the wiki to describe the steps you've taken?

-Barry


signature.asc
Description: PGP signature
___
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 after the buildbots (in general)

[Barry Warsaw]

On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:

>I think the issue is that many core developers don't have the reflex
>to check buildbot state after they commit some changes (or at least
>on a regular, say weekly, basis), and so gradually the buildbots have
>a tendency to turn from green to red, one after another.

I'd classify this as a failure of the tools, not of the developers.  These
post-commit verification steps should be proactive, and scream really loud (or
even prevent future commits) until everything is green again.  Buildbots
themselves can be unstable, so this may or may not be workable, and changing
any of this will take valuable volunteer time.  It's also unsexy work.

-Barry


signature.asc
Description: PGP signature
___
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] Windows

[Brian Curtin]

On Wed, Aug 4, 2010 at 09:48, Barry Warsaw  wrote:

> On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:
>
> >It's a little disappointing to discover that despite the relatively
> >large number of developers who have received MSDN licenses from
> >Microsoft, none if us have the time to make sure that the buildbots are
> >green for the 2.6.6 release.
>
> Should note that I did try to build Python using my MSDN license for
> Windows 7
> and Visual Studio 2010.  I only had an hour or so to attempt it, and did
> not
> succeed, though I think I got as far as trying to properly situate various
> dependent libraries (sqlite, ssl).
>
> If anybody's successfully navigated the twisty maze, would you be able to
> write something up on the wiki to describe the steps you've taken?
>
> -Barry


I can expand the dev setup guide I wrote for the PSF Sprints to include the
third-party stuff, then try to get that in wider circulation. I currently
gloss over it to get a first-time contributor up and running quickly (since
someone's first look into core dev is unlikely to be fixing sqlite).

I haven't tried the current codebase on VS2010 yet, but it's on my todo
list.
___
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] w32 drive separator (was: Drive suffix)

[Oleg Broytman]

On Wed, Aug 04, 2010 at 03:45:45PM +0100, Rob Cliffe wrote:
> Is there a way of determining the suffix used after a drive letter to denote 
> a drive, e.g. on Windows the ":" in r"C:\Dir\Subdir\File.Ext" ?  Or is the 
> colon so universal that it is considered unnecessary?  Should it be in the os 
> module somewhere (as far as I can tell, it isn't, although every other kind 
> of file path component separator seems to be) ?

   It's not universal, exactly opposite - it's specific to a rare graphic
environment produced by a small company based in Redmond... sorry, I cannot
resist. (-:
   Because of this (':' being too specific) it's built right into ntpath.py
- the module that 'os' module imports when it finds itself running inside
that graphic environment. It's used as a character constant all over
ntpath.py without any name.

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
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] Drive suffix

[Guido van Rossum]

It's Windows specific syntax and always a colon. Use
os.path.splitdrive() to parse it. I don't think there's a need to add
a named constant for it (you're the first to ask, in my memory).

On Wed, Aug 4, 2010 at 7:45 AM, Rob Cliffe  wrote:
> Is there a way of determining the suffix used after a drive letter to denote
> a drive, e.g. on Windows the ":" in r"C:\Dir\Subdir\File.Ext" ?  Or is the
> colon so universal that it is considered unnecessary?  Should it be in the
> os module somewhere (as far as I can tell, it isn't, although every other
> kind of file path component separator seems to be) ?

-- 
--Guido van Rossum (python.org/~guido)
___
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 after the buildbots (in general)

[exarkun]

On 02:51 pm, ba...@python.org wrote:

On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:

I think the issue is that many core developers don't have the reflex
to check buildbot state after they commit some changes (or at least
on a regular, say weekly, basis), and so gradually the buildbots have
a tendency to turn from green to red, one after another.


I'd classify this as a failure of the tools, not of the developers. 
These
post-commit verification steps should be proactive, and scream really 
loud (or
even prevent future commits) until everything is green again. 
Buildbots
themselves can be unstable, so this may or may not be workable, and 
changing

any of this will take valuable volunteer time.  It's also unsexy work.


How hard is it to look at a web page?

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

Re: [Python-Dev] Looking after the buildbots (in general)

[Michael Foord]

On 04/08/2010 16:15, exar...@twistedmatrix.com wrote:

On 02:51 pm, ba...@python.org wrote:

On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:

I think the issue is that many core developers don't have the reflex
to check buildbot state after they commit some changes (or at least
on a regular, say weekly, basis), and so gradually the buildbots have
a tendency to turn from green to red, one after another.


I'd classify this as a failure of the tools, not of the developers. 
These
post-commit verification steps should be proactive, and scream really 
loud (or

even prevent future commits) until everything is green again. Buildbots
themselves can be unstable, so this may or may not be workable, and 
changing

any of this will take valuable volunteer time. It's also unsexy work.


How hard is it to look at a web page?


The hard part is remembering.

Michael



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




--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
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] Drive suffix

[James Mills]

On Thu, Aug 5, 2010 at 1:10 AM, Guido van Rossum  wrote:
> It's Windows specific syntax and always a colon. Use
> os.path.splitdrive() to parse it. I don't think there's a need to add
> a named constant for it (you're the first to ask, in my memory).

HI Guido, I'm not a windows user or developer, but I concur.
When I was reading this post I kept thinking to myself that Windows
is one of the only Operating Systems with a File system that reuiqres
this [A-Z]:\ syntax. All sensible POSIX systems I know and File Systems
all mount various other media on "mount points". *shrug*

--James

-- 
-- James Mills
--
-- "Problems are solved by method"
___
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] Drive suffix

[Rob Cliffe]

Thanks for your replies, guys.
As it happens, what sparked the question was trying to determine in a 
platform-independent way whether a path consisted of a bare drive 
specification (e.g. "C:").  I guess

   os.path.splitdrive(MyPath)[1] == ""
takes care of that.
Rob Cliffe


- Original Message - 
From: "Guido van Rossum" 

To: "Rob Cliffe" 
Cc: "Python-Dev" 
Sent: Wednesday, August 04, 2010 4:10 PM
Subject: Re: [Python-Dev] Drive suffix


It's Windows specific syntax and always a colon. Use
os.path.splitdrive() to parse it. I don't think there's a need to add
a named constant for it (you're the first to ask, in my memory).

On Wed, Aug 4, 2010 at 7:45 AM, Rob Cliffe  
wrote:
Is there a way of determining the suffix used after a drive letter to 
denote

a drive, e.g. on Windows the ":" in r"C:\Dir\Subdir\File.Ext" ? Or is the
colon so universal that it is considered unnecessary? Should it be in the
os module somewhere (as far as I can tell, it isn't, although every other
kind of file path component separator seems to be) ?


--
--Guido van Rossum (python.org/~guido) 


___
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] Windows

[Paul Moore]

On 4 August 2010 08:49, Tim Golden  wrote:
> I have watched the buildbot pages occasionally, especially when I see
> Windows-related commits going in, but several times "red" buildbots
> have turned out to be -- apparently -- environmental / local issues
> unrelated to commits. Obviously I could/should have contacted the
> buildbot owner to at least inform him or her that something was amiss.
> But somehow at that point one's technical enthusiasm for fixing a
> problem diminishes when it's not clear that there *is* a problem.
> (Grumble, grumble, mutter, mutter... :) )

I agree that having a buildbot of your own to administer tends to
encourage you to be more aware of issues - it certainly did for me.
However, from my own experience, the Windows buildbot environment is
fairly flaky, and I spend far too much time killing "stuck" python
processes and VS JIT debugger processes, rather than actually usefully
debugging real issues. (And I don't know of any way of finding out
where the stuck processes came from or what they were doing at the
time that they got stuck, so all I can do is kill them...)

I don't have any Windows sysadmin experience, so I struggle to fix
these types of problem, and doing so often takes up all the time that
would otherwise go to areas where I *could* do some good, digging into
genuine issues :-(

I don't really have any answer to this problem right now. Is it
possible to set up a local buildslave-like environment (so I can run
the test suite on my development PC without needing to set up access
and register that PC as a temporary buildslave, which wouldn't be
practical for me)? If I can get an environment where I can run the
tests as I need and debug them in place, I might be able to work on
improving the reliability of things.

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

Re: [Python-Dev] [python-committers] (Windows) buildbots on 3.x

[Paul Moore]

On 4 August 2010 13:05, Antoine Pitrou  wrote:

>> I'm also quite confused by the test_smtpd failures that pop up on some
>> of the test runs that I've had absolutely no luck reproducing locally
>> under OS X or Solaris.
>
> It happens when running test_smtplib before test_smtpb:

Nice! How did you work that out? I'd like to learn how to diagnose
this sort of thing, because it seems to come up a lot, and I'm not
much use at the moment :-)

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

Re: [Python-Dev] Looking after the buildbots (in general)

[Barry Warsaw]

On Aug 04, 2010, at 03:15 PM, exar...@twistedmatrix.com wrote:

>On 02:51 pm, ba...@python.org wrote:
>>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>>I think the issue is that many core developers don't have the reflex
>>>to check buildbot state after they commit some changes (or at least
>>>on a regular, say weekly, basis), and so gradually the buildbots have
>>>a tendency to turn from green to red, one after another.
>>
>>I'd classify this as a failure of the tools, not of the developers.
>>>These post-commit verification steps should be proactive, and scream
>>>really >loud (or
>>even prevent future commits) until everything is green again.
>>>Buildbots themselves can be unstable, so this may or may not be
>>>workable, and >changing
>>any of this will take valuable volunteer time.  It's also unsexy work.
>
>How hard is it to look at a web page?

That's not the right question :)

The real questions are: how hard is it to remember how to find the appropriate
web page, how hard is it to know which buildbots are *actually* stable enough
to rely on, how hard is it to decipher the results to know what they're
telling you?

-Barry


signature.asc
Description: PGP signature
___
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-committers] (Windows) buildbots on 3.x

[Antoine Pitrou]

Le mercredi 04 août 2010 à 16:28 +0100, Paul Moore a écrit :
> On 4 August 2010 13:05, Antoine Pitrou  wrote:
> 
> >> I'm also quite confused by the test_smtpd failures that pop up on some
> >> of the test runs that I've had absolutely no luck reproducing locally
> >> under OS X or Solaris.
> >
> > It happens when running test_smtplib before test_smtpb:
> 
> Nice! How did you work that out? I'd like to learn how to diagnose
> this sort of thing, because it seems to come up a lot, and I'm not
> much use at the moment :-)

I took a quick look at test_smtpd, and the one possibly fishy thing that
stood out was the monkeypatching of the socket module using
test.mock_socket. Since monkeypatching typically goes wrong when several
people monkeypatch the same thing, and the other test.mock_socket user
is test_smtplib, and since the buildbots run tests in random order
(rather than in deterministic alphabetic order), I simply tried to run
test_smtplib before test_smtpd.

Regards

Antoine.


___
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 after the buildbots (in general)

[exarkun]

On 03:17 pm, fuzzy...@voidspace.org.uk wrote:

On 04/08/2010 16:15, exar...@twistedmatrix.com wrote:

On 02:51 pm, ba...@python.org wrote:

On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:

I think the issue is that many core developers don't have the reflex
to check buildbot state after they commit some changes (or at least
on a regular, say weekly, basis), and so gradually the buildbots 
have

a tendency to turn from green to red, one after another.


I'd classify this as a failure of the tools, not of the developers. 
These
post-commit verification steps should be proactive, and scream really 
loud (or
even prevent future commits) until everything is green again. 
Buildbots
themselves can be unstable, so this may or may not be workable, and 
changing

any of this will take valuable volunteer time. It's also unsexy work.


How hard is it to look at a web page?


The hard part is remembering.


Seems to be setting the bar awfully low for Python developers.

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

Re: [Python-Dev] Windows

[Steve Holden]

On 8/4/2010 11:00 AM, Brian Curtin wrote:
> On Wed, Aug 4, 2010 at 09:48, Barry Warsaw  > wrote:
> 
> On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:
> 
> >It's a little disappointing to discover that despite the relatively
> >large number of developers who have received MSDN licenses from
> >Microsoft, none if us have the time to make sure that the buildbots are
> >green for the 2.6.6 release.
> 
> Should note that I did try to build Python using my MSDN license for
> Windows 7
> and Visual Studio 2010.  I only had an hour or so to attempt it, and
> did not
> succeed, though I think I got as far as trying to properly situate
> various
> dependent libraries (sqlite, ssl).
> 
> If anybody's successfully navigated the twisty maze, would you be
> able to
> write something up on the wiki to describe the steps you've taken?
> 
> -Barry
> 
> 
> I can expand the dev setup guide I wrote for the PSF Sprints to include
> the third-party stuff, then try to get that in wider circulation. I
> currently gloss over it to get a first-time contributor up and running
> quickly (since someone's first look into core dev is unlikely to be
> fixing sqlite).
> 
> I haven't tried the current codebase on VS2010 yet, but it's on my todo
> list.
> 
I think that could be incredibly useful. I've tried building Windows
Pythons in the past and stalled because I didn't have enough familiarity
with the VS environment.

regards
 Steve

-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

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

Re: [Python-Dev] Windows

[Steve Holden]

On 8/4/2010 11:00 AM, Brian Curtin wrote:
> On Wed, Aug 4, 2010 at 09:48, Barry Warsaw  > wrote:
> 
> On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:
> 
> >It's a little disappointing to discover that despite the relatively
> >large number of developers who have received MSDN licenses from
> >Microsoft, none if us have the time to make sure that the buildbots are
> >green for the 2.6.6 release.
> 
> Should note that I did try to build Python using my MSDN license for
> Windows 7
> and Visual Studio 2010.  I only had an hour or so to attempt it, and
> did not
> succeed, though I think I got as far as trying to properly situate
> various
> dependent libraries (sqlite, ssl).
> 
> If anybody's successfully navigated the twisty maze, would you be
> able to
> write something up on the wiki to describe the steps you've taken?
> 
> -Barry
> 
> 
> I can expand the dev setup guide I wrote for the PSF Sprints to include
> the third-party stuff, then try to get that in wider circulation. I
> currently gloss over it to get a first-time contributor up and running
> quickly (since someone's first look into core dev is unlikely to be
> fixing sqlite).
> 
> I haven't tried the current codebase on VS2010 yet, but it's on my todo
> list.
> 
I think that could be incredibly useful. I've tried building Windows
Pythons in the past and stalled because I didn't have enough familiarity
with the VS environment.

regards
 Steve

-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

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

Re: [Python-Dev] Windows

[Tim Golden]

On 04/08/2010 16:38, Steve Holden wrote:

On 8/4/2010 11:00 AM, Brian Curtin wrote:

On Wed, Aug 4, 2010 at 09:48, Barry Warsawmailto:ba...@python.org>>  wrote:

 On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:

 >It's a little disappointing to discover that despite the relatively
 >large number of developers who have received MSDN licenses from
 >Microsoft, none if us have the time to make sure that the buildbots are
 >green for the 2.6.6 release.

 Should note that I did try to build Python using my MSDN license for
 Windows 7
 and Visual Studio 2010.  I only had an hour or so to attempt it, and
 did not
 succeed, though I think I got as far as trying to properly situate
 various
 dependent libraries (sqlite, ssl).

 If anybody's successfully navigated the twisty maze, would you be
 able to
 write something up on the wiki to describe the steps you've taken?

 -Barry


I can expand the dev setup guide I wrote for the PSF Sprints to include
the third-party stuff, then try to get that in wider circulation. I
currently gloss over it to get a first-time contributor up and running
quickly (since someone's first look into core dev is unlikely to be
fixing sqlite).

I haven't tried the current codebase on VS2010 yet, but it's on my todo
list.


I think that could be incredibly useful. I've tried building Windows
Pythons in the past and stalled because I didn't have enough familiarity
with the VS environment.


Brian: could you remind us where that doc is, please? I've lost track of it.

In broad terms it's not too hard to get going once you've installed 
VS[*]; I've
rebuild several different fresh Python checkouts several times today 
while these

issues have been discussed, and generally it's a question of:

cd py3k (or whatever)
tools\buildbot\externals.bat
cd py3k\pcbuild
env
build -d
rt -d

and you're done and tested.

That said, I seem to be having build issues with ssl on 2.7 which I'll
try to look into. But the technique is fairly straightforward.

TJG

[*] And a small clutter of other tools for certain bits
___
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] pickle output not unique

[Kristján Valur Jónsson]

> -Original Message-
> From: "Martin v. Löwis" [mailto:mar...@v.loewis.de]
> Sent: 3. ágúst 2010 20:48
> To: Kristján Valur Jónsson
> Cc: Python-Dev
> Subject: Re: [Python-Dev] pickle output not unique
> 
> > I just wanted to point this out.  We'll attempt some local
> workarounds
> > here, but it should otherwise be simple to modify pickling to
> optionally
> > turn off this optimization and always generate the same output
> > irrespective of the internal reference counts of the objects.
> 
> I think there are many other instances where values that compare equal
> pickle differently in Python. By relying on this property for hashing,
> you are really operating on thin ice.

Well, it is not _that_ dangerous.  It just causes cache misses when they 
wouldn't be expected.
But since this has been brought up and dismissed in issue 8738, I won't pursue 
this further.

K
___
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] Windows

[Curt Hagenlocher]

On Wed, Aug 4, 2010 at 8:25 AM, Paul Moore  wrote:
>
> However, from my own experience, the Windows buildbot environment is
> fairly flaky, and I spend far too much time killing "stuck" python
> processes and VS JIT debugger processes, rather than actually usefully
> debugging real issues.

I would turn off JIT debugging. On an unattended machine, it's more
annoying than useful.
http://msdn.microsoft.com/en-us/library/5hs4b7a6(VS.80).aspx

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

Re: [Python-Dev] Looking after the buildbots (in general)

[Georg Brandl]

Am 04.08.2010 17:15, schrieb exar...@twistedmatrix.com:
> On 02:51 pm, ba...@python.org wrote:
>>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
>>>I think the issue is that many core developers don't have the reflex
>>>to check buildbot state after they commit some changes (or at least
>>>on a regular, say weekly, basis), and so gradually the buildbots have
>>>a tendency to turn from green to red, one after another.
>>
>>I'd classify this as a failure of the tools, not of the developers. 
>>These
>>post-commit verification steps should be proactive, and scream really 
>>loud (or
>>even prevent future commits) until everything is green again. 
>>Buildbots
>>themselves can be unstable, so this may or may not be workable, and 
>>changing
>>any of this will take valuable volunteer time.  It's also unsexy work.
> 
> How hard is it to look at a web page?

The hard part is to know *when* to look.  As you might have noticed, the
Python test suite does not run in ten seconds, especially on some of the
buildbots -- it can take 1-2 there to complete.  So if you look too soon,
you won't see all the results, and usually the slow systems are the
interesting ones.

Now we could of course have a commit hook that counts down two hours and
then sends an email to the committer "Now look at the buildbot!"...

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Windows

[Brian Curtin]

On Wed, Aug 4, 2010 at 10:49, Tim Golden  wrote:

> On 04/08/2010 16:38, Steve Holden wrote:
>
>> On 8/4/2010 11:00 AM, Brian Curtin wrote:
>>
>>> On Wed, Aug 4, 2010 at 09:48, Barry Warsaw>> >  wrote:
>>>
>>> On Aug 03, 2010, at 09:08 PM, Steve Holden wrote:
>>>
>>> >It's a little disappointing to discover that despite the relatively
>>> >large number of developers who have received MSDN licenses from
>>> >Microsoft, none if us have the time to make sure that the buildbots
>>> are
>>> >green for the 2.6.6 release.
>>>
>>> Should note that I did try to build Python using my MSDN license for
>>> Windows 7
>>> and Visual Studio 2010.  I only had an hour or so to attempt it, and
>>> did not
>>> succeed, though I think I got as far as trying to properly situate
>>> various
>>> dependent libraries (sqlite, ssl).
>>>
>>> If anybody's successfully navigated the twisty maze, would you be
>>> able to
>>> write something up on the wiki to describe the steps you've taken?
>>>
>>> -Barry
>>>
>>>
>>> I can expand the dev setup guide I wrote for the PSF Sprints to include
>>> the third-party stuff, then try to get that in wider circulation. I
>>> currently gloss over it to get a first-time contributor up and running
>>> quickly (since someone's first look into core dev is unlikely to be
>>> fixing sqlite).
>>>
>>> I haven't tried the current codebase on VS2010 yet, but it's on my todo
>>> list.
>>>
>>>  I think that could be incredibly useful. I've tried building Windows
>> Pythons in the past and stalled because I didn't have enough familiarity
>> with the VS environment.
>>
>
> Brian: could you remind us where that doc is, please? I've lost track of
> it.
>
> In broad terms it's not too hard to get going once you've installed VS[*];
> I've
> rebuild several different fresh Python checkouts several times today while
> these
> issues have been discussed, and generally it's a question of:
>
> cd py3k (or whatever)
> tools\buildbot\externals.bat
> cd py3k\pcbuild
> env
> build -d
> rt -d
>
> and you're done and tested.
>
> That said, I seem to be having build issues with ssl on 2.7 which I'll
> try to look into. But the technique is fairly straightforward.
>
> TJG
>
> [*] And a small clutter of other tools for certain bits


http://docs.pythonsprints.com/core_development/beginners.html

Building ssl requires Perl and nasm, and gets completed as a post-build
step. I haven't done that in a while but it's documented in
PCBuild/readme.txt. That's the stuff I'll be adding to the above document.
___
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] pickle output not unique

[Alexander Belopolsky]

2010/8/4 Kristján Valur Jónsson :
..
> Well, it is not _that_ dangerous.  It just causes cache misses when they 
> wouldn't be expected.
> But since this has been brought up and dismissed in issue 8738, I won't 
> pursue this further.

Don't read too much from the "dismissal" of issue 8738.  I will be
happy to reopen it if there are ideas on how to improve the situation.
  For example, it may be helpful to document whether the situation
improved in 3.x and whether pickletools.optimize produces more
consistent pickles.  If you change your mind, please leave a note on
the issue.
___
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 after the buildbots (in general)

[David Stanek]

On Wed, Aug 4, 2010 at 11:53 AM, Georg Brandl  wrote:
>
> The hard part is to know *when* to look.  As you might have noticed, the
> Python test suite does not run in ten seconds, especially on some of the
> buildbots -- it can take 1-2 there to complete.  So if you look too soon,
> you won't see all the results, and usually the slow systems are the
> interesting ones.
>
> Now we could of course have a commit hook that counts down two hours and
> then sends an email to the committer "Now look at the buildbot!"...
>

Why not have buildbot slaves email the committer when their change
broke the build. I realize that if you break 25 slaves it would not be
pleasant to receive 25 emails, but I've had worse things happen. Or
buildbot slaves can report failures to a mailing list or IRC chat.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
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 after the buildbots (in general)

[exarkun]

On 03:31 pm, ba...@python.org wrote:

On Aug 04, 2010, at 03:15 PM, exar...@twistedmatrix.com wrote:

On 02:51 pm, ba...@python.org wrote:

On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:

I think the issue is that many core developers don't have the reflex
to check buildbot state after they commit some changes (or at least
on a regular, say weekly, basis), and so gradually the buildbots 
have

a tendency to turn from green to red, one after another.


I'd classify this as a failure of the tools, not of the developers.

These post-commit verification steps should be proactive, and scream
really >loud (or

even prevent future commits) until everything is green again.

Buildbots themselves can be unstable, so this may or may not be
workable, and >changing
any of this will take valuable volunteer time.  It's also unsexy 
work.


How hard is it to look at a web page?


That's not the right question :)

The real questions are: how hard is it to remember how to find the 
appropriate

web page


Oh, come on.  I don't believe this.

how hard is it to know which buildbots are *actually* stable enough
to rely on,


This is more plausible.  But it's not the tools' fault that the test 
suite has intermittent failures.  Developers choose to add new features 
or change existing ones instead of fixing bugs in existing code or 
tests.  I'd call that a developer failure.

how hard is it to decipher the results to know what they're
telling you?


Red bad, green good.

A much more plausible explanation, to me, is that most developers don't 
really care if things are completely working most of the time.  They're 
happy to push the work onto other developers and onto the release team. 
And as long as other developers let them get away with that, it's not 
likely to stop.


But perhaps the people picking up the slack here don't mind and are 
happy to keep doing it, in which case nothing needs to change.


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

Re: [Python-Dev] Looking after the buildbots (in general)

[exarkun]

On 03:53 pm, g.bra...@gmx.net wrote:

Am 04.08.2010 17:15, schrieb exar...@twistedmatrix.com:

On 02:51 pm, ba...@python.org wrote:

On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:

I think the issue is that many core developers don't have the reflex
to check buildbot state after they commit some changes (or at least
on a regular, say weekly, basis), and so gradually the buildbots 
have

a tendency to turn from green to red, one after another.


I'd classify this as a failure of the tools, not of the developers.
These
post-commit verification steps should be proactive, and scream really
loud (or
even prevent future commits) until everything is green again.
Buildbots
themselves can be unstable, so this may or may not be workable, and
changing
any of this will take valuable volunteer time.  It's also unsexy 
work.


How hard is it to look at a web page?


The hard part is to know *when* to look.  As you might have noticed, 
the
Python test suite does not run in ten seconds, especially on some of 
the
buildbots -- it can take 1-2 there to complete.  So if you look too 
soon,

you won't see all the results, and usually the slow systems are the
interesting ones.

Now we could of course have a commit hook that counts down two hours 
and

then sends an email to the committer "Now look at the buildbot!"...


I don't think it's that hard to take a look at the end of the day (or 
before starting anything else the next morning).  All it really takes is 
a choice on the part of each developer to care whether or not their 
changes are correct.


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

Re: [Python-Dev] Looking after the buildbots (in general)

[Antoine Pitrou]

On Wed, 04 Aug 2010 16:45:37 -
exar...@twistedmatrix.com wrote:
> 
> I don't think it's that hard to take a look at the end of the day (or 
> before starting anything else the next morning).  All it really takes is 
> a choice on the part of each developer to care whether or not their 
> changes are correct.

And as reported by Ezio, using bbreport makes it extra easy:

$ bbreport.py -q 3.x
Selected builders: 20 / 80 (branch: 3.x)
3.x.dmg83717, 83666, 528, 403
ARMv4 Debian 3.x*** , 83681, 649, 636 # hung for 30 min
ARMv7Thumb Ubuntu 3.x  83025, 82997, 985, 985 # failed slave lost
[etc.]

http://code.google.com/p/bbreport/
hg clone https://bbreport.googlecode.com/hg/ bbreport

Regards

Antoine.


___
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 after the buildbots (in general)

[Georg Brandl]

Am 04.08.2010 18:45, schrieb exar...@twistedmatrix.com:
>>>How hard is it to look at a web page?
>>
>>The hard part is to know *when* to look.  As you might have noticed, 
>>the
>>Python test suite does not run in ten seconds, especially on some of 
>>the
>>buildbots -- it can take 1-2 there to complete.  So if you look too 
>>soon,
>>you won't see all the results, and usually the slow systems are the
>>interesting ones.
>>
>>Now we could of course have a commit hook that counts down two hours 
>>and
>>then sends an email to the committer "Now look at the buildbot!"...
> 
> I don't think it's that hard to take a look at the end of the day (or 
> before starting anything else the next morning).  All it really takes is 
> a choice on the part of each developer to care whether or not their 
> changes are correct.

That's true.  However, when most of the time you're looking at the buildbots
you have to check 10 different red ones, only to realize none of the failures
is related to any recent commit, this gets tiresome fast.

I know that the remedy is to get the buildbots stable, but hey, somebody has
to do that.  It's probably not you, and it's probably not me.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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 after the buildbots (in general)

[Georg Brandl]

Am 04.08.2010 18:21, schrieb David Stanek:
> On Wed, Aug 4, 2010 at 11:53 AM, Georg Brandl  wrote:
>>
>> The hard part is to know *when* to look.  As you might have noticed, the
>> Python test suite does not run in ten seconds, especially on some of the
>> buildbots -- it can take 1-2 there to complete.  So if you look too soon,
>> you won't see all the results, and usually the slow systems are the
>> interesting ones.
>>
>> Now we could of course have a commit hook that counts down two hours and
>> then sends an email to the committer "Now look at the buildbot!"...
>>
> 
> Why not have buildbot slaves email the committer when their change
> broke the build. I realize that if you break 25 slaves it would not be
> pleasant to receive 25 emails, but I've had worse things happen. Or
> buildbot slaves can report failures to a mailing list or IRC chat.

This is what we did once (or the mails were sent to python-dev, I don't
remember), but it became ugly fast whenever the buildbots became unstable.
Also, some of the buildbot slave owners do not have endless spare time
to look at issues on their side.

Once we manage to get them into a mostly stable situation again, we
should definitely enable notifications in on form or other again.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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 after the buildbots (in general)

[Barry Warsaw]

On Aug 04, 2010, at 06:58 PM, Antoine Pitrou wrote:

>On Wed, 04 Aug 2010 16:45:37 -
>exar...@twistedmatrix.com wrote:
>> 
>> I don't think it's that hard to take a look at the end of the day
>> (or before starting anything else the next morning).  All it really
>> takes is a choice on the part of each developer to care whether or
>> not their changes are correct.
>
>And as reported by Ezio, using bbreport makes it extra easy:
>
>$ bbreport.py -q 3.x
>Selected builders: 20 / 80 (branch: 3.x)
>3.x.dmg83717, 83666, 528, 403
>ARMv4 Debian 3.x*** , 83681, 649, 636 # hung for 30 min
>ARMv7Thumb Ubuntu 3.x  83025, 82997, 985, 985 # failed slave lost
>[etc.]
>
>http://code.google.com/p/bbreport/
>hg clone https://bbreport.googlecode.com/hg/ bbreport

It would be kind of nice to integrate this with release.py.

-Barry


signature.asc
Description: PGP signature
___
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] Windows

[Martin v. Löwis]

> I don't really have any answer to this problem right now. Is it
> possible to set up a local buildslave-like environment (so I can run
> the test suite on my development PC without needing to set up access
> and register that PC as a temporary buildslave, which wouldn't be
> practical for me)? If I can get an environment where I can run the
> tests as I need and debug them in place, I might be able to work on
> improving the reliability of things.

Not sure what you are asking. It's certainly possible to run the test
suite yourself: just invoke "python Lib\test\regrtest.py" or some such.

So I assume you are asking for something else.

Regards,
Martin
___
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] Add aware local time support to datetime module

[Alexander Belopolsky]

[I've got no response from python-ideas, so I am forwarding to python-dev.]

With addition of fixed offset timezone class and the timezone.utc
instance [0], it is easy to get UTC time as an aware datetime
instance:

>>> datetime.now(timezone.utc)
datetime.datetime(2010, 8, 3, 14, 16, 10, 670308, tzinfo=datetime.timezone.utc)

However, if you want to keep time in your local timezone, getting an
aware datetime is almost a catch 22.  If you know your timezone UTC
offset, you can do

>>> EDT = timezone(timedelta(hours=-4))
>>> datetime.now(EDT)
datetime.datetime(2010, 8, 3, 10, 20, 23, 769537,
tzinfo=datetime.timezone(datetime.timedelta(-1, 72000)))

but the problem is that there is no obvious or even correct way to
find local timezone UTC offset. [1]

In a comment on issue #5094 ("datetime lacks concrete tzinfo
implementation for UTC"), I proposed to address this problem in a
localtime([t]) function that would return current time (or time
corresponding to the optional datetime argument) as an aware datetime
object carrying local timezone information in a tzinfo set to an
appropriate timezone instance.   This solution is attractive by its
simplicity, but there are several problems:

1. An aware datetime cannot carry all information that system
localtime() supplies in a time tuple.  Specifically, the is_dst flag
is lost.  This is not a problem for most applications as long as
timezone UTC offset and timezone name are available, but may be an
issue when interoperability with the time module is required.

2.  Datetime's tzinfo interface was designed with the idea that
<2010-11-06 12:00 EDT> + <1 day> =  <2010-11-07 12:00 EST>, not
<2010-11-07 12:00 EDT>. It other words, if I have lunch with someone
at noon (12:00 EDT) on Saturday the day before first Sunday in
November, and want to meet again "at the same time tomorrow", I mean
12:00 EST, not 24 hours later.  With localtime() returning datetime
with tzinfo set to fixed offset timezone, however, localtime()  +
timedelta(1) will mean exactly 24 hours later and the result will be
expressed in an unusual for the given location timezone.

An alternative approach is the one recommended in the python manual.
[3]  One could implement a LocalTimezone class with utcoffset(),
tzname() and dst() extracting information from system mktime and
localtime calls.  This approach has its own shortcomings:

1. While adding integral number of days to datetimes in business
setting, it is natural to expect automatic timezone adjustments, it is
not as clearcut when adding hours or minutes.

2. The tzinfo.utcoffset() interface that expects *standard* local time
as an argument is confusing to many users.  Even the "official"
example in the python manual gets it wrong. [4]

3. datetime(..., tzinfo=LocalTimezone()) is ambiguous during the
"repeated hour" when local clock is set back in DST to standard time
transition.

As far as I can tell, the only way to resolve the last problem is to
add is_dst flag to the datetime object, which would also be the
only way to achieve full interoperability between datetime objects and
time tuples. [5]

The traditional answer to call for improvement of timezone support in
datetime module has been: "this is upto 3rd parties to implement."
Unfortunately, stdlib is asking 3rd parties to implement an impossible
interface without giving access to the necessary data.   The
impossibility comes from the requirement that dst() method should find
out whether local time represents DST or standard time while there is
an hour each year when the same local time can be either.  The missing
data is the system UTC offset when it changes historically.  The time
module only gives access to the current UTC offset.

My preference is to implement the first alternative - localtime([t])
returning aware datetime with fixed offset timezone.  This will solve
the problem of python's lack of access to the universally available
system facilities that are necessary to implement any kind of aware
local time support.

[0] http://docs.python.org/dev/library/datetime.html#timezone-objects
[1] http://bugs.python.org/issue1647654
[2] http://bugs.python.org/issue5094#msg106997
[3] http://docs.python.org/library/datetime.html#tzinfo-objects
[4] http://bugs.python.org/issue9063
[5] http://bugs.python.org/issue9004
___
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] Windows

[Martin v. Löwis]

> http://docs.pythonsprints.com/core_development/beginners.html
> 
> Building ssl requires Perl and nasm, and gets completed as a post-build
> step. I haven't done that in a while but it's documented in
> PCBuild/readme.txt. That's the stuff I'll be adding to the above document.

Perl shouldn't be a requirement if you use the OpenSSL copy from
svn.python.org.

Regards,
Martin
___
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-committers] (Windows) buildbots on 3.x

[Martin v. Löwis]

>>> It happens when running test_smtplib before test_smtpb:
>>
>> Nice! How did you work that out? I'd like to learn how to diagnose
>> this sort of thing, because it seems to come up a lot, and I'm not
>> much use at the moment :-)
> 
> I simply tried to run test_smtplib before test_smtpd.

A more deterministic (and more tedious) way is this: if you
suspect that some failure might be due to the order of test cases,
take a build log from the build bot where it fails, and run the tests
in the exact same order. See whether the problem reproduces.

If it does, drop tests from the test sequence until you end up with
the minimum number of tests that you need to run in sequence (and yes,
I had interworkings of three test modules at some point).

Of course, educated guessing can accelerate the process.

Regards,
Martin
___
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 after the buildbots (in general)

[Steve Holden]

On 8/4/2010 12:42 PM, exar...@twistedmatrix.com wrote:
> On 03:31 pm, ba...@python.org wrote:
>> On Aug 04, 2010, at 03:15 PM, exar...@twistedmatrix.com wrote:
>>> On 02:51 pm, ba...@python.org wrote:
 On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
> I think the issue is that many core developers don't have the reflex
> to check buildbot state after they commit some changes (or at least
> on a regular, say weekly, basis), and so gradually the buildbots have
> a tendency to turn from green to red, one after another.

 I'd classify this as a failure of the tools, not of the developers.
> These post-commit verification steps should be proactive, and scream
> really >loud (or
 even prevent future commits) until everything is green again.
> Buildbots themselves can be unstable, so this may or may not be
> workable, and >changing
 any of this will take valuable volunteer time.  It's also unsexy work.
>>>
>>> How hard is it to look at a web page?
>>
>> That's not the right question :)
>>
>> The real questions are: how hard is it to remember how to find the
>> appropriate
>> web page
> 
> Oh, come on.  I don't believe this.
>> how hard is it to know which buildbots are *actually* stable enough
>> to rely on,
> 
> This is more plausible.  But it's not the tools' fault that the test
> suite has intermittent failures.  Developers choose to add new features
> or change existing ones instead of fixing bugs in existing code or
> tests.  I'd call that a developer failure.
>> how hard is it to decipher the results to know what they're
>> telling you?
> 
> Red bad, green good.
> 
> A much more plausible explanation, to me, is that most developers don't
> really care if things are completely working most of the time.  They're
> happy to push the work onto other developers and onto the release team.
> And as long as other developers let them get away with that, it's not
> likely to stop.
> 
> But perhaps the people picking up the slack here don't mind and are
> happy to keep doing it, in which case nothing needs to change.

This whole discussion seems to make it clear that the release manager
procedures are still ill-defined in certain areas. Otherwise a release
manager could proceed by reading a web page an even, heaven help us,
following specific links to ensure particular actions were taken.

But I see rules being established ("there's a language moratorium: no
changes!", "no release should be made unless the buildbots are *all*
green") and then ignored apparently on a whim. This doesn't give people
any confidence that the rules actually mean much, and I think ignoring
the latter rule can negatively affect quality.

Establishing comprehensive procedures can be as difficult as
programming, though, and requires skills that have eluded me through a
fairly lengthy technical career. So it also boils down to shortage of
manpower of a particular kind. People with programming skill would,
understandably, rather invest their time in something they are good at.

regards
 Steve


-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

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

Re: [Python-Dev] [python-committers] (Windows) buildbots on 3.x

[Michael Foord]

On 04/08/2010 18:53, "Martin v. Löwis" wrote:

It happens when running test_smtplib before test_smtpb:
 

Nice! How did you work that out? I'd like to learn how to diagnose
this sort of thing, because it seems to come up a lot, and I'm not
much use at the moment :-)
   

I simply tried to run test_smtplib before test_smtpd.
 

A more deterministic (and more tedious) way is this: if you
suspect that some failure might be due to the order of test cases,
take a build log from the build bot where it fails, and run the tests
in the exact same order. See whether the problem reproduces.

If it does, drop tests from the test sequence until you end up with
the minimum number of tests that you need to run in sequence (and yes,
I had interworkings of three test modules at some point).

   


A colleague in a previous job wrote a tool that would repeat a test 
sequence using a binary chop to find test interactions... It could take 
a while to run, but was usually faster than manually trying to find them 
(assuming educated guessing had already failed).


Michael


Of course, educated guessing can accelerate the process.

Regards,
Martin
___
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/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
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 after the buildbots (in general)

[Łukasz Langa]

Wiadomość napisana przez Steve Holden w dniu 2010-08-04, o godz. 19:56:

> But I see rules being established ("there's a language moratorium: no
> changes!", "no release should be made unless the buildbots are *all*
> green") and then ignored apparently on a whim. This doesn't give people
> any confidence that the rules actually mean much

Very good point.

-- 
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

___
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 after the buildbots (in general)

[Antoine Pitrou]

On Wed, 04 Aug 2010 13:56:27 -0400
Steve Holden  wrote:
> 
> This whole discussion seems to make it clear that the release manager
> procedures are still ill-defined in certain areas. Otherwise a release
> manager could proceed by reading a web page an even, heaven help us,
> following specific links to ensure particular actions were taken.

This isn't about release management. If we care about buildbots only
the few days before a release, we are doomed.

> Establishing comprehensive procedures can be as difficult as
> programming, though, and requires skills that have eluded me through a
> fairly lengthy technical career. So it also boils down to shortage of
> manpower of a particular kind.

The problem is more of gathering support for a particular policy or
procedure, giving that it isn't necessarily part of the established
culture. There are certainly some of us who do care about buildbot
stability and general test suite quality (a few months ago, we had a
majority of green buildbots, quite consistently; but keeping those
buildbots green in the face of daily SVN activity is an uphill battle
if we don't get support from the majority of committers).

Regards

Antoine.


___
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 after the buildbots (in general)

[Barry Warsaw]

On Aug 04, 2010, at 01:56 PM, Steve Holden wrote:

>But I see rules being established ("there's a language moratorium: no
>changes!", "no release should be made unless the buildbots are *all*
>green") and then ignored apparently on a whim. This doesn't give people
>any confidence that the rules actually mean much, and I think ignoring
>the latter rule can negatively affect quality.

I don't believe we've ever had a rule (as embodied in PEP 101) that a release
requires all buildbots to be green.  I think that would be unachievable due in
large part to the buildbot infrastructure itself not being very stable.  We
have identified some buildbots as "stable" ones and PEP 101 says:

  ___ Check the stable buildbots.

  Go to http://www.python.org/dev/buildbot/stable/

  (the trailing slash is required).  Look at the buildbots for the release
  you're making.  Ignore any that are offline (or inform the community so
  they can be restarted).  If what remains are (mostly) green buildbots,
  you're good to go.  If you have non-offline red buildbots, you may want
  to hold up the release until they are fixed.  Review the problems and
  use your judgement, taking into account whether you are making an alpha,
  beta, or final release.

Even having non-offline stable buildbots completely green for a release would
take work we don't have the manpower for.  When I'm doing a release, I
certainly consult both the stable and unstable buildbots, but I always run the
full test suite on local platforms I have access too, which covers Linux, OS
X, and hopefully soon Windows.  #python-dev is helpful here for providing some
additional sanity checks.

-Barry


signature.asc
Description: PGP signature
___
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] question

[Terry Reedy]

On 8/4/2010 3:08 AM, Senthil Kumaran wrote:

Hello,

Please ask the support questions at:

http://groups.google.com/group/comp.lang.python


Some people filter out posts from google because of spam.
Better gmane.comp.python.general at news.gmane.org
or python-list at python.org.

--
Terry Jan Reedy

___
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] Windows

[Paul Moore]

On 4 August 2010 18:42, "Martin v. Löwis"  wrote:
>> I don't really have any answer to this problem right now. Is it
>> possible to set up a local buildslave-like environment (so I can run
>> the test suite on my development PC without needing to set up access
>> and register that PC as a temporary buildslave, which wouldn't be
>> practical for me)? If I can get an environment where I can run the
>> tests as I need and debug them in place, I might be able to work on
>> improving the reliability of things.
>
> Not sure what you are asking. It's certainly possible to run the test
> suite yourself: just invoke "python Lib\test\regrtest.py" or some such.
>
> So I assume you are asking for something else.

Sorry, I wasn't clear. The issues I see tend to look like they come
from the test suite being run under the control of the buildbot
service - issues caused by not having a terminal session or window
station (like the JIT debugger appearing, which Curt pointed out a way
of addressing) or issues relating to my seeing orphaned python_d.exe
processes which never occur for me when running the test suite
manually.

I'm guessing that these issues aren't "simple" test failures, but
somehow triggered by the way in which the environment buildbot
provides differs from a "normal" console session, and so I was looking
for a way to reproduce those conditions.

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

Re: [Python-Dev] Looking after the buildbots (in general)

[Martin v. Löwis]

> This whole discussion seems to make it clear that the release manager
> procedures are still ill-defined in certain areas.

No. It rather makes clear that people who never had the role of release
manager

> Otherwise a release
> manager could proceed by reading a web page an even, heaven help us,
> following specific links to ensure particular actions were taken.

When Barry had the keys to the time machine, he wrote PEP 101,
to give you a web page with specific links in it:

http://www.python.org/dev/peps/pep-0101/

> But I see rules being established ("there's a language moratorium: no
> changes!", "no release should be made unless the buildbots are *all*
> green") and then ignored apparently on a whim.

What makes you say that?

> Establishing comprehensive procedures can be as difficult as
> programming, though, and requires skills that have eluded me through a
> fairly lengthy technical career. So it also boils down to shortage of
> manpower of a particular kind. People with programming skill would,
> understandably, rather invest their time in something they are good at.

I think you are belittling the contributions of past and present
release managers.

Regards,
Martin
___
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] Windows

[Paul Moore]

On 4 August 2010 15:48, Barry Warsaw  wrote:
> Should note that I did try to build Python using my MSDN license for Windows 7
> and Visual Studio 2010.  I only had an hour or so to attempt it, and did not
> succeed, though I think I got as far as trying to properly situate various
> dependent libraries (sqlite, ssl).
>
> If anybody's successfully navigated the twisty maze, would you be able to
> write something up on the wiki to describe the steps you've taken?

I could probably reasonably easily set up a (VMWare/VirtualBox) VM
image of a Windows 7 system with VS installed and all the
infrastructure set up for Python development/testing, using my MSDN
license (in fact, that's something I keep meaning to do for my own
purposes, anyway).

I don't know what issues there might be in making that available for
others to use - on the one hand, it would need to be protected so that
it couldn't be taken by just anyone, and it may be necessary to set
something up to allow other users to re-register the software with
their own license keys, but in principle that's just "a matter of
programming"...

Hosting might also be fun - I'm on an ADSL connection so uploading a
(multi-)gigabyte image could be a challenge :-)

If there's interest in this (and more particularly, if anyone could
offer advice on what would be needed to be sure I do it legally!), let
me know and I'll look into it.
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows

[Martin v. Löwis]

Am 04.08.2010 21:03, schrieb Paul Moore:
> On 4 August 2010 18:42, "Martin v. Löwis"  wrote:
>>> I don't really have any answer to this problem right now. Is it
>>> possible to set up a local buildslave-like environment (so I can run
>>> the test suite on my development PC without needing to set up access
>>> and register that PC as a temporary buildslave, which wouldn't be
>>> practical for me)? If I can get an environment where I can run the
>>> tests as I need and debug them in place, I might be able to work on
>>> improving the reliability of things.
> 
> Sorry, I wasn't clear. The issues I see tend to look like they come
> from the test suite being run under the control of the buildbot
> service - issues caused by not having a terminal session or window
> station (like the JIT debugger appearing, which Curt pointed out a way
> of addressing) or issues relating to my seeing orphaned python_d.exe
> processes which never occur for me when running the test suite
> manually.

Ah. It should certainly be possible to set this up locally - you just
need to run a buildbot master as well, either on the same machine
or a different one. The only thing you can't then get is automatic
notifications on commits. You could emulate this with manually
triggering builds over the master web pages, or by using buildbot's
svnpoller change source (which defaults to a poll interval of 10min).

To get started, I could share with you the master configuration of
python.org (with account information stripped, of course).

Regards,
Martin


___
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 after the buildbots (in general)

[Neil Schemenauer]

Georg Brandl  wrote:
> The hard part is to know *when* to look.  As you might have noticed, the
> Python test suite does not run in ten seconds, especially on some of the
> buildbots -- it can take 1-2 there to complete.

Based on this and other issues, I don't think it's practical to
expect that people will always check that their commits pass tests
on all platforms.

Perhaps a slight change in culture is necessary.  When someone finds
a problem with a buildbot, the first response is should be to
request that the committer attempt to fix the problem.  Finding the
guilty party can be easier said than done since there could be
multiple problems or if the problem has been present for a long
time.  Another complication is that the commiter may not have access
to the plaform and require it for debugging purposes.

Basically, I think better communication could mostly solve the
problem.  If someone finds a test failing on a certain plaform, it's
okay to complain about it.   You don't have to fix it yourself.
Perhaps the simpliest approach would be to open a new issue.

  Neil

___
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] Windows

[Paul Moore]

On 4 August 2010 20:17, "Martin v. Löwis"  wrote:

> Ah. It should certainly be possible to set this up locally - you just
> need to run a buildbot master as well, either on the same machine
> or a different one. The only thing you can't then get is automatic
> notifications on commits. You could emulate this with manually
> triggering builds over the master web pages, or by using buildbot's
> svnpoller change source (which defaults to a poll interval of 10min).
>
> To get started, I could share with you the master configuration of
> python.org (with account information stripped, of course).

Thanks, I'll have a look at what I need to set up when I next get some
time (which may be a few weeks, as I'm on holiday soon :-)). When I
get to a suitable point, I'll get back to you.

It may be that setting up a full master/slave setup is more effort
than it's going to be worth to me (after all, I have a buildslave to
work on in any case...) - I was thinking more of something a little
simpler, just a means of running the tests manually in a service-type
environment. If the buildmaster/slave setup is more than I feel like
setting up, I'll look into that as an alternative.

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

Re: [Python-Dev] Looking after the buildbots (in general)

[Steve Holden]

On 8/4/2010 2:57 PM, "Martin v. Löwis" wrote:
>> This whole discussion seems to make it clear that the release manager
>> procedures are still ill-defined in certain areas.
> 
> No. It rather makes clear that people who never had the role of release
> manager
> 
>> Otherwise a release
>> manager could proceed by reading a web page an even, heaven help us,
>> following specific links to ensure particular actions were taken.
> 
> When Barry had the keys to the time machine, he wrote PEP 101,
> to give you a web page with specific links in it:
> 
> http://www.python.org/dev/peps/pep-0101/
> 
>> But I see rules being established ("there's a language moratorium: no
>> changes!", "no release should be made unless the buildbots are *all*
>> green") and then ignored apparently on a whim.
> 
> What makes you say that?
> 
>> Establishing comprehensive procedures can be as difficult as
>> programming, though, and requires skills that have eluded me through a
>> fairly lengthy technical career. So it also boils down to shortage of
>> manpower of a particular kind. People with programming skill would,
>> understandably, rather invest their time in something they are good at.
> 
> I think you are belittling the contributions of past and present
> release managers.
> 
I'd prefer to say I was displaying my ignorance.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

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

Re: [Python-Dev] Looking after the buildbots (in general)

[Georg Brandl]

Am 04.08.2010 17:53, schrieb Georg Brandl:
> Am 04.08.2010 17:15, schrieb exar...@twistedmatrix.com:
>> On 02:51 pm, ba...@python.org wrote:
>>>On Aug 04, 2010, at 11:16 AM, Antoine Pitrou wrote:
I think the issue is that many core developers don't have the reflex
to check buildbot state after they commit some changes (or at least
on a regular, say weekly, basis), and so gradually the buildbots have
a tendency to turn from green to red, one after another.
>>>
>>>I'd classify this as a failure of the tools, not of the developers. 
>>>These
>>>post-commit verification steps should be proactive, and scream really 
>>>loud (or
>>>even prevent future commits) until everything is green again. 
>>>Buildbots
>>>themselves can be unstable, so this may or may not be workable, and 
>>>changing
>>>any of this will take valuable volunteer time.  It's also unsexy work.
>> 
>> How hard is it to look at a web page?
> 
> The hard part is to know *when* to look.  As you might have noticed, the
> Python test suite does not run in ten seconds, especially on some of the
> buildbots -- it can take 1-2 there to complete.

That should be "1-2 hours", by the way...

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] #2651 - KeyError does not round trip strings

[Nick Coghlan]

2010/8/5 Fred Drake :
> 2010/8/4 Łukasz Langa :
>> 1. The patch makes KeyError behave analogically to IOError so that the first
>> arg is now a message and the second is the actual key.
>
> I agree with Antoine; there's no point to this.
>
>> 2. Some people suggest adding e.key to KeyError. I like the idea but in my
>> opinion currently it is not implementable in a reliable way.
>
> This is interesting and useful.
>
> I'd be really happy to see e.key be present if the key is known
> (because it was specifically provided to the constructor:
> KeyError(key=...)), or not present if the key isn't known.  (The idea
> is much less interesting if code can't distinguish between the
> key-is-known and the key-not-known cases.)
>
> The runtime and standard library should be adjusted to provide the key
> whenever possible, of course.
>
> Though I doubt this would break anything, we've lived without this
> long enough that the it doesn't represent a sufficient failing that
> the moratorium should be broken.  It can wait.

+1 on what Fred said (i.e. post-moratorium, add a keyword-only "key"
argument to KeyError, set "e.key" only if that argument is supplied,
update the standard library to supply it and use a default message of
"'Key not found: %r' % key" if the key argument is supplied without an
explicit message). Also +1 for doing the equivalent with
AttributeError and an "attr" keyword only argument.

Since a keyword-only approach doesn't actually *break* any current
code, I'm only -0 on doing that for 3.2 rather than -1.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 after the buildbots (in general)

[Antoine Pitrou]

On Wed, 04 Aug 2010 23:53:22 +0200
Georg Brandl  wrote:
> > 
> > The hard part is to know *when* to look.  As you might have noticed, the
> > Python test suite does not run in ten seconds, especially on some of the
> > buildbots -- it can take 1-2 there to complete.
> 
> That should be "1-2 hours", by the way...

But if the buildbot is late, it can sometimes be 1-2 days.

Antoine.


___
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] #2651 - KeyError does not round trip strings

[Fred Drake]

On Wed, Aug 4, 2010 at 5:57 PM, Nick Coghlan  wrote:
> and use a default message of
> "'Key not found: %r' % key" if the key argument is supplied without an
> explicit message

I suspect you meant a default message of

'Key not found: %r' % (key,)

since `key` might be a 1-tuple.  :-)


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
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] #2651 - KeyError does not round trip strings

[Nick Coghlan]

On Thu, Aug 5, 2010 at 8:02 AM, Fred Drake  wrote:
> On Wed, Aug 4, 2010 at 5:57 PM, Nick Coghlan  wrote:
>> and use a default message of
>> "'Key not found: %r' % key" if the key argument is supplied without an
>> explicit message
>
> I suspect you meant a default message of
>
>    'Key not found: %r' % (key,)
>
> since `key` might be a 1-tuple.  :-)

Gah, you're right.

Maybe I should have said "'Key not found: {}'.format(key)" :)

Crazy-overloaded-mod-operators'ly,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 after the buildbots (in general)

[Georg Brandl]

Am 04.08.2010 20:25, schrieb Barry Warsaw:
> On Aug 04, 2010, at 01:56 PM, Steve Holden wrote:
> 
>>But I see rules being established ("there's a language moratorium: no
>>changes!", "no release should be made unless the buildbots are *all*
>>green") and then ignored apparently on a whim. This doesn't give people
>>any confidence that the rules actually mean much, and I think ignoring
>>the latter rule can negatively affect quality.
> 
> I don't believe we've ever had a rule (as embodied in PEP 101) that a release
> requires all buildbots to be green.  I think that would be unachievable due in
> large part to the buildbot infrastructure itself not being very stable.  We
> have identified some buildbots as "stable" ones and PEP 101 says:

...

> Even having non-offline stable buildbots completely green for a release would
> take work we don't have the manpower for.  When I'm doing a release, I
> certainly consult both the stable and unstable buildbots, but I always run the
> full test suite on local platforms I have access too, which covers Linux, OS
> X, and hopefully soon Windows.  #python-dev is helpful here for providing some
> additional sanity checks.

Same here.  For 3.2a1, I looked at the stable buildbots -- unfortunately, three
out of six were offline.  Of the other three, I fixed a few real bugs, and in
the end two of them were green.  The last one, a Windows 7 machine, had some
obscure failures building OpenSSL, about which I consulted Martin and David,
the owner, and some real issues with the new OpenSSL version were fixed, but
in the end it was still red.

So, I think in the end having the buildbots was a success, even if only 2/6
were green :)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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 after the buildbots (in general)

[Georg Brandl]

Am 04.08.2010 19:56, schrieb Steve Holden:

> This whole discussion seems to make it clear that the release manager
> procedures are still ill-defined in certain areas.

If you mean to imply that a release manager should care for the stability
of "their" branch also in between of releases -- I'd love to do that,
but I'd need a 36-hour day then.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] #2651 - KeyError does not round trip strings

[Łukasz Langa]

Wiadomość napisana przez Nick Coghlan w dniu 2010-08-04, o godz. 23:57:

> 2010/8/5 Fred Drake :
>> 2010/8/4 Łukasz Langa :
>>> 1. The patch makes KeyError behave analogically to IOError so that the first
>>> arg is now a message and the second is the actual key.
>> 
>> I agree with Antoine; there's no point to this.

So I'm proposing to close the original issue #2651 and not include what's there.
(see below though)

>> 
>>> 2. Some people suggest adding e.key to KeyError. I like the idea but in my
>>> opinion currently it is not implementable in a reliable way.
>> 
>> This is interesting and useful.
>> 
>> I'd be really happy to see e.key be present if the key is known
>> (because it was specifically provided to the constructor:
>> KeyError(key=...)), or not present if the key isn't known.  (The idea
>> is much less interesting if code can't distinguish between the
>> key-is-known and the key-not-known cases.)
>> 
>> The runtime and standard library should be adjusted to provide the key
>> whenever possible, of course.
>> 
>> Though I doubt this would break anything, we've lived without this
>> long enough that the it doesn't represent a sufficient failing that
>> the moratorium should be broken.  It can wait.
> 
> +1 on what Fred said (i.e. post-moratorium, add a keyword-only "key"
> argument to KeyError, set "e.key" only if that argument is supplied,
> update the standard library to supply it and use a default message of
> "'Key not found: %r' % key" if the key argument is supplied without an
> explicit message). Also +1 for doing the equivalent with
> AttributeError and an "attr" keyword only argument.

Good stuff guys. Shall we do an e.index for IndexErrors as well?

> Since a keyword-only approach doesn't actually *break* any current
> code, I'm only -0 on doing that for 3.2 rather than -1.

I'm -1 because we would alter the standard library to use this functionality
which would make it incompatible with other implementations. That is of
course unless Guido says we should add it anyway ;)

We might create a separate issue superseding #2651 which will be all about
presenting sensible named arguments for built-in exceptions. Does this sound
like a good plan?

-- 
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

___
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] Python 2.6.6 release candidate 1 now available

[Barry Warsaw]

Hello fellow Pythoneers and Pythonistas,

The source tarballs and Windows installers for the first (and hopefully only)
Python 2.6.6 release candidate is now available:

http://www.python.org/download/releases/2.6.6/

As usual, we would love it if you could download, install, and test these with
your favorite projects and environments.  A truly impressive number of bug
have been fixed since Python 2.6.5, with the full NEWS file available here:

http://www.python.org/download/releases/2.6.6/NEWS.txt

Barring complications, we expect to release Python 2.6.6 final on August 16,
2010.

Please note that with the release of Python 2.7 final on July 3, 2010, and in
accordance with Python policy, Python 2.6.6 is the last scheduled bug fix
maintenance release of the 2.6 series.  Because of this, your testing of this
release candidate will help immensely.  We will of course continue to support
security fixes in Python 2.6 for quite some time.

My thanks go out to everyone who has helped contribute fixes great and small,
and much testing and bug tracker gardening for Python 2.6.6.  The excellent
folks on #python-dev are true Pythonic heros too.

Enjoy,
-Barry
(on behalf of the Python development community)


signature.asc
Description: PGP signature
___
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] #2651 - KeyError does not round trip strings

[Eric Smith]

On 8/4/2010 6:09 PM, Nick Coghlan wrote:

On Thu, Aug 5, 2010 at 8:02 AM, Fred Drake  wrote:

On Wed, Aug 4, 2010 at 5:57 PM, Nick Coghlan  wrote:

and use a default message of
"'Key not found: %r' % key" if the key argument is supplied without an
explicit message


I suspect you meant a default message of

'Key not found: %r' % (key,)

since `key` might be a 1-tuple.  :-)


Gah, you're right.

Maybe I should have said "'Key not found: {}'.format(key)" :)


'Key not found: {!r}'.format(key)

Eric.
___
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] #2651 - KeyError does not round trip strings

[Antoine Pitrou]

On Thu, 5 Aug 2010 07:57:07 +1000
Nick Coghlan  wrote:
> 
> +1 on what Fred said (i.e. post-moratorium, add a keyword-only "key"
> argument to KeyError, set "e.key" only if that argument is supplied,
> update the standard library to supply it and use a default message of
> "'Key not found: %r' % key" if the key argument is supplied without an
> explicit message). Also +1 for doing the equivalent with
> AttributeError and an "attr" keyword only argument.

Keyword-only arguments are rather annoying to use from C code, though.

Regards

Antoine.


___
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 after the buildbots (in general)

[Steve Holden]

On 8/4/2010 6:11 PM, Georg Brandl wrote:
> Am 04.08.2010 19:56, schrieb Steve Holden:
> 
>> This whole discussion seems to make it clear that the release manager
>> procedures are still ill-defined in certain areas.
> 
> If you mean to imply that a release manager should care for the stability
> of "their" branch also in between of releases -- I'd love to do that,
> but I'd need a 36-hour day then.
> 
I'll see if I can get God to extend it for you. I honestly do understand
that everyone else works under the same restrictions of time that I do
... and I appreciate all the hard work the release managers continue to
put in.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Drive suffix

[Greg Ewing]

James Mills wrote:

Windows
is one of the only Operating Systems with a File system that reuiqres
this [A-Z]:\ syntax.


There's also VMS, but it uses a colon too. Also its
pathnames are funky enough in other ways that it
needs its own os-specific pathname routines.

I'm not aware of any system that's "just like Windows"
except that it uses something other than colons.

--
Greg
___
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 after the buildbots (in general)

[Barry Warsaw]

On Aug 04, 2010, at 06:39 PM, Steve Holden wrote:

>I'll see if I can get God to extend it for you.

No need to involve the supernatural Steve!  Just approve that PSF grant I
submitted so I can finish my (Python powered of course!) clone army.

>I honestly do understand that everyone else works under the same restrictions
>of time that I do ... and I appreciate all the hard work the release managers
>continue to put in.

We know you love us Steve. :)

-Barry


signature.asc
Description: PGP signature
___
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] barry_as_FLUFL

[Jasper St. Pierre]

I was fooling around with Python 3.1 today, and I found this little nugget:

>>> import __future__
>>> dir(__future__)
['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_BARRY_AS_BDFL',
'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION',
'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT',
'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__',
'__builtins__', '__doc__', '__file__', '__name__', '__package__',
'absolute_import', 'all_feature_names', 'barry_as_FLUFL', 'division',
'generators', 'nested_scopes', 'print_function', 'unicode_literals',
'with_statement']

hmm... BARRY_AS_BDFL and barry_as_FLUFL

>>> from __future__ import barry_as_FLUFL
>>>

nothing noticable happened. I googled the latter, and found that it's an April
Fools (of 2009!) checkin that was never reverted.

http://mail.python.org/pipermail/python-checkins/2009-April/080796.html
___
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] barry_as_FLUFL

[Éric Araujo]

Hello


> hmm... BARRY_AS_BDFL and barry_as_FLUFL

Oh, bad consistency. Should have been BARRY_AS_FLUFL and barry_as_flufl.

 from __future__ import barry_as_FLUFL
> nothing noticable happened.

I made some tests about that and found that the behavior didn’t match
the PEP; I have to redo experiments and eventually report bugs.

> I googled the latter, and found that it's an April
> Fools (of 2009!) checkin that was never reverted.

Why should it be reverted? It causes no harm.


Regards


P.S. from __future__ import braces

___
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] barry_as_FLUFL

[Guido van Rossum]

On Wed, Aug 4, 2010 at 3:48 PM, Jasper St. Pierre  wrote:
> I was fooling around with Python 3.1 today, and I found this little nugget:
>
 import __future__
 dir(__future__)
> ['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_BARRY_AS_BDFL',
> 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION',
> 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT',
> 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__',
> '__builtins__', '__doc__', '__file__', '__name__', '__package__',
> 'absolute_import', 'all_feature_names', 'barry_as_FLUFL', 'division',
> 'generators', 'nested_scopes', 'print_function', 'unicode_literals',
> 'with_statement']
>
> hmm... BARRY_AS_BDFL and barry_as_FLUFL
>
 from __future__ import barry_as_FLUFL

>
> nothing noticable happened. I googled the latter, and found that it's an April
> Fools (of 2009!) checkin that was never reverted.

We don't revert our April Fool's checkins. Easter eggs are forever!

-- 
--Guido van Rossum (python.org/~guido)
___
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] barry_as_FLUFL

[Barry Warsaw]

On Aug 04, 2010, at 06:48 PM, Jasper St. Pierre wrote:

>hmm... BARRY_AS_BDFL and barry_as_FLUFL

[...]

>nothing noticable happened. I googled the latter, and found that it's
>an April Fools (of 2009!) checkin that was never reverted.

Wait.  It's a joke?!


signature.asc
Description: PGP signature
___
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] Drive suffix

[Stephen J. Turnbull]

Greg Ewing writes:

 > I'm not aware of any system that's "just like Windows"
 > except that it uses something other than colons.

It's a shame that Windows machines can be networked; otherwise we
could formally treat drive letters as the scheme component of file
URLs.

___
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 after the buildbots (in general)

[Stephen J. Turnbull]

Steve Holden writes:

 > But I see rules being established ("there's a language moratorium: no
 > changes!", "no release should be made unless the buildbots are *all*
 > green") and then ignored apparently on a whim. This doesn't give people
 > any confidence that the rules actually mean much, and I think ignoring
 > the latter rule can negatively affect quality.

I don't see this.  In the first case, you've misstated the rule: it's
"no changes to the Python language", and what is and is not part of
the language is subject to a certain amount of interpretation.  There
are several PEPs waiting on the moratorium despite everybody loving
them, and the decisions on borderline changes (which have gone both
ways, mostly denials) are establishing precedents that narrow the
scope for "interpretation".  I think it's very reasonable to assess
the moratorium as *very successful* with respect to it being a rule
that is obeyed in spirit and according to the letter.

In the second case, I don't recall it being stated as a project rule.
The buildbots were considered untrustworthy by many from the get-go,
and I do recall discussion of the "community buildbots" which
effectively resulted in community 'bots being fully deprecated.

Some RMs have nevertheless chosen to take them very seriously and want
them fixed if they're broken, others consider them a useful indicator
but are willing to proceed if there are strong indications that the
'bot is broken rather than CPython.  That's something that can be left
up to the release manager or not, as the project chooses, but my
impression to date has been that this is a matter of RM policy, not
project policy.

Note that following the latter rule can also negatively affect
quality, if scarce developer effort is devoted to fixing somebody
else's software rather than working on Python.

FWIW my assessment is that for the moment all of the RMs take the
buildbots pretty seriously, which is good (that seems to be consensus
opinion), with some variations in intensity, which is also (IMO YMMV)
good.  No need for change here yet (IMO YMMV), although community
members (anybody who cares) should prod RMs who seem to be neglecting
buildbot results.  In another cycle or so, the bots will probably be
ready for a project-wide rule.

I agree with J-P's suggestion that the place to start is asking
developers to bookmark the bot pages relevant to them, and visit it
(with appropriate lag) after committing.  For one thing, if people see
the 'bots deprecating their perfectly good changes, they'll have some
incentive to work on the bots and beat them into shape.  That can help
take some load off the people who have concentrated on the bots.  It
will also mean that a decision to condition releases on green bots
will be taken based on much broader experience rather than hearsay
about their reliability.
___
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] barry_as_FLUFL

[Ben Finney]

Barry Warsaw  writes:

> On Aug 04, 2010, at 06:48 PM, Jasper St. Pierre wrote:
> >hmm... BARRY_AS_BDFL and barry_as_FLUFL
> [...]
>
> >nothing noticable happened. I googled the latter, and found that it's
> >an April Fools (of 2009!) checkin that was never reverted.
>
> Wait.  It's a joke?!

That doesn't mean it's not true :-)

this-hacker-for-one-welcomes-our-great-FLUFL-'ly yrs,

-- 
 \“… Nature … is seen to do all things Herself and through |
  `\ herself of own accord, rid of all gods.” —Titus Lucretius |
_o__) Carus, c. 40 BCE |
Ben Finney


pgpzOglxu2OSD.pgp
Description: PGP signature
___
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] Drive suffix

[Ben Finney]

"Stephen J. Turnbull"  writes:

> It's a shame that Windows machines can be networked

+1 QOTW

Even if QOTW doesn't work in this forum, I still cast my vote.

-- 
 \ “We should strive to do things in [Gandhi's] spirit… not to use |
  `\   violence in fighting for our cause, but by non-participation in |
_o__)   what we believe is evil.” —Albert Einstein |
Ben Finney

___
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] #2651 - KeyError does not round trip strings

[Fred Drake]

2010/8/4 Łukasz Langa :
> Shall we do an e.index for IndexErrors as well?

I don't recall stumbling over that need, but the parallel makes it
tempting.  I expect is should be a separate patch, though.

Antoine's right about using keyword args from C, though.  I'd expect a
new helper function that handles this specific case, since it's likely
to be common.  Whether it used a keyword are or just performed a
setattr after the exception is created doesn't really matter.


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
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 after the buildbots (in general)

[Martin v. Löwis]

>> If you mean to imply that a release manager should care for the stability
>> of "their" branch also in between of releases -- I'd love to do that,
>> but I'd need a 36-hour day then.
>>
> I'll see if I can get God to extend it for you. I honestly do understand
> that everyone else works under the same restrictions of time that I do
> ... and I appreciate all the hard work the release managers continue to
> put in.

And indeed, from an RM point of view, fixing the bugs that cause
buildbot breakage isn't the right action for the RM.

Instead, if the release procedures say that the buildbots must pass the
test, and the tests don't actually pass, the natural consequence is not
to release. Barry has often exercised that approach in the past, and in
many cases, it actually helped in getting people motivated to fix bugs
when he threatened not to release.

Regards,
Martin
___
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 after the buildbots (in general)

[Georg Brandl]

Am 05.08.2010 01:26, schrieb Barry Warsaw:
> On Aug 04, 2010, at 06:39 PM, Steve Holden wrote:
> 
>>I'll see if I can get God to extend it for you.
> 
> No need to involve the supernatural Steve!  Just approve that PSF grant I
> submitted so I can finish my (Python powered of course!) clone army.

*Now* I know why the PSU abducted all these developers!  To assemble
a sufficient gene pool...

>>I honestly do understand that everyone else works under the same restrictions
>>of time that I do ... and I appreciate all the hard work the release managers
>>continue to put in.
> 
> We know you love us Steve. :)

In a PHBy way, it seems :)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Drive suffix

[Cesare Di Mauro]

2010/8/5 Greg Ewing 

> James Mills wrote:
>
>> Windows
>> is one of the only Operating Systems with a File system that reuiqres
>> this [A-Z]:\ syntax.
>>
>
> There's also VMS, but it uses a colon too. Also its
> pathnames are funky enough in other ways that it
> needs its own os-specific pathname routines.
>
> I'm not aware of any system that's "just like Windows"
> except that it uses something other than colons.
>
> --
> Greg


AmigaOS / AROS / MorphOS uses colon too as a volume (or device) separator:

dir "Ram Disk:System/Local Preferences"

Cesare
___
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] Drive suffix

[Ulrich Eckhardt]

On Wednesday 04 August 2010, Rob Cliffe wrote:
> As it happens, what sparked the question was trying to determine in a
> platform-independent way whether a path consisted of a bare drive
> specification (e.g. "C:").  I guess
> os.path.splitdrive(MyPath)[1] == ""
> takes care of that.

"platform-independent"? What is a "bare drive specification" on a FreeBSD 
system? Do you perhaps mean "mount point" instead? I don't think this 
discussion belongs Here(tm) though.

BTW: Embedded MS Windows CE uses a filesystem tree like *nix, i.e. without 
drive letters. Not that I have any kind of Python crawling on one of those 
yet, just wanted to mention...

Uli

-- 
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

___
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