Re: [Python-Dev] Python Language Summit at PyCon: Agenda

[Antoine Pitrou]

Le Mon, 4 Mar 2013 19:46:07 +1300,
Robert Collins  a écrit :
> On 4 March 2013 19:40, Nick Coghlan  wrote:
> 
> > Your feedback on http://bugs.python.org/issue16997 would be greatly
> > appreciated.
> 
> Done directly to Antoine on IRC the other day in a conversation with
> him and Michael about the compatability impact of subtests. Happy to
> do a full code review if that would be useful.

Indeed and some of the changes in the latest patch stem from that
conversation.

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] Disabling string interning for null and single-char causes segfaults

[Serhiy Storchaka]

On 02.03.13 22:32, Terry Reedy wrote:

I am just curious: does 3.3 still
intern (some) unicode chars? Did the 256 interned bytes of 2.x carry
over to 3.x?


Yes, Python 3 interns an empty string and first 256 Unicode characters.


___
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] Disabling string interning for null and single-char causes segfaults

[Serhiy Storchaka]

On 01.03.13 17:24, Stefan Bucur wrote:

Before digging deeper into the issue, I wanted to ask here if there are
any implicit assumptions about string identity and interning throughout
the interpreter implementation. For instance, are two single-char
strings having the same content supposed to be identical objects?


I think this is not a bug if the code relies on the fact that an empty 
string is a singleton. This obviously is an immutable object and there 
is no public method to create different empty string. But a user can 
create different 1-character strings with same value (first create 
uninitialized a 1-character string and than fill a content). If some 
code fails when none of 1-character strings are interned, this obviously 
is a bug.



___
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 Language Summit at PyCon: Agenda

[Barry Warsaw]

On Mar 04, 2013, at 07:26 PM, Robert Collins wrote:

>It is of course possible for subunit and related tools to run their
>own implementation, but it seems ideal to me to have a common API
>which regular unittest, nose, py.test and others can all agree on and
>use : better reuse for pretty printers, GUI displays and the like
>depend on some common API.

And One True Way of invoking and/or discovering how to invoke, a package's
test suite.

-Barry
___
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] Introducing Electronic Contributor Agreements

[Brian Curtin]

The full announcement is at
http://blog.python.org/2013/03/introducing-electronic-contributor.html,
but a summary follows.

We've now moved to an electronic Contributor License Agreement form at
http://www.python.org/psf/contrib/contrib-form/ which will hopefully
ease the signing and sending of forms for our potential contributors.
The form shows the required fields whether you're signing as an
individual or a representative of an organization, and removes the
need to print, scan, fax, etc.

When a new contributor fills in the form, they are emailed a copy of
the form and asked to confirm the email address that they used (and
received that copy at). Upon confirming, the signed form is sent to
the PSF Administrator and filed away.

The signature can either be generated from your typed name, or you can
draw or upload your actual written signature if you choose.
___
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] Introducing Electronic Contributor Agreements

[Brett Cannon]

On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin  wrote:

> The full announcement is at
> http://blog.python.org/2013/03/introducing-electronic-contributor.html,
> but a summary follows.
>
> We've now moved to an electronic Contributor License Agreement form at
> http://www.python.org/psf/contrib/contrib-form/ which will hopefully
> ease the signing and sending of forms for our potential contributors.
> The form shows the required fields whether you're signing as an
> individual or a representative of an organization, and removes the
> need to print, scan, fax, etc.
>
> When a new contributor fills in the form, they are emailed a copy of
> the form and asked to confirm the email address that they used (and
> received that copy at). Upon confirming, the signed form is sent to
> the PSF Administrator and filed away.
>
> The signature can either be generated from your typed name, or you can
> draw or upload your actual written signature if you choose.


With this in place I would like to propose that all patches submitted to
bugs.python.org must come from someone who has signed the CLA before we
consider committing it (if you want to be truly paranoid we could say that
we won't even look at the code w/o a CLA).
___
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 Language Summit at PyCon: Agenda

[Brett Cannon]

On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw  wrote:

> On Mar 04, 2013, at 07:26 PM, Robert Collins wrote:
>
> >It is of course possible for subunit and related tools to run their
> >own implementation, but it seems ideal to me to have a common API
> >which regular unittest, nose, py.test and others can all agree on and
> >use : better reuse for pretty printers, GUI displays and the like
> >depend on some common API.
>
> And One True Way of invoking and/or discovering how to invoke, a package's
> test suite.
>

How does unittest's test discovery not solve that?
___
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 Language Summit at PyCon: Agenda

[David Cournapeau]

On Mon, Mar 4, 2013 at 4:34 PM, Brett Cannon  wrote:
>
>
>
> On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw  wrote:
>>
>> On Mar 04, 2013, at 07:26 PM, Robert Collins wrote:
>>
>> >It is of course possible for subunit and related tools to run their
>> >own implementation, but it seems ideal to me to have a common API
>> >which regular unittest, nose, py.test and others can all agree on and
>> >use : better reuse for pretty printers, GUI displays and the like
>> >depend on some common API.
>>
>> And One True Way of invoking and/or discovering how to invoke, a package's
>> test suite.
>
>
> How does unittest's test discovery not solve that?

It is not always obvious how to test a package when one is not
familiar with it. Are the tests in pkgname/tests or tests or ... ?

In the scientific community, we have used the convention of making the
test suite available at runtime with pkgname.tests().

David
___
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 Language Summit at PyCon: Agenda

[Brett Cannon]

On Mon, Mar 4, 2013 at 11:44 AM, David Cournapeau wrote:

> On Mon, Mar 4, 2013 at 4:34 PM, Brett Cannon  wrote:
> >
> >
> >
> > On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw  wrote:
> >>
> >> On Mar 04, 2013, at 07:26 PM, Robert Collins wrote:
> >>
> >> >It is of course possible for subunit and related tools to run their
> >> >own implementation, but it seems ideal to me to have a common API
> >> >which regular unittest, nose, py.test and others can all agree on and
> >> >use : better reuse for pretty printers, GUI displays and the like
> >> >depend on some common API.
> >>
> >> And One True Way of invoking and/or discovering how to invoke, a
> package's
> >> test suite.
> >
> >
> > How does unittest's test discovery not solve that?
>
> It is not always obvious how to test a package when one is not
> familiar with it. Are the tests in pkgname/tests or tests or ... ?
>

I would argue that's a packaging problem and not a testing infrastructure
in the stdlib problem. If we want to standardize on always having the tests
in a 'tests' sub-package that's fine, but I don't see unittest or subtest
directly controlling that short of some registration hook that has to be
called to declare where the tests are.
___
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 Language Summit at PyCon: Agenda

[Barry Warsaw]

On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote:

>> And One True Way of invoking and/or discovering how to invoke, a package's
>> test suite.
>
>How does unittest's test discovery not solve that?

I should have added "from the command line".  E.g. is it:

$ python -m unittest discover
$ python setup.py test
$ python setup.py nosetests
$ python -m nose test
$ nosetests-X.Y

Besides having a multitude of choices, there's almost no way to automatically
discover (e.g. by metadata inspection or some such) how to invoke the tests.
You're often lucky if there's a README.test and it's still accurate.

Cheers,
-Barry


signature.asc
Description: 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] Introducing Electronic Contributor Agreements

[Skip Montanaro]

On Mon, Mar 4, 2013 at 10:30 AM, Brian Curtin  wrote:

> The full announcement is at
> http://blog.python.org/2013/03/introducing-electronic-contributor.html,
> but a summary follows.
> ...


Brian,

Do you want old-timers like me who have a wet-signed fax gathering dust in
a  box at PSF World Headquarters to execute the electronic contributor
agreement?  While not strictly necessary, I suspect it might be nice for
you to have all agreements in a common form.

Skip
___
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] Introducing Electronic Contributor Agreements

[Brian Curtin]

On Mon, Mar 4, 2013 at 11:02 AM, Skip Montanaro  wrote:
>
>
> On Mon, Mar 4, 2013 at 10:30 AM, Brian Curtin  wrote:
>>
>> The full announcement is at
>> http://blog.python.org/2013/03/introducing-electronic-contributor.html,
>> but a summary follows.
>> ...
>
>
> Brian,
>
> Do you want old-timers like me who have a wet-signed fax gathering dust in a
> box at PSF World Headquarters to execute the electronic contributor
> agreement?  While not strictly necessary, I suspect it might be nice for you
> to have all agreements in a common form.

I'll check on that, but I don't think it's necessary since the
gathered data is no different.
___
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 Language Summit at PyCon: Agenda

[Antoine Pitrou]

On Mon, 4 Mar 2013 11:51:04 -0500
Barry Warsaw  wrote:
> On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote:
> 
> >> And One True Way of invoking and/or discovering how to invoke, a package's
> >> test suite.
> >
> >How does unittest's test discovery not solve that?
> 
> I should have added "from the command line".  E.g. is it:
> 
> $ python -m unittest discover
> $ python setup.py test
> $ python setup.py nosetests
> $ python -m nose test
> $ nosetests-X.Y
> 
> Besides having a multitude of choices, there's almost no way to automatically
> discover (e.g. by metadata inspection or some such) how to invoke the tests.
> You're often lucky if there's a README.test and it's still accurate.

I hope we can have a "pytest" utility that does the right thing in
3.4 :-)
Typing "python -m unittest discover" is too cumbersome.

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] Disabling string interning for null and single-char causes segfaults

