Guido van Rossum wrote:
> Keeping im_class would be tricky -- the information isn't easily
> available when the function is defined, and adding it would require
> changing unrelated code that the patch so far didn't have to get near.
> Also, it would not be compatible -- the unbound method sets im
> I still think that only an experiment could decide: somebody should
> come up with a patch that does that, and we will see what breaks.
>
> I still have the *feeling* that this has significant impact, but
> I could not pin-point this to any specific problem I anticipate.
This sounds like a good
[Guido]
> > Apart from the tests that were testing the behavior of im_class, I
> > found only a single piece of code in the standard library that used
> > im_class of an unbound method object (the clever test in the pyclbr
> > test). Uses of im_self and im_func were more widespread. Given the
> > l
On Jan 17, 2005, at 18:33, Glyph Lefkowitz wrote:
It's not the strongest use-case in the world, but is the impetus to
remove unbound method objects from Python that much stronger? I like
the fact that it's simpler, but it's a small amount of extra
simplicity,
it doesn't seem to enable any new use
On Mon, 2005-01-17 at 17:58, M.-A. Lemburg wrote:
> If you want to make methods look more like functions,
> the method object should become a subclass of the function
> object (function + added im_* attributes).
I have no personal use cases, but it does make me vaguely uncomfortable
to lose im_cl
On Mon, 2005-01-17 at 23:58 +0100, M.-A. Lemburg wrote:
> If you want to make methods look more like functions,
> the method object should become a subclass of the function
> object (function + added im_* attributes).
I think this suggestion would fix my serialization problem as well...
but does
On Mon, 2005-01-17 at 07:43 -0800, Guido van Rossum wrote:
> Note that you can't pickle unbound methods anyway unless you write
> specific suppport code to do that; it's not supported by pickle
> itself.
It's supported by Twisted. Alternatively, replace "pickle" with "python
object serializer of
Guido van Rossum wrote:
Apart from the tests that were testing the behavior of im_class, I
found only a single piece of code in the standard library that used
im_class of an unbound method object (the clever test in the pyclbr
test). Uses of im_self and im_func were more widespread. Given the
level
Gustavo J. A. M. Carneiro wrote:
Oh... sorry, I didn't know about any rules.
My apologies - I had announced this (personal) rule
a few times, so I thought everybody on python-dev knew.
If you really want to push a patch, you
can do so by doing your own share of work, namely by
reviewing other's p
On Mon, 2005-01-17 at 23:12 +0100, "Martin v. Löwis" wrote:
> Gustavo J. A. M. Carneiro wrote:
> > If someone could take a look at:
> >
> > [ 1069624 ] incomplete support for AF_PACKET in socketmodule.c
>
>
> The rule applies: five reviews, with results posted to python-dev,
> and I will revie
Guido van Rossum wrote:
a) Is Exception to be new-style?
Probably not in 2.5; Martin and others have suggested that this could
introduce instability for users' existing exception classes.
Really? I thought that was eventually decided to be a very small amount of code.
I still think that only an ex
Gustavo J. A. M. Carneiro wrote:
If someone could take a look at:
[ 1069624 ] incomplete support for AF_PACKET in socketmodule.c
The rule applies: five reviews, with results posted to python-dev,
and I will review your patch.
Regards,
Martin
___
Python
> >That would be much more reasonable if Exception itself was a new-style
> >class. As long as it isn't, you'd have to declare new-style classes
> >like this:
> >
> >class MyError(Exception, object):
> > ...
> >
> >which is ugly.
>
> I was thinking the use case was that you were having to add
At 10:21 AM 1/17/05 -0800, Guido van Rossum wrote:
> Heh. As long as you're going to continue the electrical metaphor, why not
> just call them transformers and appliances?
Please don't. Transformer is commonly used in all sorts of contexts.
But appliances applies mostly to kitchenware and the occ
At 10:16 AM 1/17/05 -0800, Guido van Rossum wrote:
On Mon, 17 Jan 2005 11:35:53 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 04:06 PM 1/17/05 +, Michael Hudson wrote:
> >a) Is Exception to be new-style?
>
> Probably not in 2.5; Martin and others have suggested that this could
> introdu
Thomas Heller <[EMAIL PROTECTED]> writes:
> 25-27 January are all ok for me. Will there be a lot of backports, or
> are they already in place? If they are already there, I can build the
> installer as soon as Fred has built the html docs.
I've got a couple, I'll get them in by tomorrow.
--
KBK
> Heh. As long as you're going to continue the electrical metaphor, why not
> just call them transformers and appliances?
Please don't. Transformer is commonly used in all sorts of contexts.
But appliances applies mostly to kitchenware and the occasional
marketing term for cheap computers.
The e
On Mon, 17 Jan 2005 11:35:53 -0500, Phillip J. Eby
<[EMAIL PROTECTED]> wrote:
> At 04:06 PM 1/17/05 +, Michael Hudson wrote:
> >a) Is Exception to be new-style?
>
> Probably not in 2.5; Martin and others have suggested that this could
> introduce instability for users' existing exception class
At 04:06 PM 1/17/05 +, Michael Hudson wrote:
a) Is Exception to be new-style?
Probably not in 2.5; Martin and others have suggested that this could
introduce instability for users' existing exception classes.
b) Somewhat but not entirely independently, would demanding that all
new-style e
On Monday 17 January 2005 08:41, Anthony Baxter wrote:
> As I'd kinda feared, my return to work has left me completely
> buried this week, and so I'm going to have to push 2.3.5 until
> next week. Thomas and Fred: does one of the days in the
> range 25-27 January suit you? The 26th is a public
Guido van Rossum <[EMAIL PROTECTED]> writes:
> [Michael]
>> It would still be worth doing, IMHO.
>
> Then let's do it. Care to resurrect your patch? (And yes, classic
> classes should also be allowed for b/w compatibility.)
I found it and uploaded it here:
http://starship.python.net/crew/mwh
Phillip J. Eby wrote:
> Heh. As long as you're going to continue the electrical metaphor,
> why not just call them transformers and appliances? [ ... ]
Next we'll see Appliance-Oriented Programming ;-)
Just
___
Python-Dev mailing list
Python-Dev@pytho
If someone could take a look at:
[ 1069624 ] incomplete support for AF_PACKET in socketmodule.c
I have to ship my own patched copy of the socket module because of
this... :|
On Sun, 2005-01-16 at 17:08 +0100, Irmen de Jong wrote:
> Hello
> I've looked at one bug and a bunch of patches and
>
Hi Guido,
On Mon, Jan 17, 2005 at 07:27:33AM -0800, Guido van Rossum wrote:
> That is stricter than classic Python though -- it allows the value to
> be anything (and you get the value back unadorned in the except 's',
> x: clause).
Thanks for the note !
Armin
__
Anthony Baxter <[EMAIL PROTECTED]> writes:
> As I'd kinda feared, my return to work has left me completely
> buried this week, and so I'm going to have to push 2.3.5 until
> next week. Thomas and Fred: does one of the days in the
> range 25-27 January suit you? The 26th is a public holiday here,
>
> Will it still be possible to create an unbound method with
> new.instancemethod? (I know the patch doesn't change this, I mean, is it
> planned to remove the facility from the instancemethod type?)
I was hoping to be able to get rid of this as soon as the built-in
exceptions code no longer depe
At 01:49 AM 1/17/05 -0500, Glyph Lefkowitz wrote:
On Sun, 2005-01-16 at 13:00 -0500, Phillip J. Eby wrote:
> """One type is the "extender", ...
> By contrast, an "independent adapter" ...
I really like the way this part of the PEP is sounding, since it really
captures two almost, but not quite, com
[Guido]
> > def test_im_class():
> > class C:
> > def foo(self): pass
> > - verify(C.foo.im_class is C)
[Glyph]
> ^ Without this, as JP Calderone pointed out earlier, you can't serialize
> unbound methods. I wouldn't mind that so much, but you can't tell that
> they're any d
At 10:12 PM 1/16/05 -0800, Guido van Rossum wrote:
I couldn't remove support for unbound methods
completely, since they were used by the built-in
exceptions. (We can get rid of that use once we convert
to new-style exceptions.)
Will it still be possible to create an unbound method with
new.instanc
[Armin]
> For reference, PyPy doesn't have old-style classes at all so far, so we had to
> come up with something about exceptions. After some feedback from python-dev
> it appears that the following scheme works reasonably well. Actually it's
> surprizing how little problems we actually encounte
As I'd kinda feared, my return to work has left me completely
buried this week, and so I'm going to have to push 2.3.5 until
next week. Thomas and Fred: does one of the days in the
range 25-27 January suit you? The 26th is a public holiday here,
and so that's the day that's most likely for me...
A
Guido van Rossum <[EMAIL PROTECTED]> writes:
> To be honest, I don't recall the exact reasons why this wasn't fixed
> in 2.2; I believe it has something to do with the problem of
> distinguishing between string and class exception, and between the
> various forms of raise statements.
A few months
On 2005 Jan 17, at 14:45, Anthony Baxter wrote:
...
both, but, of course, everybody's welcome to help!). Surely this
can't
be the first case in which a bug got triggered only by a certain
behavior in an extension type, but I couldn't find precedents. Ideas,
suggestions, ...?
Beats me - worst
Title: Deprecating old bugs
As I discussed in this list, in the "Policy about old Python versions" thread at 8-Nov-2004, I started verifying the old bugs.
Here are the results for 2.1.*. This maybe should be put in an informational PEP.
When I verified the bug, I filled two fields:
- Grou
On Sunday 16 January 2005 20:38, Alex Martelli wrote:
> Problem: to write unit tests showing that the current copy.py
> misbehaves with a classic extension type, I need a classic extension
> type which defines __copy__ and __deepcopy__ just like /F's
> cElementTree does. So, I made one: a small tr
Nick Coghlan wrote:
Guido van Rossum wrote:
What do people think? (My main motivation for this, as stated before,
is that it adds complexity without much benefit.)
I'm in favour, since it removes the "an unbound method is almost like a
bare function, only not quite as useful" distinction. It woul
Guido van Rossum wrote:
Typechecking can be trivially defined in terms of adaptation:
def typecheck(x, T):
y = adapt(x, T)
if y is x:
return y
raise TypeError("...")
Assuming the type error displayed contains information on T, the caller can then
trivially correct the type error by
Hi,
On Fri, Jan 14, 2005 at 07:20:31PM -0500, Jim Jewett wrote:
> The base of the Exception hierarchy happens to be a classic class.
> But why are they "required" to be classic?
For reference, PyPy doesn't have old-style classes at all so far, so we had to
come up with something about exceptions.
Guido van Rossum wrote:
What do people think? (My main motivation for this, as stated before,
is that it adds complexity without much benefit.)
I'm in favour, since it removes the "an unbound method is almost like a bare
function, only not quite as useful" distinction. It would allow things like
39 matches
Mail list logo
