Pytov – C-like syntax Python | Hacker News Reader

Pytov – C-like syntax Python

github.com

46 pointsYuvix2564 comments

Curly braces designate scope in C like languages:

    int i = 100;
    std::cout << i << std::endl;
    if (1) {
        int i = 200;
        std::cout << i << std::endl;
    }
    std::cout << i << std::endl;

giving

    100
    200
    100

They don't seem to serve such a purpose in Pytov. Eyeballing the source, it looks like you'd get this:

    i = 100
    print (i)
    if (True) {
        i = 200
        print (i)
    }
    print (i)

giving

    100
    200
    200

So what's the point?

> it looks like you'd get this

Yes, you would - variables in Python have function-scope, not block-scope.

It doesn’t look like this project changes anything about Python except trivial bits of syntax.

So would you in C if you do not redeclare the variable inside of the block. Also in JavaScript (although in JavaScript the type is not declared; in C it is). I don't know how it is working in Python, though.

Not sure if you're aware, but you could just write that as:

    int i = 100;
    std::cout << i << std::endl;
    {
        int i = 200;
        std::cout << i << std::endl;
    }
    std::cout << i << std::endl;

And since PyTov is supposed to be C-like, this might be a better example:

    #include <stdio.h>
    
    int main(void) {
        int i = 100;
        printf("%i\n", i);
        {
            int i = 200;
            printf("%i\n", i);
        }
        printf("%i\n", i);
        
        return 0;
    }

Also, the same would occur in C(/C++) if you didn't shadow the variable in the block scope and just called:

    i = 200

> Curly braces designate scope in C

It's not the curly braces that create the scope as such. It's the block, and the curly braces just happen to create the block. In C++ you can even do this, for example (I was surprised to find it doesn't work in C):

    int i = 1;
    if (true) int i = 2;
    std::cout << i << '\n';
    // Prints 1

In any case, the semanics of blocks (whether they create scopes) is totally orthogonal to the syntax of blocks. You can just as easily imagine the reverse: the current colon-indent syntax where blocks do create scopes.

Another issue, which other replies have alluded to but not quite spelt out. You'd need to add a syntax to distinguish between regular assignment and declaration. In C you can still choose to assign to the outer-scope variable from a nested scope of you wish, so you don't want i=1 in a nested scope to always declare a new variable that shadows a variable in the outer scope.

Oh and one more thing. Your snippet (or equivalent) won't work in all C-style braces languages: in C# it is a compilation error to shadow a variable from an outer scope in the same function (presumably because it's a common source of bugs and extremely easy to just choose a different name for one of the variables).

This probably makes me sound like an old man, but probably the biggest thing keeping my interest in Python too low to really learn it was the syntax. I really like the c-like syntax of many languages, and Python’s use of significant whitespace instead of braces just seemed too foreign to me.

That said, even if it gives me the syntactic sugar I crave I don’t know how much I’d be willing to trust a little-used language that compiles to something more common, because I’d worry about how its maintenance goes.

If the software goes unmaintained, would the syntax of Python outgrow it and break it? Maybe new features wouldn’t be usable? So while that syntactic sugar is indeed tasty, I don’t think this is what I need to get going in Python.

I just put 'pass' at the end of each block... Emacs could actually do proper auto-indenting then.

Thing I know from implementing simple line protocols. Pythons encoding just blows. Languages with defined begin and end tokens are better.

Dumb question, what's the use case for a line protocol?

Just stupid serial protocols to talk between devices. Often you have problems with picking commands and responses out of noise and or garbage. Think half duplex RS485. Protocols that use one token for delineating messages have poor error recovery/synchronization. I think pythons grammar is rather poor as a result. Other languages are far better. It's important because it effects tooling because tooling often has to deal with broken input.

Eh, I wouldn't assign that too much importance. Most C/C++ tooling practically gives up on a missing closing brace and almost never gives the right error message.