[Amaury Forgeot d'Arc]

2013/3/4 Serhiy Storchaka 

> On 01.03.13 17:24, Stefan Bucur wrote:
>
>> Before digging deeper into the issue, I wanted to ask here if there are
>> any implicit assumptions about string identity and interning throughout
>> the interpreter implementation. For instance, are two single-char
>> strings having the same content supposed to be identical objects?
>>
>
> I think this is not a bug if the code relies on the fact that an empty
> string is a singleton. This obviously is an immutable object and there is
> no public method to create different empty string.


Really?

>>> x = u'\xe9'.encode('ascii', 'ignore')
>>> x == '', x is ''
(True, False)


-- 
Amaury Forgeot d'Arc
___
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 Language Summit at PyCon: Agenda

[Maciej Fijalkowski]

On Mon, Mar 4, 2013 at 8:41 PM, Antoine Pitrou  wrote:
> On Mon, 4 Mar 2013 11:51:04 -0500
> Barry Warsaw  wrote:
>> On Mar 04, 2013, at 11:34 AM, Brett Cannon wrote:
>>
>> >> And One True Way of invoking and/or discovering how to invoke, a package's
>> >> test suite.
>> >
>> >How does unittest's test discovery not solve that?
>>
>> I should have added "from the command line".  E.g. is it:
>>
>> $ python -m unittest discover
>> $ python setup.py test
>> $ python setup.py nosetests
>> $ python -m nose test
>> $ nosetests-X.Y
>>
>> Besides having a multitude of choices, there's almost no way to automatically
>> discover (e.g. by metadata inspection or some such) how to invoke the tests.
>> You're often lucky if there's a README.test and it's still accurate.
>
> I hope we can have a "pytest" utility that does the right thing in
> 3.4 :-)
> Typing "python -m unittest discover" is too cumbersome.
>
> Regards
>
> Antoine.

Please pick a different name though, pytest is already widely used.
___
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] Disabling string interning for null and single-char causes segfaults

[Guido van Rossum]

On Mon, Mar 4, 2013 at 11:06 AM, Amaury Forgeot d'Arc
 wrote:
>
>
> 2013/3/4 Serhiy Storchaka 
>>
>> On 01.03.13 17:24, Stefan Bucur wrote:
>>>
>>> Before digging deeper into the issue, I wanted to ask here if there are
>>> any implicit assumptions about string identity and interning throughout
>>> the interpreter implementation. For instance, are two single-char
>>> strings having the same content supposed to be identical objects?
>>
>>
>> I think this is not a bug if the code relies on the fact that an empty
>> string is a singleton. This obviously is an immutable object and there is no
>> public method to create different empty string.
>
>
> Really?
>
 x = u'\xe9'.encode('ascii', 'ignore')
 x == '', x is ''
> (True, False)

Code that relies on this is incorrect (the language doesn't guarantee
interning) but nevertheless given the intention of the implementation,
that behavior of encode() is also a bug.

-- 
--Guido van Rossum (python.org/~guido)
___
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 Language Summit at PyCon: Agenda

[Barry Warsaw]

On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:

>> $ python -m unittest discover
>> $ python setup.py test
>> $ python setup.py nosetests
>> $ python -m nose test
>> $ nosetests-X.Y
>> 
>> Besides having a multitude of choices, there's almost no way to
>> automatically discover (e.g. by metadata inspection or some such) how to
>> invoke the tests.  You're often lucky if there's a README.test and it's
>> still accurate.
>
>I hope we can have a "pytest" utility that does the right thing in 3.4 :-)
>Typing "python -m unittest discover" is too cumbersome.

Where is this work being done (e.g. is there a PEP)?

One thing to keep in mind is how to invoke this on a system with multiple
versions of Python available.  For example, in Debian, a decision was recently
made to drop all the nosetests-X.Y scripts from /usr/bin[1].

This makes sense when you think about having at least two major versions of
Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), *plus* debug
versions of each.  Add to that, we don't actually know at package build time
which versions of Python you might have installed on your system.

A suggestion was made to provide a main entry point so that `pythonX.Y -m
nose` would work, which makes sense to me and was adopted by the
nose-devs[2].

So while a top level `pytest` command may make sense, it also might not ;).
While PEP 426 has a way to declare test dependencies (a good thing), it seems
to have no way to declare how to actually run the tests.

Cheers,
-Barry

[1] Start of thread:
http://comments.gmane.org/gmane.linux.debian.devel.python/8572

[2] https://github.com/nose-devs/nose/issues/634
___
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] Disabling string interning for null and single-char causes segfaults

[Amaury Forgeot d'Arc]

2013/3/4 Guido van Rossum 

>  x = u'\xe9'.encode('ascii', 'ignore')
>  x == '', x is ''
> > (True, False)
>
> Code that relies on this is incorrect (the language doesn't guarantee
> interning) but nevertheless given the intention of the implementation,
> that behavior of encode() is also a bug.
>

The example above is obviously from python2.7; there is a similar example
with python3.2:
>>> x = b'\xe9\xe9'.decode('ascii', 'ignore')
>>> x == '', x is ''
(True, False)

...but this bug has been fixed in 3.3: PyUnicode_Resize() always returns
the unicode_empty singleton.

-- 
Amaury Forgeot d'Arc
___
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 Language Summit at PyCon: Agenda

[Berker Peksağ]

On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw  wrote:
> On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>
>>> $ python -m unittest discover
>>> $ python setup.py test
>>> $ python setup.py nosetests
>>> $ python -m nose test
>>> $ nosetests-X.Y
>>>
>>> Besides having a multitude of choices, there's almost no way to
>>> automatically discover (e.g. by metadata inspection or some such) how to
>>> invoke the tests.  You're often lucky if there's a README.test and it's
>>> still accurate.
>>
>>I hope we can have a "pytest" utility that does the right thing in 3.4 :-)
>>Typing "python -m unittest discover" is too cumbersome.
>
> Where is this work being done (e.g. is there a PEP)?

There is an open issue on the tracker: http://bugs.python.org/issue14266

--Berker
___
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] Introducing Electronic Contributor Agreements

[Ben Leslie]

On Tue, Mar 5, 2013 at 3:30 AM, Brian Curtin  wrote:

> The full announcement is at
> http://blog.python.org/2013/03/introducing-electronic-contributor.html,
> but a summary follows.
>
> We've now moved to an electronic Contributor License Agreement form at
> http://www.python.org/psf/contrib/contrib-form/ which will hopefully
> ease the signing and sending of forms for our potential contributors.
> The form shows the required fields whether you're signing as an
> individual or a representative of an organization, and removes the
> need to print, scan, fax, etc.
>
> When a new contributor fills in the form, they are emailed a copy of
> the form and asked to confirm the email address that they used (and
> received that copy at). Upon confirming, the signed form is sent to
> the PSF Administrator and filed away.
>
> The signature can either be generated from your typed name, or you can
> draw or upload your actual written signature if you choose.
>

I had been procrastinating on filling in the paper version, but having this
means no excuse.

The process was very simple and straight forward. (The only difficult part
was actually working out my python bugs username).

Thanks for taking the administrative effort to get this all in place.

Cheers,

Benno
___
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 Language Summit at PyCon: Agenda

[Robert Collins]

On 5 March 2013 05:34, Brett Cannon  wrote:
>
>
>
> On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw  wrote:
>>
>> On Mar 04, 2013, at 07:26 PM, Robert Collins wrote:
>>
>> >It is of course possible for subunit and related tools to run their
>> >own implementation, but it seems ideal to me to have a common API
>> >which regular unittest, nose, py.test and others can all agree on and
>> >use : better reuse for pretty printers, GUI displays and the like
>> >depend on some common API.
>>
>> And One True Way of invoking and/or discovering how to invoke, a package's
>> test suite.
>
>
> How does unittest's test discovery not solve that?

Three reasons
 a) There are some bugs (all filed I think) - I intend to hack on
these in the near future - that prevent discovery working at all for
some use cases.
 b) discovery requires magic parameters that are project specific
(e.g. is it 'discover .' or 'discover . lib' to run it). This is
arguably a setup.py/packaging entrypoint issue.
 c) Test suites written for e.g. Twisted, or nose, or other
non-stdunit-runner-compatible test runners will fail to execute even
when discovered correctly.

There are ways to solve this without addressing a/b/c - just defining
a standard command to run that signals success/failure with it's exit
code. Packages can export a particular flavour of that in their
setup.py if they have exceptional needs, and do nothing in the common
case. That doesn't solve 'how to introspect a package test suite' but
for distro packagers - and large scale CI integration - that doesn't
matter.

For instance testrepository offers a setuptools extension to let it be
used trivially, I believe nose does something similar.

Having something that would let *any* test suite spit out folk's
favourite test protocol de jour would be brilliant of course :).
[junit-xml, subunit, TAP, ...]

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services
___
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 Language Summit at PyCon: Agenda

[Daniel Holth]

On Mon, Mar 4, 2013 at 2:26 PM, Berker Peksağ  wrote:
> On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw  wrote:
>> On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>>
 $ python -m unittest discover
 $ python setup.py test
 $ python setup.py nosetests
 $ python -m nose test
 $ nosetests-X.Y

 Besides having a multitude of choices, there's almost no way to
 automatically discover (e.g. by metadata inspection or some such) how to
 invoke the tests.  You're often lucky if there's a README.test and it's
 still accurate.
