Re: [Python-Dev] [Python-checkins] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py

[Martin v. Löwis]

>> It's rather a matter of agreeing when moving forward: IMO, mere style
>> changes, code cleanup etc shouldn't be applied to the bug fix branches,
>> as their only purpose is to provide bug fixes for existing users.
> 
> The omission of the deletion from the 5/5 revision was a bug in that
> revision. If the removal of OS9 support was documented (announced),
> which I presume it was, then one could consider any visible trace
> remaining to be a bug.

Well, the question is: can anything break due to the code removal.
In principle, stuff *could* break even by a function that is supposedly
unused, and had supposedly been removed. The problem is that a
supposedly-unused function actually might be used somewhere, in some
context unrelated to its intended usage.

> Perhaps the policy on code cleanup should be a bit more liberal for 2.7
> *because* it will be maintained for several years and *because* there is
> no newer 2.x branch to apply changes to.

You mean, it's ok to break stuff with no gain in 2.7 bug fix releases?

> If I were going to maintain 2.7
> for several years, I would want to have the benefit of gradual
> improvements that make maintainance easier.

I question whether cleanup on a maintenance branch makes maintenance
easier. For example, one may (and I often do) compare the code base
of the previous bug fix release with the upcoming one, to see whether
any suspicious change accidentally was backported. Code cleanup is
in the way of such analysis, making maintenance more difficult.

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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Trent Nelson]

On 07-Nov-10 1:55 AM, Nick Coghlan wrote:

On Sun, Nov 7, 2010 at 3:53 AM, Giampaolo Rodolà  wrote:

In such cases I would find more easy to be able to connect to the
machine and test myself rather than create a separate branch, commit,
schedule a buildbot run, wait for it to complete and see whether
everything is "green".

On the other side I perfectly understand how opening up blanket ssh
access is not something everyone is comfortable with doing.
AFAICR there was someone who was setting up an evironment to solve
exactly this problem but I'm not sure whether this is already usable.


Dealing with exactly this problem is one of the goals of the Snakebite project.

As far as I know, the folks behind that project are still working on
it - I've cc'ed Trent Nelson to see if he can provide any additional
info on the topic.


Thanks for the ping Nick, I might have missed this otherwise.  Good 
timing, too, as Titus and I were just discussing which low hanging 
fruit/pain points Snakebite should tackle first (now that all the server 
room stuff has finally been taken care of).


Luckily, the problems that we faced 2.5 years ago when I came up with 
the idea of Snakebite are still just as ever present today ;-)


1.  Not having access to buildbots is a pain when something doesn't work 
right.  Doing dummy debug commits against trunk to try and coerce some 
more information out of a failing platform is painful.  Losing a build 
slave entirely due to a particularly hard crash and requiring the 
assistance of the owner is also super frustrating.


2.  The buildbot web interface for building non-(trunk|2.x|py3k) 
branches is also crazy unfriendly.  Per-activity branches are a great 
way to isolate development, even with Subversion, but it kinda' blows 
that you don't *really* get any feedback about how your code behaves on 
other platforms until you re-integrate your changes back into a mainline 
branch.  (I'm sure none of us have been masochistic enough to manually 
kick off individual builds for every platform via the buildbot web page 
after every commit to a non-standard branch.)


So, enter Snakebite.  We've got three racks filled with way more 
hardware than I should have ever purchased.  Ignoring the overhead of 
having to set machines up and whatnot, let's just assume that over the 
next couple of months, if there's a platform we need a stable buildbot 
for, Snakebite can provide it.  (And if we feel like bringing IRIX/MIPS 
and Tru64/Alphas back as primary platforms, we've got the hardware to do 
that, too ;-).)


Now, the fact that they're all in the one place and under my complete 
control is a big advantage, as I can start addressing some of the pain 
points that lead me down this twisted path 2.5 years ago.


I'd like to get some feedback from the development community on what 
they'd prefer.  In my mind, I could take one of the following two steps:


