Warning: Reply-To set to email-sig.
Greg Ewing writes:
Only for headers known to be unstructured, I think.
Completely unknown headers should be available only
as bytes.
Why do I get the feeling that you guys are feeling up an
elephant?wink
There are four things you might want to do with
Ned Deily wrote:
In article 49e3d34e.8040...@trueblade.com,
Eric Smith e...@trueblade.com wrote:
Before then, if anyone could build and test the py3k-short-float-repr
branch on any of the following machines, that would be great:
[...]
Something bigendian, like a G4 Mac
I'll crank up some
In article nad-d10aa9.19075613042...@news.gmane.org,
Ned Deily n...@acm.org wrote:
In article 49e3d34e.8040...@trueblade.com,
Eric Smith e...@trueblade.com wrote:
Before then, if anyone could build and test the py3k-short-float-repr
branch on any of the following machines, that would be
2009/4/13 Daniel Stutzbach dan...@stutzbachenterprises.com:
print(Content-Type: application/json; charset=utf-8)
Please don't do that! According to RFC 4627 the charset parameter is
not allowed for the application/json media type.
Just use Content-Type: application/json, the charset is only
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily n...@acm.org wrote:
Ned Deily n...@acm.org wrote:
Eric Smith e...@trueblade.com wrote:
Before then, if anyone could build and test the py3k-short-float-repr
branch on any of the following machines, that would be great:
[...]
Something
Ned Deily wrote:
I'll crank up some OS X installer builds and run them on G3 and G4 Macs
vs 32-/64- Intel. Any tests of interest beyond the default regttest.py?
FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for
10.3 and above; this is the similar to recent python.org
By the way, a simple native build on OS X 10.4/PPC passed all tests (that
we're already failing before).
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Tue, Apr 14, 2009 at 11:37 AM, Mark Dickinson dicki...@gmail.com wrote:
By the way, a simple native build on OS X 10.4/PPC passed all tests (that
we're already failing before).
s/we're/weren't
___
Python-Dev mailing list
Python-Dev@python.org
Mark Dickinson dickinsm at gmail.com writes:
But I'd expect that there are already similar issues
with a 'fat' build of py3k on OS X. After all, there's
already a 'WORDS_BIGENDIAN' in pyconfig.h.in. I
don't know where this is used.
It's used e.g. in unicode encoding/decoding, and in the IO
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily n...@acm.org wrote:
FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for
10.3 and above; this is the similar to recent python.org OSX installers.
What's the proper way to create such a build? I've been trying:
./configure
Jeroen Ruigrok van der Werven asmodai at in-nomine.org writes:
This got posted on the Unicode list, does it seem interesting for Python
itself, the UTF-8 to UTF-16 transcoding might be?
http://bjoern.hoehrmann.de/utf-8/decoder/dfa/
If you have some time on your hands, you could try
On 2009-04-07 19:46, P.J. Eby wrote:
At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-07 16:05, P.J. Eby wrote:
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote:
Wouldn't it be better to stick with a simpler approach and look for
__pkg__.py files to detect namespace packages
On 2009-04-07 18:19, Guido van Rossum wrote:
On Tue, Apr 7, 2009 at 5:25 AM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-06 15:21, Jesse Noller wrote:
On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
I propose the following
Okay, I think I might have fixed up the float endianness detection for
universal builds on OS X. Ned, any chance you could give this
another try with an updated version of the py3k-short-float-repr branch?
One thing I don't understand:
Is it true that to produce a working universal/fat build of
Mark Dickinson dickinsm at gmail.com writes:
Okay, I think I might have fixed up the float endianness detection for
universal builds on OS X. Ned, any chance you could give this
another try with an updated version of the py3k-short-float-repr branch?
If this approach is sane, could it be
At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
I don't see the emphasis in the PEP on Linux distribution support and the
remote possibility of them wanting to combine separate packages back
into one package as good argument for adding yet another separate hierarchy
of special files which
On Tue, Apr 14, 2009 at 5:14 PM, Antoine Pitrou solip...@pitrou.net wrote:
If this approach is sane, could it be adopted for all other instances of
endianness detection in the py3k code base?
I think everything else is fine: float endianness detection (for marshal,
pickle, struct) is done at
Mark Dickinson dickinsm at gmail.com writes:
Has anyone tested a recent py3k using universal builds? Do all tests pass?
Do you know the right way to create a universal build?
Not at all, sorry.
Regards
Antoine.
___
Python-Dev mailing list
On Tue, Apr 14, 2009 at 5:49 PM, Antoine Pitrou solip...@pitrou.net wrote:
Mark Dickinson dickinsm at gmail.com writes:
Do you know the right way to create a universal build?
Not at all, sorry.
No problem :). I might try asking on the pythonmac-sig list.
Mark
In article loom.20090414t161327-...@post.gmane.org,
Antoine Pitrou solip...@pitrou.net wrote:
Has anyone tested a recent py3k using universal builds? Do all tests pass?
It's done all the time. All of the current released installers (2.5,
2.6, 3.0) are 2-way (i386, ppc) universal and we
In article
5c6f2a5d0904140909x417d225ejd845de9c5c780...@mail.gmail.com,
Mark Dickinson dicki...@gmail.com wrote:
Okay, I think I might have fixed up the float endianness detection for
universal builds on OS X. Ned, any chance you could give this
another try with an updated version of the
In article
5c6f2a5d0904140930y7dc7cf4fg496d50fd34f89...@mail.gmail.com,
Mark Dickinson dicki...@gmail.com wrote:
Do you know the right way to create a universal build? If so, I'm in a
position
to test on 32-bit PPC, 32-bit Intel and 64-bit Intel.
The OSX installer script is in
Is it true that to produce a working universal/fat build of Python,
one has to first regenerate configure and pyconfig.h.in using autoconf
version = 2.62? If not, then I don't understand how the
AC_C_BIGENDIAN autoconf macro can be giving the right results.
The outcome of AC_C_BIGENDIAN
If this approach is sane, could it be adopted for all other instances of
endianness detection in the py3k code base?
Don't worry - the approach that we already take is already sane, so no
further changes are needed.
Regards,
Martin
___
Python-Dev
On Tue, Apr 14, 2009 at 6:55 PM, Martin v. Löwis mar...@v.loewis.de wrote:
The outcome of AC_C_BIGENDIAN isn't used on OSX. Depending on the exact
version you look at, things might work differently; in trunk,
Include/pymacconfig.h should be used [...]
Many thanks---that was the missing piece
On Tue, Apr 14, 2009 at 6:32 PM, Ned Deily n...@acm.org wrote:
The OSX installer script is in Mac/BuildScript/build-installer.py.
For 2-way builds, it essentially does:
export MACOSX_DEPLOYMENT_TARGET=10.3
configure -C --enable-framework
I rather like supporting short float representation. Given that CPython is
adopting it, I'm sure Jython will adopt this approach too as part of a
future Jython 3.x release.
- Jim
On Tue, Apr 7, 2009 at 9:41 AM, Michael Foord fuzzy...@voidspace.org.ukwrote:
Mark Dickinson wrote:
[snip...]
On 14 Apr, 2009, at 18:09, Mark Dickinson wrote:
Okay, I think I might have fixed up the float endianness detection for
universal builds on OS X. Ned, any chance you could give this
another try with an updated version of the py3k-short-float-repr
branch?
One thing I don't understand:
Is
On 2009-04-14 18:27, P.J. Eby wrote:
At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
I don't see the emphasis in the PEP on Linux distribution support and the
remote possibility of them wanting to combine separate packages back
into one package as good argument for adding yet another
At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
packages at all, so the PEP doesn't apply.
The way this works is by having a base distribution
Hi,
Can someone please explain why read() should return an immutable bytes
type instead of a mutable bytearray? It's not like read() from a file
and use buffer as a key in a dict is common. Certainly read() from
file or stream, modify, write is very common. I don't understand why
the common case
Hello,
On Wed, Apr 15, 2009 at 03:01, Dan Eloff dan.el...@gmail.com wrote:
Hi,
Can someone please explain why read() should return an immutable bytes
type instead of a mutable bytearray? It's not like read() from a file
and use buffer as a key in a dict is common. Certainly read() from
file
No, the read() method did not change from the 2.x series. It returns a new
object on each call.
I think you misunderstand me, but the readinto() method looks like a
perfectly reasonable solution, I didn't realize it existed, as it's
not in the library reference on file objects. Thanks for
33 matches
Mail list logo
