Of course, Drupal has historically been about the community more than the software, but this is not the point. The question here is: what defines the Drupal experience technically, be it for developers, themers, or content authors.

The goal here is to think what Drupyx should (or not) be. Similar previous attempts were designed differently:

• Drupy 1 was designed as a line-per-line PHP-to-Python port of the under-development Drupal 7
• Drupy 2 was designed as a rebuild of Drupal 7 main features on top of Django
• The goal for Drupyx, besides improving the overall Python-fu at OSInet, is to provide a Drupal-like developer experience (DX), themer experience (TX), and admin experience (AX) on top of Python, without an additional framework layer

Drupy 1 shows how low-level porting has been a trap, and actively discourages from pursuing in the same vein without higher-level thoughts.

Discussion transferred to http://groups.drupal.org/node/108604

• The hook mechanism. Refined from its inception to the generalizing categories of accumulators (hooks invokable via module_invoke_all) and alterators (hook_*_alter) while early/historical pseudo-hooks (hook_insert/update/delete…)
• The theme() mechanism, with its overlaid overrides, theme functions and templates
• Render arrays, with their properties (#) and elements (no #)
• Complete renouncement of basic PHP practice expected (forms, superglobals, sessions…)
• Refusal to give in to the MVC for the benefit of practitioners with more academic training than experience
• Storage
  • No ORM, but DB API virtualization
  • SQL mandatory (until D7), NoSQL available (D6 and later)
  • File management
• No mandatory content relationships
  • Taxonomy
  • 9-level deep book structure
• Content (until D6)
  • Everything rich is either a node, comment, or user account (until D6)
  • Every piece of rich content has a unique owner
  • Fieldable nodes (CCK) and accounts (Profile)
  • Terms and vocabularies are plain text
• Content (D7 and later)
  • Everything is a fieldable entity
  • Yes, even fields, although it may not be implemented yet
  • Including user accounts
• “Simpletest”
• IRC #drupal, #drupal-dev: possibly the single most important developer feature
• http://api.drupal.org: an always-up-to-date public API reference for anyone to use without having to set it up on their server

• Multiple themes
• Hierarchical templates
• RTL support
• Presupposed XHTML (until D7)
• Blue

Something will have to give, here: Python seems to be unusable as a PHP-like templating language, thanks to its reliance on indentation.

• Online configuration, without a separate CLI installer/manager (à la Django or Rails)
  • Drush does not count, being contrib an addon
• Themable extensible query/report builder (Views)
• IRC #drupal-support: possibly the single most important developer feature