Mailman 3 December 2002 - Python-Dev

deprecating APIs
by Neal Norwitz Dec. 19, 2002

Dec. 19, 2002

Are we still planning to provide a mechanism to declare APIs, etc as deprecated? I have this code added to pyport.h which works for gcc: /* Py_DEPRECATED(version) * Declare a macro or function deprecated. * Usage: * extern int old_var Py_DEPRECATED(2.3); * typedef int T1 Py_DEPRECATED(2.4); * extern int x() Py_DEPRECATED(2.5); */ #if defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ >= 1) #define Py_DEPRECATED(… [View More]

3 5

Mail to fredrik@pythonware.com bounces
by Guido van Rossum Dec. 19, 2002

Dec. 19, 2002

Has the effbot decided he's not interested in feedback any more? :-) --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Thu, 19 Dec 2002 09:41:46 -0500 From: Mail Delivery Subsystem <MAILER-DAEMON(a)odiug.zope.com> To: <guido(a)odiug.zope.com> Subject: Returned mail: see transcript for details This is a MIME-encapsulated message - --gBJEfko23279.1040308906/odiug.zope.com The original message was received at Thu, 19 Dec 2002 … [View More]09:39:59 -0500 from guido@localhost ----- The following addresses had permanent fatal errors ----- <fredrik(a)pythonware.com> (reason: 550 <fredrik(a)pythonware.com>... denied) ----- Transcript of session follows ----- ... while talking to mailgw.algonet.se.: >>> RCPT To:<fredrik(a)pythonware.com> <<< 550 <fredrik(a)pythonware.com>... denied 550 5.1.1 <fredrik(a)pythonware.com>... User unknown - --gBJEfko23279.1040308906/odiug.zope.com Content-Type: message/delivery-status Reporting-MTA: dns; odiug.zope.com Arrival-Date: Thu, 19 Dec 2002 09:39:59 -0500 Final-Recipient: RFC822; fredrik(a)pythonware.com Action: failed Status: 5.1.1 Remote-MTA: DNS; mailgw.algonet.se Diagnostic-Code: SMTP; 550 <fredrik(a)pythonware.com>... denied Last-Attempt-Date: Thu, 19 Dec 2002 09:41:03 -0500 - --gBJEfko23279.1040308906/odiug.zope.com Content-Type: message/rfc822 Return-Path: <guido(a)odiug.zope.com> Received: from guido (guido@localhost) by odiug.zope.com (8.11.0/8.11.0) with ESMTP id gBJEdwo23277; Thu, 19 Dec 2002 09:39:59 -0500 Message-Id: <200212191439.gBJEdwo23277(a)odiug.zope.com> To: "Fredrik Lundh" <fredrik(a)pythonware.com> cc: "Jack Jansen" <Jack.Jansen(a)oratrix.com>, "Samuele Pedroni" <pedronis(a)bluewin.ch>, "Moore, Paul" <Paul.Moore(a)atosorigin.com>, python-dev(a)python.org Subject: Re: [Python-Dev] Zipping Zope3 In-reply-to: Your message of "Thu, 19 Dec 2002 08:16:29 +0100." <005201c2a72e$8ec4c6b0$ced241d5@hagrid> References: <r01050400-1022-E00BBF9F12D811D7A7C4003065D5E7E4(a)[10.0.0.1]> <005201c2a72e$8ec4c6b0$ced241d5@hagrid> From: Guido van Rossum <guido(a)python.org> Date: Thu, 19 Dec 2002 09:39:58 -0500 Sender: guido(a)odiug.zope.com > some of us has been shipping deployment tools for many years, and > have a pretty good understanding of what optional extensions we and > our customers have needed over the years... Would you mind summarizing what you think is needed? - --Guido van Rossum (home page: http://www.python.org/~guido/) - --gBJEfko23279.1040308906/odiug.zope.com-- ------- End of Forwarded Message [View Less]

1 0

Re: [Python-Dev] Zipping Zope3
by Moore, Paul Dec. 19, 2002

Dec. 19, 2002

