6 ms·

Why don't languages like Python have the concept of a C-like struct? Seems like it should be straight forward to have with no downsides that I can think of.

• bkul 9y ago
  Seems to me that classes generally replace structs in such languages. I know they're not the same thing, but classes have the features of structs (and much more) at the cost of performance.
  • smitherfield 9y ago
    > classes have the features of structs (and much more) at the cost of performance. Not true; C++ classes have zero performance overhead over C/C++ structs (because they're just another word for the same thing). Of course Python classes have a lot of costly features that C++ classes don't have, but the notion of a "class" (with methods, constructors etc) is not one of them.
    • kronos29296 9y ago
      And also makes them look more complicated with more syntax. C++ has all those features that I will never know without adding performance. But people don't use Python for performance but ease of use. In C++ ease of use is given up for the sake of performance. In python it is the other way.
    • hasenj 9y ago
      Don't C++ classes (and therefore structs) have a hidden vtable?
      • taejo 9y ago
        Only if they have virtual members.
      • plq 9y ago
        vtable is always "hidden". It's only there when there is at least one virtual member defined. Sole difference between class and struct in C++ is default visibility. class A { int a; // private } struct A { int a; // public }
  • bpicolo 9y ago
    A lot of people (my whole company, for sure) are using namedtuples essentially just as immutable structs. This is a case where classes aren't sufficing. To be fair, it's at least a little bit the functional-programming, immutability bandwagon, but either way it's helping maintain large python apps with many devs. Python36 gradual typing also helps here though, and am definitely interested to see if that changes the game a bit
• chubot 9y ago
  I had this question for awhile too, but I realized after hacking on the Python interpreter that it breaks the execution model: - Python compiles a single module to bytecode at a time (.py to .pyc) - It interleaves execution and compilation -- imports are dynamic, you can put arbitrary computation between them, and conditionally import, etc. If you had structs, then you would need to resolve names to offsets at compile time -- e.g p.x is offset 0, p.y is offset 4. That's a form of type information. Types can be defined in one module and used in another, and Python really has no infrastructure for that. Nor do any other dynamic languages like Ruby, Perl, JavaScript, Lua, or PHP, as far as I can tell. They are all based on hash tables because deferring name lookup until runtime means that I can start executing "now" rather than looking all over the program for types. It probably helps a bit with the REPL too. The need for type information in a translation unit is also what gives you C's header file mess, so it's not a trivial problem.
  • pjmlp 9y ago
    Common Lisp, Dylan and Julia do offer such support. It is a matter of caring about it, and having JIT/AOT support as part of the standard tooling. C header file mess is caused by its designers ignoring the work outside AT&T and not bothering to implement a module system.
    • agumonkey 9y ago
      modules are unloved children, I recently used scheme48 which has a very nice module system (funny considering how old, but anyway) even though other don't have one..
    • nnwedwe 9y ago
      Can you point us to a public repository that contains your output? It would be very instructive.
    • flavio81 9y ago
      > C header file mess is caused by its designers ignoring the work outside AT&T and not bothering to implement a module system. To be fair to them, they wanted to create a language whose compiler did fit into the limited hardware they had. It's not their fault that UNIX had so much success and the world largely went there ignoring most of the progress made in programming tools and languages during the 70s.
• pjmlp 9y ago
  If you mean dynamic languages, Common Lisp, Dylan and Julia do have such concept.
• ubernostrum 9y ago
  Python does have the ability to create and use packed byte objects which are interoperable with C structs. The interface is even in a module in the standard library called... 'struct'. The main issues are: 1. The C-struct interoperability is cumbersome, since really it's just byte objects with some helper functions to pack and unpack them according to a given definition (so you need both the bytes and the correct format definition in order to turn it back into native Python objects), and 2. Most people already are using one of a few different struct-like things depending on their exact use case and preference, and getting everyone to agree on a One True Struct Object to build in to Python or its standard library is probably never going to happen. Just look at namedtuples -- they were an attempt to take the most struct-like thing in Python (the tuple) and add extra optional struct-like behavior to appease people who were frustrated with the lack of structs, but of course people rant about them for having a weird internal implementation and for having behavior that makes them backwards-compatible with plain tuples.
  • eesmith 9y ago
    ctypes can also be used to create C-like structs. It has the advantage over the struct module that the elements can be accessed and modified in place.
• Pxtl 9y ago
  The tuple was Python's answer to the C-Struct, really. If I want to duct-tape 4 values together and hand them around as 1, the convention was to use a tuple. Tuples don't name values, but that's actually important for performance - Python is an old-fashioned dynamic language that still uses hashtable access for everything, but tuple indexing is a simple array offset. Considering Python's age, reducing that endlessly-nested series of hashtable hits was important back in the day.