Saturday, 31 December 2022

IIEF's

I've been fiddling with Kotlin these last weeks and it's an absolutely amazing language. Honestly I didn't expect it, as it's an static language and I've always considered dynamic languages more appealing to my "Freak inside", but the expressiviness of Kotlin is just incredible. Notice that this expressiviness comes with a price, as there's a learning curve to understand what that beautiful and expressive code is doing. I'm going to use a sample comparing Groovy, JavaScript and Python. Hey, I absolutely love JavaScript and Python, being dynamic languages they still have some rare features that are not possible in Kotlin, but my overall feeling is that at least for non-browser projects, probably I would favor Kotlin for any relatively big project due to its combination of a beautiful language with the amazingly performant JVM.

Same as JavaScript, Kotlin has IIFE's (Immediatelly Invokable Function Expressions). They come very handy when you need a closure, and you'll only have one instance of that closure. In this case, as you won't be invoking that "closure factory" function in several places with different arguments to obtain different instances, but just once, you can just define and invoke the "closure factory" in the place where you first need that instance. As I'm still learning the crazy kotlin syntax, writing the same "one shot" closure factory in Kotlin, JavaScript and Python seemed like a pretty nice exercise to me. Let's see:

This is the Kotlin's most compact code I've come up with. It's beautiful and idiomatic, but I would not say it's easy to read, particularly if you stop coding in Kotlin for some time.


val formatWithCounter = {
    var counter = 0
    { txt: String, wrapper: String -> "${++counter}.${wrapper}${txt}${wrapper}" }
}()


println(formatWithCounter("Paris", "|"))
println(formatWithCounter("Paris", "+"))
// 1.|Paris|
// 2.+Paris+

The JavaScript code is slightly more verbose, but I guess feels a bit clearer. I would say it's the winner for me.


const formatWithCounter = (() => {
    let counter = 0;
    return (txt, wrapper) => `${++counter}.${wrapper}${txt}${wrapper}`
})();


console.log(formatWithCounter("Paris", "|"))
console.log(formatWithCounter("Paris", "+"))
// 1.|Paris|
// 2.+Paris+

The Python code is much more verbose and less elegant. The only Function Expressions in Python are lambdas (that in Python can only contain an expression). We still lack (multi)statement lambdas, as Guido said in 2006 that they were "unpythonic"... which is a reasoning that upsets me quite a bit, and we can not use "def" as an expression. So we have to define the factory function first and invoke it in another line. The same goes for the function being created and returned from the factory, that can not be just a lambda cause in this function I need to add the "nonlocal" line so that the counter variable is trapped by the closure (otherwise, as the variable is being modified, the compiler would consider it as local rather than trap it from the surrounding scope).


def factory():
    counter = 0
    def _format_with_counter(txt, wrapper):
        nonlocal counter
        return f"{(counter:=counter+1)}.{wrapper}{txt}{wrapper}"
    return _format_with_counter   
format_with_counter = factory()


print(format_with_counter("Paris", "|"))
print(format_with_counter("Paris", "+"))
# 1.|Paris|
# 2.+Paris+

An additional note regarding the Python version. I've used the walrus (:=) operator (assignment expressions). These 2 codes are equivalent:


        return f"{(counter:=counter+1)}.{wrapper}{txt}{wrapper}"
        
        # is equivalent to:
        
	counter += 1
        return f"{counter}.{wrapper}{txt}{wrapper}"
        

Saturday, 24 December 2022

Bolo de Arroz

I've recently been lucky enough to spend a few days in Lisbon. I already wrote a post 5 years ago about how lovely the city is. Lisbon is still booming, and that massive advantage over other gorgeous European cities that I mention in that post has not done but to increase, as France, Belgium, Germany... are each day more and more submerged by that kind of incompatible and hostile "culture" arrived from abroad and that hopefully is not ravaging Portugal yet. Also, the Left-wing and ecologist mindset in Portugal seems to be rather civilized (the way it was intended to be), far away from the ultra-violent Far-Left, Islamo-Left, Eco-Madness scum in France that propagate self-hatred, racialism and communitarism.
As for cities in Eastern Europe, the fact that they are more conservative is no longer something that bothers me particularly, but the pro-USA fanatism and servility to the fucking North American empire of countries like Poland, the Baltic ones and so on (and their senseless hatred for anything related to Russia) is something that now makes me have a really negative perception of them.

