Mailman 3 May 2002 - Python-Dev

RE: [Python-Dev] True division in embedded Python
by Bjorn Pettersen 30 May '02

30 May '02

> From: Tim Peters [mailto:tim.one@comcast.net] > > [Bjorn Pettersen] [snip: me asking whether I should turn on true division] > Nevertheless, I recommend you not try to enable true division > now. Part of the joy of Python is sharing the many libraries > and extension modules people freely provide, and so far > nothing except the core distribution is tested with true > division enabled -- and even in the core, true division is > tested sporadically and lightly. You don't want to be a > pioneer here, unless advancing true division is your business <wink>. Nope, we just want the advantage of the best language around while still using our 900KLoc of C++ libraries <wink>. > That said, in 2.2.x, you can start using // *now* when you > intend flooring integer division. That's already > implemented. 5/3 will also produce 1 for now, but don't do > it -- do 5//3 instead. > > Also read the PEP: > > http://www.python.org/peps/pep-0238.html > > Guido has implemented some quite elaborate mechanisms to > help with the transition, and if you start using i//j now > you *should* have a very easy time when Python 3 changes > the rules (indeed, you shouldn't need any division changes > later, provided you use // now). The simplest of the > mechanisms is -Qwarn: And if I'm reading the source correctly all I would have to do when embedding Python would be to set Py_DivisionWarningFlag = 1? Thanks for the detailed input. Sincerely, Bjorn Pettersen NAREX Inc. 303.526.4000 ext. 312 303.526.5130 fax www.narex.com

2 1

Bug in PyNumber_InPlacePower implementation?
by Greg Ewing 30 May '02

30 May '02

