|
tef posted:fwiw the paper https://dl.acm.org/doi/pdf/10.1145/3485513 has this as the contributions I think these were common implementation idioms for LISP compilers in the 1970s
|
#
?
Jan 12, 2024 06:03
|
|
|
|
| # ? May 26, 2024 14:04 |
|
|
Subjunctive posted:there was a Python implementation on top of the CLR, but it didn’t have compatibility with the world of C extensions so nobody took it seriously. I think it was IronPython? there was also boo, which adds static typing with inference. if you're going to drop compatibility with existing code, you might as well make the language not suck rear end while you're at it
|
|
#
?
Jan 12, 2024 06:07
|
|
|
python seems impossibly bad why do people use it. all they’re doing is gluing together c code anyways. seems miserable
|
|
#
?
Jan 12, 2024 06:10
|
|
|
because the alternatives are perl or bash
|
|
#
?
Jan 12, 2024 06:21
|
|
|
or just use the c directly
|
|
#
?
Jan 12, 2024 06:22
|
|
|
Bloody posted:python seems impossibly bad why do people use it. all they’re doing is gluing together c code anyways. seems miserable because it has a large software catalog and works nice with scientific software people try to build better things but it's pretty established
|
|
#
?
Jan 12, 2024 06:24
|
|
|
it’s 2024 we’ve been in the future for a while now everything has trivial c interop
|
|
#
?
Jan 12, 2024 06:24
|
|
|
does everything have cython?
|
|
#
?
Jan 12, 2024 06:25
|
|
|
Arcteryx Anarchist posted:because it has a large software catalog and works nice with scientific software a large library of garbage people still probably use matlab a lot though. scientific software types have never been the brightest
|
|
#
?
Jan 12, 2024 06:25
|
|
|
one piece of software ive worked on started out as matlab iirc and then transitioned into c/lua, into an even more messy kluge of software, and is now on its way to being python (hopefully)
|
|
#
?
Jan 12, 2024 06:27
|
|
|
if you're writing a 50 line or less script it does not matter what you use to write it; you can get away with literally any language, no matter how flawed, and it'll be fine the basics of python are apparently simple and unsurprising, so nobody's afraid of using it much like php, python has a huge stdlib and can do a lot of stuff out of the box put those two facts together and python is essentially a glue-trap for greenfield software development
|
|
#
?
Jan 12, 2024 06:29
|
|
|
we use python to build/update our solr indexes the scripts are fairly simple, basically they run a bunch of sql, massage it into json, and send it off to solr for the most recent index though, i added some end points to our backend, since it can already generate 75% of the json needed. so basically the newest script just asks the backend for the objects, adds whatever is missing, and sends that off. no sql doing the whole thing in the backend would be a pain in the rear end so we went the simplest route
|
|
#
?
Jan 12, 2024 07:41
|
|
|
Bloody posted:python seems impossibly bad why do people use it. all they’re doing is gluing together c code anyways. seems miserable the important decisions on any software project were always made five years ago by someone completely unqualified to make them, and half your time is spent dealing with the consequences
|
|
#
?
Jan 12, 2024 07:58
|
|
|
Internet Janitor posted:if you're writing a 50 line or less script it does not matter what you use to write it; you can get away with literally any language, no matter how flawed, and it'll be fine I'm working on a small python script (not by choice, its a photoshop script part of a tool we're making and the people who will end.l up maintaining it wanted it to be in python ) and I disagree, it's complete crap like I have a bunch of helper functions and want to move them to a separate .py file and I ended up having to mess with paths and poo poo because the module system is loving convoluted
|
|
#
?
Jan 12, 2024 10:08
|
|
|
mystes posted:both ironpython and jython were pretty neat honestly without extension compatibility they aren’t replacements for cpython in scientific computing etc, but that’s not the only use case for python. loads of python code doesn’t use c extensions at all. jython was really useful as a scripting engine for java apps so people didn’t have to touch java unless they wanted to. what killed it was the difficulty of reimplementing everything to support python3.
|
|
#
?
Jan 12, 2024 10:10
|
|
|
not writing c is a good first step for most things and projects. python being the choice for gluing little things that can't avoid it is a noble purpose. python itself little to write home about but it is very sane and has somehow gotten more sane over time (almost unheard of in pl)
|
|
#
?
Jan 12, 2024 10:23
|
|
|
Internet Janitor posted:if you're writing a 50 line or less script it does not matter what you use to write it; you can get away with literally any language, no matter how flawed, and it'll be fine see also perl5 and how it lost its place as the standard glue-trap plang to python hopefully something will come along and do to python what it did to perl, i think that's the only way to make real progress in this space
|
|
#
?
Jan 12, 2024 10:42
|
|
|
Zlodo posted:I'm working on a small python script (not by choice, its a photoshop script part of a tool we're making and the people who will end.l up maintaining it wanted it to be in python ) and I disagree, it's complete crap ?? if the files are in the working directory you just import them
|
|
#
?
Jan 12, 2024 11:01
|
|
|
Carthag Tuek posted:?? if the files are in the working directory you just import them I don't want to mess with the cwd just so that the script works
|
|
#
?
Jan 12, 2024 11:09
|
|
|
Maybe it's an issue with how Photoshop Python scripts work or something? That's normally not an issue in Python
|
|
#
?
Jan 12, 2024 11:10
|
|
|
even running from some other dir with a path to the script will import other py files in the same dir as the script maybe ps copies the contents into its own process?
|
|
#
?
Jan 12, 2024 11:54
|
|
|
Soricidus posted:jython was really useful as a scripting engine for java apps so people didn’t have to touch java unless they wanted to. what killed it was the difficulty of reimplementing everything to support python3. nowadays you simply run a copy of v8 in a subprocess
|
|
#
?
Jan 12, 2024 11:57
|
|
|
Carthag Tuek posted:even running from some other dir with a path to the script will import other py files in the same dir as the script didn't work and I had to resort to using some module path stuff I copied from some other script quote:maybe ps copies the contents into its own process? I'm running it as a standalone script because photoshop doesn't directly support python scripting but it have a COM interface I dunno perhaps it's because i'm using a portable python install that we have on our perforce repo
|
|
#
?
Jan 12, 2024 12:57
|
|
|
weird. idk then
|
|
#
?
Jan 12, 2024 14:02
|
|
|
no worries, im sort of glad that my annoyance at python remains justified
|
|
#
?
Jan 12, 2024 14:11
|
|
|
Can someone remind me why it's actually cool & good that Apple disables OpenMP in their gcc-impersonating C compiler?
|
|
#
?
Jan 12, 2024 14:14
|
|
|
there's many things one can say about pythons module support, but "convoluted" is not among them
|
|
#
?
Jan 12, 2024 14:47
|
|
|
Cybernetic Vermin posted:there's many things one can say about pythons module support, but "convoluted" is not among them Namespace packages are definitely weird and complicated, people invoking interpreter with a path instead of -m also can mess up imports
|
|
#
?
Jan 12, 2024 15:11
|
|
|
btw zlodo what version is in your perforce there? iirc they did some finagling with how imports work a couple minor versions of 3 ago, and also probably 2->3
|
|
#
?
Jan 12, 2024 15:31
|
|
|
Carthag Tuek posted:btw zlodo what version is in your perforce there? 3.7.6
|
|
#
?
Jan 12, 2024 16:08
|
|
|
BobHoward posted:see also perl5 and how it lost its place as the standard glue-trap plang to python julia just isn’t going to happen
|
|
#
?
Jan 12, 2024 16:36
|
|
|
Cybernetic Vermin posted:there's many things one can say about pythons module support, but "convoluted" is not among them the transformation to writing everything as a script into writing everything as a module is easy to trip up, cause module packaging requires the magic words __init__py and __main__py (or cramming main into something else via init) making modules is easy once you learn the magic words. theres a blog post i share about this when it comes up that i cannot find in my bookmarks
|
|
#
?
Jan 12, 2024 16:48
|
|
|
Zlodo posted:3.7.6 ah well. looks like it as 3.3 i was thinking of https://docs.python.org/3.10/whatsnew/3.3.html#using-importlib-as-the-implementation-of-import fwiw ive done some __path__ fuckery in my time, but thats always been for loading things like config or data files that reside with the .py file, never for imports that i can recall Carthag Tuek fucked around with this message at 16:52 on Jan 12, 2024 |
|
#
?
Jan 12, 2024 16:50
|
|
|
Share Bear posted:the transformation to writing everything as a script into writing everything as a module is easy to trip up, python2 eol'd 4 years ago bud
|
|
#
?
Jan 12, 2024 16:54
|
|
|
tef posted:python2 eol'd 4 years ago bud i never used python2 so idgi, im doing this in a boring repeatable way with directories as modules
|
|
#
?
Jan 12, 2024 16:55
|
|
|
the file is the module you can use directories to organize modules into groups of submodules if you want to
|
|
#
?
Jan 12, 2024 17:00
|
|
|
Athas posted:Can someone remind me why it's actually cool & good that Apple disables OpenMP in their gcc-impersonating C compiler? what a weird way of putting this from someone who iirc actually works on compilers. you might as well be asking why apple disabled fortran for aarch64. like there’s a turnkey perfect openmp implementation that we just spitefully set on fire openmp is a massive language extension / library. the current openmp spec is considerably longer than the c standard. there is some existing work in clang to support it — i did most of the code review on that, actually — but it is not simple to enable on a new platform because of the nature of the feature. openmp is meant to be a performance optimization, and supporting it well so that it’s actually, y’know, faster requires major system and toolchain integration work. that’s because almost every single thing in openmp involves one or more of (1) offloading (and therefore secondary compilation and (typically) gpu driver support) or (2) cpu parallelism (which would normally be the most turnkey thing here except it obviously would need to be completely reimplemented on top of gcd on apple platforms) or (3) vectorization (which i’m certain you know is always a ton of work to make efficient, especially when the established code has been written assuming a different architecture) so implementing openmp is a ton of upfront work and an ongoing permanent commitment. and programmer adoption of it in the wild is not really all that high, all things considered. that’s partially circular, i know, but it’s still true it’s also a c technology at a time when we’re pretty all-in on moving to swift. “here’s a great new technology you should use! you’ll have to use c, please continue doing that for another ten years” is not the message we are going for as a platform. the openmp annotations certainly could be adapted into swift — the spec already presents them in both c and fortran — but that would be yet another major design and implementation task i don’t want to be completely discouraging; it is something we still talk about from time to time. if you have a pretty good idea of what parts of openmp you’d be interested in using, i can put you in touch with the right people. knowing about more potential clients can’t hurt rjmccall fucked around with this message at 17:08 on Jan 12, 2024 |
|
#
?
Jan 12, 2024 17:02
|
|
|
Arcteryx Anarchist posted:the file is the module yeah i do this generally. sorry to mismatch terminology as a file is its own module is also correct it can be easier to organize groups of stuff using the directory method into submodules/packages and calling the entire thing as a module with python -m to the module entry point, but thats not as intuitive or simple as running a single file directly (cause then you gotta set up the module structure) i hope thats a clearer expression of my point
|
|
#
?
Jan 12, 2024 17:07
|
|
|
also you’re probably better off doing the work to make it a property lib/package if you’re at that point
|
|
#
?
Jan 12, 2024 17:15
|
|
|
|
| # ? May 26, 2024 14:04 |
|
|
what i find most annoying on the rare occasions i need to write a python script is that the stdlib, while reasonably comprehensive, is completely scattershot in its approach to everything. it's even odds that a given module will expect an imperative style (bang on these magic functions and mutable values in sequence), a functional style (everything makes new copies of stuff), or a pointlessly object-oriented style (instantiate a parser whatzit, set fields to configure it, call a method and get back some other inscrutable piece of crap instead of just giving me the data) for a glue language it is remarkably inconvenient and awkward to glue together the parts that come in the box
|
|
#
?
Jan 12, 2024 17:16
|
|