Recursions in Python 3.8

Posted in General on July 13th, 2019 by kay – Be the first to comment

In Python 3.8 we can finally write short recursive functions:

>>> (fac := lambda n: (1 if n<2 else n*fac(n-1)))
<function <lambda> at 0x000001AFD258D550>
>>> fac(4)

In the same way we can define the notorious fixed point combinator

>>> (Y:= lambda f: lambda *args: f(Y(f))(*args))
<function <lambda> at 0x000001AFD257E0D0>
>>> fac = lambda f: lambda n: (1 if n<2 else n*f(n-1))  # fac in non recursive form
>>> Y(fac)(4)

Life is good again!

Open source saturation

Posted in General, Programming Culture on August 7th, 2010 by kay – 7 Comments

Reading the following post of Jimmy Schementi who explained his exit at Microsoft with the loss of MS’s interest in IronRuby I start to wonder if this isn’t a sign of the times? Open source projects get started by a small team of employees and killed when they don’t attract a community which brings them forth what rarely ever happens because everyone in OSS is already busy and either engaged with a major project, a brand which has been established a few years ago like (C)Python, Rails, Linux or Django¬† or doing solo acts as in my own case. Same with Google Wave which was promising but the only wave it produced was a Tsunami of initial attention in the wikiredditblogosphere. Everyone expected Google would bring it forth just like any other commodity. I guess the same would happen to their Go language which was started by a superstar team of veteran programmers and would immediately go away if Google discontinues investment.

There are very few brands which are both new and do well like Clojure and Scala which seem to follow Pythons BDFL model and they are – unsurprisingly? – programming languages. Are there other examples of OSS projects that peaked in the last 2-3 years and established a community of regular committers who are not interns of a single company or do we see an almost inevitable saturation?


Posted in General on July 16th, 2010 by kay – Be the first to comment

Trails in a Langscape

Welcome to Trails in a Langscape which is the new title of this blog. It is a minor change since URLs are not affected and the character of the blog will also remain the same. Langscape is the successor project of EasyExtend and is publically hosted at Google Code.

Since I created this WordPress blog instance I slowly worked on a new EasyExtend release. I published lots of related technical ideas but never released any code. Now the code is out. It lives in an Hg repository, it is filed under a new label and hopefully a first packaged Langscape 0.1 release will follow soon. There is no project documentation at the moment and I still think about its organization. Another open issue is packaging and distribution, but I have no idea what is up-to-date in this area, how Langscape is possibly used, if anyone will ever create langlets or just use the growing toolbox applicable to Python, including syntactically guarded search and replace.

Europython 2010

Of course the time of publication is not arbitrarily chosen. I attend to Europython 2010 next week in Birmingham and have a talk about EasyExtend/Langscape at Wednesday late in the afternoon before we leave for Conference dinner. I hope many of you go to Europython as well and I’ll find a few of my casual readers in the audience. If the talk is so good as the fun I had preparing my slides, you’ll enjoy it as well.

reverb – a revival

Posted in General on February 28th, 2010 by kay – 3 Comments

Sometimes software is given up by people and you realize it only a few years later.  Large packages or libraries will inevitably be flagged as legacy and die but tiny modules might have a chance to survive and find a maintainer. I have done the latter now for

The future of EasyExtend

Posted in General on October 3rd, 2009 by kay – 4 Comments

The state of EasyExtend

Maybe an autumnal look on EasyExtend is justified. EE was and is an alien project which never resonated well with the Python community and its possible users. Actually up to now I don’t no anyone who has ever used it ( besides myself, of course ) and I wouldn’t wonder if this isn’t going to change in the future. For a Python programmer there are numerous alternatives now like python4ply, MetaPython and also 2to3 – why not? – which can be used to extend Python. None of them were available when I started with EE in 2006. Some people might also attempt to revive Logix which is among the more famous “dead” projects in the Python community. Logix might be in style and ambition precisely what Python users are looking for. EasyExtend isn’t even tangential.

Whenever I thought EE becomes stable I challenged it with bigger, more difficult problems: simultaneous transformations of multiple langlets, context sensitive languages, quirky real world grammars, online syntax definitions, source directed transformations, more expressible grammar syntax, language agnosticism etc.

Another major issue is performance. In the past I’ve used Psyco and also Cython. They boosted performance quite well and I got 3-5 times speedup for lexer+parser but I have clearly no performance model and I don’t see why those speedups shall be the limit? Python isn’t the right tool for the right job here and I suspect this had been an impediment for the current implementation already, since I overused containers like tuples and dicts in favor for classes and objects and their slow attribute access.

From EasyExtend to Langscape

The most likely path into the future of EasyExtend is to factor out components like the parser generator, the langlet transformer and most of the csttools and rewrite them in C++. I’ll probably start a completely new project which I intend to call “Langscape”. By means of SWIG it shall be possible to use Langscape also from environments like the JVM or the CLR. As a Python front end I’ll use the code I’ve developed for EasyExtend 4 which will probably never go public in the current form. I’ll still consider doing the functional testing in Python and I also want to preserve interactivity. Both the language front-end as well as back-end bindings become separated from Langscape. Langscape only deals with source code, grammars and CSTs.