I was looking at the implementation of PyNumber_InPlacePower last night, and something about it struck me as odd. It starts off: if (HASINPLACE(v) && v->ob_type->tp_as_number && v->ob_type->tp_as_number->nb_inplace_power != NULL) { return ternary_op(v, w, z, NB_SLOT(nb_inplace_power), "**="); Now, looking at ternary_op, it appears that under some circumstances this could call the nb_inplace_power slot of the second or third argument before trying the first one: if (slotv) { if (slotw && PyType_IsSubtype(w->ob_type, v->ob_type)) { x = slotw(v, w, z); i.e. if the 2nd argument is a subtype of the 1st, and it has an nb_inplace_power method, it will be called first. This looks wrong to me. Surely only the *first* argument should be checked for an inplace method when doing an inplace operation? That's the way it seems to be for all the other inplace operations. Is this a bug? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg(a)cosc.canterbury.ac.nz +--------------------------------------+

2 6

True division in embedded Python
by Bjorn Pettersen 30 May '02

30 May '02

We're currently in the process of adapting Python as the common scripting plug-in for all of our projects (and it's working great :-). We're standardizing on 2.2.1, and unless there is a pressing business need, we'll probably stay with that version for the next 18-24 months. My question is if it's intended for users to start using true division _now_? The reason I'm inclined to do so is that we're going to have snippets of Python code everywhere, including our libraries, disk files, and databases -- it would be a major undertaking to find and fix this later... My second question is how do you enable true division in embedded Python? I've read the documentation and I couldn't find anything appropriate... Any insight would be greatly appreciated. Sincerely, Bjorn Pettersen NAREX Inc. 303.526.4000 ext. 312 303.526.5130 fax www.narex.com

5 6

Re: [Python-Dev] Re: PendingDeprecationWarning
by Guido van Rossum 30 May '02

30 May '02

> Having both repr AND the peculiar `...` operator is another one of > those things which I find _really_ hard to explain without > handwaving and without sounding negative about Python, a language > about which I'm actually enthusiastic. Give yourself a bit of credit, Alex. Surely you can talk marketing-speak if you want to! FWIW, I consider `...` a historic wart and a failed experiment (even though I use it frequently myself). It appeared in a different form in ABC, where you could use `...` inside a string literal to do variable substitution (expression substitution actually). I think I found it to hard to implement that in the parser, so I decided that `...` would be a separate construct that you could embed in a string using regular string concatenation. But that means that the equivalent of "The sum of $a and $b is $c" would have to be written as "The sum of " + `a` + " and " + `b` + " is " + `c` which contains way too much interpunction. The other killer is that it uses repr() rather than str(). Python 0.0 only had `...`, it had neither str() not repr(). > I'd rather lose the `...` > (via pendingsilentdeprecation or whatever). +0 > As to repr itself, I'd be +0 on taking it out of the builtins, but > that's hardly a major issue, nor of course a realistic prospect. Why get rid of repr()? It's very useful. In error messages I often want to show an object relevant to the message, but if that object is (or may be) a string, I don't want newlines and other control characters in the string to mess up the formatting of the error message. repr() is perfect for that. > str is obviously quite a different kettle of fish -- it's a TYPE and > thus it cannot be substituted by whatever operator. It would also > be the natural way to put a format-with-whatever-number-base > functionality (2-arg str, just like parsing with arbitrary base is > 2-arg int -- perfect!). How useful is formatting numbers with arbitrary bases? I think decimal and hex cover all current use cases; even octal is mostly historic. (I still read octal more quickly than hex, but that's showing my age more than anything else -- I grew up around a CDC mainframe that dumped in octal.) --Guido van Rossum (home page: http://www.python.org/~guido/)

4 4

RE: [Python-Dev] True division in embedded Python
by Bjorn Pettersen 30 May '02

30 May '02

> From: Guido van Rossum [mailto:guido@python.org] [snip] > > We're standardizing on 2.2.1, and unless there is a > > pressing business need, we'll probably stay with > > that version for the next 18-24 months. > > Would you consider upgrading to 2.2.2 when it comes out, and > subsequent bugfix releases? The goal for those releases is > to make the upgrade 100% painless. We would probably consider it. What it comes down to is whether the new release is binary compatible (which I'm assuming it is), and if it included a bugfix that we found prudent to incorporate. Don't misunderstand me, it's not that we don't want to update -- the developers here would probably be quite happy to work on the latest and greatest -- updating just inherently takes time (money) and it's not very exciting work. We'd just rather spend our time on something that has a more direct revenue source :-) Thanks for answering my question about true division. Sincerely, Bjorn Pettersen NAREX Inc. 303.526.4000 ext. 312 303.526.5130 fax www.narex.com

2 1

Re: Stability and change
by Guido van Rossum 29 May '02

29 May '02

On c.p.py, Alex Martelli wrote: > Linus Thorvalds seems to have done pretty well with picking TWO > middle grounds -- two parallel tracks for Linux, "stable" and > "experimental". I'm moving the discussion to python-dev, since that's where I think it belongs. Personally, I hate the way Linux releases are numbered (I can never tell which one is stable and which one isn't). But I could get used to it if we used the micro version number to indicate stability -- in particular, 2.2 would be experimental, and 2.2.1 and following would be stable; 2.3 would be experimental, and 2.3.1 stable. This would require only a very slight change of policy: PEP 6 would have to be renamed from "Bug Fix Releases" to "Stable Releases". It wouldn't even have to loosen up its prohibitions; quoting: """ 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). """ This doesn't prevent us to evolve the standard library. It doesn't prohibit adding new built-in functions, although I'd be reluctant to do so. It would, however, require a big change in how we present new releases to the world. Currently, Once 2.x is out, anything running 2.(x-1) is labeled obsolete, or at least oldfashioned. That needs to change! The website needs to present at least two options: - Bleeding edge (e.g. 2.3 alpha, or 2.3 once it's out) - Stable (e.g. 2.2.1) There may be more options: Zope 2 currently requires 2.1.2 and will require 2.1.3 as soon as it's out; other people still swear by 1.5.2. (I don't think that the 1.6 and 2.0 lines are still popular.) --Guido van Rossum (home page: http://www.python.org/~guido/)

38 173

Re: [Python-Dev] Re: Stability and change
by Mats Wichmann 29 May '02

29 May '02

>Some help on this score may hopefully come from the recently >formed Python Business Forum. Among other tasks the PBF plans >to choose and exhaustively test certain Python releases, proposing >to Guido to designate those releases "Python in a tie" (I think GvR >came up with this specific monicker), then backporting fixes to them >&c to ensure the long period of stability typically desired by commercial >end-users (I think the target is 18-24 months vs the 6-8 months >target of Python minor releases). I apologize if this summary is in >any way imprecise -- http://pbf.nuxeo.org/ has authoritative info. As of today, there's a "real" website (well, it's the same contents): http://www.python-in-business.org/

2 1

Re: [Python-Dev] Re: Stability and change
by Guido van Rossum 29 May '02

29 May '02

> "Python in a tie" (I think GvR came up with this specific monicker) Actually I think it was Andy Robinson. I think he came up with it in a phone conversation we had about the PBF. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] Re: String module
by Guido van Rossum 29 May '02

29 May '02

Didn't want to let this useful suggestion miss the archives. ------- Forwarded Message Date: Wed, 29 May 2002 20:37:40 +0200 From: Finn Bock To: Guido van Rossum Subject: Re: [Python-Dev] Re: String module Guido van Rossum wrote: >... > digits -- isdigit() > > That leaves: > > hexdigits -- isxdigit() > octdigits -- isodigit() Java solves this task by a method that takes a radix argument and returns an int for the numeric value and -1 for characters that are invalid in the radix. http://java.sun.com/j2se/1.4/docs/api/java/lang/Character.html#digit(char,%… t) regards, finn ------- End of Forwarded Message

1 0

Re: [Python-Dev] deprecating string module?
by Tino Lange 29 May '02

29 May '02

Skip Montanaro wrote: > It has nothing to do with 11k worth of disk space and everything to do with > "there's one (best) way to do it". Hi! String method's are really nice! (By the way: I miss a length() method) But in some cases the old-school string module yields the more readable code. So the "one (best) way" is not always the clearest to read and understand. I cannot see/understand why it's the "best" way to write for example fromaddr = " ".join(map(lambda x: x[0] , email.Header.decode_header(fromaddr[1]))) with this (IMHO not intuitive empty string " ") instead of fromaddr = string.join(map(lambda x: x[0] , email.Header.decode_header(fromaddr[1]))) It's much cleaner to read and understand with string instead of " " - at least for beginners, or? Tino

9 16