> FWIW, <http://www.python.org/sf/652586> has been > enhanced with the mod.__importer__ feature. ... and I've just added a comment expressing some concerns. I think we need a PEP about now, pinning down the "abstract" import hook interface. What zipimport does risks turning into a de-facto requirement, before we have any other hooks to compare with. My specific issue is with get_data, which is totally unneeded for the import protocol itself (although it does solve real, related … [View More]

6 14

RE: [Python-Dev] Zipping Zope3
by Moore, Paul Dec. 19, 2002

Dec. 19, 2002

From: Just van Rossum [mailto:just@letterror.com] > Btw. what you want is _possible_ with the current zipimporter > object: there's zi.get_data(filename), and you can inspect the > "files" attribute (a dict mapping filenames to index info; it's > an internal attribute, so I might rename it to _files). Just to clarify this point: you can subclass the existing zipimport.zipimporter class and add any extra methods you want. Then, by replacing zipimporter in sys.path_hooks with your … [View More]

2 1

Adding decimal (aka FixedPoint) numbers to Python
by Michael McLay Dec. 18, 2002

Dec. 18, 2002

sf/653938I is a patch to integrate the fixedpoint module, that was created by Tim Peters, into Python as a first class object. That is, the patch adds this new number type so that it has direct syntax support like float, int, long, str., etc. within the interpreter. I use Tim's module to implement the type. This limits the patch to a small bit of code that adds the a syntax interface to this module. Syntax recognition for the new number format required a change to Parser/tokenizer.c and … [View More]to Python/compile.c. This patch allows the new decimal type (I renamed the FixedPoint type to decimal in the fixedpoint.py file because the name is shorter and it is sufficient to distinguish the type from a binary float.) to be entered as a literal that is similar to a long, int, or float. The new syntax works as follows: >>> 12.00d 12.00d >>> .012d 0.012d >>> 1d 1.d >>> str(1.003d) '1.003' As you can see from the example, the default precision for decimal literals are determined by the precision entered expressed in the literal. The patch also adds glue to Python/bltinmodule.c to create a builtin decimal() function. This builtin decimal (Formally FixedPoint) function invokes the constructor of the Python implementation of the decimal class defined in the fixedpoint module. The implementation follows the familiar pattern for adding special builtin functions, much like the implementation of apply and abs. It does not follow the typical method for adding built in types. That would require a more invasive patch. The builtin decimal function works as follows: >>> decimal(1.333) 1.33d >>> decimal(1.333,4) 1.3330d >>> decimal(400,2) 400.00d The semantics of the precision parameter may be incorrect because it is only addressing the precision of the fraction part of the number. Shouldn't it reflect the number of significant digits? If that were the case then the following would have been the result: >>> decimal(400,2) 4.0e2d This problem is more noticable when exponents are large relative to the number of significant digits. For instance: >>> 40.e3d 40000.d The result should have been 40.e3d, not 40000. This implies more precision than is declared by the constant. As it currently is implemented the type pads with zeros on the integer side of the decimal point, whic implies more accuracy in the number than is true. I ran into this problem when I tried to implement the automatic conversion of string number values to decimal representation for numbers in 'e' format. >>> 3.03e5d 303000.00d The representation is incorrect. It should have returned 3.03e5d but it padded the result with bogus zeros. For this first cut at a new decimal type I am primarily interested in investigating the semantics of the new native decimal number type in Python. This type will be useful to bankers, accountants, and newbies. The backend implementation could be replaced with a C implementation without affecting the Python language semantics. The approach used in this patch makes it very easy to experiment with changes to the semantics because all of the experimentation can be done by changing the code in Lib/fixedpoint.py. The compiled wrapper doesn't have to be modified and recompiled. Unit testing so far just reuses the _test function in the fixedpoint.py module. Since I am not sure which way to go with the semantic interpretation of precision I decided to post the patch before making a significant change to fixedpoint.py. Some feedback on the interpretation of precision would be appreciated. Documentation: The following needs to be added to section 2.1 of the library reference manual: decimal(value, precision) Convert a string or a number to fixed point decimal number. If the argument is a string, it must contain a possibly signed decimal or floating point number, possibly embedded in whitespace. The precision parameter will be ignored on string values. The precision will be set based on the number of significant digits. Otherwise, the argument may be a plain or long integer or a floating point number, and a decimal number with the same value ( the precision attribute will set the precision of the fraction roundoff) is returned. Section 3.1.1 of the tutorial will add a brief description of decimal number usage after the description of floating point: There is full support for floating point; operators with mixed type operands convert the integer operand to floating point: >>> 3 * 3.75 / 1.5 7.5 >>> 7.0 / 2 3.5 Python also supports fixed point decimal numbers. These numbers do not suffer from the somewhat random roundoff errors that can occur with binary floating point numbers. A decimal number is created by adding a 'd' or 'D' suffix to a number: >>> 3.3d + 3d 6.3d >>> 3.3d + 3.03 6.3d >>> 3.3d + decimal(3.03,3) 6.330d >>> decimal(1.1, 16) 1.1000000000000001d >>> The builtin decimal constructor provides a means for converting float and int types to decimal types. Since floats are approximations of decimal floating point numbers there are often roundoff errors introduced by using floats. (The 1 in the last place of the conversion of 1.1 with 16 digits is a binary round off error.) For this reason the decimal function requires the specification of precision when converting a float to a decimal. This allows the significant digits of the number to be specified. (Accountants and bankers love this because it allows them to balance the books without pennies being lost due to the use of binary numbers.) >>> 3.3d/2 1.6d Note that in the example above the expression 3.3d/2 returned 1.6d. The rounding scheme for Python decimals uses "banking" rounding rules. With floating point numbers the result would have been as follows: >>> 3.3/2 1.6499999999999999 So as you can see the banking rules round off the .04999999999 portion of the number and calls it a an even 1.6. [View Less]

