• programming languages do matter; choice can hugely affect the end result
• whitespace enforcement the “best worst feature” (other languages’ worst features are much more severe)
• Unicode handling is a pain
• lambdas
  • should just be called functions (increases acceptance)
  • cannot contain statements
  • binding issues in loops
• threading is haphazard (GIL is evil) — however: CPython implementation issue, addressed in v2.6 – “it’s different, not necessarily insufficient (e.g. using underlying OS)”
• confusing packaging situation (setuptools, Easy Install, distutils, eggs, buildout, PyPI, virtualenv) – “solved, but people disagree” – “Easy Install sucks, too magic” – “not a Python-specific, but OS-level task” – problem is hard to solve, as there’s a variety of different usage scenarios
• infinity, NaN support (IEEE 754)
• floating point printing (0.1 becomes 0.10000000000000001) — fixed in v3.1
• division — fixed in v3.0
• decorators (“@ is scary, unfamiliar syntax”)
• argument list splicing (e.g. zip(*l)) – “unfamiliar syntax”
• some modules only exist on certain platforms
• positive aspects
  • everything is an object
  • object instantiation (no new keyword – i.e. just like calling a function)
  • generator expressions (from Haskell)
  • chained comparisons (0 < = x < n) - though largely unknown, and allows 0 < x > a or 0 < x in L
  • Iverson’s convention (x < y evaluates to 0/False or 1/True) - "open to abuse"
  • access control (public, private etc.) – not enforced (“advisory [bicycle] locks”) – likely more a social than a technical problem
  • fractions (from v2.6)
  • power (x**2)
  • explicit > implicit (unlike this in JavaScript, for example)
• “Python sucks because sometimes it has to run on Windows”

slides available

Obviously some points were quite controversial (whitespace FTW!) – which is what made the session so interesting.

1. retitled What Sucks About Python in the official program

• minimal, no-API approach; no need for boilerplates
  however, a lot of optional framework-y functionality is provided
• convention over configuration (automatic discovery of test_*.py, def test_*, class Test*)
• py.test overrides AssertionError built-in, then re-runs statement to provide details — avoid assertions with side-effects!
• skip tests only for platform and dependency issues; use @py.test.mark.xfail for “expected to fail”
• funcargs introduced in v1.0 to replace traditional setup methods for fixtures (user & provider, loose coupling); allows for more flexible grouping
• print captured by default, only shown on failure
• internally makes use of its own hook architecture (i.e. many features implemented as plugins)
• yielded tests are deprecated (due to internal ambiguity); recommended to use pytest_generate_tests instead
• interesting plugins: coverage and PyLint integration
• can be used to run non-Python tests (e.g. for JavaScript)
• supports distributed testing (load balancing with multiple CPUs or remote machines, testing on multiple platforms)
• might be renamed (“I wish I’d named it differently”)

Holger Krekel has also published his slides (PDF), which are well worth a look.

• name
  When asked about about the name (which had confused us), humorously dodged the question multiple times. Not entirely sure why…
• reinventing the wheel
  Bespin makes heavy use of canvas, essentially reinventing the rendering of text and layout (using their Thunderhead toolkit).
  While contentious with regards to accessibility and web standards, this is necessary due to performance reasons.
  (Note: Not JavaScript is the bottleneck here, but the DOM is.)
• offline capability
  Currently Bespin should be considered a “hosted application”, requiring a server-side component.
  Personally, I don’t like the idea of relying on the “cloud” for my primary editor.
  While the Bespin team is planning to use Titanium eventually, Joe said it shouldn’t be too hard to integrate TiddlyWiki‘s file-saving code (similar to the XWiki integration), essentially creating a stand-alone HTML application.
• tools integration
  Since Bespin runs in the browser, it might be hard to integrate external tools (e.g. PyLint).
  I’m concerned that this might mean the respective server must support such applications, stripping away another bit of developer independence…
• active community
  There’s already an active community of hackers making use of and contributing to the project.
  (We’re also considering using Bespin as a front-end for TiddlyWeb.)
• Ubiquity as Firefox extension API
  On a slightly unrelated note, it has been suggested that Ubiquity might be integrated into Firefox, which in turn could lead to a pure-JavaScript API for extensions (currently writing Firefox extensions involves a lot of overhead, e.g. creating XML documents). That would of course be most welcome!

• XNA (Microsoft’s game development toolkit for Windows and Xbox 360) live demo was fun, and it seemed fairly easy to get started
• Python is suitable for game development (e.g. OpenGL with pyglet), though with obvious performance limitations
• Agile methodologies would be even more suitable in game development than in traditional IT, but apathy and lacking/flawed feedback loops (publishers and retailers are harmful intermediaries) seem to prevent widespread adoption^[1]
• Open Source is mostly shunned in game development, often due to apathy and ignorance (there are a few positive examples though, like Lua); extreme short-term thinking prevents the realization of FOSS’s long-term benefits; standardization is actively subverted by platform vendors^[2]
• my overall impression is that the gaming industry is pretty messed up, largely because it’s dominated by vendors rather than consumer interests

1. apparently, the gaming industry doesn’t perceive itself as part of the IT industry – while it sits somewhere between traditional IT and the movie/entertainment business, it tends to prefer the latter (which is also reflected in the semantics, e.g. “game studio”)
2. instead of licensing game engines (e.g. Epic Games’ Unreal Engine), why are there no collaborative development efforts – similar to the way Apache now provides a superior alternative to IIS