>>>
>>>I hope we can have a "pytest" utility that does the right thing in 3.4 :-)
>>>Typing "python -m unittest discover" is too cumbersome.
>>
>> Where is this work being done (e.g. is there a PEP)?
>
> There is an open issue on the tracker: http://bugs.python.org/issue14266
>
> --Berker

setup.py's setup(test_suite="x")... not sure if this is a distutils or
setuptools feature. PEP 426 has an extension mechanism that could do
the job.
___
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 Language Summit at PyCon: Agenda

[Robert Collins]

On 5 March 2013 05:51, Barry Warsaw  wrote:
> I should have added "from the command line".  E.g. is it:
>
> $ python -m unittest discover
> $ python setup.py test
> $ python setup.py nosetests
> $ python -m nose test
> $ nosetests-X.Y

$ testr run

:)

> Besides having a multitude of choices, there's almost no way to automatically
> discover (e.g. by metadata inspection or some such) how to invoke the tests.
> You're often lucky if there's a README.test and it's still accurate.


If there is a .testr.conf you can run 'testr init; testr run'. Thats
the defined entry point for testr, and .testr.conf can specify running
make, or setup.py build or whatever else is needed to run tests.


I would love to see a declaritive interface so that you can tell that
is what you should run.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services
___
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 Language Summit at PyCon: Agenda

[Barry Warsaw]

On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote:

>setup.py's setup(test_suite="x")... not sure if this is a distutils or
>setuptools feature. PEP 426 has an extension mechanism that could do
>the job.

Shouldn't "testing" be a first order feature?

-Barry


signature.asc
Description: 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 Language Summit at PyCon: Agenda

[Daniel Holth]

On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw  wrote:
> On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote:
>
>>setup.py's setup(test_suite="x")... not sure if this is a distutils or
>>setuptools feature. PEP 426 has an extension mechanism that could do
>>the job.
>
> Shouldn't "testing" be a first order feature?

Unfortunately there are so many potential first-order features that
we've had to leave some out in order to save time. "How to run the
tests" is not something that you need to know when searching PyPI for
a distribution and its dependencies.
___
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 Language Summit at PyCon: Agenda

[Barry Warsaw]

On Mar 04, 2013, at 03:40 PM, Daniel Holth wrote:

>On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw  wrote:
>> On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote:
>>
>>>setup.py's setup(test_suite="x")... not sure if this is a distutils or
>>>setuptools feature. PEP 426 has an extension mechanism that could do
>>>the job.
>>
>> Shouldn't "testing" be a first order feature?
>
>Unfortunately there are so many potential first-order features that
>we've had to leave some out in order to save time. "How to run the
>tests" is not something that you need to know when searching PyPI for
>a distribution and its dependencies.

Although "has unittests that I can run" might be a deciding factor of which of
the many implementations of a particular feature you might choose.

-Barry


signature.asc
Description: 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] Introducing Electronic Contributor Agreements

[Terry Reedy]

On 3/4/2013 11:36 AM, Brett Cannon wrote:




On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin mailto:br...@python.org>> wrote:

The full announcement is at
http://blog.python.org/2013/03/introducing-electronic-contributor.html,
but a summary follows.

We've now moved to an electronic Contributor License Agreement form at
http://www.python.org/psf/contrib/contrib-form/ which will hopefully
ease the signing and sending of forms for our potential contributors.
The form shows the required fields whether you're signing as an
individual or a representative of an organization, and removes the
need to print, scan, fax, etc.

When a new contributor fills in the form, they are emailed a copy of
the form and asked to confirm the email address that they used (and
received that copy at). Upon confirming, the signed form is sent to
the PSF Administrator and filed away.

The signature can either be generated from your typed name, or you can
draw or upload your actual written signature if you choose.


With this in place I would like to propose that all patches submitted to
bugs.python.org  must come from someone who has
signed the CLA before we consider committing it (if you want to be truly
paranoid we could say that we won't even look at the code w/o a CLA).


Either policy could be facilitated by tracker changes. In order to see 
the file upload box, one must login and the tracker knows who has a CLA 
on file (as indicated by a * suffix on the name). If a file is uploaded 
by someone without, a box could popup with the link to the e-form and a 
message that a CLA is required.


--
Terry Jan Reedy

___
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] Disabling string interning for null and single-char causes segfaults

[Victor Stinner]

Hi,

2013/3/4 Amaury Forgeot d'Arc :
> The example above is obviously from python2.7; there is a similar example
> with python3.2:
 x = b'\xe9\xe9'.decode('ascii', 'ignore')
 x == '', x is ''
> (True, False)
>
> ...but this bug has been fixed in 3.3: PyUnicode_Resize() always returns the
> unicode_empty singleton.

Yeah, I tried to reuse singletons (empty string and latin-1 single
letters) as much as possible to reduce memory footprint, not to ensure
that an empty string is always the '' singleton.

I wouldn't call this a bug.

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] Introducing Electronic Contributor Agreements

[Antoine Pitrou]

On Mon, 04 Mar 2013 15:46:48 -0500
Terry Reedy  wrote:
> On 3/4/2013 11:36 AM, Brett Cannon wrote:
> >
> >
> >
> > On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin  > > wrote:
> >
> > The full announcement is at
> > http://blog.python.org/2013/03/introducing-electronic-contributor.html,
> > but a summary follows.
> >
> > We've now moved to an electronic Contributor License Agreement form at
> > http://www.python.org/psf/contrib/contrib-form/ which will hopefully
> > ease the signing and sending of forms for our potential contributors.
> > The form shows the required fields whether you're signing as an
> > individual or a representative of an organization, and removes the
> > need to print, scan, fax, etc.
> >
> > When a new contributor fills in the form, they are emailed a copy of
> > the form and asked to confirm the email address that they used (and
> > received that copy at). Upon confirming, the signed form is sent to
> > the PSF Administrator and filed away.
> >
> > The signature can either be generated from your typed name, or you can
> > draw or upload your actual written signature if you choose.
> >
> >
> > With this in place I would like to propose that all patches submitted to
> > bugs.python.org  must come from someone who has
> > signed the CLA before we consider committing it (if you want to be truly
> > paranoid we could say that we won't even look at the code w/o a CLA).
> 
> Either policy could be facilitated by tracker changes. In order to see 
> the file upload box, one must login and the tracker knows who has a CLA 
> on file (as indicated by a * suffix on the name). If a file is uploaded 
> by someone without, a box could popup with the link to the e-form and a 
> message that a CLA is required.

And how about people who upload something else than a patch?

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] Planning on removing cache invalidation for file finders

[PJ Eby]

On Sun, Mar 3, 2013 at 12:31 PM, Brett Cannon  wrote:
> But how about this as a compromise over introducing write_module():
> invalidate_caches() can take a path for something to specifically
> invalidate. The path can then be passed to the invalidate_caches() on
> sys.meta_path. In the case of PathFinder it would take that path, try to
> find the directory in sys.path_importer_cache, and then invalidate the most
> specific finder for that path (if there is one that has any directory prefix
> match).
>
> Lots of little details to specify (e.g. absolute path forced anywhere in
> case a relative path is passed in by sys.path is all absolute paths? How do
> we know something is a file if it has not been written yet?), but this would
> prevent importlib from subsuming file writing specifically for source files
> and minimize performance overhead of invalidating all caches for a single
> file.

ISTR that when we were first discussing caching, I'd proposed a
TTL-based workaround for the timestamp granularity problem, and it was
mooted because somebody already proposed and implemented a similar
idea.  But my approach -- or at least the one I have in mind now --
would provide an "eventual consistency" guarantee, while still
allowing fast startup times.

However I think the experience with this heuristic so far shows that
the real problem isn't that the heuristic doesn't work for the normal
case; it works fine for that.  Instead, what happens is that *it
doesn't work when you generate modules*.

And *that* problem can be fixed without even invalidating the caches:
it can be fixed by doing some extra work when writing a module - e.g.
by making sure the directory mtime changes again after the module is
written.

For example, create the module under a temporary name, verify that the
directory mtime is different than it was before, then keep renaming it
to different temporary names until the mtime changes again, then
rename it to the final name.  (This would be very fast on some
platforms, much slower on others, but the OS itself would tell you
when it had worked.)  A utility routine to "write_module()" or
"write_package()" would be easier to find than advice that says to
invalidate the cache under thus-and-such conditions, as it would show
up in searches for writing modules dynamically or creating modules
dynamically, where you could only search for info about the cache if
you knew the cache existed.
___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Eli Bendersky]

[Splitting into a separate thread]

Do we really need to overthink something that requires a trivial alias to
set up for one's own convenience?

Picking a Python version (as Barry mentions) is just one of the problems.
What's wrong with:

alias rupytests='python3 -m unittest discover"
alias runpytests2='python2 -m unittest discover"

?

Don't get me wrong, I love the "discover" option and agree that it should
be the recommended way to go - but isn't this largely a documentation issue?

Eli






On Mon, Mar 4, 2013 at 11:14 AM, Barry Warsaw  wrote:

> On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>
> >> $ python -m unittest discover
> >> $ python setup.py test
> >> $ python setup.py nosetests
> >> $ python -m nose test
> >> $ nosetests-X.Y
> >>
> >> Besides having a multitude of choices, there's almost no way to
> >> automatically discover (e.g. by metadata inspection or some such) how to
> >> invoke the tests.  You're often lucky if there's a README.test and it's
> >> still accurate.
> >
> >I hope we can have a "pytest" utility that does the right thing in 3.4 :-)
> >Typing "python -m unittest discover" is too cumbersome.
>
> Where is this work being done (e.g. is there a PEP)?
>
> One thing to keep in mind is how to invoke this on a system with multiple
> versions of Python available.  For example, in Debian, a decision was
> recently
> made to drop all the nosetests-X.Y scripts from /usr/bin[1].
>
> This makes sense when you think about having at least two major versions of
> Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), *plus*
> debug
> versions of each.  Add to that, we don't actually know at package build
> time
> which versions of Python you might have installed on your system.
>
> A suggestion was made to provide a main entry point so that `pythonX.Y -m
> nose` would work, which makes sense to me and was adopted by the
> nose-devs[2].
>
> So while a top level `pytest` command may make sense, it also might not ;).
> While PEP 426 has a way to declare test dependencies (a good thing), it
> seems
> to have no way to declare how to actually run the tests.
>
> Cheers,
> -Barry
>
> [1] Start of thread:
> http://comments.gmane.org/gmane.linux.debian.devel.python/8572
>
> [2] https://github.com/nose-devs/nose/issues/634
> ___
> 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/eliben%40gmail.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] Introducing Electronic Contributor Agreements

[Mark Lawrence]

On 04/03/2013 20:46, Terry Reedy wrote:

On 3/4/2013 11:36 AM, Brett Cannon wrote:




On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin mailto:br...@python.org>> wrote:

The full announcement is at

http://blog.python.org/2013/03/introducing-electronic-contributor.html,
but a summary follows.

We've now moved to an electronic Contributor License Agreement
form at
http://www.python.org/psf/contrib/contrib-form/ which will hopefully
ease the signing and sending of forms for our potential contributors.
The form shows the required fields whether you're signing as an
individual or a representative of an organization, and removes the
need to print, scan, fax, etc.

When a new contributor fills in the form, they are emailed a copy of
the form and asked to confirm the email address that they used (and
received that copy at). Upon confirming, the signed form is sent to
the PSF Administrator and filed away.

The signature can either be generated from your typed name, or you
can
draw or upload your actual written signature if you choose.


With this in place I would like to propose that all patches submitted to
bugs.python.org  must come from someone who has
signed the CLA before we consider committing it (if you want to be truly
paranoid we could say that we won't even look at the code w/o a CLA).


Either policy could be facilitated by tracker changes. In order to see
the file upload box, one must login and the tracker knows who has a CLA
on file (as indicated by a * suffix on the name). If a file is uploaded
by someone without, a box could popup with the link to the e-form and a
message that a CLA is required.



People already use the bug tracker as an excuse not to contribute, 
wouldn't this requirement make the situation worse?


--
Cheers.

Mark Lawrence

___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Antoine Pitrou]

On Mon, 4 Mar 2013 13:26:57 -0800
Eli Bendersky  wrote:
> [Splitting into a separate thread]
> 
> Do we really need to overthink something that requires a trivial alias to
> set up for one's own convenience?
> 
> Picking a Python version (as Barry mentions) is just one of the problems.
> What's wrong with:
> 
> alias rupytests='python3 -m unittest discover"
> alias runpytests2='python2 -m unittest discover"
> 
> ?
> 
> Don't get me wrong, I love the "discover" option and agree that it should
> be the recommended way to go - but isn't this largely a documentation issue?

I would personally call it a typing issue :-) "python -m unittest
discover" is just too long.

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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Robert Collins]

On 5 March 2013 10:26, Eli Bendersky  wrote:
> [Splitting into a separate thread]
>
> Do we really need to overthink something that requires a trivial alias to
> set up for one's own convenience?

The big thing is automated tools, not developers.

When distributors want to redistribute packages they want to be sure
they work. Running the tests is a pretty good signal for that, but
having every package slightly different adds to the work they need to
do. Being able to do 'setup.py test' consistently, everywhere - that
would be great.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services
___
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 Language Summit at PyCon: Agenda

[Brett Cannon]

On Mon, Mar 4, 2013 at 3:45 PM, Barry Warsaw  wrote:

> On Mar 04, 2013, at 03:40 PM, Daniel Holth wrote:
>
> >On Mon, Mar 4, 2013 at 3:14 PM, Barry Warsaw  wrote:
> >> On Mar 04, 2013, at 03:02 PM, Daniel Holth wrote:
> >>
> >>>setup.py's setup(test_suite="x")... not sure if this is a distutils or
> >>>setuptools feature. PEP 426 has an extension mechanism that could do
> >>>the job.
> >>
> >> Shouldn't "testing" be a first order feature?
> >
> >Unfortunately there are so many potential first-order features that
> >we've had to leave some out in order to save time. "How to run the
> >tests" is not something that you need to know when searching PyPI for
> >a distribution and its dependencies.
>
> Although "has unittests that I can run" might be a deciding factor of
> which of
> the many implementations of a particular feature you might choose.
>

Sure, but that has nothing to do with programmatic package discovery.
That's something you will have to do as a person in making a qualitative
decision along the same lines as API design. Flipping a bit in a config
file saying "I have tests" doesn't say much beyond you flipped a bit, e.g.
no idea on coverage, quality, etc.
___
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] Introducing Electronic Contributor Agreements

[Brett Cannon]

On Mon, Mar 4, 2013 at 4:33 PM, Mark Lawrence wrote:

> On 04/03/2013 20:46, Terry Reedy wrote:
>
>> On 3/4/2013 11:36 AM, Brett Cannon wrote:
>>
>>>
>>>
>>>
>>> On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin >> > wrote:
>>>
>>> The full announcement is at
>>>
>>> http://blog.python.org/2013/**03/introducing-electronic-**
>>> contributor.html
>>> ,
>>> but a summary follows.
>>>
>>> We've now moved to an electronic Contributor License Agreement
>>> form at
>>> 
>>> http://www.python.org/psf/**contrib/contrib-form/which
>>>  will hopefully
>>> ease the signing and sending of forms for our potential contributors.
>>> The form shows the required fields whether you're signing as an
>>> individual or a representative of an organization, and removes the
>>> need to print, scan, fax, etc.
>>>
>>> When a new contributor fills in the form, they are emailed a copy of
>>> the form and asked to confirm the email address that they used (and
>>> received that copy at). Upon confirming, the signed form is sent to
>>> the PSF Administrator and filed away.
>>>
>>> The signature can either be generated from your typed name, or you
>>> can
>>> draw or upload your actual written signature if you choose.
>>>
>>>
>>> With this in place I would like to propose that all patches submitted to
>>> bugs.python.org  must come from someone who has
>>> signed the CLA before we consider committing it (if you want to be truly
>>> paranoid we could say that we won't even look at the code w/o a CLA).
>>>
>>
>> Either policy could be facilitated by tracker changes. In order to see
>> the file upload box, one must login and the tracker knows who has a CLA
>> on file (as indicated by a * suffix on the name). If a file is uploaded
>> by someone without, a box could popup with the link to the e-form and a
>> message that a CLA is required.
>>
>>
> People already use the bug tracker as an excuse not to contribute,
> wouldn't this requirement make the situation worse?


Depends on your paranoia. If you're worried about accidentally lifting IP
merely by reading someone's source code, then you wouldn't want to touch
code without the CLA signed.

Now I'm not that paranoid, but I'm still not about to commit someone's code
now without the CLA signed to make sure we are legally covered for the
patch. If someone chooses not to contribute because of the CLA that's fine,
but since we have already told at least Anatoly that we won't accept
patches from him until he signs the CLA I'm not going to start acting
differently towards others. I view legally covering our ass by having
someone fill in a form is worth the potential loss of some contribution in
the grand scheme of things.
___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Barry Warsaw]

On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:

>The big thing is automated tools, not developers.

Exactly.

-Barry
___
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 Language Summit at PyCon: Agenda

[Barry Warsaw]

On Mar 04, 2013, at 05:04 PM, Brett Cannon wrote:

>Sure, but that has nothing to do with programmatic package discovery.
>That's something you will have to do as a person in making a qualitative
>decision along the same lines as API design. Flipping a bit in a config
>file saying "I have tests" doesn't say much beyond you flipped a bit, e.g.
>no idea on coverage, quality, etc.

What I'm looking for is something that automated tools can use to easily
discover how to run a package's tests.  I want it to be dead simple for
developers of a package to declare how their tests are to be run, and what
extra dependencies they might need.  It seems like PEP 426 only addresses the
latter.  Maybe that's fine and a different PEP is needed to describe automated
test discover, but I still think it's an important use case.

Imagine:

 * Every time you upload a package to PyPI, snakebite runs your test suite on
   a variety of Python versions and platforms.  You get a nice link to the
   Jenkins results so you and your users get a good sense of overall package
   quality.

 * You have an automated gatekeeper that will prevent commits or uploads if
   your coverage or test results get worse instead of better.

 * Distro packagers can build tools that auto-discover the tests so that they
   are run automatically when the package is built, ensuring high quality
   packages specifically targeted to those distros.

As a community, we know how important tests are, so I think our tools should
reflect that and make it easy for those tests to be expressed.  As a selfish
side-effect, I want to reduce the amount of guesswork I need to perform in
order to know how to run a package's test when I `$vcs clone` their
repository. ;)

Cheers,
-Barry


