Mailman 3 April 2001 - Python-Dev

Re: [Python-checkins] CVS: python/nondist/peps pep-0252.txt,NONE,1.1 pep-0000.txt,1.87,1.88
by Michael Hudson 19 Apr '01

19 Apr '01

Guido van Rossum <gvanrossum(a)users.sourceforge.net> writes: [snip] > Author: guido(a)python.org (Jeremy Hylton) Eh? [snop]

1 0

Re: [Python-Dev] ANN: Experimental Number Types (Integer, Rational, Floats)
by Michael Hudson 19 Apr '01

19 Apr '01

Before I d/l and take a look... "M.-A. Lemburg" <mal(a)lemburg.com> writes: > (e.g. Integer(2) + "3" works as one would expect ;-). So it raises an exception? Seriously, that's what *I'd* expect, and if it's not what your package does, I beg you to reconsider. Cheers, M. -- Good? Bad? Strap him into the IETF-approved witch-dunking apparatus immediately! -- NTK now, 21/07/2000

2 1

ANN: Experimental Number Types (Integer, Rational, Floats)
by M.-A. Lemburg 19 Apr '01

19 Apr '01

As you all know, Moshe Zadka has been pushing for a new rational number type recently (at the conference) and also implemented a proof- of-concept implementation of his rational PEP 239. Since the GNU Multi-Precision Lib (GMP) already has all these tools providing what people want most when it comes to numbers (precision and speed), I thought that wrapping these as Python types would be a good idea. I know that Alex Martelli has been working on a similar approach, but that project (gmpy) seems to be inactive. Anyway, even though the GMP is available for most Unix platforms and MacOS, there was no relyable port for Windows. This was a show- stopper for me, so I decided to port GMP to Windows, which was harder than I though, but well, it's done now ;-) The wrapper is called mx.Number and provides access to three numerical types: 1. Integer(value) -- arbitrary precision integers much like Python long only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision Prerequisites: -------------- * GMP 3.1.1 - Unix: GMP 3.1.1 must be installed (http://www.swox.com/gmp/) - Windows: GMP 3.1.1 is included in the download archives for Windows * Python 2.1 * Optional: egenix-mx-base package available from http://www.lemburg.com/files/python/ * The "egenix-mx-experimental" package which includes mx.Number: Source: http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.zip RPM: http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0-1.i386-py2… Windows installer: http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.win32-py2.… Usage is simple: ---------------- from mx.Number import * f = Float(3.141) r1 = Rational(3.141) r2 = Rational(2, 3) i = Integer("1231231231231231231231231") The coercion model will (someday) look like this: Float ^ | --------> Python float | ^ | | | Rational | ^ | | Python long -----> Integer ^ ^ | | -------- Python integer Complex numbers are not integrated into the picture since I think that they should not be auto-coerced. Some of these arrows are not implemented yet, others are not shown (e.g. Integer(2) + "3" works as one would expect ;-). Note that this is still a very rough version. Feedback is welcome. Questions: ---------- * What do you think about this coercion model ? Shouldn't we have a PEP for this ? * Please try out the rational type and see if it fits your needs -- the results are sometimes surprising (due to the IEEE representations of floats); I'm sure this proof of concept will raise a few more questions regarding the usefulness of switching to rationals for literals like 1.123. * This implementation also showed that even though the coercion patches have made integraton of numerical types easier, a full integration is still hard to achieve. Some issues: - string formatting cannot be "overridden" to allow formatting of these new types - there is no way of providing PyArg_ParseTuple() parser markers for the types - there is no way to bind the types to a Python literal, e.g. by specifying a number literal modifier which is then bound to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"), 2R / 3 -> Rational(2, 3) etc. Comments ? -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/

1 0

ANN: Experimental Number Types (Integer, Rational, Floats)
by M.-A. Lemburg 19 Apr '01

19 Apr '01

