Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Stephen J. Turnbull]

> "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes:

Phillip> You just said, "Unhandled, KeyboardInterrupt means..."
Phillip> If the program doesn't *want* to handle
Phillip> KeyboardInterrupt, then it obviously *isn't* critical,
Phillip> because it doesn't care.  Conversely, if it *does* handle
Phillip> KeyboardInterrupt, then once again, it's not critical by
Phillip> your definition.

That's not my definition.  By that argument, no condition that can be
handled can be critical.

By my definition, the condition only needs to prevent the program from
continuing normally when it arises.  KeyboardInterrupt is a convention
that is used to tell a program that continuing normally is not
acceptable behavior, and therefore "critical" by my definition.

Under either definition, we'll still need to do something special with
MemoryError, KeyboardInterrupt, et amicae, and they still shouldn't be
caught by a generic "except Exception".  We agree on that, don't we?

Phillip> Note, by the way, that Python programs can disable a
Phillip> KeyboardInterrupt [...].  Ergo, it's a control flow
Phillip> exception.

Sure, in some sense---but not in the Python language AFAIK.  Which
control constructs in the Python language define semantics for
continuation after KeyboardInterrupt occurs?  Anything that can stop a
program but the language doesn't define semantics for continuation is
critical and exceptional by my definition.

Willem> I'd prefer the 'condition' and 'error' terminology, and to
Willem> label a keyboard interrupt a condition, not any kind of
Willem> exception or error.

>> Now, that does bother me. [...]

Phillip> On the contrary, it is control-flow exceptions that bare
Phillip> except clauses are most harmful to: StopIteration,
Phillip> SystemExit, and...  you guessed it...  KeyboardInterrupt.

That is a Python semantics issue, but as far as I can see there's
unanimity on it.  I and (AFAICS) Willem were discussing the
connotations of the _names_ at this point, and whether they were
suggestive of the semantics we (all!) seem to agree on.  I do not find
the word "condition" suggestive of the "things 'bare except' should
not catch" semantics.  I believe enough others will agree with me that
the word "condition", even "serious condition", should be avoided.

Phillip> An exception that's being used for control flow is
Phillip> precisely the kind of thing you don't want anything but
Phillip> an explicit except clause to catch.

Which is exactly the conclusion I reached:

[It] makes me wonder if there's any benefit to having a class [ie,
CriticalException] between Raisable and KeyboardInterrupt.  ...I
don't see a need for a class whose members share only the property
that they are not catchable with a bare except

Now, somebody proposed:

Raisable -+- Exception
  +- ...
  +- ControlFlowException -+- StopIteration
   +- KeyboardInterrupt

As I wrote above, I see no use for that; I think that's what you're
saying too, right?  AIUI, you want

Raisable -+- Exception
  +- ...
  +- StopIteration
  +- KeyboardInterrupt

so that only the appropriate control construct or an explicit except
can catch a control flow exception.  At least, you've convinced me
that "critical exception" is not a concept that should be implemented
in the Python language specification.  Rather, (for those who think as
I do, if there are others) "critical exception" would be an
intuitive guide to a subclass of exceptions that shouldn't be caught
by a bare except (or a handler for any superclass except Raisable, for
that matter).

By the same token, "control flow exception" is a pedagogical concept,
not something that should be reified in a ControlFlowException class,
right?

Phillip> If you think that a KeyboardInterrupt is an error,

I have used the word "error" only in quoting Willem, and that's quite
deliberate.  I don't think that a condition need be an error to be
"critical".

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN
   Ask not how you can "do" free software business;
  ask what your business can "do for" free software.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[Martin v. Löwis]

George V. Neville-Neil wrote:
> Since Python is Open Source are you looking at Per Force which you can
> use for free and seems to be a happy medium between something like CVS
> and something horrific like Clear Case?

No. The PEP is only about Subversion. Why should we be looking at Per
Force? Only because Python is Open Source?

I think anything but Subversion is ruled out because:
- there is no offer to host that anywhere (for subversion, there is
  already svn.python.org)
- there is no support for converting a CVS repository (for subversion,
  there is cvs2svn)

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>  > The PSF does have a reasonable budget, so why not use it to
>  > maintain the infrastructure needed for Python development and
>  > let a company do the administration of the needed servers and
>  > the importing of the CSV and tracker items into their
>  > systems ?
> 
> In principle, this might be a good idea. In practice, it falls
> short of details: which company, what precisely are their procedures,
> etc. It's not always the case that giving money to somebody really
> gives you back the value you expect.

True, but if we never ask, we'll never know :-)

My question was: Would asking a professional hosting company
be a reasonable approach ?

>From the answers, I take it that there's not much trust in these
offers, so I guess there's not much desire to PSF money into this.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Nick Coghlan]

Stephen J. Turnbull wrote:
> Now, somebody proposed:
> 
> Raisable -+- Exception
>   +- ...
>   +- ControlFlowException -+- StopIteration
>+- KeyboardInterrupt
> 
> As I wrote above, I see no use for that

The use for it is :

   try:
 # do stuff
   except ControlFlowException:
 raise
   except Raisable:
 # handle anything else

Sure, you could write it as:

   try:
 # do stuff
   except (CriticalException, Exception, Warning):
 # handle anything else

But the former structure better reflects the programmers intent (handle 
everything except control flow exceptions).