1.  Set up standard build slaves on all the platforms, but put something 
in place that allowed committers to ssh/mstsc in to said slaves when 
things go wrong in order to aid with debugging and/or maintaining 
general buildbot health (OK'ing modal crash dialogues on Windows, for 
example).


2.  Address the second problem of the buildbot web interface sucking for 
non-standard branches.  I'm thinking along the lines of a hack to 
buildbot, such that upon creation of new per-activity branches off a 
mainline, something magically runs in the background and sets up a 
complete buildbot view at 
python.snakebite.org/dev/buildbot/, just as if you 
were looking at a trunk buildbot page.


I'm not sure how easy the second point will be when we switch to hg; and 
I'll admit if there have been any python-dev discussions about buildbot 
once we're on hg, I've missed them.


Of course there's a third option, which is using the infrastructure I've 
mentioned to address a similarly annoying pain point I haven't thought 
of -- so feel free to mention anything else you'd like to see first 
instead of the above two things.


Titus, for example, alluded to some nifty way for a committer to push 
his local hg branch/changes somewhere, such that it would kick off 
builds on multiple platforms in the same sorta' vein as point 2, but 
able to leverage cloud resources like Amazon's EC2, not just Snakebite 
hardware.


Look forward to hearing some feedback!

Regards,

Trent.



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

Re: [Python-Dev] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Nick Coghlan]

On Sun, Nov 7, 2010 at 9:24 PM, Trent Nelson  wrote:
> 1.  Set up standard build slaves on all the platforms, but put something in
> place that allowed committers to ssh/mstsc in to said slaves when things go
> wrong in order to aid with debugging and/or maintaining general buildbot
> health (OK'ing modal crash dialogues on Windows, for example).

This sounds like a great place to start. Perhaps focus on one or two
of the less common platforms first (e.g. FreeBSD 7 has been hitting a
few semaphore issues lately). The big 3 (Windows/Mac/Linux) are
usually reasonably well covered for debugging purposes by people that
use them for development.

> 2.  Address the second problem of the buildbot web interface sucking for
> non-standard branches.  I'm thinking along the lines of a hack to buildbot,
> such that upon creation of new per-activity branches off a mainline,
> something magically runs in the background and sets up a complete buildbot
> view at python.snakebite.org/dev/buildbot/, just as if you
> were looking at a trunk buildbot page.
>
> I'm not sure how easy the second point will be when we switch to hg; and
> I'll admit if there have been any python-dev discussions about buildbot once
> we're on hg, I've missed them.

With the switch to hg.python.org imminent, it may be better to focus
on Hg for that part (unless you have other projects in mind that also
use SVN). I believe Martin and/or Dirkjan have worked out the
equivalent triggers and build commands needed to switch the buildbot
fleet from svn to hg, but I'm not entirely certain about that one.

Good to know things are still progressing though - traffic on the
website news feed and the mailing list has been a little sparse this
year ;)

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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Dirkjan Ochtman]

On Sun, Nov 7, 2010 at 12:24, Trent Nelson  wrote:
> Titus, for example, alluded to some nifty way for a committer to push his
> local hg branch/changes somewhere, such that it would kick off builds on
> multiple platforms in the same sorta' vein as point 2, but able to leverage
> cloud resources like Amazon's EC2, not just Snakebite hardware.

Mozilla has something called the "try server", where people push
changes like to any normal repositories, but the result is that it
runs all the test suites they have. This lets people painlessly test
stuff on all platforms before actually pushing it to one of the main
repositories.

On Sun, Nov 7, 2010 at 12:50, Nick Coghlan  wrote:
> With the switch to hg.python.org imminent, it may be better to focus
> on Hg for that part (unless you have other projects in mind that also
> use SVN). I believe Martin and/or Dirkjan have worked out the
> equivalent triggers and build commands needed to switch the buildbot
> fleet from svn to hg, but I'm not entirely certain about that one.

