And Guido is stepping down as BDFL.
I guess PEP 572 was really that rough. It sounds like an anti-feature in Python to me, but what do I know? I’m just some guy.
I tried to read the PEP, but got bored before I read enough to understand what was up.
Ok, I figured it out.
Let’s say you want to write some code like this:
x = function()
if x:
do stuff
Now you can save a line of code by doing this
if x := function():
do stuff
The x := y will assign the value of y to x, but will also return x so it can be captured by an of, or a for, or whatever else. Since assigning something to a variable and then doing something with that value is very common, this := can save a lot of lines and indentations if used liberally.
The negative seems to be that it reduces how easy it is to read code.
I’m kind of ambivalent. Will I use this? Maybe? The thing is, I already try to avoid using lambda since it makes code hard to read.
At least := prevents the single/double equals typo. I think the only time I’ve ever used it in any other language is by accident. E.g.
if (foo = bar) { ...I wonder. Why is := even needed? Would it really be a problem if = also returned the value after assignment?
You probably would have a lot of bugs if people doing stuff like this:
x = False
y = False
if x = y:
print("Why won't this print!!!")
# it's because x = y returns x, which is False, but x == y would return True because x and y are the same.
But other than that? It would actually be nice when working in the REPL to do stuff like this:
x = awholebunchofstuff()
and not have to immediately follow it with
print(x)Before I even skimmed the PEP, regexp matching was the first thing that came to mind. It’s even somewhat idiomatic to represent it with :=. Nice.
I approve of the slap roof meme.
1 Like
That’s what I’m saying - I think the only time I’ve “used” it in any language was that bug.
Compiler warnings to the rescue.
But only if you have them turned on!
As an experienced C/C++ programmer though, the whole =/== thing is a misfeature. I’ve been bitten by it more times than I can recall. Pascal, Smalltalk, etc. got it right with :=/=. Sadly, most newer languages often followed C’s example.
1 Like
Cue the feeling I get when the codebase I look at daily is littered with SuppressWarnings…
1 Like
Fucking turn them on, then.
Which ones? -Wall? -Weffc++ -Wdeprecated? 
Watch out for false alarms, especially if you have it set to treat warnings as errors.
Plus compiler warnings aren’t perfect either. Ideally, you’d probably want to use some sort of static analyzer like clang-tidy and whatnot as well. So you’ll need to add even more to your tool chain, when really, all this crap ideally should be caught using the compiler with default settings. If and only if you really, really know what you’re doing, should you be allowed to somehow, using some syntactical construct of the language, perform crazy stuff that normally would be very dangerous.
At my work we actually are using this thing called Codacy.
Honestly, you don’t actually need to use this service. Everything it does you can do yourself with free tools. Either use plugins in your editor/IDE or commit hooks or stuff like that. It’s just linters and other static code analysis tools with a fancy UI. I’m not paying for it, though, so whatever.
The thing is, the integration with github is slick as fuck. It shows up right there on the Github merge request page. Then you fix your shit before you actually merge. Pretty sure you can set it to prevent merging anything that breaks the rules, stuff like that.
Admittedly, one reason why I like CLion so much is that it comes with clang-tidy and highlights fishy looking C/C++ code in the editor very nicely.
Codacy looks pretty cool, especially if you use Github. We don’t use it here, however. We are eventually planning to switch to Git at some point, but Github was determined not to fulfill all our requirements with respect to issue tracking. The powers that be are still trying to decide what to use.
Not using Github is understandable. There are lots of reasonable alternatives. The Linux Kernel just uses email.
Not using Git in 2018 is crazy town.
I recently learned our dev team uses subversion. Experienced Sysadmin lfw
Well, Mercurial is an acceptable alternative to Git as it offers pretty much all the same functionality (at least the functionality that matters) and is quite a bit friendlier to use. Heck, Python and Mozilla use Mercurial, for example.
If you talk to any of the engineers here, we all agree that not using Git is bad. Our code base pre-dates widespread adoption of Git, so we need to move all our stuff out of our old tool, Accurev, into Git, which isn’t exactly trivial (though someone did write an Accurev-to-Git importer). Accurev is also our bug tracker, so we need to figure that aspect out as well.
A few smaller projects have switched to using Git though. It’s just our main product that’s still on the old tool.
And as for everything else, it’s a time thing. We need time to do the switch, get everyone up to speed with the new tools, etc.
I’m sure people can manage with it just fine with Hg, and it’s probably better than SVN, but I can’t recommend it. Even if you want to debate features and philosophy and all that, the fact is that everyone else is using Git. Not using it creates a huge practicality problem of integrating with anyone else’s code ever. Also most tools out there these days include Git integration. Using Hg is gonna mean you are missing out on all that, and may have to build your own integrations when they don’t exist.
Hg has a time and a place: for teams who are already using it to manage a lot of code.
No one should start using it who isn’t already using it.