It's a fact that Python uses exceptions for control flow - KeyboardInterrupt 
[1], StopIteration, SystemExit (and soon to be GeneratorExit as well). 
Grouping them under a common parent allows them to be dealt with as a group, 
rather than their names being spelt out explicitly.

Actually having this in the exception hierarchy is beneficial from a 
pedagogical point of view as well - the hierarchy is practically the first 
thing you encounter when you run "help ('exceptions')" at the interactive 
prompt.

I have a Python 2.5 candidate hierarchy below, which uses dual inheritance to 
avoid breaking backward compatibility - any existing except clauses will catch 
all of the exceptions they used to catch. The only new inheritance introduced 
is to new exceptions, also avoiding backward compatibility problems, as any 
existing except clauses will let by all of the exceptions they used to let by. 
There are no removals, but the deprecation process is started in order to 
change the names of ReferenceError and RuntimeWarning to WeakReferenceError 
and SemanticsWarning.

With this hierarchy, the recommended parent class for application errors 
becomes Error, and "except Error:" is preferred to any of "except:", "except 
Exception:" and "except StandardError:" (although these three continue to 
catch everything they used to catch).

The recommended workaround for libraries raising errors which still inherit 
directly from Exception is:
   try:
 # Use library
   except (ControlFlowException, CriticalError):
 raise
   except Exception:
 # Do stuff

(Remove the 'Exception' part if the library is so outdated that it still 
raises string exceptions)

Applications which use exceptions to control the flow of execution rather than 
to indicate an error (e.g. breaking out of multiple nested loops) are free to 
use ControlFlowException directly, or else define their own subclasses of 
ControlFlowException.

This hierarchy achieves my main goal for the exception reorganisation, which 
is to make it easy for scripts and applications to avoid inadvertently 
swallowing the control flow exceptions and critical errors, while still being 
able to provide generic error handlers for application faults. (Hmm, the 
pre-PEP doesn't include that as a goal in the 'Philosophy' section. . .)

Python 2.4 Compatible Improved Exception Hierarchy v 0.1


Exception
+-- ControlFlowException (new)
  +-- GeneratorExit (new)
  +-- StopIteration
  +-- SystemExit
  +-- KeyboardInterrupt (dual-inheritance new)
+-- StandardError
  +-- KeyboardInterrupt (dual-inheritance new)
  +-- CriticalError (new)
  +-- MemoryError
  +-- SystemError
  +-- Error (new)
  +-- AssertionError
  +-- AttributeError
  +-- EOFError
  +-- ImportError
  +-- TypeError
  +-- ReferenceError (deprecated), WeakReferenceError (new alias)
  +-- ArithmeticError
  +-- FloatingPointError
  +-- DivideByZeroError
  +-- OverflowError
  +-- EnvironmentError
  +-- OSError
  +-- WindowsError
  +-- IOError
  +-- LookupError
  +-- IndexError
  +-- KeyError
  +-- NameError
  +-- UnboundLocalError
  +-- RuntimeError
  +-- NotImplementedError
  +-- SyntaxError
  +-- IndentationError
  +-- TabError
  +-- ValueError
  +-- UnicodeError
  +-- UnicodeDecodeError
  +-- UnicodeEncodeError
  +-- UnicodeTranslateError
+-- Warning
  +-- DeprecationWarning
  +-- FutureWarning
  +-- PendingDeprecationWarning
  +-- RuntimeWarning (deprecated), SemanticsWarning (new alias)
  +-- SyntaxWarning
  +-- UserWarning

Cheers,
Nick.

[1] PJE has convinced me that I was right in thinking that KeyboardInterrupt 
was a better fit under ControlFlowExceptions than it was under CriticalError.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Pyt

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[M.-A. Lemburg]

Nick Coghlan wrote:
> I have a Python 2.5 candidate hierarchy below, which uses dual inheritance to 
> avoid breaking backward compatibility - any existing except clauses will 
> catch 
> all of the exceptions they used to catch. The only new inheritance introduced 
> is to new exceptions, also avoiding backward compatibility problems, as any 
> existing except clauses will let by all of the exceptions they used to let 
> by. 
> There are no removals, but the deprecation process is started in order to 
> change the names of ReferenceError and RuntimeWarning to WeakReferenceError 
> and SemanticsWarning.

+1.

I like this approach of using multiple inheritence to solve the
b/w compatibility problem.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 02 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[Michael Hudson]

Donovan Baarda <[EMAIL PROTECTED]> writes:

> This is why I don't bother migrating any existing CVS projects to SVN;
> the benefits don't yet outweigh the pain of migrating.

I think they do.  I was on dialup for a while, and would have _loved_
Python to be using SVN then -- and given how long diffs can take even
over my broadband connection...

Cheers,
mwh

PS: Wot, noone's suggested git yet? :)

-- 
  C++ is a siren song.  It *looks* like a HLL in which you ought to
  be able to write an application, but it really isn't.
   -- Alain Picard, comp.lang.lisp
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Mark Russell]

On Tue, 2005-08-02 at 11:00, Nick Coghlan wrote:
> With this hierarchy, the recommended parent class for application errors 
> becomes Error, ...

And presumably Error could also be the recommended exception for
quick'n'dirty scripts.

Mark Russell

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

[falcon]

Hello python-list,

As I Understood, semantic may be next:

def qwerty(a,a.i,b,b.i,f.j):
pass

Would work like:
  
def qwerty(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5):

(a,a.i,b,b.i,f.j)=(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5)
del anonymous1
del anonymous2
del anonymous3
del anonymous4
del anonymous5

If so then I like it, because it more explicit than anything other
and it is working right now. I just tryed:

>>> class Stub:
... pass
>>> def qwer(a1,a2,a3,a4,a5):
... (a,a.i,b,b.i,f['i'])=(a1,a2,a3,a4,a5)
... del a1
... del a2
... del a3
... del a4
... del a5
... print (a,a.i,b,b.i,f['i'])
>>> f={}
>>> qwer(Stub(),1,Stub(),2,3)
(<__main__.Stub instance at 0x00C49530>, 1, <__main__.Stub instance at 
0x00C498C8>, 2, 3)

So there are not too much for implement.
Another question - named arguments. How I can assign to them?
May be so:
f={}
def qwerty(a,a.i,f['i']):
print (a,a.i,f['i'])
qwerty(f['i']=3,a=Stub(),a.i=4) - ?

and for __init__:
class MyClass:
def __init__(self,self.i,self.j,self.k):
pass

MyObject = MyClass(self.i=1,self.j=2,self.k=3)

?

or may be there can be an aliase syntax?

class MyClass:
def __init__(self, self.i by i,self.j by j, self.k by k):
pass

MyObject = MyClass(i=1,j=2,k=3)

--
Sokolov Yura
[EMAIL PROTECTED]


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[François Pinard]

[Martin von Löwis]

> The PEP is only about Subversion.  I think anything but Subversion is
> ruled out because:

> - there is no offer to host that anywhere (for subversion, there is
> already svn.python.org)

> - there is no support for converting a CVS repository (for subversion,
> there is cvs2svn)

I quickly discussed Subversion with a few friends.

While some say Subversion is the most reasonable avenue nowadays, others
them told me they found something more appealing than Subversion:

   http://www.venge.net/monotone/

The hosting paradigm is fairly different, and for a few weeks now, they
have a CVS repository converter.

In my very naive eyes, the centralised aspects of Python development
are be better represented with Subversion.  It is notable also that
Subversion if more Python-friendly than Monotone, with its Lua-based
scripting.  I did not deepen why, but at first glance, Monotone does not
seduce me.  On the other hand, the two guys saying good about Monotone
are well informed (and also well known), so I would not dismiss their
opinion so lightly.  So, it might be worth at least a quick look? :-)

-- 
François Pinard   http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[James Y Knight]

On Aug 2, 2005, at 12:31 AM, Phillip J. Eby wrote:
> If you think that a KeyboardInterrupt is an error, then it's an  
> indication
> that Python's documentation and the current exception class  
> hierarchy has
> failed to educate you sufficiently, and that we *really* need to add a
> class like ControlFlowException into the hierarchy to help make  
> sure that
> other people don't end up sharing your misunderstanding.  ;-)

No... KeyboardInterrupt (just like other asynchronous exceptions)  
really should be treated as a critical error. Doing anything other  
than killing your process off after receiving it is just inviting  
disaster. Because the exception can have occurred absolutely  
anywhere, it is unsuitable for normal use. Aborting a function  
between two arbitrary bytecodes and trying to continue operation is  
simply a recipe for disaster. For example, in threadable.py between  
line 200 "saved_state = self._release_save()" and 201 "try:#  
restore state no matter what (e.g., KeyboardInterrupt)" would be a  
bad place to hit control-c if you ever need to use that Condition  
again. This kind of problem is pervasive and unavoidable.

If you want to do a clean shutdown on control-c, the only sane way is  
to install a custom signal handler that doesn't throw an asynchronous  
exception at you.

There's a reason asynchronously killing off threads was deprecated in  
java.

James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[Raymond Hettinger]

[François Pinard]
> While some say Subversion is the most reasonable avenue nowadays,
others
> them told me they found something more appealing than Subversion:
> 
>http://www.venge.net/monotone/

The current release is 0.21 which suggests that it is not ready for
primetime.


Raymond

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[James Y Knight]

On Jul 31, 2005, at 12:49 PM, Phillip J. Eby wrote:

> I think you're ignoring the part where most exception handlers are  
> already broken.  At least adding CriticalException and  
> ControlFlowException makes it possible to add this:
>
> try:
> ...
> except (CriticalException,ControlFlowException):
> raise
> except:
> ...
>
> This isn't great, I admit, but at least it would actually *work*.
>
> I also don't see how changing the recommended base class from  
> Exception to Error causes *problems* for every library.  Sure, it  
> forces them to move (eventually!), but it's a trivial change, and  
> makes it *possible* to do the right thing with exceptions (e.g.  
> except Error:) as soon as all the libraries you depend on have  
> moved to using Error.

Exactly. That is the problem. Adding a new class above Exception in  
the hierarchy allows everything to work nicely *now*. Recommended  
practice has been to have exceptions derive from Exception for a  
looong time. Changing everybody now will take approximately forever,  
which means the Error class is pretty much useless. By keeping the  
definition of Exception as "the standard thing you should derive from  
and catch", and adding a superclass with things you shouldn't catch,  
you make conversion a lot simpler. If you're not worried about  
compatibility with ye olde string exceptions, you can start using  
"except Exception" immediately. If you are, you can do as your  
example above. And when Python v.Future comes around, "except  
Exception" will be the only reasonable thing to do.

