Re: [Python-Dev] PEP 380 acceptance (was Re: EuroPython Language Summit report)

2011-06-27 Thread renaud
Nick Coghlan  gmail.com> writes:

> I hit a snag with this. The real tests of the PEP 380 functionality
> aren't currently part of the patch - they're a big set of "golden
> output" tests in the zipfile hosted on Greg's site. Those need to be
> refactored into proper unittest or doctest based additions to the test
> suite and incorporated into the patch before I could commit this with
> a clear conscience. 

let me know if i can help.

> Renaud's patch mostly applies cleanly at the moment - the only change
> is that the "#endif" for the Py_LIMITED_API check needs to be moved in
> pyerrors.h so it also covers the new StopIteration struct definition.

if this helps, i've updated the patch to fix this.
https://bitbucket.org/rndblnch/cpython-pep380/changeset/6014d1720625

renaud


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 380 acceptance (was Re: EuroPython Language Summit report)

2011-06-28 Thread renaud
Nick Coghlan  gmail.com> writes:

> 
> On Tue, Jun 28, 2011 at 1:09 AM, renaud  gmail.com> wrote:
> > Nick Coghlan  gmail.com> writes:
> >
> >> I hit a snag with this. The real tests of the PEP 380 functionality
> >> aren't currently part of the patch - they're a big set of "golden
> >> output" tests in the zipfile hosted on Greg's site. Those need to be
> >> refactored into proper unittest or doctest based additions to the test
> >> suite and incorporated into the patch before I could commit this with
> >> a clear conscience.
> >
> > let me know if i can help.
> 
> It would be good if you could take a look at Greg's original test
> suite, consider ways of bringing it into the main regression tests and
> then update the patch queue on bitbucket accordingly.
> 
> My preference is for something unittest based, essentially taking the
> "golden output" comparisons and turning them into appropriate
> self.assert* invocations.
> 
> Given the number of tests Greg has, it will probably make more sense
> to do it as a new test subdirectory rather than as a single test file
> (although that depends on how many tests are in each file - if there
> are only a few, or if they overlap a lot, then having them as separate
> test cases within a single file may be a better choice).

ok, i've generated a single test_pep380.py using greg tests wrapped to be
run by unittest.
it's ugly, but it does the job.
some things that may not be desirable:
- line numbers in the tracebacks do rely on the position of the tests in the 
file, so any editing before the last test case will probably screw up 
everything;
- the test touches sys.stdout & sys.stderr

the whole thing is available here:
<https://bitbucket.org/rndblnch/cpython-pep380/src/tip/pep380-tests>

renaud

ps. i had to edit the test24 (Test parser module) expected output to make it
match the actual output, i guess that the parser module has changed since greg
wrote the tests.


___
Python-Dev mailing list
[email protected]
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 Core Tools

2011-10-03 Thread renaud
Maciej Fijalkowski  gmail.com> writes:

> https://bitbucket.org/pypy/pypy/src/59460302c713/lib_pypy/disassembler.py
> 
> this might be of interest. It's like dis module except it creates
> objects instead of printing them
> 

I think that Issue11816 (under review) aims at extending the dis module in a
similar direction:
Refactor the dis module to provide better building blocks for bytecode analysis
http://bugs.python.org/issue11816

renaud


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com