signature.asc
Description: 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] Introducing Electronic Contributor Agreements

[Terry Reedy]

On 3/4/2013 3:46 PM, Antoine Pitrou wrote:

On Mon, 04 Mar 2013 15:46:48 -0500
Terry Reedy  wrote:

On 3/4/2013 11:36 AM, Brett Cannon wrote:



With this in place I would like to propose that all patches submitted to
bugs.python.org  must come from someone who has
signed the CLA before we consider committing it (if you want to be truly
paranoid we could say that we won't even look at the code w/o a CLA).


While I regard CLAs as partly being a form of legal theater, I regard 
our participation as necessary, both to make explicit to contributors 
what should be implicit in the act of submission *and* to show to 
copyright holders a good-faith effort to not improperly incorporate 
their code.


Note: no one expected the Linux copyright challenge, nor our European 
trademark challenge, but they happened. I expect there will be more 
challenges to open source projects, perhaps some legitimate as the 
number of contributors increases.



Either policy could be facilitated by tracker changes. In order to see
the file upload box, one must login and the tracker knows who has a CLA
on file (as indicated by a * suffix on the name). If a file is uploaded
by someone without, a box could popup with the link to the e-form and a
message that a CLA is required.


And how about people who upload something else than a patch?


Limit the popup to files with .diff or .patch extension. Reviewers can 
check for '*' for the occasionally patch lacking that.


--
Terry Jan Reedy

___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Eli Bendersky]

On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou  wrote:

> On Mon, 4 Mar 2013 13:26:57 -0800
> Eli Bendersky  wrote:
> > [Splitting into a separate thread]
> >
> > Do we really need to overthink something that requires a trivial alias to
> > set up for one's own convenience?
> >
> > Picking a Python version (as Barry mentions) is just one of the problems.
> > What's wrong with:
> >
> > alias rupytests='python3 -m unittest discover"
> > alias runpytests2='python2 -m unittest discover"
> >
> > ?
> >
> > Don't get me wrong, I love the "discover" option and agree that it should
> > be the recommended way to go - but isn't this largely a documentation
> issue?
>
> I would personally call it a typing issue :-) "python -m unittest
> discover" is just too long.
>

Command-line options for advanced capabilities can get long, yes. It's not
a reason to add an extra layer, which is extra complexity, IMHO. The user
is free to create his own shortcuts if this is too much typing. Moreover,
many projects already have a way to run "all tests" from their root
directory.

As a case in point, we also have the useful:

$ python -m SimpleHTTPServer

So why not create a new "pyserve" command to reduce the amount of typing?

Eli
___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Eli Bendersky]

On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw  wrote:

> On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:
>
> >The big thing is automated tools, not developers.
>
> Exactly.
>

I don't understand. Is "python -m unittest discover" too much typing for
automatic tools? If anything, it's much more portable across Python
versions since any new coommand/script won't be added before 3.4, while the
longer version works in 2.7 and 3.2+

Eli
___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Robert Collins]

On 5 March 2013 12:49, Eli Bendersky  wrote:
>
> On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw  wrote:
>>
>> On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:
>>
>> >The big thing is automated tools, not developers.
>>
>> Exactly.
>
> I don't understand. Is "python -m unittest discover" too much typing for
> automatic tools? If anything, it's much more portable across Python versions
> since any new coommand/script won't be added before 3.4, while the longer
> version works in 2.7 and 3.2+

It isn't about length. It is about knowing that *that* is what to type
(and btw that exact command cannot run twisted's tests, among many
other projects tests).

Perhaps we are talking about different things. A top level script to
run tests is interesting, but orthogonal to the thing Barry was asking
for.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services
___
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 Language Summit at PyCon: Agenda

[Michael Foord]

On 3 Mar 2013, at 01:29, Trent Nelson  wrote:

> On Wed, Feb 27, 2013 at 08:51:16AM -0800, Michael Foord wrote:
>> If you have other items you'd like to discuss please let me know and I
>> can add them to the agenda.
> 
>Hmm, seems like this might be a good forum to introduce the
>parallel/async stuff I've been working on the past few months.
>TL;DR version is I've come up with an alternative approach for
>exploiting multiple cores that doesn't rely on GIL-removal or
>STM (and has a negligible performance overhead when executing
>single-threaded code).  (For those that are curious, it lives
>in the px branch of the sandbox/trent repo on hg.p.o, albeit
>in a very experimental/prototype/proof-of-concept state (i.e.
>it's an unorganized, undocumented, uncommented hackfest); on
>the plus side, it works.  Sort of.)
> 
>Second suggestion: perhaps a little segment on Snakebite?  What
>it is, what's available to committers, feedback/kvetching from
>those who have already used it, etc.
> 

I've added both to the agenda.

>(I forgot the format of these summits -- is there a projector?)
> 

I've asked for a projector, yes.

Michael

>Trent.


--
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 Language Summit at PyCon: Agenda

[Terry Reedy]

On 3/4/2013 5:24 PM, Barry Warsaw wrote:


What I'm looking for is something that automated tools can use to easily
discover how to run a package's tests.  I want it to be dead simple for
developers of a package to declare how their tests are to be run, and what


I am writing a package that has tests for each module (which I so far 
run individually for each module) using a custom test framework. I am 
planning to add a function to the package to run all of them. Should I 
call it 'testall', 'test_all', 'runtests', or something else? I really 
do not care. It would be used like this.

  import xxx; xxx.testall()
Of course, this would not work with the stdlib since /lib is not a 
package that can be imported. I could put the same code in the top level 
of a module, to be run when imported (but that would not work with 
re-imports), or put the function in my test module. I am willing to 
adjust to a standard when there is one.


What I do suggest is that package developers should only have to provide 
one standard entry point that hides all package-specific details. I 
presume the side-effect spec would be error messages to sdterr. Any 
return requirements should be a simple as possible, as in all pass 
True/False, or (number run, number fail) by whatever counting method the 
package/test framework uses. (Note: my framework does not count tests, 
as I only care about failure messages, but testall could count modules 
tested and those with a failure.)



extra dependencies they might need.  It seems like PEP 426 only addresses the
latter.  Maybe that's fine and a different PEP is needed to describe automated
test discover, but I still think it's an important use case.


New PEP.

--
Terry Jan Reedy

___
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 Language Summit at PyCon: Agenda

[Nick Coghlan]

On 5 Mar 2013 05:21, "Barry Warsaw"  wrote:
>
> On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>
> >> $ python -m unittest discover
> >> $ python setup.py test
> >> $ python setup.py nosetests
> >> $ python -m nose test
> >> $ nosetests-X.Y
> >>
> >> Besides having a multitude of choices, there's almost no way to
> >> automatically discover (e.g. by metadata inspection or some such) how
to
> >> invoke the tests.  You're often lucky if there's a README.test and it's
> >> still accurate.
> >
> >I hope we can have a "pytest" utility that does the right thing in 3.4
:-)
> >Typing "python -m unittest discover" is too cumbersome.
>
> Where is this work being done (e.g. is there a PEP)?
>
> One thing to keep in mind is how to invoke this on a system with multiple
> versions of Python available.  For example, in Debian, a decision was
recently
> made to drop all the nosetests-X.Y scripts from /usr/bin[1].
>
> This makes sense when you think about having at least two major versions
of
> Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), *plus*
debug
> versions of each.  Add to that, we don't actually know at package build
time
> which versions of Python you might have installed on your system.
>
> A suggestion was made to provide a main entry point so that `pythonX.Y -m
> nose` would work, which makes sense to me and was adopted by the
> nose-devs[2].
>
> So while a top level `pytest` command may make sense, it also might not
;).
> While PEP 426 has a way to declare test dependencies (a good thing), it
seems
> to have no way to declare how to actually run the tests.

Metadata 2.0 won't cover that, 2.1 probably will. Please give us time to
solve problems incrementally rather than trying to fix everything at once.

Regards,
Nick.

>
> Cheers,
> -Barry
>
> [1] Start of thread:
> http://comments.gmane.org/gmane.linux.debian.devel.python/8572
>
> [2] https://github.com/nose-devs/nose/issues/634
> ___
> 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/ncoghlan%40gmail.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] Python Language Summit at PyCon: Agenda

[Michael Foord]

On 4 Mar 2013, at 06:26, Robert Collins  wrote:

> On 4 March 2013 18:54, Guido van Rossum  wrote:
>> On Sun, Mar 3, 2013 at 9:24 PM, Robert Collins
>>  wrote:
>>> I'd like to talk about overhauling - not tweaking, overhauling - the
>>> standard library testing facilities.
>> 
>> That seems like too big a topic and too vague a description to discuss
>> usefully. Perhaps you have a specific proposal? Or at least just a use
>> case that's poorly covered?
> 
> I have both - I have a draft implementation for a new test result API
> (and forwards and backwards compat code etc), and use cases that drive
> it. I started a thread here -
> http://lists.idyll.org/pipermail/testing-in-python/2013-February/005434.html
> , with blog posts
> https://rbtcollins.wordpress.com/2013/02/14/time-to-revise-the-subunit-protocol/
> https://rbtcollins.wordpress.com/2013/02/15/more-subunit-needs/
> https://rbtcollins.wordpress.com/2013/02/19/first-experience-implementing-streamresult/
> https://rbtcollins.wordpress.com/2013/02/23/simpler-is-better/
> 
> They are focused on subunit, but much of subunit's friction has been
> due to issues encountered from the stdlibrary TestResult API - in
> particular three things:
> - the single-active-test model that the current API (or at least
> implementation) has.
> - the expectation that all test outcomes will originate from the same
> interpreter (or something with a live traceback object)
> - the inability to supply details about errors other than the exception
> 
> All of which start to bite rather deep when working on massively
> parallel test environments.
> 
> It is of course possible for subunit and related tools to run their
> own implementation, but it seems ideal to me to have a common API
> which regular unittest, nose, py.test and others can all agree on and
> use : better reuse for pretty printers, GUI displays and the like
> depend on some common API.
> 
>> TBH, your choice of words is ambiguous -- are you interested in
>> overhauling the facilities for testing *of* the standard library (i.e.
>> the 'test' package), or the testing facilities *provided by* the
>> standard library (i.e. the unittest module)?
> 
> Sorry! Testing facilities provided by the standard library. They
> should naturally facilitate testing of the standard library too.


