• (nodebb) 
    if user:
    if user.is_frist():
        self.template_values['ealry_bird'] = users.create_login_time(dateUtils.now())
    else:
        self.template_values['early_brrd'] = users.create_login_time(dateUtils.now2())
else:
    self.template_values['early_bind'] = users.create_login_time(dateUtils1.now())

    There; now all three branches do something usefully different.

  • Sauron (unregistered) 
    if frist: print("wtf");
if not frist: print("wtf");

    (and yes, the above is valid Python, semicolons are a thing in Python)

  • Burner (unregistered)

    Extended case of 'measure twice, cut once'?

  • DeeKay (unregistered)

    Nothing to see here. Business rules changed over time, and the devs changed the stuff that business wanted changed, that business don't want to work the same way that business wanted it to work before this business decision change.

  • (nodebb)

    My best guess for such code is always, that it started out with genuinely different code in each branch, and then slowly, through many small commits, converged to do the same on each branch, but nobody ever taking the step of removing them, for whatever strange reason there may be, probably related to badly implemented code-review processes or performance metrics. Or negligence.

    With such code I'd be really interested to see the code history leading to it...

  • (nodebb)

    No doubt that removing any of the cases will cause a regression

  • wolferitza (unregistered)

    In Python, can user.is_owner() do something else before returning a boolean? Like, I don't know, recalculate and set the status of all users, then send a mail to confirm the email? I only know about .Net enterprisey solutions, where the risk to simplify this code would be small, but not 0

  • wolferitza (unregistered)

    In Python, can user.is_owner() do something else before returning a boolean? Like, I don't know, recalculate and set the status of all users, then send a mail to confirm the email? I only know about .Net enterprisey solutions, where the risk to simplify this code would be small, but not 0

  • Scragar (unregistered) in reply to R3D3

    Sometimes it's not even in the code history, it was added when first making the change and updated to the current version before anyone committed anything.

    This happens a lot with less experienced developers who don't like to commit until they're done(a terrible practice but understandable when you're unsure and don't want mistakes in the commit history forever).

  • Naomi (unregistered)

    Comment held for moderation.

  • (nodebb)

    As the Scarecrow said,

    Of course, people do go both ways!

  • Oracles (unregistered)

    We get paid by the pound, so dammit, we're gonna add some pounds.

  • (nodebb)

    Honestly I never understood the appeal of Python beside being a nice language for scripts and people lacking experience or general coding skills. I don't see how it would be well suited for something like HTTP handling but maybe that's just because Python to me is a total black box beyond what I see from time to time and then often have to rewrite into something proper.

  • anonymous (unregistered)

    "I got paid by the line."

  • LZ79LRU (unregistered) in reply to anonymous

    I get paid by the bit. My managers thought I was crazy until I switched all code files to UTF-32. :)

  • Nonymous (unregistered) in reply to wolferitza

    Bold of you to assume that user.is_owner() will return a boolean. I mean, it might, and in a sensible solution it would. But given that we are already on TDWTF, I wouldn't count on that without actually checking the implementation myself.

    But yes, there's nothing stopping that function from doing whatever monstrosities someone might have fancied to implement there, including but not limited to the things you listed.

  • (nodebb) in reply to MaxiTB

    Python is a programming language, and it can do pretty much anything that other programming languages can do. I don't see why you would think it's less suited for server-side web programming than PHP, Perl, or Ruby.

  • Blue Raccoon (unregistered)

    The illusion of choice

  • (nodebb) in reply to MaxiTB

    "Honestly I never understood the appeal of Python beside being a nice language for scripts and people lacking experience or general coding skills. I don't see how it would be well suited for something like HTTP handling but maybe that's just because Python to me is a total black box beyond what I see from time to time and then often have to rewrite into something proper."

    Python is the closest thing we have to "executable pseudocode". In plain English, Python operates on the principle that if the computer can figure out something on its own, it should do that. Sure, it sacrifices a bit of performance but it also leads to fewer lines of code and more easily readable code (the "semantic gap" is smaller). Not every piece of code out there has to be performant. If your code's execution time is 98-99% network requests for example, does it really matter if the code is not as performant as it could be?

    Also, I personally find mandating correct indentation instead of leaving it up to the programmer a good thing.

  • (nodebb) in reply to kurkosdr

    Also, I personally find mandating correct indentation instead of leaving it up to the programmer a good thing.

    Mixed bag there. Consistent indentation should be enforced by mandatory code formatting tools, but I find an explicit open/close syntax like C-style {} blocks good to have. Basically with proper code-formatting and {} combined, you have two visual indicators of code structure, which I find to help readability.

    It also allows powerful programming constructs to be implemented as plain function calls with an anonymous function as argument, which in Python is limited to expression-only functions, due to the syntax not allowing full function definitions in such places.

    So where in JavaScript you'd have

    function parentFunction() {
    // ...
    dispatch(() => {
        // callback code
    });
}

    in Python you end up with something like

    def parentFunction() {
    ...
    def callback():
        ...
    dispatch(callback)

    Personally I find the JavaScript version more clear; It communicates “this function definition is only ever needed in this one place, and nowhere else”, while the Python version doesn't communicate that, and it forces me to come up with a name for a function that is used only once.

    Another example is “pipe-style processing” (.map, .filter, .foreach, ...) which in JavaScript make use of full-fledged function expressions to allow a pipe-like postfix notation and allow arbitrary code blocks in the callback functions. You could do something like that with decorators, but function decorators are usually expected to return a function, not a value, so it would feel like abuse of a language feature. And it is directly a consequence of “block structure by indentation”.

  • (nodebb) in reply to R3D3

    And in some languages like Perl, you can do nifty things like

    sub parentFunction($x) {
    ...
    dispatch sub ($y) {
        $x += $y;
    };
    ...
}
  • (nodebb) in reply to gordonfish

    dispatch sub ($y) { $x += $y }

    What version of Perl is that? In the Perl that I used, you were not able to declare parameters like that, but had to do weird stuff like

    dispatch sub {
    my ($y) = @_;
    $x += $y;
}

    Exact syntax may be nonsense. Haven't used Perl much since switching to Python for most tasks.

  • (nodebb) in reply to R3D3

    Since Perl 5.20 IIRC, one can enable sub routine signatures. The older method can still be used and has its uses.

    Please see https://perldoc.perl.org/perlsub#Signatures for more info.

Leave a comment on “All Roads”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article