timothycrosley

Hi! I said this with more certainty than I should have. Software can always have bugs! For reference, I wrote isort, and my response came from the perspective that I have certainly worked very hard to ensure it doesn't have any behavior that is random or non-deterministic. From your description, it sounds like someone may have turned on force-alphabetical-sort (if this is in a single project). See: https://pycqa.github.io/isort/docs/configuration/options.htm.... You can do `isort . --show-config `, to introspect the config options isort finds and where it finds them from within a project directory. The other thing I could think of, is coming from isort 4 -> 5, I wouldn't think it would fully ignore import groupings, but maybe it doesn't find something it used to find automagically from the environment for determining a first_party import. If that's the case this guide may be helpful: https://pycqa.github.io/isort/docs/upgrade_guides/5.0.0.html. If none of this helps, I'd be happy to help you diagnose what your seeing.

Are you using any custom settings?

FWIW, I wrote isort, but am seriously considering migrating my projects to use Ruff. Long term I think the design is just better over the variety of tools we use within the Python ecosystem today. The fact we have a plethora of projects that are meant to run per a commit with each one reparsing the AST independently, and often using a different approach to do so, just feels untenable long term to me.

> isort's completely random… For example the latest version I tried decided to alphabetically sort all the imports, regardless if they are part of standard library or 3rd party. This is a big change of behaviour from what it was doing before.

This is not isort! isort has never done that. And it has a formatting guarantee across the major versions that it actively tests against projects online that use it on every single commit to the repository: https://pycqa.github.io/isort/docs/major_releases/release_po...

