Re: [Python-Dev] Shorter float repr in Python 3.1?
Ned Deily wrote: In article <[email protected]>, 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 builds and run them on G3 and G4 Macs vs 32-/64- Intel. Any tests of interest beyond the default regttest.py? Thanks! regrtest.py should be enough. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article , Ned Deily wrote: > In article <[email protected]>, > 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 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 OSX installers. The good news: on 10.5 i386, running the default regrtest, no signficant differences were noted from an installer built from the current main py3k head. Bad news: the same build installed on a G4 running 10.5 hung hard in test_pow of test_builtin; a kill was needed to terminate python. Same results on a G3 running 10.4. n...@pbg4:/Library/Frameworks/Python.framework/Versions/3.1$ bin/python -S lib/python3.1/test/regrtest.py -s -v test_builtin test_builtin test_abs (test.test_builtin.BuiltinTest) ... ok test_all (test.test_builtin.BuiltinTest) ... ok test_any (test.test_builtin.BuiltinTest) ... ok test_ascii (test.test_builtin.BuiltinTest) ... ok test_bin (test.test_builtin.BuiltinTest) ... ok test_callable (test.test_builtin.BuiltinTest) ... ok test_chr (test.test_builtin.BuiltinTest) ... ok test_cmp (test.test_builtin.BuiltinTest) ... ok test_compile (test.test_builtin.BuiltinTest) ... ok test_delattr (test.test_builtin.BuiltinTest) ... ok test_dir (test.test_builtin.BuiltinTest) ... ok test_divmod (test.test_builtin.BuiltinTest) ... ok test_eval (test.test_builtin.BuiltinTest) ... ok test_exec (test.test_builtin.BuiltinTest) ... ok test_exec_redirected (test.test_builtin.BuiltinTest) ... ok test_filter (test.test_builtin.BuiltinTest) ... ok test_general_eval (test.test_builtin.BuiltinTest) ... ok test_getattr (test.test_builtin.BuiltinTest) ... ok test_hasattr (test.test_builtin.BuiltinTest) ... ok test_hash (test.test_builtin.BuiltinTest) ... ok test_hex (test.test_builtin.BuiltinTest) ... ok test_id (test.test_builtin.BuiltinTest) ... ok test_import (test.test_builtin.BuiltinTest) ... ok test_input (test.test_builtin.BuiltinTest) ... ok test_isinstance (test.test_builtin.BuiltinTest) ... ok test_issubclass (test.test_builtin.BuiltinTest) ... ok test_iter (test.test_builtin.BuiltinTest) ... ok test_len (test.test_builtin.BuiltinTest) ... ok test_map (test.test_builtin.BuiltinTest) ... ok test_max (test.test_builtin.BuiltinTest) ... ok test_min (test.test_builtin.BuiltinTest) ... ok test_neg (test.test_builtin.BuiltinTest) ... ok test_next (test.test_builtin.BuiltinTest) ... ok test_oct (test.test_builtin.BuiltinTest) ... ok test_open (test.test_builtin.BuiltinTest) ... ok test_ord (test.test_builtin.BuiltinTest) ... ok test_pow (test.test_builtin.BuiltinTest) ... ^CTerminated Stepping through some of test_pow from the interactive interpreter: Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> pow(0,0) 1<-- OK >>> pow(2,30) 1073741824 <-- OK >>> pow(0.,0) ^C^CTerminated <-- float argument => python hung in CPU loop, killed Then I tried a couple of random floats: Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 3.1 -9.255965342383856e+61 >>> 1. ^C Terminated <-- kill needed The same tests work fine on the intel Mac. Just out of curiosity, I'll try to do the same build on the 10.4 ppc; there are occasionally a few differences noted in the build results. That won't be available until later today. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping bytes "support" in json
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 you specify, e.g., ISO-8859-1 a
standard-compliant receiver will probably still try to interpret the
content as UTF-8/16/32.
OTOH a charset can be used if you send JSON with an
application/javascript MIME type.
--
Lino Mastrodomenico
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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'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?
Ned, many thanks for doing this!
> Then I tried a couple of random floats:
>
> Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35)
> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
3.1
> -9.255965342383856e+61
1.
> ^C
> Terminated <-- kill needed
Cool! I suspect endianness issues. As evidence, I present:
>>> list(struct.pack('>> list(struct.pack('http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 OSX installers. The good news: on 10.5 i386, running the default regrtest, no signficant differences were noted from an installer built from the current main py3k head. Okay, that's awesome. Thanks. Bad news: the same build installed on a G4 running 10.5 hung hard in test_pow of test_builtin; a kill was needed to terminate python. Same results on a G3 running 10.4. Okay, that's less than awesome. But still a huge thanks. Then I tried a couple of random floats: Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. 3.1 -9.255965342383856e+61 1. ^C Terminated <-- kill needed I don't suppose it's possible that you could run this under gdb and get a stack trace when it starts looping (assuming that's what's happening)? I think I might have a PPC Mac Mini I can get my hands on, and I'll test there if possible. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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. If that constant can't take different values depending on the CPU arch, we have a big problem. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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-archs=32-bit --enable-framework --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 but the configure AC_C_BIGENDIAN macro doesn't seem to pick up on the universality: the output from ./configure contains the line: checking whether byte ordering is bigendian... no I was expecting a "... universal" instead of "... no". >From reading the autoconf manual, it seems as though AC_C_BIGENDIAN knows some magic to make things work for universal builds; it ought to be possible to imitate that magic somehow. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] UTF-8 Decoder
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 it against Python 3.1's (py3k) decoder. There are two cases to consider: - mostly non-ASCII input, such as the "utf-8 demo" file mentioned in the page above - mostly ASCII input, such as will happen very often (think HTML, XML, log files, etc.) The py3k utf-8 decoder is optimized for the latter. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
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 using that O(1) >> >> check ? >> >> > >> >> > Again - this wouldn't be O(1). More importantly, it breaks system >> >> > packages, which now again have to deal with the conflicting file >> names >> >> > if they want to install all portions into a single location. >> >> >> >> True, but since that means changing the package infrastructure, I >> think >> >> it's fair to ask distributors who want to use that approach to also >> take >> >> care of looking into the __pkg__.py files and merging them if >> >> necessary. >> >> >> >> Most of the time the __pkg__.py files will be empty, so that's not >> >> really much to ask for. >> > >> > This means your proposal actually doesn't add any benefit over the >> > status quo, where you can have an __init__.py that does nothing but >> > declare the package a namespace. We already have that now, and it >> > doesn't need a new filename. Why would we expect OS vendors to start >> > supporting it, just because we name it __pkg__.py instead of >> __init__.py? >> >> I lost you there. >> >> Since when do we support namespace packages in core Python without >> the need to add some form of magic support code to __init__.py ? >> >> My suggestion basically builds on the same idea as Martin's PEP, >> but uses a single __pkg__.py file as opposed to some non-Python >> file yaddayadda.pkg. > > Right... which completely obliterates the primary benefit of the > original proposal compared to the status quo. That is, that the PEP 382 > way is more compatible with system packaging tools. > > Without that benefit, there's zero gain in your proposal over having > __init__.py files just call pkgutil.extend_path() (in the stdlib since > 2.3, btw) or pkg_resources.declare_namespace() (similar functionality, > but with zipfile support and some other niceties). > > IOW, your proposal doesn't actually improve the status quo in any way > that I am able to determine, except that it calls for loading all the > __pkg__.py modules, rather than just the first one. (And the setuptools > implementation of namespace packages actually *does* load multiple > __init__.py's, so that's still no change over the status quo for > setuptools-using packages.) The purpose of the PEP is to create a standard for namespace packages. That's orthogonal to trying to enhance or change some existing techniques. 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 Python scans during imports. That said, note that most distributions actually take the other route: they try to split up larger packages into smaller ones, so the argument becomes even weaker. It is much more important to standardize the approach than to try to extend some existing trickery and make them even more opaque than they already are by introducing yet another level of complexity. My alternative approach builds on existing methods and fits nicely with the __init__.py approach Python has already been using for more than a decade now. It's transparent, easy to understand and provides enough functionality to build upon - much like the original __init__.py idea. I've already laid out the arguments for and against it in my previous reply, so won't repeat them here. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 14 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding new features to Python 2.x
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 to Python 3.1. Thanks for picking this up. I'd like to extend the proposal to Python 2.7 and later. >>> -1 to adding it to the 2.x series. There was much discussion around >>> adding features to 2.x *and* 3.0, and the consensus seemed to *not* >>> add new features to 2.x and use those new features as carrots to help >>> lead people into 3.0. >> I must have missed that discussion :-) >> >> Where's the PEP pinning this down ? >> >> The Python 2.x user base is huge and the number of installed >> applications even larger. >> >> Cutting these users and application developers off of important new >> features added to Python 3 is only going to work as "carrot" for >> those developers who: >> >> * have enough resources (time, money, manpower) to port their existing >> application to Python 3 >> >> * can persuade their users to switch to Python 3 >> >> * don't rely much on 3rd party libraries (the bread and butter >> of Python applications) >> >> Realistically, such a porting effort is not likely going to happen >> for any decent sized application, except perhaps a few open source >> ones. >> >> Such a policy would then translate to a dead end for Python 2.x >> based applications. > > Think of the advantages though! Python 2 will finally become *stable*. > The group of users you are talking to are usually balking at the > thought of upgrading from 2.x to 2.(x+1) just as much as they might > balk at the thought of Py3k. We're finally giving them what they > really want. Python 2.x is stable - much more than 3.x is today. However, stable does not mean zero development, which a "No new features in Python 2.x" policy would translate to. If there are core developers that care about 2.x, then it should be possible for them to add the necessary patches to future 2.x releases. > Regarding calling this a dead end, we're committed to supporting 2.x > for at least five years. If that's not enough, well, it's open source, > so there's no reason why some group of rogue 2.x fans can't maintain > it indefinitely after that. Sure, but why can't this be done within the existing Python developer community ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 14 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 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. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 for all other instances of endianness detection in the py3k code base? Has anyone tested a recent py3k using universal builds? Do all tests pass? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
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 Python scans during imports. That said, note that most distributions actually take the other route: they try to split up larger packages into smaller ones, so the argument becomes even weaker. I think you've misunderstood something about the use case. System packaging tools don't like separate packages to contain the *same file*. That means that they *can't* split a larger package up with your proposal, because every one of those packages would have to contain a __pkg__.py -- and thus be in conflict with each other. Either that, or they would have to make a separate system package containing *only* the __pkg__.py, and then make all packages using the namespace depend on it -- which is more work and requires greater co-ordination among packagers. Allowing each system package to contain its own .pkg or .nsp or whatever files, on the other hand, allows each system package to be built independently, without conflict between contents (i.e., having the same file), and without requiring a special pseudo-package to contain the additional file. Also, executing multiple __pkg__.py files means that when multiple system packages are installed to site-packages, only one of them could possibly be executed. (Note that, even though the system packages themselves are not "combined", in practice they will all be installed to the same directory, i.e., site-packages or the platform equivalent thereof.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 endianness detection goes via AC_C_BIGENDIAN, which understands universal builds---but only for autoconf >= 2.62. > Has anyone tested a recent py3k using universal builds? Do all tests pass? 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. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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.1) as 4-way (i386, ppc, x86_64, ppc64), although the ppc64 has had no testing recently. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article <[email protected]>, 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? Not looking good. Appears to be same behavior on the G4 with 10.5 (haven't tried the G3 yet). -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article <[email protected]>, 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-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 --with-universal-archs='32-bit' --with-computed-gotos OPT='-g -O3' and for 4-way: export MACOSX_DEPLOYMENT_TARGET=10.5 configure -C --enable-framework --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk --with-universal-archs='all' --with-computed-gotos OPT='-g -O3' -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
> 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 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, which does #if defined(__APPLE__) # undef WORDS_BIGENDIAN #ifdef __BIG_ENDIAN__ #define WORDS_BIGENDIAN 1 #endif /* __BIG_ENDIAN */ #endif Earlier versions included that ifdef block directly in pyconfig.h.in. In case it isn't clear how this works: GCC predefines __BIG_ENDIAN__ on PPC but not on x86; for universal binaries, two (or more) separate preprocessor (and compiler runs) are done. HTH, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
> 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 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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. I think I understand how to make things work now. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 > --with-universal-archs='32-bit' --with-computed-gotos OPT='-g -O3' Great---thank you! And thank you for all the testing. I'll try to sort all this out later this evening (GMT+1); I think I understand how to fix everything now. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 >> = >> >> (1) Any objections to including this into py3k? If there's >> controversy, then I guess we'll need a PEP. >> >> > > Big +1 > >> (2) Should other Python implementations (Jython, >> IronPython, etc.) be expected to use short float repr, or should >> it just be considered an implementation detail of CPython? >> I propose the latter, except that all implementations should >> be required to satisfy eval(repr(x)) == x for finite floats x. >> >> > Short float repr should be an implementation detail, so long as > eval(repr(x)) == x still holds. > > Michael Foord > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jbaker%40zyasoft.com > -- Jim Baker [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter float repr in Python 3.1?
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 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. It cannot, the actual bigendian detection for universal build is done in pymacconfig.h. I have given up on getting pyconfig.h right for universal builds, especially when dealing with 4-way universal builds. Ronald Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
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 separate >> hierarchy >> of special files which Python scans during imports. >> >> That said, note that most distributions actually take the other route: >> they try to split up larger packages into smaller ones, so the argument >> becomes even weaker. > > I think you've misunderstood something about the use case. System > packaging tools don't like separate packages to contain the *same > file*. That means that they *can't* split a larger package up with your > proposal, because every one of those packages would have to contain a > __pkg__.py -- and thus be in conflict with each other. Either that, or > they would have to make a separate system package containing *only* the > __pkg__.py, and then make all packages using the namespace depend on it > -- which is more work and requires greater co-ordination among packagers. 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 bundle that includes the needed __init__.py file and a set of extension bundles the add other files to the same directory (without including another copy of __init__.py). The extension bundles include a dependency on the base package to make sure that it always gets installed first. Debian has been using that approach for egenix-mx-base for years. Works great: http://packages.debian.org/source/lenny/egenix-mx-base eGenix has been using that approach for mx package add-ons as well - long before "namespace" packages where given that name :-) Please note that the PEP is about providing ways to have package parts live on sys.path that reintegrate themselves into a single package at import time. As such it's targeting Python developers that want to ship add-ons to existing packages, not Linux distributions (they usually have their own ideas about what goes where - something that's completely out-of- scope for the PEP). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 14 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 382: Namespace Packages
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 bundle that includes the needed __init__.py file and a set of extension bundles the add other files to the same directory (without including another copy of __init__.py). The extension bundles include a dependency on the base package to make sure that it always gets installed first. If we're going to keep that practice, there's no point to having the PEP: all three methods (base+extensions, pkgutil, setuptools) all work just fine as they are, with no changes to importing or the stdlib. In particular, without the feature of being able to drop that practice, there would be no reason for setuptools to adopt the PEP. That's why I'm -1 on your proposal: it's actually inferior to the methods we already have today. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Why does read() return bytes instead of bytearray?
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 pays the price in performance and simplicity. It seemed to me that the immutable bytes was described as being useful in niche situations, but it actually seems to have been favored over bytearray in Python 3. Was there was a good reason for this decision? Or was this just an artifact in the change to two bytes types? The reason I ask is I have a server application that is mostly stream reading/writing on the hot path and in Python 2.5 the redundant copies add up to a significant overhead, (I estimate as much as 25% from my measurements) I was looking at Python 3 as a way to solve that problem, but unfortunately it doesn't look like it will help. Thanks, -Dan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why does read() return bytes instead of bytearray?
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, modify, write is very common. I don't understand why > the common case pays the price in performance and simplicity. It > seemed to me that the immutable bytes was described as being useful in > niche situations, but it actually seems to have been favored over > bytearray in Python 3. > > Was there was a good reason for this decision? Or was this just an > artifact in the change to two bytes types? No, the read() method did not change from the 2.x series. It returns a new object on each call. > The reason I ask is I have a server application that is mostly stream > reading/writing on the hot path and in Python 2.5 the redundant copies > add up to a significant overhead, (I estimate as much as 25% from my > measurements) I was looking at Python 3 as a way to solve that > problem, but unfortunately it doesn't look like it will help. Files opened in binary mode have a readinto() method, which fills the given bytearray. Is this what you are looking for? -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Why does read() return bytes instead of bytearray?
>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 enlightening me, I feel a little stupid now :) Python 3, lookout, here I come! -Dan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
