Sorry, but this is really not suitable for much. There is so much wrong with this implementation that I’m not sure where to start. Every call to your template writes to a single file called “index.html”[1] which is then copied to another file when “written”[2]? You also print exceptions rather than allowing people to handle them as they wish.
The idea is nice, but try and remove all file system calls and do this entirely in-memory. This may mean completely changing the API.
Yeah, you're absolutely right, I wasn't able to really think of another way to implement it. [2] was meant to be implemented with Flask, which is optional, so the files can directly be written to templates/ and static/. We're actually changing this. Can you give a few suggestions on how it must be implemented? We want to work on this
Unlike Ruby Python doesn't have great facilities for writing making implicit APIs like this:
with Table():
header(...)
row(...)
You can do something like this but I'd recommend against it as it involves a lot of magic and has trade-offs which make it an uncommon choice. Instead you'd do something like:
with Table() as table:
table.header(...)
table.row(...)
This follows through to your template API as well. So you'd want to construct an object that represents your template, and have methods on that to add a table. For example:
page = sierra.Page(...)
with page.div(...), page.add_table() as table:
table.header(...)
table.row()
print(page) # __str__() should return the raw HTML response
This simplifies things, and you can use an in-memory StringIO object rather than a file. You can then return this string to flask as a text/html response and avoid Jinja2 entirely.
Also don't use CamelCase, please! It looks very unpythonic.
However you're really trying to create an API for producing a tree of nodes (some of which might logically map to individual tags, some of which might not) which are then serialized to HTML.
I'd recommend looking at how you can use BeautifulSoup for a lot of this. BS4 contains a lot of classes and functions for creating trees of HTML-like nodes, so you could use this rather than a StringIO object and directly writing "<div>" and having to support all of the attributes as method arguments. You could just use "soup.new_tag(element, *kwargs)" and only do something "special" when handling pandas dataframes or other stuff (like ol/ul tags).
'This simplifies things, and you can use an in-memory StringIO object rather than a file. You can then return this string to flask as a text/html response and avoid Jinja2 entirely.'
I didn't think of this until you mentioned this, so might do that. But I don't get the 'avoid Jinja2 entirely' part. Jinja2 is avoided with the current syntax already (which is definitely changing).
About BeautifulSoup, the autoPrettify() function is actually from bs4, it is a dependency.
When you do “render_template()” Flask uses jinja2 - it will read it, pass it to jinja2 and render the response. This is what I meant by avoiding jinja2 entirely.
But the issue when I avoid render_template() is this:
I can't add the CSS file along with the HTML one, unless I create a <style> tag at the end of the file that has all of the CSS content. Can you comment on that?
Unfortunately my Python skills start and stop at pandas and I use Rails for web development so I can’t comment on the actual code base in any meaningful way.
I just wanted to congratulate you on committing to something and putting yourself out there and am only commenting because you only got one response and that was a negative one which I know can be demoralizing. Saturday night was not the best time to post it, I recommend Monday morning when a lot of us are spending more time on HN than we should be and are more likely to engage with your post.
Regardless of what the actual quality of Sierra ends up being right now, you should be proud of yourself for doing what a lot of is struggle to do. You picked something, did it, and shipped it to the world for criticism. Good luck with your project!
Since you mentioned this was your first serious project and some others were giving advice: in the future, I would recommend using snake_case rather than camelCase for Python projects. Not due to any subjective feelings about it, but just because that's the idiomatic Python convention. It's what the standard library and almost all third-party libraries use.
I always use snake_case. But the guy I'm working with always insists on using camelCase, though he's never used Java/c#/Go. I don't like it, so sometimes we make compromises there. Thanks for the advice
It's probable that inexperienced workers (of all ages) will come across this and deploy it to unsuspecting small businesses because both want to ride the Python Way.
I think in the future Microsoft's LinkedIN will verify everyone and Microsoft's Github will require a LinkedIN account. In the meantime, Caveat Emptor if you let RedFox2 BrainStormYourWayIN.
16 comments
[ 4.0 ms ] story [ 43.3 ms ] threadThe idea is nice, but try and remove all file system calls and do this entirely in-memory. This may mean completely changing the API.
1. https://github.com/BrainStormYourWayIn/sierra/blob/main/src/...
2. https://github.com/BrainStormYourWayIn/sierra/blob/main/src/...
Also don't use CamelCase, please! It looks very unpythonic.
However you're really trying to create an API for producing a tree of nodes (some of which might logically map to individual tags, some of which might not) which are then serialized to HTML.
I'd recommend looking at how you can use BeautifulSoup for a lot of this. BS4 contains a lot of classes and functions for creating trees of HTML-like nodes, so you could use this rather than a StringIO object and directly writing "<div>" and having to support all of the attributes as method arguments. You could just use "soup.new_tag(element, *kwargs)" and only do something "special" when handling pandas dataframes or other stuff (like ol/ul tags).
Check out the BS4 documentation and methods for tree manipulation here: https://www.crummy.com/software/BeautifulSoup/bs4/doc/
I didn't think of this until you mentioned this, so might do that. But I don't get the 'avoid Jinja2 entirely' part. Jinja2 is avoided with the current syntax already (which is definitely changing).
About BeautifulSoup, the autoPrettify() function is actually from bs4, it is a dependency.
Yeah I know, camelCase IS unpythonic
Thanks again
Good luck!
I just wanted to congratulate you on committing to something and putting yourself out there and am only commenting because you only got one response and that was a negative one which I know can be demoralizing. Saturday night was not the best time to post it, I recommend Monday morning when a lot of us are spending more time on HN than we should be and are more likely to engage with your post.
Regardless of what the actual quality of Sierra ends up being right now, you should be proud of yourself for doing what a lot of is struggle to do. You picked something, did it, and shipped it to the world for criticism. Good luck with your project!
snake_case: Python, Ruby, Rust
camelCase: JavaScript, Java, C#, Go
I think in the future Microsoft's LinkedIN will verify everyone and Microsoft's Github will require a LinkedIN account. In the meantime, Caveat Emptor if you let RedFox2 BrainStormYourWayIN.