If, on the other hand, we use Exception as the base class and Error  
as the thing you should use, I predict that even by the time Python  
v.Future comes out, many libraries/prgrams will still have exceptions  
deriving from Exception, thus making the Exception/Error distinction  
somewhat broken.

James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

[Terry Reedy]

"falcon" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Hello python-list,
>
> As I Understood, semantic may be next:
[snip]

This was properly posted to the general Python discussion group/list.
Reposted here, to the Python development list/group, it is offtopic.

If you did not get a satisfactory answer to your first post to the general 
group/list, it may be because your question is confusing.  So you might 
want to try again there with different words.

Terry J. Reedy




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Phillip J. Eby]

At 04:13 PM 8/2/2005 +0900, Stephen J. Turnbull wrote:
>Now, somebody proposed:
>
>Raisable -+- Exception
>   +- ...
>   +- ControlFlowException -+- StopIteration
>+- KeyboardInterrupt
>
>As I wrote above, I see no use for that; I think that's what you're
>saying too, right?  AIUI, you want
>
>Raisable -+- Exception
>   +- ...
>   +- StopIteration
>   +- KeyboardInterrupt
>
>so that only the appropriate control construct or an explicit except
>can catch a control flow exception.

No, I want ControlFlowException to exist as a parent so that code today can 
work around the fact that bare "except:" and "except Exception:" catch 
everything.  In Python 3.0, we should have "except Error:" and be able to 
have it catch everything but control flow exceptions and possibly critical 
errors.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Phillip J. Eby]

At 08:00 PM 8/2/2005 +1000, Nick Coghlan wrote:
>Python 2.4 Compatible Improved Exception Hierarchy v 0.1
>
>
>Exception
>+-- ControlFlowException (new)
>   +-- GeneratorExit (new)
>   +-- StopIteration
>   +-- SystemExit
>   +-- KeyboardInterrupt (dual-inheritance new)
>+-- StandardError
>   +-- KeyboardInterrupt (dual-inheritance new)
>   +-- CriticalError (new)
>   +-- MemoryError
>   +-- SystemError
>   +-- Error (new)

Couldn't we make Error a parent of StandardError, here, and then make the 
CriticalError subclasses dual-inherit StandardError, i.e.:

 Error
 CriticalError
 MemoryError (also subclass StandardError)
 SystemError (also subclass StandardError)
 StandardError
 ...

In this way, we can encourage people to inherit from Error.  Or maybe we 
should just make the primary hierarchy the way we want it to be, and only 
cross-link exceptions to StandardError that were previously under 
StandardError, i.e.:

 Raisable
 ControlFlowException
 ...  (cross-inherit to StandardError as needed)
 CriticalError
 ...  (cross-inherit to StandardError as needed)
 Exception
 ...

This wouldn't avoid "except Exception" and bare except being problems, but 
at least you can catch the uncatchables and reraise them.

Hm.  Maybe we should include a Reraisable base for ControlFlowException and 
CriticalError?  Then you could do "except Reraisable: raise" as a nice way 
to do the right thing until Python 3.0.

It seems to me that multiple inheritance is definitely the right idea, 
though.  That way, we can get the hierarchy we really want with only a 
minimum of boilerplate in pre-3.0 to make it actually work.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Phillip J. Eby]

At 10:53 AM 8/2/2005 -0400, James Y Knight wrote:
>No... KeyboardInterrupt (just like other asynchronous exceptions)
>really should be treated as a critical error. Doing anything other
>than killing your process off after receiving it is just inviting
>disaster. Because the exception can have occurred absolutely
>anywhere, it is unsuitable for normal use. Aborting a function
>between two arbitrary bytecodes and trying to continue operation is
>simply a recipe for disaster. For example, in threadable.py between
>line 200 "saved_state = self._release_save()" and 201 "try:#
>restore state no matter what (e.g., KeyboardInterrupt)" would be a
>bad place to hit control-c if you ever need to use that Condition
>again. This kind of problem is pervasive and unavoidable.

In my personal experience with using KeyboardInterrupt I've only ever 
needed to do some minor cleanup of external state, such as removing 
lockfiles, abandoning connections, etc., so I haven't encountered this 
issue before.  I can see, however, why it would be a problem if you were 
trying to keep the program *running* - but I've been assuming that 
KeyboardInterrupt is something that always means "attempt to shutdown 
gracefully".  I suppose considering it a critical error might put it more 
clearly in that category.

I'm not 100% convinced, but you've definitely given me something to think 
about.  On the other hand, any exception can happen "between two arbitrary 
bytecodes", so there are always circumstances that need special attention, 
or require a "with block_signals" statement or something.  I suppose this 
issue may have to come down to BDFL pronouncement.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[François Pinard]

[Raymond Hettinger]

> >http://www.venge.net/monotone/

> The current release is 0.21 which suggests that it is not ready for
> primetime.

It suggests it, yes, and to me as well.  On the other hand, there is
a common prejudice that something requires many releases, or frequent
releases, to be qualified as good.  While it might be true on average,
this is not necessarily true: some packages need not so many steps for
becoming very usable, mature or stable.  (Note that I'm not asserting
anything about Monotone, here.)  We should merely keep an open mind.