Yeah, Martin has things for buildbot worked out. Notes about this are
in the hg.python.org/pymigr repository.

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] [Python-checkins] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py

[Antoine Pitrou]

On Sun, 07 Nov 2010 09:01:22 +0100
"Martin v. Löwis"  wrote:
> 
> > If I were going to maintain 2.7
> > for several years, I would want to have the benefit of gradual
> > improvements that make maintainance easier.
> 
> I question whether cleanup on a maintenance branch makes maintenance
> easier.

It certainly does when using svnmerge. You can have many merge
conflicts if cleanups on the dev branch aren't backported to the bugfix
branches.

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

[Python-Dev] rlcompleter -- auto-complete dictionary keys (+ tests)

[Valery Khamenya]

Hi,

A) I missed the auto-complete feature for dictionary keys a lot in python
console. This patch seems to do the job.

B) There is no rlcompleter tests in trunk for some reason. So, I've taken
the 2.7.x test_rlcompleter.py and extended it.

C) patched rlcompleter as such works OK for unicode dictionary keys as well.
All tests pass OK. HOWEVER, readline's completion mechanism seem to be
confused with unicode strings -- see comments to
Completer.dict_key_matches(). So, perhaps, some changes should be applied to
readline code too.

Attached:

1. rlcompleter.py (as for trunk)

2. test_rlcompleter (as for trunk)

3. rlcompleter_trunk_to_new.diff (created as: diff rlcompleter_trunk.py
rlcompleter.py >rlcompleter_trunk_to_new.diff)

P.S. thanks to kerio & ssbr on icq for advices.

best regards
--
Valery A.Khamenya
# -*- coding: utf-8 -*-

"""Word completion for GNU readline 2.0.

This requires the latest extension to the readline module. The completer
completes keywords, built-ins and globals in a selectable namespace (which
defaults to __main__); when completing NAME.NAME..., it evaluates (!) the
expression up to the last dot and completes its attributes.

It's very cool to do "import sys" type "sys.", hit the
completion key (twice), and see the list of names defined by the
sys module!

Tip: to use the tab key as the completion key, call

readline.parse_and_bind("tab: complete")

Notes:

- Exceptions raised by the completer function are *ignored* (and
generally cause the completion to fail).  This is a feature -- since
readline sets the tty device in raw (or cbreak) mode, printing a
traceback wouldn't work well without some complicated hoopla to save,
reset and restore the tty state.

- The evaluation of the NAME.NAME... form may cause arbitrary
application defined code to be executed if an object with a
__getattr__ hook is found.  Since it is the responsibility of the
application (or the user) to enable this feature, I consider this an
acceptable risk.  More complicated expressions (e.g. function calls or
indexing operations) are *not* evaluated.

- GNU readline is also used by the built-in functions input() and
raw_input(), and thus these also benefit/suffer from the completer
features.  Clearly an interactive application can benefit by
specifying its own completer function and using raw_input() for all
its input.

- When the original stdin is not a tty device, GNU readline is never
used, and this module (and the readline module) are silently inactive.

"""

import __builtin__
import __main__

__all__ = ["Completer"]

class Completer:
def __init__(self, namespace=None):
"""Create a new completer for the command line.

Completer([namespace]) -> completer instance.

If unspecified, the default namespace where completions are performed
is __main__ (technically, __main__.__dict__). Namespaces should be
given as dictionaries.

Completer instances should be used as the completion mechanism of
readline via the set_completer() call:

readline.set_completer(Completer(my_namespace).complete)
"""

if namespace and not isinstance(namespace, dict):
raise TypeError, 'namespace must be a dictionary'

# Don't bind to namespace quite yet, but flag whether the user wants a
# specific namespace or to use __main__.__dict__. This will allow us
# to bind to __main__.__dict__ at completion time, not now.
if namespace is None:
self.use_main_ns = 1
else:
self.use_main_ns = 0
self.namespace = namespace