13 26

test_datetime fails on alpha
by Neal Norwitz Dec. 18, 2002

Dec. 18, 2002

I used the alpha in the SF compile to verify the bug. The problem was originally reported on the snake-farm from the test suite. nnorwitz@usf-cf-alpha-linux-1:~/python/dist/src$ ./python Python 2.3a0 (#15, Dec 18 2002, 15:52:53) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import timedelta >>> timedelta(1, 7, 31) datetime.timedelta(1, 7, 31) >>> _.days, _.seconds, _.… [View More]

3 3

[ 654866 ] pickle and cPickle not equivalent
by Patrick K. O'Brien Dec. 18, 2002

Dec. 18, 2002

I'd like to call attention to a bug report I just submitted to SF concerning a potentially serious problem with the c-version of pickle. In short, I think I discovered a situation where cPickle is not doing the right thing in terms of storing a reference to a previously pickled class instance (using Pickler, of course). It looks like its doing a put of a new instance, then a get of the original instances dictionary, rather than a get of the original instance. On the other hand, pickle … [View More]

6 16

Re: [Python-Dev] Zipping Zope3
by Moore, Paul Dec. 18, 2002

Dec. 18, 2002

Fredrik Lundh said: > And if we're making get_data part of the protocol, can we > please have an optional get_module_names/list_modules/listdir > method too? This is why I'm concerned about get_data. It isn't necessarily enough - we've already had people ask about get_module_names and stat. Who knows what else could be useful? I suspect that some things simply aren't going to be noticed until the new import hooks get actually used "in the wild". At the moment, this issue is in the "… [View More]

1 0

RE: [Python-Dev] Zipping Zope3
by Moore, Paul Dec. 18, 2002

Dec. 18, 2002

From: Guido van Rossum [mailto:guido@python.org] >> My specific issue is with get_data, which is totally unneeded >> for the import protocol itself (although it does solve real, >> related issues). I don't think it should be a requirement of >> the import hook API. Documenting it as an optional interface >> which hooks may choose to support may be reasonable, though. > I like get_data(). The caller should always be prepared for > it to return an error (how … [View More]

1 0

Re: [Python-checkins] python/dist/src setup.py,1.126,1.127
by Michael Hudson Dec. 18, 2002

Dec. 18, 2002

Andrew Kuchling <akuchlin(a)mems-exchange.org> writes: > On Tue, Dec 17, 2002 at 08:47:20AM -0800, mwh(a)users.sourceforge.net wrote: > >+ # Do exactly what install_lib does but make sure correct access modes get > >+ # set on installed directories and files. All installed files with get > >+ # mode 644 unless they are a shared library in which case they will get > >+ # mode 755. All installed directories will get mode 755. > > If … [View More]

1 0