Unexpectedly, I'm not going to talk about architecture, about charming streets, beautiful view-points... but about something I think I rarely talk about in my blog, food!. I mentioned in that previous post that Portuguese sweets are pretty good, and coffee is absolutely delicious and cheap. That statement remains completely true. The most iconic Portuguese sweet, the Pastel de Belem/Pastel de Nata is really popular in I guess most of Europe (for example you have them in Lidl in France and Spain, and in Mercadona in Spain). Though the ones that you buy in a supermarket (the ones in a Portuguese supermarkets are basically the same than those in Lidl abroad) are years ahead from the ones that you can buy in Belem, right out of the oven, with a powdered sugar and a cinnamon sachet, they are still delicious. Portuguese people are very fond of their coffee and sweets, so there are cafetarias/pastelarias in every corner (they are so omnipresent as bars and cafes in Spain) and it's a very common tradition (respected also by the young generations) to go to them to have a coffee and a sweaet in the afternoons (and obviously for breakfast). From the beautiful assortment of sweets that you'll find in a "Pastelaria", there's one that I have rediscovered in this trip, the delicious Bolo de Arroz. Forget you English muffins, Bolo de Arroz plays in an upper level (the same level as French magdalenes). I used to eat them with breakfast in 2008 while working in Lisbon, but in later visits I seemed not to appreciate them so much, and now I think I know why. In those visits I had bought them in MiniPreco supermarkets (part of Spanish Dia chain). This trip I had a Pingo Doce supermarket very close to my hostel, and I bought them there (it has its own "patisserie", cooking stuff in place), the difference is huge, pretty huge, they are way better. I don't think there's any difference betwen these ones in Pingo Doce and those that you can buy in a street patisserie.

I can not talk about Lisbon without bringing up memories of that amazing vegan buffet that has become the icing on the cake in my visits to Lisbon, Jardim das Cerejas. Right in the center of Lisbon you find this small, cosy restaurant, with a neighbourhood feeling, where a buffet with a delicios veggie soup, salad and 4 main dishes along with 2 types of rice costs just 9.5 euros. Add it a freshly squeezed juice (you can mix apple, orange, carrot...) for just 2.5 euros. The food is absolutely delicious. Some of the dishes have a black sauce that I guess is a mix of soja sauce with something more, that has such an intense taste, buff...

Friday, 16 December 2022

Boolean Coercion/Conversion, JavaScript vs Python

How a not boolean value is mapped to true or false (either converted using a function or operator, or coerced when used in a boolean context) is one of those things that I need to rethink from time to time. Adding to this that my 2 main languages as of today, Python and JavaScript, have some differences on this topic, I've thought it useful to put a small summary here.

Javascript
This post is a pretty good reference. Falsy values in JavaScript are:
undefined and null (the 2 nullish values), false, NaN, 0 and "" (empty string).
We can convert any value to boolean either with '!!value' or with 'Boolean(value)'

There's something more to bear in mind. Not al falsy values have the same behaviour with the == operator. 0 is equal to false, and "" is equal to false:

0 == false
true
"" == false
true
1 == true
true

undefined == false
false
null == false
false
NaN == false
false

null == undefined
true

Python
Answers here are a pretty good reference. The following values are considered false:
None, False, 0, "" (empty string), any other empty container: (), [] and any empty mapping, for example, {}..
Additionally, a custom class can define the __bool__() method, that will be used when converting instances of that class to boolean.
We can convert any value to boolean either with 'not not value' or with 'bool(value)'

We also have to bear in mind what happens when using the equality operator "==". Only 0 == False and 1 == True are true. All other cases are false:

>>> 1==True
True
>>> 0==False
True
>>> None==False
False
>>> [] == False
False
>>> [] == True
False
>>> 2==False
False
>>> 2==True
False

So the big difference betwewn Javascript and Python regarding boolean conversion/coercion is that in JavaScript an empty array and an empty object are coerced to true, while in Python they are coerced to False. In addition, in Python we can customize the behaviour of our classes by implementing the __bool__ method.

Sunday, 4 December 2022

Future vs Future (asyncio vs concurrent.futures)