I personally think avoiding getting infected ever, just is so impractical as to not lay out as an option. As evidence more and more is showing both infected and vaccinated people are likely to spread the infection (even if they don't get symptoms) as soon as 3 months after the acquired "immunity". Combined with how infectious delta is, this third choice of never getting infected just feels disingenuous.

This is complete nonsense. If anything VAERS would be over-reported, the people who are most against vaccination, blast it so often I see it in my facebook feed more often than advertisements. Anyone can add to VAERS, and I'm sure with all the antivaxx advertisement of it, they DO. Not to mention that doctors are required to, and report even unrelated deaths that happen right after vaccination. Meanwhile the reporting standards for covid, are the same as flu, nothing's changed there just a bunch of people grasping at straws, toward what goal I can't imagine.

While we are sharing meaningless anecdotes, almost everyone I know (since I live in Seattle) has been vaccinated. No one has reported any issues, a couple have since successfully had a child. None have even gotten a breakthrough infection of covid. Among friends I know from back east, who haven't gotten vaccinated, one had just turned 30, only health issue was obesity. He died. One was 35, best shape of any of my friends, was in ICU for 7 days with double pneumonia. And one miscarriage.

But hey, the good thing is, we also have data. And the data, shows no correlation between vaccination and these problems you're referring to, and yet a VERY HIGH correlation (and some good reasons to say causation) between getting covid and having these issues.

I use this for the isort in browser demo: https://pycqa.github.io/isort/docs/quick_start/0.-try/ it was really awesome to be able to directly use a Python package without any wrangling or modification as is usually required with other Python on the browser solutions.

Articles like this: https://www.news-medical.net/news/20201026/COVID-19-now-like... make me think that's seriously unlikely. I mean unless, you are talking about one of the historical flu pandemics. Yes, this is less deadly then the 1918 flu was in 1918. Then again, I think the 1918 flu would also be less deadly then it was in 1918 if it occurred for the first time today because of other medical advancements.

The problem with examples like this is that simple FileIO operations are optimized across all languages. It would likely have similar speed in very naive unoptimized Python.

Here is an example:

Given `create_csv.py`:

  with open("output.csv", "w") as csv_file:
    for i in range(1_000_001):
      csv_file.write(",".join([str(i)] * 100))  # creating 100 columns per entry out of a million
      csv_file.write("\n")

and `search_csv.py`:

  import sys
    
  for row in open("output.csv"):
    if "1000000" in row.split(","):
      print(row)
      break
  else: 
    sys.exit("row 1 million not found!")

With the first script creating a 1 million line csv with each row containing 100 columns, and the second one being a worse case search (has to make it all the way to last row, has to search every column). The performance is better than what you mentioned on commodity hardware, very unoptimized Python code, and default Python3 installation:

time python3 create_csv.py

  real    0m3.267s
  user    0m2.589s
  sys     0m0.608s

time python3 search_csv.py

1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000,1000000

  real    0m6.132s
  user    0m5.954s
  sys     0m0.162s

Can confirm that I would be happy to collaborate on this project, it looks really cool!

Reminder that we officially live in a post Python 2.x world. I think at this point the correct answer to the awkwardness of threads is to use async.

I'm a principal level software engineer with experience providing strong technical direction for development teams. I have extensive experience designing and developing complex web applications and large scale data processing pipelines. Working with teams to create and maintain both low and high-level documentation while working with customers to define requirements. A knack for simplifying and organizing the complex, enabling teams to scale. Core developer behind many successful Open Source projects. I'm always excited to learn more and to tackle new problems.

  Location: Seattle, WA, USA
  Remote: Yes
  Willing to relocate: No
  Technologies/Languages: Python, JavaScript, C/C++, Ruby, YAML, TOML, HTML, CSS, Sass, LESS.
  Technologies/Frameworks: Spark, Hive, Django, Compass, Zope, QT, PySide, GTK, TK, MEAN, Angular, hug, flask.
  Technologies/Databases and Caches: Hadoop, Oracle, PostgreSQL, MYSQL, MongoDB, Redis, Memcache, ElasticSearch, Solr, Google’s Cloud Datastore.
  Resume/CV: github.com/timothycrosley, timothycrosley.com
  Email: timothy.crosley@gmail.com

It's funny you say this. I've always had a suspicision that every budding programmer I encounter studies forward looking things, and if a young person did study something ancient like COBOL, they'd probably have great job security and stand out for the few companies that need that kind of developer.

Switched to poetry and couldn't be happier. From my experience, poetry wins hands down. It managed to replace flit, remove duplicate dependencies, and maintain stability across machines. All while using the standard pyproject.toml configuration file.

What is that platform? Are you considering Go a platform, or something that was built with it (like Docker)?

And what are the frameworks you consider to be the most advanced in decades?

Most of my complaints, I feel like are pretty well documented: No ability to do Generics, no ability to do operator overloading, no ability to make your own for each style loop objects, very manual and repetitive error handling. These are all simplifications to the language spec at the expense of more complicated usage. For the most part, I've been trying to understand myself how to express why I get a pretty bad taste in my mouth when using or looking at Go code, why it feels so much less productive to me than the higher-level languages. Which is what it has been making dents in more than anything else. I especially wanted to understand this since I do see myself as someone who values simplicity. In the end, it's because I value simplicity in usage, rather than the simplicity be in the language constructs. I'd instead rather learn a slightly more complicated language, and be more productive with every task I write using it. I don't see Go users as cavemen. That was admittedly an exaggeration to express my point clearly.

And yet it still feels like a language out of the 60s or 70s. To me, Go feels like the programming language equivalent of insisting that everyone communicate just by grunting because it's less complex to teach people just grunting than it is to teach them more effective forms of communication. And in theory, they still can communicate all the same things with more grunting! Some people refer to this as simplicity, and in a way it is, but it's simplicity in the language constructs at the expense of more complexity in the usage of the language to form more complex thoughts. There must be a golden balance here, but I don't feel like Go is it for all the fanfare it has been getting lately.

> I'll have to check those out, but one inherent problem is that even if these tools really do solve my pain points, adopting them means I'm leaving my org on a relatively small island, isolated from the Python community. If these really are the holy grail, why isn't the broader Python community adopting them? Please don't take this as me looking for something wrong--whatever Python build tool I use, I'll eventually need support and there's a lot to be said for having a thriving community that has almost always run into my exact problem before.

Only because they are so new. portray was built a few weeks ago and already has a thriving community building around it - but of course it's still a small drop of the whole ecosystem. Older tools I've built like isort, are now ingrained into the community: https://github.com/timothycrosley/isort, but that took years, even without major issues or complaints being present. It just takes people time to adopt new things.

For sure!

> build tooling

All my projects now use poetry for the full build tooling and I love it. No setup.py needed just include any settings in the standard pyproject.toml file example: https://github.com/timothycrosley/portray/blob/master/pyproj..., which can be generated with poetry's help using poetry init.

> text-editor support

I feel like Python with type hints (for all their current flaws) does give you this exactly.

> dependency management

Again I think poetry solves the problems here very nicely

> documentation generator

Personally, I like portray better than anything in the Golang world for this https://timothycrosley.github.io/portray/ I may be biased since I wrote it.

I write a lot of Python tools so I'm genuinely curious because if there were unfilled needs I would want to address them as one of my 52 projects: https://timothycrosley.com/

> type-system

I agree, but if you for instance look at the TypeScript comparison sub-thread, you'll see that all the issues with both the syntax and implementation of the type-system are being aggressively resolved, and likely will all be so by 3.9.

> Good way to constrain the dynamism so performance could be improved

Couldn't agree more!

> environment

I find poetry a joy to use. If you want to bypass venvs all together, there's a lot of work to make that a reality, such as https://github.com/David-OConnor/pyflow.

> packaging

Python in 3.5 added complete zip app support, which has improved this dramatically from my perspective. Extended by things like shiv https://github.com/linkedin/shiv make it fairly complete.

> async/await

This is interesting to me. I prefer async/await in general, because it has become a standard across programming languages and I find it really easy to reason about. I also find channels to be too widely seen as a cure-all, when the only study so far has shown they actually led to an increase bug count. But I don't discount the value of real-parallelism, and am glad to see that Python has been pushing harder on that lately, with things like subshells that allow bypassing the GIL on a single thread.

Answered this below:

> I've been tracking nim, and would agree it's the most promising so far! I feel though that it's trying to be too flexible in many ways. Examples of this include allowing multiple different garbage collectors and encouraging heavy ast manipulation. I'm also afraid it is different enough to keep it from attracting a significant amount of developers from the Python community. Nonetheless, it's something I plan on using and contributing to, since it's the best option so far.

Though, now that another commenter pointed out mypyc: https://github.com/mypyc/mypyc I believe I'll invest my limited free-time in that project instead, as it will allow me to stay within the Python community and eco-system that I love so much.

As far as I understand it, RPython isnt' really meant for actually writing programs in:

> Do I have to rewrite my programs in RPython?

> No, and you shouldn’t try. First and foremost, RPython is a language designed for writing interpreters. It is a restricted subset of Python. If your program is not an interpreter but tries to do “real things”, like use any part of the standard Python library or any 3rd-party library, then it is not RPython to start with. You should only look at RPython if you try to write your own interpreter.

See: https://rpython.readthedocs.io/en/latest/faq.html

I'm curious what you see as the tooling benefits of go?

What would you say are the biggest blockers to becoming realistic? I saw on the README they need tools in the Python ecosystem to start utilizing them, which I can help with starting with isort, beyond that I'd want to do whatever I can to help the project succeed.

> Python is horrible but forced on a huge number of developers because of its ecosystem

This is a really interesting perspective to me. Coming from Python circles, I've heard too often how horrible JavaScript is as a language and how it's only used because the web has dictated it. Doing web development, I've used both, and generally am inclined to agree. I know TypeScript add some niceties on top of it, but it still is stuck with JavaScript baggage. My perspective has always been that Python is by far the better language, which is why people have written that eco-system in it despite the fact it doesn't have a built-in monopoly of the browser.

Python is very healthy at the moment, and still growing! However, I think that makes it even more important as a community that we don't rest on our laurels and we fix the issues we do have. CPU concurrency is definitely one of those issues.

I hate the fact that you may be right, because I really don't like Go in many ways:

- I hate it's module system and package eco-system story. - I don't like its syntax. - I don't like its error handling. - I'd much prefer gradual typing. - I want to maintain the ability to use interactive interpreters. - I don't like the fact that instead of being community driven it is Google driven.

But, anecdotally, I see go being used as a second language to Python more than anything else and at an ever accelerating rate.

> I think a successful modern language has to have the potential for efficient concurrency baked in

I agree with this!

> I don't think there is any sort of long-term future in anything "Python".

I disagree with this :)

I think Python has efficient IO concurrency built-in already with async, and I feel it is likely that it finds a way to work out CPU bound concurrency long-term, as projects like sub-shells with channel communication demonstrate.