We can certainly talk about it - although as Guido says, something specific may 
be easier to have a useful discussion about.

Reading through your blog articles it seemed like a whole lot of subunit 
context was required to understand the specific proposal you're making for the 
TestResult. It also *seems* like you're redesigning the TestResult for a single 
use case (distributed testing) with an api that looks quite "odd" for anything 
that isn't that use case. I'd rather see how we can make the TestResult play 
*better* with those requirements. That discussion probably belongs in another 
thread - or at the summit.

Michael

> 
> -Rob
> 
>> --
>> --Guido van Rossum (python.org/~guido)
> 
> 
> 
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Cloud Services
> ___
> 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 Language Summit at PyCon: Agenda

[Michael Foord]

On 4 Mar 2013, at 19:26, Berker Peksağ  wrote:

> On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw  wrote:
>> On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>> 
 $ python -m unittest discover
 $ python setup.py test
 $ python setup.py nosetests
 $ python -m nose test
 $ nosetests-X.Y
 
 Besides having a multitude of choices, there's almost no way to
 automatically discover (e.g. by metadata inspection or some such) how to
 invoke the tests.  You're often lucky if there's a README.test and it's
 still accurate.
>>> 
>>> I hope we can have a "pytest" utility that does the right thing in 3.4 :-)
>>> Typing "python -m unittest discover" is too cumbersome.
>> 
>> Where is this work being done (e.g. is there a PEP)?
> 
> There is an open issue on the tracker: http://bugs.python.org/issue14266
> 


Indeed, and unittest2 (the backport) which has to work with Python 2.6 (where 
"python -m package_name" doesn't work) has "unit2" as a shortcut. So it has an 
advantage over the standard library version here.

I'd like to see pyunit as a short-cut for "python -m unittest discover", with a 
"pyunit-3.x" variant too. 

Barry objects that Linux distributions won't want to support all of these, 
which is frankly their problem.

Michael

> --Berker
> ___
> 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 Language Summit at PyCon: Agenda

[Robert Collins]

On 5 March 2013 13:21, Michael Foord  wrote:
>

> We can certainly talk about it - although as Guido says, something specific 
> may be easier to have a useful discussion about.
>
> Reading through your blog articles it seemed like a whole lot of subunit 
> context was required to understand the specific
> proposal you're making for the TestResult. It also *seems* like you're 
> redesigning the TestResult for a single use case
> (distributed testing) with an api that looks quite "odd" for anything that 
> isn't that use case. I'd rather see how we can
> make the TestResult play *better* with those requirements. That discussion 
> probably belongs in another thread - or at
> the summit.

Right - all I wanted was to flag that you and I and any other
interested parties should discuss this at the summit :).

-Rob






-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services
___
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 Language Summit at PyCon: Agenda

[Michael Foord]

On 28 Feb 2013, at 13:49, Brett Cannon  wrote:

> 
> 
> 
> On Thu, Feb 28, 2013 at 6:34 AM, Michael Foord  
> wrote:
> 
> On 28 Feb 2013, at 07:36, Georg Brandl  wrote:
> 
> > Am 27.02.2013 17:51, schrieb Michael Foord:
> >> Hello all,
> >>
> >> PyCon, and the Python Language Summit, is nearly upon us. We have a good 
> >> number of people confirmed to attend. If you are intending to come to the 
> >> language summit but haven't let me know please do so.
> >>
> >> The agenda of topics for discussion so far includes the following:
> >>
> >> * A report on pypy status - Maciej and Armin
> >> * Jython and IronPython status reports - Dino / Frank
> >> * Packaging (Doug Hellmann and Monty Taylor at least)
> >> * Cleaning up interpreter initialisation (both in hopes of finding areas
> >>  to rationalise and hence speed things up, as well as making things
> >>  more embedding friendly). Nick Coghlan
> >> * Adding new async capabilities to the standard library (Guido)
> >> * cffi and the standard library - Maciej
> >> * flufl.enum and the standard library - Barry Warsaw
> >> * The argument clinic - Larry Hastings
> >>
> >> If you have other items you'd like to discuss please let me know and I can 
> >> add them to the agenda.
> >
> > May I in absentia propose at least a short discussion of the XML fixes
> > and accompanying security releases?  FWIW, for 3.2 and 3.3 I have no
> > objections to secure-by-default.
> >
> 
> Sure. It would be good if someone who *will* be there can champion the 
> discussion.
> 
> While Christian is in the best position to discuss this, I did review his 
> various monkeypatch fixes + expat patches so I can attempt to answer any 
> questions people may have.

I've put you next to the topic in the agenda Brett :-)

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] Python Language Summit at PyCon: Agenda

[Michael Foord]

On 4 Mar 2013, at 20:02, Daniel Holth  wrote:

> On Mon, Mar 4, 2013 at 2:26 PM, Berker Peksağ  wrote:
>> On Mon, Mar 4, 2013 at 9:14 PM, Barry Warsaw  wrote:
>>> On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:
>>> 
> $ python -m unittest discover
> $ python setup.py test
> $ python setup.py nosetests
> $ python -m nose test
> $ nosetests-X.Y
> 
> Besides having a multitude of choices, there's almost no way to
> automatically discover (e.g. by metadata inspection or some such) how to
> invoke the tests.  You're often lucky if there's a README.test and it's
> still accurate.
 
 I hope we can have a "pytest" utility that does the right thing in 3.4 :-)
 Typing "python -m unittest discover" is too cumbersome.
>>> 
>>> Where is this work being done (e.g. is there a PEP)?
>> 
>> There is an open issue on the tracker: http://bugs.python.org/issue14266
>> 
>> --Berker
> 
> setup.py's setup(test_suite="x")... not sure if this is a distutils or
> setuptools feature. PEP 426 has an extension mechanism that could do
> the job.


This is a setuptools extension. There was some discussion for 
packaging/distutils2 of having test support but I have no idea if that has been 
picked up for the new bunch of packaging related work.

Michael

> ___
> 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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Eli Bendersky]

On Mon, Mar 4, 2013 at 4:09 PM, Robert Collins wrote:

> On 5 March 2013 12:49, Eli Bendersky  wrote:
> >
> > On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw  wrote:
> >>
> >> On Mar 05, 2013, at 11:01 AM, Robert Collins wrote:
> >>
> >> >The big thing is automated tools, not developers.
> >>
> >> Exactly.
> >
> > I don't understand. Is "python -m unittest discover" too much typing for
> > automatic tools? If anything, it's much more portable across Python
> versions
> > since any new coommand/script won't be added before 3.4, while the longer
> > version works in 2.7 and 3.2+
>
> It isn't about length. It is about knowing that *that* is what to type
> (and btw that exact command cannot run twisted's tests, among many
> other projects tests).
>
> Perhaps we are talking about different things. A top level script to
> run tests is interesting, but orthogonal to the thing Barry was asking
> for.
>

Perhaps :-)
I'm specifically referring to a new top-level script that will run all
unittests in discovery mode from the current directory, as a shortcut to
"python -m unittest discover". ISTM this is at leas in part what was
discussed, and my email was in this context.

Eli
___
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 Language Summit at PyCon: Agenda

[Michael Foord]

On 1 Mar 2013, at 18:38, Antoine Pitrou  wrote:

> On Fri, 1 Mar 2013 09:32:23 -0500
> Barry Warsaw  wrote:
>> 
>>> On the other hand in some ways Jython is sort of like Python on a
>>> weird virtual OS that lets the real OS bleed through some. This may
>>> still need to be checked in that way (there's are still checks of >> os.name == 'nt'> right?)
>> 
>> Yeah, but that all old code ;)
> 
> Hmm, what do you mean? `os.name == 'nt'` is still the proper way to
> test that we're running on a Windows system (more accurately, over the
> Windows API).
> 

It has been used incorrectly in a few places in the Python standard library - 
Windows support code that would work correctly on IronPython is skipped because 
os.name is *not* 'nt' on IronPython.  That was the case in the past anyway. 
It's quite some time since I've used IronPython now.

Michael

> 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/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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Robert Collins]

On 5 March 2013 13:35, Eli Bendersky  wrote:

> Perhaps :-)
> I'm specifically referring to a new top-level script that will run all
> unittests in discovery mode from the current directory, as a shortcut to
> "python -m unittest discover". ISTM this is at leas in part what was
> discussed, and my email was in this context.

So that is interesting, but its not sufficient to meet the automation
need Barry is calling out, unless all test suites can be run by
'python -m unittest discover' with no additional parameters [and a
pretty large subset cannot].

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services
___
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] Introducing Electronic Contributor Agreements

