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
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.
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 would
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
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:
-
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...
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
[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 different
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, completely
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
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,
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
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
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
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:
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
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 classes.
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
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
introduce
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
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 'Exception',
not
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
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 review your
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
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 my
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 it
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
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
[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
level of
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 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
31 matches
Mail list logo
