I think it's interesting to note the primary usecases / benefits mentioned: more readable than perl, better syntax than bash, easy to follow stacktraces. In short: an object-oriented scripting language. In that respect I think python has succeeded, probably beyond even the author's wildest dreams. And I love python, it's a language I use almost every day. The areas where it falls short are those which it was never designed for, as this announcement reminds us.
You're probably joking but, just for kicks and to provide some historical context, my guess is email. I seem to recall that attachment sizes would have been limited to something less than that back then. Also, 1.76 MB could have fit onto two HD floppies which would have made it easy to snail mail. Although it wouldn't have been all that hard to download with a 14.4 modem.
I’ll just add that it wasn’t a technological limitation - providers were simply profiting by selling every additional MB at hefty prices. When GMail appeared, it broke their business model... but there are still providers selling ridiculously low amounts of space for a lot of money, usually to people who don’t really know anything about the internet.
Linux could actually store more, as could some custom programs for dos iirc - ms dos had some conservative standards in place due to early floppies being less reliable I think. I initially became aware because the Amiga floppy drive/format was a superset of dos. You could (with appropriate software) read/write dos floppies on the amiga - but you couldn't read/write amiga floppies on pc hw (not even Linux, I think).
Interesting to read his description of the language, which sounds pretty much exactly like python is now. It’s a pretty good testament to why python gained and retained popularity. Though not without fault, python is certainly one of the best-designed languages ever created, in my opinion.
It may not be the most efficient one out there, but it certainly is the most productive, atleast for me.
God I love the language. The only language, that allows my thoughts to flow alongside writing code that allows my thoughts to manifest.
I am well experienced with C# as well, but something about statically typed stuff (I worked with C# before the dynamic stuff wasn't added to it) breaks the flow of thoughts.
With python, it's like designing systems on paper. Friction-free.
C# does not in any way represent the best that static typing has to offer. Try F#, Haskell or OCaml seriously before discounting static typing. These functional languages offer much better safety (e.g. no nulls, no casts, case exhaustiveness) and are as succinct as Python. They also generalise a lot of features that are ad-hoc in C# and Python (e.g. async-await is a library in F# and Haskell). For me, using Haskell is also like "designing a system in paper, friction free". In fact, I tend to write down the types and type check them, before I attempt to fill in any implementation.
Truth be told, I am not a Python fan. I am seeing it take over in my industry, because it's superficially 'easy' and it's popular. The lack of static typing only later becomes a big problem when large codebases start to appear with many contributors.
I think the closest thing to "python with types" is probably Julia:
https://julialang.org/
I think the efforts of adding type/type hints to python are interesting - but there's a tension between "weee! Look at me ducktyping, metaprogramming all the prototypes!!"-design and leveraging types as part of your design. Haskell/f#/ml are great languages, but they feel very different from python (ml maybe less so,but afaik there are no full featured implementations with areasonable standard lib...).
If Python is the starting point, I think there's probably four approaches that makes sense if python ends up being limited (in part due to lack of typing): move to a language like Julia, proto-type in python; re-employment in go, prototype in python; reimplement parts in cython and/or rust, add type hints on top of python.
[ed: almost forgot, secret option number five: use restricted-python and the pypy framework to implement a language suited to the problem domain..]
I am in the odd situation that from habit collection[0] feels natural - but I actually think "first element" makes a lot more sense than "item at zero offset".
Except maybe for things that are actually pointer+offset (which I think very rarely makes sense in high level languages/most ADTs).
In fact, I think for situations where 0-based indexing makes sense, I'd prefer "memory_area+offset" rather than "pretend_collection_type[offset]".
I also usually talk about "the first character" of a string, or first word of a sentence; not "word at zero offset from start".
So yeah, I think Dijkstra's wrong on this one (or rather he has some very strong opinions on greater-/less-/-and-equal-to, and which are natural - for which I have little sympathy outside of abstract discrete math papers).
One nice thing about Julia is that you basically never have to think about the indices. One of the primary reasons for this is that people using julia like array types with all types of strange and wonderful index sets (e.g. skew lattices to slice through a higher-dimensional array which people in medical imaging like apparently). As such, there are easy and convenient abstractions that are independent of the index space and all of the standard libraries and most external packages use these (to be able to deal with non-standard arrays).
I disagree when you're used to 0based array languages and you use a 1based array language (or vice versa of course), you have a high risk of 'off by one' errors.
I think the closest to "python with types" really is typescript. I hope Python can one day get there. Typescript really gets how strong typing can be accessible yet optional.
It's also my understanding that the TS community wants to replicate the mypy model where typechecking and compilation are separate steps; by adding a typescript compiler with no type checking to Babel.
@granitosaurus you're dead, but you make a valid point:
> granitosaurus 3 hours ago [dead] [-]
> There's also nim, which is rather new and not yet v1 worthy but I'd say it's still a worthy contender to the "closes thing to python with types"
I think nim looks nice, and have some very python like qualities. But while it's statically typed, I think it's more "python with native compilation", than "python with types" - in the sense of how the typesystem help with program design.
Mypy, while somewhat bolted on and relegated to linter space, does an amazingly good job at bringing modern static typing to Python. Highly recommended to at least test drive it.
Python + pascal are by far the ones I enjoy the most. I do a lot of F# now, and I like it, except, is not a good pascal!
i.e: The thing that bother my most of F# is that by default it not force to anotate types. One thing good about pascal is that is VERY EASY to figure out almost any line you read (without IDE help. Infurate me that F# know, but hide the knowledge to me!). With python is easy to infer the operations but not the data (ie: easy to read "I'm iterating" but not "and is a array of ints")
I could anotate a lot on F#/Python but is not idiomatic. This mean, that a lot of times I'm lost with F# in the ways is with python, with the worse thing that the infered stuff get crazy hard.
But, IMHO, python and pascal are in the TOP of truly well designed languages, where the sum of all the small things match well
There's "Real World OCaml" (new) and "Real World Haskell" (a bit out of date). But my favourite introductory text, which is not free, is Graham Hutton's "Programming in Haskell".
Thanks for the info. Just curious, what sort of problems are strongly typed languages most suited for? In the sense that which class of problems can be solved using them leading to elegant solutions.
There's a famous quote by Linus Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
Even when prototyping, I find that nailing down the data structures from the get-go makes subsequent code-writing much easier. A lot of times, the code kind of falls out naturally when you've figured out the data structures you're working with.
Strongly-typed languages give you a nice way to define data structures.
And Fred Brooks, from _The Mythical Man-Month_: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."
It has been my experience that “data-structures” in real world situations and especially within code directly facing consumers varies a lot more compared to what any pre-implementation data design process can predict (I’d even say that the structure of a lousy data-input form on a god-forsaken website has the potential to change a lot more often compared to the intrinsic structure of the Linux kernel). Dynamic languages (like python or even php) are very good at tackling this real life situation, hence their popularity.
They are very good at letting you make the quick easy change while providing no helping hand in ensuring all your code is utilizing the data structure's new schema correctly
They are "easy" in that sense which makes them popular with a subset if developers, while another subset loathes the terrible language services/tooling.
Incidentally many dynamic languages seem to have attempted to bolt on some faux type system; python type annotations, phpdoc, jsdoc, type specs, etc, etc.
I use Haskell professionally in the area of quantitative finance in a large team with a multi-million line codebase. Everything is built upon domain specific libraries, sometimes many layers deep. And these libraries are constantly changing to keep pace with the business. Strong types tell us early when things are broken. Others are attempting to use Python for similar projects, but it isn't fun (we have some of their alumni).
Haskell's effect typing also helps us. For example, for reproducible calculations, it is critical that no data is pulled-in via a backdoor (i.e. a side effect). Even reading and using the current system datetime is something we want to prevent. This can be expressed in the types using Haskell.
So, highly reliable and completely transparent data processing. Awesome. Very interesting to know. I always assumed financial data processing, HFT, etc are done in java / C# or other mainstream languages.
And yes, in such a situation, Python will not be an easy fit.
Thanks a lot for sharing the info. Have been wanting to learn functional programming for a long time now. Specifically, I am planning to build computation systems based on Haskell, Scala, etc which sit behind a Message Queue server. Just to isolate the computation part from other mundane activities like HTTP request processing.
> what sort of problems are strongly typed languages most suited for
I'm going to volunteer an answert to a slightly different question. "What sort of problems are strongly typed languages suited for?". They are suited for general purpose programming.
After a decade of experience developing big systems in C and C++ followed by a decade of developing big systems in Python, my own experience is that static vs. dynamic typing isn't actually the issue that normally matters in a big system. Static typing is great for optimizing performance and for having efficient interaction with the underlying system libraries. So the closer your work is to the underlying machine and its types, the more important static typing is. But only a small part of any big system is usually like that, and static typing makes code harder to develop, harder to read, and needlessly limited in scope (overly specifying down to a machine type, when the actual algorithm may be far more general than that). Dynamic typing addresses those concerns, but it makes for a brittle system where each component makes a lot of undocumented assumptions about what might be passed in, with users of those components often just crossing their fingers about what the component might accept. Worse, dynamically typed systems eventually end up accruing pages and pages of hand-written documentation, assertions, and exceptions as people try to make them more well validated against user and external-programmer errors. All that well-intentioned "hardening" inevitably eliminates the readability benefit, except during initial development (when such checking is conveniently skipped). So neither static nor dynamic typing alone makes it easy to build big systems.
What does make it easy to build big systems is semantic typing. I.e., the ability not just to declare a machine type, but to declare the actual assumptions made by any component about its inputs. In some low-level code those assumptions are about machine types (argument i must be an 8-bit integer, and s must be a string). But in other cases the assumptions are about what the argument represents (argument s is a string denoting a filename (not just any string), argument n is a number between 1 and 36.2 (regardless of machine type)). Any given component makes some assumptions about what it can handle, and if you can easily declare those assumptions and validate against them, then the component is easy to read, easy to understand, easy to use, safe against user errors, and easy to implement (as you don't have to write any code to handle conditions not allowed by the declarations).
The beauty of Python is that semantic typing can be implemented very naturally within the language itself, which is crucial because it has to be extensible to handle any given domain's objects if it is to be of use. There are a variety of options, but my own package Param (https://ioam.github.io/param) provides support for semantic typing, and if you look at some of the examples there you should be able to get a feeling for how you can have the best of all worlds in Python: freedom where you can handle it, constraints where you want them, and everyone being up front about what they are doing in a way that makes big teams able to work freely with whatever other people come up with.
Types in any modern statically-typed language should go well beyond simple "machine types" and also capture semantics. If one is representing everything with Strings and Doubles, then the type system is not being fully exploited.
Refinement types can statically capture range checks and other similar assertions. There is a project to add them to Haskell (Liquid Haskell) which is already quite useable.
Of course, static types are machine checked prior to running the program. None of your Python "types" exist until runtime, by which point it is too late. The program crashing due to an assertion failed error is logically still a crash.
We will have to agree to disagree on the roll of static types when building large systems. I have also spent over a decade working on very large codebases. The more "dynamic" a system was (late binding, reflection, string-based lookup, variants), the harder it was to statically reason about the code and avoid introducing errors. In a fast-paced business where hundreds of people are changing the same codebase daily, I do not understand how one could stay sane without static types. Python was never designed with such use-cases in mind.
Sounds like we'll have to agree to disagree about a lot of things! :-) Having types specified statically is a recipe for generating untold many different versions of the same thing, plus untold bits of glue between them, which leads to huge codebases that need hundreds of people to work on them. Python was designed to avoid huge codebases and let smaller numbers of programmers be more efficient. (Of course, so was Haskell, but that's mostly a straw man, given how few large-scale users of Haskell there are in industry...)
And Python's duck typing is for addressing the needless constraints that statically typed polymorphism introduces. Discussions like this can go on forever! :-)
It would be great to still have static constraints as an option though.
I absolutely love the free form in the prototype phase, but once I've got that one nailed and want to make it maintainable... well, I always miss it at that time.
I started using type hints and it greatly improves the readability and sometimes catches a mistake. But would love for it to be more.
Maybe a flag to the interpreter that would raise an exception each time it detects an inconsistency at runtime. I can imaging turning this feature on in a staging environment.
From my understanding, this should be possible by setting the sys.settrace hook. It would slow down every function call, but I'm surprised it looks like nobody has done it yet.
It can be done partially with type-hinting in python.
However, quickly iterating through to a solution and then optimizing it in a static language is a workflow that can be adopted. However, that may be necessary for only the most critical parts of an application.
With software development moving towards distributed computing, there is a lot of breathing space for languages like Python.
That's funny: my python's experience is totally opposite from yours: I find that me and my colleague keep making mistakes that would have been caught by the compiler..
So we're replacing a Python based test system by a C++ one.
There's a lot I like about Python, but there are a couple of things that they've gotten so horribly wrong.
1. The KeyboardInterrupt exception for SIGINT. Whoever came up with that idea destroyed the credibility of the entire interpreter. Python falls flat on its face to me because of this one design choice. It's impossible to write a Python script that will not dump a full debug stack trace if you send SIGINT (ie: Ctrl+C) before the first line of your script is reached. That is, even if your very first line of code is a try/except block intended to catch KeyboardInterrupt, a SIGINT early on will still fail spectacularly at some point during Python's internal startup. Python runs a lot of code before turning control over to your script and it's simply not possible to, from within Python, catch these signals.
In order to provide a professional piece of software to clients that will not dump debugging gibberish to the terminal, one must wrap every single Python script with a shell script or small C binary that catches signals and proxies/rewrites SIGINT as SIGTERM, in order to avoid KeyboardInterrupt entirely. Something as fundamental as signal handling having been botched to this extent is frustrating.
2. The asyncio module. They screwed up the async implementation in the earlier phases, and the hacks that have been implemented in an attempt to improve the situation are grotesque. The state of async in Python is confusing enough as it is, but if you happen to run into one of the edge cases where the ways in which they've hacked the core of the language to make room for the async stuff affects you, you're in for quite the ride.
While it's never been a problem for me, I can see that #1 makes a lot of sense.
% python -c pass
^CTraceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 62, in <module>
import os
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 400, in <module>
import UserDict
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/UserDict.py", line 83, in <module>
import _abcoll
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_abcoll.py", line 9, in <module>
"""
KeyboardInterrupt
to avoid importing the site module, then set your signal handlers, then import site manually. In that case the only output, if caught at the wrong time, will be the message 'KeyboardInterrupt'. This isn't quite what you want, but it's a lot closer.
There should be a way to pass an option to Python so that if you do 'python --early-sigint "message"' it prints the message for an early sigint.
You should post that to the python-ideas mailing list. It's a long and tedious process to get everyone on board by writing mails, but it works. Pretty much everyone can do it.
As a minor nitpick it bugs me a lot that there are no truly anonymous functions. You either have to use a lambda which is limited to expressions, or name a function and use it as a first class object. Every other language in the same domain has this feature.
I suppose you could avoid the possibility of a name clash if the interpreter maintained a hidden, name-mangled reference for you...?
Personally I think it's a bigger problem that python isn't all that well suited to functional programming because of lack of tco etc (see slackness python etc). But I understand the design decision.
Python actually does have a kind of "anonymous function" feature, at least in a way that replaces most common use cases. It just happens to be bundled in a unique Python-like way. A lot of people don't seem to know about @contextmanager (contextlib.contextmanager) - it's what provides the functionality for "with" blocks. You've probably seen with() used with file operations (open file, run block of code, file is closed automatically at end of block), but I suspect many developers are unaware that you can create your own context managers.
While they are not true anonymous functions, I have yet to stumble on a scenario where a context manager did not fit the bill. They're easy to create - nothing more than a try/except/finally with a "yield" call to execute... you guessed it, essentially an anonymous function block. It's a little mind-warping the first time through, but it winds up creating clean code. PEP 343 is a good source to learn more.
How do contextmanagers (which by the way, @contextmanager is sugar for manually defining an object with __enter__ and __exit__ methods) take the place of anonymous functions?
It's both very expressive and readable, and it's the last part I absolutely love. I can understand Python code very quickly and I can often recognize the algorithm that's implemented.
And you can do composition easily, that's the main seller for me.
Does this not work with Ubuntu on Windows? I've been using it as my primary development environment and it seems to work perfectly with the mainstream Ubuntu/linux software I deal with. https://docs.microsoft.com/en-us/windows/wsl/about
While we fix bugs in our Linux packages so they work on USW/WSL this one appears to have problems (and I do not expect I will look into them any time soon):
.. I did capture the backtrace though; for what it's worth:
(gdb) bt
#0 0x00000000004212bb in do_mkvalue ()
#1 0x00000000004210a7 in do_mktuple ()
#2 0x00000000004211a8 in do_mkvalue ()
#3 0x00000000004213f2 in vmkvalue ()
#4 0x00000000004214a1 in mkvalue ()
#5 0x0000000000422438 in err_input ()
#6 0x000000000042258c in parse_file ()
#7 0x00000000004226ae in run_file ()
#8 0x0000000000422bf3 in run_script ()
#9 0x000000000042232a in realmain ()
#10 0x00000000004039f4 in main ()
bt full
#0 0x00000000004212bb in do_mkvalue ()
No symbol table info available.
#1 0x00000000004210a7 in do_mktuple ()
No symbol table info available.
#2 0x00000000004211a8 in do_mkvalue ()
No symbol table info available.
#3 0x00000000004213f2 in vmkvalue ()
No symbol table info available.
#4 0x00000000004214a1 in mkvalue ()
No symbol table info available.
#5 0x0000000000422438 in err_input ()
No symbol table info available.
#6 0x000000000042258c in parse_file ()
No symbol table info available.
#7 0x00000000004226ae in run_file ()
No symbol table info available.
#8 0x0000000000422bf3 in run_script ()
No symbol table info available.
#9 0x000000000042232a in realmain ()
No symbol table info available.
#10 0x00000000004039f4 in main ()
No symbol table info available.
If memory serves, '94 was just before internet access and web browsing became things that everyone had and did. I don't think people had settled on the terminology just yet.
Arguably, that would be Java, which was introduced in 1995. For whatever hey are worth, most language popularity indexes (TIOBE, LangPop) place Java above Python with quite a large margin.
Java may not get much exposure here or in startups, but if you go out in the real world of 'boring' business applications, Java is pretty much the defacto language (together with C#).
I would really be careful to use StackOverflow statistics as a proxy of language popularity. There are many ways that Python's relative popularity compared to Java on StackOverflow can be explained. For example: Python is used more by hobbyist programmers, hence more questions about it. Or: Java is taught in many universities, so people generally have fewer questions about Java.
If you go outside this filter bubble and look at the large IT companies, such as IBM, Oracle, Accenture, Atos, Capgemini, SAP, etc. they are all JVM/.NET shops. Also, on job sites such as Indeed, there are more Java jobs than Python jobs (currently respectively ~60,000 vs. 47,000 in the US) [1].
Note, I am not denying that Python is popular. Python is immensely popular. And I definitely like the Python ecosystem more than the Java ecosystem. I was just contending that the original statement that Python is the most successful language in the last 20 years is concorrect. Java is younger and is (still) more widely used in companies. Of course, Python may or may not surpass Java some day.
[1] Also, the positions mentioning Java often require that an applicant knows Java, whereas ads with Python often have wording such as "dynamic languages such as Javascript, Ruby, Python, and Perl are preferred".
I wouldn't argue that Java is a lot bigger than Python in real world adaption. But the Stackoverflow graph that was posted above looks at growth over the last past 5 years.
I have been working with Python for 12 years and only in the last few did I get the impression that it is a popular language. For example when I'm interviewing candidates for a junior dev position, pretty much all of them have at least some Python experience from University, whereas when I started all the fellow Python programmers either learned it on the job or in their spare time.
I do agree that StackOverflow isn't a good proxy, but I could image Python getting more new regular users than Java at the moment.
My anecdata is exactly the opposite: I have worked for four companies in the last 12 years, 2 big multinationals, mining and defence. All four used git.
Don't forget mercurial: it's not used much for FOSS due to GitHub, but has a pretty strong hold in private companies. It's better than git (historically, not sure if it's still true in 2018) at dealing with Windows and huge repositories. And perforce for the truly humongous code bases...
Java's tooling support blows Python's tooling support right out of the water. The static type system of Java allows faster refactoring and IMHO makes development of large applications easier and less error prone.
I use Python for simple scripts and often for data transformation. But e.g. at work we have a few million lines of C# that I would never ever want to manage if it was written in Python.
One might argue that Python doesnt need as much tooling. In java you need tools to autogenerate code, refactor, etc. Because its so strict. But with python, you can use the language itself to do things, such as adding a parameter to a function without actually modifying any existing references.
In other words, in java, the language is the canvas and the ide is the paintbrush, but in Python, your editor is the canvas, and the language is the paintbrush.
I always find it peculiar that people seem to defend a million line code base, like that is something to be proud off. The days I walk out of the office with less code in some mature project's repo are the days I know I accomplished the most.
Sometimes it's not possible to do it in another way. Hacker News' web-focused world doesn't apply to most of the software world where software is deployed on customers hardware for the customer to work with by themselves as much as possible.
If I had to deploy 10 microservices with 2 level caches and internal network routing on a whole server rack or in "the cloud", our customers would laugh in our face and choose one of our competitors that deploys on one or two on-site servers that can sit somewhere in the office and require minimal, if any, maintenance besides security updates.
No, you simply write your app in a language that does not force you to write millions of lines of code, a language like Python, for example. I don't understand what any of this has to do with 'web-based' vs whatever though. Yes most systems I tend to work on these days have browser-based front ends, but that's usually a trivial part of the system.
About deployments:
The fast majority of 'web-focused' apps I work on ships in a single docker container. The customer, another department in the big multinational I currently work for, deploys it on one of their docker hosts where it lives behind a nginx emperor with many - up to 30 other vassals. It happens automatically once a week on the release schedule. OK, these are usually trivial little CRUD things - but not always. Bigger systems tend to get their own VM or et of VM's.
Every other third party vendor product I had to deal with in the last 5 years came in either a set of docker containers, a pre-built VM, or both.
Do you mean tooling in the sense of Debugging support? Or is it code generation, etc? Just curious.
I use PyCharm for medium to fairly complex projects and with Python 3 type hinting, I have not faced any particularly difficult development situations, tooling wise.
Well, type hints are a relatively new addition to Python and while they are nice, not every code has them and you cannot rely on them 100%. Python in general is a cool language that you can build stuff fast in but is is also extremely dynamic which doesn't make it good for IDE support where you often want to know where stuff is coming from in one click. Large code bases can get very confusing and navigating in a module you don't know is easier with IDE support.
Debugging in Python has gotten very nice but I feel like it's still easier in Java. I'm always very bad at finding examples, sorry :/
Yes but "sucking so bad its not even funny" is still superior to maven and ant (and as another user mentioned, pipenv is a very good approximation of Cargo, which is a really good build and package management system).
That's not a library, it's a platform. There are all kinds of platforms stuck on ancient Java versions (Android), for which libraries are not always compatible. Every package you'll use is compatible, unless you're Mozilla's build system.
Im curious what languages you use. Because while python's package management might not be great, I would definitely put it in the top 5. Most languages have bad package management, including go.
I love python. And hate Java (as logical is to hate a language, ok?)
Java have a super big assets: A very powerfull VM. And this is the part where python is not as good. Is sad that Python3 was not used as the moment to build up a good VM, but well, history is history.
And this actually mean: Put a very strong and well funded team behind it. Make a good VM for python is hard
Ridiculous is thinking you could write a whole OS userspace in Java.
Ridiculous is making that comment without realising Python is a core part of most modern *nix userspace. try uninstalling Python on a default Ubuntu/Fedora/Centos install and see what still works. I would suggest trying the same with Java, but nobody bundles that by default despite it's JIT.
Ridiculous is pontificating about how useless Python is without C/C++, clearly without knowing much about the language and its strengths.
I've known people who say the same kind of things, who write reams of very poor, unidiomatic Python code and wonder why it's slow, not wanting to accept that it's their bad code that's slow!
I'm not sure if you're being intellectually dishonest or just willfully ignorant, but except Android all of those projects are long dead or discontinued. It seems Java wasn't a great choice. And while Android uses the same syntax as Java under the hood it's a completely different and doesn't share any code with, one very different from the JVM (Yes, Java != the JVM, but you're whining about the CPython implementation of Python rather than the syntactical differences compared to Java)
I mean this whole thread is ridiculous, you start out by saying "Python is bad because you can't write an OS user-space in it" which by itself is entirely ridiculous. You defend this by saying "Java is fast, therefore Python is bad".
You like to troll around these Python threads saying the same thing, "boo Python is bad because it's slow" and "boo where is the Python JIT". By all means make these points, but until you put some actual substance into your arguments they will continue to come across as very confused. And honestly it does seem like you are very confused.
> As a replacement for complex shell scripts, libraries written in C and C++, or scripting GUI applications.
Those projects were done and ran in actual hardware.
I am making the counter point regarding OP statement that Python is suitable to fully replace Java ,regardless of the implementation. Lets not mix languages and implementations.
So given that even PyPy does not match the performance of most Java implementations, it seems a bit hard to consider the scenario of Python fully replacing Java's use cases.
Sure, in Java applications where performance is critical it might be hard. Is this all Java applications? Is this even most Java applications?
I'm not necessarily agreeing with the original point that you can rewrite any Java app in Python, because that's ridiculous as well. But your counterpoint that it can only happen "when a user-space could be written in it" is very poorly chosen.
Which other language shares Python's level of dynamism - where object attributes can be conditionally deleted at runtime, for example - and manages to have convenient thread-safe operations?
Wow it's much older than I thought. As it says in the post, if you want to a view the online doc's just fire up Mosaic. Then compile it on your IRIX box. Those were the days.
Wow. What a gift this language has been. Thanks Guido! I'm using it this morning with GAE. I was using it last night to write a Luigi ingestor for Redis. It's my favorite language.
A good automatic code formatter (like JavaScript’s/typescript’s prettier) really really breaks the arguments used by significant white space supporters ...
I use a code formatting tool in my python work flow as well but it’s nowhere near as nice/fun as with a non-significant white space language ...
Python 2.4.2 for DOS/DPMI, built on the DJGPP platform, is also available”.
So, yes, there was one. The link (http://www.caddit.net/pythond) works, and seems to still have the binary. You will need a ”proper Long Filename Driver for your platform” to fully enjoy it.
I learned Python 1.4 on DOS (with DJGPP). I think there were binary releases, but you couldn't use them if you needed any third-party C modules. There was no dynamic linking on DOS so you needed to statically link any C code you were using into python.exe. This was a huge pain but it also taught me a ton about both C and Python.
Yes. Very much still an issue. There's mountains of Python 2 code still out there and loads of software starts with Python 2 and then maybe adds Python 3 support later. Hopefully.
It's one of the biggest reasons not to use Python IMO. No other popular language has this issue. The other reasons I wouldn't use Python:
1. Difficult to distribute standalone programs. You end up having to bundle an interpreter which is a pain.
2. So many programs include python interpreters you end up with insane path issues, especially on windows.
3. It's still slow.
> It's one of the biggest reasons not to use Python IMO. No other popular language has this issue.
No other popular language struggles with issues of backwards incompatibility? That's a huge exaggeration.
> Difficult to distribute standalone programs. You end up having to bundle an interpreter which is a pain.
I guess then you generally prefer not to use interpreted languages?
> So many programs include python interpreters you end up with insane path issues...
How is that? There's usually a system Python which system programs should reference explicitly if they care. If you code up a Python program without being careful about its dependencies, then yeah you're asking for trouble. But that's true of any program, whether it needs to locate an interpreter or be compiled against a shared library.
None of the pain points you mention are inherently specific to Python. But maybe Python's huge success and ubiquity trick people into conflating general software development issues with Python issues; rather like how people start confusing popular brand names with actual products (e.g. Band-Aids).
> No other popular language struggles with issues of backwards incompatibility? That's a huge exaggeration.
Pretty much true. As far as I know C, C++, Java, C#, Javascript, etc. have never broken backwards compatibility. At least not in a serious way (like changing how `print` works).
> There's usually a system Python which system programs should reference explicitly if they care.
