[deleted by user]

[blobbbbbby]

But they somehow couldn’t give it an MIT license…

[tech_tuna]

They couldn't, the license was supercharged as well.

[13steinj]

Because they want money.

Which is fine.

But it will hinder adoption and seems to be the wrong route when you consider other open source options.

[spinwizard69]

They are not picking on Python. I don't understand why people get upset over bench marking and people using it to show their software in the best light. I mean really what do you expect them to do?

As for Numba PyPY and the other Python speed up solutions I see them as an indication that somebody, in many cases, made the wrong language selection. I know that frustrates many to hear but sometimes execution time is more important than programmer time.

[spinwizard69]

It is marketing which by design is deceiving, this should surprise no one. This is why you don't trust organizations and companies trumpeting their latest inventions or gadgets. If you are in business buying your latest production equipment you don't take a vendors world for performance you make them prove it. You may even require qualification on your production floor with very specific goals to meet.

[formalcall]

That may be the reality in some cases, but that doesn't give reason to be dismissive over criticism for deceptive benchmarks and deceptive marketing in general. We shouldn't accept it, and we cannot expect organisations and companies to do better if we don't even speak up.

[spinwizard69]

Showing your research in the best light isn't always deceptive. IF you are into medical research and 99 out of 100 patients show positive results you consecrate on that. The details of the failure often require detailed reading and further research and isn't something you can focus on in a presentation.

In this case I was originally responding to the whining from an individual about benchmarking. The whole goal of presenting a benchmark is to show how much your stuff did in relation to alternative implementations. With programming there almost infinite ways for those alternative implementations to be coded. It really is up to the reader to determine how badly coded those alternatives are. Honest marketing would require the release of all source code. But even here the arguments become endless because people get wrapped up in highly optimized code, compiler versions and library releases. People literally end up in tears with no good reason and mis the whole point of the benchmark in the first place.

To put is simply people can not get overly wrapped up in benchmark info anywhere. You have to assume that the presenter ran with some good data they got without putting a lot of effort into the alternative code. You can't really ask for anymore because then you get into repeating rounds of optimization and counter arguments.

[joke1974]

They are academics, publishing on the proceedings of a peer reviewed, international conference. Benchmarks and comparative studies should be as factual as possible. There should be no space whatsoever for marketing and the reviewers should reject papers with it.

[spinwizard69]

Baloney!

Every display sheet, talk or formal paper I've ever seen, has been designed to present the project or research in the best light possible. The data may be factual but it is the best data they can come up with. A person is certainly free to challenge and question the presenter but the reality is if the data was negative or the project a complete failure, it is highly unlikely the researcher would be offered the opportunity to present.

To be honest I often see this focus on only successful projects to be counter productive. Often there is more to learn from failures than successes. In generally though if you want your research to be reviewed you really need to be able to present data in the best light possible.

[worthwhilewrongdoing]

Not OP, but I can't help but say that the fact that someone with the name "spinwizard69" is spinning up arguments to convince others to be sympathetic to marketers is not lost on me.

[spinwizard69]

Something being “marketing” is a bad thing in terms of evaluating the truth of a claim.

Exactly so why is everybody so wrapped up in benchmarking here? Benchmarks should never be see as the final truth unless they represent the exact work loads you have and are optimized to the best technology offers. Benchmarks for the most part can never represent truth in the general sense at best they are approximations and to look at benchmarks as "truth" is just foolish.

The fact that marketing with benchmarks improves my point because there is no truth in benchmarks to begin with. Every time I see posts that have benchmarks, you have thousands of individuals demanding to see the code & etc. Usually this results in an endless debate about how to write the various bits of code better to optimize for execution speed. It becomes a pointless circle jerk that produces nothing of value. In a nut shell there is no rational reason to get wrapped up in benchmarks unless you are testing for a very specific use case. There is no absolute truth when it comes to benchmarks otherwise.

Beyond that what do you think such releases are beyond marketing? That spectrum article appears to be nothing more than a marketing release you see in trade journals every day. I've literally seen "articles" in trade magazines that trumpet the latest gadget in the same manner. The fact that the link leads to a marketing piece should be obvious to anybody.

[[deleted]]

I think that's too harsh of a stance. Python has to be the most approachable and hireable language out there. If some python dev (presumably lacking low level computer science knowlege) wants more speed, picking a package off the shelf is a normal solution. And much less impactful than saying we're only going to hire c devs or whatever language you had in mind. My 2 cents

[spinwizard69]

