[Paul Moore]
On Thu, 17 Mar 2005 18:21:33 -0800, Brett C. [EMAIL PROTECTED] wrote:
2.4.1 should be out soon
Python 2.4.1c1 is out. Very shortly c2 will be released. Assuming no major
issues come up, 2.4 final will be out.
You probably mean
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.Context(),
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++ and the
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 could be
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
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
thus take care of the licensing problem. He also hopes
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
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 module
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 will be no more need
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 permissions to be
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.
, and on
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 Cannon [EMAIL PROTECTED
On 7/29/05, Robert Brewer [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
New Hierarchy
=
Raisable (new; rename BaseException?)
+-- CriticalException (new)
+-- KeyboardInterrupt
+-- MemoryError
+-- SystemExit
+-- SystemError (subclass SystemExit?)
I'd
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 subclassing
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 StopIteration and
GeneratorExit should be inheriting from
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 reorganizing exceptions for Python 3.0 .
Key points
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 doesn't
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 applications
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 loving your newfangled idea
10x more
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 code, I expect changing its name would be more pain
than
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
probably
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
CriticalError and Error actually ends with the word 'Error'.
I
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 needs to stop because an serious event
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 ...
I've
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 idea
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 the blackboard? :-).
Start with Brett's latest proposal
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]
+-- EnvironmentError
+-- OSError
+-- IOError
+-- EOFError
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 bare 'except:'
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
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 just
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 control flow being caused by the user
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):
Renamed Exceptions
Renamed
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 new
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 twice about
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 it to
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
inherit from
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
RuntimeError; I think I'd be happier if it remained
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)
+-- UnboundLocalError
What
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, because if the
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
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
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 with the idea that the exceptions are meant
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 conversion
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 dist/src.
Ah, OK. I didn't drill far enough
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 henceforth
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, SystemExit, and NotImplementedError
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.
Too O/S specific is not a
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 module instead?
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. That would make it free for use with Mac errors and Linux
errors
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 current
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.
In other words, to get the exception, do ``from os import
WindowsError
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
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
satisfied by
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
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 not a partial
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 itertools or listcomps.
I expected
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, there is
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 to the PEP
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 (b) is
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 Tools/
On 9/15/05, Neal Becker [EMAIL PROTECTED] wrote:
I use cpython. I'm accustomed (from c++/gcc) to a style of coding that is
highly readable, making the assumption that the compiler will do good
things to optimize the code despite the style in which it's written. For
example, I assume
Is anyone truly attached to nested tuple function parameters; ``def
fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed
okay with just having them removed when Jeremy asked about ditching
them thanks to the pain they caused in the AST branch. I personally
don't see them being
[forgot to CC python-dev]
On 9/18/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
test__locale still fails for me on Mac OS X 10.3.9. This is on both the 2.4
branch and HEAD. Does it succeed for anyone on 10.4? If not, perhaps we
should list that as an expected failure on that platform?
On 9/18/05, Greg Ewing [EMAIL PROTECTED] wrote:
François Pinard wrote:
The only practical reason to like this feature is sparing the need of
finding an otherwise useless name for the formal argument.
If the argument represents a coherent enough concept
to be passed in as a tuple in the
On 9/19/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote:
While you're at it, maybe we should switch to and || as well?
That's another thing I always mistype when switching between
languages...
Please no! 'and' and 'or' is so readably
On 9/20/05, Michael Hudson [EMAIL PROTECTED] wrote:
[SNIP]
I _like_ the explanation of 'and' and 'or' as they are now. They are
basically control flow constructs -- and have to be to get
short-circuiting to work -- and adding a coercion to bool at the end
seems to add complexity, not reduce
On 9/20/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use
On 9/20/05, John J Lee [EMAIL PROTECTED] wrote:
On Mon, 19 Sep 2005, Florian Weimer wrote:
The real problem is that you can ditch most extension modules. 8-(
[...]
*Is* that a showstopper for Python 3.0, though?
Who knows. I bet Guido doesn't even know how much breakage he is
going to
On 9/21/05, Michael Hudson [EMAIL PROTECTED] wrote:
Brett Cannon [EMAIL PROTECTED] writes:
On 9/20/05, Michael Hudson [EMAIL PROTECTED] wrote:
[SNIP]
I _like_ the explanation of 'and' and 'or' as they are now. They are
basically control flow constructs -- and have to be to get
short
On 9/29/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[SNIP]
Flames, pleas to reconsider, etc., to /dev/null.
Congratulations gracefully accepted.
And gladly given! All proposals should be resolved this cleanly in the end.
It's still my language! :-)
Yes it is, thank goodness!
-Brett
To answer Nick's email here, I didn't respond to that initial email
because it seemed specifically directed at Guido and not me.
On 10/5/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 10/5/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Anyway, the question is: What do we want to do with
On 10/6/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Kurt]
Unless I'm missing something, we would need to merge HEAD to the AST
branch once more to pick up the changes in MAIN since the last merge,
and then make sure everything in the AST branch is passing the test
suite. Otherwise
On 10/10/05, Christos Georgiou [EMAIL PROTECTED] wrote:
This might be minor-- but I didn't see anyone mentioning it so far. If
`exec` functionality is to be provided, then I think it still should be a
keyword for the parser to know; currently bytecode generation is affected if
`exec` is
On 10/10/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2005-10-10 at 01:47, Calvin Spealman wrote:
Never created for a reason? lumping things together for having the
similar usage semantics, but unrelated purposes, might be something to
avoid and maybe that's why it hasn't happened yet
On 10/10/05, Greg Ewing [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
But the better answer is we will just find a way. =)
I think the best answer would be just to dump the idea of
exec-in-local-namespace altogether. I don't think I've
ever seen a use case for it that wasn't better done
On 10/18/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Martin If people want to test the installation before the switch
Martin happens, this would be the time to do it.
Martin,
Can you let us know again the magic incantation to check out the source from
the repository?
And any
On 10/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[SNIP]
Most of you are probably interested in checking out one of these
folders:
svn+ssh://[EMAIL PROTECTED]/python/trunk
svn+ssh://[EMAIL PROTECTED]/python/branches/release24-maint
svn+ssh://[EMAIL PROTECTED]/peps
Why the entire
I have started a svn section in the dev FAQ
(http://www.python.org/dev/devfaq.html) pertaining to checking out a
project from the repository and other stuff discussed so far. If
something is not clear or people feel a step is missing, let me know.
I will remove the CVS section once Martin has
On 10/27/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Brett I have started a svn section in the dev FAQ
Brett (http://www.python.org/dev/devfaq.html) pertaining to checking
Brett out a project from the repository and other stuff discussed so
Brett far. If something is not
Well, I am at it again, but this time Guido is a co-conspirator. We
wrote a PEP that introduces BaseException and moves KeyboardInterrupt
and SystemExit. Even if you followed the discussion for PEP 348 you
should read the PEP since I am sure there will be something that
someone doesn't like,
On 10/27/05, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Thursday 27 October 2005 23:03, Brett Cannon wrote:
I guess, but I just don't like wikis personally so I have no
inclination to make the conversion. If someone wants to make the
conversion over to the wiki and keep it up that's
On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
Anyway, as soon as the cron job posts the PEP to the web site (already
checked into the new svn repository) have a read and start expounding
about how wonderful
On 10/28/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
Why would a
release allow catching something that cannot be raised? I must be
missing something here.
So conforming code can catch exceptions raised by not-yet conforming
code.
That makes sense.
What was the rationale for
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Nick got the python-checkins email and then read the PEP from the
repository (or at least that is what I assume since that is how Neal
managed to catch the PEP
On 10/28/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Trying to cut this short... We have too many threads for this topic. :-( ]
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
[on making args b/w compatible]
I agree changing the behaviour is highly unlikely to cause any serious
On 10/28/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
Interesting point, but I think that chaining should have more concrete
support ala PEP 344 or some other mechanism. I think most people
agree that exception chaining is important enough to have better
support than
On 11/7/05, Neal Norwitz [EMAIL PROTECTED] wrote:
We've been having some issues and discussions at work about cross
compiling. There are various people that have tried (are) cross
compiling python. Right now the support kinda sucks due to a couple
of reasons.
This might make a good sprint
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Maybe it makes more sense to deprecate .pyo altogether and instead
have a post-load optimizer optimize .pyc files according to the
current optimization settings?
But I thought part of the point of .pyo files was that they left out
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 11/9/05, Brett Cannon [EMAIL PROTECTED] wrote:
Plus I wouldn't be
surprised if we started to move away from bytecode optimization and
instead tried to do more AST transformations which would remove
possible post-load optimizations
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Guido]
However, this would be a major pain for the standard library and other
shared code -- there it's really nice to have a cache for each of the
optimization levels since usually regular users can't write the
.py[co] files
On 11/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I like Phillip's suggestion -- no new opcode, just a conditional jump
that can be easily optimized out.
Huh? But Phillip is suggesting a new opcode that is essentially the
same as my proposal but naming it differently and saying
I just finished fleshing out the dev FAQ
(http://www.python.org/dev/devfaq.html) with questions covering what
someone might need to know for regular usage. If anyone thinks I
didn't cover something I should have, let me know.
-Brett
___
Python-Dev
On 11/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
I just finished fleshing out the dev FAQ
(http://www.python.org/dev/devfaq.html) with questions covering what
someone might need to know for regular usage. If anyone thinks I
didn't cover something I should have, let
On 11/10/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
I just finished fleshing out the dev FAQ
(http://www.python.org/dev/devfaq.html) with questions covering what
someone might need to know for regular usage. If anyone thinks I
didn't cover something I should have, let
On 11/13/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Thomas Lee wrote:
Implemented as you suggested and tested. I'll submit the patch to the
tracker on sourceforge shortly. Are you guys still after contextual
diffs as per the developer pages, or is an svn diff the preferred way to
submit
On 11/16/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Thomas Lee wrote:
Even if it meant we had just one function call - one, safe function call
that deallocated all the memory allocated within a function - that we
had to put before each and every return, that's better than what we
have.
On 11/16/05, Thomas Lee [EMAIL PROTECTED] wrote:
Just messing around with some ideas. I was trying to avoid the ugly
macros (note my earlier whinge about a learning curve) but they're the
cleanest way I could think of to get around the problem without
resorting to a mass deallocation right at
1 - 100 of 3172 matches
Mail list logo