-- 
François Pinard   http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Brett Cannon]

On 8/2/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:00 PM 8/2/2005 +1000, Nick Coghlan wrote:
[SNIP]
> Or maybe we
> should just make the primary hierarchy the way we want it to be, and only
> cross-link exceptions to StandardError that were previously under
> StandardError, i.e.:
> 
>  Raisable
>  ControlFlowException
>  ...  (cross-inherit to StandardError as needed)
>  CriticalError
>  ...  (cross-inherit to StandardError as needed)
>  Exception
>  ...
> 
> This wouldn't avoid "except Exception" and bare except being problems, but
> at least you can catch the uncatchables and reraise them.
> 

I think that is acceptable.  Using multiple inheritance to make sure
that the exceptions that have been moved out of the main exception
branch seems like it will be the best solution for giving some form of
backwards-compatibility for now while allowing things to still move
forward and not cripple the changes we want to make.

> Hm.  Maybe we should include a Reraisable base for ControlFlowException and
> CriticalError?  Then you could do "except Reraisable: raise" as a nice way
> to do the right thing until Python 3.0.
> 

As in exceptions that don't inherit from
Error/StandError/whatever_the_main_exception_is can easily be caught
separately?

> It seems to me that multiple inheritance is definitely the right idea,
> though.  That way, we can get the hierarchy we really want with only a
> minimum of boilerplate in pre-3.0 to make it actually work.
> 

Yeah.  I think name aliasing and multiple inheritance will take us a
long way.  Warnings should be able to take us the rest of the way.

-Brett (who is still waiting for a number; Barry, David, you out there?)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Syscall Proxying in Python

[Gabriel Becedillas]

Donovan Baarda wrote:
> On Mon, 2005-08-01 at 10:36, Gabriel Becedillas wrote:
> 
>>Hi,
>>We embbeded Python 2.0.1 in our product a few years ago and we'd like to
>>upgrade to Python 2.4.1. This was not a simple task, because we needed 
>>to execute syscalls on a remote host. We modified Python's source code 
>>in severall places to call our own versions of some functions. For 
>>example, instead of calling fopen(...), the source code was modified to 
>>call remote_fopen(...), and the same was done with other libc functions. 
>>Socket functions where hooked too (we modified socket.c), Windows 
>>Registry functions, etc..
> 
> 
> Wow... you guys sure did it the hard way. If you had done it at the
> Python level, you would have had a much easier time of both implementing
> and updating it.
> 
> As an example, have a look at my osVFS stuff. This is a replacement for
> the os module and open() that tricks Python into using a virtual file
> system;
> 
> http://minkirri.apana.org.au/~abo/projects/osVFS
> 
> 

Hi, thanks for your reply.
The problem I see with the aproach you're sugesting is that I have to 
rewrite a lot of code to make it work the way I want. We allready have 
the syscall proxying stuff with an stdio layer on top of it. I should 
have to rewrite some parts of some modules and use my own versions of 
stdio functions, and that is pretty much the same as we have done before.
There are also native objects that use stdio functions, and I should 
replace those ones too, or modules that have some native code that uses 
stdio, or sockets. I should duplicate those files, and make the same 
kind of search/replace work that we have done previously and that we'd 
like to avoid.
Please let me know if I misunderstood you.
Thanks again.

-- 


Gabriel Becedillas
Developer
CORE SECURITY TECHNOLOGIES

Florida 141 - 2º cuerpo - 7º piso
C1005AAC Buenos Aires - Argentina
Tel/Fax: (54 11) 5032-CORE (2673)
http://www.corest.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Willem Broekema]

On 8/2/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> I don't see it that way.  Rather, "Raisable" is the closest equivalent
> to "serious-condition", and "CriticalException" is an intermediate
> class that has no counterpart in Lisp usage.

That would imply that all raisables are 'serious' in the Lisp sense,
which is defined as "all conditions serious enough to require
interactive intervention if not handled". Yet Python warnings are
raisable (as raisable is the root), but are certainly not serious in
the Lisp sense.

(This is complicated by that warnings are raised using 'signal'. More below.)

Willem:
> I'd prefer the 'condition' and 'error' terminology, and to
> label a keyboard interrupt a condition, not any kind of
> exception or error.

To clarify myself: a 'serious-condition' in CL stands for "all
conditions serious enough to require interactive intervention if not
handled"; I meant to label KI a 'serious-condition'.

Stephen: 
> Now, that does bother me.  Anything we will not permit a program
> to ignore with a bare "except: pass" if it so chooses had better be
> more serious than merely a "condition".  Also, to me a "condition" is
> something that I poll for, it does not interrupt me.  To me, a
> condition (even a serious one) is precisely the kind of thing that I
> should be able to ignore with a bare except!

If I understand your position correctly, it is probably not changed
yet by the above clarification. 

Maybe it will surprise you, that in Lisp a bare except (ignore-errors)
does not catch non-serious things like warnings. And if left
uncatched, a warning leaks out to the top level, gets printed and
subsequently ignored. That's because non-serious conditions are
(usually) raised using 'signal', not 'error'. The default top-level
warnings handler just prints it, but does not influence the program
control flow, so the execution resumes just after the (warn ..) form.

