gt;
> On Tue, Sep 25, 2018 at 09:59:53PM +1000, Hugh Fisher wrote:
>
> > C and Python (currently) are known as simple languages.
>
> o_O
>
> That's a usage of "simple" I haven't come across before. Especially in
> the case of C, which is a minefield of *
th infinite resources contracts could be added to those
Python packages, or everything in PyPi, and it would be an improvement.
But we don't. So I'd like to see the developers of numpy etc keep doing
whatever it is that they're doing now.
--
cheers,
Hugh Fisher
ular, contracts in
Eiffel don't explain *why* they're there.
As for 4) reading the code, why not? "Use the source, Luke" is now a
programming cliche because it works. It's particularly appropriate for
Python packages which are usually distributed in source form and
Or is this an updated version of the old saying "real programmers write
FORTRAN in any language" ? If you are accustomed to Design by Contract,
think of your time in the Python world as a trip to another country. Relax
and try to program like the locals do. You might enjoy it.
--
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 progra
; in QT is only half a dozen or less lines of
code in total, so
meets the simplicity requirement. The big drawback of QT for Python
until now has
been building the thing, but now it's on PyPI so "pip install"
(should) Just Work.
--
cheers,
Hugh Fisher
___
i, Jun 08, 2018 at 08:17:02AM +1000, Hugh Fisher wrote:
>
>> But I think that the use of
>> radians in programming language APIs is more prevalent, so the initial
>> advantage
>> of easy learning will be outweighed by the long term inconvenience of
>> adjusting to w
> import to know if it's in degrees or radians (and that leads to very filthy
> bugs). Also "degrees" is already so the name would have to change the name of
> the package.
Agree, not a good idea.
--
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/
al to how Python works, and also
the source of so much power and flexibility, that I think it is worth
living with the
occasional glitch.
I would not want to see Python allow module or class writers to declare "my code
is perfect and not to be changed". But I would not mind if I could write c
print(x)
if x == 2:
x += 1 ;"Add 1 to x"
print(x)
if x == 3:
42
print("Answered everything")
if __name__ == "__main__":
helloWorld()
print(empty())
--
cheers,
Hugh Fisher
__
other people have made theirs, so I'll shut
up now. Thanks to everyone who responded.
--
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/
erpreter:
>>> def foo(x:itn):
>>> ... return x
and the interpreter raises a NameError because 'itn' is not defined.
Annotations look like code, they're mixed in with names and operators
and literals and keywords, and all the standard syntax and semantic
ritten, either makes sense.
What I would not expect is for the interpreter to silently assign a
scalar 1.0 to c and continue. That's just ... WTF?
Type annotations are code, not tests.
--
cheers,
Hugh Fisher
___
Pytho
kers themselves have versions? When a dev team
uses one type checker for 1.x and then switches to another for 2.x?
That's a special circle of hell.
--
cheers,
Hugh Fisher
___
Python-ideas mailing list
Python-ideas@python.org
14 matches
Mail list logo
