Ben Finney wrote:
Both interesting, thank you. But Python 3 isn't an option for several
projects where I'd like to use this.
Okay, I took some time to try and figure this out (have I mentioned how
much I love Python 3's clean-up?), and I have something -- lightly
tested with methods, properti
On Fri, Apr 15, 2011 at 05:03:55PM -0700, Bob Ippolito wrote:
> On Fri, Apr 15, 2011 at 4:12 PM, Antoine Pitrou wrote:
> > On Fri, 15 Apr 2011 14:27:04 -0700
> > Bob Ippolito wrote:
> >> On Fri, Apr 15, 2011 at 2:20 PM, Antoine Pitrou
> >> wrote:
> >
> > Well, here's a crude microbenchmark. I'm
On Fri, Apr 15, 2011 at 05:03:55PM -0700, Bob Ippolito wrote:
> On Fri, Apr 15, 2011 at 4:12 PM, Antoine Pitrou wrote:
> > On Fri, 15 Apr 2011 14:27:04 -0700
> > Bob Ippolito wrote:
> >> On Fri, Apr 15, 2011 at 2:20 PM, Antoine Pitrou
> >> wrote:
> >
> > Well, here's a crude microbenchmark. I'm
On Fri, Apr 15, 2011 at 4:12 PM, Antoine Pitrou wrote:
> On Fri, 15 Apr 2011 14:27:04 -0700
> Bob Ippolito wrote:
>> On Fri, Apr 15, 2011 at 2:20 PM, Antoine Pitrou wrote:
>> > Le vendredi 15 avril 2011 à 14:18 -0700, Bob Ippolito a écrit :
>> >> On Friday, April 15, 2011, Antoine Pitrou wrote:
Michael Foord wrote:
But you have to be aware that
because of the semantics of super, not calling up to your parents
basically prevents those methods being used in the presence of multiple
inheritance.
No, it prevents them being used in the presence of super().
Multiple inheritance is still p
Mark Shannon wrote:
class A: pass
class B(A): pass
class C(A,B):pass
Traceback (most recent call last):
File "", line 1, in
TypeError: Cannot create a consistent method resolution
order (MRO) for bases B, A
All right, but this is okay:
class C(B, A): pass
> Michael Foord wrote:
>
For a
Michael Foord wrote:
consider the "recently" introduced problem caused by object.__init__
> not taking arguments. This makes it impossible to use super correctly
> in various circumstances.
>
> ...
>
It is impossible to inherit from both C and A and have all parent
__init__ methods called corr
On Fri, 15 Apr 2011 14:27:04 -0700
Bob Ippolito wrote:
> On Fri, Apr 15, 2011 at 2:20 PM, Antoine Pitrou wrote:
> > Le vendredi 15 avril 2011 à 14:18 -0700, Bob Ippolito a écrit :
> >> On Friday, April 15, 2011, Antoine Pitrou wrote:
> >> >>
> >> >> > Since the JSON spec is set in stone, the cha
Ethan Furman wrote:
Ben Finney wrote:
Ethan Furman writes:
8<---test_compose.py---
import unittest
ack! There should be an 'import new' here as well. :/
___
Python-Dev mailing list
Python-Dev@python.org
Ben Finney wrote:
Ethan Furman writes:
>> Ben Finney wrote:
>>>
How can composition add test cases detectable by Python's ‘unittest’?
>>
Metaclasses, if's that an option...
[…]
or a class decorator
[…]
Both interesting, thank you. But Python 3 isn't an option for several
projects where I
On Fri, Apr 15, 2011 at 2:20 PM, Antoine Pitrou wrote:
> Le vendredi 15 avril 2011 à 14:18 -0700, Bob Ippolito a écrit :
>> On Friday, April 15, 2011, Antoine Pitrou wrote:
>> >>
>> >> > Since the JSON spec is set in stone, the changes
>> >> > will mostly be about API (indentation, object convers
Ethan Furman writes:
> Ben Finney wrote:
> > TestCase subclasses is a multiple-inheritance use case that I share.
> > The mix-ins add test cases (methods named ‘test_’ on the mix-in
> > class) to the TestCase subclass. I would prefer not to use multiple
> > inheritance for this if it can be achie
Le vendredi 15 avril 2011 à 14:18 -0700, Bob Ippolito a écrit :
> On Friday, April 15, 2011, Antoine Pitrou wrote:
> >>
> >> > Since the JSON spec is set in stone, the changes
> >> > will mostly be about API (indentation, object conversion, etc)
> >> > and optimization. I presume the core parsing
On Friday, April 15, 2011, Antoine Pitrou wrote:
>>
>> > Since the JSON spec is set in stone, the changes
>> > will mostly be about API (indentation, object conversion, etc)
>> > and optimization. I presume the core parsing logic won't
>> > be changing much.
>>
>> Actually the core parsing logic
>
> > Since the JSON spec is set in stone, the changes
> > will mostly be about API (indentation, object conversion, etc)
> > and optimization. I presume the core parsing logic won't
> > be changing much.
>
> Actually the core parsing logic is very different (and MUCH faster),
Are you talking a
Ben Finney wrote:
Ethan Furman writes:
Here we have django's TestCase that does *not* want to call
unittest2.TestCase (assuming that's not a bug), but it gets called
anyway because the Mixin3 sibling has it as a base class. So does
this mean that TestCase and Mixin3 just don't play well toget
On Fri, Apr 15, 2011 at 11:30 PM, Michael Foord
wrote:
> On 15/04/2011 02:02, Greg Ewing wrote:
>> There isn't necessarily a clear distinction between parents
>> and siblings.
>>
>> class A:
>> ...
>>
>> class B(A):
>> ...
>>
>> class C(A, B):
>> ...
>>
>> In C, is A a parent of B or a sibling
Hi,
I just wanted to clear a slight misunderstanding:
How can composition add test cases detectable by Python 2's
‘unittest’
and Python 3's ‘unittest2’?
The package shipped in the stdlib is named unittest in all Python
versions. The codebase that has seen a lot of improvements thanks to
Mic
On 14/04/2011, Michael Foord wrote:
> I'd be interested to know what is keeping the tests alive even when the
> test suite isn't. As far as I know there is nothing else in unittest
> that would do that.
The main cause is some handy code for collecting and filtering tests
by name, which unintentio
On Thu, Apr 14, 2011 at 2:29 PM, Raymond Hettinger
wrote:
>
> On Apr 14, 2011, at 12:22 PM, Sandro Tosi wrote:
>
>> The version we have in cpython of json is simplejson 2.0.9 highly
>> patched (either because it was converted to py3k, and because of the
>> normal flow of issues/bugfixes) while ups
ACTIVITY SUMMARY (2011-04-08 - 2011-04-15)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2734 ( -7)
closed 20899 (+54)
total 23633 (+47)
Open issues wit
On 15/04/2011 16:18, Carl Meyer wrote:
On 04/15/2011 08:53 AM, Michael Foord wrote:
If we treat django's failure to use super as a bug, you want the
Python language to work-around that bug so that:
What you say (that this particular circumstance could be treated as a
bug in django) is true,
J
On 04/15/2011 08:53 AM, Michael Foord wrote:
>> If we treat django's failure to use super as a bug, you want the
>> Python language to work-around that bug so that:
>
> What you say (that this particular circumstance could be treated as a
> bug in django) is true,
Just as a side note: if there
Michael Foord wrote:
On 15/04/2011 02:02, Greg Ewing wrote:
Michael Foord wrote:
What I was suggesting is that a method not calling super shouldn't
stop a *sibling* method being called, but could still prevent the
*parent* method being called.
There isn't necessarily a clear distinction betwe
On Fri, Apr 15, 2011 at 8:59 AM, Antoine Pitrou wrote:
> On Fri, 15 Apr 2011 08:36:16 -0400
> Jesse Noller wrote:
>> On Fri, Apr 15, 2011 at 8:30 AM, Brian Curtin wrote:
>> >
>> > On Apr 15, 2011 3:46 AM, "Gustavo Narea" wrote:
>> >>
>> >> Hi all,
>> >>
>> >> How come a description of how to ex
Le vendredi 15 avril 2011 à 13:34 +0200, Jesus Cea a écrit :
> http://docs.python.org/py3k/ takes you to 2.7, by default.
>
> Should we update it to point to 3.2?. If the point is to promote Python 3...
>
> I would point it to 3.2, with a big "access to documentation to legacy
> 2.7" (beside the
On Fri, Apr 15, 2011 at 8:59 AM, Antoine Pitrou wrote:
> Relying on a vendor distribution (such as a Linux distro, or
> ActiveState) is hopefully enough to get these security updates in time
> without patching anything by hand. I don't think many people compile
> Python for production use, but man
On 15/04/2011 02:23, Steven D'Aprano wrote:
Ricardo Kirkner wrote:
I have a TestCase class, which inherits from both Django's TestCase
and from some custom TestCases that act as mixin classes. So I have
something like
class MyTestCase(TestCase, Mixin1, Mixin2):
...
now django's TestCase cl
On 15/04/2011 02:02, Greg Ewing wrote:
Michael Foord wrote:
What I was suggesting is that a method not calling super shouldn't
stop a *sibling* method being called, but could still prevent the
*parent* method being called.
There isn't necessarily a clear distinction between parents
and siblin
On Fri, 15 Apr 2011 08:36:16 -0400
Jesse Noller wrote:
> On Fri, Apr 15, 2011 at 8:30 AM, Brian Curtin wrote:
> >
> > On Apr 15, 2011 3:46 AM, "Gustavo Narea" wrote:
> >>
> >> Hi all,
> >>
> >> How come a description of how to exploit a security vulnerability
> >> comes before a release for said
On Fri, Apr 15, 2011 at 8:30 AM, Brian Curtin wrote:
>
> On Apr 15, 2011 3:46 AM, "Gustavo Narea" wrote:
>>
>> Hi all,
>>
>> How come a description of how to exploit a security vulnerability
>> comes before a release for said vulnerability? I'm talking about this:
>> http://blog.python.org/2011/0
On Apr 15, 2011 3:46 AM, "Gustavo Narea" wrote:
>
> Hi all,
>
> How come a description of how to exploit a security vulnerability
> comes before a release for said vulnerability? I'm talking about this:
> http://blog.python.org/2011/04/urllib-security-vulnerability-fixed.html
>
> My understanding
On Fri, 15 Apr 2011 13:34:59 +0200
Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> http://docs.python.org/py3k/ takes you to 2.7, by default.
Really? Perhaps it has already been fixed, but I read “Python v3.2
documentation” on that page.
Antoine.
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://docs.python.org/py3k/ takes you to 2.7, by default.
Should we update it to point to 3.2?. If the point is to promote Python 3...
I would point it to 3.2, with a big "access to documentation to legacy
2.7" (beside the small left column link). W
R. David Murray wrote:
Why not? It seems more useful than using it for chaining,
especially given the compiler hack in Python3.
Because it's prone to doing the wrong thing if the class
using it is ever involved in multiple inheritance. If
you're expecting the call to go to a particular class,
On Fri, Apr 15, 2011 at 09:35:06AM +0100, Gustavo Narea wrote:
>
> How come a description of how to exploit a security vulnerability
> comes before a release for said vulnerability? I'm talking about this:
> http://blog.python.org/2011/04/urllib-security-vulnerability-fixed.html
>
> My understand
Hi all,
How come a description of how to exploit a security vulnerability
comes before a release for said vulnerability? I'm talking about this:
http://blog.python.org/2011/04/urllib-security-vulnerability-fixed.html
My understanding is that the whole point of asking people not to
report security
37 matches
Mail list logo