This probably marks a very important difference between Python and CL.
I think one could say that where in Python one would use a bare except
to catch both non-serious and serious exceptions, in CL one normally
doesn't bother with catching the non-serious ones because they will
not create havoc at an outer level anyway. So in Python a warning must
be catched by a bare except, while in Lisp it would not. And from this
follow different contraints on the hierarchy.

By the way, this is the condition hierarchy in Allegro CL (most of
which is prescribed by the ANSI standard):



- Willem
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[Martin v. Löwis]

M.-A. Lemburg wrote:
> True, but if we never ask, we'll never know :-)
>
> My question was: Would asking a professional hosting company
> be a reasonable approach ?

It would be an option, yes, of course. It's not an approach that
*I* would be willing to implement, though.

>>From the answers, I take it that there's not much trust in these
> offers, so I guess there's not much desire to PSF money into this.

I haven't received any offers to make a qualified statement. I only
know that I would oppose an approach to ask somebody but our
volunteers to do it for free, and I also know that I don't want to
spend my time researching commercial alternatives (although I
wouldn't mind if you spent your time).

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[Martin v. Löwis]

François Pinard wrote:
> So, it might be worth at least a quick look? :-)

Certainly not my look - although I'm willing to integrate
anything that people contribute into the PEP.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0

[Brett Cannon]

OK, having taken in all of the suggestions, here is another revision
round.  I think I still have a place or two I partially ignored people
just because there was not a severe uproar and I still think the
original idea is good (renaming RuntimeError, for instance).  I also
added notes on handling the transition and rejected idea.

There is now only one open issue, which is whether
ControlFlowException should be removed.

And I am still waiting on a PEP number to be able to check this into
CVS and push me to flesh out the references.  =)


--

PEP: XXX
Title: Exception Reorganization for Python 3.0
Version: $Revision: 1.5 $
Last-Modified: $Date: 2005/06/07 13:17:37 $
Author: Brett Cannon <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Jul-2005
Post-History: XX-XXX-XXX

.. contents::


Abstract


Python, as of version 2.4, has 38 exceptions (including warnings) in
the built-in namespace in a rather shallow hierarchy.
This list of classes has grown over the years without a chance to
learn from mistakes and cleaning up the hierarchy.
This PEP proposes doing a reorganization for Python 3.0 when
backwards-compatibility is not an issue.
Along with this reorganization, adding a requirement that all objects passed to
a ``raise`` statement must inherit from a specific superclass is proposed.
Lastly, the removal of bare ``except`` class is suggested.


Rationale
=

Exceptions are a critical part of Python.
While exceptions are traditionally used to signal errors in a program,
they have also grown to be used for flow control for things such as
iterators.
There importance is great.

But the organization of the exception hierarchy is suboptimal.
Mostly for backwards-compatibility reasons, the hierarchy has stayed
very flat and old exceptions who usefulness have not been proven have
been left in.
Making exceptions more hierarchical would help facilitate exception
handling by making catching exceptions using inheritance much more
logical.
This should also help lead to less errors from being too broad in what
exceptions are caught in an ``except`` clause.

A required superclass for all exceptions is also being proposed
[Summary2004-08-01]_.
By requiring any object that is used in a ``raise`` statement to
inherit from a specific superclass, certain attributes (such as those
laid out in PEP 344 [PEP344]_) can be guaranteed to exist.
This also will lead to the planned removal of string exceptions.

Lastly, bare ``except`` clauses are to be removed [XXX Guido's reply to my
initial draft]_.
Often people use a bare ``except`` when what they really wanted were
non-critical exceptions to be caught while more system-specific ones,
such as MemoryError, to pass through and to halt the interpreter.
This leads to errors that can be hard to debug thanks to exceptions' sometimes
unpredictable execution flow.
It also causes ``except`` statements to follow the "explicit is better than
implicit" tenant of Python [XXX]_.


Philosophy of Reorganization


There are several goals in this reorganization that defined the
philosophy used to guide the work.
One goal was to prune out unneeded exceptions.
Extraneous exceptions should not be left in since it just serves to
clutter the built-in namespace.
Unneeded exceptions also dilute the importance of other exceptions by
splitting uses between several exceptions when all uses should have
been under a single exception.

Another goal was to introduce any exceptions that were deemed needed
to fill any holes in the hierarchy.
Most new exceptions were done to flesh out the inheritance hierarchy
to make it easier to catch a category of exceptions with a simpler
``except`` clause.

Changing inheritance to make it more reasonable was a goal.
As stated above, having proper inheritance allows for more accurate
``except`` statements when catching exceptions based on the
inheritance tree.

Lastly, any renaming to make an exception's use more obvious from its
name was done.
Having to look up what an exception is meant to be used for because
the name does not proper reflect its usage is annoying and slows down
debugging.
Having a proper name also makes debugging easier on new programmers.
But for simplicity of existing user's and for transitioning to Python
3.0, only exceptions whose names were fairly out of alignment with
their stated purpose have been renamed.

New Hierarchy
=

Exception
+-- CriticalException (new)
+-- KeyboardInterrupt
+-- MemoryError
+-- SystemError
+-- ControlFlowException (new)
+-- StopIteration
+-- GeneratorExit
+-- SystemExit
+-- StandardError
+-- AssertionError
+-- SyntaxError
+-- IndentationError
+-- TabError
+-- UserException (rename of RuntimeError)
+-- ArithmeticError
+-- FloatingPointError
+-- DivideByZeroError
+-- OverflowError
+-- Unico

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Stephen J. Turnbull]

