Mailing List Archive

Guido van Rossum wrote:
>
> I can't say how disappointed I am: at the very last moment I have
> heard that I am not allowed to release Python 2.0b1 on July 1 as
> planned. Some last-minute issues have come up regarding the licensing
> from CNRI. BeOpen is going to resolve these issues as soon as
> possible, but it could be weeks...

Doh.
The premature 2.0 release excitement died prematurely <wink>

>
> In the mean time, I thank everybody who worked very hard to make this
> release a success. We will continue to work on the SourceForge CVS
> repository as before. There will be a 2.0 release as soon as
> possible!

Maybe it would be good to think about and define a short-term plan of
action, given that we'll have a "major" release and that now we have
some more time, cf. the previous discussion on the subject.

--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

guido wrote:


> I can't say how disappointed I am: at the very last moment I have
> heard that I am not allowed to release Python 2.0b1 on July 1 as
> planned. Some last-minute issues have come up regarding the licensing
> from CNRI. BeOpen is going to resolve these issues as soon as
> possible, but it could be weeks...

what's the legal status of the material on the SF site.

can people download and redistribute snapshots of the CVS repository,
or is it in some kind of legal limbo at this time?

</F>

On Fri, Jun 30, 2000 at 10:35:33PM -0500, Guido van Rossum wrote:
>I can't say how disappointed I am: at the very last moment I have
>heard that I am not allowed to release Python 2.0b1 on July 1 as
>planned. Some last-minute issues have come up regarding the licensing

I'm not convinced this delay is wholly a bad thing. Did Barry ever
track down the mysterious crashes he was seeing from running the test
suite? And it's more time to experiment with the garbage collection,
hunt for SRE bugs, and so forth.

--amk

> I'm not convinced this delay is wholly a bad thing. Did Barry ever
> track down the mysterious crashes he was seeing from running the test
> suite? And it's more time to experiment with the garbage collection,
> hunt for SRE bugs, and so forth.

But that's what beta releases are for, right? The result now is that
fewer people will try out the code than if it were released today, and
the final release will undoubtedly be delayed again.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)

Guido van Rossum wrote:
>
> > I'm not convinced this delay is wholly a bad thing. Did Barry ever
> > track down the mysterious crashes he was seeing from running the test
> > suite? And it's more time to experiment with the garbage collection,
> > hunt for SRE bugs, and so forth.
>
> But that's what beta releases are for, right? The result now is that
> fewer people will try out the code than if it were released today, and
> the final release will undoubtedly be delayed again.

Guido, what about reverting the version number to 2.0a3 ?
We're still not in a beta stage, but there *is* a new version ready,
which, if not beta, should be an alpha. We're used to see the version
bumped a day or two before the release.

--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

>>>>> "AK" == Andrew Kuchling <akuchlin@cnri.reston.va.us> writes:

AK> I'm not convinced this delay is wholly a bad thing. Did Barry
AK> ever track down the mysterious crashes he was seeing from
AK> running the test suite?

No, and Purify didn't help, although it did identify a couple of small
memory leaks. Nothing more serious than that. One possible source of
discrepancy though is that the machine I ran the tests on apparently
didn't have enough memory (at 256MB!) to run the entire regrtest under
a Purify'd Python. I'm going to continue looking though.

-Barry

AK> I'm not convinced this delay is wholly a bad thing. Did Barry ever
AK> track down the mysterious crashes he was seeing from running the
AK> test suite?

BAW> No, and Purify didn't help, although it did identify a couple of
BAW> small memory leaks. Nothing more serious than that. One possible
BAW> source of discrepancy though is that the machine I ran the tests on
BAW> apparently didn't have enough memory (at 256MB!) to run the entire
BAW> regrtest under a Purify'd Python. I'm going to continue looking
BAW> though.

My guess is that -tt triggered a SyntaxError (maybe we should create an
IndentationError that is a subclass of SyntaxError?) the .pyc file didn't
get generated, but the exception was caught by regrtest and execution
continued. That would have caused any test that tried to import the
tab-challenged file(s) to fail, right? Would that have been sufficient to
provoke the symptoms we saw?

