On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
In response to Ka-Ping's comments on the subject of "Resource Hiding"vs "Resource Crippling", Brett says:> It seems that your criticisms are aimed at resource crippling> being a "plug holes as needed but if you foul up you are screwed"
> with
To make sure I don't unfairly block out capabilities as a complete security model instead of just crippling 'file's constructor (I do like capabilities and think it is a good model, really!), let's discuss how one can get to the 'file' type without importing any extension modules (that can be prote
On 7/5/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Michael Chermside wrote:> That leaves the other problem: auxiliary means of accessing> objects. There are things like gc.get_objects(). In the special> case of file, which is a type that's also dangerous, there are
> tricks like "object().__class__._
On 7/5/06, Talin <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote:>> If you were using capabilities, you would need to ensure that>> restricted interpreters could only get the file object that they
>> were giv
On 7/6/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
I wrote:> I would still rather not spread FUD.Brett Cannon responds:> I don't consider it FUD. Armin in an email said that he thought it> was a losing battle to try to hide 'file' from an interpreter. That
> is what I am worried about, perio
On 7/5/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
On Wed, 5 Jul 2006, Brett Cannon wrote:> On 7/4/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:> > In response to Guido's comment about confusing the words "trusted" and
> > "untrusted", how about
On 7/5/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> Armin in an email said that he thought it was> a losing battle to try to hide 'file' from an interpreter.And I would change file() so that it didn't openfiles. Then it would be harmless for code
[replying to both Ping and Michael in the same email]On 7/6/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
Ka-Ping Yee writes:> i'm starting to think> that it would be good to clarify what kinds of threats we are
> trying to defend against, and specify what invariants we are> intending to preserv
On 7/6/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
Armin Rigo writes:> I don't think I can "sign off" [on hiding the file type]. Really hiding> Python objects is quite hard IMHO.
I agree. But we don't have to give up yet. How about instead of hidingfile, we cripple it. Completely. Modify the
On 7/6/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
Hi Brett,On Wed, Jul 05, 2006 at 05:01:48PM -0700, Brett Cannon wrote:> And if Armin and/or Samuele sign off that what we find is most likely (with> "most likely" equalling 99% chance) all there is, then bonus points an
On 7/6/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
Me:> I agree. But we don't have to give up yet. How about instead of hiding> file, we cripple it. Completely. Modify the file type so that when> executing on a sandboxed interpreter, all of the dangerous methods
> and attributes of file throw
Back at the beginning of June, the Python Software Foundation's Infrastructure committee sent out an email requesting people to help us find a replacement tracker for SourceForge (the original announcement can be found at
http://wiki.python.org/moin/CallForTrackers ). We asked that people put tes
On 7/6/06, Talin <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 7/5/06, Talin <[EMAIL PROTECTED]> wrote:>> Transitioning from the checked to the unchecked state could only be done>> via C code. So the 'file' wrapper, for example, would switch over to the
&g
On 7/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 7/5/06, *Greg Ewing* <[EMAIL PROTECTED]> And I would change file() so that it didn't open> files. Then it would be harmless for code to have
> access to the file class.> Right, that i
On 7/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Another thing I perhaps should point out is thatI'm proposing the separation of open() and file()for *all* code, not just restricted code. So it'snot a matter of "crippling" file() specially forrestricted code.
Well, that's fine with me since I use o
On 7/7/06, Talin <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 7/6/06, Talin <[EMAIL PROTECTED]> wrote:>> And if we can call it for every operation, then we don't have to spend>> time hunting down all of the possible loopholes and ways in which 'file
On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 7/7/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> I guess I am just not seeing where your approach is better than preventing> the constructor in 'file' and having open() return the 'file' object or
>
On 7/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Nick Coghlan wrote:> What would the signature of the file constructor be in that case?If it's possible to call it at all, I think it wouldhave to take a file descriptor, or whatever theplatform's OS-level representation of an open file
is.The other p
On 7/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> Good point. C code could circumvent the bit check by doing all of the> work behind the scenes without pushing the object on the stack. But if> the check is in the C code for the object itself it is much
On 7/7/06, Talin <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:>>>>> On 7/7/06, Brett Cannon <[EMAIL PROTECTED]
> wrote:>> > I guess I am just not seeing where your approach is better than>>
On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 7/8/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:> The situation you're describing here is a classic case of one> component keeping a closely held authority while using it to
> provide some limited capability to some other component. This> com
On 7/8/06, Tim Peters <[EMAIL PROTECTED]> wrote:
Back in:http://mail.python.org/pipermail/python-dev/2005-March/051856.htmlI made a pitch for adding:sys._current_frames()
to 2.5, which would return a dict mapping each thread's id to thatthread's current (Python) frame. As noted there, an e
"Resource managed"?
On 6/30/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
>
> What term should describe those objects in the documentation?
>
> For instance, if the new magic methods are added to decimal.Cont
On 7/1/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Friday 01 July 2005 11:44, Phillip J. Eby wrote:
> > Resource managers.
>
> Yeah, I was thinking that, but was somewhat ambivalent. But I definately like
> it better than anything else proposed so far.
>
I say we steal from the C++
On 7/7/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Guido]
> > OTOH I don't particularly like code that requires flag variables;
>
> Me neither; that's indeed why this one isn't a slam dunk.
>
> > they often make me squirm because the same condition (flag) is
> > tested multiple times where it co
Floris is working on wrapping Hotshot to replace 'profile' and
replacing pstats so that there will be no more need for 'profile' and
thus take care of the licensing problem. He also hopes to make pstats
faster to use. And if we are really lucky, get threading working for
Hotshot.
It would be gre
On 7/7/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 7/7/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Floris is working on wrapping Hotshot to replace 'profile' and
> > replacing pstats so that there will be no more need for 'profile' and
&
In order to lower the barrier for reporting bugs, writing patches, and
handling CVS commits, I am writing up checklists for each and I will
put them up on python.org.
The first checklist is for bug reports. All comments welcome. Keep
in mind the list is supposed to be short and straight-forward;
On 7/8/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I compiled a list of some possible new context managers that could be
> added to the stdlib. Introducing a new feature should IMO also show
> usage of it in the distribution itself. That wasn't done with
> decorators (a decorators
This is taking too long, so I am going to have Floris do his dev work
somewhere else. Forget about the request.
-Brett
On 7/7/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Floris is working on wrapping Hotshot to replace 'profile' and
> replacing pstats so that there wi
On 7/14/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > raymond> Log Message:
> > raymond> Brett requests that Flovis's permissions be dropped.
>
> [Skip]
> > Not to put too fine a spin on things, but I think it was more like
> Brett
> > got
> > tired of waiting for Flovis's permissio
On 7/28/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-07-28 at 16:00, "Martin v. Löwis" wrote:
> > I'd like to see the Python source be stored in Subversion instead
> > of CVS
>
> +1
>
+1 from me as well; single commit numbers for commits across multiple
files will be wonderful.
>
with Ping's PEP 344
will cover the major ideas for exceptions for Python 3.0 .
-Brett
--
PEP: XXX
Title: Exception Reorganization for Python 3.0
Version: $Revision: 1.5 $
Last-Modified: $Date: 2005/06/07 13:17:37 $
Author: Brett Cann
On 7/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 7/29/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Well, it has been discussed at multiple times in the past and I have
> > promised to write this PEP several times, so I finally found enough
> > ti
On 7/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > New Hierarchy
> > =
> >
> > Raisable (new; rename BaseException?)
> > +-- CriticalException (new)
> > +-- KeyboardInterrupt
> > +-- MemoryE
OK, I withdraw the suggestion of the subclassing of SystemError by SystemExit.
-Brett
On 7/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 7/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote:
> > > +-- SystemExit
> > > +-- SystemError (subclass SystemExit?)
> >
> > I'd recommend not
On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > +-- ControlFlowException (new)
>
> While I like the idea of ControlFlowException as the "one obvious way" to
> break out of multiple nested loops, I'm not convinced Stop
On 7/30/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Well, it has been discussed at multiple times in the past and I have
> > promised to write this PEP several times, so I finally found enough
> > time to write a PEP on reorganizin
On 7/30/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote:
>
> > I'd recommend not subclassing SystemExit--there are too many programs
> > out there which expect the argument (e.g. sys.exit(3)) to mean
> > something
> > specific, but that expectation
On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
> > The reason for my -1 on the renaming and reordering is
> > that it would completely break compatibility of Python 2.x
> > applications with Python 3. Furthermore, there would be next to
> > no chance of writing new appli
On 7/30/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> > > +-- Warning
> > > +-- DeprecationWarning
> > > +-- FutureWarning
> > > +-- PendingDeprecationWarning
> >
&g
On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Nick, are you going go start subbing in for Tim when he is busy and
> > take my work that I spent hours on, come up with an alternative that
> > took 10 minutes, and have everyone end up
On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
[SNIP]
> >> +-- RuntimeError
> > I still don't like the name.
>
> I'm not that fond of it either - but as the builtin exception most likely to
> be used (abused?) by user cod
On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > I like this a lot, and a good bit of it could actually be done in 2.5,
> > apart from the Exception/StandardError move, assuming also that the
> > renamed errors were also available under their old names. We could
> >
On 7/30/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Saturday 30 July 2005 22:20, Brett Cannon wrote:
> > True, but the hierarchy should still properly reflect increasing
> > severity in my opinion. I am going to push for this; we will see if I
> > get push
On 7/31/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> >>Notice that I've classified KeyboardInterrupt as user-initiated control flow
> >>and put it under ControlFlowException above. This means that everything
> >>under
> >>C
On 7/31/05, Willem Broekema <[EMAIL PROTECTED]> wrote:
> On 7/31/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > While we do tend to use KeyboardInterrupt as a way to kill a
> > program, is that really control flow, or a critical exception
> > that the program
On 8/1/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> > +-- Exception (formerly StandardError)
> > +-- AttributeError
> > +-- NameError
> > +-- UnboundLocalError
> > +-- RuntimeError
> > +-- NotImplementedError
>
> Time to wade in
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.:
>
>
. =)
--
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
.. co
On 8/2/05, Raymond Hettinger <[EMAIL PROTECTED]> 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 prematu
On 8/3/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > +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.
>
> I gue
On 8/3/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:10 PM 8/3/2005 +1000, Nick Coghlan wrote:
> > New exceptions:
> > - Raisable (new base)
> > - ControlFlow (inherits from Raisable)
> > - CriticalError (inherits from Raisable)
> > - GeneratorExit (inherits from
On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So here's a radical proposal (hear the scratching of the finglernail
> on the blackboard? :-).
>
> Start with Brett's latest proposal.
Including renaming (I want to know if you support the renamings at
all, if I should make them more of an
On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/3/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > So here's a radical proposal (hear the scratching of the finglernail
> > &
On 8/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Guido van Rossum <[EMAIL PROTECTED]> writes:
>
> > So here's a radical proposal (hear the scratching of the finglernail
> > on the blackboard? :-).
> >
> > Start with Brett's latest proposal. Goal: keep bare "except:" but
> > change it to catc
On 8/3/05, Russell E. Owen <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Brett Cannon <[EMAIL PROTECTED]> wrote:
>
> > New Hierarchy
> > =
> >
> > Exception
[SNIP]
> > +-- StandardError
[SNIP]
> > +
On 8/3/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote:
> > [...brain hums...]
> >
> > OK, I'm changing my mind again about the names again.
> >
> > Exception as the root and StandardError can stay; the only new
> > proposal would then be to make b
On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Guido van Rossum]
> > > OK, I'm changing my mind again about the names again.
> > >
> > > Exception as the root and StandardError can stay; the only new
> > > proposal would then be to make bare 'except:' call StandardError.
>
> [James Y Kn
OK, once the cron job comes around and is run,
http://www.python.org/peps/pep-0348.html will not be a 404 but be the
latest version of the PEP.
Differences since my last public version is that it has
BaseException/Exception as the naming hierarchy, Warning inherits from
Exception, UserException is
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The PEP moves StopIteration out from under Exception so that it cannot
> be caught by a bare except or an explicit "except Exception".
>
> IMO, this is a mistake. In either form, a programmer is stating that
> they want to catch and handle
On 8/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote (in the PEP):
> > KeyboardInterrupt inheriting from ControlFlowException
> >
> > KeyboardInterrupt has been a contentious point within this hierarchy. Some
> > view the exception as more cont
On 8/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Since I forgot to mention it in the last couple of messages - this version
> looks very good. The transition strategy section makes it a lot more
> meaningful.
>
Great to hear!
> Brett Cannon wrote (in the PEP):
&
On 8/4/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> >+-- NamespaceError (rename of NameError)
> >+-- UnboundFreeError (new)
> >+-- UnboundGlobalError (new)
> >+-- UnboundLocalError
> >
>
> What are these new exceptions for? Under what circumstances ar
On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> In general the PEP looks really good now!
>
Glad you like it.
> On 8/4/05, Willem Broekema <[EMAIL PROTECTED]> wrote:
> > On 8/4/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > > OK, once the cr
On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> This does contradict my earlier claim that Python itself doesn't use
> RuntimeError; I think I'd be happier if it remained RuntimeError. (I
> think there are a few more uses of it inside Python itself; I don't
> think it's worth inventing ne
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [ Guido]
> > One more thing. Is renaming NameError to NamespaceError really worth
> > it? I'd say that NameError is just as clear.
>
> +1 on NameError -- it's clear, easy to type, isn't a gratuitous change,
> and doesn't make you think twic
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Also strong -1 on renaming RuntimeWarning to SemanticsWarning.
>
> Besides being another unnecessary change (trying to solve a non-existent
> problem), this isn't an improvement. The phrase RuntimeWarning is
> sufficiently generic to allow
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > When a user creates their own exception for exiting multiple levels
> of
> > > loops or frames, should they inherit from ControlFlowException on
> the
> > > theory that it no different in intent from StopIteration or should
> they
> > >
On 8/5/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[SNIP]
> Those legitimate uses often need to make a special case of
> Keyboardinterrupt and SystemExit -- KeyboardInterrupt because it's not
> a bug in the code but a request from the user who is *running* the app
> (and the appropriate default
On 8/5/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/5/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > This does contradict my earlier claim that Python itself doesn't use
&
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > On 8/4/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> > > >+-- NamespaceError (rename of NameError)
> > > >+-- UnboundFreeError (new)
> > > >+-- UnboundGlobalError (new)
> > > >+-- UnboundLocalE
On 8/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/6/05, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> > PEP 8 doesn't express any preference between the
> > two forms of raise statements:
> > raise ValueError, 'blah'
> > raise ValueError("blah")
> >
> > I like the second form better, becau
Version 1.5 of PEP 348 (http://www.python.org/peps/pep-0348.html) just
got checked in. This one is a *big* change compared to the previous
version:
* Renamings removed
* SystemExit are the KeyboardInterrupt are the only exceptions *not*
inheriting from Exception
+ CriticalException has been r
On 8/7/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> VMError -- This is a new intermediate grouping so it won't break
> anything and it does bring together two exceptions relating them by
> source. However, I recommend against introducing this new group.
> Besides added yet another thing to r
On 8/7/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > * SystemExit are the KeyboardInterrupt are the only exceptions *not*
> > inheriting from Exception
> > + CriticalException has been renamed TerminalException so it is
> > more inline
On 8/7/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I have placed a new version of the PEP on
>
> http://www.python.org/peps/pep-0347.html
>
> Changes to the previous version include:
>
> - add more rationale for using svn (atomic changesets,
> fast tags and branches)
>
> - changed conv
On 8/7/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > What is going in under python/ ? If it is what is currently
> > /dist/src/, then great and the renaming of the repository works.
>
> Just have a look yourself :-) Yes, this is
On 8/8/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> I can't think of a Python feature with a higher aggregate
> braincell_burned / benefit ratio than __del__ methods. If P3K retains
> them-- or maybe even before --we should consider taking "the Java
> dodge" on this one. That is, decree that henc
version 1.7 scales the proposal back once more
(http://www.python.org/peps/pep-0348.html). At this point the only
changes to the hierarchy are the addition of BaseException and
TerminatingException, and the change of inheritnace for
KeyboardInterrupt, SystemExit, and NotImplementedError. At this
On 8/8/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Brett Cannon]
> > At this point the only
> > changes to the hierarchy are the addition of BaseException and
> > TerminatingException, and the change of inheritnace for
> > KeyboardInterrupt, Sy
On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > WindowsError
> > >
> > >
> > > This should be kept. Unlike module specific exceptions, this
> exception
> > > occurs in multiple places and diverse applications. It is
> appropriate
> > > to list as a builtin.
> > >
> > >
On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > Then I don't follow what you mean by "moved under os".
> >
> > In other words, to get the exception, do ``from os import
> > WindowsError``. Unfortunately we don't have a generic win module to
> > put it under. Maybe in the platform m
On 8/10/05, Aahz <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 10, 2005, Brett Cannon wrote:
> > On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >>
> >> If the name bugs you, I would support renaming it to PlatformError or
> >> somesuch. Tha
On 8/11/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote:
> > Remember, the Exception reorganization is for Python 3.0/3k/whatever,
> > not for 2.5 .
>
> Huh, I could *swear* we were talking about fixing things for
> 2.5...but I see at least the cur
On 8/12/05, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Brett Cannon <[EMAIL PROTECTED]> writes:
>
> > On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >> > > Then I don't follow what you mean by "moved under os".
> >&g
On 8/14/05, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a
> checkout that is less than two hours old. I'm building a standard
> unix tree (no framework install):
>
> $ ./configure --prefix=/opt/python/2.5
> ...
> $ make
> ...
>
I am sure people mainly care about the big changes inroduced by
revision 1.8 of the PEP (http://www.python.org/peps/pep-0348.html).
So, first is that WindowsError is staying. Enough people want it to
stay and have a legitimate use that I removed the proposal to ditch
it.
Second, I changed the ba
OK, I will take this as BDFL pronouncement that ditching bare
'except's is just not going to happen. Had to try. =)
And I will strip out the TerminatingException proposal.
-Brett
On 8/15/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm with Raymond here.
>
> On 8/15/05, Raymond Hettinger
On 8/15/05, Toby Dickenson <[EMAIL PROTECTED]> wrote:
> On Monday 15 August 2005 14:16, Raymond Hettinger wrote:
>
> > -1 on replacing "except (KeyboardInterrupt, SystemExit)" with "except
> > TerminatingException".
>
> The rationale for including TerminatingException in the PEP would also be
> s
OK, TerminatingException and the removal of bare 'except' clauses are now out.
I also stripped out the transition plan to basically just add
BaseException in Python 2.5, tweak docs to recommend future-proof
practices, and then change everything in Python 3.0 . This will
prevent any nasty performa
On 8/17/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-17 at 12:37, Jeremy Hylton wrote:
> > I'd like to see the builtin id() removed so that I can use it as a
> > local variable name without clashing with the builtin name. I
> > certainly use the id() function, but not as often as
On 8/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/18/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > As for the more general proposal: -1 on more places to pass strings to
> > denote method/function/class names. These are ugly to type.
>
> Agreed.
>
> > What I think you want is
On 8/18/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Oh, when should we think of putting reduce into functional? I
> > remember this was discussed when it was realized reduce was the only
> > functional built-in that is not covered by ite
On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/24/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> > I think it must be the case that raising an object which does not
> > derive from an exception class must be deprecated as well in order
> > for "except:" to be deprecated. Otherwise,
On 8/24/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/24/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> > Explicit is better than Implicit. I think that in newly written code
> > "except Exception:" is better (more explicit and easier to understand)
> > than "except:" Legacy code that
The PEP has been rejected.
-Brett
On 8/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> > I wish Fredrik would chime in. He would
> > have something pithy, angry, and incisive to say about this.
>
> Raymond, I'm sick of the abuse
On 8/26/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/26/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
> > Can str.find be listed in PEP 3000 (under builtins) for removal?
>
> Yes please. (Except it's not technically a builtin but a string method.)
>
Done. Added an "Atomic Types" section
On 9/5/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote:
>
> > We could decide not to provide (b) directly, since it is easily
> > reduced to (c) using an appropriate format string ("%s" times the
> > number of arguments). But I expect that use case
On 9/8/05, Tony Meyer <[EMAIL PROTECTED]> wrote:
> [finding Tools/i18n/pygettext.py]
> > You're right, I think Tools is probably a bad place for
> > anything. If it's not part of the stdlib, I'll likely never
> > find it.
>
> Agreed. Maybe with the introduction of -m in Python 2.4, some of the T
3101 - 3200 of 3314 matches
Mail list logo
