>> But it would be really nice if the configure fix for 2.5 was
>> backported to 2.4.5 since Zope is still on 2.4 and Mac OS X skipped
>> system builds for 2.4 going direct from 2.3 -> 2.5.
>
>
> Yes, it would be very nice if this worked out of the box on Mac OS X
> 10.5.2. It's definitely a
>> Assuming no major problems crop up, a final release of Python 2.4.4 will
>> follow in about a week's time.
>
> I do suppose you mean 2.4.5.
Oops, yes.
> 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2:
>
> gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
> -mno-fu
On Mar 2, 2008, at 8:35 PM, Kevin Teague wrote:
> This issue was fixed for Python 2.5. As the issue notes, you can
> work around it with:
>
> ./configure MACOSX_DEPLOYMENT_TARGET=10.5
Indeed, that works wonderfully for me for 2.4.5.
> But it would be really nice if the configure fix for 2.5 was
"It has to do with the MACOSX_DEPLOYMENT_TARGET. If it's set to 10.4,
the
legacy version of setpgrp is used (with args), it it's 10.5, setpgrp
expects no arguments. It seems configure won't detect the difference."
http://bugs.python.org/issue1358
This issue was fixed for Python 2.5. As the issu
On Sun, Mar 2, 2008 at 3:26 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-03-02 23:11, Greg Ewing wrote:
> > M.-A. Lemburg wrote:
> >> Why not also make unicode() the default type constructor and only
> >> keep str() as alias to simplify porting (perhaps with a warning) ?
> >
> > -1 o
On Sun, Mar 2, 2008 at 4:52 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Mar 2, 2008, at 7:43 PM, Fred Drake wrote:
> > 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2:
>
>
> Neither does 2.3.7 now that I've tried that:
>
> gcc -u __dummy -u _PyMac_Error -framework System -f
On Mar 2, 2008, at 7:43 PM, Fred Drake wrote:
> 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2:
Neither does 2.3.7 now that I've tried that:
gcc -u __dummy -u _PyMac_Error -framework System -framework
CoreServices -framework Foundation -o python.exe \
I tested and tried a few XML validators but none of them is able to successfully
validate a string of xml (not a file just a string) to programatically be able
to validate messages of xml that flow in and out of the different systems.
Teh validators I used were XSV, oNVDL and lxml, can we implement
On Mar 2, 2008, at 4:05 PM, Martin v. Löwis wrote:
> Assuming no major problems crop up, a final release of Python 2.4.4
> will
> follow in about a week's time.
I do suppose you mean 2.4.5.
2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2:
gcc -fno-strict-aliasing -Wno-long-do
As far as I can tell, the asyncore.py, asynchat.py, and updated
test_asyncore.py are good. I have been using earlier variants in my
own projects (prior to their updating to pass the test suite) for
quite a few months now. The updated modules provide better
performance, features, and support for r
I've discussed a lot with Josiah via e-mail and I provided an updated
version of the patch proposed in bug #1736190 including a fix for the
two issues raised by me in the bug report.
The update has been needed also because the original patch has been
out-dated by some commits after r53734 involving
On 2008-03-02 23:11, Greg Ewing wrote:
> M.-A. Lemburg wrote:
>> Why not also make unicode() the default type constructor and only
>> keep str() as alias to simplify porting (perhaps with a warning) ?
>
> -1 on making us type 7 characters instead of
> 3 all over the place.
Oh well... how about "t
On 2008-03-02 20:39, Bill Janssen wrote:
>> Why not also make unicode() the default type constructor and only
>> keep str() as alias to simplify porting (perhaps with a warning) ?
>>
>> The term "string" is just too overloaded with all kinds of
>> misinterpretations. The term "string" just refers t
M.-A. Lemburg wrote:
> Why not also make unicode() the default type constructor and only
> keep str() as alias to simplify porting (perhaps with a warning) ?
-1 on making us type 7 characters instead of
3 all over the place.
> The term "string" is just too overloaded with all kinds of
> misinterp
Stefan Behnel wrote:
> The release schedule in PEP 3000 says "August 2008" for 3.0 final, is that
> still the current goal? Can I expect the C-API to stabilise by June, then?
> That's where we are planning a Cython workshop with a couple of sprints. Py3k
> support might be worth targeting - if we c
On behalf of the Python development team and the Python community, I'm
happy to announce the release candidates of Python 2.4.5 and 2.4.5.
Both releases include only security fixes. Python 2.5 is the latest
version of Python, we're making this release for people who are still
running Python 2.3 or
On Sunday 02 March 2008, Alex Martelli wrote:
> On Sun, Mar 2, 2008 at 10:39 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > On 3/2/08, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > > Alex Martelli wrote:
> > > > Yep, but please do keep the PyUnicode for str and PyString for bytes
> > > > (as
> Why not also make unicode() the default type constructor and only
> keep str() as alias to simplify porting (perhaps with a warning) ?
>
> The term "string" is just too overloaded with all kinds of
> misinterpretations. The term "string" just refers to a string of
> bytes - a variable length arr
On Sun, Mar 2, 2008 at 10:39 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
> On 3/2/08, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Alex Martelli wrote:
> > > Yep, but please do keep the PyUnicode for str and PyString for bytes
> > > (as macros/synonnyms of PyStr and PyBytes if you want!-)
On 3/2/08, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> Alex Martelli wrote:
> > Yep, but please do keep the PyUnicode for str and PyString for bytes
> > (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the
> > task of porting existing extensions... the bytearray functions should
On 2008-03-02 14:47, Christian Heimes wrote:
> Alex Martelli wrote:
>> Yep, but please do keep the PyUnicode for str and PyString for bytes
>> (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the
>> task of porting existing extensions... the bytearray functions should
>> no doubt be
Alex Martelli wrote:
> Yep, but please do keep the PyUnicode for str and PyString for bytes
> (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the
> task of porting existing extensions... the bytearray functions should
> no doubt be PyBytearray, though.
Yeah, we've already planed t
-On [20080301 19:57], Christian Heimes ([EMAIL PROTECTED]) wrote:
>I also propose translations of the shorter text to important languages
>like French, German, Japanese, Portuguese and Spanish. I'm willing to
>help with the German translation.
I can probably get a translation done in Japanese, Chi
23 matches
Mail list logo
