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.

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

When I wrote Alembic just recently, I ran 2to3 on it and it literally needed two "file()" calls to be changed to "open()" and that's it.

The contradiction in Armin's post is that he starts off with "we don't like Python because its perfect, we like it because it always does a pretty good job, etc. etc.". Aside from Armin's very specific issues with codecs (I've never used codecs that way) and with the filesystem (OK, he's convinced me work is needed there), I don't quite see how 2to3 is any different than "not perfect, but does the job at the end of the day".

Also, we really shouldn't be fixating on 2to3 very much - it is already deprecated. We should be thinking/worrying very, very, much about 3to2. Since we really should be shooting to have our source in all Python 3 within a couple more years.

I have a hard time seeing how one can use 2to3 on an everyday basis: it makes testing, distribution, etc... that much more painful because it is so slow (2to3 takes as much time as compiling all the C code from numpy, for example). It also removes one of the big plus of a language like python (modify code - see the result right away).

I really don't want projects to go back to maintaining two source trees, that was a disaster.

Try implementing even a medium-sized project in both Python and JS and tell me JS is a serious replacement, let alone for the large ones.

Like clojure, or something else. Indeed, as a newcomer to Python I wanted to pick up python 3 from the start, but went back to python 2 becuase of poor library support.

If in the future people still decide to go with what works, they might as well go with a completley different language, that just works, not becuase it is the correct way.

Also, encoding was one example. I could rant for hours about the ways in which Python is more suitable than JS(-of-today) for medium-or-greater sized projects.

However I'm a big proponent of 'breaking with the past' once in a while, to fix issues that have snuck into the language/library/system, and to clean up the cruft. Yes it will bring some frustrating porting, but the end result will be a cleaner more focused language.

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".

Even if not, the python devs are not trying to define this point for anyone, you can stay with 2.7 the rest of your life if you want to. I don't think a "2.x will no longer be maintained even for bugfixes" date has been established.

Python 2.x is not going away, but staying at 2.7 is not a long term solution either.

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.

   config = Configurator()
   config.add_route('hello', '/hello/{name}')
   config.add_view(hello_world, route_name='hello')

    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.

    @view_config(route_name='hello', request_method='GET')
    def get_hello(request):
        return Response('a GET request for %s' % request.matchdict['name'])

    @view_config(route_name='hello', request_method='POST')
    def post_hello(request):
        return Response('stored info')

    config = Configurator()
    config.add_route('hello', '/hello/{name}')
    config.scan()
    app = config.make_wsgi_app()

   @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

- "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."

Would you expand on what you meant by:

> The context of the comment makes it seem like it's subpar on these things.

What I intended to get across was that Bottle, being a single file at ~2700 lines, makes it convenient to scan the code to see exactly what it is doing (or not). It also doesn't require a lot of typing to wire a function to a URL and offers some nice syntactic sugar while doing so: you don't have to @route things you can @get them or @post them (it's probably my Java background that makes me think in terms of separate code paths for the different HTTP verbs).

My take on a more detailed (and hopefully hyperbole-free) summation of my original post is:

"Because this was a short timeframe prototype, they had no Linux VM available in the lab so I had to use Windows. I found a recipe that let me run Python stuff as a service which I was able to wrap around Bottle more quickly than I was able to with the other frameworks I tried. Because I was working on a machine that had no access out to the internet, I had no virtualenv and had to instead bundle all my stuff up by hand."