[Mark Lawrence]

On 04/03/2013 22:08, Brett Cannon wrote:




On Mon, Mar 4, 2013 at 4:33 PM, Mark Lawrence mailto:breamore...@yahoo.co.uk>> wrote:

On 04/03/2013 20:46, Terry Reedy wrote:

On 3/4/2013 11:36 AM, Brett Cannon wrote:




On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin
mailto:br...@python.org>
>> wrote:

 The full announcement is at


http://blog.python.org/2013/__03/introducing-electronic-__contributor.html

,
 but a summary follows.

 We've now moved to an electronic Contributor License
Agreement
form at
http://www.python.org/psf/__contrib/contrib-form/
 which will
hopefully
 ease the signing and sending of forms for our potential
contributors.
 The form shows the required fields whether you're
signing as an
 individual or a representative of an organization, and
removes the
 need to print, scan, fax, etc.

 When a new contributor fills in the form, they are
emailed a copy of
 the form and asked to confirm the email address that
they used (and
 received that copy at). Upon confirming, the signed
form is sent to
 the PSF Administrator and filed away.

 The signature can either be generated from your typed
name, or you
can
 draw or upload your actual written signature if you choose.


With this in place I would like to propose that all patches
submitted to
bugs.python.org 
 must come from someone who has
signed the CLA before we consider committing it (if you want
to be truly
paranoid we could say that we won't even look at the code
w/o a CLA).


Either policy could be facilitated by tracker changes. In order
to see
the file upload box, one must login and the tracker knows who
has a CLA
on file (as indicated by a * suffix on the name). If a file is
uploaded
by someone without, a box could popup with the link to the
e-form and a
message that a CLA is required.


People already use the bug tracker as an excuse not to contribute,
wouldn't this requirement make the situation worse?


Depends on your paranoia. If you're worried about accidentally lifting
IP merely by reading someone's source code, then you wouldn't want to
touch code without the CLA signed.

Now I'm not that paranoid, but I'm still not about to commit someone's
code now without the CLA signed to make sure we are legally covered for
the patch. If someone chooses not to contribute because of the CLA
that's fine, but since we have already told at least Anatoly that we
won't accept patches from him until he signs the CLA I'm not going to
start acting differently towards others. I view legally covering our ass
by having someone fill in a form is worth the potential loss of some
contribution in the grand scheme of things.




Who's talking source code, you're previously mentioned *ALL* patches 
needing a CLA.  Does this mean you have to sign a CLA for a one line 
documentation patch?  What is the definition of a patch, an actual patch 
file or a proposal for a change that is given within a bug tracker message?


--
Cheers.

Mark Lawrence

___
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 Language Summit at PyCon: Agenda

[Michael Foord]

On 5 Mar 2013, at 00:23, Robert Collins  wrote:

> On 5 March 2013 13:21, Michael Foord  wrote:
>> 
> 
>> We can certainly talk about it - although as Guido says, something specific 
>> may be easier to have a useful discussion about.
>> 
>> Reading through your blog articles it seemed like a whole lot of subunit 
>> context was required to understand the specific
>> proposal you're making for the TestResult. It also *seems* like you're 
>> redesigning the TestResult for a single use case
>> (distributed testing) with an api that looks quite "odd" for anything that 
>> isn't that use case. I'd rather see how we can
>> make the TestResult play *better* with those requirements. That discussion 
>> probably belongs in another thread - or at
>> the summit.
> 
> Right - all I wanted was to flag that you and I and any other
> interested parties should discuss this at the summit :).

I've added a testing topic to the agenda. At the very least you could outline 
your streaming test result proposal, or kick off a meta discussion. We'll 
probably time limit the discussion so some specific focus will make it more 
productive - or maybe you can get a feel for how open to major changes in this 
area other python devs are.

Michael

> 
> -Rob
> 
> 
> 
> 
> 
> 
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Cloud Services


--
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 Language Summit at PyCon: Agenda

[Robert Collins]

On 5 March 2013 13:50, Michael Foord  wrote:

>> Right - all I wanted was to flag that you and I and any other
>> interested parties should discuss this at the summit :).
>
> I've added a testing topic to the agenda. At the very least you could outline 
> your streaming test result proposal, or kick off a meta discussion. We'll 
> probably time limit the discussion so some specific focus will make it more 
> productive - or maybe you can get a feel for how open to major changes in 
> this area other python devs are.


Cool. I can step through the core use cases and differences to what
TestResult is in pretty short order. We can spider out from there as
folk desire.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services
___
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 Language Summit at PyCon: Agenda

[Michael Foord]

On 4 Mar 2013, at 22:24, Barry Warsaw  wrote:

> On Mar 04, 2013, at 05:04 PM, Brett Cannon wrote:
> 
>> Sure, but that has nothing to do with programmatic package discovery.
>> That's something you will have to do as a person in making a qualitative
>> decision along the same lines as API design. Flipping a bit in a config
>> file saying "I have tests" doesn't say much beyond you flipped a bit, e.g.
>> no idea on coverage, quality, etc.
> 
> What I'm looking for is something that automated tools can use to easily
> discover how to run a package's tests.  I want it to be dead simple for
> developers of a package to declare how their tests are to be run, and what
> extra dependencies they might need.  It seems like PEP 426 only addresses the
> latter.  Maybe that's fine and a different PEP is needed to describe automated
> test discover, but I still think it's an important use case.
> 
> Imagine:
> 
> * Every time you upload a package to PyPI, snakebite runs your test suite on
>   a variety of Python versions and platforms.  You get a nice link to the
>   Jenkins results so you and your users get a good sense of overall package
>   quality.
> 
> * You have an automated gatekeeper that will prevent commits or uploads if
>   your coverage or test results get worse instead of better.
> 
> * Distro packagers can build tools that auto-discover the tests so that they
>   are run automatically when the package is built, ensuring high quality
>   packages specifically targeted to those distros.
> 
> As a community, we know how important tests are, so I think our tools should
> reflect that and make it easy for those tests to be expressed.  As a selfish
> side-effect, I want to reduce the amount of guesswork I need to perform in
> order to know how to run a package's test when I `$vcs clone` their
> repository. ;)
> 


Distutils2 had a way of specifying this in the metadata. It looks like this 
hasn't made it into the reboot:

 http://alexis.notmyidea.org/distutils2/distutils/newcommands.html

Michael 

> Cheers,
> -Barry
> ___
> 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 Language Summit at PyCon: Agenda

[Michael Foord]

On 4 Mar 2013, at 20:00, Robert Collins  wrote:

> On 5 March 2013 05:34, Brett Cannon  wrote:
>> 
>> 
>> 
>> On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw  wrote:
>>> 
>>> On Mar 04, 2013, at 07:26 PM, Robert Collins wrote:
>>> 
 It is of course possible for subunit and related tools to run their
 own implementation, but it seems ideal to me to have a common API
 which regular unittest, nose, py.test and others can all agree on and
 use : better reuse for pretty printers, GUI displays and the like
 depend on some common API.
>>> 
>>> And One True Way of invoking and/or discovering how to invoke, a package's
>>> test suite.
>> 
>> 
>> How does unittest's test discovery not solve that?
> 
> Three reasons
> a) There are some bugs (all filed I think) - I intend to hack on
> these in the near future - that prevent discovery working at all for
> some use cases.


The only discovery related issues I'm aware of are:

* Issue 16079 (filed by you) - trivial to fix just needs a test
* Issue 15010 obscure and unlikely to be an issue for standard discovery

I'm not aware of any other discovery related issues. Please let me know (or add 
me as nosy) to them.

> b) discovery requires magic parameters that are project specific
> (e.g. is it 'discover .' or 'discover . lib' to run it). This is
> arguably a setup.py/packaging entrypoint issue.


This was addressed by Barry - and yes discovery has to be done with the right 
parameters. If you layout your project in a particular way then "python -m 
unittest discover" in the project root will just work. This is project specific 
metadata though and not a particular problem of any testing library.

> c) Test suites written for e.g. Twisted, or nose, or other
> non-stdunit-runner-compatible test runners will fail to execute even
> when discovered correctly.
> 
> There are ways to solve this without addressing a/b/c - just defining
> a standard command to run that signals success/failure with it's exit
> code. Packages can export a particular flavour of that in their
> setup.py if they have exceptional needs, and do nothing in the common
> case. That doesn't solve 'how to introspect a package test suite' but
> for distro packagers - and large scale CI integration - that doesn't
> matter.
> 
> For instance testrepository offers a setuptools extension to let it be
> used trivially, I believe nose does something similar.
> 

unittest2 also has setuptools compatible test command.

> Having something that would let *any* test suite spit out folk's
> favourite test protocol de jour would be brilliant of course :).
> [junit-xml, subunit, TAP, ...]
> 

Yes.

Michael

> -Rob
> 
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Cloud Services
> ___
> 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] running tests; mebs

[Daniel Holth]

>> As a community, we know how important tests are, so I think our tools should
>> reflect that and make it easy for those tests to be expressed.  As a selfish
>> side-effect, I want to reduce the amount of guesswork I need to perform in
>> order to know how to run a package's test when I `$vcs clone` their
>> repository. ;)
>>
>
>
> Distutils2 had a way of specifying this in the metadata. It looks like this 
> hasn't made it into the reboot:
>
>  http://alexis.notmyidea.org/distutils2/distutils/newcommands.html
>
> Michael
>
>> Cheers,
>> -Barry

