Re: [Python-Dev] python-dev Summary for 2005-03-01 through 2005-03-15 [draft]

2005-03-19 Thread Brett Cannon
[Nick Coghlan] - sum() semantics discussed - Guido's blog entry on `the fate of reduce() in Python 3000`_ (which reiterated Guido's plan to cut map(), reduce(), filter() and lambdas (what about zip()?) caused a huge discussion on whether sum()

Re: [Python-Dev] python-dev Summary for 2005-03-01 through 2005-03-15 [draft]

2005-03-19 Thread Brett Cannon
[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

Re: [Python-Dev] Terminology for PEP 343

2005-06-30 Thread Brett Cannon
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(),

Re: [Python-Dev] Terminology for PEP 343

2005-07-01 Thread Brett Cannon
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

Re: [Python-Dev] Chaining try statements: eltry?

2005-07-07 Thread Brett Cannon
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

[Python-Dev] Another SoC student for CVS access

2005-07-07 Thread Brett Cannon
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

Re: [Python-Dev] Another SoC student for CVS access

2005-07-07 Thread Brett Cannon
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

[Python-Dev] checklist for filing a bug

2005-07-07 Thread Brett Cannon
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

Re: [Python-Dev] Possible context managers in stdlib

2005-07-08 Thread Brett Cannon
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

Re: [Python-Dev] Another SoC student for CVS access

2005-07-13 Thread Brett Cannon
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

Re: [Python-Dev] [Python-checkins] python/dist/src/Miscdevelopers.txt, 1.15, 1.16

2005-07-14 Thread Brett Cannon
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

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

2005-07-28 Thread Brett Cannon
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

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

2005-07-29 Thread Brett Cannon
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

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

2005-07-30 Thread Brett Cannon
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

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

2005-07-30 Thread Brett Cannon
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

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

2005-07-30 Thread Brett Cannon
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

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

2005-07-30 Thread Brett Cannon
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

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

2005-07-30 Thread Brett Cannon
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

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

2005-07-30 Thread Brett Cannon
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

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

2005-07-30 Thread Brett Cannon
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

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

2005-07-30 Thread Brett Cannon
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

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

2005-07-30 Thread Brett Cannon
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

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

2005-07-31 Thread Brett Cannon
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

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

2005-07-31 Thread Brett Cannon
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

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

2005-08-01 Thread Brett Cannon
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

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

2005-08-03 Thread Brett Cannon
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

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

2005-08-03 Thread Brett Cannon
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

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

2005-08-03 Thread Brett Cannon
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

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

2005-08-03 Thread Brett Cannon
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

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

2005-08-03 Thread Brett Cannon
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:'

[Python-Dev] Exception Reorg PEP checked in

2005-08-03 Thread Brett Cannon
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

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

2005-08-05 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP checked in

2005-08-05 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP checked in

2005-08-05 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP checked in

2005-08-05 Thread Brett Cannon
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

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

2005-08-05 Thread Brett Cannon
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

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

2005-08-05 Thread Brett Cannon
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

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

2005-08-05 Thread Brett Cannon
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

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

2005-08-05 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP checked in

2005-08-05 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP checked in

2005-08-05 Thread Brett Cannon
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

Re: [Python-Dev] PEP 8: exception style

2005-08-06 Thread Brett Cannon
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

[Python-Dev] Major revision of PEP 348 committed

2005-08-06 Thread Brett Cannon
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

Re: [Python-Dev] Major revision of PEP 348 committed

2005-08-07 Thread Brett Cannon
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

Re: [Python-Dev] Major revision of PEP 348 committed

2005-08-07 Thread Brett Cannon
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

Re: [Python-Dev] PEP 347: Migration to Subversion

2005-08-07 Thread Brett Cannon
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

Re: [Python-Dev] PEP 347: Migration to Subversion

2005-08-08 Thread Brett Cannon
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

Re: [Python-Dev] __traceback__ and reference cycles

2005-08-08 Thread Brett Cannon
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

[Python-Dev] Exception Reorg PEP revised yet again

2005-08-08 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP revised yet again

2005-08-09 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP revised yet again

2005-08-10 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP revised yet again

2005-08-10 Thread Brett Cannon
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?

Re: [Python-Dev] Exception Reorg PEP revised yet again

2005-08-10 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP revised yet again

2005-08-11 Thread Brett Cannon
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

Re: [Python-Dev] Exception Reorg PEP revised yet again

2005-08-12 Thread Brett Cannon
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

[Python-Dev] PEP 348 (exception reorg) revised again

2005-08-14 Thread Brett Cannon
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

Re: [Python-Dev] PEP 348 (exception reorg) revised again

2005-08-15 Thread Brett Cannon
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

Re: [Python-Dev] PEP 348 (exception reorg) revised again

2005-08-15 Thread Brett Cannon
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

[Python-Dev] rev. 1.9 of PEP 348: Raymond tested, Guido approved

2005-08-16 Thread Brett Cannon
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

Re: [Python-Dev] PEP 309: Partial method application

2005-08-18 Thread Brett Cannon
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

Re: [Python-Dev] PEP 309: Partial method application

2005-08-18 Thread Brett Cannon
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

Re: [Python-Dev] Bare except clauses in PEP 348

2005-08-24 Thread Brett Cannon
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

Re: [Python-Dev] Remove str.find in 3.0?

2005-08-27 Thread Brett Cannon
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

Re: [Python-Dev] Replacement for print in Python 3.0

2005-09-05 Thread Brett Cannon
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

Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)

