The bug is in Lib/xml/__init__.py __version__ = "1.9".split()[1] I don't know what it was supposed to be, but .split() without an argument splits on whitespace. best guess is "1.9".split('.') ?? -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
[Moshe Zadka]
The bug is in Lib/xml/__init__.py
__version__ = "1.9".split()[1]
Believe me, we would not have shipped 2.1b2 if it failed any of the std tests (and I ran the whole suite 8 ways: with and without nuking all .pyc/.pyo files first, with and without -O, and under release and debug builds).
I don't know what it was supposed to be, but .split() without an argument splits on whitespace. best guess is "1.9".split('.') ??
On my box that line is: __version__ = "$Revision: 1.9 $".split()[1] So this is this some CVS retrieval screwup?
On Sat, 24 Mar 2001 02:52:28 -0500, "Tim Peters" <tim.one@home.com> wrote:
Probably. But nobody cares about your machine <1.9 wink> In the Py2.1b2 you shipped, the line says ''' __version__ = "1.9".split()[1] ''' It's line 18. That, or someone managed to crack one of the routers from SF to me. should-we-start-signing-our-releases-ly y'rs, Z. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
No, in the 2.1b2 I installed on my machine, from the installer I sucked down from SourceForge, the line is what I said it was: __version__ = "$Revision: 1.9 $".split()[1] So you're talking about something else, but I don't know what ... Ah, OK! It's that silly source tarball, Python-2.1b2.tgz. I just sucked that down from SF, and *that* does have the damaged line just as you say (in Lib/xml/__init__.py). I guess we're going to have to wait for Guido to wake up and explain how this got hosed ... in the meantime, switch to Windows and use a real installer <wink>.
This must be because I used "cvs export -kv" to create the tarball this time. This may warrant a release update :-( --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@digicool.com> writes:
>> The bug is in Lib/xml/__init__.py __version__ = >> "1.9".split()[1] I don't know what it was supposed to be, but >> .split() without an argument splits on whitespace. best guess >> is "1.9".split('.') ?? GvR> This must be because I used "cvs export -kv" to create the GvR> tarball this time. This may warrant a release update :-( Using "cvs export -kv" is a Good Idea for a release! That's because if others import the release into their own CVS, or pull the file into an unrelated CVS repository, your revision numbers are preserved. I haven't followed this thread very carefully, but isn't there a better way to fix the problem rather than stop using -kv (I'm not sure that's what Guido has in mind)? -Barry
I know, but I doubt that htis is used much any more. I haven't had any complaints about this, and I know that we didn't use -kv for previous releases (I checked 1.5.2, 1.6 and 2.0).
Well, if we only us -kv to create the final tarball and installer, and everybody else uses just the CVS version, the problem is that we don't have enough testing time in. Given that most code is written to deal with "$Revision: 1.9 $", why bother breaking it? --Guido van Rossum (home page: http://www.python.org/~guido/)
OK, here's what I've done. I've done a new cvs export of the r21b2 tag, this time *without* specifying -kv. I've tarred it up and uploaded it to SF and python.org. The new tarball is called Python-2.1b2a.tgz to distinguish it from the broken one. I've removed the old, broken tarball, and added a note to the python.org/2.1/ page about the new tarball. Background: "cvs export -kv" changes all CVS version insertions from "$Release: 1.9$" to "1.9". (It affects other CVS inserts too.) This is so that the versions don't get changed when someone else incorporates it into their own CVS tree, which used to be a common usage pattern. The question is, should we bother to make the code robust under releases with -kv or not? I used to write code that dealt with the fact that __version__ could be either "$Release: 1.9$" or "1.9", but clearly that bit of arcane knowledge got lost. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sat, 24 Mar 2001 08:33:59 -0500, Guido van Rossum <guido@digicool.com> wrote:
OK, here's what I've done. I've done a new cvs export of the r21b2 tag, this time *without* specifying -kv.
This was clearly the solution to *this* problem ;-) "No code changes in CVS between the same release" sounds like a good rule.
The question is, should we bother to make the code robust under releases with -kv or not?
Yes. People *will* be incorporating Python into their own CVS trees. FreeBSD does it with ports, and Debian are thinking of moving in this direction, and some Debian maintainers already do that with upstream packages -- Python might be handled like that too. The only problem I see if that we need to run the test-suite with a -kv'less export. Fine, this should be part of the release procedure. I just went through the core grepping for '$Revision' and it seems this is the only place this happens -- all the other places either put the default version (RCS cruft and all), or are smart about handling it. Since "smart" means just __version__ = [part for part in "$Revision$".split() if '$' not in part][0] We can just mandate that, and be safe. However, whatever we do the Windows build and the UNIX build must be the same. I think it should be possible to build the Windows version from the .tgz and that is what (IMHO) should happen, instead of Tim and Guido exporting from the CVS independantly. This would stop problems like the one Tim and I had this (my time) morning. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
I haven't seen *any* complaints about this, so is it possible that they don't mind having the $Revision: ... $ strings in there?
Hm. This means that the -kv version gets *much* less testing than the regular checkout version. I've done this before in the past with other projects and I remember that the bugs produced by this kind of error are very subtle and not always caught by the test suite. So I'm skeptical.
This is less typing, and no more obscure, and seems to work just as well given that the only two inputs are "$Revision: 1.9 $" or "1.9": __version__ = "$Revision: 1.9 $".split()[-2:][0]
However, whatever we do the Windows build and the UNIX build must be the same.
That's hard right there -- we currently build the Windows compiler right out of the CVS tree.
Who are you telling us how to work? --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sat, 24 Mar 2001 10:34:13 -0500, Guido van Rossum <guido@digicool.com> wrote:
I haven't seen *any* complaints about this, so is it possible that they don't mind having the $Revision: ... $ strings in there?
I don't know. Like I said, my feelings about that are not very strong...
I said "I think" and "IMHO", so I'm covered. I was only giving suggestions. You're free to ignore them if you think my opinion is without merit. I happen to think otherwise <8am wink>, but you're the BDFL and I'm not. Are you saying it's not important to you that the .py's in Windows and UNIX are the same? I think it should be a priority, given that when people complain about OS-independant problems, they often neglect to mention the OS. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
[Moshe]
Hmm. Unless it's in a *comment*, I expect most uses are dubious. Clear example, from the new Lib/unittest.py: __version__ = "$Revision: 1.2 $"[11:-2] Presumably that's yielding an empty string under the new tarball release. One of a dozen fuzzy examples, from pickle.py: __version__ = "$Revision: 1.46 $" # Code version The module makes no other use of this, and since it's not in a comment I have to presume that the author *intended* clients to access pickle.__version__ directly. But, if so, they've been getting the $Revision business for years, so changing the released format now could break users' code.
*Sounds* good <wink>.
Ya, sounds good too. A few things against it: The serialization would add hours to the release process, in part because I get a lot of testing done now, on the Python I install *from* the Windows installer I build, while the other guys are finishing the .tgz business (note that Guido doesn't similarly run tests on a Python built from the tarball, else he would have caught this problem before you!). Also in part because the Windows installer is not a simple packaging of the source tree: the Windows version also ships with pre-compiled components for Tcl/Tk, zlib, bsddb and pyexpat. The source for that stuff doesn't come in the tarball; it has to be sprinkled "by hand" into the source tree. The last gets back to Guido's point, which is also a good one: if the Windows release gets built from a tree I've used for the very first time a couple hours before the release, the higher the odds that a process screwup gets overlooked. To date, there have been no "process bugs" in the Windows build process, and I'd be loathe to give that up. Building from the tree I use every day is ... reassuring. At heart, I don't much like the idea of using source revision numbers as code version numbers anyway -- "New and Improved! Version 1.73 stripped a trailing space from line 239!" <wink>. more-info-than-anyone-needs-to-know-ly y'rs - tim
"GvR" == Guido van Rossum <guido@digicool.com> writes:
GvR> The question is, should we bother to make the code robust GvR> under releases with -kv or not? Yes. GvR> I used to write code that dealt with the fact that GvR> __version__ could be either "$Release: 1.9$" or "1.9", but GvR> clearly that bit of arcane knowledge got lost. Time to re-educate then! On the one hand, I personally try to avoid assigning __version__ from a CVS revision number because I'm usually interested in a more confederated release. I.e. mimelib 0.2 as opposed to mimelib/mimelib/__init__.py revision 1.4. If you want the CVS revision of the file to be visible in the file, use a different global variable, or stick it in a comment and don't worry about sucking out just the numbers. OTOH, I understand this is a convenient way to not have to munge version numbers so lots of people do it (I guess). Oh, I see there are other followups to this thread, so I'll shut up now. I think Guido's split() idiom is the Right Thing To Do; it works with branch CVS numbers too:
-Barry
[Moshe Zadka]
The bug is in Lib/xml/__init__.py
__version__ = "1.9".split()[1]
Believe me, we would not have shipped 2.1b2 if it failed any of the std tests (and I ran the whole suite 8 ways: with and without nuking all .pyc/.pyo files first, with and without -O, and under release and debug builds).
I don't know what it was supposed to be, but .split() without an argument splits on whitespace. best guess is "1.9".split('.') ??
On my box that line is: __version__ = "$Revision: 1.9 $".split()[1] So this is this some CVS retrieval screwup?
On Sat, 24 Mar 2001 02:52:28 -0500, "Tim Peters" <tim.one@home.com> wrote:
Probably. But nobody cares about your machine <1.9 wink> In the Py2.1b2 you shipped, the line says ''' __version__ = "1.9".split()[1] ''' It's line 18. That, or someone managed to crack one of the routers from SF to me. should-we-start-signing-our-releases-ly y'rs, Z. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
No, in the 2.1b2 I installed on my machine, from the installer I sucked down from SourceForge, the line is what I said it was: __version__ = "$Revision: 1.9 $".split()[1] So you're talking about something else, but I don't know what ... Ah, OK! It's that silly source tarball, Python-2.1b2.tgz. I just sucked that down from SF, and *that* does have the damaged line just as you say (in Lib/xml/__init__.py). I guess we're going to have to wait for Guido to wake up and explain how this got hosed ... in the meantime, switch to Windows and use a real installer <wink>.
This must be because I used "cvs export -kv" to create the tarball this time. This may warrant a release update :-( --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@digicool.com> writes:
>> The bug is in Lib/xml/__init__.py __version__ = >> "1.9".split()[1] I don't know what it was supposed to be, but >> .split() without an argument splits on whitespace. best guess >> is "1.9".split('.') ?? GvR> This must be because I used "cvs export -kv" to create the GvR> tarball this time. This may warrant a release update :-( Using "cvs export -kv" is a Good Idea for a release! That's because if others import the release into their own CVS, or pull the file into an unrelated CVS repository, your revision numbers are preserved. I haven't followed this thread very carefully, but isn't there a better way to fix the problem rather than stop using -kv (I'm not sure that's what Guido has in mind)? -Barry
I know, but I doubt that htis is used much any more. I haven't had any complaints about this, and I know that we didn't use -kv for previous releases (I checked 1.5.2, 1.6 and 2.0).
Well, if we only us -kv to create the final tarball and installer, and everybody else uses just the CVS version, the problem is that we don't have enough testing time in. Given that most code is written to deal with "$Revision: 1.9 $", why bother breaking it? --Guido van Rossum (home page: http://www.python.org/~guido/)
OK, here's what I've done. I've done a new cvs export of the r21b2 tag, this time *without* specifying -kv. I've tarred it up and uploaded it to SF and python.org. The new tarball is called Python-2.1b2a.tgz to distinguish it from the broken one. I've removed the old, broken tarball, and added a note to the python.org/2.1/ page about the new tarball. Background: "cvs export -kv" changes all CVS version insertions from "$Release: 1.9$" to "1.9". (It affects other CVS inserts too.) This is so that the versions don't get changed when someone else incorporates it into their own CVS tree, which used to be a common usage pattern. The question is, should we bother to make the code robust under releases with -kv or not? I used to write code that dealt with the fact that __version__ could be either "$Release: 1.9$" or "1.9", but clearly that bit of arcane knowledge got lost. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sat, 24 Mar 2001 08:33:59 -0500, Guido van Rossum <guido@digicool.com> wrote:
OK, here's what I've done. I've done a new cvs export of the r21b2 tag, this time *without* specifying -kv.
This was clearly the solution to *this* problem ;-) "No code changes in CVS between the same release" sounds like a good rule.
The question is, should we bother to make the code robust under releases with -kv or not?
Yes. People *will* be incorporating Python into their own CVS trees. FreeBSD does it with ports, and Debian are thinking of moving in this direction, and some Debian maintainers already do that with upstream packages -- Python might be handled like that too. The only problem I see if that we need to run the test-suite with a -kv'less export. Fine, this should be part of the release procedure. I just went through the core grepping for '$Revision' and it seems this is the only place this happens -- all the other places either put the default version (RCS cruft and all), or are smart about handling it. Since "smart" means just __version__ = [part for part in "$Revision$".split() if '$' not in part][0] We can just mandate that, and be safe. However, whatever we do the Windows build and the UNIX build must be the same. I think it should be possible to build the Windows version from the .tgz and that is what (IMHO) should happen, instead of Tim and Guido exporting from the CVS independantly. This would stop problems like the one Tim and I had this (my time) morning. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
I haven't seen *any* complaints about this, so is it possible that they don't mind having the $Revision: ... $ strings in there?
Hm. This means that the -kv version gets *much* less testing than the regular checkout version. I've done this before in the past with other projects and I remember that the bugs produced by this kind of error are very subtle and not always caught by the test suite. So I'm skeptical.
This is less typing, and no more obscure, and seems to work just as well given that the only two inputs are "$Revision: 1.9 $" or "1.9": __version__ = "$Revision: 1.9 $".split()[-2:][0]
However, whatever we do the Windows build and the UNIX build must be the same.
That's hard right there -- we currently build the Windows compiler right out of the CVS tree.
Who are you telling us how to work? --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sat, 24 Mar 2001 10:34:13 -0500, Guido van Rossum <guido@digicool.com> wrote:
I haven't seen *any* complaints about this, so is it possible that they don't mind having the $Revision: ... $ strings in there?
I don't know. Like I said, my feelings about that are not very strong...
I said "I think" and "IMHO", so I'm covered. I was only giving suggestions. You're free to ignore them if you think my opinion is without merit. I happen to think otherwise <8am wink>, but you're the BDFL and I'm not. Are you saying it's not important to you that the .py's in Windows and UNIX are the same? I think it should be a priority, given that when people complain about OS-independant problems, they often neglect to mention the OS. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
[Moshe]
Hmm. Unless it's in a *comment*, I expect most uses are dubious. Clear example, from the new Lib/unittest.py: __version__ = "$Revision: 1.2 $"[11:-2] Presumably that's yielding an empty string under the new tarball release. One of a dozen fuzzy examples, from pickle.py: __version__ = "$Revision: 1.46 $" # Code version The module makes no other use of this, and since it's not in a comment I have to presume that the author *intended* clients to access pickle.__version__ directly. But, if so, they've been getting the $Revision business for years, so changing the released format now could break users' code.
*Sounds* good <wink>.
Ya, sounds good too. A few things against it: The serialization would add hours to the release process, in part because I get a lot of testing done now, on the Python I install *from* the Windows installer I build, while the other guys are finishing the .tgz business (note that Guido doesn't similarly run tests on a Python built from the tarball, else he would have caught this problem before you!). Also in part because the Windows installer is not a simple packaging of the source tree: the Windows version also ships with pre-compiled components for Tcl/Tk, zlib, bsddb and pyexpat. The source for that stuff doesn't come in the tarball; it has to be sprinkled "by hand" into the source tree. The last gets back to Guido's point, which is also a good one: if the Windows release gets built from a tree I've used for the very first time a couple hours before the release, the higher the odds that a process screwup gets overlooked. To date, there have been no "process bugs" in the Windows build process, and I'd be loathe to give that up. Building from the tree I use every day is ... reassuring. At heart, I don't much like the idea of using source revision numbers as code version numbers anyway -- "New and Improved! Version 1.73 stripped a trailing space from line 239!" <wink>. more-info-than-anyone-needs-to-know-ly y'rs - tim
"GvR" == Guido van Rossum <guido@digicool.com> writes:
GvR> The question is, should we bother to make the code robust GvR> under releases with -kv or not? Yes. GvR> I used to write code that dealt with the fact that GvR> __version__ could be either "$Release: 1.9$" or "1.9", but GvR> clearly that bit of arcane knowledge got lost. Time to re-educate then! On the one hand, I personally try to avoid assigning __version__ from a CVS revision number because I'm usually interested in a more confederated release. I.e. mimelib 0.2 as opposed to mimelib/mimelib/__init__.py revision 1.4. If you want the CVS revision of the file to be visible in the file, use a different global variable, or stick it in a comment and don't worry about sucking out just the numbers. OTOH, I understand this is a convenient way to not have to munge version numbers so lots of people do it (I guess). Oh, I see there are other followups to this thread, so I'll shut up now. I think Guido's split() idiom is the Right Thing To Do; it works with branch CVS numbers too:
-Barry
participants (4)
-
barry＠digicool.com -
Guido van Rossum -
Moshe Zadka -
Tim Peters