Jython – 64K ought to be enough for anybody

Posted in General on June 10th, 2009 by kay – 9 Comments
Jython 2.5rc4 (Release_2_5rc4:6470, Jun 8 2009, 13:23:16)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_13
Type "help", "copyright", "credits" or "license" for more information.
&gt;&gt;&gt; L = range(10000)
&gt;&gt;&gt; eval(str(L))
Traceback (most recent call last):
  File "", line 1, in
java.lang.ClassFormatError: Invalid method Code length 99894 in class file org/python/pycode/_pyx9
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at org.python.core.BytecodeLoader$Loader.loadClassFromBytes(
        at org.python.core.BytecodeLoader.makeClass(
        at org.python.core.BytecodeLoader.makeCode(
        at org.python.util.InteractiveConsole.interact(
        at org.python.util.jython.main(
java.lang.ClassFormatError: java.lang.ClassFormatError: Invalid method Code length 99894 in class file org/python/pycode/_pyx9

64K ought to be enough for anybody.

irb(main):001:0&gt; L = (1...10000).to_a ;nil
=&gt; nil
irb(main):002:0&gt; SL = eval "["+L.join(",")+"]"; nil
=&gt; nil
irb(main):003:0&gt; SL[10..15]
=&gt; [11, 12, 13, 14, 15, 16]

Just to get this straight. It is argued for almost decade that Python cannot have some advanced features ( the whole FP/Stackless story ) because this would break Jython and Jython is implemented s.t. eval is broken and Jython users cannot even import Python data-structures like generated dicts or lists that exceed 64KB. What about backporting this behavior to CPython in order to preserve conformance between implementations?

Note that the Ruby example is JRuby – not that anyone blames the JVM. Ruby is morally inferior though and wildly coerces types on its own behalf but this is another story.

Singular irregularities

Posted in General on June 6th, 2009 by kay – 3 Comments

An irregularity is a shape or rule violation. It supposes that objects are built according to rules but there are exceptional cases that don’t really fit or do at least violate our expectations of the building law. An irregularity is singular if the building law is violated in a single case.

The best known example in Python is the syntax of tuples:

()                          # empty tuple
(arg)                       # parenthesized expression - no tuple!
(arg,)                      # tuple with one element
(arg1, arg2, ...)           # tuple with many arguments

Another more recent example is the set syntax in Python 3 which requires an ambiguity resolution involving an empty set and an empty dict:

{}                          # empty dict!
set()                       # empty set !
{arg}                       # set with one element
{arg1, arg2, ...}           # set with many elements

Some people suggested to drop parentheses around arguments in function calls. This leads to an ambiguity between a function object and function call without arguments. In order to resolve it one might introduce another singular irregularity:

func                      # object !
func arg1 arg2...         # function call with arguments
func()                    # function call
func(arg1, arg2, ...)     # function call with arguments

Are singular irregularities design mistakes or are they acceptable trade offs for avoiding verbosity and/or the introduction of even more syntax?

The statement that never was

Posted in General, Python on April 15th, 2009 by kay – 1 Comment

The Python release archive is a nice repository for archaeological findings. My biggest surprise was the existence of an access statement and access keyword in the pre-history of Python 1.5.0. The syntax was already specified in release 1.0 with an accompanying accessobject.c and it began to fade in Python 1.4.

The access statement

That is how the access statement was defined in 1.0

access_stmt: 'access' ('*' | NAME (',' NAME)*) ':' accesstype  (',' accesstype)*
accesstype: NAME+
# accesstype should be ('public' | 'protected' | 'private') ['read'] ['write']
# but can't be because that would create undesirable reserved words!

The access_stmt was a small statement i.e. one that doesn’t contain a block and could be used like print, del or exec.

So the proper use of the access statement would be like

class Point:
    access x, y, z: private write, public read

or more compact:

class Point:
    access *: private write, public read

The word public wasn’t a language keyword which made it possible to use it in this way:

class AccessModifier:
    access public: public
    access private: public
    access protected: public

Note that the access statement was purely declarative even more so than Java’s where you can write

public int x = 10;
and define x while specifying its type and access modifier. It was also more elaborated in terms of intended protections by means of differentiating between read and write.

How it never took off and gone away

In the HISTORY file of Python 1.0 we find the notice

There’s a new reserved word: “access”. The syntax and semantics are still subject of of research and debate (as well as undocumented), but the parser knows about the keyword so you must not use it as a variable, function, or attribute name.

In Python 1.4 the access statement was already uncommented from the Grammar.

The story ends with the following remark in the HISTORY of Python 1.5:

‘access’ is no longer a reserved word, and all code related to its implementation is gone (or at least #ifdef’ed out). This should make Python a little speedier too!

Future !

Posted in General on February 25th, 2009 by kay – 2 Comments


Posted in F, General on February 8th, 2009 by kay – Be the first to comment

The Flusser hierarchy

4 the natural man in the state of concrete spatio-temporal experience. No mind in escape.
3 the modeler and maker whose hands shape the things and brings them to rest.
2 the artist imagines the world. Eternal return and circulation on a magical surface.
1 the author linearizes the flow of things in symbols and historical time.
0 the programmer computes the it from the bit.