>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 enlig
Hello,
On Wed, Apr 15, 2009 at 03:01, Dan Eloff 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 or stream, mo
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 p
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 bun
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 s
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 i
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 wrote:
> Mark Dickinson wrote:
>
>> [snip...]
>> Discussion points
>> =
On Tue, Apr 14, 2009 at 6:32 PM, Ned Deily 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
> --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk
>
On Tue, Apr 14, 2009 at 6:55 PM, "Martin v. Löwis" 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 of the puzzle.
> 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 ma
> 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
In article
<5c6f2a5d0904140930y7dc7cf4fg496d50fd34f89...@mail.gmail.com>,
Mark Dickinson 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 Mac/BuildScript/build-inst
In article
<5c6f2a5d0904140909x417d225ejd845de9c5c780...@mail.gmail.com>,
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
In article ,
Antoine Pitrou 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 occasionally test all
of the current lines (2.6, trunk, 3.0, 3.
On Tue, Apr 14, 2009 at 5:49 PM, Antoine Pitrou wrote:
> Mark Dickinson 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
___
Python-De
Mark Dickinson 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
Python-D
On Tue, Apr 14, 2009 at 5:14 PM, Antoine Pitrou 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 runtime. Integer e
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 Pytho
Mark Dickinson 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 adopted f
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
On 2009-04-07 18:19, Guido van Rossum wrote:
> On Tue, Apr 7, 2009 at 5:25 AM, M.-A. Lemburg wrote:
>> On 2009-04-06 15:21, Jesse Noller wrote:
>>> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote:
On 2009-04-02 17:32, Martin v. Löwis wrote:
> I propose the following PEP for inclusion
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 na
Jeroen Ruigrok van der Werven 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 benchmarking
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily 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 --with-universal-ar
Mark Dickinson 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 lib.
On Tue, Apr 14, 2009 at 11:37 AM, Mark Dickinson 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
http://mail.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:
http://mail.python.org/mailma
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 OS
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily wrote:
> Ned Deily wrote:
>> Eric Smith 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'
2009/4/13 Daniel Stutzbach :
> 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
misleading because even if y
In article ,
Ned Deily wrote:
> In article <49e3d34e.8040...@trueblade.com>,
> Eric Smith 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
>
>
Ned Deily wrote:
In article <49e3d34e.8040...@trueblade.com>,
Eric Smith 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 OS X installer b
32 matches
Mail list logo