As you all know, Moshe Zadka has been pushing for a new rational number type recently (at the conference) and also implemented a proof- of-concept implementation of his rational PEP 239. Since the GNU Multi-Precision Lib (GMP) already has all these tools providing what people want most when it comes to numbers (precision and speed), I thought that wrapping these as Python types would be a good idea. I know that Alex Martelli has been working on a similar approach, but that project (gmpy) seems to be inactive. Anyway, even though the GMP is available for most Unix platforms and MacOS, there was no relyable port for Windows. This was a show- stopper for me, so I decided to port GMP to Windows, which was harder than I though, but well, it's done now ;-) The wrapper is called mx.Number and provides access to three numerical types: 1. Integer(value) -- arbitrary precision integers much like Python long only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision Prerequisites: -------------- * GMP 3.1.1 - Unix: GMP 3.1.1 must be installed (http://www.swox.com/gmp/) - Windows: GMP 3.1.1 is included in the download archives for Windows * Python 2.1 * Optional: egenix-mx-base package available from http://www.lemburg.com/files/python/ * The "egenix-mx-experimental" package which includes mx.Number: Source: http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.zip RPM: http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0-1.i386-py2… Windows installer: http://www.lemburg.com/files/python/egenix-mx-experimental-0.1.0.win32-py2.… Usage is simple: ---------------- from mx.Number import * f = Float(3.141) r1 = Rational(3.141) r2 = Rational(2, 3) i = Integer("1231231231231231231231231") The coercion model will (someday) look like this: Float ^ | --------> Python float | ^ | | | Rational | ^ | | Python long -----> Integer ^ ^ | | -------- Python integer Complex numbers are not integrated into the picture since I think that they should not be auto-coerced. Some of these arrows are not implemented yet, others are not shown (e.g. Integer(2) + "3" works as one would expect ;-). Note that this is still a very rough version. Feedback is welcome. Questions: ---------- * What do you think about this coercion model ? Shouldn't we have a PEP for this ? * Please try out the rational type and see if it fits your needs -- the results are sometimes surprising (due to the IEEE representations of floats); I'm sure this proof of concept will raise a few more questions regarding the usefulness of switching to rationals for literals like 1.123. * This implementation also showed that even though the coercion patches have made integraton of numerical types easier, a full integration is still hard to achieve. Some issues: - string formatting cannot be "overridden" to allow formatting of these new types - there is no way of providing PyArg_ParseTuple() parser markers for the types - there is no way to bind the types to a Python literal, e.g. by specifying a number literal modifier which is then bound to the type: 1234L -> long("1234"), 1234.123F -> Float("1234.123"), 2R / 3 -> Rational(2, 3) etc. Comments ? -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/

1 0

ANNOUNCE: Python 2.1 final release
by Guido van Rossum 19 Apr '01

19 Apr '01

Yes, the *final* release of Python 2.1 is now available. Thanks again for all who helped! Go here for downloads and information: http://www.python.org/2.1/ As a reminder, here's a list of some of the big new features in 2.1 (news since 2.0 was released in October 2000): - nested scopes and __future__ directives - rich comparisons and new coercion model - warnings framework - new build process (Unix) - weak references - function attributes - unittest and doctest modules for automated testing - ports to several new platforms, including Cygwin and RISCOS --Guido van Rossum (home page: http://www.python.org/~guido/)

4 5

2.2a0: latest unicode change breaks test_unicodedata
by Mark Favas 18 Apr '01

18 Apr '01

In a change from 2.1 (final) to 2.2a0 - test_unicodedata now fails the methods test: test test_unicodedata failed -- Writing: '00c22b40a906a1a738012676c9feaedfc6be20 d9', expected: '6c7a7c02657b69d0fdd7a7d174f573194bba2e18' python Lib/test/test_unicodedata.py Testing Unicode Database... Methods: 00c22b40a906a1a738012676c9feaedfc6be20d9 Functions: 4db70de42a8f2de6236242949579fe0e80e7c34a API: ok (Tru64 Unix, Compaq C) -- Mark Favas - m.favas(a)per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA

2 1

PEP 6 revision
by aahz＠panix.com 18 Apr '01

18 Apr '01