--
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille
O'Neal said: "He's got the rings. I listen to the man with the rings."

Skip Montanaro <skip@mojam.com>:
> My guess is that -tt triggered a SyntaxError (maybe we should create an
> IndentationError that is a subclass of SyntaxError?)

+1!
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The United States is in no way founded upon the Christian religion
-- George Washington & John Adams, in a diplomatic message to Malta.

Resending...

Subject: Re: [Python-Dev] Sorry. No Release.
To: guido@beopen.com (Guido van Rossum)
Date: Sat, 1 Jul 2000 16:23:16 +0200 (CEST)
Cc: python-dev@python.org

Guido van Rossum wrote:
>
> > I'm not convinced this delay is wholly a bad thing. Did Barry ever
> > track down the mysterious crashes he was seeing from running the test
> > suite? And it's more time to experiment with the garbage collection,
> > hunt for SRE bugs, and so forth.
>
> But that's what beta releases are for, right? The result now is that
> fewer people will try out the code than if it were released today, and
> the final release will undoubtedly be delayed again.

Guido, what about reverting the version number to 2.0a3 ?
We're still not in a beta stage, but there *is* a new version ready,
which, if not beta, should be an alpha. We're used to see the version
bumped a day or two before the release.

--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

Skip Montanaro <skip@mojam.com>:
> My guess is that -tt triggered a SyntaxError (maybe we should create an
> IndentationError that is a subclass of SyntaxError?)

Yes! +1!


-- ?!ng

Skip Montanaro wrote:
>
> ...
>
> My guess is that -tt triggered a SyntaxError (maybe we should create an
> IndentationError that is a subclass of SyntaxError?)

+1

That would be great for newbies!

--
Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it
gave rise made modern science possible, but it was the algorithm that
made the modern world possible.
- The Advent of the Algorithm (pending), by David Berlinski

Skip Montanaro wrote:
> My guess is that -tt triggered a SyntaxError (maybe we should create an
> IndentationError that is a subclass of SyntaxError?)

Paul Prescod writes:
> +1
>
> That would be great for newbies!

Yes, but the name is confusing, because it isn't raised for every
sort of indentation error if it's only used for tab/space problems:

try:
1/0
1/0
finally:
pass

still would raise SyntaxError. Should that raise an IndentationError
as well? Or should IndentationError be named something else?
(Just adding IndentationError for -tt isn't hard, I have a
preliminary patch for that now. Adding it for the case above looks
harder.)


-Fred

--
Fred L. Drake, Jr. <fdrake at beopen.com>
BeOpen PythonLabs Team Member

Fred L. Drake, Jr. <fdrake@beopen.com>:
>
> Skip Montanaro wrote:
> > My guess is that -tt triggered a SyntaxError (maybe we should create an
> > IndentationError that is a subclass of SyntaxError?)
>
> Paul Prescod writes:
> > +1
> >
> > That would be great for newbies!
>
> Yes, but the name is confusing, because it isn't raised for every
> sort of indentation error if it's only used for tab/space problems:
>
> try:
> 1/0
> 1/0
> finally:
> pass
>
> still would raise SyntaxError. Should that raise an IndentationError
> as well? Or should IndentationError be named something else?

WhitespaceError
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Morality is always the product of terror; its chains and
strait-waistcoats are fashioned by those who dare not trust others,
because they dare not trust themselves, to walk in liberty.
-- Aldous Huxley

[Fred L. Drake, Jr. <fdrake@beopen.com>]
> Yes, but the name is confusing, because it isn't raised for every
> sort of indentation error if it's only used for tab/space problems:

[Eric S. Raymond]
> WhitespaceError

How about TabError?

Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange / CNRI voice: +1-703-262-5376
Reston, Virginia, USA fax: +1-703-262-5367

