
Pytov – C-like syntax Python - Yuvix25
https://github.com/Yuvix25/pytov
======
riazrizvi
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?

~~~
pansa2
> _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.

------
brirec
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.

~~~
jnwatson
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.

~~~
jclulow
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.

~~~
IgorPartola
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.

~~~
mixmastamyk
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?

------
teddyh

      from __future__ import braces
      SyntaxError: not a chance

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

------
burfog
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.

~~~
1337shadow
Cython it is then !

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

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

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

------
arijun
> 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

------
dugword
Python already has support for optional braces.

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

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

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

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

------
zzo38computer
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?)

------
cgufus
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.

------
fermienrico
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.

~~~
pansa2
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.

~~~
dependenttypes
doing simply funname(args): would work fine

~~~
pansa2
How would the parser know that’s a function _definition_ and not a function
_call_?

~~~
dependenttypes
by the :

~~~
pansa2
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](https://docs.python.org/3/reference/grammar.html)

------
ponderingfish
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 :)

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

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

(meaning indentation, mostly)

------
dunefox
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.

