[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Do we still need Python 2.3 support from Pygame?



hi,

the main reason for keeping 2.3 support was to support the last ye
olde Debian stable I think... However they finally got their new
release out with 2.5 as the standard python (unfortunately they
released with a version of pygame from 2005).  Plus the 2.3 python on
tiger OSX, and not requiring msvc71 on windows too... like everyone
has already mentioned.

So hopefully we don't have to worry too much about 2.3 support.
However unless there's a good reason, I don't think there's no need to
rip out any 2.3 support code.

cu,



On Thu, Dec 11, 2008 at 1:49 PM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
> I don't know about msvcr71.dll licensing. msvcr90.dll may be an even
> stickier issue. A  Python 2..6 version of py2exe was recently released
> though.
>
> I am not currently working on any Pygame extensions, just support stuff. So
> I won't worry about maintaining Python 2.3 compatibility.
>
> Lenard
>
>
> Brian Fisher wrote:
>>
>> The only interesting thing about python 2.3 on windows is that it uses the
>> older MSVCRT60.dll and friends, which have shipped with all the windows
>> OS's, meaning that you don't need to redistribute the runtime dlls if you
>> build an exe with python 2.3.
>>
>> That being said, I'm the type to really care about stuff like that, and
>> I'm perfectly happy with 2.5, cause it's only like 1 more MB to distribute,
>> and I'm convinced there is no legal issue there.
>>
>>
>> On Wed, Dec 10, 2008 at 12:52 PM, Lenard Lindstrom <len-l@xxxxxxxxx
>> <mailto:len-l@xxxxxxxxx>> wrote:
>>
>>    Hi,
>>
>>    Do we still need to keep Pygame Python 2.3 compatible. I believe
>>    Python 2.3 shipped with Mac OS X Tiger. Is it still the OS X
>>    default? How about other operating systems? The testing framework
>>    is Python 2.4, using the subprocess module. But what about the
>>    core Pygame code? I am getting tired of testing for the set
>>    builtin type or avoiding generator expressions. And what about
>>    those function decorators?
>>
>>    --    Lenard Lindstrom
>>    <len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>>
>>
>>
>
>
> --
> Lenard Lindstrom
> <len-l@xxxxxxxxx>
>
>