> "Willem" == Willem Broekema <[EMAIL PROTECTED]> writes:

Willem> On 8/2/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:

>> I don't see it that way.  Rather, "Raisable" is the closest
>> equivalent to "serious-condition", and "CriticalException" is
>> an intermediate class that has no counterpart in Lisp usage.

Willem> That would imply that all raisables are 'serious' in the
Willem> Lisp sense,

No, it implies that Phillip was right when he wrote that the Lisp
hierarchy of signals is not relevant (as a whole) to the discussion of
Python Raisables.  Of course partial analogies are useful.

In any case, Nick's idiom of "except ControlFlowException: raise"
clarified everything for me.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN
   Ask not how you can "do" free software business;
  ask what your business can "do for" free software.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[Donovan Baarda]

On Tue, 2005-08-02 at 09:06, François Pinard wrote:
> [Raymond Hettinger]
> 
> > >http://www.venge.net/monotone/
> 
> > The current release is 0.21 which suggests that it is not ready for
> > primetime.
> 
> It suggests it, yes, and to me as well.  On the other hand, there is
> a common prejudice that something requires many releases, or frequent
> releases, to be qualified as good.  While it might be true on average,
> this is not necessarily true: some packages need not so many steps for
> becoming very usable, mature or stable.  (Note that I'm not asserting
> anything about Monotone, here.)  We should merely keep an open mind.

It is true that some well designed/developed software becomes reliable
very quicky. However, it still takes heavy use over time to prove that.
You don't want to be the guy who finds out that this is not one of those
bits of software.

IMHO you need maturity for revision control software... you are relying
on it for history. The only open source options worth considering for
Python are CVS and SVN, and even SVN is questionable (see bdb backend
issues).

-- 
Donovan Baarda <[EMAIL PROTECTED]>

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0

[Raymond Hettinger]

The Py3.0 PEPs are a bit disconcerting.  Without 3.0 actively in
development, it is difficult to get the participation, interest, and
seriousness of thought that we apply to the current release.  The PEPs
may have the effect of prematurely finalizing discussions on something
that still has an ethereal if not pie-in-the-sky quality to it.  I would
hate for 3.0 development to start with constraints that got set in stone
before the project became a reality.

With respect to exception re-organization, the conversation has been
thought provoking but a little too much of a design-from-scratch
quality.  Each proposed change needs to be rooted in a specific problem
with the current hierarchy (i.e. what use cases cannot currently be
dealt with under the existing tree).  Setting a high threshold for
change will increase the likelihood that old code can be easily ported
and decrease the likelihood of either throwing away previous good
decisions or adopting new ideas that later prove unworkable.  IOW,
unless the current tree is thought to be really bad, then the new tree
ought to be very close to what we have now.


Raymond



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:python-dev-
> [EMAIL PROTECTED] On Behalf Of Brett Cannon
> Sent: Tuesday, August 02, 2005 8:34 PM
> To: Python Dev
> Subject: [Python-Dev] PEP, take 2: Exception Reorganization for Python
3.0
> 
> OK, having taken in all of the suggestions, here is another revision
> round.  I think I still have a place or two I partially ignored people
> just because there was not a severe uproar and I still think the
> original idea is good (renaming RuntimeError, for instance).  I also
> added notes on handling the transition and rejected idea.
> 
> There is now only one open issue, which is whether
> ControlFlowException should be removed.
> 
> And I am still waiting on a PEP number to be able to check this into
> CVS and push me to flesh out the references.  =)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0

[Phillip J. Eby]

At 09:02 PM 8/2/2005 -0400, Raymond Hettinger wrote:
>The Py3.0 PEPs are a bit disconcerting.  Without 3.0 actively in
>development, it is difficult to get the participation, interest, and
>seriousness of thought that we apply to the current release.  The PEPs
>may have the effect of prematurely finalizing discussions on something
>that still has an ethereal if not pie-in-the-sky quality to it.  I would
>hate for 3.0 development to start with constraints that got set in stone
>before the project became a reality.
>
>With respect to exception re-organization, the conversation has been
>thought provoking but a little too much of a design-from-scratch
>quality.  Each proposed change needs to be rooted in a specific problem
>with the current hierarchy (i.e. what use cases cannot currently be
>dealt with under the existing tree).  Setting a high threshold for
>change will increase the likelihood that old code can be easily ported
>and decrease the likelihood of either throwing away previous good
>decisions or adopting new ideas that later prove unworkable.  IOW,
>unless the current tree is thought to be really bad, then the new tree
>ought to be very close to what we have now.

+1.  The main things that need fixing, IMO, are the need for critical and 
control flow exceptions to be distinguished from "normal" errors.  The rest 
is mostly too abstract for me to care about in 2.x.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Syscall Proxying in Python

[Donovan Baarda]

