|
Yeah I did consider Dash and I have used plotly but I'm a bit skeptical I guess it. Seemed a bit more like Streamlit where it'd be good for demos and little mini apps but prob doesn't have all the other ecosystem of stuff like Flask. Definitely open for people's experience with Dash I did know about Bootstrap but wasn't sure if it was still well regarded and/or suggested given its age. Probably the best one to use given how much existing examples out there exist. Anyone have experience with Flask AppBuilder? I know airflow + superset was built with it but I think the same guys made it so dunno how well regarded it is. The LDAP security integration and admin panels look good but would be curious if it locks you into a really opinionated framework like Django or if you still have decent flexibility.
|
#
¿
Mar 20, 2024 00:13
|
|
|
|
| # ¿ May 14, 2024 00:24 |
|
|
Zoracle Zed posted:Thanks for this by the way! I've been playing around with it and like it a lot. Markdown instead of rst is wayyy more ergonomic for me and `mkdocstrings` is the plugin does the automatic API docs generation exactly like I'd want it to, including out of the box support for parsing type annotations from function signatures That's awesome, glad to hear and also reassuring others see it useful too. I'm really big on docs pages but I know lots of people are really adamantly against them because it takes away from just writing code. But I know for myself I'm always really happy to see em. Bit of an abstract question here for so please ignore if you find these tedious. I'm coming to python as a data analyst who mainly understands data in RDBMS tables (SQL obviously being a big tool I turn to). I find myself often though getting lost and confused with just how granular that imperative python code lets you take apart then out together data again with all the different variety of data structures. Is there a particular 'style' of python that leans towards tables and similar relational data rather than slinging everything around in key:value pairs, lists etc. I've been finding it hard to get imperative styles to click in my head when I'm so used to how "connected" All the data is within a SQL statement for example. Like is there a way to manage data in python script basically create dimensional tables of data that you need and join em as needed. Like, would it be weird if I pretty much used entirely dataclasses (PersonsTable, OfficeTable) or hell, pandas data frames even, written like a dimensional star schema with FK/PK s and basically just did essentially python equivalent of joins and select statements anytime I accessed those objects? Or would that just be complete gobbledygook? I'll try and maybe get an example of what I'm talking about here so apologies for the ambiguity. Note here I'm not really talking about using an ORM on data that's from/in a database. Those cases I tend to just be leaning on pure SQL when I can. (I do tend to lean towards functional styles of python when I'm straight up transforming / cleaning data, but in this case I mean within the context of OOP / imperative styles for local scripts and such). Oysters Autobio fucked around with this message at 13:24 on Mar 23, 2024 |
|
#
¿
Mar 23, 2024 05:16
|
|
|
Would it be odd to use data frames (pandas, polars etc) for non dataset/table related functions? Like I'm making a generic Flask app and I move and manipulate the data around with pandas data frames, transforms with map-apply style functions etc? Or would this really make it an unreadable mess for others?
|
|
#
¿
Mar 23, 2024 22:16
|
|
|
ComradePyro posted:I can personally attest to weeks of frustration for lack of this advice. Echoing this and expanding it even further: don't touch anything related to XML as a beginner. While I'm absolutely sure it has some great features about it, I'm finding it's very much a "big boy" format and not beginner friendly. Maybe not the format necessarily but the ecosystem of tools in Python for it are really dense. Hell, just look at the name "lxml" as a package. Gonna throw out a dumb hot take that I literally put no thought into: Acronyms should be banned from package naming.
|
|
#
¿
Apr 4, 2024 11:19
|
|
|
Data Graham posted:Doesn't help that loving lxml has to be natively compiled so if you're on Windows on a locked-down workstation you're forever trying to chase down some way to install the particular 10-years-deprecated version of Microsoft Visual Studio Enterprise Edition For Professionals Workstation Edition 9.0 C++ Supplemental that it needs in order to build, or else finding the binary version matching your pinned requirements on some college student's HTML 1.0 page in Finland that has 35 different builds of 714 different versions but not the specific one you want. phew, glad I'm not the only one. Deeply worried I was doing a "show off how little you know" hot take. As a non-programmer using Python, I just have an aversion to very crunchy naming conventions. Yeah yeah I get it, I'm sure there's deeper engineering / computer sciencey reasons why you want to append a billion prefixes and use shortened names but no offense, go use a real programming language or write assembly or whatever. Leave the baby languages for babies like me please. I don't care about camel vs snake whatever, just use real words or very obvious acronyms please. BeautifulSoup provides no semantic description of what it does. But it's easy to remember and associate with HTML scraping. If it was called 'lhtml' I'm gonna be straight up with y'all and be honest that unless I saw it had a billion stars on GitHub or high mentions on Google, I probably wouldn't have even bothered to try it out or even look at the README It's like an immediate shibboleth for me that if it uses some cryptic name that the docs will be written with far too many assumptions about my knowledge and probably just isn't right for me. Actually now that I think about it, I retract all of the above. It's actually probably a good thing for everyone if we had a standard of "friendly fuzzy trendy name" implied easy to use and "incomprehensible gibberish acronym soup" was a snake rattle warning of "stay away, you're prob too dumb for this". No offense would be taken, I could continue on to find baby packages and the big-brained folks can build cooler esoteric stuff.
|
|
#
¿
Apr 4, 2024 12:53
|
|