Cython is a fantastic and underrated language. It basically allows you to write C using Python syntax, and to also write Python in the same source file. Basically if you use a dict or some other nice python functionality, your code will run at Python speed, but if you add a few type annotations and whatnot it runs like C. Not to mention that you can import and use C libraries. Mix and match Python and C as required for the ultimate balance of speed and convenience. It's great.

I disagree (strongly).

Cython is nice to save some typing for generating wrappers. It is a very tough language to work with for actually implementing things that you'd want to do in a low-level language, because it's severely underdocumented and underspecified, but extremely complex at the same time. To actually see whether the code as written is correct, one must almost always cythonize it and dig through the generated, verbose and hard to decipher C code. Both the language and the compiler have a ton of things I'd call bugs, induced by the complexities and mismatches in the type system. E.g. it's awkwardly easy to have Cython call some PyObject function on something that isn't a Python object.

No thank you.

PS: Also avoid using setup.py Extension, including Cython's variant, if you can at all.

(Source: I've been maintaining software containing Cython stuff for some while, written and reviewed quite some of it, too.)

I suppose I almost solely use Cython for numerics, which seems to be reliable. Anything that's not numerics is not usually the bottleneck for my code and so is left as Python. So I can't comment on problems trying to use the C end of the Cython continuum as a general purpose replacement for C.

For my numerics at least I can't say I've had to dig through generated C. I generate the annotated html to ensure that what I thought would translate to pure C without python API calls indeed has, but I've never had to actually read the C it generates.

The annotated mode is indeed very nice to browse the generated C code, although I still needed to manually read the .c in some cases. The annotated code elides things like the (many thousand lines of) Cython support code; but since few things are documented I sometimes even needed to dig through those, deciphering nested #ifs and whatnot just to see whether the code would be correct.

E.g. what does `cdef char *something = somethingelse` give me. Even if you know the type of somethingelse it's at best a guess. (Bonus question: Say you know somethingelse is going to be a Python bytes object. Does something point to a copy?)

Cython can wrap libraries but there are better alternatives for doing that. It is of most benefit when doing computation on NumPy arrays. That way you pass in and out native C objects, do bulk computation in compiled code, and never pay the penalty of accessing a PyObject. If you can't guarantee that then there is not much point in using Cython although you still do get a speedup on PyObject code by bypassing the bytecode interp.

> All I could wish for is C with native features of python (dict, list comprehensions, libs like sqlite and xml...)

So... C#?

> All I could wish for is C with native features of python (dict, list comprehensions, libs like sqlite and xml...)

Many had these fantasies before realizing the intrinsic conflict. First, it is merely a library away to have high-level data types in C, but that is not enough. So the wish is not merely to have, it needs to be native. What does that mean? First, it needs syntax support. That can be managed by macros and, in c++, templates. But that is still not enough. So the wish really goes into the semantic level, that is, high-level data types that do not need worry or understanding of its low-level subtleties. But, you now should realize, that without understanding and worrying about these low-level subtleties, there is simply no reason at all to use C versus, e.g. python. We use C because we want to program in low-level that is impossible or difficult to do in the other languages, e.g. efficiencies. Wanting to do low-level programming and refusing to distinguish and understand low-level subtleties are intrinsically conflicting.

So any such effort of adding high-level data types natively to C will end up with syntax full of details of low-level subtleties: types, memory management, runtime, etc. The language will no longer be simple and they still doesn't feel like native (as python).

So honestly don't make another C++. Embrace C. Use Python.

> I'd take most thing that make C and python popular, to make something as simple as possible, and as similar to C as possible. (...) What I think is the most important thing for a language is that it must be easy to learn and read for beginners. There is no need to have advanced features for advanced programmers.

I understand that your aim would be to create a 'beginners' language. But why keeping the syntax of C? C's syntax is not so much appropiate for beginners, Python is.

C's advantage, or reason-to-be, was to create a better alternative to assembler. That is, to create a language almost as fast as assembler, but with higher-level constructs. Still, C is a pretty "low-level" procedural language. That's why all the features for manipulating pointers, etc. C wasn't really thought as a beginners' language.

From your description, perhaps you would better keep Python syntax as is, and perhaps simplify some features a little bit?

Python may have its failures, but the syntax is so clear that it is very suited to beginners. And I dare to say that it is already used in many introductory courses to programming.

I doubt you would agree, but you're somewhat describing Perl. Perl written by a C aficionado is very C like...similar looping and control constructs, pretty direct C library mappings (sockets, for example, are almost exactly the same), etc. Map() and grep() are fair approximations of list comprehensions. And popular libraries are abundant.