On Tue, Mar 5, 2013 at 10:02 AM, Glyph wrote:
> On Mar 4, 2013, at 11:13 PM, Robert Collins
> wrote:
>
> In principle maybe. Need to talk with the trial developers, nose
> developers, py.test developers etc - to get consensus on a number of
> internal API friction points.
>
>
> Some of trial's l
On Fri, Apr 29, 2011 at 12:31 AM, Raymond Hettinger
wrote:
>
> On Apr 28, 2011, at 3:07 PM, Guido van Rossum wrote:
>
>> On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger
>> wrote:
>>>
>>> On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
>>>
On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
>> In my opinion assert should be avoided completely anywhere else than
>> in the tests. If this is a wrong statement, please let me know why :)
>
> I would turn that around. The assert
On Mon, Aug 2, 2010 at 8:48 PM, Michael Foord wrote:
> On 02/08/2010 19:45, Holger Krekel wrote:
[...]
>>>> I'd much prefer a one-step process and rather provide a way to not-use
>>>> a plugin even if installed. The difference is e.g. with py.test th
On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord wrote:
> On 02/08/2010 19:05, Holger Krekel wrote:
>>
>> On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking wrote:
>>
>>>
>>> Just to add a general opinion in here:
>>>
>>> Having worked w
On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking wrote:
> Just to add a general opinion in here:
>
> Having worked with Setuptools' entry points, and a little with some Zope
> pluginish systems (Products.*, which I don't think anyone liked much, and
> some ways ZCML is used is pluginish), I'm not very
On Fri, Feb 12, 2010 at 12:00 AM, Robert Kern wrote:
> On 2010-02-11 16:20 PM, Ben Finney wrote:
>>
>> Guido van Rossum writes:
>
>>> The argument that a unittest framework shouldn't be "abused" for
>>> regression tests (or integration tests, or whatever) is also bizarre
>>> to my mind. Surely if
Hi Guido,
On Thu, Feb 11, 2010 at 7:11 PM, Guido van Rossum wrote:
> On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord
> wrote:
>> 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 suppo
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
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
Hello Python-dev!
we have a document on PyPy's interpreter and translation
features that might be of interest to you - we target
it at language implementors in general: Includes
a discussion on our .NET and also the emerging Java
backends, as well as our RPython -> Javascript webapp
generating
On Fri, Sep 09, 2005 at 11:31 -0700, Russell E. Owen wrote:
> In article <[EMAIL PROTECTED]>,
> Tristan Seligmann <[EMAIL PROTECTED]> wrote:
> >
> > Why does it matter if the single statement you insert is spelled
> > " metaclass = type" instead of "from future import whatever"?
> > Rememb
[Guido]
> [Holger]
> > However, i would find it much clearer if *defining* blocktemplates
> > used a new keyword, like:
> >
> > blocktemplate opening(filename, mode="r"):
> > ...
> >
> > because this immediately tells me what the purpose and semantics
> > of the folowing definition is
Hi Guido,
On Mon, May 02, 2005 at 17:55 -0700, Guido van Rossum wrote:
> These are the loose ends on the PEP (apart from filling in some
> missing sections):
>
> 1. Decide on a keyword to use, if any.
I just read the PEP340 basically the first time so bear with me.
First i note that introduci
Hi Nick,
On Sun, Apr 24, 2005 at 12:40 +1000, Nick Coghlan wrote:
> Seeing this example has convinced me of something. PEP 310 should use the
> 'with' keyword, and 'expression block' syntax should be used to denote the
> 'default object' semantics proposed for Python 3K. For example:
While tha
On Sat, Apr 23, 2005 at 13:41 +1000, Nick Coghlan wrote:
> Nick Coghlan wrote:
> In light of Alex's comments, I'd actually like to suggest the below as a
> potential new definition for PEP 310 (making __exit__ optional, and adding
> an __else__ handler):
>
> if hasattr(x, '__enter__'):
>
On Fri, Apr 22, 2005 at 19:03 -0700, Josiah Carlson wrote:
> [EMAIL PROTECTED] (holger krekel) wrote:
> > basically translates to:
> >
> > if hasattr(x, '__enter__'):
> > x.__enter__()
> > try:
> > ...
> >
Hi all,
probably unsuprisingly i am still pondering the idea of having
an optional __except__ hook on block handlers. The PEP says this
about this:
An extension to the protocol to include an optional __except__
handler, which is called when an exception is raised, and which
can han
[Guido van Rossum Wed, Dec 08, 2004 at 02:18:48PM -0800]
> I was pleasantly surprised to find a pointer to this article in a news
> digest that the ACM emails me regularly (ACM TechNews).
>
> http://gcn.com/vol1_no1/daily-updates/28026-1.html
>
> One thing that bugs me: the article says 3 or 4 ti
[Stelios Xanthakis Fri, Dec 03, 2004 at 11:59:30PM +0200]
> On Fri, 3 Dec 2004, holger krekel wrote:
> >We are about to test out this approach with the py lib
> >(http://codespeak.net/py) and want to have it work for
> >for Python 2.2, 2.3. and 2.4.
>
> Do you plan ha
Hi Stelios,
[Stelios Xanthakis Fri, Dec 03, 2004 at 11:54:25AM +0200]
> Abstract
>
> This PEP suggests the implementation of __source__ attribute for
> functions and classes. The attribute is a read-only string which
> is generated by the parser and is a copy of the original source
21 matches
Mail list logo