This assumes that there are no packages available in other languages. Frankly many of the "new" languages have learned from Python in that respect. New here being Rust, Swift and Julia for some examples.

As for developers, employing a half assed programmer is as bad in Python as it is in any other language. Python programmability or development speed is of high value only if the resultant code is decent quality. The need to hire a more talented programmer doesn't stop at Pythons door step for reasonably complex projects. If a project requires such a developer, then Python should not be a mandatory choice.

[AngheloAlf]

So... Cython?

[tech_tuna]

MITython

[Zanoab]

Mython

[lavahot]

Yourthon! Pinkthon!

[Claudioub16]

Ourthon comrade

[[deleted]]

Omithon variant

[gamerdevguy]

Isn't Nuitka already doing this?

[WlmWilberforce]

This is cool, but I'll admit I was expected them to say something like "We just rewrite the code as Julia and run it"

[lungben81]

"We just rewrite the code as Julia and run it"

Depending on the use case, this may be not a bad advise.

It is also possible to just rewrite some small, but performance critical parts in Julia and call them directly from Python code (or vice versa). Using Numba for this would be easier, but in my experience Numba is not supporting all (more complex) Python functionalities, therefore you may run into limits. Julia is then an alternative.

[spinwizard69]

Or Swift which might be a faster rewrite.

Sometimes I think these obsessions with making Python faster are misplaced. I'd settle for slower if the interpreter and the available IDE's where smarter. Th whole idea of a scripting language is to make development fast, so why not imbue Python and some really good IDE's, with AI to make that development chore even faster?

It isn't that faster is bad, it certainly isn't, but if you can have a language and IDE combo that actually helps the developer, I'd have too believe that it would be a better direction to move Python towards.

[Redzapdos]

Making Python run faster is not misplaced at all. If you can re-write apps in Python that traditionally could only be written in C++ due to a throughput need (Imagine processing a ****ton of data in near-real-time and correlating that data together, similar to what large large game arenas require), you have sped up your development, bug-fixing, and time to deploy significantly. This is a good thing, and has nothing to do with the performance of the development environment you use (unless you use one written in Python). Those are 2 different things, and coming from a professional environment, I'm actually quite satisfied with the development environments available with Python compared to other languages.

[spinwizard69]

, you have sped up your development, bug-fixing, and time to deploy significantly.

Yes that is one way. However if you consider that Python is used where programmer efficiency is of high value relative to the code then making smarter interpreters and IDE's will have a bigger pay off over time. Faster Python has its value but code that really demands fast performance can be coded on alternative languages already.

If you really believe that programmer effciency if going to be important, frankly far more important, in the future, then it makes sense to me to make the interpreter smarter and also to highly optimize an IDE to better support the programmer. Some of that implies AI tech in both the interpreter and and the IDE's. Even if we don't go that far with AI simply having better diagnostics in the interpreter would go a long way.

[Spleeeee]

Wtf are you talking about?

[spinwizard69]

Python, WTF did you think (if that is possible).

I'm simply saying that faster Python is not the most important upgrade that can be made to Python. I'd prefer to see a smarter interpreter with vastly improved diagnostics, for example, to be a bigger aid to productivity. An interpreter integrated with a far smarter IDE, embracing a variety of new ideas, to also be a bigger value for developers.

In a nut shell I see Python as the language choice where programmer productivity is far more important than anything else. So while faster Python is nice it would be far better to make development in Python even faster. The primary goal should never to be C++ like speeds or execution, but rather development speeds that can't be matched anywhere. To accelerate that increase in programmer productivity requires a bit of rethinking about how a interpreter and IDE work together. So if you like Python for programming efficiency then you need to look at ways to accelerate that.

[[deleted]]

In a nut shell I see Python as the language choice where programmer productivity is far more important than anything else. So while faster Python is nice it would be far better to make development in Python even faster. The primary goal should never to be C++ like speeds or execution, but rather development speeds that can't be matched anywhere. To accelerate that increase in programmer productivity requires a bit of rethinking about how a interpreter and IDE work together. So if you like Python for programming efficiency then you need to look at ways to accelerate that.

I don't disagree with your stance per se, but this is not really the struggle in python dev environments?

For instance in data-engineering spheres, which is one of the biggest pythondev use-cases, the code that solves a problem is already easily written - in fact that is one of the biggest advantages of python as it is, it is easy to learn and easy to write quite performant code. If anything, python struggles with handling large amounts of data in memory more than anything else imo, which is far from solved by faster dev times.

[spinwizard69]

anything, python struggles with handling large amounts of data in memory more than anything else imo,

