The trick is to assign someone the responsibility of the upgrade and give them the authority to tell the other developers how their newly added code shall look like. This will get you there eventually.
Seen it work on a >1 million SLOC project.
The trick is to assign someone the responsibility of the upgrade and give them the authority to tell the other developers how their newly added code shall look like. This will get you there eventually.
Seen it work on a >1 million SLOC project.
I’m definitely looking forward to Unpack[…]. This makes kwargs typing manageable for the first time.
The rest is nice too, but no game changers.
New money laundering scheme?
This seems to be a thing with Dell. My Dell doesn’t work well together with my (Dell) monitor!
Well, you can still have the up-to-date plugin, you just have to pay for it now.
Since working with SQLAlchemy a lot (specifically it’s SQL compiler, not it’s ORM), I don’t want to work with SQL any other way. I want to have the possibility to extract column definitions into named variables, reuse queries as columns in other queries, etc. I don’t want to concatenate SQL strings ever again.
Having a DSL or even a full language which compiles to SQL is clearly the superior way to work with SQL.
I’m wondering if a field with more detailed information would be helpful for the users. Moderators might want to clarify or explain in more detail the function or intention behind a tag. This doesn’t seem to be considered in the RFC.
deleted by creator
Depends on how large your Python projects are. If you have a million lines of Python code, navigating quickly and directed is invaluable.
I used plain vim before for Python projects, but these never grew above 50k lines of code.
I never got so far, but had a system built which some parts of what you described. It was incredibly relaxing to develop with it. Our take as a team was: boring is better, we don’t want to be paged on weekends.
It teaches you to think about data in a different way. Even if you never will use it in your products, the mental facilities you have to build for it will definitely benefit you.
Completely agree. I really love SQL, but I hate it’s syntactic limitations. SQLAlchemy was my band-aid with an after-burner to make it bearable (and maintainable).
Python development without PyCharm (or IntelliJ) and the IdeaVim plugin is unbearable. List usages is a game changer. Don’t care much for anything else.
You could be onto something. On of my first language was “dBase” (early 90s) which, through it’s style, enabled you to build complex user interfaces with data storage very quickly. I only built small things with it at the time, but it influenced my desire for some better solutions than we have to today.
They don’t want you to see the “if benchmark_xyz { do less work }” blocks of code.
The way I perceive PRQL is somewhat like SQLAlchemy-Core (the SQL expression layer, not the ORM). Almost a 1:1 mapping to SQL but softening the rough edges in SQL when constructing more complex queries dynamically, in particular: no function calls, no real variables, only string concatenation. While SQLAlchemy-Core lets you even extract sub-queries into variables, I don’t know about how powerful PRQL is in this regard.
From what I see from the docs I’m rather hopeful though.
Sir, your washing machine will arrive on Wednesday. Be sure to be at home at around 3.
Can the ozone be countered by a reverse polarity static charge? Not sure how the laser printer do it, but recent printers barely emit ozone. I think it should be possible.
Can the ozone be countered by a reverse polarity static charge? Not sure how the laser printer do it, but recent printers barely emit ozone. I think it should be possible.
You can write selects with many joins, as long they are regular and either add a column or reduce the result set. You have to write the joins explicitly though. Just shoving all of the restrictions into the where clause will definitely confuse everybody.