-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,
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 to
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
no
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!-) to help the
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 array so to
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 macros/synonnyms
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
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 can
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
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 to a string of
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 text() ?
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
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
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
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 -framework
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 on making us
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 issue
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-fused-madd
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 surprise
22 matches
Mail list logo