Re: [Python-Dev] Adding test case methods to TestCase subclasses
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, properties, and attributes, with the objects being kept in classes instead of modules. Posted to ActiveState. http://code.activestate.com/recipes/577658-composition-of-classes-instead-of-multiple-inherit Hope this helps! ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
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 comparing 2.6+simplejson 2.1.3 > > to 3.3+json, so I'm avoiding integers: > > > > * json.dumps: > > > > $ python -m timeit -s "from simplejson import dumps, loads; \ > > ?? ??d = dict((str(i), str(i)) for i in range(1000))" \ > > ?? "dumps(d)" > > > > - 2.6+simplejson: 372 usec per loop > > - 3.2+json: 352 usec per loop > > > > * json.loads: > > > > $ python -m timeit -s "from simplejson import dumps, loads; \ > > ?? ??d = dict((str(i), str(i)) for i in range(1000)); s = dumps(d)" \ > > ?? ??"loads(s)" > > > > - 2.6+simplejson: 224 usec per loop > > - 3.2+json: 233 usec per loop > > > > > > The runtimes look quite similar. > > That's the problem with trivial benchmarks. With more typical data > (for us, anyway) you should see very different results. Slightly less crude benchmark showing simplejson is quite a bit faster: http://pastebin.com/g1WqUPwm 250ms vs 5.5s encoding and decoding an 11KB json object 1000 times... m -- Matt Billenstein m...@vazor.com http://www.vazor.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
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 comparing 2.6+simplejson 2.1.3 > > to 3.3+json, so I'm avoiding integers: > > > > * json.dumps: > > > > $ python -m timeit -s "from simplejson import dumps, loads; \ > > ?? ??d = dict((str(i), str(i)) for i in range(1000))" \ > > ?? "dumps(d)" > > > > - 2.6+simplejson: 372 usec per loop > > - 3.2+json: 352 usec per loop > > > > * json.loads: > > > > $ python -m timeit -s "from simplejson import dumps, loads; \ > > ?? ??d = dict((str(i), str(i)) for i in range(1000)); s = dumps(d)" \ > > ?? ??"loads(s)" > > > > - 2.6+simplejson: 224 usec per loop > > - 3.2+json: 233 usec per loop > > > > > > The runtimes look quite similar. > > That's the problem with trivial benchmarks. With more typical data > (for us, anyway) you should see very different results. Slightly less crude benchmark showing simplejson is quite a bit faster: http://pastebin.com/g1WqUPwm 250ms vs 5.5s encoding and decoding an 11KB json object 1000 times... m -- Matt Billenstein m...@vazor.com http://www.vazor.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
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: >> >> >> >> >> >> > 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 about the Python logic or the C logic? >> >> >> >> Both, actually. IIRC simplejson in pure python typically beats json >> >> with it's C extension. >> > >> > Really? It would be nice to see some concrete benchmarks against both >> > repo tips. >> >> Maybe in a few weeks or months when I have time to finish up the >> benchmarks that I was working on... but it should be pretty easy for >> anyone to show that the version in CPython is very slow (and uses a >> lot more memory) in comparison to simplejson. > > Well, here's a crude microbenchmark. I'm comparing 2.6+simplejson 2.1.3 > to 3.3+json, so I'm avoiding integers: > > * json.dumps: > > $ python -m timeit -s "from simplejson import dumps, loads; \ > d = dict((str(i), str(i)) for i in range(1000))" \ > "dumps(d)" > > - 2.6+simplejson: 372 usec per loop > - 3.2+json: 352 usec per loop > > * json.loads: > > $ python -m timeit -s "from simplejson import dumps, loads; \ > d = dict((str(i), str(i)) for i in range(1000)); s = dumps(d)" \ > "loads(s)" > > - 2.6+simplejson: 224 usec per loop > - 3.2+json: 233 usec per loop > > > The runtimes look quite similar. That's the problem with trivial benchmarks. With more typical data (for us, anyway) you should see very different results. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
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 possible the old-fashioned way using explicit upcalls as long as the classes are sufficiently independent. If they're *not* sufficiently independent, and haven't been specifically designed to cooperate with each other, attempting to make them cooperate automatically is as likely to do harm as good. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
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 super call in C, B is a sibling to A. For a super call in B, A is a parent. With the semantics I was suggesting if C calls super, but A doesn't then B would still get called. which is contradicted by: "Siblings", in the context of a single MRO are thus classes between which there is no sub-class/super-class relation. So I maintain that the situation is far from clear. :-) -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
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 correctly. Changing the semantics of super as described would fix this problem. I don't see how, because auto-super-calling would eventually end up trying to call object.__init__ with arguments and fail. You might think to "fix" this by making a special case of object.__init__ and refraining from calling it. But the same problem arises in a more general way whenever some class in the mix has a method with the right name but the wrong signature, which is likely to happen if you try to mix classes that weren't designed to be mixed together. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
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 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 about the Python logic or the C logic? > >> > >> Both, actually. IIRC simplejson in pure python typically beats json > >> with it's C extension. > > > > Really? It would be nice to see some concrete benchmarks against both > > repo tips. > > Maybe in a few weeks or months when I have time to finish up the > benchmarks that I was working on... but it should be pretty easy for > anyone to show that the version in CPython is very slow (and uses a > lot more memory) in comparison to simplejson. Well, here's a crude microbenchmark. I'm comparing 2.6+simplejson 2.1.3 to 3.3+json, so I'm avoiding integers: * json.dumps: $ python -m timeit -s "from simplejson import dumps, loads; \ d = dict((str(i), str(i)) for i in range(1000))" \ "dumps(d)" - 2.6+simplejson: 372 usec per loop - 3.2+json: 352 usec per loop * json.loads: $ python -m timeit -s "from simplejson import dumps, loads; \ d = dict((str(i), str(i)) for i in range(1000)); s = dumps(d)" \ "loads(s)" - 2.6+simplejson: 224 usec per loop - 3.2+json: 233 usec per loop The runtimes look quite similar. Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding test case methods to TestCase subclasses
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding test case methods to TestCase subclasses
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'd like to use this.
Well, I'm sure there's a way to do it -- alas, I lack the time to find
it either in the docs, archives, or by experimentation.
What I did find is that if you have your functions in modules, instead
of in classes, it works fine in Python 2.6+.
8<---spam.py---
def test_spam_01(self):
print('testing spam_01')
def test_spam_02(self):
print('testing spam_02')
8<-
8<---eggs.py---
def test_eggs_01(self):
print('testing eggs_01')
def test_eggs_02(self):
print('testing eggs_02')
8<-
8<---test_compose.py---
import unittest
class Compose(object): # 2.6-2.7, functions must be in modules
def __init__(self, *parts):
self.parts = parts
def __call__(self, func):
for part in self.parts:
for attr in dir(part):
if attr[:2] == attr[-2:] == '__':
continue
if getattr(cls, attr, None):
raise AttributeError(
"%s already exists in %s" % (attr, cls))
setattr(func, attr, getattr(part, attr))
return func
@Compose(spam, eggs)
class TestAll(unittest.TestCase):
def setUp(self):
print('Setting up...')
def tearDown(self):
print('Tearing down...')
def test_something(self):
print('testing something')
if __name__ == '__main__':
unittest.main()
8<---test_compose.py---
Compose now has rudimentary error checking, and if can live with your
extras living in their own .py files, this might work for you.
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
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 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 about the Python logic or the C logic? >> >> Both, actually. IIRC simplejson in pure python typically beats json >> with it's C extension. > > Really? It would be nice to see some concrete benchmarks against both > repo tips. Maybe in a few weeks or months when I have time to finish up the benchmarks that I was working on... but it should be pretty easy for anyone to show that the version in CPython is very slow (and uses a lot more memory) in comparison to simplejson. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding test case methods to TestCase subclasses
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 achieved in a better way. > > > > 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'd like to use this. -- \ “What is needed is not the will to believe but the will to find | `\ out, which is the exact opposite.” —Bertrand Russell, _Free | _o__) Thought and Official Propaganda_, 1928 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
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 logic won't > >> > be changing much. > >> > >> Actually the core parsing logic is very different (and MUCH faster), > > > > Are you talking about the Python logic or the C logic? > > Both, actually. IIRC simplejson in pure python typically beats json > with it's C extension. Really? It would be nice to see some concrete benchmarks against both repo tips. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
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 is very different (and MUCH faster), > > Are you talking about the Python logic or the C logic? Both, actually. IIRC simplejson in pure python typically beats json with it's C extension. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
> > > 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 about the Python logic or the C logic? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding test case methods to TestCase subclasses
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 together?
Maybe composition instead of inheritance is the answer (in this case,
anyway ;).
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 achieved in a better way.
How can composition add test cases detectable by Python's ‘unittest’?
Metaclasses, if's that an option...
8<-
import unittest
from composite import Composite # python 3 only
class Spam():
def test_spam_01(self):
print('testing spam_01')
def test_spam_02(self):
print('testing spam_02')
class Eggs():
def test_eggs_01(self):
print('testing eggs_01')
def test_eggs_02(self):
print('testing eggs_02')
class TestAll(
unittest.TestCase,
metaclass=Composite,
parts=(Spam, Eggs)):
def setUp(self):
print('Setting up...')
def tearDown(self):
print('Tearing down...')
def test_something(self):
print('testing something')
if __name__ == '__main__':
unittest.main()
8<-
or a class decorator
8<-
class Compose(object): # python 3 only
def __init__(self, *parts):
self.parts = parts
def __call__(self, func):
for part in self.parts:
for attr in dir(part):
if attr[:2] == attr[-2:] == '__':
continue
setattr(func, attr, getattr(part, attr))
return func
import unittest
class Spam():
def test_spam_01(self):
print('testing spam_01')
def test_spam_02(self):
print('testing spam_02')
class Eggs():
def test_eggs_01(self):
print('testing eggs_01')
def test_eggs_02(self):
print('testing eggs_02')
@Compose(Spam, Eggs)
class TestAll(unittest.TestCase):
def setUp(self):
print('Setting up...')
def tearDown(self):
print('Tearing down...')
def test_something(self):
print('testing something')
if __name__ == '__main__':
unittest.main()
8<-
The decorator, as written, doesn't work on py2, and doesn't do any error
checking (so overwrites methods in the final class) -- but I'm sure it
could be spiffed up.
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
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 of B? As has been pointed out elsewhere in the thread, that definition of C isn't allowed :) >>> 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 A, B Once you turn the order of definition around (class C(B, A)) it becomes clear that A remains B's parent regardless of the existence of C: >>> C.__mro__ (, , , ) The whole discussion of trying to distinguish parents from siblings when invoking super() *doesn't make sense*. The entire *point* of the multiple inheritance handling is to linearise the type hierarchy into a method resolution order that consists of a single chain of classes that are called in sequence (with any class in the chain allowed to terminate the sequence at any time). Cooperative super() calls are exactly that: cooperative. Just as cooperative threading breaks down if one task doesn't play by the rules, such is also the case with cooperative super calls. There are two ways to handle this: - Option 1 is to tailor your inheritance hierarchy such that any "non-cooperative" classes always appear on the right-most end of the MRO (e.g. as "A" and "object" do in the example above). This can be tricky, but is doable if there is just the one recalcitrant class causing problems (e.g. I wouldn't be surprised to hear that a simple rearrangement to "class MyTestCase(Mixin1, Mixin2, TestCase)" sufficiently rearranged the "MyTestCase" MRO to make this problem go away). - Option 2 is to do as Raymond suggests: noncooperative classes are incorporated via "has-a" composition (potentially as a proxy object) rather than "is-a" inheritance. For any methods which require cooperative calls, the cooperative wrapper provides that behaviour, while delegating the heavy lifting to the underlying object. Essentially, any cooperative hierarchy requires a base class that defines the rules of cooperation and provides "no-op" termination methods for any cooperative calls. Non-cooperative classes must either be parents of that base class, or else they must be wrapped as described in Option 2. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding test case methods to TestCase subclasses
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 Michael Foord is in 2.7 and 3.2 (some bits already in 3.1, I think). The standalone release of that improved codebase is called unittest2. Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Test cases not garbage collected after run
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 unintentionally keeps alive a list outside the TestSuite instance. There's also the problem of reference cycles involving exc_info, bound methods, and so on that make the lifetimes of test cases unpredictable. That's mostly a problem for systems with a very limited allotment of certain resources such as socket handles. However it also makes ensuring the code doesn't regress back to leaking-the-universe more complicated as tests may still survive past the pop. > It's either a general problem that unittest can fix, or it is a problem > *caused* by the bazaar test suite and should be fixed there. Bazaar does > some funky stuff copying tests to run them with different backends, so > it is possible that this is the cause of the problem (and it isn't a > general problem). The fact it's easy to accidentally keep objects alive is a general problem. If every project that writes their own little test loader risks reverting to immortal cases, that's not really progress. The Bazaar example is a warning because the intention was the same as yours, but ended up being a behaviour regression that went unnoticed by most of the developers while crippling others. And as John mentioned, the fix hasn't yet landed, mostly because the hack is good enough for me and the right thing is too complicated. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of json (simplejson) in cpython
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 upstream have already released >> 2.1.13 . >> >> Their 2 roads had diverged a lot, and since this blocks any further >> update of cpython's json from upstream, I'd like to close this gap. > > Are you proposing updates to the Python 3.3 json module > to include newer features like use_decimal and changing > the indent argument from an integer to a string? https://github.com/simplejson/simplejson/blob/master/CHANGES.txt >> - what are we going to do in the long run? > > If Bob shows no interest in Python 3, then > the code bases will probably continue to diverge. I don't have any real interest in Python 3, but if someone contributes the code to make simplejson work in Python 3 I'm willing to apply the patches run the tests against any future changes. The porting work to make it suitable for the standard library at that point should be something that can be automated since it will be moving some files around and changing the string simplejson to json in a whole bunch of places. > 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), which is why the merge is tricky. There's the potential for it to change more in the future, there's definitely more room for optimization. Probably not in the pure python parser, but the C one. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
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 with patches: 1185
Issues opened (31)
==
#9670: Exceed Recursion Limit in Thread
http://bugs.python.org/issue9670 reopened by ned.deily
#11803: Memory leak in sub-interpreters
http://bugs.python.org/issue11803 reopened by swapnil
#11805: package_data only allows one glob per-package
http://bugs.python.org/issue11805 opened by erik.bray
#11807: Documentation of add_subparsers lacks information about parame
http://bugs.python.org/issue11807 opened by gruszczy
#11811: ssl.get_server_certificate() does not work for IPv6 addresses
http://bugs.python.org/issue11811 opened by pwouters
#11812: transient test_telnetlib failure
http://bugs.python.org/issue11812 opened by pitrou
#11813: inspect.getattr_static doesn't get module attributes
http://bugs.python.org/issue11813 opened by Trundle
#11816: Refactor the dis module to provide better building blocks for
http://bugs.python.org/issue11816 opened by eltoder
#11820: idle3 shell os.system swallows shell command output
http://bugs.python.org/issue11820 opened by Thekent
#11822: Improve disassembly to show embedded code objects
http://bugs.python.org/issue11822 opened by rhettinger
#11823: disassembly needs argument counts on calls with keyword args
http://bugs.python.org/issue11823 opened by rhettinger
#11824: freeze.py broken due to ABI flags
http://bugs.python.org/issue11824 opened by Trundle
#11826: Leak in atexitmodule
http://bugs.python.org/issue11826 opened by skrah
#11827: mention of list2cmdline() in docs of subprocess.Popen
http://bugs.python.org/issue11827 opened by eli.bendersky
#11828: startswith and endswith don't accept None as slice index
http://bugs.python.org/issue11828 opened by hkBst
#11829: inspect.getattr_static code execution with meta-metaclasses
http://bugs.python.org/issue11829 opened by Trundle
#11831: "python -w" causes "no Python documentation found" error when
http://bugs.python.org/issue11831 opened by susam
#11832: Add option to pause regrtest to attach a debugger
http://bugs.python.org/issue11832 opened by brian.curtin
#11834: wrong module installation dir on Windows
http://bugs.python.org/issue11834 opened by techtonik
#11835: python (x64) ctypes incorrectly pass structures parameter
http://bugs.python.org/issue11835 opened by Abraham.Soedjito
#11836: multiprocessing.queues.SimpleQueue is undocumented
http://bugs.python.org/issue11836 opened by pitrou
#11838: IDLE: make interactive code runnable.
http://bugs.python.org/issue11838 opened by terry.reedy
#11839: argparse: unexpected behavior of default for FileType('w')
http://bugs.python.org/issue11839 opened by Paolo.Elvati
#11841: Bug in the verson comparison
http://bugs.python.org/issue11841 opened by tarek
#11842: slice.indices with negative step and default stop
http://bugs.python.org/issue11842 opened by durban
#11844: Update json to upstream simplejson latest release
http://bugs.python.org/issue11844 opened by sandro.tosi
#11846: Implementation question for (-5) - 256 caching, and doc update
http://bugs.python.org/issue11846 opened by antlong
#11847: OSError importing antigravity module
http://bugs.python.org/issue11847 opened by ackounts
#11849: ElementTree memory leak
http://bugs.python.org/issue11849 opened by kaifeng
#11851: Flushing the standard input causes an error
http://bugs.python.org/issue11851 opened by pasm...@concepts.nl
#11837: smtplib._quote_periods triggers spurious type error in re.sub
http://bugs.python.org/issue11837 opened by axel
Most recent 15 issues with no replies (15)
==
#11839: argparse: unexpected behavior of default for FileType('w')
http://bugs.python.org/issue11839
#11838: IDLE: make interactive code runnable.
http://bugs.python.org/issue11838
#11837: smtplib._quote_periods triggers spurious type error in re.sub
http://bugs.python.org/issue11837
#11836: multiprocessing.queues.SimpleQueue is undocumented
http://bugs.python.org/issue11836
#11829: inspect.getattr_static code execution with meta-metaclasses
http://bugs.python.org/issue11829
#11826: Leak in atexitmodule
http://bugs.python.org/issue11826
#11824: freeze.py broken due to ABI flags
http://bugs.python.org/issue11824
#11813: inspect.getattr_static doesn't get module attributes
http://bugs.python.org/issue11813
#11812: transient test_telnetlib failure
http://bugs.python.org/issue11812
#11804: expat parser not xml 1.1 (breaks xmlrpclib)
http://bugs.python.org/issue11804
#11784: multiprocessing.Process.join: timeout argument doesn't specify
http://bugs.python.org/issue11784
#11781: test/test_email directory does not get installed by 'make inst
http://bugs.python.org/issue
Re: [Python-Dev] python and super
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, Just as a side note: if there is a bug demonstrated here, it is in unittest2, not Django. Django's TestCase subclasses don't even override __init__ or setUp, so there is no opportunity for them to call or fail to call super() in either case. If you re-read Ricardo's original presentation of the case, he correctly noted that it is unittest2's TestCase which does not call super() and thus prevents cooperative multiple inheritance. I'm not sure who in this thread first mis-read his post and called it a possible bug in Django, but it was a mis-reading which now appears to be self-propagating ;-) Well yes, but it is also a bug in the copy of unittest2 embedded in django - so whilst it can be fixed in unittest2 (simply deleting the setUp and tearDown methods which do nothing but override unittest.TestCase.setUp and tearDown) it *also* needs to be fixed in django. This particular issue does illustrate the problem well though - the methods in unittest2 don't call up to their parent class (which is fine because those methods are empty), but in not calling up also they prevent sibling methods being called in a multiple inheritance situation. So for those who have been saying that not wanting to call up to parents is a valid use case, yes I quite agree. 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. All the best, Michael Foord Carl ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
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 is a bug demonstrated here, it is in unittest2, not Django. Django's TestCase subclasses don't even override __init__ or setUp, so there is no opportunity for them to call or fail to call super() in either case. If you re-read Ricardo's original presentation of the case, he correctly noted that it is unittest2's TestCase which does not call super() and thus prevents cooperative multiple inheritance. I'm not sure who in this thread first mis-read his post and called it a possible bug in Django, but it was a mis-reading which now appears to be self-propagating ;-) Carl ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
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 between parents and siblings. class A: ... class B(A): ... class C(A, B): ... In C, is A a parent of B or a sibling of B? Its neither, as C can't exist: 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 For a super call in C, B is a sibling to A. For a super call in B, A is a parent. With the semantics I was suggesting if C calls super, but A doesn't then B would still get called. A class cannot precede any of its sub-classes in an MRO, see http://en.wikipedia.org/wiki/C3_linearization If A is a "parent" (super-class) of B, then B must precede A in any MRO that contains them both. "Siblings", in the context of a single MRO are thus classes between which there is no sub-class/super-class relation. Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Releases for recent security vulnerability
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 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 vulnerability publicly was to allow time to release a >> >> fix. >> > >> > To me, the fix *was* released. Sure, no fancy installers were generated >> > yet, >> > but people who are susceptible to this issue 1) now know about it, and 2) >> > have a way to patch their system *if needed*. >> > >> > If that's wrong, I apologize for writing the post too early. On top of >> > that, >> > it seems I didn't get all of the details right either, so apologies on that >> > as well. >> >> The code is open source: Anyone watching the commits/list know that >> this issue was fixed. It's better to keep it in the public's eyes, so >> they know *something was fixed and they should patch* than to rely on >> people *not* watching these channels. >> >> Assume the bad guys already knew about the exploit: We have to spread >> the knowledge of the fix as far and as wide as we can so that people >> even know there is an issue, and that it was fixed. This applies to >> users and *vendors* as well. > > True. However, many open source projects take the habit of cutting a > release when a hole is discovered and fixed. It depends how seriously > they (and their users) take security. Of course, there are different > kinds of security issues, more or less severe. I don't know how severe > the above issue is. > > 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 many do use our Windows installers. > > Regards > > Antoine. > Agreed; but all I'm defending is the post describing what, and how it was fixed. Hiding it until we get around to eventually cutting a release doesn't make the fix, or vulnerability go away. We need to issue a release *quickly* - and we need to notify all of our consumers quickly. jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] http://docs.python.org/py3k/ pointing to 2.7
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 small left column link). What do you think?. http://docs.python.org/ points to 2.7 yes. I'm already reading 3.3 doc to develop with Python 2.5: I prefer the most recent doc, and the API is usually exactly the same. So I vote +1 to make 3.3 the default doc. Anyway, Python 2 is a dead language! I don't like URL prefixes to indicate the version: "py3k/" for 3.2 (last Python 3 stable version), no prefix for 2.7, "release/2.6.6/" for 2.6, "dev/py3k/" for 3.3, etc. Can't we keep it simple as: - "2.6/" for 2.6 - "2.7/" for 2.7 - "3.1/" for 3.1 - "3.2/" for 3.2 - "3.3/" for 3.3 - "2.x/" (or maybe just "2/"?) as a redirection to 2.7 - "3.x/" (or maybe just "3/"?) as a redirection to 3.3 http://docs.python.org/ may be a redirection (to http://docs.python.org/3.x/) instead of directly the doc. So it would be intuitive to replace 2 by 3 (or 3 by 2) in the URL. The http://www.python.org/doc/versions/ page uses other URLS: http://www.python.org/doc// which are redirections to http://docs.python.org/release//. For example: http://www.python.org/doc/3.2/ is a redirection to http://docs.python.org/release/3.2/ (which give the same content than http://docs.python.org/py3k/ !). On the left of http://docs.python.org/, you have links to other versions of the doc: 2.6, 3.2, 3.3... but not 3.1. 3.3 doc have links to 2.7 and 3.2 (not 2.6 or 3.1). If there is a rule to choose links on the left, I don't understand this rule. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Releases for recent security vulnerability
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 many do use our Windows installers. Antoine, I actually expect many companies build their own Python for production use; relying on the system Python has long been considered a stability vulnerability by many of us. This is especially the case for large deployments, where machines are less likely to receive updates quickly. I'd strongly recommend making sure releases are available for download quickly in cases like this, even if (in any particular case) we think a vulnerability is unlikely to affect many users. Whenever we think something like that, we're always wrong. -Fred -- Fred L. Drake, Jr. "Give me the luxuries of life and I will willingly do without the necessities." --Frank Lloyd Wright ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
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 class inherits from unittest2.TestCase, which we
found was not calling super. Even if this is a bug and should be fixed
in unittest2, this is an example where I, as a consumer of django,
shouldn't have to be worried about how django's TestCase class is
implemented. Since I explicitely base off 3 classes, I expected all 3
classes to be initialized, and I expect the setUp method to be called
on all of them.
If I'm assuming/expecting unreasonable things, please enlighten me.
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, however consider the "recently" introduced
problem caused by object.__init__ not taking arguments. This makes it
impossible to use super correctly in various circumstances.
http://freshfoo.com/blog/object__init__takes_no_parameters
Given the following classes (Python 3):
class A:
def __init__(self, a):
print ('A')
class B:
def __init__(self, a):
print ('B')
class C(B):
def __init__(self, a):
print ('C')
super().__init__(a)
It is impossible to inherit from both C and A and have all parent
__init__ methods called correctly. Changing the semantics of super as
described would fix this problem.
For:
class D(C, A):
def __init__(self, a):
super().__init__(a)
D(1)
This is printed:
C
B
(A __init__ is not called).
For this:
class D(A, C):
def __init__(self, a):
super().__init__(a)
D(1)
The following is printed:
A
(B and C __init__ methods are not called.)
All the best,
Michael Foord
"I, as a consumer of django, shouldn't have to be worried about bugs
in django". (For at least one class of bug.)
If we *don't* treat django's failure to use super as a bug, but as a
deliberate design choice, then you are trying to do something which
django doesn't support. Possibly *deliberately* doesn't support. You
want the Python language to add that support so that:
"I, as a consumer of django, shouldn't have to be worried about
whether django supports what I want to do or not".
Either way you look at it, I think it's extremely unreasonable to
expect the language to work-around bugs in third-party applications,
or to add features to them that the third-party developers either
didn't consider or don't want.
Multiple inheritance is tricky enough to get right without adding "Do
What I Mean" black magic to it. I'd rather work around bugs in
third-party classes than try to deal with Python actively subverting
the code I read and write by mysteriously calling superclass methods
where there is no call to a superclass method.
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
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 siblings. class A: ... class B(A): ... class C(A, B): ... In C, is A a parent of B or a sibling of B? For a super call in C, B is a sibling to A. For a super call in B, A is a parent. With the semantics I was suggesting if C calls super, but A doesn't then B would still get called. All the best, Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Releases for recent security vulnerability
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 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 vulnerability publicly was to allow time to release a > >> fix. > > > > To me, the fix *was* released. Sure, no fancy installers were generated yet, > > but people who are susceptible to this issue 1) now know about it, and 2) > > have a way to patch their system *if needed*. > > > > If that's wrong, I apologize for writing the post too early. On top of that, > > it seems I didn't get all of the details right either, so apologies on that > > as well. > > The code is open source: Anyone watching the commits/list know that > this issue was fixed. It's better to keep it in the public's eyes, so > they know *something was fixed and they should patch* than to rely on > people *not* watching these channels. > > Assume the bad guys already knew about the exploit: We have to spread > the knowledge of the fix as far and as wide as we can so that people > even know there is an issue, and that it was fixed. This applies to > users and *vendors* as well. True. However, many open source projects take the habit of cutting a release when a hole is discovered and fixed. It depends how seriously they (and their users) take security. Of course, there are different kinds of security issues, more or less severe. I don't know how severe the above issue is. 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 many do use our Windows installers. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Releases for recent security vulnerability
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/04/urllib-security-vulnerability-fixed.html >> >> My understanding is that the whole point of asking people not to >> report security vulnerability publicly was to allow time to release a >> fix. > > To me, the fix *was* released. Sure, no fancy installers were generated yet, > but people who are susceptible to this issue 1) now know about it, and 2) > have a way to patch their system *if needed*. > > If that's wrong, I apologize for writing the post too early. On top of that, > it seems I didn't get all of the details right either, so apologies on that > as well. The code is open source: Anyone watching the commits/list know that this issue was fixed. It's better to keep it in the public's eyes, so they know *something was fixed and they should patch* than to rely on people *not* watching these channels. Assume the bad guys already knew about the exploit: We have to spread the knowledge of the fix as far and as wide as we can so that people even know there is an issue, and that it was fixed. This applies to users and *vendors* as well. A blog post is good communication to our users. I have to side with Brian on this one. jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Releases for recent security vulnerability
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 is that the whole point of asking people not to > report security vulnerability publicly was to allow time to release a > fix. To me, the fix *was* released. Sure, no fancy installers were generated yet, but people who are susceptible to this issue 1) now know about it, and 2) have a way to patch their system *if needed*. If that's wrong, I apologize for writing the post too early. On top of that, it seems I didn't get all of the details right either, so apologies on that as well. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] http://docs.python.org/py3k/ pointing to 2.7
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] http://docs.python.org/py3k/ pointing to 2.7
-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). What do you think?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTagtY5lgi5GaxT1NAQKCigP/YwAMrqyQglgJa85rXBQrFVdvHPcNASab Fw7PWTMdg7Hxof/cXn9gsdiR3fGqVrRv9G5V64hxi6WN5aVbXDyAMJzxsCEAtPfW PkRDvdZKsKD1xgxLKIZo1gUCY80Xqrts+kXRJKGtA/TeXzmqhhknHQyHW0oiYK3t jL9qRKGxVO0= =gFw7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python and super
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, it's safer to explicitly name that class. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Releases for recent security vulnerability
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 understanding is that the whole point of asking people not to > report security vulnerability publicly was to allow time to release a > fix. Yes, I agree with you. I am surprised that it made it to blog and just catching more attention (via Responses/Retweets) than what it is worth. FWIW, if we analyze the technical details more carefully, urllib/urllib2 as a library could have redirected to file:// url, but it is library and not web-server and person who wrote the server could catch the redirection and handle it at higher level too. This may sound less drastic than what it appears in the post. Anyways it was an issue and it is fixed. -- Senthil Knghtbrd: irc doesn't compile c code very well ;) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Releases for recent security vulnerability
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 vulnerability publicly was to allow time to release a fix. If developers haven't had enough time to release the fix, that's fine. But I can't think of a sensible reason why it should be announced first. Cheers, - Gustavo. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
