Re: [Python-ideas] Fix some special cases in Fractions?
On 2018-08-30 06:39, Neil Girdhar wrote: I'd like these to be Fraction(1), Fraction(1), and Fraction(0). Why? I cannot think of any natural use case why you would want Fractions for a few special cases on an operation which returns non-Fractions generically. I consider it a feature to know in advance the type of the output of an operation, given the types of the input. Having an unexpected type suddenly show up because you happen to hit a special case is a recipe for bugs. Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Fix some special cases in Fractions?
Would there be any problem with changing: In [4]: Fraction(1, 1) ** Fraction(2, 3) Out[4]: 1.0 In [5]: Fraction(-1, 1) ** Fraction(2, 3) Out[5]: (-0.4998+0.8660254037844387j) In [6]: Fraction(0, 1) ** Fraction(2, 3) Out[6]: 0.0 I'd like these to be Fraction(1), Fraction(1), and Fraction(0). ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
On 08/29/2018 04:53 PM, Hugh Fisher wrote: From: Marko Ristin-Kaufmann: There seems to be evidence that design-by-contract is useful. Let me cite Bertrand Meyer from his article "Why not program right?" that I already mentioned before: I don't think that being useful by itself should be enough. I think new features should also be "Pythonic" and I don't see design by contract notation as a good fit. I don't see type annotation notation as a good fit, either, and yet we have it. Seems to me that DbC would be just as useful as type annotations (and I find D'Aprano's example syntax very readable). For design by contract, as others have noted Python assert statements work fine for simple preconditions and postconditions. And print statements work fine for simple debugging. New features are not added for the simple cases, but the complex, or non-obviously correct, or the very useful cases. Yes there's more to design by contract than simple assertions, but it's not just adding syntax. Meyer often uses the special "old" construct in his post condition examples, a trivial example being ensure count = old.count + 1 I can see where that could get expensive quickly. How do we do that in Python? And another part of design by contract (at least according to Meyer) is that it's not enough to just raise an exception, but there must be a guarantee that it is handled and the post conditions and/or invariants restored. Well, we don't have to have exactly the same kind of DbC as Eiffel does. -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] zipfile encryption function
Dear all, I would like to use zipfile encryption as python standard library. https://github.com/python/cpython/blob/master/Lib/zipfile.py Below document says "currently" cannot. https://github.com/python/cpython/blob/master/Doc/library/zipfile.rst "but it currently cannot create an encrypted file." Current pythonians like me have to use 3rd party like below, but I believe it is worth to include. https://pypi.org/project/pyminizip/ https://github.com/wllm-rbnt/py-zipcrypt please forgive me if someone have already suggested before. Thanks and Regards, -- Takahiro Ono ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
> Date: Thu, 30 Aug 2018 00:07:04 +0200
> From: Marko Ristin-Kaufmann
...
> I think we got entangled in a discussion about whether design-by-contract
> is useful or not. IMO, the personal experience ("I never used/needed this
> feature") is quite an inappropriate rule whether something needs to be
> introduced into the language or not.
>
> There seems to be evidence that design-by-contract is useful. Let me cite
> Bertrand Meyer from his article "Why not program right?" that I already
> mentioned before:
I don't think that being useful by itself should be enough. I think new features
should also be "Pythonic" and I don't see design by contract notation as a
good fit.
For example, C has the useful & operator which lets you pass as
a pointer/array argument despite foo being a scalar, so assignment to
bar[0] in the called function actually sets the value of foo. It might be
possible to create some kind of aliasing operator for Python so that two
or more variables were bound to the same location, but would we want
it? No, because Python is not intended for that style of programming.
For another example, GPU shading languages have the special keywords
uniform and varying for distinguishing definitions that won't change across
parallel invocations and definitions that will. Demonstrably very useful in
computer games and supercomputer number crunching, so why doesn't
Python have those keywords? Because it's not designed to be used for
such.
For design by contract, as others have noted Python assert statements
work fine for simple preconditions and postconditions. I don't see any
significant difference in readability between existing
def foo(x, y):
assert(x > 0)
# Do stuff
assert(x == y)
and new style
def foo(x, y):
require:
x > 0
# Do stuff
ensure:
x == y
Yes there's more to design by contract than simple assertions, but it's not
just adding syntax. Meyer often uses the special "old" construct in his post
condition examples, a trivial example being
ensure count = old.count + 1
How do we do that in Python? And another part of design by contract (at
least according to Meyer) is that it's not enough to just raise an exception,
but there must be a guarantee that it is handled and the post conditions
and/or invariants restored. So there's more syntax for "rescue" and "retry"
If you want to do simple pre and post conditions, Python already has assert.
If you want to go full design by contract, there's no law saying that Python
is the only programming language allowed. Instead of trying to graft new
and IMHO alien concepts onto Python, what's wrong with Eiffel?
--
cheers,
Hugh Fisher
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
On 8/29/2018 6:39 PM, Eric Fahlgren wrote: On Wed, Aug 29, 2018 at 3:07 PM Marko Ristin-Kaufmann mailto:marko.ris...@gmail.com>> wrote: Could you please elaborate a bit? I don't see how the annotations would make the contracts invoked on inheritance. Consider this simple case: class A: @icontract.pre(lambda x: x > 0) def some_method(self, x: int)->None: pass class B(A): # Precondition should be inherited here. def some_method(self, x: int) -> None: pass You would still need to somehow decorate manually the overridden methods even though you would not specify any new contracts, right? Is there a mechanism in Python that I am not aware of that would allow us to accomplish that? A metaclass does this pretty easily. I have a thing I wrote years ago called MIS (Multi-Inheritance Safety) that is used to ensure you don't do anything stupid in our physics-modeling database. The database is a collection of ~200 Python classes/mixins all deriving madly from each other to get various behaviors (Has mass? You'll need this. Has moments? You'll need this. Has physical extent, i.e., can be seen? You'll need these...). I think a metaclass is a non-starter. If one were used, it would preclude using contracts in any case where a metaclass were already used, or where one was needed in the future. I'm sure people will disagree with me on this. But, I think a more productive line of thinking is: what could be added to the language that would let contracts be implementable, and could also be used for other things, too? Sort of like how PEP 487 adds customizability that has wide applicability. Eric ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
replying to the list now... On Thu, 30 Aug 2018 at 00:11, Ivan Levkivskyi wrote: > On Wed, 29 Aug 2018 at 13:18, Steven D'Aprano wrote: > >> I didn't want to embarass Ivan any further by seemingly picking on his >> opinion about contracts being always statically checked, but when I >> asked off-list I got told to reword and post it here. So here it is. >> >> Sorry Ivan if this makes you feel I'm picking on you, that isn't my >> intention. >> > > NP, the discussion just shift more towards terminology etc. which is less > interesting TBH. > > -- > Ivan > > > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
The technique Eric suggests is probably better than what I had in mind. But I was thinking you could have an "inherit" decorator for methods (or for a class as a whole). It's easy enough for a decorator to attach a `.__contracts__` attribute to either the class or the individual methods. Then the decorator(s) in the child can simply look through the `.__mro__` to find any such parent contracts. E.g.: class B(A): @inherit_invariants def some_method(self, x: int) -> None: pass @precondition(lambda x: x=42, inherit_parent=True) def other_method(self, x: int) -> float: return 42/5 I'm not writing a library to do this, so you can tweak the API to be different than my example. But this is already well possible. On the broader idea: Is there any logical or empirical objection that the design-by-contract is not useful and hence does not merit to be introduced into the core language? There is little point in writing a PEP and fleshing out the details if the community will reject it on grounds that design-by-contract by itself is meaningless. Lots of people have explained this relative to lots of ideas, probably mostly better than I will. Adding a new feature, even if it is *technically* backwards compatible, has HUGE costs. All the documentation—the books, articles, blog posts, videos, webinars, tutorials, etc.—about Python has to be updated. We get a divide between "code that will work in Python 3.9" versus what will run in 3.7. The cognitive burden of learning Python is increased for everyone in the world (millions of people) because even if they do not use a feature they will encounter code that does. There is another section of code in the implementation(s) of Python that can potentially have bugs and needs to be maintained by someone. Obviously, design-by-contract is not *meaningless*! It's a specific feature that is relatively well defined as a concept (and precisely defined in regard to Eiffel specifically; but we might not implement those *exact* semantics). It's also a feature that no languages in particularly widespread use have decided to implement at the language level. I've chatted with Meyer; he's definitely very smart and definitely strongly opinionated, but I also think he's wrong about the overall importance of this feature versus lots of others. In my mind, this feature doesn't come close to meeting the burden of those high costs listed above (and others I did not mention). But I don't have any say in what the core developers will do, beyond in that they might be influenced by my opinion here. Yours, David... On Wed, Aug 29, 2018 at 6:41 PM Eric Fahlgren wrote: > On Wed, Aug 29, 2018 at 3:07 PM Marko Ristin-Kaufmann < > marko.ris...@gmail.com> wrote: > >> Could you please elaborate a bit? I don't see how the annotations would >> make the contracts invoked on inheritance. Consider this simple case: >> >> class A: >> @icontract.pre(lambda x: x > 0) >> def some_method(self, x: int)->None: >> pass >> >> class B(A): >> # Precondition should be inherited here. >> def some_method(self, x: int) -> None: >> pass >> >> You would still need to somehow decorate manually the overridden methods >> even though you would not specify any new contracts, right? Is there a >> mechanism in Python that I am not aware of that would allow us to >> accomplish that? >> > > A metaclass does this pretty easily. I have a thing I wrote years ago > called MIS (Multi-Inheritance Safety) that is used to ensure you don't do > anything stupid in our physics-modeling database. The database is a > collection of ~200 Python classes/mixins all deriving madly from each other > to get various behaviors (Has mass? You'll need this. Has moments? You'll > need this. Has physical extent, i.e., can be seen? You'll need these...). > > Anyhow, the basemost class has the metaclass, which traverses all the > methods in the subclasses and makes sure you don't have methods with the > same name in two distinct superclass trees and such things. It also forces > you to be explicit when you overload a method from a base class (among > other things, but this one is easy to illustrate). > > class MIS(type): > def __init__(cls, name, bases, namespace): > mro = cls.mro()[1:-1] # All the stuff between new class and > 'object' > for method_name, method in namespace.items(): > if isinstance(method, executable_types): > if not getattr(method, '_its_ok', False): > # Make sure it's not in any baser class. > # Could easily check for decorated pre/post properties and > copy them... > > def override(func): > # Mark the function as a valid override... > func._its_ok = True > return func > > class Base(metaclass=MIS): > def something(self): > pass > > class Derived(Base): > @override # Signal that this is ok, otherwise we get an error. > def
Re: [Python-ideas] Pre-conditions and post-conditions
Jonathan Fine wrote: My message of support for Ivan quoted the Eiffel docs. https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions During development and testing, assertion monitoring should be turned on at the highest possible level. Combined with static typing and the immediate feedback of compilation techniques [...] this permits the development process [...] where errors are exterminated at birth. I think you're misinterpreting the Eiffel docs here. It's saying that contracts *together* with static typing help to catch a lot of errors early in the development process. It's not saying that contracts are verified statically, or that all the errors thus caught are caught at compile time. the context to me makes it clear that in Eiffel static typing IS NOT regarded as a run-time assertion. That's true, but static typing and contracts are *different things* in Eiffel. Static types are checked at compile time, contracts are checked at run time. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
On Wed, Aug 29, 2018 at 02:26:54PM +0100, Jonathan Fine wrote: > This is about a difference of opinion regarding design by contract and > static checking, that Steve D'Aprano has re-raised. Steve wrote that > Ivan Levkivskyi's opinion was that: > > > contracts [are] always statically checked > > This is what Ivan wrote: > > > TBH, I think one of the main points of design by contract is that contracts > > are verified statically. > > There's no 'always' or 'all' here. I read it to mean 'sometimes' or > 'some'. And also, that static verification is a good thing. Fair enough, I should not have added "always" in my description. But you probably shouldn't have skipped the part I wrote earlier: "Contracts may be verified statically if the compiler is able to do so, but they are considered runtime checks. Static checks are an optimization." In context, you quoted me disagreeing with the "static" claim, but trimmed out my qualification that contracts may sometimes be statically verified when possible. [...] > > Ivan said that static checking was a main point. Those Eiffel docs which > > you (Jonathon) quoted approvingly describe them as "run-time > > assertions". > > I'm sorry, but I'm just not seeing that. Either in what I quoted, or > elsewhere in the page. True, my quote is from a section titled > "Run-time assertion monitoring", but the context to me makes it clear > that in Eiffel static typing IS NOT regarded as a run-time assertion. Of course it isn't. By definition, static typing is done *statically*, at compile-time, not run-time. That has not been questioned and nobody has asserted that static typing is done at run-time. We're discussing whether *contracts* are checked at run-time. Because contracts are (in general) run-time assertions, they are a good fit for Python's execution model -- or at least they would be if we can find a good way to apply contracts to methods and classes. If they were static, they would be a bad fit and would probably need to be handled by a separate static checker, like MyPy does for static type checks. -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
This is about a difference of opinion regarding design by contract and static checking, that Steve D'Aprano has re-raised. Steve wrote that Ivan Levkivskyi's opinion was that: > contracts [are] always statically checked This is what Ivan wrote: > TBH, I think one of the main points of design by contract is that contracts > are verified statically. There's no 'always' or 'all' here. I read it to mean 'sometimes' or 'some'. And also, that static verification is a good thing. My message of support for Ivan quoted the Eiffel docs. > https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions > During development and testing, assertion monitoring should > be turned on at the highest possible level. Combined with > static typing and the immediate feedback of compilation techniques > [...] this permits the development process [...] > where errors are exterminated at birth. I then wrote: > Based on the Eiffel docs, I find Ivan's opinion reasonable. Steve wrote: > Ivan said that static checking was a main point. Those Eiffel docs which > you (Jonathon) quoted approvingly describe them as "run-time > assertions". I'm sorry, but I'm just not seeing that. Either in what I quoted, or elsewhere in the page. True, my quote is from a section titled "Run-time assertion monitoring", but the context to me makes it clear that in Eiffel static typing IS NOT regarded as a run-time assertion. By the way, Steve wrote > when I asked off-list I got told to reword and post it here. I don't think that's quite right. What I said off-list to Steve was > If you post [...] to python-ideas, I'd be happy to respond there. It was my intention that it was up to Steve, whether or not to re-raise the issue. And now I'm doing my part of the bargain, by responding happily. I'm now happy to let this particular topic rest. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python-ideas Digest, Vol 141, Issue 145
On Wed, 29 Aug 2018 at 13:26, Steven D'Aprano wrote: > > [steve@ando ~]$ pip install numpy > Collecting numpy > /usr/local/lib/python3.5/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:315: > SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject > Name Indication) extension to TLS is not available on this platform. > This may cause the server to present an incorrect TLS certificate, which > can cause validation failures. For more information, see > https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning. > SNIMissingWarning > Could not fetch URL https://pypi.python.org/simple/numpy/: There was a > problem confirming the ssl certificate: [SSL: > TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:645) > - skipping > Could not find a version that satisfies the requirement numpy (from > versions: ) > No matching distribution found for numpy > > > I'm sure pip is great, but honestly I've never been able to get it to > work reliably, ever, on four different machines using four different > Linux distros. >From the "For more information" link above, that seems to be related to your SSL support. The link says it happens with Python older than 2.7.9, but you seem to be getting a Python 3.5 site-packages. Did you build Python yourself? Maybe you have an old version of openssl somewhere. I've not seen this sort of error come up commonly, so I suspect there's something particular to how you have your environment(s) set up. However... > In any case, the answer "just use Numpy" isn't really relevant to the > question about adding new syntax. Indeed. And nor is discussion about pip issues, so I'll leave it there. If you want help getting pip to work, I'd suggest raising an issue on the pip tracker. Paul. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python-ideas Digest, Vol 141, Issue 145
On Wed, 29 Aug 2018 at 13:17, Oscar Benjamin wrote: > Scipy (on Windows) is a different story. There are Windows (and other platform) wheels for scipy 1.1.0 on PyPI, so that's easy too :-) Paul ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python-ideas Digest, Vol 141, Issue 145
On Wed, Aug 29, 2018 at 01:15:46PM +0100, Oscar Benjamin wrote: > On Tue, 28 Aug 2018 at 08:12, Jacco van Dorp wrote: > > > > Op ma 27 aug. 2018 om 23:18 schreef James Lu : > >> > >> > As Matthew points out, you could use numpy.array. Or code your own > >> > class, by providing __add__ and __iadd__ methods. > >> > >> I could, but I don't think that justifies not having this functionality in > >> python > >> standard. From the language experience perspective, numpy is often a > >> pain to install on most systems. > > Numpy is easy to install: > > $ pip install numpy [steve@ando ~]$ pip install numpy Collecting numpy /usr/local/lib/python3.5/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning. SNIMissingWarning Could not fetch URL https://pypi.python.org/simple/numpy/: There was a problem confirming the ssl certificate: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:645) - skipping Could not find a version that satisfies the requirement numpy (from versions: ) No matching distribution found for numpy I'm sure pip is great, but honestly I've never been able to get it to work reliably, ever, on four different machines using four different Linux distros. In any case, the answer "just use Numpy" isn't really relevant to the question about adding new syntax. -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
I didn't want to embarass Ivan any further by seemingly picking on his opinion about contracts being always statically checked, but when I asked off-list I got told to reword and post it here. So here it is. Sorry Ivan if this makes you feel I'm picking on you, that isn't my intention. On Mon, Aug 27, 2018 at 12:25:44PM +0100, Jonathan Fine wrote: [..] > Based on the Eiffel docs, I find Ivan's opinion reasonable. He said it > was "one of the main points". The goal is to detect errors > immediately. Run-time assertion monitoring and static typing are two > means towards that end. Ivan said that static checking was a main point. Those Eiffel docs which you (Jonathon) quoted approvingly describe them as "run-time assertions". You describe them as "run-time assertions". I described them as "run-time assertions". So I'm having difficulty in understand what part of Ivan's opinion that they are compile-time static checks is "reasonable". If there's something I'm missing about Ivan's comment that you can see, I'd like to be enlightened. I don't see the relevance of the "two means towards that end" -- we have many means towards detecting bugs as early as possible: - correctness proofs - test-driven development - type checking - design by contract (and possibly more). If it was just a throw-away comment and I'm reading more into it than you intended, that's okay too, but I'd like to understand what you meant. > Our shared problem and goal is to have similar immediate detection of > errors in Python (when the development process requires that degree of > rigour). Well, yes, but what's that got to do with the question of whether contracts are checked statically or at runtime? -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python-ideas Digest, Vol 141, Issue 145
On Tue, 28 Aug 2018 at 08:12, Jacco van Dorp wrote: > > Op ma 27 aug. 2018 om 23:18 schreef James Lu : >> >> > As Matthew points out, you could use numpy.array. Or code your own >> > class, by providing __add__ and __iadd__ methods. >> >> I could, but I don't think that justifies not having this functionality in >> python >> standard. From the language experience perspective, numpy is often a >> pain to install on most systems. Numpy is easy to install: $ pip install numpy Should work on OSX, Windows and Linux. In all cases this should download a precompiled binary wheel. It used to be more difficult but improvements in packaging (wheels, manylinux etc) and the good work of the numpy folks have made this painless now. Scipy (on Windows) is a different story. -- Oscar ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
On Wed, Aug 29, 2018 at 09:23:02AM +0200, Jacco van Dorp wrote: > Op wo 29 aug. 2018 om 03:59 schreef Steven D'Aprano : > > > On Tue, Aug 28, 2018 at 07:46:02AM +0200, Marko Ristin-Kaufmann wrote: > > > Hi, > > > To clarify the benefits of the contracts, let me give you an example from > > > our code base: [snip long sequence of @decorator(lambda) calls] > > Thanks for your example Marko. I think that is quite close to the > > ugliest piece of Python code I've ever seen, and I don't mean that as a > > criticism of you for writing it or the icontract library's design. > > > > > What, really ? I said *close* :-) > Well, it clearly shows you teach python and don't look much > at code written by people who taught themselves. I didn't mean to compare it to code written by beginners. I meant professional quality. And I didn't mean it was *bad* code. Python is a remarkable elegant and pretty language, but there are some things that aren't a good fit to the existing syntax. Contracts are one. We can't easily write code in a declarative style like Prolog: sibling(X, Y) :- parent_child(Z, X), parent_child(Z, Y) (X is a sibling of Y when there exists some Z who is a parent of X and the same Z is the parent of Y); we have to re-write it in a procedural style. Some programming styles aren't a natural fit to a given syntax. > I taught myself, and the > first .py file I created was over a 1000 lines, and contained the GUI in a > 4-deep nested global dictionary, since I'd never seen a style guide at that > point. (I got better) So far, nothing you describe is *necessarily* ugly or bad code. The std lib contains at least one file well over 1000 lines, and while it is complex code, its not ugly code by any means. And I couldn't judge the elegance of the dict unless I saw it and the alternatives :-) -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
On Wed, Aug 29, 2018 at 05:52:46PM +1200, Greg Ewing wrote: > Wes Turner wrote: > >I'm going to re-write that in a pseudo-Eiffel like syntax: > > Maybe some magic could be done to make this work: > > def __init__(self, img: np.ndarray, x: int, y: int, width: int, > height: int) -> None: > > def __require__(): The problem with this idea is that methods and functions are not declarations, but executable code. This __require__ function doesn't exist except while the __init__ method is running. So it can't be called before the __init__, it can't be called *automatically* (you need to call it yourself, from inside the __init__), and it can't be inherited. Of course with sufficient compiler magic of course the compiler could special case these methods and do whatever we want, but that seems like it would be just as much work but much uglier than using dedicated syntax. -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
Op wo 29 aug. 2018 om 03:59 schreef Steven D'Aprano : > On Tue, Aug 28, 2018 at 07:46:02AM +0200, Marko Ristin-Kaufmann wrote: > > Hi, > > To clarify the benefits of the contracts, let me give you an example from > > our code base: > > > > @icontract.pre(lambda x: x >= 0) > > @icontract.pre(lambda y: y >= 0) > > @icontract.pre(lambda width: width >= 0) > > @icontract.pre(lambda height: height >= 0) > > @icontract.pre(lambda x, width, img: x + width <= > pqry.opencv.width_of(img)) > > @icontract.pre(lambda y, height, img: y + height <= > pqry.opencv.height_of(img)) > > @icontract.post(lambda self: (self.x, self.y) in self) > > @icontract.post(lambda self: (self.x + self.width - 1, self.y + > > self.height - 1) in self) > > @icontract.post(lambda self: (self.x + self.width, self.y + > > self.height) not in self) > > def __init__(self, img: np.ndarray, x: int, y: int, width: int, > > height: int) -> None: > > > Thanks for your example Marko. I think that is quite close to the > ugliest piece of Python code I've ever seen, and I don't mean that as a > criticism of you for writing it or the icontract library's design. > > What, really ? Well, it clearly shows you teach python and don't look much at code written by people who taught themselves. I taught myself, and the first .py file I created was over a 1000 lines, and contained the GUI in a 4-deep nested global dictionary, since I'd never seen a style guide at that point. (I got better) ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Pre-conditions and post-conditions
I've never used contracts, so excuse me if I didn't get how they would work, and what they should do. The last example is about pre-post conditions in a class constructor. But I imagine this is not the only case where one would want to define contracts, like probably: within methods that return something and to functions (and in both cases, we'd want to contractually state some of the return's specificities). Is the following function something someone used to work with contracts would write? def calculate(first: int, second: int) -> float: def __require__(): first > second second > 0 # or first > second > 0 ? def __ensure__(ret): # we automatically pass the return of the function to this one ret > 1 return first / second If so, having a reference to the function's output would probably be needed, as in the example above. Also, wouldn't someone who use contracts want the type hints he provided to be ensured without having to add requirements like `type(first) is int` or something? - Brice Le 29/08/2018 à 07:52, Greg Ewing a écrit : Wes Turner wrote: I'm going to re-write that in a pseudo-Eiffel like syntax: Maybe some magic could be done to make this work: def __init__(self, img: np.ndarray, x: int, y: int, width: int, height: int) -> None: def __require__(): x >= 0 y >= 0 width >= 0 height >= 0 x + width <= pqry.opencv.width_of(img) y + height <= pqry.opencv.height_of(img) def __ensure__(): (self.x, self.y) in self (self.x + self.width - 1, self.y + self.height - 1) in self (self.x + self.width, self.y + self.height) not in self # body of __init__ goes here... ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
