On 7/21/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Saturday 21 July 2007, Joe Gregorio wrote:
> > Should xml.parsers.expat.XMLParser.ParseFile(file) operate on
> > both text and binary streams?
>
> No. XML is a serialization of a markup language containing Unicode character
> into an
Greg Ewing wrote:
> Nick Coghlan wrote:
>> Putting the essential parts in
>> __new__ means never having to include the instruction that "you must
>> call this classes __init__ method when subclassing and overriding
>> __init__" into any API documentation I write.
>
> I always assume that I *do*
At 01:09 PM 7/22/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > I.e., customers usually don't give you a step-by-step, "well, first I
> > check if the customer has an outstanding balance before I ship them
> > anything." They say, "Don't ship stuff to people with an
> outstanding balanc
At 01:28 PM 7/22/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > Well, I've worked with people who dislike OO for exactly the same
> > reason, since they feel they can never know whether a method might
> > have been overridden in a subclass.
>
>I think there's a considerable difference in
Andrew Dalke wrote:
> However, for backwards compatibility, the args attribute
>
> contains only a 2-tuple of the first two constructor arguments.
This is a good reason for having named attributes instead
of a tuple -- it's extensible without requiring these sorts
of hacks.
As for the
Phillip J. Eby wrote:
> Well, I've worked with people who dislike OO for exactly the same
> reason, since they feel they can never know whether a method might
> have been overridden in a subclass.
I think there's a considerable difference in degree here,
though. When you call a method, you know
Andrew Dalke:
> Does the ".args" needs to be visible to Python code?
> That would hide the problem, yes?
I see I'm not getting all messages on this thread.
Looked at the archive and saw:
Guido:
> So -1 on removing e.args. I'd be okay with a recommendation not to
> rely on it and to define explici
Phillip J. Eby wrote:
> I.e., customers usually don't give you a step-by-step, "well, first I
> check if the customer has an outstanding balance before I ship them
> anything." They say, "Don't ship stuff to people with an outstanding
> balance."
In my experience, customers often give you a va
Brett:
> This was originally proposed in PEP 352.
> So while I totally understand the desire to ditch 'args' and just have
> 'message', doing so thoroughly and in any reasonable way that is not
> painful is not easy thanks to the C API.
*sigh*
I read through the back python 3k list postings on t
Nick Coghlan wrote:
> Putting the essential parts in
> __new__ means never having to include the instruction that "you must
> call this classes __init__ method when subclassing and overriding
> __init__" into any API documentation I write.
I always assume that I *do* have to call the base __ini
On 7/21/07, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> Posting here a expansion of a short discussion I had
> after Guido's keynote at EuroPython. In this email
> I propose eliminating the ".args" attribute from the
> Exception type. It's not useful, and supporting it
> correctly is complicated en
Georg Brandl wrote:
> Hm, I always found it useful to just do
>
> class MyCustomError(Exception):
> pass
>
> and give it arbitrary arguments to it without writing __init__
> method stuff that I can access from outside.
Maybe
class Exception(object):
def __init__(self, msg = None,
The main statement I have is, excepting backwards compatibility,
nothing would care if .args was removed in 3.0, and those which
currently used .args were changed to use attributes instead.
Please show/advise me otherwise.
> Andrew Dalke wrote:
>> so I think the base exception class should look l
At 10:55 PM 7/20/2007 -0700, Talin wrote:
>You mentioned earlier that there was a design reason for preferring
>@overload and @when vs. the earlier RuleDispatch syntax, but the
>explanation you gave wasn't very clear (to me anyway).
>
>(I personally prefer the @somegeneric.overload, but that's pure
Joe Smith wrote:
> The effects of this can be wonderful. A package could convert some of a
> frameworks functions to generics, to allow them to handle the new objects
> the package provides. It might also need to add some before and after
> methods to ensure that the user of the module, it look
Andrew Dalke wrote:
> Having support for a single object (almost always a
> string) passed into the exception is pragmatically useful,
> so I think the base exception class should look like
>
> class Exception(object):
>msg = None
>def __init__(self, msg):
> self.msg = msg
>def __
James Y Knight wrote:
> On Jul 21, 2007, at 12:25 AM, Fred L. Drake, Jr. wrote:
>
>> On Saturday 21 July 2007, Joe Gregorio wrote:
>>> Should xml.parsers.expat.XMLParser.ParseFile(file) operate on
>>> both text and binary streams?
>> No. XML is a serialization of a markup language containing Unic
On Saturday 21 July 2007, James Y Knight wrote:
> Well...there's many reasons why it is useful to be able to parse an
> already-decoded unicode stream into XML, and to serialize XML into a
> unicode string. For example, if combining into a larger unicode
> document, or parsing from a literal st
At 08:16 AM 7/21/2007 -0700, Guido van Rossum wrote:
>On 7/21/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> > One of the nice features of Eby's proposal is that more complicated
> > dispatching systems can be added. Perhaps some application needs a
> > dispatching engine that can dispatch based on the
On Jul 21, 2007, at 12:25 AM, Fred L. Drake, Jr. wrote:
> On Saturday 21 July 2007, Joe Gregorio wrote:
>> Should xml.parsers.expat.XMLParser.ParseFile(file) operate on
>> both text and binary streams?
>
> No. XML is a serialization of a markup language containing Unicode
> character
> into an
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/21/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> One of the nice features of Eby's proposal is that more complicated
>> dispatching systems can be added. Perhaps some application needs a
>> dispatching engine that
On 7/21/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Andrew Dalke schrieb:
> > Posting here a expansion of a short discussion I had
> > after Guido's keynote at EuroPython. In this email
> > I propose eliminating the ".args" attribute from the
> > Exception type. It's not useful, and supporting
On 7/20/07, Talin <[EMAIL PROTECTED]> wrote:
> On the issue of method combination, aspects, and interfaces: Guido has
> not made a pronouncement on whether these things may or may not be
> accepted at some time in the future. What he has said is that he doesn't
> *yet* understand the use case for t
On 7/21/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> One of the nice features of Eby's proposal is that more complicated
> dispatching systems can be added. Perhaps some application needs a
> dispatching engine that can dispatch based on the value of an objects
> member. Perhaps the user wants an ove
Andrew Dalke schrieb:
> Posting here a expansion of a short discussion I had
> after Guido's keynote at EuroPython. In this email
> I propose eliminating the ".args" attribute from the
> Exception type. It's not useful, and supporting it
> correctly is complicated enough that it's often not
> sup
Posting here a expansion of a short discussion I had
after Guido's keynote at EuroPython. In this email
I propose eliminating the ".args" attribute from the
Exception type. It's not useful, and supporting it
correctly is complicated enough that it's often not
supported correctly
In Python 2 th
Martin v. Löwis wrote:
> You mean, like prefixing it with c, e.g. StringIO vs. cStringIO,
> pickle vs. cPickle?
Yes, but with an official scheme for deriving the names
from the main package name, and also an understanding
that these are implementation details to be used only
when really necessary
Talin wrote:
> Overloading a class method requires special treatment of the 'self'
> parameter because there's an implicit constraint on what types of
> objects can be passed as 'self'
Hang on a minute. Is it really necessary for the GF
machinery to concern itself with this? By the time
you get
Greg Ewing schrieb:
> Josiah Carlson wrote:
>> What made it really annoying is that there was no way to tell the heapq
>> module not to load the C version so that I could use a generic container.
>
> I would say that all such dual-implementation modules should
> make the specific implementations
"Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Phillip J. Eby wrote:
>> At 07:49 AM 7/20/2007 -0700, Guido van Rossum wrote:
>>> On 7/19/07, Joe Smith <[EMAIL PROTECTED]> wrote:
So the state of the PEP? From the rest of the posts so far,
it sounds like there is no
30 matches
Mail list logo