def complete(self, text, state):
"""Return the next possible completion for 'text'.

This is called successively with state == 0, 1, 2, ... until it
returns None.  The completion should begin with 'text'.
   
"""
if self.use_main_ns:
self.namespace = __main__.__dict__

if state == 0:
if "." in text:
self.matches = self.attr_matches(text)
elif "[" in text:
self.matches = self.dict_key_matches(text)
else:
self.matches = self.global_matches(text)
try:
return self.matches[state]
except IndexError:
return None

def _callable_postfix(self, val, word):
if hasattr(val, '__call__'):
word = word + "("
return word

def global_matches(self, text):
"""Compute matches when text is a simple name.

Return a list of all keywords, built-in functions and names currently
defined in self.namespace that match.

"""
import keyword
matches = []
n = len(text)
for word in keyword.kwlist:
if word[:n] == text:
matches.append(word)
for nspace in [__builtin__.__dict__, self.namespace]:
for word, val in nspace.items():
if word[:n] == text and 

Re: [Python-Dev] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Georg Brandl]

Am 07.11.2010 12:50, schrieb Nick Coghlan:
> On Sun, Nov 7, 2010 at 9:24 PM, Trent Nelson  wrote:
>> 1.  Set up standard build slaves on all the platforms, but put something in
>> place that allowed committers to ssh/mstsc in to said slaves when things go
>> wrong in order to aid with debugging and/or maintaining general buildbot
>> health (OK'ing modal crash dialogues on Windows, for example).
> 
> This sounds like a great place to start. Perhaps focus on one or two
> of the less common platforms first (e.g. FreeBSD 7 has been hitting a
> few semaphore issues lately). The big 3 (Windows/Mac/Linux) are
> usually reasonably well covered for debugging purposes by people that
> use them for development.
> 
>> 2.  Address the second problem of the buildbot web interface sucking for
>> non-standard branches.  I'm thinking along the lines of a hack to buildbot,
>> such that upon creation of new per-activity branches off a mainline,
>> something magically runs in the background and sets up a complete buildbot
>> view at python.snakebite.org/dev/buildbot/, just as if you
>> were looking at a trunk buildbot page.
>>
>> I'm not sure how easy the second point will be when we switch to hg; and
>> I'll admit if there have been any python-dev discussions about buildbot once
>> we're on hg, I've missed them.
> 
> With the switch to hg.python.org imminent, it may be better to focus
> on Hg for that part (unless you have other projects in mind that also
> use SVN). I believe Martin and/or Dirkjan have worked out the
> equivalent triggers and build commands needed to switch the buildbot
> fleet from svn to hg, but I'm not entirely certain about that one.

I've spent a good bit of time on that, and left all the instructions in
the buildbot master config.  I also adapted buildbot's hg hook to our
situation (e.g. to send a change to multiple masters, as required for
the community buildbots), so it should be quite easy to actually
switch the buildbots over on migration day.

Georg

___
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-3 transition in Arch Linux

[James Y Knight]

On Nov 6, 2010, at 9:41 AM, Martin v. Löwis wrote:
> So I don't recall a decision that there shouldn't be a python2
> binary,

The decision to make one would have to be an active decision, since Python has 
never installed one before. If there should be one, then the Python Makefile 
should make one by default.

> nor a decision that anything is done indefinitely
> (it may be that the decision was actually just about 3.1 - changing
> it again for 3.2 would require another decision, but certainly can't
> be ruled out categorically).

When I said "indefinite", I meant "until some point in the future not yet 
determined", with an implied undertone of "not anytime soon".

James

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

Re: [Python-Dev] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[exarkun]

On 11:24 am, tr...@snakebite.org wrote:


2.  Address the second problem of the buildbot web interface sucking 
for non-standard branches.  I'm thinking along the lines of a hack to 
buildbot, such that upon creation of new per-activity branches off a 
mainline, something magically runs in the background and sets up a 
complete buildbot view at python.snakebite.org/dev/buildbot/branch-name>, just as if you were looking at a trunk buildbot page.


This is basically trivial.  I gave #python-dev a tool for forcing 
builds, dunno if anyone still has a copy, but it's easy to reconstruct 
from  (which is what the Twisted project uses).  Plus, you can add 
?branch= to most BuildBot views to limit display of results to 
just builds for the named branch.
Titus, for example, alluded to some nifty way for a committer to push 
his local hg branch/changes somewhere, such that it would kick off 
builds on multiple platforms in the same sorta' vein as point 2, but 
able to leverage cloud resources like Amazon's EC2, not just Snakebite 
hardware.


BuildBot supports managing EC2 instance lifetimes to run builds.

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] rlcompleter -- auto-complete dictionary keys (+ tests)

