It's reversible, just not overnight. Start today and don't give up.

Maybe. A chimpanzee is much closer to a human than a monkey, which already had ~500 of the ~1600 proteins.

I found a handy graph of the primate family: http://www.nature.com/nrg/journal/v15/n5/fig_tab/nrg3707_F1....

> The time of separation of the human lineage from the rhesus macaque lineage is dated at 28–25 million years ago, whereas the human and chimpanzee lineages are believed to have diverged ~9–5 million years ago.

In addition, RAII is useful for more than just memory [de]allocation: database connections, resource handles, anything that you have to get/create and then cleanup/release.

As someone that works 90% with python and 10% with C++, that's something that gets missed in the debates about GC/manual memory management. It's a lot easier to leak resources in python programs because the whole point is you aren't sure what the lifetime is of some objects; if you knew, you wouldn't need a GC. So I end up putting a with block pretty high in the call stack holding the DB handles (most of the time) which is just a weaker form of RAII, as you can't "allocate" anything further down the call stack.

I prefer working in python to C++, I just wish I had a lot more control over things like this. And no, __del__ isn't a good solution as that opens a whole can of worms (for one, it's not guaranteed to ever be called).

What do you mean when you say 'as you can't "allocate" anything further down the call stack'? Do you mean you can't allocate something in c to be cleaned up in 'a', in the call tree:

    a(b(c()))

because just returning an object, then dropping the reference at the end of 'a' would do just that. You could also write your own context manager to wrap up a parameter.

    class Shadow(object):
        def __init__(self):
            self.value = None
        def __enter__(self):
            return self
        def set(self, v):
            self.value = v
        def __exit__(self, *args):
            if self.value is not None:
                self.value.cleanup()
        
    with Newdb() as db, Shadow() as d:
        a(b(c(db, d)))

you can do something like

    with a(b(c)) as f:

but then you risk any of those functions throwing an exception and screwing up the whole thing. You can move the resource allocation from __init__ to __enter__, but now you split your initialization code over 2 constructors. You can just hope and pray that a and b don't throw an exception, but someone is gonna accidentally break that assumption. And even if they don't, you've now spent more time worrying about that then if you just did manual memory allocation.

Or, in C++ you write

    class Foo {
    public:
        Foo() {/*get handle*/}
        ~Foo() {/*release resource*/}
    };

and you never have to worry again.

> You can move the resource allocation from __init__ to __enter__, but now you split your initialization code over 2 constructors

After giving it some thought, I've come up with a better example which more closely maps to C++ RAII constructs, which shows that you don't need to split anything. Consider:

    class Shadow(object):
        def __init__(self):
            # Initialization code
        @classmethod
        def __enter__(cls, *args, **kwargs):
            return cls(*args, **kwargs)
        def __exit__(self, *args, **kwargs):
            # De-initialize

`__enter__` becomes three lines of boilerplate, which you could abstract out into an inheritable class, should you so desire.

As for "In C++ you write", it's the same as saying "in Python you write __enter__ and __exit__", but instead of instantiating via `std::unique_ptr` you use `with`.

Huh, neat. I'd seen @classmethod a few times but wasn't sure what it did. I need to see if I can refactor some code now.

Python has context managers, which were added for exactly this purpose.

  with alloc_resource() as resource:
      resource.use()

I mentioned those. They work, but they're just a weak form of RAII without any extra power.

Can you elaborate on "extra power"? A c++ constructor/destructor pair is equivalent to __enter__ and __exit__. I fail to see how this grants a significant amount of power. There's certainly differences, but the gap is probably not as large as your weasel words make it out to be.

You complain about having to put initialization into 2 constructors, but there's the flip-side with things like mutexes. In c++, you have to have 2 classes, one for the lock and one for the guard. Whereas with a context-manager, you have one class and the locking code is in the __enter__ and __exit__.

    with self.lock:
        self.do_stuff()

In that case, I would say that the context-manager is nicer.

I didn't have any example of extra power, just in with blocks you have some downsides compared to RAII but no upsides. By downsides I mean that in C++ you write the constructor/destructor and never worry about it again, but in python every caller has to use a with block, plus what I said above about exceptions being thrown before __enter__.

I haven't done much with mutexes, but doesn't having it split over 2 classes introduce a race condition? Seems like a weird way to implement it to me.

Agree with @czinck. It works, it does the job, but it's not as fool proof as:

    {
        Type obj;
        // do stuff
    }
    // obj destructor just ran

C# and other languages have similar paradigms, but they require more attention to detail than a destructor does.

then maybe you will be interested in PHP - it has good RAII and I use it in one lib for resources control and mutexes.

Maybe they should send an email/SMS to notify you that email/SMS had been disabled. (And, an email/SMS to the old address when the email/SMS is changed too.)

IAP games are like going to the arcade and paying some small amount per play, rather than buying the game upfront and getting to play as much as you want.

Often this comes up in the context of a conversation with people you don't know very well. (Like, on an internet forum.) When you're discussing some subject X with people you don't know that well, and you complain about X, people might get the impression that you don't much care for X. For all values of X, not just kids.

People that mostly like their kids and kids in the abstract, but nonetheless want to complain about some aspect of kids (understandably!), may not wish to create the impression that they're not into their kids. So they make sure to include a disclaimer in their complaint that their kids are wonderful, etc.

It's different among close friends -- there you find people complaining that their kids kept them up all night or whatever without feeling the need to include a "my kids are wonderful" every third sentence. Because their close friends know this implicitly.