mhashemi

Library author and lazy README updater here to report that technically as of October 09, 2018, boltons is 79 types and 146 functions, for a grand total of 225 utilities.

While I'm here, here are the ones I use most:

- OrderedMultiDict: https://boltons.readthedocs.io/en/latest/dictutils.html#bolt... - esp the .inverted() and .sorted() methods

- Exponential backoff and jitter generator: https://boltons.readthedocs.io/en/latest/iterutils.html#bolt...

- remap (recursive map): https://boltons.readthedocs.io/en/latest/iterutils.html#nest... (recipes here: https://sedimental.org/remap.html)

- Atomic File saving: https://boltons.readthedocs.io/en/latest/fileutils.html#bolt...

- Traceback utilties, structured tracebacks: https://boltons.readthedocs.io/en/latest/tbutils.html

Also, my favorite bolton that's not a bolton, glom: https://glom.readthedocs.io/en/latest/

If you have a bolton you'd like to submit, I'm pretty merge-happy. Here are the criteria: https://boltons.readthedocs.io/en/latest/architecture.html

Here was a recent high-profile but somewhat contentious transition: https://github.com/pypa/pipenv/issues/2191

The key here was that the rapid pace of the project kept breaking various user segments' expectations about semantic versioning.

They're all on the Users page: https://calver.org/users.html

Added by user request 1 hour ago: https://github.com/mahmoud/calver/issues/5

It's more for the past (06) than for the future.

Hehe, boltons.typeutils.make_sentinel should really be documented better for more experienced developers. A few small advantages: a nice repr, pickleability, and (back to the first advantage really) good rendering in a Sphinx autodoc context. :)

Did you seriously just recommend Requests, a project which uses "Non-GMO", "organic", and "grass-fed" to describe itself on the very page you linked, as a good example of not using buzzwords?

Come on. kreitz holds the title of Python marketspeak tycoon for a reason. :P

I wouldn't recommend dynamically generating strings. Strings are just a shorthand for Path objects, use Path instead: http://glom.readthedocs.io/en/latest/api.html#specifier-type...

I think y'all might be getting a bit up in arms about a non-issue. Seasoned glommers (and experienced Pythonists), will almost always be using T: http://glom.readthedocs.io/en/latest/api.html#object-oriente...

While mentioned in the post, it's not front-and-center because that's the sort of Python superpower that can look scary to less-experienced devs.

DRF still takes care of negotiating formats, etc., but it replaces the serializers. I'll see about getting an example in the repo, stay tuned.

You're yellin at a tutorial man. You gotta let some flavor text slide. :)

That said, I'm no liar. Kurt and I (as a team), really did write stuff leading up to glom in 2013 (years ago), and have written stuff like it enough times that I've lost count (countless :P). If this isn't research, I don't know what is. Heck, I'm even getting a fun little peer review!

The big, classical school of Python definitely prefers top-level functions. Still, I definitely understand that aesthetic, and am on board with not using functools.partial to achieve it. So: https://github.com/mahmoud/glom/issues/14 :)

Hey Ka-Ping! Maybe I did get carried away :)

How I wish one could publish a dry document and expect people to read all the way to the bottom. I've published enough libraries to know that's not the case. glom's free software so it's all there, as "shown" as can be.

But referring you to the code wouldn't be very considerate either. Instead, here's this literate code version that I prepared in advance. Hopefully this will be of more help to you: http://glom.readthedocs.io/en/latest/faq.html#how-does-glom-...

That's a great example! Mind if I use it? ;)

Filtering is supported through the OMIT value: http://glom.readthedocs.io/en/latest/api.html#glom.OMIT (another example: http://glom.readthedocs.io/en/latest/snippets.html#filtered-... )

Lambdas and functions are always a safe fallback, but glom does its best to keep your specs readable and roundtrippable (gotta love a nice repr()).