[Brian Curtin]

On Sun, Nov 7, 2010 at 04:19, Valery Khamenya  wrote:

> Hi,
>
> A) I missed the auto-complete feature for dictionary keys a lot in python
> console. This patch seems to do the job.
>
> B) There is no rlcompleter tests in trunk for some reason. So, I've taken
> the 2.7.x test_rlcompleter.py and extended it.
>
> C) patched rlcompleter as such works OK for unicode dictionary keys as
> well. All tests pass OK. HOWEVER, readline's completion mechanism seem to be
> confused with unicode strings -- see comments to
> Completer.dict_key_matches(). So, perhaps, some changes should be applied to
> readline code too.
>
> Attached:
>
> 1. rlcompleter.py (as for trunk)
>
> 2. test_rlcompleter (as for trunk)
>
> 3. rlcompleter_trunk_to_new.diff (created as: diff rlcompleter_trunk.py
> rlcompleter.py >rlcompleter_trunk_to_new.diff)
>
> P.S. thanks to kerio & ssbr on icq for advices.
>
> best regards
> --
> Valery A.Khamenya
>
> ___
> 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/brian.curtin%40gmail.com
>
>
Can you post your patch on bugs.python.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] rlcompleter -- auto-complete dictionary keys (+ tests)

[Valery Khamenya]

>
> Can you post your patch on bugs.python.org?
>

 the site is not working currently.

Also, I have forgotten to mention, that the usual lines in .pythonstartup
should look now like that:

# the usual lines:
import readline
import rlcompleter
readline.parse_and_bind('tab: complete')
readline.parse_and_bind('Control-Space: complete')

# and now the additional line to allow the '[' char and both quote
characters:
readline.set_completer_delims(re.compile(r'[\'"\\[]').sub('',
readline.get_completer_delims()))
___
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] bugs.python.org not responding (Was: rlcompleter -- auto-complete dictionary keys (+ tests))

[Bobby Impollonia]

On Sun, Nov 7, 2010 at 9:07 AM, Valery Khamenya  wrote:
>> Can you post your patch on bugs.python.org?
>
>  the site is not working currently.

Yes, it is down for me too, trying from multiple hosts. It was up
approximately an hour ago, but has now been unresponsive for the past
twenty or thirty minutes. I cannot even ping bugs.python.org. The main
python.org site seems to be fine.
___
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] bugs.python.org not responding (Was: rlcompleter -- auto-complete dictionary keys (+ tests))

[R. David Murray]

On Sun, 07 Nov 2010 09:30:17 -0800, Bobby Impollonia  wrote:
> On Sun, Nov 7, 2010 at 9:07 AM, Valery Khamenya  wrote:
> >> Can you post your patch on bugs.python.org?
> >
> > the site is not working currently.
> 
> Yes, it is down for me too, trying from multiple hosts. It was up
> approximately an hour ago, but has now been unresponsive for the past
> twenty or thirty minutes. I cannot even ping bugs.python.org. The main
> python.org site seems to be fine.

The hosting company working on the problem, which seems to be a hardware
issue.  Hopefully be resolved soon.

