Re: [Cython] 0.16 release
2012/2/20 Vitja Makarov : > 2012/2/20 mark florisson : >> On 19 February 2012 10:16, Vitja Makarov wrote: >>> 2012/2/15 mark florisson : On 15 February 2012 15:45, mark florisson wrote: > On 14 February 2012 21:33, Robert Bradshaw > wrote: >> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson >> wrote: >>> On 14 February 2012 17:19, Robert Bradshaw >>> wrote: On Tue, Feb 14, 2012 at 7:49 AM, mark florisson wrote: > On 14 February 2012 07:07, Robert Bradshaw > wrote: >> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov >> wrote: >>> 2012/2/12 Vitja Makarov : 2012/2/11 Robert Bradshaw : > All of Sage passes except for one test: > > sage -t devel/sage/sage/misc/sageinspect.py > ** > File > "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", > line 970: > sage: > sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) > Expected: > ArgSpec(args=['self'], varargs=None, keywords=None, > defaults=None) > Got: > ArgSpec(args=['self'], varargs=None, keywords=None, > defaults=()) > ** > File > "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", > line 973: > sage: sage_getargspec(BooleanMonomialMonoid.gen) > Expected: > ArgSpec(args=['self', 'i'], varargs=None, keywords=None, > defaults=(0,)) > Got: > ArgSpec(args=['self', 'i'], varargs=None, keywords=None, > defaults=()) > ** > 1 items had failures: > 2 of 31 in __main__.example_21 > ***Test Failed*** 2 failures. > > Any ideas why this would have changed? > CyFunction now provides its own code object. So inspect.getargs() is called instead of inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It seems like func.func_defaults should be implemented. >>> >>> I've created a pull request: >>> >>> https://github.com/cython/cython/pull/88 >> >> Thanks! The only other thing I can think of was a question of using >> caching to mitigate the longer compile times, but I can't remember if >> this was resolved. > > The compiler has like 2 or 3 seconds of constant overhead if you use > memoryviews. That'd be nice to cut down, but certainly not a blocker. >> As I'm going to be MIA any day now, someone else should take up the >> banner to push this long awaited release. > > "Missing in action"? Are you planning to desert? :) I can't find any > relevant abbreviation, but I think I know what it means, > congratulations in advance. Twin boys coming any day now! >>> >>> And the Cython team just keeps on growing! >> >> :) >> > Stefan, you have been involved the longest, would you feel up to the > task? You probably have the best understanding and experience with any > issues (no pressure :). Otherwise I could have a try... It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-building and updating the pointer to the documentation, ...) If it goes on for a while it's worth making/using a release branch on github. >>> >>> Thanks for the summary, I'm sure I would have missed one or two :) Ok, >>> I'll volunteer then. Maybe I can create a beta somewhere next week and >>> then we can see the community tear it apart. >> >> Thanks! >> >> - Robert >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel > > Sorry, my previous email with attachment bounced. Here goes. > > I'm getting a substantial amount of failin
Re: [Cython] 0.16 release
On 23 February 2012 08:30, Vitja Makarov wrote: > 2012/2/20 Vitja Makarov : >> 2012/2/20 mark florisson : >>> On 19 February 2012 10:16, Vitja Makarov wrote: 2012/2/15 mark florisson : > On 15 February 2012 15:45, mark florisson > wrote: >> On 14 February 2012 21:33, Robert Bradshaw >> wrote: >>> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson >>> wrote: On 14 February 2012 17:19, Robert Bradshaw wrote: > On Tue, Feb 14, 2012 at 7:49 AM, mark florisson > wrote: >> On 14 February 2012 07:07, Robert Bradshaw >> wrote: >>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov >>> wrote: 2012/2/12 Vitja Makarov : > 2012/2/11 Robert Bradshaw : >> All of Sage passes except for one test: >> >> sage -t devel/sage/sage/misc/sageinspect.py >> ** >> File >> "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >> line 970: >> sage: >> sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >> Expected: >> ArgSpec(args=['self'], varargs=None, keywords=None, >> defaults=None) >> Got: >> ArgSpec(args=['self'], varargs=None, keywords=None, >> defaults=()) >> ** >> File >> "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >> line 973: >> sage: sage_getargspec(BooleanMonomialMonoid.gen) >> Expected: >> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, >> defaults=(0,)) >> Got: >> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, >> defaults=()) >> ** >> 1 items had failures: >> 2 of 31 in __main__.example_21 >> ***Test Failed*** 2 failures. >> >> Any ideas why this would have changed? >> > > CyFunction now provides its own code object. So inspect.getargs() > is > called instead of > inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It > seems like func.func_defaults should be implemented. > > I've created a pull request: https://github.com/cython/cython/pull/88 >>> >>> Thanks! The only other thing I can think of was a question of using >>> caching to mitigate the longer compile times, but I can't remember >>> if >>> this was resolved. >> >> The compiler has like 2 or 3 seconds of constant overhead if you use >> memoryviews. > > That'd be nice to cut down, but certainly not a blocker. > >>> As I'm going to be MIA any day now, someone else should take up the >>> banner to push this long awaited release. >> >> "Missing in action"? Are you planning to desert? :) I can't find any >> relevant abbreviation, but I think I know what it means, >> congratulations in advance. > > Twin boys coming any day now! And the Cython team just keeps on growing! >>> >>> :) >>> >> Stefan, you have been involved the longest, would you feel up to the >> task? You probably have the best understanding and experience with >> any >> issues (no pressure :). Otherwise I could have a try... > > It's pretty easy. Once the defaults change is in it's probably worth > cutting a beta or release candidate to email to dev/users, and if > there's no blocking feedback you go ahead and push it out (basically > writing up the release notes on the wiki, cleaning up trac, tagging > the repository, making sure everything we care about on hudson is > still passing, uploading to pypi and the website (the sdist tarball), > emailing our lists and python-announce, re-building and updating the > pointer to the documentation, ...) If it goes on for a while it's > worth making/using a release branch on github. Thanks for the summary, I'm sure I would have missed one or two :) Ok, I'll volunteer then. Maybe I can create a beta somewhere next week and then we can see the community tear it apart. >>> >>> Thanks! >>> >>> - Robert >>> ___ >>> cython-devel mailing list >>> cython-devel@python.org
Re: [Cython] 0.16 release
2012/2/23 mark florisson : > On 23 February 2012 08:30, Vitja Makarov wrote: >> 2012/2/20 Vitja Makarov : >>> 2012/2/20 mark florisson : On 19 February 2012 10:16, Vitja Makarov wrote: > 2012/2/15 mark florisson : >> On 15 February 2012 15:45, mark florisson >> wrote: >>> On 14 February 2012 21:33, Robert Bradshaw >>> wrote: On Tue, Feb 14, 2012 at 1:09 PM, mark florisson wrote: > On 14 February 2012 17:19, Robert Bradshaw > wrote: >> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >> wrote: >>> On 14 February 2012 07:07, Robert Bradshaw >>> wrote: On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov wrote: > 2012/2/12 Vitja Makarov : >> 2012/2/11 Robert Bradshaw : >>> All of Sage passes except for one test: >>> >>> sage -t devel/sage/sage/misc/sageinspect.py >>> ** >>> File >>> "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>> line 970: >>> sage: >>> sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>> Expected: >>> ArgSpec(args=['self'], varargs=None, keywords=None, >>> defaults=None) >>> Got: >>> ArgSpec(args=['self'], varargs=None, keywords=None, >>> defaults=()) >>> ** >>> File >>> "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>> line 973: >>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>> Expected: >>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, >>> defaults=(0,)) >>> Got: >>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, >>> defaults=()) >>> ** >>> 1 items had failures: >>> 2 of 31 in __main__.example_21 >>> ***Test Failed*** 2 failures. >>> >>> Any ideas why this would have changed? >>> >> >> CyFunction now provides its own code object. So >> inspect.getargs() is >> called instead of >> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). >> It >> seems like func.func_defaults should be implemented. >> >> > > I've created a pull request: > > https://github.com/cython/cython/pull/88 Thanks! The only other thing I can think of was a question of using caching to mitigate the longer compile times, but I can't remember if this was resolved. >>> >>> The compiler has like 2 or 3 seconds of constant overhead if you use >>> memoryviews. >> >> That'd be nice to cut down, but certainly not a blocker. >> As I'm going to be MIA any day now, someone else should take up the banner to push this long awaited release. >>> >>> "Missing in action"? Are you planning to desert? :) I can't find any >>> relevant abbreviation, but I think I know what it means, >>> congratulations in advance. >> >> Twin boys coming any day now! > > And the Cython team just keeps on growing! :) >>> Stefan, you have been involved the longest, would you feel up to the >>> task? You probably have the best understanding and experience with >>> any >>> issues (no pressure :). Otherwise I could have a try... >> >> It's pretty easy. Once the defaults change is in it's probably worth >> cutting a beta or release candidate to email to dev/users, and if >> there's no blocking feedback you go ahead and push it out (basically >> writing up the release notes on the wiki, cleaning up trac, tagging >> the repository, making sure everything we care about on hudson is >> still passing, uploading to pypi and the website (the sdist tarball), >> emailing our lists and python-announce, re-building and updating the >> pointer to the documentation, ...) If it goes on for a while it's >> worth making/using a release branch on github. > > Thanks for the summary, I'm sure I would have missed one or two :) Ok, > I'll volunteer then. Maybe I can create a beta somewhere next week and > then we can see the community tear it apart. T
Re: [Cython] 0.16 release
2012/2/23 Vitja Makarov : > 2012/2/23 mark florisson : >> On 23 February 2012 08:30, Vitja Makarov wrote: >>> 2012/2/20 Vitja Makarov : 2012/2/20 mark florisson : > On 19 February 2012 10:16, Vitja Makarov wrote: >> 2012/2/15 mark florisson : >>> On 15 February 2012 15:45, mark florisson >>> wrote: On 14 February 2012 21:33, Robert Bradshaw wrote: > On Tue, Feb 14, 2012 at 1:09 PM, mark florisson > wrote: >> On 14 February 2012 17:19, Robert Bradshaw >> wrote: >>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >>> wrote: On 14 February 2012 07:07, Robert Bradshaw wrote: > On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov > wrote: >> 2012/2/12 Vitja Makarov : >>> 2012/2/11 Robert Bradshaw : All of Sage passes except for one test: sage -t devel/sage/sage/misc/sageinspect.py ** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 970: sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) Expected: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) Got: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) ** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 973: sage: sage_getargspec(BooleanMonomialMonoid.gen) Expected: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) Got: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) ** 1 items had failures: 2 of 31 in __main__.example_21 ***Test Failed*** 2 failures. Any ideas why this would have changed? >>> >>> CyFunction now provides its own code object. So >>> inspect.getargs() is >>> called instead of >>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). >>> It >>> seems like func.func_defaults should be implemented. >>> >>> >> >> I've created a pull request: >> >> https://github.com/cython/cython/pull/88 > > Thanks! The only other thing I can think of was a question of > using > caching to mitigate the longer compile times, but I can't > remember if > this was resolved. The compiler has like 2 or 3 seconds of constant overhead if you use memoryviews. >>> >>> That'd be nice to cut down, but certainly not a blocker. >>> > As I'm going to be MIA any day now, someone else should take up > the > banner to push this long awaited release. "Missing in action"? Are you planning to desert? :) I can't find any relevant abbreviation, but I think I know what it means, congratulations in advance. >>> >>> Twin boys coming any day now! >> >> And the Cython team just keeps on growing! > > :) > Stefan, you have been involved the longest, would you feel up to the task? You probably have the best understanding and experience with any issues (no pressure :). Otherwise I could have a try... >>> >>> It's pretty easy. Once the defaults change is in it's probably worth >>> cutting a beta or release candidate to email to dev/users, and if >>> there's no blocking feedback you go ahead and push it out (basically >>> writing up the release notes on the wiki, cleaning up trac, tagging >>> the repository, making sure everything we care about on hudson is >>> still passing, uploading to pypi and the website (the sdist >>> tarball), >>> emailing our lists and python-announce, re-building and updating the >>> pointer to the documentation, ...) If it goes on for a while it's >>> worth making/using a release branch on github. >> >> Thanks
Re: [Cython] 0.16 release
On 23 February 2012 08:36, Vitja Makarov wrote: > 2012/2/23 mark florisson : >> On 23 February 2012 08:30, Vitja Makarov wrote: >>> 2012/2/20 Vitja Makarov : 2012/2/20 mark florisson : > On 19 February 2012 10:16, Vitja Makarov wrote: >> 2012/2/15 mark florisson : >>> On 15 February 2012 15:45, mark florisson >>> wrote: On 14 February 2012 21:33, Robert Bradshaw wrote: > On Tue, Feb 14, 2012 at 1:09 PM, mark florisson > wrote: >> On 14 February 2012 17:19, Robert Bradshaw >> wrote: >>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >>> wrote: On 14 February 2012 07:07, Robert Bradshaw wrote: > On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov > wrote: >> 2012/2/12 Vitja Makarov : >>> 2012/2/11 Robert Bradshaw : All of Sage passes except for one test: sage -t devel/sage/sage/misc/sageinspect.py ** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 970: sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) Expected: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) Got: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) ** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 973: sage: sage_getargspec(BooleanMonomialMonoid.gen) Expected: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) Got: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) ** 1 items had failures: 2 of 31 in __main__.example_21 ***Test Failed*** 2 failures. Any ideas why this would have changed? >>> >>> CyFunction now provides its own code object. So >>> inspect.getargs() is >>> called instead of >>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). >>> It >>> seems like func.func_defaults should be implemented. >>> >>> >> >> I've created a pull request: >> >> https://github.com/cython/cython/pull/88 > > Thanks! The only other thing I can think of was a question of > using > caching to mitigate the longer compile times, but I can't > remember if > this was resolved. The compiler has like 2 or 3 seconds of constant overhead if you use memoryviews. >>> >>> That'd be nice to cut down, but certainly not a blocker. >>> > As I'm going to be MIA any day now, someone else should take up > the > banner to push this long awaited release. "Missing in action"? Are you planning to desert? :) I can't find any relevant abbreviation, but I think I know what it means, congratulations in advance. >>> >>> Twin boys coming any day now! >> >> And the Cython team just keeps on growing! > > :) > Stefan, you have been involved the longest, would you feel up to the task? You probably have the best understanding and experience with any issues (no pressure :). Otherwise I could have a try... >>> >>> It's pretty easy. Once the defaults change is in it's probably worth >>> cutting a beta or release candidate to email to dev/users, and if >>> there's no blocking feedback you go ahead and push it out (basically >>> writing up the release notes on the wiki, cleaning up trac, tagging >>> the repository, making sure everything we care about on hudson is >>> still passing, uploading to pypi and the website (the sdist >>> tarball), >>> emailing our lists and python-announce, re-building and updating the >>> pointer to the documentation, ...) If it goes on for a while it's >>> worth making/using a release branch on github. >
Re: [Cython] 0.16 release
2012/2/23 mark florisson : > On 23 February 2012 08:36, Vitja Makarov wrote: >> 2012/2/23 mark florisson : >>> On 23 February 2012 08:30, Vitja Makarov wrote: 2012/2/20 Vitja Makarov : > 2012/2/20 mark florisson : >> On 19 February 2012 10:16, Vitja Makarov wrote: >>> 2012/2/15 mark florisson : On 15 February 2012 15:45, mark florisson wrote: > On 14 February 2012 21:33, Robert Bradshaw > wrote: >> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson >> wrote: >>> On 14 February 2012 17:19, Robert Bradshaw >>> wrote: On Tue, Feb 14, 2012 at 7:49 AM, mark florisson wrote: > On 14 February 2012 07:07, Robert Bradshaw > wrote: >> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov >> wrote: >>> 2012/2/12 Vitja Makarov : 2012/2/11 Robert Bradshaw : > All of Sage passes except for one test: > > sage -t devel/sage/sage/misc/sageinspect.py > ** > File > "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", > line 970: > sage: > sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) > Expected: > ArgSpec(args=['self'], varargs=None, keywords=None, > defaults=None) > Got: > ArgSpec(args=['self'], varargs=None, keywords=None, > defaults=()) > ** > File > "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", > line 973: > sage: sage_getargspec(BooleanMonomialMonoid.gen) > Expected: > ArgSpec(args=['self', 'i'], varargs=None, keywords=None, > defaults=(0,)) > Got: > ArgSpec(args=['self', 'i'], varargs=None, keywords=None, > defaults=()) > ** > 1 items had failures: > 2 of 31 in __main__.example_21 > ***Test Failed*** 2 failures. > > Any ideas why this would have changed? > CyFunction now provides its own code object. So inspect.getargs() is called instead of inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It seems like func.func_defaults should be implemented. >>> >>> I've created a pull request: >>> >>> https://github.com/cython/cython/pull/88 >> >> Thanks! The only other thing I can think of was a question of >> using >> caching to mitigate the longer compile times, but I can't >> remember if >> this was resolved. > > The compiler has like 2 or 3 seconds of constant overhead if you > use > memoryviews. That'd be nice to cut down, but certainly not a blocker. >> As I'm going to be MIA any day now, someone else should take up >> the >> banner to push this long awaited release. > > "Missing in action"? Are you planning to desert? :) I can't find > any > relevant abbreviation, but I think I know what it means, > congratulations in advance. Twin boys coming any day now! >>> >>> And the Cython team just keeps on growing! >> >> :) >> > Stefan, you have been involved the longest, would you feel up to > the > task? You probably have the best understanding and experience > with any > issues (no pressure :). Otherwise I could have a try... It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-b
Re: [Cython] 0.16 release
mark florisson, 23.02.2012 09:38: > On 23 February 2012 08:36, Vitja Makarov wrote: >> 2012/2/23 mark florisson: >>> On 23 February 2012 08:30, Vitja Makarov wrote: We can also fix this ticket before release http://trac.cython.org/cython_trac/ticket/761 >>> >>> Good idea. I think the ticket should read 'sys.path' instead of >>> PYTHONPATH, though. >> >> Yeah, I think the fix is trivial we should prepend (or append?) >> sys.path to cython includes > > I think append, you'd want local things to override installed things > along sys.path. I think it's 1) user provided directories 2) Cython provided directories 3) sys.path or would you swap 2) and 3) ? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] 0.16 release
On 23 February 2012 15:43, Stefan Behnel wrote: > mark florisson, 23.02.2012 09:38: >> On 23 February 2012 08:36, Vitja Makarov wrote: >>> 2012/2/23 mark florisson: On 23 February 2012 08:30, Vitja Makarov wrote: > We can also fix this ticket before release > http://trac.cython.org/cython_trac/ticket/761 Good idea. I think the ticket should read 'sys.path' instead of PYTHONPATH, though. >>> >>> Yeah, I think the fix is trivial we should prepend (or append?) >>> sys.path to cython includes >> >> I think append, you'd want local things to override installed things >> along sys.path. > > I think it's > > 1) user provided directories > > 2) Cython provided directories > > 3) sys.path I think this is the most sensible order, yes. And the current directory would also come before anything else, as always. > or would you swap 2) and 3) ? > > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] cython tests and py3k hash randomization
Recent py3k version has new feature "hash randomization" it solves
some security issues.
But has some drawbacks, for instance, dict.items() order is now
unknown. So it breaks
randomly some doctests that rely on exact order of dict items.
vitja@mchome:~/python$ ./py3k/bin/python -c "print({'a':1, 'b':2})"
{'b': 2, 'a': 1}
vitja@mchome:~/python$ ./py3k/bin/python -c "print({'a':1, 'b':2})"
{'a': 1, 'b': 2}
As a workaround we can set PYTHONHASHSEED environment variable to zero
for all cyhon-*-tests targets
This also affects generated code it internally depends on order of
items returned by dict.items()
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Broken C-API generation for ext modules
The commit below from Stefan broke C-API generation for extension modules. The problem is that the code of __Pyx_ImportModule() and __Pyx_ImportType() depeds on the #definition of __Pyx_PyIdentifier_FromString , and such #define is not emitted in C-API headers. Stefan, given that __Pyx_PyIdentifier_FromString() is only used in __Pyx_ImportModule() and __Pyx_ImportType(), what's your opinion about just rolling back your commit? commit 500f9a40f5ad441c2c204d076cfc4f82a41d531b Author: Stefan Behnel Date: Sat Sep 10 00:14:05 2011 +0200 minor code simplification in utility functions by using macro for Py2/3 dependent PyString/PyUnicode_FromString() calls -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169 ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython tests and py3k hash randomization
On 23 February 2012 20:52, Vitja Makarov wrote:
> Recent py3k version has new feature "hash randomization" it solves
> some security issues.
> But has some drawbacks, for instance, dict.items() order is now
> unknown. So it breaks
> randomly some doctests that rely on exact order of dict items.
>
> vitja@mchome:~/python$ ./py3k/bin/python -c "print({'a':1, 'b':2})"
> {'b': 2, 'a': 1}
> vitja@mchome:~/python$ ./py3k/bin/python -c "print({'a':1, 'b':2})"
> {'a': 1, 'b': 2}
>
> As a workaround we can set PYTHONHASHSEED environment variable to zero
> for all cyhon-*-tests targets
>
> This also affects generated code it internally depends on order of
> items returned by dict.items()
Any code or test that relies on dictionary order is wrong, really. So
I assume any pyregr issues will be fixed by the CPython test suite? If
there are any such failing tests in Cython we should simply fix them.
> --
> vitja.
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython tests and py3k hash randomization
2012/2/24 mark florisson :
> On 23 February 2012 20:52, Vitja Makarov wrote:
>> Recent py3k version has new feature "hash randomization" it solves
>> some security issues.
>> But has some drawbacks, for instance, dict.items() order is now
>> unknown. So it breaks
>> randomly some doctests that rely on exact order of dict items.
>>
>> vitja@mchome:~/python$ ./py3k/bin/python -c "print({'a':1, 'b':2})"
>> {'b': 2, 'a': 1}
>> vitja@mchome:~/python$ ./py3k/bin/python -c "print({'a':1, 'b':2})"
>> {'a': 1, 'b': 2}
>>
>> As a workaround we can set PYTHONHASHSEED environment variable to zero
>> for all cyhon-*-tests targets
>>
>> This also affects generated code it internally depends on order of
>> items returned by dict.items()
>
> Any code or test that relies on dictionary order is wrong, really. So
> I assume any pyregr issues will be fixed by the CPython test suite? If
> there are any such failing tests in Cython we should simply fix them.
>
Yes, you're right but I'm not sure how many tests may be broken. I
don't think we want to fix
them before release. Now I've added
# Disable python hash randomization
export PYTHONHASHSEED=0
to cython-devel-tests and it worked.
It's not that easy to fix, here is simple doctest:
def test_foo():
"""
>>> test_foo()
{'a': 1, 'b': 2}
"""
return {'a': 1, 'b': 2}
You can't use dicts in doctests anymore there are few options instead:
1. Compare sorted items(), e.g. sorted(test_foo().items())
2. Inplace compare test_foo() == {...}
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
