In light of recent things one can sensiblyask just how long people can keep using Python 2. At one level theanswer is 'until there is some significant problem with Python 2that the Python developers don't fix'. This could either be asecurity issue or something important that Python 2 and its coremodules don't support (eg, at one point IPv6 would have been such athing). At the moment it isn't clear howlong the Python developers will be fixing things in

In light of the still ongoing issues with Python 3 ,a very interesting question is what makes moving code to Python 3so difficult. After all, Python has made transitions before, eventransitions with little or no backwards compatibility, and giventhat there is very little real difference between Python 2 and 3 you would normally expect that people would haveno real problems shifting code across to Python 3. After all, thingslike changing from using print to using print() are not really abig deal.

In my view

Alex Gaynor just wrote About Python 3 , which is not abright and happy assessment about the state of Python 3. He says manythings that I agree wholeheartedly with, from a position of authorityand of good writing. He also crystallizes a number of things for me,such as the following:

Since the time of the Python 3.1 it's been regularly said that thenew features and additions the standard library would act as carrotsto motivate people to upgrade. Don't get me wrong, Python

Just about exactly two years ago I wrote Python3NewCode , in which Iwaved my hands a bunch and then said:

Ignoring [my handwaved issues] as ultimately unimportant, I don'tthink there's any reason not to write new, non-sysadmin code in Python3.

I take all of that back. In retrospect I was being too nice to Python 3back then and I was wrong to do so. Here is my new view: you shouldavoid Python 3 even for new code because

The venerable fmt program is not something that I normally think of asa command that I use in my scripts or on the fly pipelines; I usuallythink of it more as, say, something that I use to reflow paragraphs in vi . But it has quietly been making its way into an increasing numberof them because it turns out that fmt is the easy and lazy way to dotwo symmetrical things: to word-split lines and to merge 'one word perline' output back to a single line.

It started with vi becoming my sysadmin's editor , the editor that I used for quickedits because it was everywhere, worked in minimal environments, andit started fast. But of course it didn't stop there. Any good tool hasa virtuous circle where more use makes you more familiar with it andthus makes it easier to use so you use it more; vi goes well beyondthat in terms of rewarding extended use . Vi's march into myediting life has not been fast but it'

Yes, I know, tags are on my mind lately. In particular I've beenthinking about what I want to do with them. Ultimately what it comesdown to is supporting real blog usability ,specifically both encouraging and rewarding blog visitors for exploringoutwards from whatever entry they initially landed on. When I wrote that entry I said that the most powerful way todo that was probably some sort of 'related entries' feature; tags are anobvious way of providing that.

There is an important corollary: for

Once upon a time you could create a list of valid top level domains andthus rapidly validate if an email address presented to you was evenpossibly correct. If you were slightly more bootleg you could do itwith patterns, since all TLDs were either two letter country codes orthree letter 'traditional' TLDs (and you could actually list those).This era started to crumble a while after I did my bootleg hacks toa mailer here, with the introduction of things like .info , but fora while I

In EntryAsFileTagProblem I ran over the problem 'entry as file' blogengines have with tags (because they need efficient two-way queries onthe mappings between tags and entries) and suggested that one solutionwas a completely external mapping file (or files) of tag information.I've since realized that there is an additional reason to like thisapproach.

Put simply, having tag/entry mappings in an external file allows youto change the tags associated with an entry without editing the actualentry's file;