HN user

ionelm

183 karma
Posts8
Comments38
View on HN

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

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.

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.

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

CPAN is 20 11 years ago

`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).

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.

Java for Everything 12 years ago

The argument can be made both ways. One can say that Python is better cause readability.

Many can give examples of successful or failed projects in both languages but it's just conjecture.

The only correct way to look at language choice, and the only objective one, is to use the language you are productive in. The best language is the one you master.

Also, it's very much likely that this is a deliberate distraction from the political conflict between the USA and Hungary that has emerged last week.

Strange theory. Have you considered they just need the extra money? Also, it wouldn't be a huge distraction anyway (from whatever) - I'm pretty sure they could invent more revolting taxes if they wanted to.

How is this not high-level corruption?

No public bidding process? Check. Favouring a vendor? Check.

In my eyes this lawsuit is a cover-up for a deal gone sour.

Jail whoever assigned this contract and this sort of failures will never happen again.

fork() can fail 12 years ago

Seems Python handles this correctly (by raising an exception):

    >>> resource.setrlimit(resource.RLIMIT_NPROC, (0, 0))
    >>> os.fork()
    Traceback (most recent call last):
      File "<ipython-input-7-348c6e46312a>", line 1, in <module>
        os.fork()
    OSError: [Errno 11] Resource temporarily unavailable

I don't think many people would disagree that CSS/HTML have certain encapsulation deficiencies. But I think that less/sass just make you more efficient at writing unmaintainable stuff.

Shadow DOM and WebComponents solve this better by encapsulating styling and markup concerned with the same widget or object. Without those you still have styling concerned with different markup in the same place. You can use less/sass but it's not true encapsulation - you still have to pay attention that you don't break styling for unrelated stuff when changing styling. Thus the "unwanted pain".

I don't think Jinja is a relevant example here - it's not something people usually write. While you take great care about the API and error handling most other people are sloppy and their code is hard to debug because they unknowingly cripple the tracebacks. That's why I like this feature just the way it is (an opt out, instead of explicit opt in) - cause it needs to cater for the 99% of the people who didn't even bother to reraise properly in Python 2.

Very interesting. Thinking about what you said, one could compare the software industry to the marketing industry:

- no accountability - marketing campaign with no effect, same as a bug, a unforeseen flaw

- lots of bullshitting

- scientific methods on deciding what practice is best still at infancy

I'm intrigued by your statement. When I read the word "orthogonal" I'm thinking of two key concepts:

* No functionality overlap in primitives

* Composability of primitives

How do Polymer and React as primitives fulfil said properties ? There's certain overlap in functionality. Composability is not guaranteed.

Did you mean to convey a different idea by "orthogonal" ?

I would say it's highly unprofessional to name and shame in a workplace - regardless of how captious That Guy is. You'll end up having bigger problems if you start doing that (low morale for instance).

Rather bad advice to say "don't be That Guy" when you actually have leadership issues and you can't convince your underlings on the execution. Sounds familiar?