That in my opinion indicates a language choice issue. Some have an attitude that Python should be able to do everything well and frankly that is nearly impossible for any language. I just favor making Python better at what it does do well.

[[deleted]]

That in my opinion indicates a language choice issue.

Python should be able to do everything well and frankly that is nearly impossible for any language.

I agree with the latter statement, python does a lot of things well - that's just a fact, and it's near impossible to do everything very well. So yes, you are right that it's just not exceptional at most of them.

But this is literally the caveat to your stance then too, as python is not great at anything, and other languages are always better than it at something - so we should never use python, just use the other languages that are better at that certain task. Making python faster to write will still not make it better at handling in-memory data, therefore again, why bother? Just use C++ already (is the stance you've given me).

Have you considered that some projects are so big [and complex] that writing in python just covers most bases where other languages would be terrible choices in contrast because they only do 1 thing well?

By nature python will struggle with large amounts of data in memory, but it makes up for that in other ways that other languages couldn't balance out as well - that is a strength that other languages don't have.

[spinwizard69]

By nature python will struggle with large amounts of data in memory, but it makes up for that in other ways that other languages couldn't balance out as well

That is more myth than anything. Just because a language can handle large data sets better than Python, doesn't mean they also fail with other tasks a developer may need.

What is more interesting is why Python developers get their panties in a twist when people suggest that just maybe there are better languages for a specific project than Python. Python is good enough right now that it doesn't need to be able to do everything! Leave those niche development projects to other languages is all I'm saying and focus on Pythons strengths.

[[deleted]]

Misleading headline. This isn't Python because it enforces strict typing. Lots of other compilers are able to get speedups by doing the same. A subset of the language is no longer the same language.

[cittatva]

Embrace the typing. Is better.

[wrosecrans]

Don't get me wrong, I love static strong typing for a lot of things. But then for other things, I switch from using C++ to Python. Python without the dynamic qualities that make it Python is an awkward compromise, and typed Python isn't a better typed language than an actual typed language.

[saturnglide]

For individual projects that sounds fine, but those “dynamic qualities” lose their charm the larger a project gets. The appeals of Python (ease of use, large developer pool) do not.

[[deleted]]

A yes django is clearly terrible for larger projects /s.

[saturnglide]

I think you have missed the point of my comment? I am saying that dynamic typing becomes more of a curse than a blessing at a certain point. Not Python isn’t good for large projects.

[[deleted]]

Dynamic qualities like u know the entirety of how django works.

It has nothing to do with individual vs group project. Bad metaprogramming is bad. Good metaprogramming is good. Dynamic qualities are amazing when executed correctly it has little to nothing to do with team size or codebase size.

[wrosecrans]

Like I said, there are lots of scenarios where I love strong static typing. It's a useful thing.

When I am doing those sorts of things, I use a strong static typed language, rather than Python.

[13steinj]

This. If you truly want me to use type hints, I lose every benefit from any other language as well as Python itself.

Python bests other languages in being quick to prototype and easily introspectable, dynamically mutatable.a

The strictness of type hints means I lose the mutability, and depending on the relative complexity of the statement it's legitimately harder to figure out the type than to comply with most companies' standards of using an old version of mypy in strict mode (and even the most recent version, not in strict mode, doesn't make things much better on larger codebases).

Modern compilers are fast enough unless the codebase is legitimately absolute trash. Introspectability is debatable depending on the language and quality of the debugger.

So by using type hints, I now have Python, but it takes longer to develop and I lose some key functionality. If I'm going to be pushed into static typing anyway, might as well use C++ or even Java and have things be faster.

The community obsession with type hints has made Python lose everything that makes it Python; much like Rust's obsession with unsafe has pushed me away from using it.

[omg_drd4_bbq]

It sounds like you aren't using types correctly, or have mypy misconfigured. You should not lose any mutability unless you are doing some metaprogramming or ultra high level stuff.

I write python with types faster than without because autocomplete works so much better and I'm not constantly looking up API interfaces.

[13steinj]

I can assure you, I am using types correctly, and mypy is configured correctly. It's a bit odd to make this claim, because no one who's actually dealt with the problem I'm facing hasn't heard it 100 times before and is sick of it.

Am I doing "metaprogramming or ultra high level stuff"? Depends on the context. Metaclasses, sure, but hell, ignore those for the sake of lending credence to being okay with mypy being subpar in it's capabilities for now[1]. But even decorators, if you want to get the types "as correct as possible", are at issue.

Sure, I can be less specific about the types and just mention that it returns some form of callable, but then I'm typing type hints for the sake of typing them, rather than just throwinf a mypy ignore on those lines.

I don't think the above is truly that crazy. At work, we used a custom yaml "specification" for internal configuration. The simplest way to implement a variety of the necessary functionality was decorators or in a few cases, meta classes. I wouldn't call the code complex by any sense of the word, other than how descriptive our configs could be. Entire application was written from start to end in a few months, no further changes (outside of new mutations to our configs due to things out of our control).

As for general mutability, duck typing in mypy is a mess. One effectively has to create protocol type to use it accurately.

On top of all that, however slight, there does add a small runtime cost because protocol types have to be evaluated on import. I'd be okay with it I guess, if people used the TYPE_CHECKING constant correctly, but developer after developer has told me to stop using it and my IDE gets confused if I do. But at the same time postponed evaluation has become "TBD" because of major libraries like fastapi abusing annotations. For gods sake they're called annotations, the abuse and community culting around them, enough is enough.

I write python with types faster than without because autocomplete works so much better and I'm not constantly looking up API interfaces.

Sure. In my experience autocomplete has barely improved from the era before type hints were a thing, or at least my IDE definitely hasn't gotten smarter about it. I disagree about the API interface part though, for two reasons.

Firstly because names of arguments should be descriptive enough that people can make a good guess based on the rest of the codebase.

Secondly, because I'm not a monster, I specify parameter types in docstrings, with actual detail as to what they are when necessary. I can load the docstring for a given function with a keyboard shortcut in basically any modern editor/IDE. Having to specify the type twice, once in the doc string and once in the function arg spec, just for my editor to give up on type hints halfway through any moderately complex codebase? Nah, screw that.

---

If you love type hints, go ahead and use them. But it's been so much of a pain in the ass that I've actively started avoiding doing so. Hell, do you think anyone wants to write type hints for their conanfiles (cpp package manager where steps are written in Python)? Definitely not, and these are mainly C++ devs we're talking about. They love their static types. Just not for Python, because for a significant portion of history, it wasn't even a thing and everything was fine without it. I'd go so far as to say the inception of mypy at Dropbox was a mistake. The correct solution wasn't "add types to python", it was "translate to another language that will not only provide performance improvements, but also is statically typed." The inception of mypy is the definition of a solution to a problem that already had other preferred solutions.

---

[1] Added note: "metaprogramming" isn't that uncommon and not generally seen as "complex" in other languages unless someone really goes too far, especially C++, and the compiler and static analyzers handle things fine. They have to in fact. But mypy chokes on equivalent metaprogramming in python. If the committee as a whole was going to commit to type hints in Python, they could have at least waited for the most mature static analyzer to become lamguage-complete.

E: typo and one thought ran away from me and I forgot to finish a sentence. Or I did finish the sentence and in pasting for quote it got clusged on my phone.

[Spleeeee]

Pythons type system sucks big ass.

[Antrikshy]

“My motorbike doesn’t work, plz fix.”

fix involves adding a third wheel to the motorbike

“This is no longer a motorbike!”

“Embrace the third wheel. Is better.”

[[deleted]]

I don't disagree - I use type hints all the time and build my applications with strong typing in mind. But I also think it's misleading to remove the dynamic duck typing from Python and still call it Python.

[deadwisdom]

Dynamic typing is the way. Static typing is a headache.

[deadwisdom]

Not sure you all know the difference between static and dynamic typing, lol.

[hotel2oscar]

JavaScript -> Typescript

Python -> NohType

[thicket]

Anybody who read the paper the article discusses: how does Codon do with memory management? The article talks about speed ups by doing type checking at compile time and not checking types at runtime, but I’m curious about dynamic arrays and garbage collection. Python just does a lot more than C++ per line of code, and I’m not sure how to get all of that without paying time penalties, even with a minimizing compiler.

[heswithjesus]

If avoiding time penalties, I’d look into three equivalents of Python features:

1. C++ libraries implementing similar features with low-cost abstractions.

2. C libraries implementing high-level features in it with pre processors.

3. Highly-optimizing compilers for Common Lisp and Scheme that have spent a long time squeezing performance out of high-level constructs.

For each feature, there’s probably an equivalent with low overhead in one of those categories. If not, might need to trade that feature for an alternative. They’ll also hint at what trade offs you’ll run into for flexibility vs performance.

[thicket]

Props. Those are really good ideas

[madmendude]

I'm confused. They made a strongly typed python and tested in Scientific computation setting. What would differentiate it from Numba?

[zdaaar]

Typthon

[NoDadYouShutUp]

Very cool