On Sun, 2005-03-06 at 14:16, "Martin v. Löwis" wrote:
> I don't know whether anybody has done this before,
> but I just tried to run cvs2svn on the Python repository.
> The conversion took 7 hours, and the result is now
> available at
>
> http://www.dcl.hpi.uni-potsdam.de/python/branches/
>
> Bec
On Wed, 2005-03-09 at 07:17, Anthony Baxter wrote:
> So it's only fair that I write down my rationale for why I'm being anal
> about the no-new-features approach. Comments are more than welcome -
> ideally, after discussion, I'll put some more words in the bugfix PEP.
I applaud your strictness Ant
On Wed, 2005-03-09 at 19:39, Tommy Burnette wrote:
> I'd say I'm +0. fwiw- I've been using a locally-rolled OrderedDict
> implementation for the last 5-6 years in which insertion order is the
> only order respected. I use it all over the place (in a code base of
> ~60k lines of python code).
>
>
On Thu, 2005-03-10 at 01:29, Raymond Hettinger wrote:
> Or the implementation can have a switch to choose between keep-first
> logic or replace logic.
This is what I meant by my previous follow up: while the concept of "an
ordered dictionary" is nice and seemingly generic enough, in practice I
su
On Thu, 2005-03-10 at 23:46, Glyph Lefkowitz wrote:
> That way instead of multi-line "except NameError" tests all over the
> place you can simply have one-liner boilerplate for every module in your
> project:
>
> 'from py24compat import *'
>
> Easy to grep/sed for when you're ready to st
On Fri, 2005-03-11 at 06:43, Peter Astrand wrote:
> Even though you can use them as variables (and shadow the builtins), you
> will still get warnings from "pychecker". The code will also be harder to
> read: When you see "all" in the middle of some code, you don't know if
> it's referring to the
On Fri, 2005-03-11 at 12:18, Raymond Hettinger wrote:
> I suspect that lambda will be the only bone of contention. The reduce()
> function can be moved to the functional module. The map() and filter()
> functions are already covered by the itertools module.
I'm fine seeing reduce() eventually g
On Fri, 2005-03-11 at 12:40, M.-A. Lemburg wrote:
> While I'm no fan of lambdas either, the removal would break too
> much code (e.g. I have 407 hits in the code base I use regularly
> alone).
We /are/ talking Python 3000 here, right? I'm expecting all manner of
code breakage in moving from Pyth
On Fri, 2005-03-11 at 14:29, Jim Jewett wrote:
> Is that so bad?
>
> If you plan to use them often, then
>
> from itertools import any, every
+1
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing l
On Fri, 2005-03-18 at 01:19, Andrew McNamara wrote:
> No, exceptions are fast at the C level - all they do is set a flag. The
> expense of exceptions is saving a restoring python frames, I think,
> which doesn't happen in this case. So the current implementation is
> ideal for C code - clear and f
On Sun, 2005-03-27 at 20:55, Adam MacBeth wrote:
> Has anyone ever considered using SCons to build Python? SCons is a
> great build tool written in Python that provides some Autoconf-like
> functionality (http://www.scons.org). It seems like this type of
> self-hosting would be a great testament to
On Tue, 2005-04-05 at 19:06, Fred Drake wrote:
> Would anyone here object to renaming the file to developers.txt, though?
+1, please!
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@pyt
On Thu, 2005-04-07 at 10:58, Raymond Hettinger wrote:
> Ben Gertzfield
Ben did a lot of work on the i18n parts of the email package. I haven't
heard from him in quite a while.
> Ken Manheimer
Ken's still around. I'll send you his current email address in a
separate (pvt) message.
-Barry
On Wed, 2005-04-13 at 15:54, Brett C. wrote:
> I thought at one point this question came up and the general consensus was
> that
> unified diffs were preferred?
Back in the day, we preferred context diffs, and I think of the original
Python core group, Guido was the last holdout. But IIRC, a fe
I've noticed an apparent inconsistency in the exception thrown for
read-only properties for C extension types vs. Python new-style
classes. I'm wondering if this is intentional, a bug, a bug worth
fixing, or whether I'm just missing something.
class other(object):
def __init__(self, value):
On Thu, 2005-04-14 at 23:46, Barry Warsaw wrote:
> I've noticed an apparent inconsistency in the exception thrown for
> read-only properties for C extension types vs. Python new-style
> classes.
I haven't seen any follow ups on this, so I've gone ahead and posted a
patch,
On Sun, 2005-04-17 at 11:53, Jack Diederich wrote:
> In 2.4 & 2.3 does it make sense to raise an exception that multiply inherits
> from both TypeError and AttributeError? If anyone currently does catch the
> error raising only AttributeError will break their code. 2.5 should just
> raise an Att
On Sun, 2005-04-17 at 12:25, Aahz wrote:
> Why is changing an exception more acceptable than creating a new one?
> (I don't have a strong opinion either way, but I'd like some reasoning;
> Jack's approach at least doesn't break code.) Especially if the new
> exception isn't "public" (in the built
On Sun, 2005-04-17 at 14:36, Guido van Rossum wrote:
> Personally, I think it would be fine to just change the TypeError to
> AttributeError. I expect that very few people would be hurt by that
> change (they'd be building *way* too much specific arcane knowledge
> into their program if they had c
On Sun, 2005-04-17 at 15:44, Guido van Rossum wrote:
> You meant 2.5 only of course. It's still a new feature and as such
> can't be changed in 2.4.
Fair enough.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev
On Tue, 2005-04-19 at 15:24, Guido van Rossum wrote:
> *If* we're going to create syntax for anonymous blocks, I think the
> primary use case ought to be cleanup operations to replace try/finally
> blocks for locking and similar things. I'd love to have syntactical
> support so I can write
>
> bl
On Wed, 2005-04-20 at 14:32, Fredrik Lundh wrote:
> > File "C:\Code\python\lib\test\test_csv.py", line 58, in _test_default_attrs
> >self.assertRaises(TypeError, delattr, obj.dialect, 'quoting')
> > File "C:\Code\python\lib\unittest.py", line 320, in failUnlessRaises
> >callableObj(*args,
On Wed, 2005-05-04 at 13:09, Guido van Rossum wrote:
> Nice one. Should be a piece of cake to implement. Please talk to
> [EMAIL PROTECTED] about getting it checked into the PEP database.
+1!
-Barry
signature.asc
Description: This is a digitally signed message part
On Wed, 2005-05-04 at 14:41, Tim Peters wrote:
> IIRC (and I may well not), half of people guessed wrong about whether
> an exception raised in an "except:" suite would or would not skip
> execution of the same-level "finally:" suite.
It would not, obviously .
> try:
> 1/0
> except DivisionB
In setobject.c rev 1.26 + 1.27 Raymond removed gc support from built-in
set objects, claiming in the log message that "sets cannot have
cycles". Yet the attached program creates a cycle that I don't believe
ever gets reclaimed.
Patch 1200018 restores GC support to set objects for Python 2.4. Tha
On Mon, 2005-06-06 at 14:38, Skip Montanaro wrote:
> import urllib
> from www.urllib import urlopen
>
> the module-level code should only be executed once, and
>
> urlopen == urllib.urlopen
>
> should evaluate to True.
Not to mention "urlopen is urllib.urlopen"
-Barry
signature
On Fri, 2005-06-10 at 16:23, Guido van Rossum wrote:
> While there's still some activity in the Wiki, nothing (to me) sounds
> like signs of serious disagreement or truly better alternatives. So I
> think I'd like to move forward towards acceptance soon (before
> EuroPython).
Well, I finally read
On Sun, 2005-06-12 at 00:52, Nick Coghlan wrote:
> The idea behind 'with' is that the block is executed while holding
> (i.e. 'with') the resource.
>
> I think the '-ing' form of the example templates is a holdover from
> the days when the PEP used the 'do' keyword - I find that past tense
> o
On Fri, 2005-06-17 at 02:39, Raymond Hettinger wrote:
> While the majority of Python users deem this to be a nice-to-have
> feature
Really? Where's the supporting poll data? In over 10 years of Python
programming, I've never once needed a Roman number literal. Worse, I
don't buy the compatibili
On Fri, 2005-06-17 at 00:43, Raymond Hettinger wrote:
> Let me go on record as a strong -1 for "continue EXPR". The for-loop is
> our most basic construct and is easily understood in its present form.
> The same can be said for "continue" and "break" which have the added
> advantage of a near zer
On Fri, 2005-06-17 at 02:55, Raymond Hettinger wrote:
> After nine months, no support has grown beyond the original poster. The
> PEP did however generate some negative responses when brought-up on
> comp.lang.python (it made some people's stomach churn).
>
> The PEP fails the tests of obviousnes
On Fri, 2005-06-17 at 05:57, Raymond Hettinger wrote:
> This PEP has been open for two and half years without generating
> discussion or support.
Interesting. Just yesterday I wrote a simple stopwatch-like timer
script and I found that I needed three divmod calls to convert from
seconds into a da
On Mon, 2006-02-13 at 15:44 -0800, Guido van Rossum wrote:
> The right way to look at this is, as Phillip says, to consider
> conversion between str and bytes as not an encoding but a data type
> change *only*.
That sounds right to me too.
-Barry
signature.asc
Description: This is a digitally
On Feb 13, 2006, at 7:29 PM, Guido van Rossum wrote:
> There's one property that bytes, str and unicode all share: type(x[0])
> == type(x), at least as long as len(x) >= 1. This is perhaps the
> ultimate test for string-ness.
But not perfect, since of course other containers can contain objects
On Feb 14, 2006, at 6:35 AM, Greg Ewing wrote:
> Barry Warsaw wrote:
>
>> This makes me think I want an unsigned byte type, which b[0] would
>> return.
>
> Come to think of it, this is something I don't
> remember seeing discussed. I've been thinking
> th
On Tue, 2006-02-14 at 14:37 -0800, Alex Martelli wrote:
> What about shorter names, such as 'text' instead of 'opentext' and
> 'data' instead of 'openbinary'? By eschewing the 'open' prefix we
> might make it easy to eventually migrate off it. Maybe text and data
> could be two subclasses of file
On Tue, 2006-02-14 at 15:13 -0800, Guido van Rossum wrote:
> So I'm taking that the specific properties you want to model are the
> overflow behavior, right? N-bit unsigned is defined as arithmethic mod
> 2**N; N-bit signed is a bit more tricky to define but similar. These
> never overflow but ins
On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote:
> Regarding open vs. opentext, I'm still not sure. I don't want to
> generalize from the openbytes precedent to openstr or openunicode
> (especially since the former is wrong in 2.x and the latter is wrong
> in 3.0). I'm tempting to hold o
On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote:
> Maybe a weird idea, but why not use static methods on the
> bytes and str type objects for this ?!
>
> E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0
> renamed to str.openfile())
That's also not a bad idea, but I'd leave off o
On Wed, 2006-02-15 at 00:34 -0800, Brett Cannon wrote:
> I personally think we should choose an initial global access API to
> the AST as a starting API. I like the sys.ast_transformations idea
> since it is simple and gives enough access that whether read-only or
> read-write is allowed somethin
On Tue, 2006-02-14 at 21:24 -0800, Neal Norwitz wrote:
> We still need a release manager. No one has heard from Anthony. If
> he isn't interested is someone else interested in trying their hand at
> it? There are many changes necessary in PEP 101 because since the
> last release both python and
On Wed, 2006-02-15 at 19:02 +0100, M.-A. Lemburg wrote:
> Anyway, as long as we don't start adding openthis() and openthat()
> I guess I'm happy ;-)
Me too! :)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev
On Wed, 2006-02-15 at 14:01 -0500, Jason Orendorff wrote:
> Instead of byte literals, how about a classmethod bytes.from_hex(),
> which works like this:
>
> # two equivalent things
> expected_md5_hash =
> bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
> expected_md5_hash = bytes([92, 83,
On Wed, 2006-02-15 at 22:07 +0100, M.-A. Lemburg wrote:
> Those are not pseudo-encodings, they are regular codecs.
>
> It's a common misunderstanding that codecs are only seen as serving
> the purpose of converting between Unicode and strings.
>
> The codec system is deliberately designed to be
On Thu, 2006-02-16 at 01:09 +0100, Fredrik Lundh wrote:
> (but will there be a 2.6? isn't it time to start hacking on 3.0?)
We know at least there will never be a 2.10, so I think we still have
time.
-Barry
signature.asc
Description: This is a digitally signed message part
__
On Feb 16, 2006, at 2:05 AM, Talin wrote:
>
> Anyway, if anyone wants to play around with the patch, it is rather
> small - a couple of lines in Grammar, and a small new function in
> ast.c,
> plus a few mods to other functions to get them to call it. The context
> diff is less than two printed
On Sat, 2006-02-18 at 12:53 +0100, Pierre Barbier de Reuille wrote:
> > Guido> Over lunch with Alex Martelli, he proposed that a subclass of
> > Guido> dict with this behavior (but implemented in C) would be a good
> > Guido> addition to the language.
I agree that .setdefault() is a w
On Fri, 2006-02-17 at 11:09 -0800, Guido van Rossum wrote:
> Thanks for all the constructive feedback. Here are some responses and
> a new proposal.
>
> - Yes, I'd like to kill setdefault() in 3.0 if not sooner.
A worthy goal, but not possible unless you want to break existing code.
I don't thin
On Fri, 2006-02-17 at 00:43 -0500, Steve Holden wrote:
> Fredrik Lundh wrote:
> > Barry Warsaw wrote:
> >
> >
> >>We know at least there will never be a 2.10, so I think we still have
> >>time.
> >
> >
> > because there's no way
On Sun, 2006-02-19 at 23:30 +0900, Stephen J. Turnbull wrote:
> > "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> M> * for Unicode codecs the original form is Unicode, the derived
> M> form is, in most cases, a string
>
> First of all, that's Martin's point!
>
> Second, almost a
On Fri, 2006-02-17 at 14:01 +0100, Georg Brandl wrote:
> Fredrik Lundh wrote:
> > Georg Brandl wrote:
> >
> >> as Jim Jewett noted, multifile is supplanted by email as much as mimify
> >> etc.
> >> but it is not marked as deprecated. Should it be deprecated in 2.5?
> >
> > -0.5 (gratuitous break
On Tue, 2006-02-21 at 17:18 +0100, Georg Brandl wrote:
> > IIRC, when I brought this up ages ago, there was some grumbling that
> > multifile is useful for other than email/MIME applications. Still, I'm
> > +1 on PEP 4'ing it.
>
> Which means "go ahead" or "wait for others to be -1"?
s/or/and/
On Sat, 2006-02-18 at 14:44 +0100, M.-A. Lemburg wrote:
> In Py 2.5 we'll change that. The encodings package search
> function will only allow codecs in that package to be
> imported. All other codec packages will have to provide
> their own search function and register this with the
> codecs regi
Guido's on_missing() proposal is pretty good for what it is, but it is
not a replacement for set_default(). The use cases for a derivable,
definition or instantiation time framework is different than the
call-site based decision being made with setdefault(). The difference
is that in the former c
On Feb 23, 2006, at 4:41 PM, Thomas Wouters wrote:
> On Wed, Feb 22, 2006 at 10:29:08PM -0500, Barry Warsaw wrote:
>> d.getdefault('foo', list).append('bar')
>
>> Anyway, I don't think it's an either/or choice with Guido's subclass.
>>
On Feb 28, 2006, at 6:26 PM, Fredrik Lundh wrote:
>
> should we perhaps switch to (careful use of) C++ in 3.0 ?
I hope not. It would make life more difficult for embedded/extended
users like ourselves because it would force us to link our
applications as C++ programs. That introduces lots o
On Wed, 2006-03-01 at 11:00 -0800, Talin wrote:
> However, I would like to be able to reply to posts in such a way as to
> have them appear in the appropriate place in the thread hierarchy. Since
> I don't have the original email, I cannot reply to it directly; instead
> I have to create a new,
On Thu, 2006-03-02 at 07:26 -0800, Aahz wrote:
> On Wed, Mar 01, 2006, Guido van Rossum wrote:
> >
> > Operations with two or more arguments are often better expressed as
> > function calls -- for example, map() and filter() don't make much
> > sense as methods on callables or sequences.
>
> OTOH,
On Fri, 2006-03-03 at 13:06 -0800, Michael Chermside wrote:
> I think it's clear that if a method is invoked magically, it ought to have
> underscores; if it is invoked directly then it ought not to. next() is
> invoked both ways, so the question is which of the following invariants
> we would rat
On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote:
> OK, I tried to set eol-style on all of those. svn refused to change these:
>
> svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type property
Yeah, there's no reason for that, so I've fixed it.
-Barry
signature.asc
Description:
On Fri, 2006-03-03 at 23:43 -0500, Barry Warsaw wrote:
> On Wed, 2006-03-01 at 00:17 -0600, Tim Peters wrote:
> > OK, I tried to set eol-style on all of those. svn refused to change these:
> >
> > svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type
On Mon, 2006-03-06 at 14:26 -0500, Tim Peters wrote:
> [Ben Chelf <[EMAIL PROTECTED]>]
> > ...
> > I'd ask that if you are interested in really digging into the results a bit
> > further for your project, please have a couple of core maintainers (or
> > group nominated individuals) reach out to me
There are two patches on SF to add a couple of features to the gc
module. Skip wrote one (which I reviewed) and I wrote the other.
Neither is earth shattering, but they're helpful when debugging gc
issues.
Skips adds some timing output when DEBUG_STATS is set:
https://sourceforge.net/tracker/ind
On Mon, 2006-03-06 at 23:30 +, Neil Schemenauer wrote:
> Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > There are two patches on SF to add a couple of features to the gc
> > module. Skip wrote one (which I reviewed) and I wrote the other.
> > Neither is earth shatterin
On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote:
> IMO it shouldn't be fixed. Classic classes define their str to print
> the module name and class name with a dot in between; new-style
> classes use the same format as their repr. Making exceptions new-style
> classes is going to break a
On Fri, 2006-03-10 at 09:01 +0100, "Martin v. Löwis" wrote:
> I personally don't mind having the "upstream" ctypes repository also
> in svn.python.org; this would be similar to distutils, setuptools,
> and (I think) the email package. Currently, some of them live in
> sandbox/trunk, but I wouldn't
On Fri, 2006-03-10 at 11:25 -0600, Ian Bicking wrote:
> I'm not really making any actionable proposal here, so maybe this is
> off-topic; if so, sorry.
>
> Back during the defaultdict discussion I proposed a multidict object
> (http://mail.python.org/pipermail/python-dev/2006-February/061264.htm
On Fri, 2006-03-10 at 12:12 -0600, Ian Bicking wrote:
> There's already quite a few recipes out there. But I should probably
> collect them as well.
>
> http://www.voidspace.org.uk/python/odict.html
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/107747
> http://aspn.activestate.com/A
On Mon, 2006-03-13 at 23:06 -0500, Phillip J. Eby wrote:
> +1 on the idea, -1000 on the name. It's neither atomic nor a
> transaction. I believe that "critical section" is a more common term for
> what you're proposing.
>
> Probably the primitive could be placed in the thread or threading mod
On Mon, 2006-03-13 at 21:38 -0800, Neal Norwitz wrote:
> On 3/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> > Would it be a solution to move the 'official' ctypes development into
> > Python SVN external/ctypes, or would this be considered abuse? Another
> > location in SVN could be used as wel
On Wed, 2006-03-15 at 17:33 -0500, Jeremy Hylton wrote:
> On 3/15/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Well, absolute imports without the future statement will not use the
> > 5th argument, so they won't break, right? That's what MAL also says.
> > Someone please fix this.
>
> I'd m
On Thu, 2006-03-16 at 12:02 +0100, Fredrik Lundh wrote:
> a) sys.executable points to the executable that was used to load the
> Python interpreter library/dll.
>
> this use is supported by the docstring and the implementation, and is
> quite
> common in the wild. an application
Last night I merged email 4.0 from the sandbox into my working copy of
the Python svn trunk and ran "make testall". I hit one failure, in
test_pyclbr.py. The test was importing email.Parser and expecting a
real module, however in email 4.0 email.Parser is a placeholder object
which exposes a back
On Fri, 2006-03-17 at 09:40 -0500, Barry Warsaw wrote:
> The fix is simple, change 'P' to 'p' in the test, but I want to make
> sure that nobody cares that __import__('email.Parser') now returns an
> object that isn't a module, but acts enough li
On Sat, 2006-03-18 at 22:53 +1000, Nick Coghlan wrote:
> Should GeneratorExit inherit from Exception or BaseException?
Actually, this prompts me to write about an issue I have with PEP 352.
I actually don't think it's necessary (yes, I know it's already in the
tree).
What I would much rather is i
On Sat, 2006-03-18 at 16:50 +0100, Samuele Pedroni wrote:
> > I don't know whether this is possible for Python 2.5,
>
> well, one thing to consider is all the
>
> class MyException(Exception):
>
> in current code.
Yep, which is why I'm not sure we can do this for Py2.5. However as PEP
352 ta
On Fri, 2006-03-17 at 23:48 -0800, Neal Norwitz wrote:
> Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
> real quick, hopefully within a couple of weeks. If you have any
> *major* features (particularly implemented in C) that you want to see
> in 2.5, bring it up now. I want
On Fri, 2006-03-17 at 23:48 -0800, Neal Norwitz wrote:
> Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
> real quick, hopefully within a couple of weeks. If you have any
> *major* features (particularly implemented in C) that you want to see
> in 2.5, bring it up now. I want
On Sat, 2006-03-18 at 19:32 +0100, Giovanni Bajo wrote:
> +1 on the general idea, I just don't specifically like that "except:" is the
> "wrong" thing to do: part of the PEP352 idea was that people writing
> "except:" out of ignorance would still not cause their program to intercept
> KeyboardInte
On Sat, 2006-03-18 at 19:22 -0500, Raymond Hettinger wrote:
> > [Barry Warsaw]
> >> Oh, also, we have a couple of additions to the PySet C API.
> >> I'll work on putting together an SF patch for them over the weekend.
>
> What are you proposing to add to the Py
On Sun, 2006-03-19 at 19:45 -0800, Guido van Rossum wrote:
> -1. See my response in the other thread. The focus on 'Error' is
> mistaken, and we have a large body of existing code that derives from
> Exception.
Just to be clear, are you saying -1 only for Python 2.5 or -1 also for
Python 3.0? If
On Mon, 2006-03-20 at 19:27 +1000, Nick Coghlan wrote:
> +1 on the separate mailing list (and PEP numbers).
I'm neutral on whether a new mailing list should be added, but +1 on
separate PEP numbers.
> If Barry (or another mailing list admin) is feeling energetic, some
> branch-specific topics o
On Sun, 2006-03-19 at 20:40 -0800, Guido van Rossum wrote:
> I'm -0 for changing this in 3.0; a larger-scale reorganization could
> be undertaken but it's not a big priority.
>
> Before you spend more energy on this, I'd like to address the process
> for Python 3000, which is too chaotic right no
On Sat, 2006-03-18 at 15:37 -0800, Brett Cannon wrote:
> > Actually, this prompts me to write about an issue I have with PEP 352.
> > I actually don't think it's necessary (yes, I know it's already in the
> > tree).
> >
>
> Much to personal pain and sprint time. Are you trying to make me shed
>
On Sun, 2006-03-19 at 13:49 +1200, Greg Ewing wrote:
> Barry Warsaw wrote:
>
> > Exception
> > +- KeyboardInterrupt
> > +- GeneratorExit
> > +- SystemExit
> > +- StopIteration
> > +- Error
> > | +- ImportError
> > | +- (etc.)
> > |
&g
On Sun, 2006-03-19 at 17:31 +1000, Nick Coghlan wrote:
> With PEP 352 (tweaked to move GeneratorExit out from under Exception):
>- "except:" continues to mean catch everything
>- "except Exception:" now does the right thing
>- inheriting from Exception continues to be correct for user
On Sun, 2006-03-19 at 19:18 -0800, Guido van Rossum wrote:
> I have a problem with using Error as the focal point since so many
> exceptions (user-defined or otherwise) aren't errors.
I'm not sure that's totally true in practice. I think most user-defined
exceptions are actually errors. Ideall
On Mon, 2006-03-20 at 08:18 -0800, Aahz wrote:
> -1 -- I occasionally use exceptions as a multi-loop break. That's a
> perfectly valid Python practice, those exceptions should inherit from
> Exception, and there should not be any warnings raised.
Exactly! But they're not errors, so "except Exce
On Mon, 2006-03-20 at 11:43 -0800, Michael Chermside wrote:
> When you do, I'd like you to consider one change to the names. You are
> proposing this:
I'll keep this in mind, but won't comment further here for two reasons.
I want to think about it some more (you throw, er raise some good
points ;
On Mon, 2006-03-20 at 13:30 -0500, Terry Reedy wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> >Barry, if you could create that mailing list, please?
>
> And please mirror it on gmane the same way as this list is.
Subscription requests have been made.
-Barry
signature.asc
De
On Mon, 2006-03-20 at 20:06 -0800, Guido van Rossum wrote:
> There's also a list for Python-3000-related checkins. Don't subscribe
> to that one yet, it's very boring and uninteresting. Also, Barry
> hasn't done the svn magic yet. :-)
We're having a small problem on the svn box which requires Tho
I believe I've figured out the magic to split checkin messages so that
python/branches/p3yk goes to python-3000-checkins and everything else
goes to python-checkins. Let me know if you notice any problems, and
feel free to subscribe to whichever list(s) you're interested in.
-Barry
signature.a
Is it your intent to push for more use of the abstract API instead of
the concrete APIs for all of Python's C data structures? Current API
aside, are you advocating this approach for all new built-in types?
Would you argue that Python 3.0's C API be stripped of everything but
the abstract API and
On Tue, 2006-03-21 at 21:31 -0500, Raymond Hettinger wrote:
> [Barry]
> > Is it your intent to push for more use of the abstract API instead of
> > the concrete APIs for all of Python's C data structures? Current API
> > aside, are you advocating this approach for all new built-in types?
> > Woul
On Tue, 2006-03-21 at 22:01 -0500, Raymond Hettinger wrote:
> [Me]
> > There is a semantic difference between
> > code like s+=t and s.update(t). The former only works when t is a set
> > and the latter works for any iterable. When the C code corresponds to
> > the Python code, that knowledge is
On Sun, 2006-03-26 at 11:43 -0500, Raymond Hettinger wrote:
> It was a trick question. Everyone is supposed to be attracted to the _next
> version because it is shorter, faster, and takes less ref counting
> management.
> However, the _next version has a hard-to-find bug. The call to
> PyObj
On Sun, 2006-03-26 at 19:59 +0200, "Martin v. Löwis" wrote:
> If it is similar to PyDict_Next, it will have PyObject** /input/
> variables, which are really meant as PyObject* /output/ variables.
Yep, that's exactly what my posted patch does.
> For the caller, a clear usage strategy follows from
On Sun, 2006-03-26 at 13:24 -0500, Raymond Hettinger wrote:
> We have a perfectly good way to iterate with PyIter_Next(). It may take a
> couple of extra lines, but it is easy to get correct and has no surprises.
> It
> seems that the only issue is that Barry says that he refuses to use the
On Sun, 2006-03-26 at 21:50 +0200, "Martin v. Löwis" wrote:
> I don't know what specific application Barry has in mind, but I'm
> sure he can get it right (although it might be an interesting experiment
> to test that theory :-) In general, I would expect that people find
> it easier to get code i
On Sat, 2006-03-25 at 22:05 -0500, Raymond Hettinger wrote:
> Still, PyObject_Clear(s) would be better.
Although not ideal, in the interest of compromise, I could support this
option. There's a problem with this though: I don't think you want to
be able to clear a frozen set. My PySet_Clear()
2401 - 2500 of 2704 matches
Mail list logo