FYI bugs.python.org and www.python.org are different machines, and
in fact the two machines are not even hosted at the same location.

Valery,  I would advise you to submit the patch to bugs.python.org when
it comes back up.  Patches posted to this mailing list will in general
just get forgotten.

--
R. David Murray  www.bitdance.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

[Python-Dev] Bug track down?

[MRAB]

It looks like the bug tracker is down.
___
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-3 transition in Arch Linux

[Martin v. Löwis]

Am 07.11.2010 15:57, schrieb James Y Knight:
> On Nov 6, 2010, at 9:41 AM, Martin v. Löwis wrote:
>> So I don't recall a decision that there shouldn't be a python2 
>> binary,
> 
> The decision to make one would have to be an active decision, since
> Python has never installed one before. If there should be one, then
> the Python Makefile should make one by default.

No. Creation of additional symlinks is certainly in the realm of what
Python packagers can decide on their own.

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] Bug track down?

[Martin v. Löwis]

Am 07.11.2010 22:05, schrieb MRAB:
> It looks like the bug tracker is down.

Thanks - we have already contacted the hosting company, who have already
contacted the datacenter. It appears that the bug tracker actually
wasn't down (at least, it believes it was up all time), which suggests
that there was some kind of networking problem. It came back, then went
away again.

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] r86276 - python/branches/py3k/Lib/distutils/cygwinccompiler.py

[Antoine Pitrou]

On Sat,  6 Nov 2010 19:03:53 +0100 (CET)
eric.araujo  wrote:
> Author: eric.araujo
> Date: Sat Nov  6 19:03:52 2010
> New Revision: 86276
> 
> Log:
> Fix #10252 again (hopefully definitely).  Patch by Brian Curtin.

It seems this and previous fixes should be backported to 2.7.

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] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot

[David Bolen]

Victor Stinner  writes:

> You wrote that the "POSIX" semaphore are very limited. Do it mean that there 
> is another kind of semaphore will an higher limit?

Well, I think the SYSV semaphores are either less limited or at least
more adjustable.  They've certainly been around longer in FreeBSD.
The POSIX semaphore support is not enabled by default in FreeBSD 7, so
I added loader.conf stuff to load them (as part of issue7272).  I
don't think the Python internals are using the SYSV semaphores though.
SYSV functions have no underscore (e.g., semget) whereas POSIX do
(sem_get).  Also, I believe only POSIX has named semaphores.

> I don't think that skipping the test is a good idea: it looks like a real bug 
> in (a limitation of) the ProcessPoolExecutor implementation on FreeBSD. Eg. 
> test_map fails on FreeBSD 7.2 with ProcessPoolExecutorTest which uses 
> self.executor = futures.ProcessPoolExecutor(max_workers=1): only one worker 
> process!
>
> It looks like it is possible to tune semaphore limits on FreeBSD, without 
> recompiling the kernel, by using boot loader option (kern.ipc.sem* options). 
> But ask the FreeBSD user to tune its boot loader options to use the 
> concurrent.futures module is not pratical :-)

Yeah, I guess the key question is if changing the limit is just needed
to get around an artifact of the test process (which I'm willing to do
for the buildbot), or if it would be needed to be able to use the
regular modules in practice.  If the latter, I doubt too many users
are going to jump through such hoops, particularly if it needs a
kernel rebuild, so we may need to make other choices in terms of
support under FreeBSD.

I'm also not entirely sure just what is the limiting factor.  I think
the kern.ipc.sem* options are for the SYSV semaphores, not POSIX, though
some of them do have a similar limit.  Some are adjustable by sysctl,
others by loader.conf.