I'm not aware of a reboot of the setup.py replacement / improvement
effort. The work that has been done has proceeded backwards from the
installer end of things.

I had a proposal called "mebs, not an actual project". A completely
plugin-based system would recognize any sdist format and provide a
minimal, consistent interface. Add tests to the below text from
October.

...

A very simple meta-build system "mebs" is used to recognize sdists and
build binary packages. Build systems provide plugins having three
methods,

.recognize()
.metadata()
.build()

An installer downloads an sdist. For each installed build plugin,
.recognize(dir) is called. The first plugin to return True is used.
___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Barry Warsaw]

On Mar 05, 2013, at 01:09 PM, Robert Collins wrote:

>It isn't about length. It is about knowing that *that* is what to type
>(and btw that exact command cannot run twisted's tests, among many
>other projects tests).

>Perhaps we are talking about different things. A top level script to
>run tests is interesting, but orthogonal to the thing Barry was asking
>for.

Right, two different things.

-Barry
___
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] Introducing Electronic Contributor Agreements

[Stephen J. Turnbull]

Mark Lawrence writes:

 > People already use the bug tracker as an excuse not to contribute, 
 > wouldn't this requirement make the situation worse?

A failure to sign the CLA is already a decision not to contribute to
the distribution, no matter how noisy they are on the tracker and
list.  I think that pretty much any upload is potential content for
inclusion in Python.  For example, uploading a log of an interactive
session reproducing a bug could easily evolve into contribution of a
doctest.

Since the proposed page only triggers on uploads, I think we're in
"yes, we really do want this person's CLA" territory.  The procedure
is actually rather cool.  As Eli says, the tough part is finding your
user name, but OpenID or browser memory makes that reasonably close to
trivial for many people.

It's true that people upload "one-line documentation patches," and
these don't require a CLA under even the most paranoid interpretation
of US law.  The FSF's guideline is 16 lines, I believe.  However, the
FSF's guideline also says those 16 lines are lifetime cumulative (per
copyrighted work, but we're only talking about one, Python).  In my
experience (with a different project, so FWIW) somebody who goes to
the trouble of uploading a doc typo patch is likely to be a repeat
offender, whereas "drive-by" contributors who just need that one
feature so their web2.0 app works as desired are often going to be in
16-line territory anyway.

This argument doesn't catch 100% of those who might be deterred by the
popup, but it's definitely enough to make the popup worthwhile.

IANAL-but-I-like-a-good-license-flamewar-as-much-as-the-next-guy-ly y'rs,
___
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 Language Summit at PyCon: Agenda

[Jeff Hardy]

On Mon, Mar 4, 2013 at 4:39 PM, Michael Foord  wrote:
>
> On 1 Mar 2013, at 18:38, Antoine Pitrou  wrote:
>
>> On Fri, 1 Mar 2013 09:32:23 -0500
>> Barry Warsaw  wrote:
>>>
 On the other hand in some ways Jython is sort of like Python on a
 weird virtual OS that lets the real OS bleed through some. This may
 still need to be checked in that way (there's are still checks of >>> os.name == 'nt'> right?)
>>>
>>> Yeah, but that all old code ;)
>>
>> Hmm, what do you mean? `os.name == 'nt'` is still the proper way to
>> test that we're running on a Windows system (more accurately, over the
>> Windows API).
>>
>
> It has been used incorrectly in a few places in the Python standard library - 
> Windows support code that would work correctly on IronPython is skipped 
> because os.name is *not* 'nt' on IronPython.  That was the case in the past 
> anyway. It's quite some time since I've used IronPython now.

I think you misremembered - there's lots of code that uses
`sys.platform == 'win32'` to detect Windows, but sys.platform is 'cli'
for IronPython. I'm pretty sure `os.name has always been 'nt' (when
running on Windows), and if not, it definitely is now.

Jython sets os.name to 'java' (IIRC), so there isn't a uniform way to
detect Windows across all implementations.

- Jeff
___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Lennart Regebro]

On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
 wrote:
> So that is interesting, but its not sufficient to meet the automation
> need Barry is calling out, unless all test suites can be run by
> 'python -m unittest discover' with no additional parameters [and a
> pretty large subset cannot].

But can they be changed so they are? That's gotta be the important bit.

What's needed here is not a tool that can run all unittests in
existence, but an official way for automated tools to run tests, with
the ability for any test and test framework to hook into that, so that
you can run any test suite automatically from an automated tool. The,
once that mechanism has been identified/implemented, we need to tell
everybody to do this.

I don't care much what that mechanism is, but I think the easiest way
to get there is to tell people to extend distutils with a test command
(or use Distribute) and perhaps add such a command in 3.4 that will do
the unittest discover thingy. I remember looking into zope.testrunner
hooking into that mechanism as well, but I don't remember what the
outcome was.

//Lennart
___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Donald Stufft]

On Tuesday, March 5, 2013 at 2:02 AM, Lennart Regebro wrote:
> On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
> mailto:robe...@robertcollins.net)> wrote:
> > So that is interesting, but its not sufficient to meet the automation
> > need Barry is calling out, unless all test suites can be run by
> > 'python -m unittest discover' with no additional parameters [and a
> > pretty large subset cannot].
> > 
> 
> 
> But can they be changed so they are? That's gotta be the important bit.
> 
> What's needed here is not a tool that can run all unittests in
> existence, but an official way for automated tools to run tests, with
> the ability for any test and test framework to hook into that, so that
> you can run any test suite automatically from an automated tool. The,
> once that mechanism has been identified/implemented, we need to tell
> everybody to do this.
> 
> I don't care much what that mechanism is, but I think the easiest way
> to get there is to tell people to extend distutils with a test command
> (or use Distribute) and perhaps add such a command in 3.4 that will do
> the unittest discover thingy. I remember looking into zope.testrunner
> hooking into that mechanism as well, but I don't remember what the
> outcome was.
> 
> 

Doesn't setuptools/distribute already have a setup.py test command? That
seems like the easiest way forward? 
> 
> //Lennart
> ___
> Python-Dev mailing list
> Python-Dev@python.org (mailto:Python-Dev@python.org)
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Robert Collins]

On 5 March 2013 20:02, Lennart Regebro  wrote:
> On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
>  wrote:
>> So that is interesting, but its not sufficient to meet the automation
>> need Barry is calling out, unless all test suites can be run by
>> 'python -m unittest discover' with no additional parameters [and a
>> pretty large subset cannot].
>
> But can they be changed so they are? That's gotta be the important bit.

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.

> What's needed here is not a tool that can run all unittests in
> existence, but an official way for automated tools to run tests, with
> the ability for any test and test framework to hook into that, so that
> you can run any test suite automatically from an automated tool. The,
> once that mechanism has been identified/implemented, we need to tell
> everybody to do this.

I think the command line is the right place to do that - declare as
metadata the command line to run a packages tests.

> I don't care much what that mechanism is, but I think the easiest way
> to get there is to tell people to extend distutils with a test command
> (or use Distribute) and perhaps add such a command in 3.4 that will do
> the unittest discover thingy. I remember looking into zope.testrunner
> hooking into that mechanism as well, but I don't remember what the
> outcome was.

Agreed.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services
___
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] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Antoine Pitrou]

On Mon, 4 Mar 2013 15:47:37 -0800
Eli Bendersky  wrote:
> On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou  wrote:
> 
> > On Mon, 4 Mar 2013 13:26:57 -0800
> > Eli Bendersky  wrote:
> > > [Splitting into a separate thread]
> > >
> > > Do we really need to overthink something that requires a trivial alias to
> > > set up for one's own convenience?
> > >
> > > Picking a Python version (as Barry mentions) is just one of the problems.
> > > What's wrong with:
> > >
> > > alias rupytests='python3 -m unittest discover"
> > > alias runpytests2='python2 -m unittest discover"
> > >
> > > ?
> > >
> > > Don't get me wrong, I love the "discover" option and agree that it should
> > > be the recommended way to go - but isn't this largely a documentation
> > issue?
> >
> > I would personally call it a typing issue :-) "python -m unittest
> > discover" is just too long.
> >
> 
> Command-line options for advanced capabilities can get long, yes.

The whole point is that discovery is not "advanced capability", it's
pretty basic by today's standards. So it should actually be the default
behaviour (like it is with nose).

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] Introducing Electronic Contributor Agreements

[Terry Reedy]

On 3/4/2013 7:51 PM, Mark Lawrence wrote:


Who's talking source code, you're previously mentioned *ALL* patches
needing a CLA.  Does this mean you have to sign a CLA for a one line
documentation patch?


It it is a one char typo, I would not bother downloading the patch, or 
adding a person to ACKS. If the patch is big enough to download and 
apply, then I want a CLA. If a person is sophisticated enough to submit 
a respository file diff, they are likely to submit more, and I want them 
to feel encouraged to do so by already having done the CLA. If we do not 
get it with the first submission, then when? Who keeps track of 
cumulative lines?



What is the definition of a patch, an actual patch file


Usually.


or a proposal for a change that is given within a bug tracker message?


I view a proposal for a change as just an idea. Such usually get 
re-written by whoever creates an actual patch.


I would like the link to the e-form to be accessible somewhere on the 
tracker so I can refer people to it easily.


--
Terry Jan Reedy

___
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