2005-09-08 Thread Brett Cannon
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/

Re: [Python-Dev] python optimization

2005-09-15 Thread Brett Cannon
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

[Python-Dev] removing nested tuple function parameters

2005-09-17 Thread Brett Cannon
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

Re: [Python-Dev] test__locale on Mac OS X

2005-09-18 Thread Brett Cannon
[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?

Re: [Python-Dev] removing nested tuple function parameters

2005-09-19 Thread Brett Cannon
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

Re: [Python-Dev] and and or operators in Py3.0

2005-09-19 Thread Brett Cannon
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

Re: [Python-Dev] and and or operators in Py3.0

2005-09-19 Thread Brett Cannon
On 9/19/05, Raymond Hettinger [EMAIL PROTECTED] wrote: I propose that in Py3.0, the and and or operators be simplified to always return a Boolean value instead of returning the last evaluated argument. 1) The construct can be error-prone. When an error occurs it can be invisible to the

Re: [Python-Dev] and and or operators in Py3.0

2005-09-20 Thread Brett Cannon
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

Re: [Python-Dev] Adding a conditional expression in Py3.0

2005-09-20 Thread Brett Cannon
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

Re: [Python-Dev] GIL, Python 3, and MP vs. UP

2005-09-20 Thread Brett Cannon
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

Re: [Python-Dev] and and or operators in Py3.0

2005-09-21 Thread Brett Cannon
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

Re: [Python-Dev] Conditional Expression Resolution

2005-09-30 Thread Brett Cannon
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

Re: [Python-Dev] Python 2.5 and ast-branch

2005-10-05 Thread Brett Cannon
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

Re: [Python-Dev] Python 2.5 and ast-branch

2005-10-06 Thread Brett Cannon
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

Re: [Python-Dev] PEP 3000 and exec

2005-10-10 Thread Brett Cannon
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

Re: [Python-Dev] Fwd: defaultproperty

2005-10-10 Thread Brett Cannon
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

Re: [Python-Dev] PEP 3000 and exec

2005-10-10 Thread Brett Cannon
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

Re: [Python-Dev] Migrating to subversion

2005-10-18 Thread Brett Cannon
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

Re: [Python-Dev] Conversion to Subversion is complete

2005-10-27 Thread Brett Cannon
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

Re: [Python-Dev] Conversion to Subversion is complete

2005-10-27 Thread Brett Cannon
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

Re: [Python-Dev] Conversion to Subversion is complete

2005-10-27 Thread Brett Cannon
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

[Python-Dev] PEP 352: Required Superclass for Exceptions

2005-10-27 Thread Brett Cannon
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,

Re: [Python-Dev] Conversion to Subversion is complete

2005-10-28 Thread Brett Cannon
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

Re: [Python-Dev] PEP 352: Required Superclass for Exceptions

2005-10-28 Thread Brett Cannon
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

Re: [Python-Dev] PEP 352 Transition Plan

2005-10-28 Thread Brett Cannon
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

Re: [Python-Dev] PEP 352: Required Superclass for Exceptions

2005-10-28 Thread Brett Cannon
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

Re: [Python-Dev] PEP 352: Required Superclass for Exceptions

2005-10-28 Thread Brett Cannon
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

Re: [Python-Dev] PEP 352 Transition Plan

2005-10-28 Thread Brett Cannon
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

Re: [Python-Dev] cross-compiling

2005-11-07 Thread Brett Cannon
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

Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks

2005-11-09 Thread Brett Cannon
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

Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks

2005-11-09 Thread Brett Cannon
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

Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks

2005-11-09 Thread Brett Cannon
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

Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks

2005-11-09 Thread Brett Cannon
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

[Python-Dev] dev FAQ updated with day-to-day svn questions

2005-11-09 Thread Brett Cannon
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

Re: [Python-Dev] dev FAQ updated with day-to-day svn questions

2005-11-10 Thread Brett Cannon
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

Re: [Python-Dev] dev FAQ updated with day-to-day svn questions

2005-11-10 Thread Brett Cannon
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

  1   2   3   4   5   6   7   8   9   10   >