On Tue, 2005-08-02 at 11:59, Gabriel Becedillas wrote:
> Donovan Baarda wrote:
[...]
> > Wow... you guys sure did it the hard way. If you had done it at the
> > Python level, you would have had a much easier time of both implementing
> > and updating it.
[...]
> Hi, thanks for your reply.
> The problem I see with the aproach you're sugesting is that I have to 
> rewrite a lot of code to make it work the way I want. We allready have 
> the syscall proxying stuff with an stdio layer on top of it. I should 
> have to rewrite some parts of some modules and use my own versions of 
> stdio functions, and that is pretty much the same as we have done before.
> There are also native objects that use stdio functions, and I should 
> replace those ones too, or modules that have some native code that uses 
> stdio, or sockets. I should duplicate those files, and make the same 
> kind of search/replace work that we have done previously and that we'd 
> like to avoid.
> Please let me know if I misunderstood you.

Nope... you got it all figured out. I guess it depends on what degree of
"proxying" you want... I thought there was some stuff you wanted
re-directed, and some you didn't. The point is, you _can_ do this at the
Python level, and you only have to modify Python code, not C Python
source. 

However, if you want to proxy everything, then the glib wrapper is
probably the best approach, provided you really want to code in C and
have your own Python binary.

-- 
Donovan Baarda <[EMAIL PROTECTED]>

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[François Pinard]

[Donovan Baarda]

> It is true that some well designed/developed software becomes reliable
> very quicky. However, it still takes heavy use over time to prove that.

There is wisdom in your say! :-)

-- 
François Pinard   http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  354 open ( -3) /  2888 closed ( +3) /  3242 total ( +0)
Bugs:  909 open (+11) /  5152 closed ( +8) /  6061 total (+19)
RFE :  191 open ( +0) /   178 closed ( +0) /   369 total ( +0)

Patches Closed
__

PEP 342 Generator enhancements  (2005-06-18)
   http://python.org/sf/1223381  closed by  pje

Provide tuple of "special" exceptions  (2004-10-01)
   http://python.org/sf/1038256  closed by  ncoghlan

Patch for (Doc) #1243553  (2005-07-24)
   http://python.org/sf/1243910  closed by  montanaro

New / Reopened Bugs
___

"new" not marked as deprecated in the docs  (2005-07-30)
   http://python.org/sf/1247765  opened by  Jürgen Hermann

error in popen2() reference  (2005-07-30)
CLOSED http://python.org/sf/1248036  opened by  Lorenzo Luengo

pdb 'next' does not skip list comprehension  (2005-07-31)
   http://python.org/sf/1248119  opened by  Joseph Heled

set of pdb breakpoint fails  (2005-07-31)
   http://python.org/sf/1248127  opened by  Joseph Heled

shelve .sync operation not documented  (2005-07-31)
   http://python.org/sf/1248199  opened by  paul rubin

dir should accept dirproxies for __dict__  (2005-07-31)
   http://python.org/sf/1248658  opened by  Ronald Oussoren

2.3.5 SRPM fails to build without tkinter installed  (2005-07-31)
   http://python.org/sf/1248997  opened by  Laurie Harper

rfc822 module, bug in parsedate_tz  (2005-08-01)
   http://python.org/sf/1249573  opened by  nemesis

isinstance() fails depending on how modules imported  (2005-08-01)
   http://python.org/sf/1249615  opened by  Hugh Gibson

Encodings and aliases do not match runtime  (2005-08-01)
   http://python.org/sf/1249749  opened by  liturgist

container methods raise KeyError not IndexError  (2005-08-01)
   http://python.org/sf/1249837  opened by  Wilfredo Sanchez

numarray in debian python 2.4.1  (2005-08-01)
CLOSED http://python.org/sf/1249867  opened by  LovePanda

numarray in debian python 2.4.1  (2005-08-01)
CLOSED http://python.org/sf/1249873  opened by  LovePanda

numarray in debian python 2.4.1  (2005-08-01)
   http://python.org/sf/1249903  opened by  LovePanda

IDLE does not start. 2.4.1  (2005-08-01)
CLOSED http://python.org/sf/1249965  opened by  codepyro

gethostbyname(gethostname()) fails on misconfigured system  (2005-08-02)
   http://python.org/sf/1250170  opened by  Tadeusz Andrzej Kadlubowski

incorrect description of range function  (2005-08-02)
   http://python.org/sf/1250306  opened by  John Gleeson

The -m option to python does not search zip files  (2005-08-02)
   http://python.org/sf/1250389  opened by  Paul Moore

Tix: PanedWindow.panes nonfunctional  (2005-08-02)
   http://python.org/sf/1250469  opened by  Majromax

Bugs Closed
___

Segfault in Python interpreter 2.3.5  (2005-07-26)
   http://python.org/sf/1244864  closed by  birkenfeld

logging module doc needs to note that it changed in 2.4  (2005-07-25)
   http://python.org/sf/1244683  closed by  vsajip

manual.cls contains an invalid pdf-inquiry  (2005-07-14)
   http://python.org/sf/1238210  closed by  fdrake

error in popen2() reference  (2005-07-30)
   http://python.org/sf/1248036  closed by  birkenfeld

numarray in debian python 2.4.1  (2005-08-01)
   http://python.org/sf/1249867  closed by  birkenfeld

numarray in debian python 2.4.1  (2005-08-01)
   http://python.org/sf/1249873  closed by  birkenfeld

IDLE does not start. 2.4.1  (2005-08-01)
   http://python.org/sf/1249965  closed by  codepyro

Incorrect documentation of re.UNICODE  (2005-07-22)
   http://python.org/sf/1243192  closed by  birkenfeld

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com