I won't probably be too wrong to say that, System administration is probably the most underappreciated and thankless genre among work units in any software development organization nowadays. So let’s talk about that in urging the snarky developers to change their point of view towards fellow system administrators.
We're living in the era of web applications, and almost all softwares are run on the someone else’s computer AKA cloud. So, software engineering/development has changed a lot; we've come from developing host-native apps to developing cloud-native apps. To keep up the pace, System administration has changed a lot as well; from manually building systems from scratch, we've introduced fully automated system building, packaging and what not!
No, we can't.
The magic/dunder methods are looked up implicitly on the type definition while special functions, keywords, or operators are to be resolved by the runtime. They don't follow the regular attribute lookup procedure i.e. doesn't follow the
__getattribute__ chain. This makes them fast to access as the runtime only needs to search on the type, not on instance
So, what about classes themselves? What dunder methods should be used when any special function is called on them?
As any class is an instance of a metaclass, the dunder methods defined on the metaclass would be used.
Let's see a few examples to get a clear overview of all these. We'll be using the
repr function, for which the interpreter will call
__repr__ dunder method implicitly, in order to get the representation of an object.
Why exception name bindings are deleted while exiting the
TL;DR: To prevent the creation of reference cycles.
Traceback object attached with any exception object has a stack frame of execution containing the local, global, builtin namespaces, the code object, and other necessary entities attached. This might seem complex at first but when we follow the attribute chain to get a higher level view, it would be easier to reason about.
Let's define a simple function that will do thing but return an intentionally raised exception (which is a bad idea, i'll explain the why in a jiffy):
def foobar(num): spam = 'egg' baz = num try: raise RuntimeError # Bind `RuntimeError` object to name `exc` except RuntimeError as exc: return exc
After the introduction of the
send method of generators in Python 2.5, it was possible to send values into generators, essentially making them a two-way object. This leads to the possibility of single-threaded coroutine-based co-operative multitasking. Before 3.5, one could create a coroutine by the
types.coroutine) decorator, and pause a coroutine (when doing I/O) by using
yield from which basically is a syntactic sugar for
yield-ing values from another generator (using a
for loop, for example).
In Python 3.5, the
await keywords were introduced to support the Async operations natively, with:
asynckeyword replaces the need for an explicit decorator to create a coroutine
awaitis just a syntactic sugar for
Many times while debugging, we need to find all the files (e.g. shared libraries, configuration files, caches, logs, dumps, state files, journals, and so on) a process is opening for reading data from to get hints about the program's design and workflow.
Otherwise we want to follow the lengthy route of reading the source code of the program, we could leverage the powerful system call tracing tool
strace to get the job done fairly easily.
strace binary comes with the
strace package; so we need to install it first (if not done already):
% dpkg -S "$(command -v strace)" strace: /usr/bin/strace
While doing e2e (end to end) tests for Dealiable.com frontend (
Vue.JS), i've bumped into something interesting, which was really fun to fix/find a workaround of.
Firstly, for e2e tests, i've used Nightwatch.js, which uses the Selenium API, and is written in Node.js.
The problem was that, I was not being able to clear some
input tag field data using the API provided by Nightwatch --
browser.clearValue. For example:
My recent work, Dealiable.com, has entered the public beta phase and will be stable soon! The domain was registered on 29 June, 2018 (Friday) and then made public the same day. This was a really fun one work on, with so many challenges, so many corner cases, and so many more to come and tackle. But it feels really awesome to get this piece of work rolling and seeing people appreciating the idea and work.
Postgresql's postmaster (Postgresql cluster [not cluster in the usual notion] manager), listens on TCP socket and also on UNIX domain socket (for localhost use only). Using UNIX doamin sockets to connect to Postgresql is very useful as it is bound to filesystem access only, no network socket involved. As a result, we get less overhead and less resource usage.