Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)
On Sun, 17 Nov 2013 18:04:43 +1100 Steven D'Aprano wrote: > On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou wrote: > > > I agree that conflating the two doesn't help the discussion. > > While removing docstrings may be beneficial on memory-constrained > > devices, I can't remember a single situation where I've wanted to > > remove asserts on a production system. > > > > (I also tend to write less and less asserts in production code, since > > all of them tend to go in unit tests instead, with the help of e.g. > > mock objects) > > I'm the opposite. I like using asserts in my code, and while I don't > *typically* run it with -O, I do think it is valuable to have to > opportunity to remove asserts. I've certainly written code where -O has > given a major micro-optimization of individual functions (anything up to > 50% speedup). I've never measured if that lead to a significant > whole-application speedup, but I assume that was some benefit. (I know, > premature optimization and all that...) So you assumed there was some benefit, but you never used it anyway? 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] (#19562) Asserts in Python stdlib code (datetime.py)
On Sun, Nov 17, 2013 at 11:00:50AM +0100, Antoine Pitrou wrote: > On Sun, 17 Nov 2013 18:04:43 +1100 > Steven D'Aprano wrote: > > On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou wrote: > > > > > I agree that conflating the two doesn't help the discussion. > > > While removing docstrings may be beneficial on memory-constrained > > > devices, I can't remember a single situation where I've wanted to > > > remove asserts on a production system. > > > > > > (I also tend to write less and less asserts in production code, since > > > all of them tend to go in unit tests instead, with the help of e.g. > > > mock objects) > > > > I'm the opposite. I like using asserts in my code, and while I don't > > *typically* run it with -O, I do think it is valuable to have to > > opportunity to remove asserts. I've certainly written code where -O has > > given a major micro-optimization of individual functions (anything up to > > 50% speedup). I've never measured if that lead to a significant > > whole-application speedup, but I assume that was some benefit. (I know, > > premature optimization and all that...) > > So you assumed there was some benefit, but you never used it anyway? I had a demonstrable non-trivial speedup when timing individual functions. At the time I considered that "good enough". If you want to call that "premature optimization", I can't entirely disagree, but can you honestly say you've never done the same? Optimize a function to make it run faster, even if you have no proof that it was a bottleneck in the your application? -- Steven ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
On Sun, 17 Nov 2013 21:27:24 +1100 Steven D'Aprano wrote: > On Sun, Nov 17, 2013 at 11:00:50AM +0100, Antoine Pitrou wrote: > > On Sun, 17 Nov 2013 18:04:43 +1100 > > Steven D'Aprano wrote: > > > On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou wrote: > > > > > > > I agree that conflating the two doesn't help the discussion. > > > > While removing docstrings may be beneficial on memory-constrained > > > > devices, I can't remember a single situation where I've wanted to > > > > remove asserts on a production system. > > > > > > > > (I also tend to write less and less asserts in production code, since > > > > all of them tend to go in unit tests instead, with the help of e.g. > > > > mock objects) > > > > > > I'm the opposite. I like using asserts in my code, and while I don't > > > *typically* run it with -O, I do think it is valuable to have to > > > opportunity to remove asserts. I've certainly written code where -O has > > > given a major micro-optimization of individual functions (anything up to > > > 50% speedup). I've never measured if that lead to a significant > > > whole-application speedup, but I assume that was some benefit. (I know, > > > premature optimization and all that...) > > > > So you assumed there was some benefit, but you never used it anyway? > > I had a demonstrable non-trivial speedup when timing individual > functions. At the time I considered that "good enough". If you want to > call that "premature optimization", I can't entirely disagree, but can > you honestly say you've never done the same? You didn't answer my question: did you actually use -OO in production, or not? Saying that -OO could have helped you optimize something you didn't care about isn't a very strong argument for -OO :) What I would like to know is if people *knowingly* add costly asserts to performance-critical code, with the intent of disabling them at runtime using -OO. (in Python, that is, I know people do that in C where the programming culture and tools are different) 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] (#19562) Asserts in Python stdlib code (datetime.py)
On Sun, Nov 17, 2013 at 11:35:21AM +0100, Antoine Pitrou wrote: > You didn't answer my question: did you actually use -OO in production, > or not? Saying that -OO could have helped you optimize something you > didn't care about isn't a very strong argument for -OO :) Ah, sorry, I misunderstood your question. I didn't use -OO, since I had no reason to remove docstrings. But I did use -O to remove asserts. I was talking about assertions, not docstrings. Since I haven't had to write code for embedded devices with severely constrained memory, I've never cared about using -OO in production. > What I would like to know is if people *knowingly* add costly asserts > to performance-critical code, with the intent of disabling them at > runtime using -OO. Yes, I have knowingly added costly asserts to code with the intend of disabling them at runtime. Was it *performance-critical* code? I don't know, that was the point of my earlier rambling -- I could demonstrate a speedup of the individual functions in benchmarks, but nobody spent the effort to determine which functions were performance critical. -- Steven ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
Le 17/11/2013 12:27, Steven D'Aprano a écrit : What I would like to know is if people *knowingly* add costly asserts to performance-critical code, with the intent of disabling them at runtime using -OO. Yes, I have knowingly added costly asserts to code with the intend of disabling them at runtime. Was it *performance-critical* code? I don't know, that was the point of my earlier rambling -- I could demonstrate a speedup of the individual functions in benchmarks, but nobody spent the effort to determine which functions were performance critical. Hi, my 2 cents: asserts have been of a great help in the robustness of our provisioning framework, these are like tests embedded in code, to *consistently* check what would be VERY hard to test from the outside, from unit-tests. It makes us gain much time when we develop, because asserts (often used for "method contract checking") immediately break stuffs if we make dumb programming errors, like giving the wrong type of variable as parameter etc. (if you send a string instead of a list of strings to a method, it could take a while before the errors gets noticed, since their behaviour is quite close) We also add asserts with very expensive operations (like fully checking the proper synchronization of our DBs with the mockups of remote partners, after each provisioning command treated), so that we don't need to call something like that after every line of unit-test we write. In production, we then make sure we use -O flag to avoid doubling our treatments times and traffic. regards, Pascal ___ 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] Mixed up core/module source file locations in CPython
On Sat, Nov 16, 2013 at 3:44 PM, Brett Cannon wrote: > > > > On Sat, Nov 16, 2013 at 1:40 PM, Eric Snow wrote: > >> If you look at the Python and Modules directories in the cpython repo, >> you'll find modules in Python/ and core files (like python.c and >> main.c) in Modules/. (It's like parking on a driveway and driving on >> a parkway. ) It's not that big a deal and not that hard to >> figure out (so I'm fine with the status quo), but it is a bit >> surprising. When I was first getting familiar with the code base a >> few years ago (as a C non-expert), it was a not insignificant but not >> major stumbling block. >> >> The situation is mostly a consequence of history, if I understand >> correctly. The subject has come up before and I don't recall any >> objections to doing something about it. I haven't had the time to >> track down those earlier discussions, though I remember Benjamin >> having some comment about it. >> >> Would it be too disruptive (churn, etc.) to clean this up in 3.5? I >> see it similarly to when I moved a light switch from outside my >> bathroom to inside. For a while, but not that long, I kept >> unconsciously reaching for the switch that was no longer there on the >> outside. Regardless I'm glad I did it. Likewise, moving the handful >> of files around is a relatively inconsequential change that would make >> the project just a little less surprising, particularly for new >> contributors. >> >> -eric >> >> p.s. Either way I'll probably take some time (it shouldn't take long) >> after the PEP 451 implementation is done to put together a patch that >> moves the files around, just to see what difference it makes. >> > > I personally think it would be a good idea to re-arrange the files to make > things more beginner-friendly. I believe Nick was also talking about > renaming directories, etc. at some point. > If we're concerned with the beginner-friendliness of our source layout, I'll have to mention that I have a full ASDL parser lying around that's written in Python 3.4 (enums!) without using Spark. So that's one less custom tool to carry around with Python, less files and less LOCs in general. Just sayin' ;-) Eli ___ 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] Mixed up core/module source file locations in CPython
On Nov 17, 2013 8:58 AM, "Eli Bendersky" wrote: > > > > > On Sat, Nov 16, 2013 at 3:44 PM, Brett Cannon wrote: >> >> >> >> >> On Sat, Nov 16, 2013 at 1:40 PM, Eric Snow wrote: >>> >>> If you look at the Python and Modules directories in the cpython repo, >>> you'll find modules in Python/ and core files (like python.c and >>> main.c) in Modules/. (It's like parking on a driveway and driving on >>> a parkway. ) It's not that big a deal and not that hard to >>> figure out (so I'm fine with the status quo), but it is a bit >>> surprising. When I was first getting familiar with the code base a >>> few years ago (as a C non-expert), it was a not insignificant but not >>> major stumbling block. >>> >>> The situation is mostly a consequence of history, if I understand >>> correctly. The subject has come up before and I don't recall any >>> objections to doing something about it. I haven't had the time to >>> track down those earlier discussions, though I remember Benjamin >>> having some comment about it. >>> >>> Would it be too disruptive (churn, etc.) to clean this up in 3.5? I >>> see it similarly to when I moved a light switch from outside my >>> bathroom to inside. For a while, but not that long, I kept >>> unconsciously reaching for the switch that was no longer there on the >>> outside. Regardless I'm glad I did it. Likewise, moving the handful >>> of files around is a relatively inconsequential change that would make >>> the project just a little less surprising, particularly for new >>> contributors. >>> >>> -eric >>> >>> p.s. Either way I'll probably take some time (it shouldn't take long) >>> after the PEP 451 implementation is done to put together a patch that >>> moves the files around, just to see what difference it makes. >> >> >> I personally think it would be a good idea to re-arrange the files to make things more beginner-friendly. I believe Nick was also talking about renaming directories, etc. at some point. > > > If we're concerned with the beginner-friendliness of our source layout, I'll have to mention that I have a full ASDL parser lying around that's written in Python 3.4 (enums!) without using Spark. So that's one less custom tool to carry around with Python, less files and less LOCs in general. Just sayin' ;-) Then stop saying and check it in (or at least open a big for it). :) > > Eli > ___ 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] Mixed up core/module source file locations in CPython
On Sun, Nov 17, 2013 at 6:20 AM, Brett Cannon wrote: > > On Nov 17, 2013 8:58 AM, "Eli Bendersky" wrote: > > > > > > > > > > On Sat, Nov 16, 2013 at 3:44 PM, Brett Cannon wrote: > >> > >> > >> > >> > >> On Sat, Nov 16, 2013 at 1:40 PM, Eric Snow > wrote: > >>> > >>> If you look at the Python and Modules directories in the cpython repo, > >>> you'll find modules in Python/ and core files (like python.c and > >>> main.c) in Modules/. (It's like parking on a driveway and driving on > >>> a parkway. ) It's not that big a deal and not that hard to > >>> figure out (so I'm fine with the status quo), but it is a bit > >>> surprising. When I was first getting familiar with the code base a > >>> few years ago (as a C non-expert), it was a not insignificant but not > >>> major stumbling block. > >>> > >>> The situation is mostly a consequence of history, if I understand > >>> correctly. The subject has come up before and I don't recall any > >>> objections to doing something about it. I haven't had the time to > >>> track down those earlier discussions, though I remember Benjamin > >>> having some comment about it. > >>> > >>> Would it be too disruptive (churn, etc.) to clean this up in 3.5? I > >>> see it similarly to when I moved a light switch from outside my > >>> bathroom to inside. For a while, but not that long, I kept > >>> unconsciously reaching for the switch that was no longer there on the > >>> outside. Regardless I'm glad I did it. Likewise, moving the handful > >>> of files around is a relatively inconsequential change that would make > >>> the project just a little less surprising, particularly for new > >>> contributors. > >>> > >>> -eric > >>> > >>> p.s. Either way I'll probably take some time (it shouldn't take long) > >>> after the PEP 451 implementation is done to put together a patch that > >>> moves the files around, just to see what difference it makes. > >> > >> > >> I personally think it would be a good idea to re-arrange the files to > make things more beginner-friendly. I believe Nick was also talking about > renaming directories, etc. at some point. > > > > > > If we're concerned with the beginner-friendliness of our source layout, > I'll have to mention that I have a full ASDL parser lying around that's > written in Python 3.4 (enums!) without using Spark. So that's one less > custom tool to carry around with Python, less files and less LOCs in > general. Just sayin' ;-) > > Then stop saying and check it in (or at least open a big for it). :) > I'll clean it up and will open an issue. This shouldn't be a problem w.r.t. the beta freeze since it's not a user-visible thing, and its validation is trivial given that we can compare the output files produced. Eli ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
2013/11/16 Maciej Fijalkowski : > Can I see some writeup how -OO benefit embedded devices? You get smaller .pyc files. In an embedded device, the whole OS may be written in a small memory, something like 64 MB or smaller. Removing doctrings help to fit in 64 MB. I don't know if dropping "assert" statements is required on embedded device. Victor ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
On Saturday, November 16, 2013, Steven D'Aprano wrote: > On Sat, Nov 16, 2013 at 11:16:48AM -0500, Donald Stufft wrote: > > Personally I think that none of the -O* should be removing asserts. It > feels > > like a foot gun to me. I’ve seen more than one codebase that would be > > completely broken under -O* because they used asserts without even > knowing > > -O* existed. > > I agree that many people misuse asserts. I agree that this is a problem > for them. But I disagree that the solution is to remove what I consider > to be a useful feature, and a common one in other languages, just to > protect people from their broken code. > > I prefer to see better efforts to educate them. To that end, I've taken > the liberty of sending a post to python-l...@python.org > describing when > to use asserts, and when not to use them: > > https://mail.python.org/pipermail/python-list/2013-November/660401.html Nice post! > I will continue to use my best effort to encourage good use of > assertions in Python. Thank you! --Guido > > -- --Guido van Rossum (on iPad) ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
I believe the point of removing assertions is also to avoid throwing unhandled developper errors to end-user and not only "performance". It's like "raise" without "try" block. It's certainly because I consider "assert" as a developper util, providing a concrete documentation about methods signatures. In this idea I've made a small bench to determine if it is interesting for an assertion lib to have null functions as default. https://github.com/apieum/BenchAssert I don't make critical performance applications but still doubt of the real interest of having dead code to better document. 2013/11/17 Steven D'Aprano > On Sun, Nov 17, 2013 at 11:35:21AM +0100, Antoine Pitrou wrote: > > > You didn't answer my question: did you actually use -OO in production, > > or not? Saying that -OO could have helped you optimize something you > > didn't care about isn't a very strong argument for -OO :) > > Ah, sorry, I misunderstood your question. > > I didn't use -OO, since I had no reason to remove docstrings. But I did > use -O to remove asserts. I was talking about assertions, not > docstrings. Since I haven't had to write code for embedded devices with > severely constrained memory, I've never cared about using -OO in > production. > > > > What I would like to know is if people *knowingly* add costly asserts > > to performance-critical code, with the intent of disabling them at > > runtime using -OO. > > Yes, I have knowingly added costly asserts to code with the intend of > disabling them at runtime. Was it *performance-critical* code? I don't > know, that was the point of my earlier rambling -- I could demonstrate a > speedup of the individual functions in benchmarks, but nobody spent the > effort to determine which functions were performance critical. > > > > -- > Steven > ___ > 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/apieum%40gmail.com > ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
On Sun, 17 Nov 2013 17:14:38 +0100, Victor Stinner wrote: > 2013/11/16 Maciej Fijalkowski : > > Can I see some writeup how -OO benefit embedded devices? > > You get smaller .pyc files. In an embedded device, the whole OS may be > written in a small memory, something like 64 MB or smaller. Removing > doctrings help to fit in 64 MB. > > I don't know if dropping "assert" statements is required on embedded device. I've worked on a project (mobile platform) where both of these were true. Did we gain much by dropping asserts? As with Steve's case, no one bothered to measure, but it was a no-brainer win so we did it. Especially since we really needed to kill the docstrings to save memory. (Killing linecache was an even bigger win on the memory side). I unfortunately don't remember how much difference removing docstrings made in the process size, but I'm pretty sure it was more than a MB, and on a device with no swap in a process that must be running all the time, even 1MB makes a significant difference. On the assert side, if there hadn't been an option to remove the asserts, I'm sure that the call would have come down to manually remove all the asserts for production, which would have been a pain. In that case they *might* have measured, but since you'd have to do the removal work to do the measurement, they'd probably not have bothered. I'd say that if someone wants to drop assert removal, they'd need to prove that it *didn't* result in a speedup, which would be pretty hard considering that the checks covered by assert/if __debug__ can be arbitrarily complex :) But...yes, it would have been nice to have been able to remove docstrings and asserts *separately*. We might have measured the delta and decided to keep them in the beta in that case, since the asserts did catch some bugs. --David ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
On Nov 17, 2013, at 05:14 PM, Victor Stinner wrote: >2013/11/16 Maciej Fijalkowski : >> Can I see some writeup how -OO benefit embedded devices? > >You get smaller .pyc files. In an embedded device, the whole OS may be >written in a small memory, something like 64 MB or smaller. Removing >doctrings help to fit in 64 MB. I'm in support of separate flags for stripping docstrings and asserts. I'd even be fine with eliminating a flag to strip docstrings if we had a post-processing tool that you could apply to pyc files to strip out the docstrings. Another problem that I had while addressing these options in Debian was the use of .pyo for both -O and -OO level. -Barry ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
On Sun, Nov 17, 2013 at 9:02 PM, Barry Warsaw wrote: > On Nov 17, 2013, at 05:14 PM, Victor Stinner wrote: > >>2013/11/16 Maciej Fijalkowski : >>> Can I see some writeup how -OO benefit embedded devices? >> >>You get smaller .pyc files. In an embedded device, the whole OS may be >>written in a small memory, something like 64 MB or smaller. Removing >>doctrings help to fit in 64 MB. > > I'm in support of separate flags for stripping docstrings and asserts. I'd > even be fine with eliminating a flag to strip docstrings if we had a > post-processing tool that you could apply to pyc files to strip out the > docstrings. Another problem that I had while addressing these options in > Debian was the use of .pyo for both -O and -OO level. > > -Barry > ___ > 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/fijall%40gmail.com My problem with -O and -OO is that their arguments are very circular. Indeed, I understand the need why you would want in certain and limited cases to remove both docstrings and asserts. So some options for doing so are ok. But a lot of arguments I see are along the lines of "don't use asserts because -O removes them". If the option was named --remove-asserts, noone would care, but people care since -O is documented as "do optimizations" and people *assume* this is what it does (makes code faster) and as unintended consequence removes asserts. Cheers, fijal ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
Gregory Salvan wrote: I believe the point of removing assertions is also to avoid throwing unhandled developper errors to end-user I'm not sure I buy that. An assert is saying that something should never happen. If it does happen, either it's going to lead to an exception further down the track, or produce incorrect results. In the first case, you've failed to shield the user from exceptions; in the second, better to log an exception than silently pretend nothing has gone wrong. -- Greg ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
On Sun, Nov 17, 2013 at 1:05 PM, Maciej Fijalkowski wrote: > My problem with -O and -OO is that their arguments are very circular. > Indeed, I understand the need why you would want in certain and > limited cases to remove both docstrings and asserts. So some options > for doing so are ok. But a lot of arguments I see are along the lines > of "don't use asserts because -O removes them". If the option was > named --remove-asserts, noone would care, but people care since -O is > documented as "do optimizations" and people *assume* this is what it > does (makes code faster) and as unintended consequence removes > asserts. > It's circular indeed (and not just the shape of the letter :-). I expect that if there was a separate --remove-asserts option, people would write essential asserts and just claim "don't turn off asserts when using this code". But that's just wrong because such an option (whether named -O or --remove-asserts) is a global choice not under control of the author of the program. The correct rule should be "don't use assert (the statement) to check for valid user input" and the stated reason should be that the assert statement was *designed* to be disabled globally, not to be a shorthand for "if not X: raise (mumble) Y". A corollary should also be that unittests should not use the assert statement; some frameworks sadly encourage the anti-pattern of using it in tests. (There are valid reasons to want to run unittests with -O or -OO: for example, to validate that the code does not depend on side effects of assert statements. If there was a --remove-asserts option, running unittests with that option would be similarly useful.) That said I think our man page and --help output could be more forthcoming about this implication of "optimize". (The language reference is quite clear about it.) -- --Guido van Rossum (python.org/~guido) ___ 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] NTPath or WindowsPath?
On Sat, Nov 16, 2013 at 2:50 PM, Serhiy Storchaka wrote: > 16.11.13 21:15, Antoine Pitrou написав(ла): > >> In a (private) discussion about PEP 428 and pathlib, Guido proposed >> that maybe NTPath should be renamed to WindowsPath, since the name is >> more likely to stay relevant in the middle term. What do you think? > > > What about nturl2path, os.name, sysconfig.get_scheme_names()? What about them? ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
17.11.2013 23:05, Guido van Rossum wrote: The correct rule should be "don't use assert (the statement) to check for valid user input" and the stated reason should be that the assert statement was *designed* to be disabled globally, not to be a shorthand for "if not X: raise (mumble) Y". A corollary should also be that unittests should not use the assert statement; some frameworks sadly encourage the anti-pattern of using it in tests. My problem with -O (and -OO) is that even though my code is valid (in terms of the rule 'use assert only for should-never-happen cases') I have no control over 3rd party library code: I can never know whether doesn't it break if I turn -O or -OO on (as long as I do not analyze carefully the code of the libraries I use, including writing regression tests [for 3rd party code]...). Woudln't it to be useful to add possibility to place an "optimisation cookie" (syntactically analogous to "encoding cookie") at the beginning of each of my source files (when I know they are "-O"-safe), e.g.: # -*- opt: asserts -*- or even combined with an encoding cookie: # -*- coding: utf-8; opt: asserts, docstrings -*- Then: * The -O flag would be effectively applied *only* to a file containing such a cookie and *exactly* according to the cookie content (whether asserts, whether docstrings...). * Running without -O/-OO would mean ignoring optimisation cookies. * The -OO flag would mean removing both asserts and docstrings (i.e. the status quo of -OO). * Fine-grained explicit command line flags such as --remove-asserts and --remove-docstings could also be useful. (Of course, the '-*-' fragments in the above examples are purely conventional; the actual regex would not include them as it does not include them now for encoding cookies.) Cheers. *j ___ 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] (#19562) Asserts in Python stdlib code (datetime.py)
On Nov 17, 2013, at 11:05 PM, Maciej Fijalkowski wrote: >My problem with -O and -OO is that their arguments are very circular. >Indeed, I understand the need why you would want in certain and >limited cases to remove both docstrings and asserts. So some options >for doing so are ok. But a lot of arguments I see are along the lines >of "don't use asserts because -O removes them". If the option was >named --remove-asserts, noone would care, but people care since -O is >documented as "do optimizations" and people *assume* this is what it >does (makes code faster) and as unintended consequence removes >asserts. The reason I want to split them is more because I'd like an option to remove docstrings but not asserts. As others have also said, I use asserts for conditions that can't possibly happen (or so I think). E.g. using an if/elif on an enumeration where the else should never be hit. Or saying that after some calculation, this variable can never be None. In a sense, assertions are executable documentation about the state of behavior at a particular line of code. If an assert ever *does* get triggered, it means you didn't understand what you wrote. -Barry signature.asc Description: PGP signature ___ 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] Accepting PEP 3154 for 3.4?
[Antoine Pitrou]
> Alexandre Vassalotti (thanks a lot!) has recently finalized his work on
> the PEP 3154 implementation - pickle protocol 4.
>
> I think it would be good to get the PEP and the implementation accepted
> for 3.4. As far as I can say, this has been a low-controvery proposal,
> and it brings fairly obvious improvements to the table (which table?).
> I still need some kind of BDFL or BDFL delegate to do that, though --
> unless I am allowed to mark my own PEP accepted :-)
Try it and see whether anyone complains ;-)
I like it. I didn't review the code, but the PEP addresses real
issues, and the solutions look good on paper ;-)
One thing I wonder about: I don't know that non-seekable pickle
streams are important use cases, but am willing to be told that they
are. In which case, framing is a great idea.
But I wonder why it isn't done with a new framing opcode instead (say,
FRAME followed by 8-byte count). I suppose that would be like the
"prefetch" idea, except that framing opcodes would be mandatory
(instead of optional) in proto 4. Why I initially like that:
- Uniform decoding loop ("the next thing" _always_ starts with an opcode).
- Some easy sanity checking due to the tiny redundancy (if the byte
immediately following the current frame is not a FRAME opcode, the
pickle is corrupt; and also corrupt if a FRAME opcode is encountered
_inside_ the current frame).
When slinging 8-byte counts, _some_ sanity-checking seems like a good idea ;-)
___
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
