Re: [Python-Dev] Python 2.6.5

Le mercredi 10 février 2010 à 05:26 +0100, "Martin v. Löwis" a écrit : > > Maybe I'm being pedantic, but I really think there should be more > objective criteria for such things. Well we could try to find objective criteria but I'm not sure we'll find agreement on them. > We could set a policy

Re: [Python-Dev] Python 2.6.5

anatoly techtonik gmail.com> writes: > > Is it possible to make exploits out of crashers? It depends which ones. If it's something like a buffer overflow or a memory management problem, it may be possible to exploit it through carefully crafted input (in order to make the interpreter execute arb

Re: [Python-Dev] Python 2.6.5

> On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" wrote: >>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are kn

Re: [Python-Dev] Python 2.6.5

On Feb 9, 2010, at 9:54 PM, anatoly techtonik wrote: > > Is it possible to make exploits out of crashers? The crashers involve creating convoluted python code, but then if you're in a position to execute arbitrary Python code, then you don't have to resort to any tricks to do something nasty wit

Re: [Python-Dev] Python 2.6.5

On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" wrote: >> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : >>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this >>> one - http://bugs.python.org/issue6608  Is it ok to release new versions >>> that are known to

Re: [Python-Dev] Python 2.6.5

On Feb 9, 2010, at 5:20 PM, Martin v. Löwis wrote: > Of course, the release manager can always declare anything a release > blocker, so that may have been the reason (I don't recall the details). I should probably clarify my last statement. I will sometimes mark an issue "release blocker" becau

Re: [Python-Dev] Python 2.6.5

On Feb 9, 2010, at 4:55 PM, Martin v. Löwis wrote: >> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : >>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this >>> one - http://bugs.python.org/issue6608 Is it ok to release new versions >>> that are known to crash?

Re: [Python-Dev] Python 2.6.5

Antoine Pitrou wrote: > Martin v. Löwis v.loewis.de> writes: >> IOW, I feel that release blockers should only be used if something >> really bad would happen that can be prevented by not releasing. If >> nothing actually gets worse by the release, the release shouldn't be >> blocked. > > I think

Re: [Python-Dev] setUpClass and setUpModule in unittest

Michael Foord writes: > I've used unittest for long running functional and integration tests > (in both desktop and web applications). The infrastructure it provides > is great for this. Don't get hung up on the fact that it is called > unittest. In fact for many users the biggest reason it isn't

Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues

Michael Foord writes: > On 09/02/2010 21:50, Ben Finney wrote: > > I understood the point of ‘TestCase.shortDescription’, and indeed > > the point of that particular name, was to be clear that some *other* > > text could be the short description for the test case. Indeed, this > > is what you've

Re: [Python-Dev] PEP 385 progress report

2010/2/9 Dirkjan Ochtman : > On Tue, Feb 9, 2010 at 04:47, Benjamin Peterson wrote: >> I don't believe so. My plan was to manually sync updates or use subrepos. > > Using subrepos should work well for this. Excellent. > > It turned out that my local copy of the Subversion repository > contained

[Python-Dev] PyCon is coming! Tomorrow, Feb. 10th is the last day for pre-conference rates

PyCon is coming! Tomorrow (February 10th) is the last day for pre-conference rates. You can register for PyCon online at: Register while it is still Feb. 10th somewhere in the world and rest easy in the knowledge that within 10 days you will enjoying the comp

[Python-Dev] Request for review of issue 4037

Hello, I have submitted a patch and a test script for issue 4037 on the bug tracker, "doctest.py should include method descriptors when looking inside a class __dict__" http://bugs.python.org/issue4037 I would be grateful if somebody could review it please, and if suitable, commit it. Thank

Re: [Python-Dev] PEP 345 and PEP 386

On Wed, Feb 10, 2010 at 12:29 AM, Guido van Rossum wrote: [..] > > Since this is done I now approve both PEP 345 and PEP 386 (which is > not to say that small editorial changes to the text couldn't be made). Thanks ! Thanks to all the people that helped in those PEPs Tarek _

Re: [Python-Dev] PEP 345 and PEP 386

On Thu, Feb 4, 2010 at 2:55 PM, Tarek Ziadé wrote: > On Thu, Feb 4, 2010 at 8:20 PM, Guido van Rossum wrote: > [..] >> I have one comment on PEP 345: Why is author-email mandatory? I'm sure >> there are plenty of cases where either the author doesn't want their >> email address published, or thei

Re: [Python-Dev] Python 2.6.5

Martin v. Löwis v.loewis.de> writes: > > IOW, I feel that release blockers should only be used if something > really bad would happen that can be prevented by not releasing. If > nothing actually gets worse by the release, the release shouldn't be > blocked. I think most blocking bugs we've had

Re: [Python-Dev] setUpClass and setUpModule in unittest

On 10:42 pm, fuzzy...@voidspace.org.uk wrote: On 09/02/2010 21:57, Ben Finney wrote: Michael Foord writes: The next 'big' change to unittest will (may?) be the introduction of class and module level setUp and tearDown. This was discussed on Python-ideas and Guido supported them. They can be us

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

To follow up on some of the open issues: On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter wrote: [snip] > Open Issues > === > > - *Code review policy for the ``py3k-jit`` branch.* How does the CPython >  community want us to procede with respect to checkins on the ``py3k-jit`` >  branch? Pr

Re: [Python-Dev] setUpClass and setUpModule in unittest

On 09/02/2010 21:57, Ben Finney wrote: Michael Foord writes: The next 'big' change to unittest will (may?) be the introduction of class and module level setUp and tearDown. This was discussed on Python-ideas and Guido supported them. They can be useful but are also very easy to abuse (too

Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues

On 09/02/2010 21:50, Ben Finney wrote: Michael Foord writes: It seems to me that the same effect (always reporting test name) can be achieved in _TextTestResult.getDescription(). I propose to revert the change to TestCase.shortDescription() (which has both a horrible name and a horrible im

Re: [Python-Dev] setUpClass and setUpModule in unittest

On 2010-02-09 15:57 PM, Ben Finney wrote: Is there a better third-party framework for use in these cases? As Olemis points out later in this thread, I don't think it's good for the ‘unittest’ module to keep growing for uses that aren't focussed on unit tests (as contrasted with other kinds of te

Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues

On 09/02/2010 22:22, Olemis Lang wrote: On Tue, Feb 9, 2010 at 4:50 PM, Ben Finney wrote: Michael Foord writes: It seems to me that the same effect (always reporting test name) can be achieved in _TextTestResult.getDescription(). I propose to revert the change to TestCase.shortDesc

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney wrote: > Michael Foord writes: > >> The next 'big' change to unittest will (may?) be the introduction of >> class and module level setUp and tearDown. This was discussed on >> Python-ideas and Guido supported them. They can be useful but are also >> ver

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Tue, Feb 9, 2010 at 4:57 PM, Ben Finney wrote: > Michael Foord writes: > >> The next 'big' change to unittest will (may?) be the introduction of >> class and module level setUp and tearDown. This was discussed on >> Python-ideas and Guido supported them. They can be useful but are also >> very

Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues

On Tue, Feb 9, 2010 at 4:50 PM, Ben Finney wrote: > Michael Foord writes: > >> It seems to me that the same effect (always reporting test name) can >> be achieved in _TextTestResult.getDescription(). I propose to revert >> the change to TestCase.shortDescription() (which has both a horrible >> na

Re: [Python-Dev] Python 2.6.5

>>> I've changed this issue to release blocker. What are the other issues? >> For a bug fix release, it should (IMO) be a release blocker *only* if >> this is a regression in the branch or some recent bug fix release over >> some earlier bug fix release. > > As far as I remember, I think we have h

Re: [Python-Dev] Python 2.6.5

Le mardi 09 février 2010 à 22:55 +0100, "Martin v. Löwis" a écrit : > > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : > >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this > >> one - http://bugs.python.org/issue6608 Is it ok to release new versions > >> that

Re: [Python-Dev] setUpClass and setUpModule in unittest

Michael Foord writes: > The next 'big' change to unittest will (may?) be the introduction of > class and module level setUp and tearDown. This was discussed on > Python-ideas and Guido supported them. They can be useful but are also > very easy to abuse (too much shared state, monolithic test cla

Re: [Python-Dev] Python 2.6.5

> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this >> one - http://bugs.python.org/issue6608 Is it ok to release new versions >> that are known to crash? > > I've changed this issue to release blocker. What a

Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues

Michael Foord writes: > It seems to me that the same effect (always reporting test name) can > be achieved in _TextTestResult.getDescription(). I propose to revert > the change to TestCase.shortDescription() (which has both a horrible > name and a horrible implementation and should probably be re

Re: [Python-Dev] Python 2.6.5

> I've noticed a couple of issues that 100% crash Python 2.6.4 like this > one - http://bugs.python.org/issue6608 Is it ok to release new > versions that are known to crash? As a general principle: yes, that's ok. We even distribute known crashers with every release. Regards, Martin ___

Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues

I missed another minor issue. In the interests of completeness... You currently have to subclass TextTestRunner (and override _makeResult) for it to use a custom TestResult. Implementing a custom test result is one of extensibility points of unittest, so I propose adding an optional argument t

Re: [Python-Dev] Forking and Multithreading - enemy brothers

Hello Some update about the spawnl() thingy ; I've adapted the win32 code to have a new unix Popen object, which works with a spawn() semantic. It's quite straightforward, and the mutiprocessing call of a python functions works OK. But I've run into some trouble : synchronization primitives.

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Tue, Feb 9, 2010 at 2:16 PM, Brian Curtin wrote: > On Tue, Feb 9, 2010 at 12:29, Olemis Lang wrote: >> >> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord >> wrote: >> > I'm pretty sure I can introduce setUpClass and setUpModule without >> > breaking >> > compatibility with existing unittest ex

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Tue, Feb 9, 2010 at 1:44 PM, Michael Foord wrote: > On 09/02/2010 17:57, Antoine Pitrou wrote: >> >> Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit : >> >>> >>> The next 'big' change to unittest will (may?) be the introduction of >>> class and module level setUp and tearDown. This wa

Re: [Python-Dev] setUpClass and setUpModule in unittest

On 09/02/2010 19:14, Holger Krekel wrote: [snip...] and all tests in the class / module will have an explicit skip in the event of a setUp failure. I think reporting tests as skipped when the setup failed is a bad idea. Out of several years of practise with skips and large test suites

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Tue, Feb 9, 2010 at 12:29, Olemis Lang wrote: > On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord > wrote: > > I'm pretty sure I can introduce setUpClass and setUpModule without > breaking > > compatibility with existing unittest extensions or backwards > compatibility > > issues > > Is it possi

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Tue, Feb 9, 2010 at 7:29 PM, Olemis Lang wrote: > On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord > wrote: >> Hello all, >> >> Several >> authors of other Python testing frameworks spoke up *against* them, but >> several *users* of test frameworks spoke up in favour of them. ;-) >> > > +1 for h

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou wrote: > Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit : >> >> The next 'big' change to unittest will (may?) be the introduction of >> class and module level setUp and tearDown. This was discussed on >> Python-ideas and Guido supported th

Re: [Python-Dev] setUpClass and setUpModule in unittest

On 09/02/2010 19:00, Olemis Lang wrote: Sorry. I had not finished the previous message On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang wrote: On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang wrote: On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord wrote: Hello all, Several authors

Re: [Python-Dev] setUpClass and setUpModule in unittest

Sorry. I had not finished the previous message On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang wrote: > On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang wrote: >> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord >> wrote: >>> Hello all, >>> >>> Several >>> authors of other Python testing frameworks spoke

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang wrote: > On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord > wrote: >> Hello all, >> >> Several >> authors of other Python testing frameworks spoke up *against* them, but >> several *users* of test frameworks spoke up in favour of them. ;-) >> > > +1 for h

Re: [Python-Dev] setUpClass and setUpModule in unittest

On 09/02/2010 17:57, Antoine Pitrou wrote: Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit : The next 'big' change to unittest will (may?) be the introduction of class and module level setUp and tearDown. This was discussed on Python-ideas and Guido supported them. They can be usef

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord wrote: > Hello all, > > Several > authors of other Python testing frameworks spoke up *against* them, but > several *users* of test frameworks spoke up in favour of them. ;-) > +1 for having something like that included in unittest > I'm pretty sure

Re: [Python-Dev] setUpClass and setUpModule in unittest

Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit : > > The next 'big' change to unittest will (may?) be the introduction of > class and module level setUp and tearDown. This was discussed on > Python-ideas and Guido supported them. They can be useful but are also > very easy to abuse (too

Re: [Python-Dev] Python 2.6.5

On Tue, Feb 9, 2010 at 06:45, anatoly techtonik wrote: > On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou > wrote: > > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : > >> > >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this > >> one - http://bugs.python.org

[Python-Dev] setUpClass and setUpModule in unittest

Hello all, The next 'big' change to unittest will (may?) be the introduction of class and module level setUp and tearDown. This was discussed on Python-ideas and Guido supported them. They can be useful but are also very easy to abuse (too much shared state, monolithic test classes and module

[Python-Dev] unittest: shortDescription, _TextTestResult and other issues

Hello all, I've been looking at outstanding unittest issues as part of my preparation for my PyCon talk. There are a couple of changes (minor) I'd like to make that I thought I ought to run past Python-Dev first. If I don't get any responses then I'll just do it, so you have been warned. :-)

Re: [Python-Dev] Python 2.6.5

On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou wrote: > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : >> >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this >> one - http://bugs.python.org/issue6608  Is it ok to release new versions >> that are known to cra

Re: [Python-Dev] crashers

> There are 65 entries and among them I can additionally confirm: > http://bugs.python.org/issue3720 > http://bugs.python.org/issue7788 > http://bugs.python.org/issue5765 One of them is fixed and the other two are pathological cases. You can't really trigger them by mistake. Regards Antoine.

Re: [Python-Dev] Python 2.6.5

Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : > > I've noticed a couple of issues that 100% crash Python 2.6.4 like this > one - http://bugs.python.org/issue6608 Is it ok to release new versions > that are known to crash? I've changed this issue to release blocker. What are the

Re: [Python-Dev] PEP 385 progress report

On Tue, Feb 9, 2010 at 04:47, Benjamin Peterson wrote: > I don't believe so. My plan was to manually sync updates or use subrepos. Using subrepos should work well for this. It turned out that my local copy of the Subversion repository contained the Python dir only, so I'm now syncing a full copy

Re: [Python-Dev] Python 2.6.5

On Tue, Feb 2, 2010 at 8:08 PM, Barry Warsaw wrote: > I'm thinking about doing a Python 2.6.5 release soon.  I've added the > following dates to the Python release schedule Google calendar: > > 2009-03-01 Python 2.6.5 rc 1 > 2009-03-15 Python 2.6.5 final > > This allows us to spend some time on 2.

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Terry Reedy wrote: > Definitely. I have even wondered whether it would be possible to cache > not just the bytecode for initializing a module, but also the > initialized module itself (perhaps minus the name bindings for other > imported modules). Not easily, since running the module may have othe