The references I found were talking about a limit set explicitly
(#define SEM_MAX) in the kernel source (uipc_sem.c) which exports its
value (at least in 7.2) via the sysctl p1003_1b.sem_nsems_max, which
is read-only.  I got the impression they weren't adjustable even in
loader.conf, but haven't actually tried it yet myself.

It may be different in 8.x, but one email thread I found indicated
that the changes proposed to make the POSIX limits adjustable didn't
make the 8.1 cut (current release), though might make it in the next
8.x release.

-- David

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

Re: [Python-Dev] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Martin v. Löwis]

> Luckily, the problems that we faced 2.5 years ago when I came up with
> the idea of Snakebite are still just as ever present today ;-)

Is this bashing of existing infrastructure really necessary?
People (like me) might start bashing about vaporware and how
a bird in the hand is worth two in the bush. Cooperate, don't
confront.

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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Martin v. Löwis]

> I've spent a good bit of time on that, and left all the instructions in
> the buildbot master config.  I also adapted buildbot's hg hook to our
> situation (e.g. to send a change to multiple masters, as required for
> the community buildbots), so it should be quite easy to actually
> switch the buildbots over on migration day.

I'm not sure this is the right way of doing it. AFAICT, hg can have
multiple handlers for the same hook, e.g. incoming.buildbot and
incoming.community.

Furthermore, I believe the community buildbot farm is currently dead,
and unlikely to come back.

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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Antoine Pitrou]

On Sun, 7 Nov 2010 06:24:59 -0500
Trent Nelson  wrote:
> (And if we feel like bringing IRIX/MIPS 
> and Tru64/Alphas back as primary platforms, we've got the hardware to do 
> that, too ;-).)

Unless you want to rename your project zombiebite, it would probably be
better not to resurrect those old corpses.
(I'm talking about the OSes, not the chips)

> Of course there's a third option, which is using the infrastructure I've 
> mentioned to address a similarly annoying pain point I haven't thought 
> of -- so feel free to mention anything else you'd like to see first 
> instead of the above two things.

I'm sure there are various special builds that could be useful. One is
a build with heavy resource consumption (lots of RAM, lots of disk) if
there's a machine which can handle that.

Another is testing memory leaks on all 3 branches (I have a daily
script which does that for 3.x on my personal server).

Perhaps there could even be some automated fuzzing if Victor is looking
for something to do on his free time :)

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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Scott Dial]

On 11/7/2010 7:09 PM, Martin v. Löwis wrote:
>> Luckily, the problems that we faced 2.5 years ago when I came up with
>> the idea of Snakebite are still just as ever present today ;-)
> 
> Is this bashing of existing infrastructure really necessary?
> People (like me) might start bashing about vaporware and how
> a bird in the hand is worth two in the bush. Cooperate, don't
> confront.

+1 Respect your (software) elders.

The Snaketbite rhetoric has always been less than generous with regard
to Buildbot, but Buildbot has been providing an infinitely more useful
service to the community for much longer than Snakebite has for those
2.5 years.

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot

[Victor Stinner]

On Monday 08 November 2010 00:34:36 David Bolen wrote:
> Victor Stinner  writes:
> > You wrote that the "POSIX" semaphore are very limited. Do it mean that
> > there is another kind of semaphore will an higher limit?
> 
> Well, I think the SYSV semaphores are either less limited or at least
> more adjustable.  They've certainly been around longer in FreeBSD.
> The POSIX semaphore support is not enabled by default in FreeBSD 7, so
> I added loader.conf stuff to load them (as part of issue7272).  I
> don't think the Python internals are using the SYSV semaphores though.
> SYSV functions have no underscore (e.g., semget) whereas POSIX do
> (sem_get).  Also, I believe only POSIX has named semaphores.

I created the issue http://bugs.python.org/issue10348 to suggest this.

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

Re: [Python-Dev] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[C. Titus Brown]

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

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

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

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

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

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

--titus
-- 
C. Titus Brown, c...@msu.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] KeyboardInterrupt not catch

[Qi Yong]

Hello,

With this script, after ctrl-d, ctrl-c exception not catch.
Is it a python bug or a wrong exception usage? Thanks.
If with import readline, this problem disappears.