C and vastly more so C++ have a lot of other problems. C compilers can give the right error message 95% of the. But They have an excuse since they are older languages. Python was developed in an era when people knew better.

Java and C# are examples of well designed grammars. Tooling was a first class requirement for C# and it shows. Where python will never have great tooling.

haha yes I wish emacs could do that too but the thought of a redundant pass in every block would probably bother me more than the lack of auto-outdent.

That colon that starts every indented block is like an unmatched opening brace though.

I thought Pascal was weird, but that's because I learned BASIC first. I thought C was weird but that's because I learned Pascal before.

There happen to be a handful of popular languages that are C-like in scope syntax, but it is important to get beyond the first thing you happened to learn. It is like only eating the cuisine from the country where you were born.

I learnt BASIC when I was young, and then (Borland Turbo)Pascal after that, and C family languages (including C and Java and such) after that. Then I learnt Python, and even wrote a lot of it at Uni and for various jobs -- enough that I'm pretty firm in my distaste for significant whitespace, and I don't believe it's because I started with C.

It may be popular, but it presents a number of challenges in Python and in other languages like YAML. If you're going to buck the C trend, at least make it somewhat ergonomic like Lua which I learnt recently and kind of like.

It’s funny both you and the GP comment followed the same exact steps as I did. I guess I technically learned Pascal with with Turbo Pascal and also with Delphi. But yeah it’s funny because Python is where I ended up. What I like about it is that it seems very pragmatic. There is no sloppiness in it but also no high dogma of how things ought to be if you want to be sure your program is correct. It lets you get stuff done and gets out of your way.

Me three, and I think the intented blocks were a masterstroke. Why do so many others have redundant braces or begin/end markers while still need to indent?

I started with x86 Asm and was exposed to C and Pascal at roughly the same time (as well as XPL0: https://en.wikipedia.org/wiki/XPL0 , which is described as a mix of the two but is really like "C with Pascal syntax"), and much prefer the brevity of the C syntax. I suspect that's the reason a lot of other languages also adopted it.

Are chillies the braces of cuisine?

If you can’t get over the syntax differences I can’t imagine why you’d ever want to program in Python. You don’t need to force yourself to like or use Python in the same way some people just don’t want to eat fish, or choose to be vegetarian. It’s not for everyone. Why try to shove a square peg in a round hole?

Lots of great statistical and NLP libraries are written in Python. I'd actually argue Python is one of the few languages without a great alternative for certain niches right now.

Then have a look at Julia, you can use all those libraries from Julia and its own as well.

Interop comes in many flavors. If I were to consider Julia a replacement for Python, I'd need to know that Julia can interop seamlessly with it, like Kotlin can with Java.

How do you feel about the user experience for Julia/Python interop?

Julia has an excellent interop story with many languages. Probably C, Fortran and Python are the most polished.

Check out https://github.com/JuliaPy/PyCall.jl

I can only tell you that I consider it excellent and that I would rather use Julia with PyCall than Python.

I strongly dislike python, but I do have to use it because so many libraries are written for it.

It's the pragmatic choice.

Look at Julia and PyCall.jl, as well as its own libraries.

Except, if your job requires it.

I am the opposite. I love the whitespace significant syntax in Python. I indent my code in languages like C and Java anyway, so why bother with braces. Also, a missing brace takes a long time to find, because autoformatting tools go crazy and the error isn't usually quick to find by the compiler so it fails tens of lines below where the brace is actually missing.

Opposite. I can't stand languages that require programmer to do menial tasks such as add additional punctuation to indicate blocks that are clear from indentation. Or for end of line when there's a carriage return.

And that produce visual noise and based on many formatting standards enforce wasted vertical space (curly on its own line) being able to see more code on screen without scrolling.

I have to type that whutespace. Whitespace indentation and line breaks are the most significant visual elements. Why would the compiler ignore that?

  from __future__ import braces
  SyntaxError: not a chance

I did not know this and it’s quite funny. I’m glad there’s not a chance :)

