On Wed, Dec 1, 2010 at 3:17 AM, Severin Lemaignan
<severin.lemaignan@laas.fr> wrote:
> On 11/30/2010 06:53 PM, Ken Conley wrote:
>> The syntax is Python 2.5 (e.g. "from __future__ import
>> with_statement"). Diamondback will be Python 2.5, we have not yet
>> determined what E-Turtle will be, though I have confidence that it
>> will be 2.6.
>
> I've brought back the "from __future__ import with_statement". If
> someone want to test with Python 2.5...
>
> Just out of curiosity, why do you want to stick to Python 2.5 for
> Diamondback? Python 2.6 is standard on Linux distrib since a while
> (at least Ubuntu 9.10), and 100% compatible with Python 2.5...

Also see my note in other thread regarding "Exception as e". This is
probably the bigger issue.

When we originally started ROS, we started with Python 2.5 and quickly
discovered resistance in our user base, some of whom were stuck on
ancient university lab setups that only supported Python 2.4. Thus,
our Python versioning has generally been driven by concerns of
non-Ubuntu platforms.

Similarly, much of the code is ROS is used to maintain previous
distributions. If we were to allows Python 2.6 code in Diamondback, it
could accidentally leak into C Turtle code.  While we expect most C
Turtle users are rebasing on Lucid and similar, new distributions, our
general commitment with ROS is to push the bleeding edge of research,
but maintain a very stable base below.  Transitioning to Python 2.6
post Diamondback will be much safer.

>> It will also be best to deal with the patch tool-by-tool.  That way me
>> and Tully can deal with the patches separately.  Also, given that ROS
>> is now split into ros and ros_comm, I think first we can target the
>> 'ros' stack, and then target the ros_comm stack afterwards.
>
> Yes, the first batch of patches only target the 'ros' stack. I've
> splitted the original patch in one patch per tool in the trac ticket.
>
>> Can you go ahead and create a ticket with your patch -- given that the
>> time period for merging this will likely be a least several weeks
>> away, it will make sure that this gets targeted properly.  Also, if
>> the patch is split tool-wise, it is much more likely that we will be
>> able to tackle it sooner.
>
> Here we are:
> https://code.ros.org/trac/ros/ticket/3166

Thanks! I suspect we might not pull this up until the January
timeframe, when it will be easier to branch the ROS stack. Feel free
to 'bump' the ticket as a reminder around then to get our attention.

regards,
Ken