For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | ionelm's commentsregister

Hunter has now a bit of everything (process attach, variable diffing like in pysnooper, env var activation, breakpoints, thread support and an api to build stuff on top) but without going overboard with overenineering (like serialization, storage or sql). For most intents and purposes it should replace every other tracer tool.

There's also a work-in-progress cookbook with unusual stuff: https://python-hunter.readthedocs.io/en/latest/cookbook.html


> For context: Bash is not available|installed everywhere, and has some inter-version weirdness.

Can you cite some sources here? No one knows what you're talking about.


Non-OSX BSDs don't include bash, some things like the ... operator don't work on older versions of bash.

Many people, especially Solaris and BSD folk, don't like bash scripts, and want you to write shell scripts in Bourne shell instead.

Many other people, who code on OS X and deploy on Linux, enjoy the extras bash adds, and only deploy on platforms that include bash.


I think your last point is important. I don't think shell script writers should be concerned about Solaris/BSD if they are confident that they will use their scripts only in environments where bash is available.


The bash COMPAT page? http://tiswww.case.edu/php/chet/bash/COMPAT

Also, just because you may not know what I'm talking about, don't assume no-one else does.


Sorry, I meant "no one who replied to you knows what you're talking about". Still, that list don't tell much about potential breakages. Are you actually complaining about bash having too many features or are there actual breakages? Please illustrate with examples, not links to tedious changelogs and ad-hominems.


It doesn't. It's outdated and not free. This should be way more known: https://sourceforge.net/projects/vcxsrv/


Speaking of that, there's a nice tool to build the installer for you: http://pynsist.readthedocs.org/en/latest/


But technically no. Virtualenv is quite different, both in scope and approach. https://github.com/Deepwalker/pundler is more similar to bundler


This is something quite similar to what I've worked on 8 years ago [1] although I gave up. I didn't have integration with other async frameworks/libs in mind from the beginning. I short, there weren't many things I could use it for. Plus it was slow - sure, there was no 'yield from' (PEP-380) back then.

It's interesting that David Beazley did it (he is certainly more qualified) but it's doomed if it doesn't play well with other libraries ...

[1] https://pypi.python.org/pypi/cogen


`easy_install` is not a library per se, it's a binary offered by setuptools.

> distutils was a fork of setuptools

This is incorrect. Setuptools is an extension of distutils (it patches and extends distutils to have additional functionality). Distribute was a fork of Setuptools that has been merged back into Setuptools.

Also, `pth` is not a installation method - it's merely a way to customize the import system. It's a very scary feature as it allows one to execute arbitrary code (that can reside in the `.pth` file) when import paths are being set up (when the `site` module is being initialized).


> `easy_install` is not a library per se, it's a binary offered by setuptools.

I thought that I clarified that in my post, but if you could tell me what was confusing, I'll use that to inform future discussions I have on this.

> This is incorrect. Setuptools is an extension of distutils (it patches and extends distutils to have additional functionality). Distribute was a fork of Setuptools that has been merged back into Setuptools.

Correct, and one reason why the landscape has been confusing for a while (confusion between distutils/setuptools/distribute). Thankfully distribute has been merged back into setuptools.

> Also, `pth` is not a installation method

You're right. It's a way to customize the import system, but it's "main" usage in the wild is during installation/setup. The main place that I've seen it used is with easy_install + eggs (IIRC).



It's amazing at what lengths people go with the theoretical arguments and personal conjecture.

Screens don't really have any black - the black you see is just a dark gray. The screens have limitations ...

Even if you'd have a very good screen, very few people go through the trouble of calibrating their monitors.

At the same time, no one can point to a scientific study of contrast choices over many types of screens and (mis)calibrations ...

PS. Screens are calibrated to ambient light - that compensates for the white being too white kind of problems.


On that idea, there was a very interesting lightning talk at EuroPython 2015: https://youtu.be/Tt-R2KdQUFs?t=2772


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You