It's backwards.

I can imagine preferring Python syntax. I can't much imagine wanting Python slowness, which is inherent to the language semantics. People can disagree about syntax, but who wants slowness?

Converting is probably just a matter of a Makefile rule that would turn the code into standard C. It's just another code generator, like lex or yacc.

Cython it is then !

I'm not sure if I'm a fan of the switch syntax. It looks neither like C nor Python.

Please keep in mind that switch statement is coming to python!

Really? Hm. It will be like the := syntax, an easy way to confuse newcomers.

I know, I don't like it too, maybe I'll fix it one day...

> python, but tov (good)

More like “python, but rah (bad),” from where I’m standing.

I’m surprised that there’s anyone who prefers brackets to indentation, unless the joke is going over my head. It’s much easier to spot an incorrectly indented segment than see that there are 3 closing brackets in one spot and 2 in another instead of 2 and 3 as it should be

Python already has support for optional braces.

  def say_word(word): #{
    print(word)
  #}

being technically correct is the best kind of correct.

What??? I had no idea. You’re beautiful.

In case your not also joking, these are just comments containing braces.

There are some functions that just aren't readable without heavy commenting.

Yup joking. I cheer people up with humor. I try to joke while I’m depressed but it just makes Me sound like an ahole.

Sir (or Madam) you are a genius!

You can also use #begin and #end, of course.

Automatically fixes mismatched braces as well!

Very nice. But with the linked project, although the braces are optional, when you do use them I'm presuming they're checked for correctness (i.e. they match the indentation level and are properly matched).

I had never heard "#" pronounced "optional".

OptionalTheMoreYouKnow

Is the word "pass" still needed? It should look for empty braces and add "pass" automatically in that case, I should think, isn't it? (Doesn't "pass" just means doing nothing?)

Regarding indentation versus braces: In the beginning, I always thought python's only weakness is that it relies on indentation for code structure and I feared that some day my code will be messed up because of that. However that fear quickly disappeared as soon as I got my editors set up correctly... and the mess up never happened.

Still love pythons syntax in general.

We might as well chuck away "def" for a function signature. When I started learning python way back, this particular aspect of Python was an eye-sore. Why wouldn't they use any one of these: func, function, fun, etc. or just like C, no need for a word. void foo(){} is already sufficient structure to indicate that its a function.

In the absence of a return type, and with an LL(1) parser, there needs to be a keyword to indicate the start of a function definition. `def` is a little unusual, but it's also used by Ruby.

I once designed a Python-like language and used `function`, because the language made a distinction between `function`s and `method`s.

And lispy langs mostly use "define…" keywords.

doing simply funname(args): would work fine

How would the parser know that’s a function definition and not a function call?

by the :

That's too late. The parser needs to know whether it's looking at a definition or a call before that - for example, to know whether to parse "args" as a `parameters` or an `arglist` [0].

[0] https://docs.python.org/3/reference/grammar.html

Here's a code snippet using SRFI 49, for Scheme. (A 2003 formalisation for a macro system that had been rocking around for a few decades, for a very old Lisp):

    define
       fac x
       if
        = x 0
        1
        * x
          fac
           - x 1

Python's keywords are sometimes shorter, but they are familiar to most Lispers, which some of the founders were.

This is fantastic - I have always loved C-style syntax. The braces and indentations make code easy to read. I am always scared of Python's 2/4 space requirements - hard when you wear thick eyeglasses :)

There are no such requirements, those are guidelines. All that’s required is you indent at all, and that it’s self-consistent.

I remember finding out about a python-like C, which in my view is much more interesting.

(meaning indentation, mostly)

I never liked C-style syntax. It looks kind of... cheap, I guess. I don't know, I never got used to it, I prefer Python/Julia/Haskell etc.

Reply on news.ycombinator.com