I've been recently working with Python's very nice concurrent.futures.Executor (the ProcessPoolExecutor particularly). When combining it with the async - await magic I've come across an important gotcha that had me confused for a while.

So I have a function running inside an eventloop. In that function I create a ProcesPoolExecutor and submit some actions to it. As soon as one action completes I want to do something with its result and then continue to wait for the next action, so until all of them are done. My code looked like this:


async def parse_blocks(blocks):
	parser = BlockParser()
	pending_blocks = []
	for block in blocks:
		future_result = executor.submit(parser.parse, block, 0)
		pending_blocks.append(future_result)) 
	while len(pending_blocks):
		done_blocks, pending_blocks = await asyncio.wait(pending_blocks, return_when=asyncio.FIRST_COMPLETED)
		for done_block in done_blocks:
			print("block parsed!)
			result_writer.write(done_block)
	print("all blocks parsed")


The above code was giving me an odd exception in the wait call: TypeError: An asyncio.Future, a coroutine or an awaitable is required. But, executor.submit returns a Future, so what's happening?. Well, executor.submit returns a concurrent.futures.Future, and asyncio.wait is expecting an asyncio.Future. Hopefully we can obtain an asyncio.Future from a concurrent.futures.Future by means of asyncio.wrap_future. I found about it here.

To convert a concurrent.futures.Future into an asyncio.Future, you can call asyncio.wrap_future. The returned asyncio future is awaitable in the asyncio event loop and will complete when the underlying threading future completes. This is effectively how run_in_executor is implemented.

So this code now works fine:


async def parse_blocks(blocks):
	parser = BlockParser()
	pending_blocks = []
	for block in blocks:
		future_result = executor.submit(parser.parse, block, 0)
		pending_blocks.append(asyncio.wrap_future(concurrent_futures_future)) 
	while len(pending_blocks):
		done_blocks, pending_blocks = await asyncio.wait(pending_blocks, return_when=asyncio.FIRST_COMPLETED)
		for done_block in done_blocks:
			print("block parsed!)
			result_writer.write(done_block)
	print("all blocks parsed")


It seems odd to have to different Future classes, that both represent the same, a result that will be provided in the future. Well one of the differences that I get (for example from this discussion) is that asyncio.Future.add_done_callback will invoke its callbacks through the event loop, which I guess is necessary for the coopeative nature of asyncio. A concurrent.futures.Future will not use the eventloop for those callbacks, so this probably would break that cooperativism. This discussion goes a bit more in depth.

Sunday, 27 November 2022

Try Expressions

I've recently found that Kotlin supports try-catch-finally expressions (in the same vein as switch expressions). They seem particularly useful to me when executing a block that will assign to a variable or assign a default if the block fails, like this:



fun main (args: Array) {
  val str="23"
  val a: Int? = try { str. toInt () } catch (e: NumberFormatException) {-1}
  println (a)
}


I think this is the first time I see this feature in a programming language, and as usual I've been thinking about how to simulate it, in this case in JavaScript. We can easily simulate the try-catch expression with a tryFn function (emulating try-catch-finally would be more complicated).



function tryFn(fn, exceptions, onErrorFn){
    try{
        return fn();
    }
    catch (error){
        if (exceptions.some(exception => error instanceof exception)){
            return onErrorFn(error)
        }
        else{
            throw error;
        }
    }
}

//val = tryCatch(fn1, [Error1, Error2], onErrorDefaultFn)


We can use this function like this:



class InvalidUrlError extends Error{}
class InvalidPostError extends Error{}
class InvalidUserError extends Error{}


function getPost(url, postId, user){
    if (!url)
        throw new InvalidUrlError("Wrong URL")
    if (!postId)
        throw new InvalidPostError("Wrong Post")
    if (!user)
        throw new InvalidUserError("Wrong User")
    return `Post ${postId} by {user} content`;
}

function formatPost(post){
    return `[[[${post}]]]`;
}

let infos = [
    ["server.org", "1", "xuan"],
    [null, "1", "xuan"],
    ["server.org", null, "xuan"],
    //["server.org", "2", null],
    ["server.org", "3", "xuan"]
]


for (let info of infos){
    let post = tryFn(() => formatPost(getPost(...info)),
        /*catch*/ [InvalidUrlError, InvalidPostError], (ex) => {
            console.log(`caught error: ${ex.constructor.name}`);
            return "No Post"
        } 
    );
    console.log(`post: ${post}`)
}


Well, not sure I will ever use it, but I think it's a valid attempt.

This reminds me a bit of cases where combining await and .catch() for async code rather than wrapping the async call in a try-catch makes the code cleaner. I'm talking about this

Saturday, 19 November 2022

FIC Xixón 2021

Sort of a "deja vu". One year ago, when I was going to start to write a post for that year's edition (2021) of FIC Xixon (FICX edition number 59) I realised that I had not published anything about the previous, non-covid, edition (I'd had it partially written for almost 2 years but had forgotten to complete it), so I finished it and published it. Now, while starting my post for 60th edition (that ends today) I've just realised that in the end I had not written anything about the 59th edition... so I'm posting now a mini-summary of what I watched last year.

FIC Xixon 59 took place in one week of 2021 in a beautifully, massivelly rainy November. I only attended 3 films (that seems like a constant since I returned to Xixón in 2018). As I only intended to attend to screenings in Teatro Jovellanos I did not dig much into the program, I just checked what was on display there and came up with these 3 films that did fit my schedule:

  • Maitxable. A very powerful Spanish film. Based on a true story. Maixable, the widow of a Politician (Juan María Jáuregui) murdered by ETA accepts to meet one of the assasins, that while serving his prison sentence has come to regret his actions and moved away from the band.
    If you are interested in the bloody "Basque Conflict" that caused so much pain and suffering, you must watch the Spanish series Patria, that with its gloomy atmosphere perfectly reflects the tensions, contraditions, fanatism and fear that reigned in EuskaHerria for decades.
  • Integralde. Excellent Romanian film. Perfectly mixing hilarious moments with tension and sadness, all of it wrapped in the beauty of Romanian mountains and forests.
  • Bebia, a mon seul desir. A strange story set in a strange place (Georgia feels still rather "exotic" and mysterious to me), filmed in black and white with a rather arty feeling. I did not particularly like it, but do not consider it as a lost of time either.

Monday, 14 November 2022

Python Optional Chaining Revisited

I've been thinking again about that Python missing feature (Optional Chaining) I wrote about in this post. It seems like there are no plans to approve the PEP-505 (None aware operators), as there are quite a few opponents to the syntax. I have to admit that it's true that coming across something like:
obj?.client?.getPosts?.("url")?[0]?["title]
is not particularly beautiful and goes rather against the "almost pseudocode" syntax ideal of Python, though anyway I think it's much better than a long chain of if's. Having just a safe_access function added to the standard library would be a good alternative. Thinking of that, I've realised that the implementation of such a function that I wrote for that post is rather stupid :-), does not work with indexing and has the terrible inconvenience of using strings for the attributes names.

The different access errors that we can get when trying to access "things" (attributes, indexing, invoking) on None, or on an object lacking such attributes or indexing or not being callable, etc are: TypeError, KeyError, IndexError, AttributeError, so why not to write our code like this:


try:
	first_title = obj.client.getPosts("url")[0]["title"]
except TypeError, KeyError, IndexError, AttributeError:
	first_title = None
	

Well, that's OK, but it's 4 lines vs 1 line if we had an optional chaining operator. So, let's put the try-catch in a function, and use a lambda to express the access chain, like this:


def safe_access(fn):
    try:
        return fn()
    except (TypeError, KeyError, IndexError, AttributeError):
        return None
        

first_title = safe_access(lambda: obj.client.getPosts("url")[0]["title"])


Honestly I think it looks quite good. Notice that I'm not passing the object being accessed as a parameter to the lambda, I'm directly trapping it as a closure variable. Having a function like this in functools would be even more convenient that implementing the "?" thing, as it would not involve any addition to the language syntax.

Thanks to looking into this topic again I've come across 2 very interesting ideas. One is the Maybe pattern, and its implementation in Python. The other one quite blew me away. An implementation of PEP-505 as a polyfill. So, how can you do that? Well, you can hook into the modules import process and do crazy stuff with them like transforming their source code before python compiles them to bytecodes. This way, you can add extra features to the language as far as you can then compile them to standard python. This is a very powerful feature but that seems rather unknown. The modules import process is documented here