[posted to c.l.py.announce and c.l.py; followups to c.l.py; cc'd to python-dev] [Barry, please update Post-History] Okay, here's the next version of PEP 6: PEP: 6 Title: Bugfix Releases Version: $Revision: 1.3 $ Author: aahz(a)pobox.com (Aahz) Status: Draft Type: Informational Created: 15-Mar-2001 Post-History: 15-Mar-2001 Abstract Python has historically had only a single fork of development, with releases having the combined purpose of adding new features and delivering bug fixes (these kinds of releases will be referred to as "feature releases"). This PEP describes how to fork off patch releases of old versions for the primary purpose of fixing bugs. This PEP is not, repeat NOT, a guarantee of the existence of patch releases; it only specifies a procedure to be followed if patch releases are desired by enough of the Python community willing to do the work. Motivation With the move to SourceForge, Python development has accelerated. There is a sentiment among part of the community that there was too much acceleration, and many people are uncomfortable with upgrading to new versions to get bug fixes when so many features have been added, sometimes late in the development cycle. One solution for this issue is to maintain the previous feature release, providing bugfixes until the next feature release. This should make Python more attractive for enterprise development, where Python may need to be installed on hundreds or thousands of machines. Prohibitions Patch releases are required to adhere to the following restrictions: 1. There must be zero syntax changes. All .pyc and .pyo files must work (no regeneration needed) with all patch releases forked off from a feature release. 2. There must be zero pickle changes. 3. There must be no incompatible C API changes. All extensions must continue to work without recompiling in all patch releases in the same fork as a feature release. Breaking any of these prohibitions requires a BDFL proclamation (and a prominent warning in the release notes). Version Numbers Starting with Python 2.0, all feature releases are required to have a version number the form X.Y; patch releases will always be of the form X.Y.Z. The current feature release under development is referred to as release N; the just-released feature version is referred to as N-1. Procedure The process for managing patch releases is modeled in part on the Tcl system [1]. The Patch Czar is the counterpart to the BDFL for patch releases. However, the BDFL and designated appointees retain veto power over individual patches. As individual patches get contributed to the feature release fork, each patch contributor is requested to consider whether the patch is a bugfix suitable for inclusion in a patch release. If the patch is considered suitable, the patch contributor will mail the SourceForge patch (bugfix?) number to the maintainers' mailing list. In addition, anyone from the Python community is free to suggest patches for inclusion. Patches may be submitted specifically for patch releases; they should follow the guidelines in PEP 3 [2]. The Patch Czar decides when there are a sufficient number of patches to warrant a release. The release gets packaged up, including a Windows installer, and made public. If any new bugs are found, they must be fixed immediately and a new patch release publicized (with an incremented version number). Patch releases are expected to occur at an interval of roughly one month. In general, only the N-1 release will be under active maintenance at any time. Patch Czar History Moshe Zadka (moshez(a)zadka.site.co.il) is the Patch Czar for 2.0.1. Issues To Be Resolved What is the equivalent of python-dev for people who are responsible for maintaining Python? (Aahz proposes either python-patch or python-maint, hosted at either python.org or xs4all.net.) Does SourceForge make it possible to maintain both separate and combined bug lists for multiple forks? If not, how do we mark bugs fixed in different forks? (Simplest is to simply generate a new bug for each fork that it gets fixed in, referring back to the main bug number for details.) History This PEP started life as a proposal on comp.lang.python. The original version suggested a single patch for the N-1 release to be released concurrently with the N release. The original version also argued for sticking with a strict bugfix policy. Following feedback from the BDFL and others, the draft PEP was written containing an expanded patch release cycle that permitted any previous feature release to obtain patches and also relaxed the strict bugfix requirement (mainly due to the example of PEP 235 [3], which could be argued as either a bugfix or a feature). Discussion then mostly moved to python-dev, where BDFL finally issued a proclamation basing the Python patch release process on Tcl's, which essentially returned to the original proposal in terms of being only the N-1 release and only bugfixes, but allowing multiple patch releases until release N is published. References [1] http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html [2] http://python.sourceforge.net/peps/pep-0003.html [3] http://python.sourceforge.net/peps/pep-0235.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: -- --- Aahz <*> (Copyright 2001 by aahz(a)pobox.com) Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 "If we had some ham, we could have ham & eggs, if we had some eggs." --RH

1 0

Case sensitive import on windows
by Thomas Heller 18 Apr '01

18 Apr '01

I tried to find out what had changed between 2.0 and 2.1. Consider the following files in the current directory: Spam.py spam/__init__.py Using python 2.0: Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import Spam Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: Case mismatch for module name Spam (filename spam) >>> import spam; print spam <module 'spam' from 'spam\__init__.py'> >>> Using python 2.1: Python 2.1c2 (#14, Apr 15 2001, 21:29:05) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import Spam Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: NULL result without error in call_object >>> import spam; print spam <module 'spam' from 'spam\__init__.py'> >>> Seems like a bug to me... Thomas

2 2

Python 2.1 PEPs
by barry＠digicool.com 18 Apr '01

18 Apr '01

Now that Python 2.1 is officially out the door, it's time to do some spring cleaning on the PEPs. I'm currently processing the latest batch of PEP requests, and I'm going to create a Python 2.2 release schedule PEP. It's time to make an update pass through PEP 0 too. Here are the following PEPs that are marked as "Active for Python 2.1", along with a small commentary about changing their status. PEP authors, please take a close look at your Python 2.1 PEPs and make any final revisions that are necessary. Let me know if you disagree with my proposed disposition of the PEP. Note: individual PEP owners should update their own PEPs; I will take care of noodging you and updating PEP 0. If you are unable to make commits to the PEPs, send the updated text to me and I'll commit them. I 42 pep-0042.txt Small Feature Requests Hylton The perennial PEP, this will be moved to the "Python 2.2 Current" category. It should be updated if necessary. S 205 pep-0205.txt Weak References Drake Fred should do an update pass to reflect Python 2.1 Reality (e.g. weakref.mapping()). This PEP should then be marked as Final and moved to the Finished PEPs category. I 226 pep-0226.txt Python 2.1 Release Schedule Hylton This PEP should get a final pass (no need for "tentative"s any more!), marked as Final and moved to the Finished category. S 227 pep-0227.txt Statically Nested Scopes Hylton Jeremy, please make sure this is up-to-date w.r.t. Python 2.1 Reality, then mark it as Final and I'll move it to the Finished category. S 229 pep-0229.txt Using Distutils to Build Python Kuchling Andrew, same deal with this PEP... S 233 pep-0233.txt Python Online Help Prescod What is up with this PEP? Progress on this seems to have stalled, so I propose marking it "Deferred" and moving it out of the active PEP category (to where, I'm not yet sure). S 235 pep-0235.txt Import on Case-Insensitive Platforms Peters I think this one's done, so it should be marked as Final and moved to the Finished PEPs category. Tim should make any final edits necessary. S 236 pep-0236.txt Back to the __future__ Peters Same for this one, Tim... S 243 pep-0243.txt Module Repository Upload Mechanism Reifschneider This isn't strictly tied to the Python 2.1 release, so I propose to simply shuffle it over to the "Active for Python 2.2" category. Cheers, -Barry

7 22

Re: Problem with SSL and socketmodule on Debian Potato?
by Martin v. Loewis 18 Apr '01

18 Apr '01

> Sometimes I wonder if going to setup.py to build modules was a > mistake. It would be easy to use autoconf to test of the > RAND_status function exists. OTOH, its probably not too hard to add > the smarts to setup.py. I don't think it was a mistake. First, even though Python had been using autoconf for years, nobody came up with a complete patch to autoconfiscate Modules/Setup, or define a different configuration mechanism. So using setup.py was an improvement over the status quo, even if not an improvement over some not-implemented technique - which might have never been implemented. Furthermore, as Marc-André points out: there is nothing that stops setup.py/distutils from using the same strategies as autoconf. Finally, in this specific case, I do think that the best strategy is to check for the version of OpenSSL. This is against autoconf philosophy (check for features, not for versions), but since the SSL support is tied to a specific implementation, rather than an API with competing implementations, checking the version does no harm and simplifies the configuration machinery. Regards, Martin

3 13