-- qiyong


def parse():
try:
answer = raw_input("Eo: ")
print answer
except EOFError:
print("EOF")
except KeyboardInterrupt:
print("")

def main():
while True:
parse()

if __name__ == "__main__":
main()


-- 
Qi Yong
___
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] r86276 - python/branches/py3k/Lib/distutils/cygwinccompiler.py

[Terry Reedy]

On 11/7/2010 5:11 PM, Antoine Pitrou wrote:

On Sat,  6 Nov 2010 19:03:53 +0100 (CET)
eric.araujo  wrote:

Author: eric.araujo
Date: Sat Nov  6 19:03:52 2010
New Revision: 86276

Log:
Fix #10252 again (hopefully definitely).  Patch by Brian Curtin.


It seems this and previous fixes should be backported to 2.7.


Perhaps there should be a 'backport 2.7' keyword to check on issues that 
might be but have not been.


--
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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Scott Dial]

On 11/7/2010 9:58 PM, C. Titus Brown wrote:
> Yes, yes, I agree that some graciousness is a good idea.
> 
> Oh, wait... you're not helping.

Classy.

I don't remember being invited to help. snakebite.org is a dead end.
snakebite-list hasn't had a post for over a year. Where is the list of
things that you need done so that I can get started on that? Oh wait..

Seriously, all I asked was for you to tone down your insults to a
technology that is already solving problems today. Why you feel the need
to attack me personally is beyond my understanding. Furthermore, I don't
see why I need to be "helping" -- somebody who doesn't want help -- to
be able to deduce that your message is being insulting to the authors of
Buildbot.

On 11/7/2010 9:58 PM, C. Titus Brown wrote:
> And I'm not in a personal position to help, so I've basically tried
> to shut up about it :).

At least I am in good company. ;)

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] KeyboardInterrupt not catch

[Ben Finney]

Qi Yong  writes:

> With this script, after ctrl-d, ctrl-c exception not catch.

When I run it, the Ctrl-D doesn't affect the behaviour of Ctrl-C. Can
you confirm that the behaviour is dependent on whether Ctrl-D is used?

> If with import readline, this problem disappears.

Again, if I ‘import readline’ or not, the behaviour is unchanged. Can
you show a specific series of steps that changes the behaviour?

> Is it a python bug or a wrong exception usage? Thanks.

The ‘raw_input’ function uses the ‘readline’ library. That library uses
signal handlers for many of the terminal signals, as documented at
http://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC43>.

-- 
 \   “You've got the brain of a four-year-old boy, and I'll bet he |
  `\ was glad to get rid of it.” —Groucho Marx |
_o__)  |
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] KeyboardInterrupt not catch

[Ralf Schmitt]

Qi Yong  writes:

> Hello,
>
> With this script, after ctrl-d, ctrl-c exception not catch.
> Is it a python bug or a wrong exception usage? Thanks.
> If with import readline, this problem disappears.

there's already a bug in the issue tracker: http://bugs.python.org/issue1195

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

Re: [Python-Dev] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)

[Georg Brandl]

Am 08.11.2010 01:13, schrieb "Martin v. Löwis":
>> I've spent a good bit of time on that, and left all the instructions in
>> the buildbot master config.  I also adapted buildbot's hg hook to our
>> situation (e.g. to send a change to multiple masters, as required for
>> the community buildbots), so it should be quite easy to actually
>> switch the buildbots over on migration day.
> 
> I'm not sure this is the right way of doing it. AFAICT, hg can have
> multiple handlers for the same hook, e.g. incoming.buildbot and
> incoming.community.

That is true, however it doesn't help you: the hook takes its configuration
from the hgrc file, so you can configure exactly one host:port to send
changes to.

> Furthermore, I believe the community buildbot farm is currently dead,
> and unlikely to come back.

Then it's easy not to use that feature :)

Georg

___
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