mcdonc

Write conflicts are indeed hairy to deal with. Using a BTree in places where you might instead use a dictionary usually makes this a lot better.

It sounds like you got burned by using it without understanding it very well.

My point is that for this to actually be true (as opposed to just being wishful thinking, which there's a lot of right now), people are going to have to not only port their libraries but they will also need to maintain the resulting code. If the library is at all popular already, the resulting code will, for some open-ended period of time (perhaps "forever") need to work on both Python 2 and Python 3. And right now, though producing a port isn't monstrously hard, maintaining the resulting code across the 2/3 straddle is just no fun. The code looks bad, it's harder to read, it's harder to maintain, it's just less fun overall. Basically, maintaining a Python 3 port just takes some of the fun and aesthetic out of maintaining an open source library. It's an imposition to those folks who want their code to be popular, forward-compatible, and beautiful due to the need to straddle.

IMO, I'm not sure that a Python 2.8 helps much here, but a more backwards compatible Python 3.3 would. For example: match py3 bytes behavior with py2 string behavior, add u'' literals back in, maybe readd iteritems/iterkeys/itervalues on dict as aliases so we can use a common API for dicts, add the print keyword back in maybe, and other minor things that are really easy to do and don't have much defensibility other than "it's cleaner to not have to have bw compat here".

And this annoying feature: http://docs.python.org/dev/howto/pyporting.html#indexing-byt...

But that said, the fact that Rails (and Pylons, etc) called themselves MVC has rendered any definition meaningless, so it just kind of doesn't matter. Truth be told, it was already getting there long before web frameworks entered the picture when Java coopted the term to mean something it didn't in the 90s.

I prefer to use different terminology to avoid confusion, but if you wanna keep using "MVC" for your own stuff, I'm not going to fight city hall.

   @route('/hello/:name', method='GET')
   def hello_get(name):
       return 'Hello %s' % name

   @route('/hello/:name', method='POST')
   def hello_post(name):
       return 'Hello %s' % name

    from pyramid.view import view_config
    from pyramid.response import Response
    from paste.httpserver import serve
    
    @view_config(route_name='hello')
    def hello_world(request):
        return Response('Hello %(person)s' % request.matchdict)
    
    if __name__ == '__main__':
        config = Configurator()
        config.add_route('hello', '/hello/{person}')
        config.scan()
        serve(config.make_wsgi_app())

The rationale for putting the route ordering in imperative code instead of using decorator declaration order is in the document I linked. I'm not particularly interested in crippling Pyramid for larger apps to race to the bottom of the LOC count. It's succinct enough and works for truly large apps too.

- "saddled with any dependency baggage" == "has no dependencies"

- "beating on Flask" == "using Flask"

- "shrug" == "i didn't spend a lot of time on this"

- "Flask was completely unsuitable for that" == "I was unwilling to ask for help from the people who use Flask"

Additionally, Flask is also "easy to understand" and has "sane defaults", and it doesn't "require any boilerplate code" either. The context of the comment makes it seem like it's subpar on these things.

I'm all for people pointing out fitness of purpose for various frameworks, but this comment might have been better phrased as "I use Windows. I happened to find a recipe that let me run Bottle as a Windows service. That made it easier for me to use Bottle. Also, I like being able to deploy without the use of packaging tools."

So was my mistake in actually writing these tests or was it just advertising them? ;-)