Post by stephan schultcheni started yesterday to dig into the bottle code, and stripped
everything that is related to python2 compatibility.
As long as the Python 2/3 dual-compatibility does not affect runtime
performance or prevent progress, I do not see a reason to drop it. The
only real downside is code-complexity within bottle, but that does not
affect the users of bottle. So, removing it would only have drawbacks
for the users an no real benefit.
Post by stephan schultchenbut i have to admit that i start to dislike the one file approach that
bottle uses, and might try to split it up into different files, simply
because a 4k+ lines file is not that easy to handle.
Bottle started as a one-file framework without dependencies mostly to
simplify deployment. It was designed for learning or weekend projects,
to quickly build a REST-APIs for some command line tool or sqlite
database, or to remote control a Raspberry PI or other embedded device.
These use cases are less prominent, but actually very common for bottle.
For these use cases, downloading a bottle.py file into your project
folder is way easier than doing it 'correctly' with virtualenv and pip.
Bottle still fully supports the 'correct' way, but having an easier
option to get started is a really nice feature.
But there is a second, even more important reason for the single-file
approach: Bottle is a micro-framework. Having everything in a single
file makes it easier for me an other contributors to keep it that way.
As soon as we'd split it up into multiple files, line count starts to be
less of an issue and large pull requests become hard to argue against.
Once you need pip to install bottle, adding an external dependency would
be just a small step. And then, adding even more dependencies would be
trivial. The spirit of bottle as a 'micro' framework would be lost.
Look at other 'micro' frameworks out there. Flask for example. If you
include its mandatory dependencies, you'd have an order of magnitude
more code to read if you would want to understand what is really going
on in your web application. The ~4k Lines in bottle can be read and
understand in a weekend. A stacktrace shows you exactly where the
problem is. If you do not understand the doc-string of a method, you can
open up bottle.py and just read the code. Try that with Flask.
Nice to know: Bottle is used in some security-sensitive environments and
its security was audited by at least two independent companies (that I
know of), and both hinted that bottle was chosen for exactly this
reason: It is small enough to be fully understood, and useful enough to
be worth the audit.
Post by stephan schultchenbut it also would be nice if marcel hellkamp could make a note of what
his plans with bottle are.
Bottle is feature complete, mostly. Releasing 0.13 would be nice,
though, as it fixes a ton of issues and adds some nice little details,
but I made the same mistake I also made for 0.12: The change-set grew to
big, and I am not confided enough that there are no backwards
incompatible changes to release it. Bottle is very stable between
releases and I do not want to break this promise, but I do not have the
time to extensively test it myself, unfortunately.
What would help me a lot, is people migration their applications from
0.12 to the master branch, and tell me if that worked for them or not.
We also need to clean out some of the 'ideas' in 0.13 that are probably
not ready to become a stable API. The new Config feature for example.
Nice to have, but may as well be a plugin. I'm not sure.
--
--
You are member of the "bottlepy" group at google groups.
See http://groups.google.de/group/bottlepy for mailing list options.
See http://bottlepy.org/ for news and documentation.
---
You received this message because you are subscribed to the Google Groups "bottlepy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bottlepy+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.