[Python-Dev] Build is broken for me after updating
Ever since I updated, I am getting: In file included from Objects/dictobject.c:236:0: Objects/clinic/dictobject.c.h:70:26: fatal error: stringlib/eq.h: No such file or directory #include "stringlib/eq.h" But, Objects/stringlib/eq.h exists. Replacing the include with "Objects/stringlib/eq.h" seems to make this error go away, but others follow. Would anyone happen to know why this is happening? Neil ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 448 review
Hello, Following up with PEP 448, I've gone over the entire code review except a few points as mentioned at the issue: http://bugs.python.org/review/2292/. I'm hoping that this will get done at the PyCon sprints. Is there any way I can help? I couldn't make it to PyCon, but I do live in Montreal. I would be more than happy to make time to meet up with anyone who wants to help with the review, e.g. Laika's usually a good place to work and have a coffee ( http://www.yelp.ca/biz/la%C3%AFka-montr%C3%A9al-2). Code reviews tend go much faster face-to-face. Also, I'm definitely interested in meeting any Python developers for coffee or drinks. I know the city pretty well. :) Best, Neil On Tue, Mar 17, 2015 at 9:49 AM, Brett Cannon wrote: > > > On Mon, Mar 16, 2015 at 7:11 PM Neil Girdhar > wrote: > >> Hi everyone, >> >> I was wondering what is left with the PEP 448 ( >> http://bugs.python.org/issue2292) code review? Big thanks to Benjamin, >> Ethan, and Serhiy for reviewing some (all?) of the code. What is the next >> step of this process? >> > > My suspicion is that if no one steps up between now and PyCon to do a > complete code review of the final patch, we as a group will try to get it > done at the PyCon sprints. I have made the issue a release blocker to help > make sure it gets reviewed and doesn't accidentally get left behind. > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 update
On Tue, 07 Apr 2015 03:11:30 +0100 Rob Cliffe wrote: > > On 07/04/2015 02:08, Guido van Rossum wrote: > > I've taken the liberty of adding the following old but good rule to > > PEP 8 (I was surprised to find it wasn't already there since I've > > lived by this for ages): > > > > * > > > > Be consistent in return statements. Either all return statements > > in a function should return an expression, or none of them should. > > If any return statement returns an expression, any return > > statements where no value is returned should explicitly state this > > asreturn None, and an explicit return statement should be present > > at the end of the function (if reachable). > > > > Yes: > > > > def foo(x): > > if x >= 0: > > return math.sqrt(x) > > else: > > return None > > > That would seem to be good style and common sense. > > As a matter of interest, how far away from mainstream am I in > preferring, *in this particular example* (obviously it might be > different for more complicated computation), > > def foo(x): > return math.sqrt(x) if x >= 0 else None I agree with you on this. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 update
> My own preference would be: > > def foo(x): > if x >= 0: > return math.sqrt(x) > return None Kind of getting into the weeds here, but I would always invert this to "return errors early, and keep the normal flow at the main indentation level". Depends a little on what foo() means, but it seems to me the "return None" case is the exceptional/error case, so this would be: def foo(x): if x < 0: return None return math.sqrt(x) The handling of errors is done first, and the normal case stays at the main indentation level. Is this discussed in style guides at all? I don't see anything directly in PEP 8, but I might be missing something. Oh wait, I just noticed this is exactly how Guido has it in his PEP addition with the definition of bar(). :-| -Ben ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 448 review
On 7 Apr 2015 03:43, "Neil Girdhar" wrote: > > Hello, > > Following up with PEP 448, I've gone over the entire code review except a few points as mentioned at the issue: http://bugs.python.org/review/2292/. I'm hoping that this will get done at the PyCon sprints. Is there any way I can help? > > I couldn't make it to PyCon, but I do live in Montreal. I would be more than happy to make time to meet up with anyone who wants to help with the review, e.g. Laika's usually a good place to work and have a coffee ( http://www.yelp.ca/biz/la%C3%AFka-montr%C3%A9al-2). Code reviews tend go much faster face-to-face. My understanding is that it's possible to register for the post-PyCon sprints, even if you're not attending PyCon itself. Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 update
Antoine Pitrou schrieb am 07.04.2015 um 14:26: > On Tue, 07 Apr 2015 03:11:30 +0100 > Rob Cliffe wrote: >> >> On 07/04/2015 02:08, Guido van Rossum wrote: >>> I've taken the liberty of adding the following old but good rule to >>> PEP 8 (I was surprised to find it wasn't already there since I've >>> lived by this for ages): >>> >>> * >>> >>> Be consistent in return statements. Either all return statements >>> in a function should return an expression, or none of them should. >>> If any return statement returns an expression, any return >>> statements where no value is returned should explicitly state this >>> asreturn None, and an explicit return statement should be present >>> at the end of the function (if reachable). >>> >>> Yes: >>> >>> def foo(x): >>> if x >= 0: >>> return math.sqrt(x) >>> else: >>> return None >>> >> That would seem to be good style and common sense. >> >> As a matter of interest, how far away from mainstream am I in >> preferring, *in this particular example* (obviously it might be >> different for more complicated computation), >> >> def foo(x): >> return math.sqrt(x) if x >= 0 else None > > I agree with you on this. +1, the ternary operator reads best when there is a "normal" case that can go first and a "special" or "unusual" case that can go last and does not apply under the (given) normal conditions. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 update
Talk about hijacking an unrelated thread... :-( Though there's maybe a style rule for the ternary operator to be devised here? :-) On Apr 7, 2015 11:36 AM, "Stefan Behnel" wrote: > Antoine Pitrou schrieb am 07.04.2015 um 14:26: > > On Tue, 07 Apr 2015 03:11:30 +0100 > > Rob Cliffe wrote: > >> > >> On 07/04/2015 02:08, Guido van Rossum wrote: > >>> I've taken the liberty of adding the following old but good rule to > >>> PEP 8 (I was surprised to find it wasn't already there since I've > >>> lived by this for ages): > >>> > >>> * > >>> > >>> Be consistent in return statements. Either all return statements > >>> in a function should return an expression, or none of them should. > >>> If any return statement returns an expression, any return > >>> statements where no value is returned should explicitly state this > >>> asreturn None, and an explicit return statement should be present > >>> at the end of the function (if reachable). > >>> > >>> Yes: > >>> > >>> def foo(x): > >>> if x >= 0: > >>> return math.sqrt(x) > >>> else: > >>> return None > >>> > >> That would seem to be good style and common sense. > >> > >> As a matter of interest, how far away from mainstream am I in > >> preferring, *in this particular example* (obviously it might be > >> different for more complicated computation), > >> > >> def foo(x): > >> return math.sqrt(x) if x >= 0 else None > > > > I agree with you on this. > > +1, the ternary operator reads best when there is a "normal" case that can > go first and a "special" or "unusual" case that can go last and does not > apply under the (given) normal conditions. > > Stefan > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ctypes module
Hi all, Not sure whether you got this question, or this is the right distribution list: Intel has deprecated Itanium architecture, and Windows also deprecated its versions(currently 2003 and 2008) that run on IA64. However Python (2.7.3) is compilable on Windows IA64, but ctypes module (1.1.0) which is now part of Python is not (the source files have been removed). What was the reason for its disablement? I am asking because an older version of ctypes (1.0.2) which came as a separate extension module (i used to compile it with Python 2.4.5) was available for WinIA64; i found (and fixed) a nasty buffer overrun in it. Regards, Cristi Fati. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 update
On Tue, Apr 07, 2015 at 08:47:25AM -0400, Ben Hoyt wrote: > > My own preference would be: > > > > def foo(x): > > if x >= 0: > > return math.sqrt(x) > > return None > > Kind of getting into the weeds here, but I would always invert this to > "return errors early, and keep the normal flow at the main indentation > level". Depends a little on what foo() means, but it seems to me the > "return None" case is the exceptional/error case, so this would be: > > def foo(x): > if x < 0: > return None > return math.sqrt(x) While *in general* I agree with "handle the error case early", there are cases where "handle the normal case early" is better, and I think that this is one of them. Also, inverting the comparison isn't appropriate, due to float NANs. With the first version, foo(NAN) returns None (which I assumed was deliberate by the OP). In your version, it returns NAN. But as you say, we're now deep into the weeds... -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
