Re: [Cython] All DEF constants are now unsigned?
On Sun, Sep 6, 2015 at 5:30 AM, Stefan Behnel wrote: > Jeroen Demeyer schrieb am 06.09.2015 um 10:54: >> On 2015-09-05 17:09, Stefan Behnel wrote: >>> It now appends the 'U' suffix only to literals that are used in an unsigned >>> context (e.g. assignment to unsigned variable), and additionally appends >>> L/LL suffixes for integers that might exceed the int/long limits. >> >> Why not just keep it simple, append no suffixes and let the C/C++ compiler >> deal with it? No heuristics needed. >> >> More concretely, I would handle this as follows: >> * do not use any L or U suffix >> * write all DEF constants as hexadecimal in the source code >> >> This way, the C/C++ compiler will determine the integral type. > > I previously tried that with decimal literals and got warnings in gcc. > Hadn't tried hex literals. > > >> It will use >> the first type in the following list which can represent the number: >> - int >> - unsigned int >> - long >> - unsigned long >> - long long >> - unsigned long long >> >> The reason for the *hexadecimal* constants is that the unsigned types are >> not tried for decimal constants. > > That's interesting to know (you were quoting 6.4.4 of the C standard > apparently). C - what a language full of wonders. Wow, I didn't know that either... thanks for the pointer. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Integer division
Or perhaps we should respect float division even with cdivision... Thoughts? On Mon, Sep 7, 2015 at 5:13 PM, Robert Bradshaw wrote: > Oh, that's another issue. I'll clarify this in the documentation. > > On Mon, Sep 7, 2015 at 3:59 PM, Antony Lee wrote: >> Actually I realized that it's another problem; setting cdivision to True (as >> I did in the directive of the example I gave, because I basically always set >> this to True) overrides __future__ division and restores the C division >> semantic that int / int = int. The documentation actually says that the >> cdivision directive should only affect the case of operands with different >> signs and of division by zero, not whether int / int = int. >> Antony >> >> 2015-09-07 15:50 GMT-07:00 Robert Bradshaw : >>> >>> On Mon, Sep 7, 2015 at 3:46 PM, Robert Bradshaw >>> wrote: >>> > On Mon, Sep 7, 2015 at 3:29 PM, Antony Lee >>> > wrote: >>> >> Sorry, I intended the entire discussion to apply to the case of Python3 >>> >> semantics. Indeed, even with language_level=3 and from __future__ >>> >> import >>> >> division, foo.decl(3, 3) prints "1, 2, 0, 1" whereas foo.nodecl(3, 3) >>> >> prints >>> >> "1.0, 0.5, 2.0, 1.0". >>> > >>> > from __future__ import division behaves as expected; I just added some >>> > even more explicit tests: >>> > >>> > https://github.com/cython/cython/commit/e61da2eb8a292bc34285c895aade523b6d353414 >>> > >>> > I'm surprised language_level=3 doesn't automatically set this directive. >>> >>> Are you sure you're setting it correctly? >>> https://github.com/cython/cython/blob/master/tests/run/cython3.pyx#L30 >>> >>> >> 2015-09-07 15:07 GMT-07:00 Robert Bradshaw : >>> >>> >>> >>> On Mon, Sep 7, 2015 at 11:59 AM, Antony Lee >>> >>> wrote: >>> >>> > I would like to suggest that division of integers with "/" prints a >>> >>> > warning >>> >>> > at compile time. In my opinion, "/" should be restricted to float >>> >>> > division, >>> >>> > and "//" should be used when rounding semantics are required. >>> >>> > >>> >>> > Otherwise, we get weird edge cases such as: >>> >>> > >>> >>> > #cython: cdivision=True, infer_types=True >>> >>> > def decl(int m, int n): >>> >>> > for i in range(1, m): >>> >>> > for j in range(1, n): >>> >>> > print(i / j) # integer division >>> >>> > >>> >>> > def nodecl(m, n): >>> >>> > for i in range(1, m): >>> >>> > for j in range(1, n): >>> >>> > print(i / j) # float division >>> >>> >>> >>> Slight correction: int or float division depending on whether you're >>> >>> using Python 2 or Python 3. The runtime type of i/j isn't something we >>> >>> can delegate to the C compiler. >>> >>> >>> >>> > (whose behavior may even change if type inference rules changes). >>> >>> > >>> >>> > A more extreme choice would be to have "/" always behave like float >>> >>> > (double) >>> >>> > division even with integer arguments. >>> >>> >>> >>> You mean like putting from __future__ import division at the top of >>> >>> your file? Or compiling with -3 (for Python 3 language semantics)? >>> >>> >>> >>> -- >>> >>> >>> >>> --- >>> >>> You received this message because you are subscribed to the Google >>> >>> Groups >>> >>> "cython-users" group. >>> >>> To unsubscribe from this group and stop receiving emails from it, send >>> >>> an >>> >>> email to cython-users+unsubscr...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >>> >> >>> >> -- >>> >> >>> >> --- >>> >> You received this message because you are subscribed to the Google >>> >> Groups >>> >> "cython-users" group. >>> >> To unsubscribe from this group and stop receiving emails from it, send >>> >> an >>> >> email to cython-users+unsubscr...@googlegroups.com. >>> >> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "cython-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to cython-users+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "cython-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to cython-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Integer division
On Mon, Sep 7, 2015 at 5:42 PM, Antony Lee wrote: > My 2c (not cc'ed to cython-devel, as I am not registered): > > - language_level=3 implies __future__ division. > - if __future__ division is set: int / int => float (whether variables are > untyped (= typed at runtime by python) or typed (including by the > inferencer)) > - if __future__ division is not set: int / int => int, with > opposite-sign-case and zero-divisor-case handled depending on cdivision > - in both cases, int // int => int, with opposite-sign-case and > zero-divisor-case handled depending on cdivision (also for % and divmod). That's what I'm leaning towards as well, but it is backwards incompatible. Anyone else have any opinions? > 2015-09-07 17:15 GMT-07:00 Robert Bradshaw : >> >> Or perhaps we should respect float division even with cdivision... >> Thoughts? >> >> On Mon, Sep 7, 2015 at 5:13 PM, Robert Bradshaw >> wrote: >> > Oh, that's another issue. I'll clarify this in the documentation. >> > >> > On Mon, Sep 7, 2015 at 3:59 PM, Antony Lee >> > wrote: >> >> Actually I realized that it's another problem; setting cdivision to >> >> True (as >> >> I did in the directive of the example I gave, because I basically >> >> always set >> >> this to True) overrides __future__ division and restores the C division >> >> semantic that int / int = int. The documentation actually says that >> >> the >> >> cdivision directive should only affect the case of operands with >> >> different >> >> signs and of division by zero, not whether int / int = int. >> >> Antony >> >> >> >> 2015-09-07 15:50 GMT-07:00 Robert Bradshaw : >> >>> >> >>> On Mon, Sep 7, 2015 at 3:46 PM, Robert Bradshaw >> >>> wrote: >> >>> > On Mon, Sep 7, 2015 at 3:29 PM, Antony Lee >> >>> > wrote: >> >>> >> Sorry, I intended the entire discussion to apply to the case of >> >>> >> Python3 >> >>> >> semantics. Indeed, even with language_level=3 and from __future__ >> >>> >> import >> >>> >> division, foo.decl(3, 3) prints "1, 2, 0, 1" whereas foo.nodecl(3, >> >>> >> 3) >> >>> >> prints >> >>> >> "1.0, 0.5, 2.0, 1.0". >> >>> > >> >>> > from __future__ import division behaves as expected; I just added >> >>> > some >> >>> > even more explicit tests: >> >>> > >> >>> > >> >>> > https://github.com/cython/cython/commit/e61da2eb8a292bc34285c895aade523b6d353414 >> >>> > >> >>> > I'm surprised language_level=3 doesn't automatically set this >> >>> > directive. >> >>> >> >>> Are you sure you're setting it correctly? >> >>> https://github.com/cython/cython/blob/master/tests/run/cython3.pyx#L30 >> >>> >> >>> >> 2015-09-07 15:07 GMT-07:00 Robert Bradshaw : >> >>> >>> >> >>> >>> On Mon, Sep 7, 2015 at 11:59 AM, Antony Lee >> >>> >>> >> >>> >>> wrote: >> >>> >>> > I would like to suggest that division of integers with "/" >> >>> >>> > prints a >> >>> >>> > warning >> >>> >>> > at compile time. In my opinion, "/" should be restricted to >> >>> >>> > float >> >>> >>> > division, >> >>> >>> > and "//" should be used when rounding semantics are required. >> >>> >>> > >> >>> >>> > Otherwise, we get weird edge cases such as: >> >>> >>> > >> >>> >>> > #cython: cdivision=True, infer_types=True >> >>> >>> > def decl(int m, int n): >> >>> >>> > for i in range(1, m): >> >>> >>> > for j in range(1, n): >> >>> >>> > print(i / j) # integer division >> >>> >>> > >> >>> >>> > def nodecl(m, n): >> >>> >>> > for i in range(1, m): >> >>> >>> > for j in range(1, n): >> >>> >>> > print(i / j) # float division >> >>> >>> >> >>> >>> Slight correction: int or float division depending on whether >> >>> >>> you're >> >>> >>> using Python 2 or Python 3. The runtime type of i/j isn't >> >>> >>> something we >> >>> >>> can delegate to the C compiler. >> >>> >>> >> >>> >>> > (whose behavior may even change if type inference rules >> >>> >>> > changes). >> >>> >>> > >> >>> >>> > A more extreme choice would be to have "/" always behave like >> >>> >>> > float >> >>> >>> > (double) >> >>> >>> > division even with integer arguments. >> >>> >>> >> >>> >>> You mean like putting from __future__ import division at the top >> >>> >>> of >> >>> >>> your file? Or compiling with -3 (for Python 3 language semantics)? >> >>> >>> >> >>> >>> -- >> >>> >>> >> >>> >>> --- >> >>> >>> You received this message because you are subscribed to the Google >> >>> >>> Groups >> >>> >>> "cython-users" group. >> >>> >>> To unsubscribe from this group and stop receiving emails from it, >> >>> >>> send >> >>> >>> an >> >>> >>> email to cython-users+unsubscr...@googlegroups.com. >> >>> >>> For more options, visit https://groups.google.com/d/optout. >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> >> >>> >> --- >> >>> >> You received this message because you are subscribed to the Google >> >>> >> Groups >> >>> >> "cython-users" group. >> >>> >> To unsubscribe from this group and stop receiving emails from it, >> >>> >> send >> >>> >> an >> >>> >> email to cython-users+unsubscr...@googlegroups.com. >> >>> >> For m
Re: [Cython] [cython-users] Integer division
Since Cython already tries to make division of C integers behave like Python division, I'd expect python-like behavior (mimicking python 2 or 3 as needed) by default and unchanged C integer division when the cdivision directive is set. Best, -Ian Henriksen On Mon, Sep 7, 2015 at 9:55 PM Robert Bradshaw wrote: > On Mon, Sep 7, 2015 at 5:42 PM, Antony Lee > wrote: > > My 2c (not cc'ed to cython-devel, as I am not registered): > > > > - language_level=3 implies __future__ division. > > - if __future__ division is set: int / int => float (whether variables > are > > untyped (= typed at runtime by python) or typed (including by the > > inferencer)) > > - if __future__ division is not set: int / int => int, with > > opposite-sign-case and zero-divisor-case handled depending on cdivision > > - in both cases, int // int => int, with opposite-sign-case and > > zero-divisor-case handled depending on cdivision (also for % and divmod). > > That's what I'm leaning towards as well, but it is backwards > incompatible. Anyone else have any opinions? > > > 2015-09-07 17:15 GMT-07:00 Robert Bradshaw : > >> > >> Or perhaps we should respect float division even with cdivision... > >> Thoughts? > >> > >> On Mon, Sep 7, 2015 at 5:13 PM, Robert Bradshaw > >> wrote: > >> > Oh, that's another issue. I'll clarify this in the documentation. > >> > > >> > On Mon, Sep 7, 2015 at 3:59 PM, Antony Lee > >> > wrote: > >> >> Actually I realized that it's another problem; setting cdivision to > >> >> True (as > >> >> I did in the directive of the example I gave, because I basically > >> >> always set > >> >> this to True) overrides __future__ division and restores the C > division > >> >> semantic that int / int = int. The documentation actually says that > >> >> the > >> >> cdivision directive should only affect the case of operands with > >> >> different > >> >> signs and of division by zero, not whether int / int = int. > >> >> Antony > >> >> > >> >> 2015-09-07 15:50 GMT-07:00 Robert Bradshaw : > >> >>> > >> >>> On Mon, Sep 7, 2015 at 3:46 PM, Robert Bradshaw > > >> >>> wrote: > >> >>> > On Mon, Sep 7, 2015 at 3:29 PM, Antony Lee < > antony@berkeley.edu> > >> >>> > wrote: > >> >>> >> Sorry, I intended the entire discussion to apply to the case of > >> >>> >> Python3 > >> >>> >> semantics. Indeed, even with language_level=3 and from > __future__ > >> >>> >> import > >> >>> >> division, foo.decl(3, 3) prints "1, 2, 0, 1" whereas > foo.nodecl(3, > >> >>> >> 3) > >> >>> >> prints > >> >>> >> "1.0, 0.5, 2.0, 1.0". > >> >>> > > >> >>> > from __future__ import division behaves as expected; I just added > >> >>> > some > >> >>> > even more explicit tests: > >> >>> > > >> >>> > > >> >>> > > https://github.com/cython/cython/commit/e61da2eb8a292bc34285c895aade523b6d353414 > >> >>> > > >> >>> > I'm surprised language_level=3 doesn't automatically set this > >> >>> > directive. > >> >>> > >> >>> Are you sure you're setting it correctly? > >> >>> > https://github.com/cython/cython/blob/master/tests/run/cython3.pyx#L30 > >> >>> > >> >>> >> 2015-09-07 15:07 GMT-07:00 Robert Bradshaw : > >> >>> >>> > >> >>> >>> On Mon, Sep 7, 2015 at 11:59 AM, Antony Lee > >> >>> >>> > >> >>> >>> wrote: > >> >>> >>> > I would like to suggest that division of integers with "/" > >> >>> >>> > prints a > >> >>> >>> > warning > >> >>> >>> > at compile time. In my opinion, "/" should be restricted to > >> >>> >>> > float > >> >>> >>> > division, > >> >>> >>> > and "//" should be used when rounding semantics are required. > >> >>> >>> > > >> >>> >>> > Otherwise, we get weird edge cases such as: > >> >>> >>> > > >> >>> >>> > #cython: cdivision=True, infer_types=True > >> >>> >>> > def decl(int m, int n): > >> >>> >>> > for i in range(1, m): > >> >>> >>> > for j in range(1, n): > >> >>> >>> > print(i / j) # integer division > >> >>> >>> > > >> >>> >>> > def nodecl(m, n): > >> >>> >>> > for i in range(1, m): > >> >>> >>> > for j in range(1, n): > >> >>> >>> > print(i / j) # float division > >> >>> >>> > >> >>> >>> Slight correction: int or float division depending on whether > >> >>> >>> you're > >> >>> >>> using Python 2 or Python 3. The runtime type of i/j isn't > >> >>> >>> something we > >> >>> >>> can delegate to the C compiler. > >> >>> >>> > >> >>> >>> > (whose behavior may even change if type inference rules > >> >>> >>> > changes). > >> >>> >>> > > >> >>> >>> > A more extreme choice would be to have "/" always behave like > >> >>> >>> > float > >> >>> >>> > (double) > >> >>> >>> > division even with integer arguments. > >> >>> >>> > >> >>> >>> You mean like putting from __future__ import division at the top > >> >>> >>> of > >> >>> >>> your file? Or compiling with -3 (for Python 3 language > semantics)? > >> >>> >>> > >> >>> >>> -- > >> >>> >>> > >> >>> >>> --- > >> >>> >>> You received this message because you are subscribed to the > Google > >> >>> >>> Groups > >> >>> >>> "cython-users" group. > >> >>> >>>
Re: [Cython] call for contribution: PEP 498 - Literal String Interpolation
Hello, I would like to give a look on that on my spare time. On 5 Sep 2015 20:32, "Stefan Behnel" wrote: Hi! It looks like PEP 498 (f-strings) is going to be accepted soon. Anyone interested in implementing it for Cython? https://www.python.org/dev/peps/pep-0498/ It's certainly a bit of work, but it's also very much Python-level functionality and most of it can be handled in the parser, so I would count it as an entry-level project for working on Cython. There is already an initial implementation for CPython (in C) which should provide an answer to the tricky details of the functionality itself, as well as tests for it (eventually). https://bugs.python.org/issue24965 So, if this feature, and if extending the Cython language and working on a real compiler sounds tempting to you, please speak up on the cython-devel mailing list. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] call for contribution: PEP 498 - Literal String Interpolation
Fabrizio Messina schrieb am 07.09.2015 um 12:23: > On 5 Sep 2015 20:32, "Stefan Behnel" wrote: >> It looks like PEP 498 (f-strings) is going to be accepted soon. Anyone >> interested in implementing it for Cython? >> >> https://www.python.org/dev/peps/pep-0498/ >> >> It's certainly a bit of work, but it's also very much Python-level >> functionality and most of it can be handled in the parser, so I would count >> it as an entry-level project for working on Cython. There is already an >> initial implementation for CPython (in C) which should provide an answer to >> the tricky details of the functionality itself, as well as tests for it >> (eventually). >> >> https://bugs.python.org/issue24965 >> >> So, if this feature, and if extending the Cython language and working on a >> real compiler sounds tempting to you, please speak up on the cython-devel >> mailing list. > > Hello, I would like to give a look on that on my spare time. Cool. If you need any help or have any questions, just reply to this thread. Here's an intro to get you started. It explains how the test suite works and how you can figure out how the C code you see is being generated. https://github.com/cython/cython/wiki/HackerGuide#getting-started Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