The real advantage over toolz/get_in is in the breadth of types glom can support (http://glom.readthedocs.io/en/latest/api.html#setup-and-regi...), the extensive fallback behavior (http://glom.readthedocs.io/en/latest/api.html#advanced-speci...), and "T" specifier (https://sedimental.org/glom_restructured_data.html#true-pyth...), which allows performing object-oriented traversals and calls.

Check the post for more examples of where path-based access falls short of the mark!

(Sidenote: I find it very clunky that get_in() takes a "default" kwarg and _also_ a n"o_default" kwarg. Use a Sentinel object! http://boltons.readthedocs.io/en/latest/typeutils.html#bolto... )

What's really interesting is that we're approaching the same ideal state from different directions. Specter goes from Clojure's immutability to something more practical, from Python's super dynamic system to something more declarative and immutable.

From within Python, all objects are supported by default. If you can parse it, you can glom it. You can even register additional behaviors for specific types to keep your specs tight: http://glom.readthedocs.io/en/latest/api.html#setup-and-regi... (example: http://glom.readthedocs.io/en/latest/snippets.html#automatic...)

The CLI is in a pretty preliminary state, usable but not as robust as it will be in a few weeks. It only supports built-in parsers (JSON and Python literals) What formats are you thinking? YAML?

It depends on the complexity of the spec, but we've already done some programmatic building of glomspecs, so for many cases I think the answer is yes! Once we feel out the patterns I think glom will gain some utilities for this purpose.

Total coincidence! Reading the README, Nathan and I are definitely on the same wavelength though. When I get a chance I'll add it to the analogies doc: http://glom.readthedocs.io/en/latest/by_analogy.html :)

glom not only supports more than string keys, it also supports assigning to non-dictionary objects. That's a part of the API we're working on right now, actually.

As for the data insertion, mutation may be in the future, but for now glom only transforms and returns new objects. Definitely something to think about though, bookmarked! :)

Oh nice! Total coincidence, I assure you. Still, I should read on this and add it to the analogy doc: http://glom.readthedocs.io/en/latest/by_analogy.html

Declarative data transformation generates a lot of comparisons (almost all of them great, though!).

Haha, I'm all for console usage, but let me tell you, there's nothing quite like that feeling of moving a working spec into a dedicated application with exception handling, logging, etc. :)

Was it the literal link to https://en.wikipedia.org/wiki/Poe%27s_law on https://0ver.org/about.html ? :P

Countless people are already using 0ver, and always will. In other words, 0ver.org is descriptive, not prescriptive.

Ohhhh snap! I'll update the article tonight!

That great! The PyPA works hard to make pip+pypi behave intuitively. That said, a lot of more applications need more machinery, yielding utilities like pip-tools[0] and conda.

[0]: https://github.com/jazzband/pip-tools

Absolutely! The post mentions a little bit how pip is definitely used for distributing command-line applications, from fab to pex to ansible. So much so that pipsi[0] is a thing. Even the tiny static site generator used to generate the post is a CLI app that leans on PyPI for distribution[1]. The origins and designs for the tools listed are primarily for libraries. Entrypoints[2] and other features came much later. Use of these techniques is overextended when developer distribute nontrivial code on PyPI with a non-developer audience. People get a buggy install and conclude that Python packaging is the problem :)

As for the package manager crosstalk, I feel you. That's definitely a source of the demand for tools that create self-contained artifacts.

[0]: https://github.com/mitsuhiko/pipsi [1]: https://pypi.python.org/pypi/chert [2]: http://setuptools.readthedocs.io/en/latest/setuptools.html#a...

That's really useful to hear, especially from you, (presuming you're the same wbond who wrote oscrypto)! Have you written or considered writing a longer-form expansion on these experiences?

And yeah, in spite/because of all its simplisticness, ctypes really does seem to win out among those who share Python's aesthetics.

yes, he's the real deal

Sampling is fundamental to so much of practical statistics. It's more or less proven and accepted. In real studies, we "throw data away" by just not collecting it in the first place. As long as you do it right, you still get a reliable answer.

But if you've already got it all and it all fits in memory, by all means, hold on to it!

Whoa! With praise like this, how couldn't there be more? Thank you!