-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
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 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
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 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!-)
> 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 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
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
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
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
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
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
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
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 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
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 \
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 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
"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 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
>> 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
>> 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
23 matches
Mail list logo