Greg Ward <gward@mems-exchange.org>:
> [Fred L. Drake, Jr. <fdrake@beopen.com>]
> > Yes, but the name is confusing, because it isn't raised for every
> > sort of indentation error if it's only used for tab/space problems:
>
> [Eric S. Raymond]
> > WhitespaceError
>
> How about TabError?

Not a big deal to me which gets used.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The United States is in no way founded upon the Christian religion
-- George Washington & John Adams, in a diplomatic message to Malta.

"Fred L. Drake, Jr." wrote:
>
> ...
>
> (Just adding IndentationError for -tt isn't hard, I have a
> preliminary patch for that now. Adding it for the case above looks
> harder.)

I think that in a perfect world, IndentationError would apply to both of
them. Maybe TabError would be a subclass of IndentationError. You could
set up the hierarchy that way without actually implementing the code
that recognizes "ordinary" indentation errors.
--
Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it
gave rise made modern science possible, but it was the algorithm that
made the modern world possible.
- The Advent of the Algorithm (pending), by David Berlinski

Eric S. Raymond wrote:
> WhitespaceError

Greg Ward wrote:
> How about TabError?

But what i'd really like is an IndentationError that shows
up whenever there's an indentation problem.

It doesn't even have to be its own class of error, i suppose,
as long as it gets indicated some way ("SyntaxError: invalid
indentation" would be fine). This response would be good for
all of the following situations:

>>> 3
File "<stdin>", line 1
3
^
SyntaxError: invalid syntax
>>> if 1:
... 3
File "<stdin>", line 2
3
^
SyntaxError: invalid syntax
>>> if 1:
... 3
... 4
inconsistent dedent
File "<stdin>", line 3
4
^
SyntaxError: invalid token
>>> if 1:
... if 2:
... 3
File "<stdin>", line 3
3
^
SyntaxError: invalid syntax
>>> if 1:
... if 2:
... 3
inconsistent dedent
File "<stdin>", line 3
3
^
SyntaxError: invalid token
>>> if 1:
... if 2:
... 3
... 4
inconsistent dedent
File "<stdin>", line 4
4
^
SyntaxError: invalid token



-- ?!ng

Ka-Ping Yee writes:
> But what i'd really like is an IndentationError that shows
> up whenever there's an indentation problem.

That's what I think of when I hear "IndentationError" -- TabError is
a specialized case of that.
I think the general IndentationError will be hard to do, since many
cases are just another parse error by the time they can be turned into
exceptions. Unless I'm misreading that code.


-Fred

--
Fred L. Drake, Jr. <fdrake at beopen.com>
BeOpen PythonLabs Team Member

On Mon, Jul 03, 2000 at 06:58:22PM -0400, Fred L. Drake, Jr. wrote:
>
> Ka-Ping Yee writes:
> > But what i'd really like is an IndentationError that shows
> > up whenever there's an indentation problem.
>
> That's what I think of when I hear "IndentationError" -- TabError is
> a specialized case of that.
> I think the general IndentationError will be hard to do, since many
> cases are just another parse error by the time they can be turned into
> exceptions. Unless I'm misreading that code.

Speaking out of my butt here, without looking at code, I would suspect that
the parser can return specializations "syntax error" to indicate that a
problem with indentation occurred.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Greg Stein writes:
> Speaking out of my butt here, without looking at code, I would suspect that
> the parser can return specializations "syntax error" to indicate that a
> problem with indentation occurred.

And I'm sure you'll find the way to do it. ;) Here's a patch that
sets up the IndentationError and TabError exceptions, and gets
TabError raised when -tt is in effect. If you can figure out how to
get IndentationError raised for other indentation-related errors, I'll
be interested in seeing it. Essentially, the parser-generator will
need to be able to distinguish between INDENT/DEDENT errors and other
errors, and I've not dug deep enough to figure that one out. The
tab/space errors are easy since they're in the hand-coded lexer.


-Fred

--
Fred L. Drake, Jr. <fdrake at beopen.com>
BeOpen PythonLabs Team Member