Mailman 3 December 2002 - Python-Dev

deprecating APIs
by Neal Norwitz 19 Dec '02

19 Dec '02

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(VERSION_UNUSED) __attribute__((__deprecated__)) #else #define Py_DEPRECATED(VERSION_UNUSED) #endif The version number is not necessary. It is only for documentation. I don't know how to support other compilers. We could add Py_USE_DEPRECATED and/or Py_HIDE_DEPRECATED for providing/hiding access to deprecated features. #ifdef Py_USE_DEPRECATED #define Py_SOME_DEPRECATED_MACRO #endif or #ifndef Py_HIDE_DEPRECATED #define Py_SOME_DEPRECATED_MACRO #endif Unfortunately, the Py_DEPRECATED macro doesn't work with macros, so we would have to use Py_USE_DEPRECATED/Py_HIDE_DEPRECATED around deprecated macros. Neal

3 5

Mail to fredrik@pythonware.com bounces
by Guido van Rossum 19 Dec '02

19 Dec '02

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 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

1 0

Re: [Python-Dev] Zipping Zope3
by Moore, Paul 19 Dec '02

19 Dec '02

> 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 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 can construct theoretical use cases where it could be hard to support get_data. But I don't like theoretical use cases any more than anyone else - I'm just suggesting that we wait for practical experience before adding anything more to what is currently a nice, clean, and simple API] Paul. PS If Just doesn't want to, I'll volunteer to write such a PEP. But be warned, if I do, I'll probably indulge my instincts and make the API as minimal as I can get away with (I *like* the iterator interface :-))

6 14

RE: [Python-Dev] Zipping Zope3
by Moore, Paul 19 Dec '02

19 Dec '02

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 subclass, you transparently get your extra functionality. I'm not saying that this is the ultimate solution, but it gives us an opportunity to experiment before committing to a specific implementation in the core. Paul.

2 1

Adding decimal (aka FixedPoint) numbers to Python
by Michael McLay 18 Dec '02

18 Dec '02

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 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.

13 26

test_datetime fails on alpha
by Neal Norwitz 18 Dec '02

18 Dec '02

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, _.microseconds (30064771073, 133143986183, 31) Neal

3 3

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

18 Dec '02

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 does the right thing. I think this is a pretty serious problem, but I'm out of my league when it comes to debugging the c-version of pickle. I'm also basing my assessment on a minimal understanding of the pickle source code combined with looking at two pickle files, one created using pickle, the other using cPickle, with no other changes to the program that produced them. I understand that cosmetic differences are to be expected. But the difference I see is more substantial. I attached the two pickle files to the SF bug report, but I can't tell if they got through so I'm attaching them here as well. If anyone can help track this down, I'd really appreciate it. If more detail is needed, or a simple code example would help, I'll be happy to do that. Thanks. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------

6 16

Re: [Python-Dev] Zipping Zope3
by Moore, Paul 18 Dec '02

18 Dec '02

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 "Open Issues" section of the (not yet released) PEP. Paul

1 0

RE: [Python-Dev] Zipping Zope3
by Moore, Paul 18 Dec '02

18 Dec '02

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 does it do that? raise what? or > return None? that should be specified!). An importer that > can't do this should implement a version that always reports > an error. This is much easier on the client than calling > hasattr(importer, 'get_data') first or catching AttributeError. I don't have a big problem with get_data(). But currently, it's badly under-specified. You mention the question of how it returns errors (not just "can't do this" - what about "file not found"?). There's also the question of the exact format of the "filename". Should it be like a module name (dotted)? This has the advantage of matching how the rest of the importer logic works, but the disadvantage of being unnatural to the user. Should it be a pseudo-path format? This has the disadvantage of being platform specific (the zipimporter already jumps through some hoops to convert os.sep/os.altsep into forward slashes (which is what the zip format uses), and other importers may have even more work to do). Or something else? Also is it a method of the object that implements load_module, or the one that implements find_module? I could argue either. I can code things either way. But I don't have enough "real world" experience to say which is best in practice. Paul.

1 0

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

18 Dec '02

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 install_lib is getting the mode wrong, shouldn't this fix be applied to > install_lib instead of just the setup.py? Probably. Do you have the time/inclination to work out any possible backwards compatibility interactions, where it needs to go, etc.? If you do, be my guest. I don't, and neither did the guy who wrote the patch. Cheers, M. -- Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jeff Raskin

1 0